From jcholast at redhat.com Mon Oct 1 07:19:46 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 01 Oct 2012 09:19:46 +0200 Subject: [Freeipa-devel] [PATCH] 317 Improve StrEnum validation error message In-Reply-To: <5064468A.5000204@redhat.com> References: <5064468A.5000204@redhat.com> Message-ID: <50694412.1010505@redhat.com> Dne 27.9.2012 14:28, Martin Kosek napsal(a): > Do not print list of possible values as "%r" but simply as a list > of quoted values which should make it easier to read for users. > Also add a special case when there is just one allowed value. > > https://fedorahosted.org/freeipa/ticket/2869 > > > Examples of the improved Enum validation error messages: > > # ipa automember-add foo --type=bar > ipa: ERROR: invalid 'type': must be one of 'group', 'hostgroup' > > # ipa trust-add foo --type=foo > ipa: ERROR: invalid 'type': must be 'ad' > > Martin > IMO instead of doing this: + else: + return _("must be empty") we should not allow empty "values" kwarg in Enum at all, i.e. check that len(self.values) > 0 in Enum.__init__. Also, I have opened , as we use %r in more places where we should not. Honza -- Jan Cholasta From mkosek at redhat.com Mon Oct 1 08:05:38 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 01 Oct 2012 10:05:38 +0200 Subject: [Freeipa-devel] [PATCH] 317 Improve StrEnum validation error message In-Reply-To: <50694412.1010505@redhat.com> References: <5064468A.5000204@redhat.com> <50694412.1010505@redhat.com> Message-ID: <50694ED2.3020007@redhat.com> On 10/01/2012 09:19 AM, Jan Cholasta wrote: > Dne 27.9.2012 14:28, Martin Kosek napsal(a): >> Do not print list of possible values as "%r" but simply as a list >> of quoted values which should make it easier to read for users. >> Also add a special case when there is just one allowed value. >> >> https://fedorahosted.org/freeipa/ticket/2869 >> >> >> Examples of the improved Enum validation error messages: >> >> # ipa automember-add foo --type=bar >> ipa: ERROR: invalid 'type': must be one of 'group', 'hostgroup' >> >> # ipa trust-add foo --type=foo >> ipa: ERROR: invalid 'type': must be 'ad' >> >> Martin >> > > IMO instead of doing this: > > + else: > + return _("must be empty") > > we should not allow empty "values" kwarg in Enum at all, i.e. check that > len(self.values) > 0 in Enum.__init__. Right, I fixed it. I also added a relevant test case to our unit tests. > > Also, I have opened , as we use > %r in more places where we should not. > > Honza > Thanks. New patch attached. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-317-2-improve-strenum-validation-error-message.patch Type: text/x-patch Size: 4015 bytes Desc: not available URL: From jcholast at redhat.com Mon Oct 1 09:16:13 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 01 Oct 2012 11:16:13 +0200 Subject: [Freeipa-devel] [PATCH] 317 Improve StrEnum validation error message In-Reply-To: <50694ED2.3020007@redhat.com> References: <5064468A.5000204@redhat.com> <50694412.1010505@redhat.com> <50694ED2.3020007@redhat.com> Message-ID: <50695F5D.2060302@redhat.com> Dne 1.10.2012 10:05, Martin Kosek napsal(a): > On 10/01/2012 09:19 AM, Jan Cholasta wrote: >> Dne 27.9.2012 14:28, Martin Kosek napsal(a): >>> Do not print list of possible values as "%r" but simply as a list >>> of quoted values which should make it easier to read for users. >>> Also add a special case when there is just one allowed value. >>> >>> https://fedorahosted.org/freeipa/ticket/2869 >>> >>> >>> Examples of the improved Enum validation error messages: >>> >>> # ipa automember-add foo --type=bar >>> ipa: ERROR: invalid 'type': must be one of 'group', 'hostgroup' >>> >>> # ipa trust-add foo --type=foo >>> ipa: ERROR: invalid 'type': must be 'ad' >>> >>> Martin >>> >> >> IMO instead of doing this: >> >> + else: >> + return _("must be empty") >> >> we should not allow empty "values" kwarg in Enum at all, i.e. check that >> len(self.values) > 0 in Enum.__init__. > > Right, I fixed it. I also added a relevant test case to our unit tests. > >> >> Also, I have opened , as we use >> %r in more places where we should not. >> >> Honza >> > > Thanks. New patch attached. > > Martin > ACK. Honza -- Jan Cholasta From abokovoy at redhat.com Mon Oct 1 09:24:51 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 1 Oct 2012 12:24:51 +0300 Subject: [Freeipa-devel] [PATCH] 0081 Support both unified samba and samba/samba4-packages Message-ID: <20121001092451.GU17454@redhat.com> Hi, The patch attached fixes Fedora build system issue with unified samba package (samba/samba4 packages got merged in Fedora 18 and Rawhide recently) since we depend on a wbclient.h header file path to which included versioned directory name previously (samba-4.0/ vs samba/). -- / Alexander Bokovoy -------------- next part -------------- >From 45a8c7255199dc3b8bf1c0bbb6c4535abf75c899 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Mon, 1 Oct 2012 12:18:36 +0300 Subject: [PATCH 2/2] Support both unified samba and samba/samba4 packages for wbclient.h Fedora 18 (and beyond) has moved to unified samba package, while previous versions and RHEL 6.x are still using separate samba and samba4 packages. We need to access wbclient.h header which may now be either samba-4.0/wbclient.h or samba/wbclient.h depending on a setup. This patch fixes the issue found by Fedora build system. --- daemons/configure.ac | 8 ++++++-- daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h | 10 +++++++++- 2 files changed, 15 insertions(+), 3 deletions(-) diff --git a/daemons/configure.ac b/daemons/configure.ac index ebf625ebffd8a92e0a3b050955b9376e002ed6c9..581d5640221b3ba29bf85620d3bf742ceffb3cfb 100644 --- a/daemons/configure.ac +++ b/daemons/configure.ac @@ -241,8 +241,12 @@ PKG_CHECK_MODULES([SAMBAUTIL], [samba-util]) SAMBA40EXTRA_LIBPATH="-L`$PKG_CONFIG --variable=libdir samba-util`/samba -Wl,-rpath=`$PKG_CONFIG --variable=libdir samba-util`/samba" AC_SUBST(SAMBA40EXTRA_LIBPATH) AC_CHECK_HEADERS([samba-4.0/wbclient.h], - , - [AC_MSG_ERROR([samba-4.0/wbclient.h not found])], + , + [AC_CHECK_HEADERS([samba/wbclient.h], + , + [AC_MSG_ERROR([samba/wbclient.h not found])], + [#include + #include ])], [#include #include ]) AC_CHECK_LIB([wbclient], diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h index 5c2eeddceb3983fa5793c1a7fa86c5001c47beba..f6fd0aaa2dacb037dbdda49fa7454fd6bbd1aaab 100644 --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h @@ -54,7 +54,15 @@ #include #include -#include +#ifdef HAVE_SAMBA_4_0_WBCLIENT_H +# include +#else +# ifdef HAVE_SAMBA_WBCLIENT_H +# include +# else +# error "wbclient.h header from Samba was not found" +# endif +#endif #include #include -- 1.7.12 From mkosek at redhat.com Mon Oct 1 11:40:14 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 01 Oct 2012 13:40:14 +0200 Subject: [Freeipa-devel] [PATCH] 317 Improve StrEnum validation error message In-Reply-To: <50695F5D.2060302@redhat.com> References: <5064468A.5000204@redhat.com> <50694412.1010505@redhat.com> <50694ED2.3020007@redhat.com> <50695F5D.2060302@redhat.com> Message-ID: <5069811E.7000504@redhat.com> On 10/01/2012 11:16 AM, Jan Cholasta wrote: > Dne 1.10.2012 10:05, Martin Kosek napsal(a): >> On 10/01/2012 09:19 AM, Jan Cholasta wrote: >>> Dne 27.9.2012 14:28, Martin Kosek napsal(a): >>>> Do not print list of possible values as "%r" but simply as a list >>>> of quoted values which should make it easier to read for users. >>>> Also add a special case when there is just one allowed value. >>>> >>>> https://fedorahosted.org/freeipa/ticket/2869 >>>> >>>> >>>> Examples of the improved Enum validation error messages: >>>> >>>> # ipa automember-add foo --type=bar >>>> ipa: ERROR: invalid 'type': must be one of 'group', 'hostgroup' >>>> >>>> # ipa trust-add foo --type=foo >>>> ipa: ERROR: invalid 'type': must be 'ad' >>>> >>>> Martin >>>> >>> >>> IMO instead of doing this: >>> >>> + else: >>> + return _("must be empty") >>> >>> we should not allow empty "values" kwarg in Enum at all, i.e. check that >>> len(self.values) > 0 in Enum.__init__. >> >> Right, I fixed it. I also added a relevant test case to our unit tests. >> >>> >>> Also, I have opened , as we use >>> %r in more places where we should not. >>> >>> Honza >>> >> >> Thanks. New patch attached. >> >> Martin >> > > ACK. > > Honza > Pushed to master, ipa-3-0. Martin From pviktori at redhat.com Mon Oct 1 13:35:55 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 01 Oct 2012 15:35:55 +0200 Subject: [Freeipa-devel] [PATCH] Changes to use a single database for dogtag and IPA In-Reply-To: <50640DCB.2060901@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50640DCB.2060901@redhat.com> Message-ID: <50699C3B.4050200@redhat.com> On 09/27/2012 10:26 AM, Petr Viktorin wrote: > On 09/20/2012 05:58 AM, Ade Lee wrote: >> Changes to use a single database for dogtag and IPA >> >> New servers that are installed with dogtag 10 instances will use >> a single database instance for dogtag and IPA, albeit with different >> suffixes. Dogtag will communicate with the instance through a >> database user with permissions to modify the dogtag suffix only. >> This user will authenticate using client auth using the subsystem >> cert >> for the instance. >> >> This patch includes changes to allow the creation of masters and >> clones >> with single ds instances. >> >> I have tested being able to create a master and a clone using f17 and >> dogtag 10. Note that you will need to use the latest builds on the >> dogtag repo to get some changes that were checked in today. We'll kick >> off another official f18 dogtag build in a day or so. >> >> This is a pretty big change - so I expect many issues to come up as >> things get tested. But as this will take awhile to get resolved, its >> better to get this out for review as fast as possible. >> >> Happy reviewing. >> >> Ade >> >> > > Attaching a rebased patch with a couple of style issues fixed. > - PEP8 compliance (remove trailing whitespace, use parentheses rather > than \ for line continuation, wrap touched lines at 80 characters) > - for files, use the with statement instead of the "open/close sandwich" > - don't mix tabs and spaces in install/share/certmap.conf.template > > I've also adjusted the spec file, as we need dogtag 10.0 and pki-server > now obsoletes pki-setup. > > > I still need selinux in permissive mode to install on f17, and I still > need to exclude *.i686 packages when updating. > Are the following limitations expected? IPA and Dogtag have to be updated simultaneously; it's not possible to have current IPA master with Dogtag 10, or IPA with this patch with D9. It is not possible to create a replica from a machine with a single DS to an older version without the patch -- the older version will try the wrong ports. I've tried to run ipa-ca-install on a D10 replica cloned from an upgraded (unpatched?patched IPA, D9?D10) master, and I got "Failed to obtain installation token from security domain" (see attached log). AFAICS pkispawn returns with exit code 0 on error, so our installation script fails later, on missing /var/lib/pki/pki-tomcat/alias/ca_backup_keys.p12. It would be nice if pkispawn told us it failed. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: ipareplica-ca-install.log Type: text/x-log Size: 24202 bytes Desc: not available URL: From tbabej at redhat.com Mon Oct 1 13:38:55 2012 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 01 Oct 2012 15:38:55 +0200 Subject: [Freeipa-devel] [PATCH 0014] Improve user addition to default group in host-add In-Reply-To: <50630D52.5090008@redhat.com> References: <5061894D.9010202@redhat.com> <506301B7.8070107@redhat.com> <50630D52.5090008@redhat.com> Message-ID: <50699CEF.30700@redhat.com> On 09/26/2012 04:12 PM, Martin Kosek wrote: > On 09/26/2012 03:23 PM, Tomas Babej wrote: >> On 09/25/2012 12:37 PM, Tomas Babej wrote: >>> Hi, >>> >>> On adding new user, host-add tries to make it a member of default >>> user group. This, however, can raise AlreadyGroupMember when the >>> user is already member of this group due to automember rule or >>> default group configured. This patch makes sure AlreadyGroupMember >>> exception is caught in such cases. >>> >>> https://fedorahosted.org/freeipa/ticket/3097 >>> >>> Tomas >> I fixed the typo in the commit message. It refers to the proper command now. >> >> Tomas > I would also like to see the tests that Petr Viktorin already asked for. > > Setting an automember default group to ipausers, adding a user and checking the > result should be enough. > > Martin > I added a relevant test to the test_host_plugin.py file. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0014-3-Improve-user-addition-to-default-group-in-user-add.patch Type: text/x-patch Size: 5050 bytes Desc: not available URL: From mkosek at redhat.com Mon Oct 1 13:51:58 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 01 Oct 2012 15:51:58 +0200 Subject: [Freeipa-devel] [PATCH] 0081 Support both unified samba and samba/samba4-packages In-Reply-To: <20121001092451.GU17454@redhat.com> References: <20121001092451.GU17454@redhat.com> Message-ID: <50699FFE.8050105@redhat.com> On 10/01/2012 11:24 AM, Alexander Bokovoy wrote: > Hi, > > The patch attached fixes Fedora build system issue with unified samba > package (samba/samba4 packages got merged in Fedora 18 and Rawhide > recently) since we depend on a wbclient.h header file path to which > included versioned directory name previously (samba-4.0/ vs samba/). > I am not convinced this is a correct approach, this was failing on my Fedora 18 instance anyway: # make rpms ... checking for NDR... yes checking for SAMBAUTIL... yes checking for samba-4.0/wbclient.h... no checking for samba/wbclient.h... no configure: error: samba/wbclient.h not found make: *** [bootstrap-autogen] Error 1 The problem was that samba-devel package is no longer providing wbclient.h header file: # rpm -qR samba-devel-4.0.0-150.fc18.rc1.x86_64 | grep wbclient.h # I had a discussion with Andreas (CC-ed), the root cause was a missing libwbclient-devel package which is the new provider of the samba-4.0/wbclient.h file. He was also not aware of /usr/include/samba-4.0/ -> /usr/include/samba/ change. I created a new patch with recommended approach (attached). Could you please check if it is OK? It worked for me on both Fedora 17 and 18. Thanks, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-318-add-support-for-unified-samba-packages.patch Type: text/x-patch Size: 2204 bytes Desc: not available URL: From mkosek at redhat.com Mon Oct 1 14:09:52 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 01 Oct 2012 16:09:52 +0200 Subject: [Freeipa-devel] [PATCH] Changes to use a single database for dogtag and IPA In-Reply-To: <50699C3B.4050200@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50640DCB.2060901@redhat.com> <50699C3B.4050200@redhat.com> Message-ID: <5069A430.20207@redhat.com> On 10/01/2012 03:35 PM, Petr Viktorin wrote: > On 09/27/2012 10:26 AM, Petr Viktorin wrote: >> On 09/20/2012 05:58 AM, Ade Lee wrote: >>> Changes to use a single database for dogtag and IPA >>> >>> New servers that are installed with dogtag 10 instances will use >>> a single database instance for dogtag and IPA, albeit with different >>> suffixes. Dogtag will communicate with the instance through a >>> database user with permissions to modify the dogtag suffix only. >>> This user will authenticate using client auth using the subsystem >>> cert >>> for the instance. >>> >>> This patch includes changes to allow the creation of masters and >>> clones >>> with single ds instances. >>> >>> I have tested being able to create a master and a clone using f17 and >>> dogtag 10. Note that you will need to use the latest builds on the >>> dogtag repo to get some changes that were checked in today. We'll kick >>> off another official f18 dogtag build in a day or so. >>> >>> This is a pretty big change - so I expect many issues to come up as >>> things get tested. But as this will take awhile to get resolved, its >>> better to get this out for review as fast as possible. >>> >>> Happy reviewing. >>> >>> Ade >>> >>> >> >> Attaching a rebased patch with a couple of style issues fixed. >> - PEP8 compliance (remove trailing whitespace, use parentheses rather >> than \ for line continuation, wrap touched lines at 80 characters) >> - for files, use the with statement instead of the "open/close sandwich" >> - don't mix tabs and spaces in install/share/certmap.conf.template >> >> I've also adjusted the spec file, as we need dogtag 10.0 and pki-server >> now obsoletes pki-setup. >> >> >> I still need selinux in permissive mode to install on f17, and I still >> need to exclude *.i686 packages when updating. >> > > Are the following limitations expected? > > IPA and Dogtag have to be updated simultaneously; it's not possible to have > current IPA master with Dogtag 10, or IPA with this patch with D9. > > It is not possible to create a replica from a machine with a single DS to an > older version without the patch -- the older version will try the wrong ports. In this case, I think we are covered - we do not support installation of a replica with a lower version than the master where the replica info file was created. Rob's patch 26dfbe61dd399e9c34f6f5bdeb25a197f1f461cb should ensure this for next version release. For 3.0 I think we will have to settle with a note in Documentation. We just need to make sure, that 3.0 replica made out of 2.x master will work. Martin From abokovoy at redhat.com Mon Oct 1 14:35:25 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 1 Oct 2012 17:35:25 +0300 Subject: [Freeipa-devel] [PATCH] 0081 Support both unified samba and samba/samba4-packages In-Reply-To: <50699FFE.8050105@redhat.com> References: <20121001092451.GU17454@redhat.com> <50699FFE.8050105@redhat.com> Message-ID: <20121001143525.GW17454@redhat.com> On Mon, 01 Oct 2012, Martin Kosek wrote: >On 10/01/2012 11:24 AM, Alexander Bokovoy wrote: >> Hi, >> >> The patch attached fixes Fedora build system issue with unified samba >> package (samba/samba4 packages got merged in Fedora 18 and Rawhide >> recently) since we depend on a wbclient.h header file path to which >> included versioned directory name previously (samba-4.0/ vs samba/). >> > >I am not convinced this is a correct approach, this was failing on my Fedora 18 >instance anyway: > ># make rpms >... >checking for NDR... yes >checking for SAMBAUTIL... yes >checking for samba-4.0/wbclient.h... no >checking for samba/wbclient.h... no >configure: error: samba/wbclient.h not found >make: *** [bootstrap-autogen] Error 1 > >The problem was that samba-devel package is no longer providing wbclient.h >header file: > ># rpm -qR samba-devel-4.0.0-150.fc18.rc1.x86_64 | grep wbclient.h ># > >I had a discussion with Andreas (CC-ed), the root cause was a missing >libwbclient-devel package which is the new provider of the samba-4.0/wbclient.h >file. He was also not aware of /usr/include/samba-4.0/ -> /usr/include/samba/ >change. > >I created a new patch with recommended approach (attached). Could you please >check if it is OK? It worked for me on both Fedora 17 and 18. ACK for your patch except one change: >@@ -214,10 +220,16 @@ Summary: Virtual package to install packages required for Active Directory trust > Group: System Environment/Base > Requires: %{name}-server = %version-%release > Requires: python-crypto >+%if 0%{?fedora} >= 18 >+Requires: samba-python >+Requires: samba >+Requires: samba-winbind >+%else > Requires: samba4-python > Requires: samba4 >-Requires: libsss_idmap Why libsss_idmap is removed? I'd assume this is a mistake. -- / Alexander Bokovoy From rcritten at redhat.com Mon Oct 1 14:41:13 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 01 Oct 2012 10:41:13 -0400 Subject: [Freeipa-devel] [PATCH] 1037 optimize restoring SELinux booleans Message-ID: <5069AB89.6000005@redhat.com> The web uninstall step can be very long because we restore two SELinux booleans individually. This patch combines them into a single step, and skips setting them if the values won't actually change. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1037-2-uninstall.patch Type: text/x-diff Size: 2264 bytes Desc: not available URL: From mkosek at redhat.com Mon Oct 1 14:45:51 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 01 Oct 2012 16:45:51 +0200 Subject: [Freeipa-devel] [PATCH] 0081 Support both unified samba and samba/samba4-packages In-Reply-To: <20121001143525.GW17454@redhat.com> References: <20121001092451.GU17454@redhat.com> <50699FFE.8050105@redhat.com> <20121001143525.GW17454@redhat.com> Message-ID: <5069AC9F.7020309@redhat.com> On 10/01/2012 04:35 PM, Alexander Bokovoy wrote: > On Mon, 01 Oct 2012, Martin Kosek wrote: >> On 10/01/2012 11:24 AM, Alexander Bokovoy wrote: >>> Hi, >>> >>> The patch attached fixes Fedora build system issue with unified samba >>> package (samba/samba4 packages got merged in Fedora 18 and Rawhide >>> recently) since we depend on a wbclient.h header file path to which >>> included versioned directory name previously (samba-4.0/ vs samba/). >>> >> >> I am not convinced this is a correct approach, this was failing on my Fedora 18 >> instance anyway: >> >> # make rpms >> ... >> checking for NDR... yes >> checking for SAMBAUTIL... yes >> checking for samba-4.0/wbclient.h... no >> checking for samba/wbclient.h... no >> configure: error: samba/wbclient.h not found >> make: *** [bootstrap-autogen] Error 1 >> >> The problem was that samba-devel package is no longer providing wbclient.h >> header file: >> >> # rpm -qR samba-devel-4.0.0-150.fc18.rc1.x86_64 | grep wbclient.h >> # >> >> I had a discussion with Andreas (CC-ed), the root cause was a missing >> libwbclient-devel package which is the new provider of the samba-4.0/wbclient.h >> file. He was also not aware of /usr/include/samba-4.0/ -> /usr/include/samba/ >> change. >> >> I created a new patch with recommended approach (attached). Could you please >> check if it is OK? It worked for me on both Fedora 17 and 18. > ACK for your patch except one change: > >> @@ -214,10 +220,16 @@ Summary: Virtual package to install packages required >> for Active Directory trust >> Group: System Environment/Base >> Requires: %{name}-server = %version-%release >> Requires: python-crypto >> +%if 0%{?fedora} >= 18 >> +Requires: samba-python >> +Requires: samba >> +Requires: samba-winbind >> +%else >> Requires: samba4-python >> Requires: samba4 >> -Requires: libsss_idmap > Why libsss_idmap is removed? I'd assume this is a mistake. > I just moved it to the end of the Requires list so that I can group samba Fedora-version-dependent Requires together: ... +%else Requires: samba4-python Requires: samba4 -Requires: libsss_idmap Requires: samba4-winbind +%endif +Requires: libsss_idmap <<<<< Martin From pviktori at redhat.com Mon Oct 1 14:53:26 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 01 Oct 2012 16:53:26 +0200 Subject: [Freeipa-devel] [PATCH] 1037 optimize restoring SELinux booleans In-Reply-To: <5069AB89.6000005@redhat.com> References: <5069AB89.6000005@redhat.com> Message-ID: <5069AE66.10603@redhat.com> On 10/01/2012 04:41 PM, Rob Crittenden wrote: > The web uninstall step can be very long because we restore two SELinux > booleans individually. This patch combines them into a single step, and > skips setting them if the values won't actually change. > > rob > > Is there a reason to not reuse the code that sets the values on install? As far as I can tell it does the same thing slightly differently. -- Petr? From abokovoy at redhat.com Mon Oct 1 14:54:10 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 1 Oct 2012 17:54:10 +0300 Subject: [Freeipa-devel] [PATCH] 0081 Support both unified samba and samba/samba4-packages In-Reply-To: <5069AC9F.7020309@redhat.com> References: <20121001092451.GU17454@redhat.com> <50699FFE.8050105@redhat.com> <20121001143525.GW17454@redhat.com> <5069AC9F.7020309@redhat.com> Message-ID: <20121001145410.GY17454@redhat.com> On Mon, 01 Oct 2012, Martin Kosek wrote: >On 10/01/2012 04:35 PM, Alexander Bokovoy wrote: >> On Mon, 01 Oct 2012, Martin Kosek wrote: >>> On 10/01/2012 11:24 AM, Alexander Bokovoy wrote: >>>> Hi, >>>> >>>> The patch attached fixes Fedora build system issue with unified samba >>>> package (samba/samba4 packages got merged in Fedora 18 and Rawhide >>>> recently) since we depend on a wbclient.h header file path to which >>>> included versioned directory name previously (samba-4.0/ vs samba/). >>>> >>> >>> I am not convinced this is a correct approach, this was failing on my Fedora 18 >>> instance anyway: >>> >>> # make rpms >>> ... >>> checking for NDR... yes >>> checking for SAMBAUTIL... yes >>> checking for samba-4.0/wbclient.h... no >>> checking for samba/wbclient.h... no >>> configure: error: samba/wbclient.h not found >>> make: *** [bootstrap-autogen] Error 1 >>> >>> The problem was that samba-devel package is no longer providing wbclient.h >>> header file: >>> >>> # rpm -qR samba-devel-4.0.0-150.fc18.rc1.x86_64 | grep wbclient.h >>> # >>> >>> I had a discussion with Andreas (CC-ed), the root cause was a missing >>> libwbclient-devel package which is the new provider of the samba-4.0/wbclient.h >>> file. He was also not aware of /usr/include/samba-4.0/ -> /usr/include/samba/ >>> change. >>> >>> I created a new patch with recommended approach (attached). Could you please >>> check if it is OK? It worked for me on both Fedora 17 and 18. >> ACK for your patch except one change: >> >>> @@ -214,10 +220,16 @@ Summary: Virtual package to install packages required >>> for Active Directory trust >>> Group: System Environment/Base >>> Requires: %{name}-server = %version-%release >>> Requires: python-crypto >>> +%if 0%{?fedora} >= 18 >>> +Requires: samba-python >>> +Requires: samba >>> +Requires: samba-winbind >>> +%else >>> Requires: samba4-python >>> Requires: samba4 >>> -Requires: libsss_idmap >> Why libsss_idmap is removed? I'd assume this is a mistake. >> > >I just moved it to the end of the Requires list so that I can group samba >Fedora-version-dependent Requires together: > >... >+%else > Requires: samba4-python > Requires: samba4 >-Requires: libsss_idmap > Requires: samba4-winbind >+%endif >+Requires: libsss_idmap <<<<< :) Thanks. I was not looking properly. ACK -- / Alexander Bokovoy From alee at redhat.com Mon Oct 1 15:02:08 2012 From: alee at redhat.com (Ade Lee) Date: Mon, 01 Oct 2012 11:02:08 -0400 Subject: [Freeipa-devel] [PATCH] Changes to use a single database for dogtag and IPA In-Reply-To: <5069A430.20207@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50640DCB.2060901@redhat.com> <50699C3B.4050200@redhat.com> <5069A430.20207@redhat.com> Message-ID: <1349103729.2575.109.camel@aleeredhat.laptop> On Mon, 2012-10-01 at 16:09 +0200, Martin Kosek wrote: > On 10/01/2012 03:35 PM, Petr Viktorin wrote: > > On 09/27/2012 10:26 AM, Petr Viktorin wrote: > >> On 09/20/2012 05:58 AM, Ade Lee wrote: > >>> Changes to use a single database for dogtag and IPA > >>> > >>> New servers that are installed with dogtag 10 instances will use > >>> a single database instance for dogtag and IPA, albeit with different > >>> suffixes. Dogtag will communicate with the instance through a > >>> database user with permissions to modify the dogtag suffix only. > >>> This user will authenticate using client auth using the subsystem > >>> cert > >>> for the instance. > >>> > >>> This patch includes changes to allow the creation of masters and > >>> clones > >>> with single ds instances. > >>> > >>> I have tested being able to create a master and a clone using f17 and > >>> dogtag 10. Note that you will need to use the latest builds on the > >>> dogtag repo to get some changes that were checked in today. We'll kick > >>> off another official f18 dogtag build in a day or so. > >>> > >>> This is a pretty big change - so I expect many issues to come up as > >>> things get tested. But as this will take awhile to get resolved, its > >>> better to get this out for review as fast as possible. > >>> > >>> Happy reviewing. > >>> > >>> Ade > >>> > >>> > >> > >> Attaching a rebased patch with a couple of style issues fixed. > >> - PEP8 compliance (remove trailing whitespace, use parentheses rather > >> than \ for line continuation, wrap touched lines at 80 characters) > >> - for files, use the with statement instead of the "open/close sandwich" > >> - don't mix tabs and spaces in install/share/certmap.conf.template > >> > >> I've also adjusted the spec file, as we need dogtag 10.0 and pki-server > >> now obsoletes pki-setup. > >> > >> > >> I still need selinux in permissive mode to install on f17, and I still > >> need to exclude *.i686 packages when updating. > >> > > > > Are the following limitations expected? > > > > IPA and Dogtag have to be updated simultaneously; it's not possible to have > > current IPA master with Dogtag 10, or IPA with this patch with D9. > > > > It is not possible to create a replica from a machine with a single DS to an > > older version without the patch -- the older version will try the wrong ports. > > In this case, I think we are covered - we do not support installation of a > replica with a lower version than the master where the replica info file was > created. Rob's patch 26dfbe61dd399e9c34f6f5bdeb25a197f1f461cb should ensure > this for next version release. For 3.0 I think we will have to settle with a > note in Documentation. > There is currently a dogtag bug where when the master is dogtag 9 (or dogtag 9 converted to 10), and the clone is dogtag 10, the clone will fail to get the installation token from the security domain. This is because the dogtag 10 code tries the new restful interface call -- which is not present on a dogtag 9 subsystem. https://fedorahosted.org/pki/ticket/334 This has been fixed in the latest dogtag 10 nightly builds. And will be in the next dogtag 10 official build, which we plan to create and release today. Incidentally, to see whats coming up in the new dogtag build, look for the 10.0.0-0.X.a2 milestone (plus some of what is closed in 9.0.24) > We just need to make sure, that 3.0 replica made out of 2.x master will work. > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From mkosek at redhat.com Mon Oct 1 15:28:39 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 01 Oct 2012 17:28:39 +0200 Subject: [Freeipa-devel] [PATCH] 319 Make ipakrbprincipal objectclass optional Message-ID: <5069B6A7.3020403@redhat.com> >From IPA 3.0, services have by default ipakrbprincipal objectclass which allows ipakrbprincipalalias attribute used for case-insensitive principal searches. However, as services created in previous version do not have this objectclass (and attribute), they are not listed in service list produced by service-find. Treat the ipakrbprincipal as optional to avoid missing services in service-find command. Add flag to service-mod command which can fill ipakrbprincipalalias attribute when case-insensitive principal searches for a 2.x service are required. https://fedorahosted.org/freeipa/ticket/3106 ----- I am still pondering about a right way to fill ipakrbprincipalalias used in for IPA 3.0 case-insensitive searches, so far I implemented this command: ipa service-mod PRINCIPAL --update-principal-alias But I am thinking it may be a better approach to generalize it and do something like that: ipa service-mod PRINCIPAL --upgrade/--update This command would do a general update of service entry to an up-to-date 3.0 style, in this case it could do 2 things: * fill ipakrbprincipalalias * fill ipakrbauthzdata (based on default value in IPA config). Suggestions or comments welcome. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-319-make-ipakrbprincipal-objectclass-optional.patch Type: text/x-patch Size: 5222 bytes Desc: not available URL: From mkosek at redhat.com Mon Oct 1 15:39:19 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 01 Oct 2012 17:39:19 +0200 Subject: [Freeipa-devel] [PATCH] 0081 Support both unified samba and samba/samba4-packages In-Reply-To: <20121001145410.GY17454@redhat.com> References: <20121001092451.GU17454@redhat.com> <50699FFE.8050105@redhat.com> <20121001143525.GW17454@redhat.com> <5069AC9F.7020309@redhat.com> <20121001145410.GY17454@redhat.com> Message-ID: <5069B927.2080806@redhat.com> On 10/01/2012 04:54 PM, Alexander Bokovoy wrote: > On Mon, 01 Oct 2012, Martin Kosek wrote: >> On 10/01/2012 04:35 PM, Alexander Bokovoy wrote: >>> On Mon, 01 Oct 2012, Martin Kosek wrote: >>>> On 10/01/2012 11:24 AM, Alexander Bokovoy wrote: >>>>> Hi, >>>>> >>>>> The patch attached fixes Fedora build system issue with unified samba >>>>> package (samba/samba4 packages got merged in Fedora 18 and Rawhide >>>>> recently) since we depend on a wbclient.h header file path to which >>>>> included versioned directory name previously (samba-4.0/ vs samba/). >>>>> >>>> >>>> I am not convinced this is a correct approach, this was failing on my >>>> Fedora 18 >>>> instance anyway: >>>> >>>> # make rpms >>>> ... >>>> checking for NDR... yes >>>> checking for SAMBAUTIL... yes >>>> checking for samba-4.0/wbclient.h... no >>>> checking for samba/wbclient.h... no >>>> configure: error: samba/wbclient.h not found >>>> make: *** [bootstrap-autogen] Error 1 >>>> >>>> The problem was that samba-devel package is no longer providing wbclient.h >>>> header file: >>>> >>>> # rpm -qR samba-devel-4.0.0-150.fc18.rc1.x86_64 | grep wbclient.h >>>> # >>>> >>>> I had a discussion with Andreas (CC-ed), the root cause was a missing >>>> libwbclient-devel package which is the new provider of the >>>> samba-4.0/wbclient.h >>>> file. He was also not aware of /usr/include/samba-4.0/ -> /usr/include/samba/ >>>> change. >>>> >>>> I created a new patch with recommended approach (attached). Could you please >>>> check if it is OK? It worked for me on both Fedora 17 and 18. >>> ACK for your patch except one change: >>> >>>> @@ -214,10 +220,16 @@ Summary: Virtual package to install packages required >>>> for Active Directory trust >>>> Group: System Environment/Base >>>> Requires: %{name}-server = %version-%release >>>> Requires: python-crypto >>>> +%if 0%{?fedora} >= 18 >>>> +Requires: samba-python >>>> +Requires: samba >>>> +Requires: samba-winbind >>>> +%else >>>> Requires: samba4-python >>>> Requires: samba4 >>>> -Requires: libsss_idmap >>> Why libsss_idmap is removed? I'd assume this is a mistake. >>> >> >> I just moved it to the end of the Requires list so that I can group samba >> Fedora-version-dependent Requires together: >> >> ... >> +%else >> Requires: samba4-python >> Requires: samba4 >> -Requires: libsss_idmap >> Requires: samba4-winbind >> +%endif >> +Requires: libsss_idmap <<<<< > :) Thanks. > I was not looking properly. > > ACK Pushed to master, ipa-3-0. I just added ticket #3118 to patch description (I discovered there is already a filed ticket for this change). I think we do not need to update our Fedora packages until RC2 release since dependencies are not broken - samba packages have samba4 provides... I verified by installing freeipa-server-3.0.0-0.6.fc18 on F18 box with new unified samba packages. Martin From abokovoy at redhat.com Mon Oct 1 16:08:06 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 1 Oct 2012 19:08:06 +0300 Subject: [Freeipa-devel] [PATCH] 0081 Support both unified samba and samba/samba4-packages In-Reply-To: <5069B927.2080806@redhat.com> References: <20121001092451.GU17454@redhat.com> <50699FFE.8050105@redhat.com> <20121001143525.GW17454@redhat.com> <5069AC9F.7020309@redhat.com> <20121001145410.GY17454@redhat.com> <5069B927.2080806@redhat.com> Message-ID: <20121001160806.GB17454@redhat.com> On Mon, 01 Oct 2012, Martin Kosek wrote: >>> +%else >>> Requires: samba4-python >>> Requires: samba4 >>> -Requires: libsss_idmap >>> Requires: samba4-winbind >>> +%endif >>> +Requires: libsss_idmap <<<<< >> :) Thanks. >> I was not looking properly. >> >> ACK > >Pushed to master, ipa-3-0. > >I just added ticket #3118 to patch description (I discovered there is already a >filed ticket for this change). > >I think we do not need to update our Fedora packages until RC2 release since >dependencies are not broken - samba packages have samba4 provides... I verified >by installing freeipa-server-3.0.0-0.6.fc18 on F18 box with new unified samba >packages. Aside from binary compatibility, there are regulard rebuilds of Rawhide and they failed for us on Friday, as Stephen has discovered. So, maybe we'd better update Rawhide with the patch? -- / Alexander Bokovoy From tbabej at redhat.com Mon Oct 1 16:27:55 2012 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 01 Oct 2012 18:27:55 +0200 Subject: [Freeipa-devel] [PATCH 0016] Adds port to connection error message in ipa-client-install In-Reply-To: <50635847.5070602@redhat.com> References: <5062FD9A.7060802@redhat.com> <50635847.5070602@redhat.com> Message-ID: <5069C48B.8050104@redhat.com> On 09/26/2012 09:32 PM, Rob Crittenden wrote: > Tomas Babej wrote: >> Hi, >> >> Connection error message in ipa-client-install now warns the user >> about the need of opening 389 port for directory server. >> >> https://fedorahosted.org/freeipa/ticket/2816 >> >> I think this can be pushed as a one-liner. > > I think we should list all ports that are required for client enrollment. > > From my calculations we need at a minimum tcp ports 80 and 389, either > or both udp/tcp for port 88 and if NTP is enabled 123 udp for > enrollment alone. The NTP failure won't cause enrollment to fail > though, so we may be able to skip that. > > Similarly 464 should be enabled but we don't use it during enrollment. > > rob I improved the error message. Please check if there are any issues. Thanks Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0016-2-Adds-port-to-connection-error-message-in-ipa-client-.patch Type: text/x-patch Size: 1805 bytes Desc: not available URL: From rcritten at redhat.com Mon Oct 1 19:29:49 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 01 Oct 2012 15:29:49 -0400 Subject: [Freeipa-devel] [PATCH] 1037 optimize restoring SELinux booleans In-Reply-To: <5069AE66.10603@redhat.com> References: <5069AB89.6000005@redhat.com> <5069AE66.10603@redhat.com> Message-ID: <5069EF2D.6060004@redhat.com> Petr Viktorin wrote: > On 10/01/2012 04:41 PM, Rob Crittenden wrote: >> The web uninstall step can be very long because we restore two SELinux >> booleans individually. This patch combines them into a single step, and >> skips setting them if the values won't actually change. >> >> rob >> >> > > Is there a reason to not reuse the code that sets the values on install? > As far as I can tell it does the same thing slightly differently. > The differences are enough that trying to consolidate them would likely end up taking considerable more time, require considerable more testing, etc. It would be worthwhile to revisit this at the beginning of a new version, but at the end it seems safer to take the simplest route. rob From mkosek at redhat.com Tue Oct 2 07:18:49 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 02 Oct 2012 09:18:49 +0200 Subject: [Freeipa-devel] [PATCH] 0081 Support both unified samba and samba/samba4-packages In-Reply-To: <20121001160806.GB17454@redhat.com> References: <20121001092451.GU17454@redhat.com> <50699FFE.8050105@redhat.com> <20121001143525.GW17454@redhat.com> <5069AC9F.7020309@redhat.com> <20121001145410.GY17454@redhat.com> <5069B927.2080806@redhat.com> <20121001160806.GB17454@redhat.com> Message-ID: <506A9559.1010509@redhat.com> On 10/01/2012 06:08 PM, Alexander Bokovoy wrote: > On Mon, 01 Oct 2012, Martin Kosek wrote: >>>> +%else >>>> Requires: samba4-python >>>> Requires: samba4 >>>> -Requires: libsss_idmap >>>> Requires: samba4-winbind >>>> +%endif >>>> +Requires: libsss_idmap <<<<< >>> :) Thanks. >>> I was not looking properly. >>> >>> ACK >> >> Pushed to master, ipa-3-0. >> >> I just added ticket #3118 to patch description (I discovered there is already a >> filed ticket for this change). >> >> I think we do not need to update our Fedora packages until RC2 release since >> dependencies are not broken - samba packages have samba4 provides... I verified >> by installing freeipa-server-3.0.0-0.6.fc18 on F18 box with new unified samba >> packages. > Aside from binary compatibility, there are regulard rebuilds of Rawhide > and they failed for us on Friday, as Stephen has discovered. So, maybe > we'd better update Rawhide with the patch? > Ok. I updated Fedora GIT and produced builds for both F18 and rawhide. Martin From sbose at redhat.com Tue Oct 2 07:54:21 2012 From: sbose at redhat.com (Sumit Bose) Date: Tue, 2 Oct 2012 09:54:21 +0200 Subject: [Freeipa-devel] [PATCHES] 3 enhancements for the ipa-adtrust-install page Message-ID: <20121002075421.GR6816@localhost.localdomain> Hi, the following three patches should fix https://fedorahosted.org/freeipa/ticket/2967 https://fedorahosted.org/freeipa/ticket/2972 https://fedorahosted.org/freeipa/ticket/3038 respectively. bye, Sumit -------------- next part -------------- From bab787a651773ec9bead34cfaaec05991ebc74c4 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Mon, 1 Oct 2012 13:36:00 +0200 Subject: [PATCH] Add man page paragraph about running ipa-adtrust-install multiple times Fixes https://fedorahosted.org/freeipa/ticket/2967 --- install/tools/man/ipa-adtrust-install.1 | 8 ++++++++ 1 Datei ge?ndert, 8 Zeilen hinzugef?gt(+) diff --git a/install/tools/man/ipa-adtrust-install.1 b/install/tools/man/ipa-adtrust-install.1 index 5303ec27be2af3d36c0e83d839625c3bdd6816a4..dc48ac8cdf5342ff3750b2bf1965ee25224e26fb 100644 --- a/install/tools/man/ipa-adtrust-install.1 +++ b/install/tools/man/ipa-adtrust-install.1 @@ -25,6 +25,14 @@ ipa\-adtrust\-install [\fIOPTION\fR]... Adds all necessary objects and configuration to allow an IPA server to create a trust to an Active Directory domain. This requires that the IPA server is already installed and configured. + +ipa\-adtrust\-install can be run multiple times to reinstall deleted objects or +broken configuration files. E.g. a fresh samba configuration (smb.conf file and +registry based configuration can be created. Other items like e.g. the +configuration of the local range cannot be changed by running +ipa\-adtrust\-install a second time because with changes here other objects +might be affected as well. + .SH "OPTIONS" .TP \fB\-d\fR, \fB\-\-debug\fR -- 1.7.11.4 -------------- next part -------------- From ff2700ab7b793ae167823dc3d93c131e0d8ea998 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Mon, 1 Oct 2012 21:43:45 +0200 Subject: [PATCH] Enhance description of --no-msdcs in man page Fixes https://fedorahosted.org/freeipa/ticket/2972 --- install/tools/man/ipa-adtrust-install.1 | 26 +++++++++++++++++++++++++- 1 Datei ge?ndert, 25 Zeilen hinzugef?gt(+), 1 Zeile entfernt(-) diff --git a/install/tools/man/ipa-adtrust-install.1 b/install/tools/man/ipa-adtrust-install.1 index dc48ac8cdf5342ff3750b2bf1965ee25224e26fb..13f111004eda4477db948355d26f524409805b7b 100644 --- a/install/tools/man/ipa-adtrust-install.1 +++ b/install/tools/man/ipa-adtrust-install.1 @@ -45,7 +45,31 @@ The IP address of the IPA server. If not provided then this is determined based The NetBIOS name for the IPA domain. If not provided then this is determined based on the leading component of the DNS domain name. .TP \fB\-\-no\-msdcs\fR -Do not create DNS service records for Windows in managed DNS server +Do not create DNS service records for Windows in managed DNS server. Since those +DNS service records are the only way to discover domain controllers of other +domains they must be added manually to a different DNS server to allow trust +realationships work properly. All needed service records are listed when +ipa\-adtrust\-install finishes and either \-\-no\-msdcs was given or no IPA DNS +service is configured. Typically service records for the following service names +are needed for the IPA domain which should point to all IPA servers: +.IP +\(bu _ldap._tcp +.IP +\(bu _kerberos._tcp +.IP +\(bu _kerberos._udp +.IP +\(bu _ldap._tcp.dc._msdcs +.IP +\(bu _kerberos._tcp.dc._msdcs +.IP +\(bu _kerberos._udp.dc._msdcs +.IP +\(bu _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs +.IP +\(bu _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs +.IP +\(bu _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs .TP \fB\-U\fR, \fB\-\-unattended\fR An unattended installation that will never prompt for user input -- 1.7.11.4 -------------- next part -------------- From 335ea2644ba8b171a288223dedbe6a237316e8f7 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Mon, 1 Oct 2012 21:54:00 +0200 Subject: [PATCH] Add --rid-base and --secondary-rid-base to ipa-adtrust-install man page Fixes https://fedorahosted.org/freeipa/ticket/3038 --- install/tools/man/ipa-adtrust-install.1 | 10 ++++++++++ 1 Datei ge?ndert, 10 Zeilen hinzugef?gt(+) diff --git a/install/tools/man/ipa-adtrust-install.1 b/install/tools/man/ipa-adtrust-install.1 index 13f111004eda4477db948355d26f524409805b7b..fa63bca3c4859325acb5891de6ad1e21b97dc754 100644 --- a/install/tools/man/ipa-adtrust-install.1 +++ b/install/tools/man/ipa-adtrust-install.1 @@ -74,6 +74,16 @@ are needed for the IPA domain which should point to all IPA servers: \fB\-U\fR, \fB\-\-unattended\fR An unattended installation that will never prompt for user input .TP +\fB\-U\fR, \fB\-\-rid-base\fR=\fIRID_BASE\fR +First RID value of the local domain. The first Posix ID of the local domain will +be assigned to this RID, the second to RID+1 etc. See the online help of the +idrange CLI for details. +.TP +\fB\-U\fR, \fB\-\-secondary-rid-base\fR=\fISECONDARY_RID_BASE\fR +Start value of the secondary RID range, which is only used in the case a user +and a group share numerically the same Posix ID. See the online help of the +idrange CLI for details. +.TP \fB\-A\fR, \fB\-\-admin\-name\fR=\fIADMIN_NAME\fR The name of the user with administrative privileges for this IPA server. Defaults to 'admin'. .TP -- 1.7.11.4 From pviktori at redhat.com Tue Oct 2 08:32:52 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 02 Oct 2012 10:32:52 +0200 Subject: [Freeipa-devel] [PATCH] 1037 optimize restoring SELinux booleans In-Reply-To: <5069EF2D.6060004@redhat.com> References: <5069AB89.6000005@redhat.com> <5069AE66.10603@redhat.com> <5069EF2D.6060004@redhat.com> Message-ID: <506AA6B4.60605@redhat.com> On 10/01/2012 09:29 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 10/01/2012 04:41 PM, Rob Crittenden wrote: >>> The web uninstall step can be very long because we restore two SELinux >>> booleans individually. This patch combines them into a single step, and >>> skips setting them if the values won't actually change. >>> >>> rob >>> >>> >> >> Is there a reason to not reuse the code that sets the values on install? >> As far as I can tell it does the same thing slightly differently. >> > > The differences are enough that trying to consolidate them would likely > end up taking considerable more time, require considerable more testing, > etc. It would be worthwhile to revisit this at the beginning of a new > version, but at the end it seems safer to take the simplest route. > > rob Well, okay then, ACK. But please keep the bug open. -- Petr? From pviktori at redhat.com Tue Oct 2 08:49:08 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 02 Oct 2012 10:49:08 +0200 Subject: [Freeipa-devel] [PATCH] 316 Improve DN usage in ipa-client-install In-Reply-To: <50643A0D.3020603@redhat.com> References: <50643A0D.3020603@redhat.com> Message-ID: <506AAA84.4040104@redhat.com> On 09/27/2012 01:35 PM, Martin Kosek wrote: > A hotfix pushed in a scope of ticket 3088 forced conversion of DN > object (baseDN) in IPA client discovery so that ipa-client-install > does not crash when creating an IPA default.conf. Since this is not > a preferred way to handle DN objects, improve its usage: > > - make sure, that baseDN retrieved by client discovery is always > a DN object > - update ipachangeconf.py code to handle strings better and instead > of concatenating objects, make sure they are converted to string > first > > As a side-effect of ipachangeconf changes, default.conf config file > generated by ipa-client-install has no longer empty new line at the > end of a file. > > https://fedorahosted.org/freeipa/ticket/3088 ACK, but since you're reformatting the code, here are some minor issues found by the PEP8 checker. > diff --git a/ipa-client/ipaclient/ipachangeconf.py b/ipa-client/ipaclient/ipachangeconf.py > index f6288062be5c5d1b29341ed90814e1fa1431019c..2bb0cc487670ce74833fc09b06449d0a176ffaf5 100644 > --- a/ipa-client/ipaclient/ipachangeconf.py > +++ b/ipa-client/ipaclient/ipachangeconf.py > @@ -68,7 +68,7 @@ class IPAChangeConf: > elif type(indent) is str: > self.indent = (indent, ) > else: > - raise ValueError, 'Indent must be a list of strings' > + raise ValueError('Indent must be a list of strings') Please re-indent to 4 spaces. > > @@ -143,35 +143,50 @@ class IPAChangeConf: > def getSectionLine(self, section): > if len(self.sectnamdel) != 2: > return section > - return self.sectnamdel[0]+section+self.sectnamdel[1]+self.deol > + return self._dump_line(self.sectnamdel[0], > + section, > + self.sectnamdel[1], > + self.deol) > + > + def _dump_line(self, *args): > + return u"".join(unicode(x) for x in args) > > def dump(self, options, level=0): > - output = "" > + output = [] > if level >= len(self.indent): > level = len(self.indent)-1 > > for o in options: > if o['type'] == "section": > - output += self.sectnamdel[0]+o['name']+self.sectnamdel[1]+self.deol > - output += self.dump(o['value'], level+1) > + output.append(self._dump_line(self.sectnamdel[0], > + o['name'], > + self.sectnamdel[1])) > + output.append(self.dump(o['value'], level+1)) Please surround the + operator by spaces (here & below). > @@ -274,15 +297,19 @@ class IPAChangeConf: > opts.append(o) > continue > if no['action'] == 'comment': > - opts.append({'name':'comment', 'type':'comment', > - 'value':self.dcomment+o['name']+self.dassign+o['value']}) > + value = self._dump_line(self.dcomment, > + o['name'], > + self.dassign, > + o['value']) > + opts.append({'name':'comment', 'type':'comment', > + 'value':value}) Please add a space after each colon. -- Petr? From sbose at redhat.com Tue Oct 2 09:28:46 2012 From: sbose at redhat.com (Sumit Bose) Date: Tue, 2 Oct 2012 11:28:46 +0200 Subject: [Freeipa-devel] [PATCH] Fix various issues found by Coverity Message-ID: <20121002092846.GS6816@localhost.localdomain> Hi, this patch fixes a couple of resource leaks and unchecked return and an uninitialised value found by Coverity. bye, Sumit -------------- next part -------------- From b39269b5adf5d2ae6076d5aa4394e68924027ce6 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 2 Oct 2012 11:25:04 +0200 Subject: [PATCH] Fix various issues found by Coverity --- daemons/ipa-sam/ipa_sam.c | 2 +- daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap.c | 6 ++++-- .../ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c | 12 +++++++----- .../ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c | 6 ++++-- daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c | 3 ++- daemons/ipa-slapi-plugins/ipa-sidgen/ipa_sidgen_task.c | 5 ++++- 6 Dateien ge?ndert, 22 Zeilen hinzugef?gt(+), 12 Zeilen entfernt(-) diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c index 3d4f741c157fb624e272d800bd9e0cdf9edb9444..db300022af0a29c32a2df5e5ef2bc12f39ed2886 100644 --- a/daemons/ipa-sam/ipa_sam.c +++ b/daemons/ipa-sam/ipa_sam.c @@ -1522,7 +1522,7 @@ static int set_cross_realm_pw(struct ldapsam_privates *ldap_state, krb5_error_code krberr; krb5_context krbctx; krb5_principal service_princ; - struct keys_container keys; + struct keys_container keys = {0, NULL}; char *err_msg; struct berval *reqdata = NULL; struct berval *retdata = NULL; diff --git a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap.c b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap.c index d7a59d51229ca9fbf754a2600e42339dcc235698..54d44ebf64b1efa0dda06773736d3413a6b70977 100644 --- a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap.c +++ b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap.c @@ -124,13 +124,15 @@ static int ipa_cldap_init_service(Slapi_PBlock *pb, slapi_pblock_get(pb, SLAPI_PLUGIN_CONFIG_ENTRY, &e); if (!e) { LOG_FATAL("Plugin configuration not found!\n"); - return -1; + ret = -1; + goto done; } ctx->base_dn = slapi_entry_attr_get_charptr(e, "nsslapd-basedn"); if (!ctx->base_dn) { LOG_FATAL("Plugin configuration not found!\n"); - return -1; + ret = -1; + goto done; } /* create a stop pipe so the main DS thread can interrupt the poll() diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c index f48bead04cbb18b040557b7b78a6cb27a3368422..47d4d68d1d7f5e4f02ad68849b840eaa63f7c33d 100644 --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c @@ -137,10 +137,12 @@ int parse_request_data(struct berval *req_val, struct extdom_req **_req) break; default: ber_free(ber, 1); + free(req); return LDAP_PROTOCOL_ERROR; } ber_free(ber, 1); if (tag == LBER_ERROR) { + free(req); return LDAP_PROTOCOL_ERROR; } @@ -284,11 +286,6 @@ static int get_domain_info(struct ipa_extdom_ctx *ctx, const char *domain_name, domain_info->flat_name = slapi_entry_attr_get_charptr(e[0], "ipaNTFlatName"); - /* TODO: read range from LDAP server */ -/* - range.min = 200000; - range.max = 400000; -*/ ret = set_domain_range(ctx, domain_info->sid, &range); if (ret != 0) { goto done; @@ -313,6 +310,11 @@ done: slapi_free_search_results_internal(pb); slapi_pblock_destroy(pb); free(filter); + + if (ret != 0) { + free_domain_info(domain_info); + } + return ret; } diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c index d5a2f604c4a61bda04dd026ace4b53ea5c2c3645..f36878c37a7fca2b06db70a4f7694ee53d7c9422 100644 --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c @@ -170,13 +170,15 @@ static int ipa_extdom_init_ctx(Slapi_PBlock *pb, struct ipa_extdom_ctx **_ctx) slapi_pblock_get(pb, SLAPI_PLUGIN_CONFIG_ENTRY, &e); if (!e) { LOG_FATAL("Plugin configuration not found!\n"); - return -1; + ret = -1; + goto done; } ctx->base_dn = slapi_entry_attr_get_charptr(e, "nsslapd-basedn"); if (!ctx->base_dn) { LOG_FATAL("Base DN not found in plugin configuration not found!\n"); - return -1; + ret = -1; + goto done; } diff --git a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c index 499e54a9c4a4c9134a231c0cd09e700390565a14..82479bec8184adb28cbf641d8ff019de64099818 100644 --- a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c +++ b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c @@ -90,7 +90,8 @@ static int slapi_entry_to_range_info(struct slapi_entry *entry, range->name = slapi_entry_attr_get_charptr(entry, IPA_CN); if (range->name == NULL) { - return EINVAL; + ret = EINVAL; + goto done; } ul_val = slapi_entry_attr_get_ulong(entry, IPA_BASE_ID); diff --git a/daemons/ipa-slapi-plugins/ipa-sidgen/ipa_sidgen_task.c b/daemons/ipa-slapi-plugins/ipa-sidgen/ipa_sidgen_task.c index ffbc9c636e32b0c0a3960ec76eda378a94c504fe..9e474e83dd0e1bfc52b2e2da3fda12420d2ea281 100644 --- a/daemons/ipa-slapi-plugins/ipa-sidgen/ipa_sidgen_task.c +++ b/daemons/ipa-slapi-plugins/ipa-sidgen/ipa_sidgen_task.c @@ -71,7 +71,10 @@ static const char *fetch_attr(Slapi_Entry *e, const char *attrname, if (slapi_entry_attr_find(e, attrname, &attr) != 0) return default_val; - slapi_attr_first_value(attr, &val); + + if (slapi_attr_first_value(attr, &val) == -1) + return default_val; + return slapi_value_get_string(val); } -- 1.7.11.4 From pviktori at redhat.com Tue Oct 2 10:19:03 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 02 Oct 2012 12:19:03 +0200 Subject: [Freeipa-devel] [PATCH] 319 Make ipakrbprincipal objectclass optional In-Reply-To: <5069B6A7.3020403@redhat.com> References: <5069B6A7.3020403@redhat.com> Message-ID: <506ABF97.2040903@redhat.com> On 10/01/2012 05:28 PM, Martin Kosek wrote: >>From IPA 3.0, services have by default ipakrbprincipal objectclass which > allows ipakrbprincipalalias attribute used for case-insensitive principal > searches. However, as services created in previous version do not have > this objectclass (and attribute), they are not listed in service list > produced by service-find. > > Treat the ipakrbprincipal as optional to avoid missing services in > service-find command. Add flag to service-mod command which can fill > ipakrbprincipalalias attribute when case-insensitive principal searches > for a 2.x service are required. > > https://fedorahosted.org/freeipa/ticket/3106 This works, I'm getting all services now & the tests pass. > > ----- > > I am still pondering about a right way to fill ipakrbprincipalalias used in for > IPA 3.0 case-insensitive searches, so far I implemented this command: > > ipa service-mod PRINCIPAL --update-principal-alias > > But I am thinking it may be a better approach to generalize it and do something > like that: > > ipa service-mod PRINCIPAL --upgrade/--update > > This command would do a general update of service entry to an up-to-date 3.0 > style, in this case it could do 2 things: > * fill ipakrbprincipalalias > * fill ipakrbauthzdata (based on default value in IPA config). I don't think you're generalizing enough; `service-mod --upgrade` isn't that different from `service-mod --update-principal-alias --update-authzdata`. Scripting this to happen for all services could be a nuisance, though. There should be a way to upgrade all services at once, and since we already have ipa-ldap-updater for it, it should run as part of that. I think we should keep ipakrbprincipal optional, in case the upgrade goes wrong. -- Petr? From mkosek at redhat.com Tue Oct 2 10:48:32 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 02 Oct 2012 12:48:32 +0200 Subject: [Freeipa-devel] [PATCH] 316 Improve DN usage in ipa-client-install In-Reply-To: <506AAA84.4040104@redhat.com> References: <50643A0D.3020603@redhat.com> <506AAA84.4040104@redhat.com> Message-ID: <506AC680.8090105@redhat.com> On 10/02/2012 10:49 AM, Petr Viktorin wrote: > On 09/27/2012 01:35 PM, Martin Kosek wrote: >> A hotfix pushed in a scope of ticket 3088 forced conversion of DN >> object (baseDN) in IPA client discovery so that ipa-client-install >> does not crash when creating an IPA default.conf. Since this is not >> a preferred way to handle DN objects, improve its usage: >> >> - make sure, that baseDN retrieved by client discovery is always >> a DN object >> - update ipachangeconf.py code to handle strings better and instead >> of concatenating objects, make sure they are converted to string >> first >> >> As a side-effect of ipachangeconf changes, default.conf config file >> generated by ipa-client-install has no longer empty new line at the >> end of a file. >> >> https://fedorahosted.org/freeipa/ticket/3088 > > ACK, but since you're reformatting the code, here are some minor issues found > by the PEP8 checker. > >> diff --git a/ipa-client/ipaclient/ipachangeconf.py >> b/ipa-client/ipaclient/ipachangeconf.py >> index >> f6288062be5c5d1b29341ed90814e1fa1431019c..2bb0cc487670ce74833fc09b06449d0a176ffaf5 >> 100644 >> --- a/ipa-client/ipaclient/ipachangeconf.py >> +++ b/ipa-client/ipaclient/ipachangeconf.py >> @@ -68,7 +68,7 @@ class IPAChangeConf: >> elif type(indent) is str: >> self.indent = (indent, ) >> else: >> - raise ValueError, 'Indent must be a list of strings' >> + raise ValueError('Indent must be a list of strings') > > Please re-indent to 4 spaces. > >> >> @@ -143,35 +143,50 @@ class IPAChangeConf: >> def getSectionLine(self, section): >> if len(self.sectnamdel) != 2: >> return section >> - return self.sectnamdel[0]+section+self.sectnamdel[1]+self.deol >> + return self._dump_line(self.sectnamdel[0], >> + section, >> + self.sectnamdel[1], >> + self.deol) >> + >> + def _dump_line(self, *args): >> + return u"".join(unicode(x) for x in args) >> >> def dump(self, options, level=0): >> - output = "" >> + output = [] >> if level >= len(self.indent): >> level = len(self.indent)-1 >> >> for o in options: >> if o['type'] == "section": >> - output += >> self.sectnamdel[0]+o['name']+self.sectnamdel[1]+self.deol >> - output += self.dump(o['value'], level+1) >> + output.append(self._dump_line(self.sectnamdel[0], >> + o['name'], >> + self.sectnamdel[1])) >> + output.append(self.dump(o['value'], level+1)) > > Please surround the + operator by spaces (here & below). > >> @@ -274,15 +297,19 @@ class IPAChangeConf: >> opts.append(o) >> continue >> if no['action'] == 'comment': >> - opts.append({'name':'comment', 'type':'comment', >> - >> 'value':self.dcomment+o['name']+self.dassign+o['value']}) >> + value = self._dump_line(self.dcomment, >> + o['name'], >> + self.dassign, >> + o['value']) >> + opts.append({'name':'comment', 'type':'comment', >> + 'value':value}) > > Please add a space after each colon. > Since the whole ipachangeconf.py is not much PEP8 compliant, I did not want to create just small "islands of compliance" with different coding style that the rest of the file. In attached patch I fixed the PEP8 warnings in the whole file. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-316-2-improve-dn-usage-in-ipa-client-install.patch Type: text/x-patch Size: 18327 bytes Desc: not available URL: From pviktori at redhat.com Tue Oct 2 11:33:51 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 02 Oct 2012 13:33:51 +0200 Subject: [Freeipa-devel] [PATCH] 316 Improve DN usage in ipa-client-install In-Reply-To: <506AC680.8090105@redhat.com> References: <50643A0D.3020603@redhat.com> <506AAA84.4040104@redhat.com> <506AC680.8090105@redhat.com> Message-ID: <506AD11F.1050808@redhat.com> On 10/02/2012 12:48 PM, Martin Kosek wrote: > On 10/02/2012 10:49 AM, Petr Viktorin wrote: >> On 09/27/2012 01:35 PM, Martin Kosek wrote: >>> A hotfix pushed in a scope of ticket 3088 forced conversion of DN >>> object (baseDN) in IPA client discovery so that ipa-client-install >>> does not crash when creating an IPA default.conf. Since this is not >>> a preferred way to handle DN objects, improve its usage: >>> >>> - make sure, that baseDN retrieved by client discovery is always >>> a DN object >>> - update ipachangeconf.py code to handle strings better and instead >>> of concatenating objects, make sure they are converted to string >>> first >>> >>> As a side-effect of ipachangeconf changes, default.conf config file >>> generated by ipa-client-install has no longer empty new line at the >>> end of a file. >>> >>> https://fedorahosted.org/freeipa/ticket/3088 >> >> ACK, but since you're reformatting the code, here are some minor issues found >> by the PEP8 checker. >> >>> diff --git a/ipa-client/ipaclient/ipachangeconf.py >>> b/ipa-client/ipaclient/ipachangeconf.py >>> index >>> f6288062be5c5d1b29341ed90814e1fa1431019c..2bb0cc487670ce74833fc09b06449d0a176ffaf5 >>> 100644 >>> --- a/ipa-client/ipaclient/ipachangeconf.py >>> +++ b/ipa-client/ipaclient/ipachangeconf.py >>> @@ -68,7 +68,7 @@ class IPAChangeConf: >>> elif type(indent) is str: >>> self.indent = (indent, ) >>> else: >>> - raise ValueError, 'Indent must be a list of strings' >>> + raise ValueError('Indent must be a list of strings') >> >> Please re-indent to 4 spaces. >> >>> >>> @@ -143,35 +143,50 @@ class IPAChangeConf: >>> def getSectionLine(self, section): >>> if len(self.sectnamdel) != 2: >>> return section >>> - return self.sectnamdel[0]+section+self.sectnamdel[1]+self.deol >>> + return self._dump_line(self.sectnamdel[0], >>> + section, >>> + self.sectnamdel[1], >>> + self.deol) >>> + >>> + def _dump_line(self, *args): >>> + return u"".join(unicode(x) for x in args) >>> >>> def dump(self, options, level=0): >>> - output = "" >>> + output = [] >>> if level >= len(self.indent): >>> level = len(self.indent)-1 >>> >>> for o in options: >>> if o['type'] == "section": >>> - output += >>> self.sectnamdel[0]+o['name']+self.sectnamdel[1]+self.deol >>> - output += self.dump(o['value'], level+1) >>> + output.append(self._dump_line(self.sectnamdel[0], >>> + o['name'], >>> + self.sectnamdel[1])) >>> + output.append(self.dump(o['value'], level+1)) >> >> Please surround the + operator by spaces (here & below). >> >>> @@ -274,15 +297,19 @@ class IPAChangeConf: >>> opts.append(o) >>> continue >>> if no['action'] == 'comment': >>> - opts.append({'name':'comment', 'type':'comment', >>> - >>> 'value':self.dcomment+o['name']+self.dassign+o['value']}) >>> + value = self._dump_line(self.dcomment, >>> + o['name'], >>> + self.dassign, >>> + o['value']) >>> + opts.append({'name':'comment', 'type':'comment', >>> + 'value':value}) >> >> Please add a space after each colon. >> > > Since the whole ipachangeconf.py is not much PEP8 compliant, I did not want to > create just small "islands of compliance" with different coding style that the > rest of the file. > > In attached patch I fixed the PEP8 warnings in the whole file. > > Martin > Looking better. ACK -- Petr? From mkosek at redhat.com Tue Oct 2 11:42:58 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 02 Oct 2012 13:42:58 +0200 Subject: [Freeipa-devel] [PATCH] 316 Improve DN usage in ipa-client-install In-Reply-To: <506AD11F.1050808@redhat.com> References: <50643A0D.3020603@redhat.com> <506AAA84.4040104@redhat.com> <506AC680.8090105@redhat.com> <506AD11F.1050808@redhat.com> Message-ID: <506AD342.7080202@redhat.com> On 10/02/2012 01:33 PM, Petr Viktorin wrote: > On 10/02/2012 12:48 PM, Martin Kosek wrote: >> On 10/02/2012 10:49 AM, Petr Viktorin wrote: >>> On 09/27/2012 01:35 PM, Martin Kosek wrote: >>>> A hotfix pushed in a scope of ticket 3088 forced conversion of DN >>>> object (baseDN) in IPA client discovery so that ipa-client-install >>>> does not crash when creating an IPA default.conf. Since this is not >>>> a preferred way to handle DN objects, improve its usage: >>>> >>>> - make sure, that baseDN retrieved by client discovery is always >>>> a DN object >>>> - update ipachangeconf.py code to handle strings better and instead >>>> of concatenating objects, make sure they are converted to string >>>> first >>>> >>>> As a side-effect of ipachangeconf changes, default.conf config file >>>> generated by ipa-client-install has no longer empty new line at the >>>> end of a file. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3088 >>> >>> ACK, but since you're reformatting the code, here are some minor issues found >>> by the PEP8 checker. >>> >>>> diff --git a/ipa-client/ipaclient/ipachangeconf.py >>>> b/ipa-client/ipaclient/ipachangeconf.py >>>> index >>>> f6288062be5c5d1b29341ed90814e1fa1431019c..2bb0cc487670ce74833fc09b06449d0a176ffaf5 >>>> >>>> 100644 >>>> --- a/ipa-client/ipaclient/ipachangeconf.py >>>> +++ b/ipa-client/ipaclient/ipachangeconf.py >>>> @@ -68,7 +68,7 @@ class IPAChangeConf: >>>> elif type(indent) is str: >>>> self.indent = (indent, ) >>>> else: >>>> - raise ValueError, 'Indent must be a list of strings' >>>> + raise ValueError('Indent must be a list of strings') >>> >>> Please re-indent to 4 spaces. >>> >>>> >>>> @@ -143,35 +143,50 @@ class IPAChangeConf: >>>> def getSectionLine(self, section): >>>> if len(self.sectnamdel) != 2: >>>> return section >>>> - return self.sectnamdel[0]+section+self.sectnamdel[1]+self.deol >>>> + return self._dump_line(self.sectnamdel[0], >>>> + section, >>>> + self.sectnamdel[1], >>>> + self.deol) >>>> + >>>> + def _dump_line(self, *args): >>>> + return u"".join(unicode(x) for x in args) >>>> >>>> def dump(self, options, level=0): >>>> - output = "" >>>> + output = [] >>>> if level >= len(self.indent): >>>> level = len(self.indent)-1 >>>> >>>> for o in options: >>>> if o['type'] == "section": >>>> - output += >>>> self.sectnamdel[0]+o['name']+self.sectnamdel[1]+self.deol >>>> - output += self.dump(o['value'], level+1) >>>> + output.append(self._dump_line(self.sectnamdel[0], >>>> + o['name'], >>>> + self.sectnamdel[1])) >>>> + output.append(self.dump(o['value'], level+1)) >>> >>> Please surround the + operator by spaces (here & below). >>> >>>> @@ -274,15 +297,19 @@ class IPAChangeConf: >>>> opts.append(o) >>>> continue >>>> if no['action'] == 'comment': >>>> - opts.append({'name':'comment', 'type':'comment', >>>> - >>>> 'value':self.dcomment+o['name']+self.dassign+o['value']}) >>>> + value = self._dump_line(self.dcomment, >>>> + o['name'], >>>> + self.dassign, >>>> + o['value']) >>>> + opts.append({'name':'comment', 'type':'comment', >>>> + 'value':value}) >>> >>> Please add a space after each colon. >>> >> >> Since the whole ipachangeconf.py is not much PEP8 compliant, I did not want to >> create just small "islands of compliance" with different coding style that the >> rest of the file. >> >> In attached patch I fixed the PEP8 warnings in the whole file. >> >> Martin >> > > Looking better. ACK > Pushed to master, ipa-3-0. Martin From tbabej at redhat.com Tue Oct 2 12:33:50 2012 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 02 Oct 2012 14:33:50 +0200 Subject: [Freeipa-devel] [PATCH 0015] Restrict admins group modifications In-Reply-To: <506322F5.4000901@redhat.com> References: <5061A202.2090203@redhat.com> <5061A432.3090709@redhat.com> <5061AAAB.7020801@redhat.com> <506322F5.4000901@redhat.com> Message-ID: <506ADF2E.9050502@redhat.com> On 09/26/2012 05:44 PM, Martin Kosek wrote: > On 09/25/2012 02:59 PM, Tomas Babej wrote: >> On 09/25/2012 02:31 PM, Martin Kosek wrote: >>> On 09/25/2012 02:22 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> Group-mod command no longer allows --rename and/or --external >>>> changes made to the admins group. In such cases, ProtectedEntryError >>>> is being raised. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3098 >>>> >>>> Tomas >>>> >>> Just based on a quick glance, I see few issues: 1) I would like to >>> see unit tests for this scenario 2) Some overlooked debug output: + >>> self.log.info(str(keys)) Martin >> I removed the unfortunate debug output and added two unit tests to test the >> scenarios. >> >> Tomas > I finally got to a proper review and here it is: > > 1) I think we should use some common global variable containing protected > groups and not define it in every command separately (duplication -> errors). > One is already used: > > ... > protected_group_name = u'admins' > ... > > I would like to see that to be used in both group-del and group-mod. I also > think we should protect "trust admins" too as this group is also encoded in > trust ACI, i.e. using a global variable like this one: > > PROTECTED_GROUPS = (u'admins', u'trust admins') > > > 2) Minor issue, I think instead of: > > + is_admins_group = u'admins' in keys > > a more common pattern in IPA is the following: > > + is_admins_group = keys[-1] == u'admins' > > > 3) We usually do not end our error messages in exceptions with ".": > > ... > + raise errors.ProtectedEntryError(label=u'group', > key=u'admins', reason=u'Cannot be renamed.') > ... > + raise errors.ProtectedEntryError(label=u'group', > key=u'admins', reason=u'Cannot support external non-IPA members.') > ... > > Otherwise the patch looks OK. > > Martin I fixed the relevant issues and added few more test cases as well. Please check the new patch version. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0015-3-Restrict-admins-group-modifications.patch Type: text/x-patch Size: 6832 bytes Desc: not available URL: From pviktori at redhat.com Tue Oct 2 13:02:19 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 02 Oct 2012 15:02:19 +0200 Subject: [Freeipa-devel] [PATCH] Changes to use a single database for dogtag and IPA In-Reply-To: <1349103729.2575.109.camel@aleeredhat.laptop> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50640DCB.2060901@redhat.com> <50699C3B.4050200@redhat.com> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> Message-ID: <506AE5DB.9020605@redhat.com> On 10/01/2012 05:02 PM, Ade Lee wrote: > On Mon, 2012-10-01 at 16:09 +0200, Martin Kosek wrote: >> On 10/01/2012 03:35 PM, Petr Viktorin wrote: >>> On 09/27/2012 10:26 AM, Petr Viktorin wrote: >>>> On 09/20/2012 05:58 AM, Ade Lee wrote: >>>>> Changes to use a single database for dogtag and IPA >>>>> >>>>> New servers that are installed with dogtag 10 instances will use >>>>> a single database instance for dogtag and IPA, albeit with different >>>>> suffixes. Dogtag will communicate with the instance through a >>>>> database user with permissions to modify the dogtag suffix only. >>>>> This user will authenticate using client auth using the subsystem >>>>> cert >>>>> for the instance. >>>>> >>>>> This patch includes changes to allow the creation of masters and >>>>> clones >>>>> with single ds instances. >>>>> >>>>> I have tested being able to create a master and a clone using f17 and >>>>> dogtag 10. Note that you will need to use the latest builds on the >>>>> dogtag repo to get some changes that were checked in today. We'll kick >>>>> off another official f18 dogtag build in a day or so. >>>>> >>>>> This is a pretty big change - so I expect many issues to come up as >>>>> things get tested. But as this will take awhile to get resolved, its >>>>> better to get this out for review as fast as possible. >>>>> >>>>> Happy reviewing. >>>>> >>>>> Ade >>>>> >>>>> >>>> >>>> Attaching a rebased patch with a couple of style issues fixed. >>>> - PEP8 compliance (remove trailing whitespace, use parentheses rather >>>> than \ for line continuation, wrap touched lines at 80 characters) >>>> - for files, use the with statement instead of the "open/close sandwich" >>>> - don't mix tabs and spaces in install/share/certmap.conf.template >>>> >>>> I've also adjusted the spec file, as we need dogtag 10.0 and pki-server >>>> now obsoletes pki-setup. >>>> >>>> >>>> I still need selinux in permissive mode to install on f17, and I still >>>> need to exclude *.i686 packages when updating. >>>> >>> >>> Are the following limitations expected? >>> >>> IPA and Dogtag have to be updated simultaneously; it's not possible to have >>> current IPA master with Dogtag 10, or IPA with this patch with D9. >>> >>> It is not possible to create a replica from a machine with a single DS to an >>> older version without the patch -- the older version will try the wrong ports. >> >> In this case, I think we are covered - we do not support installation of a >> replica with a lower version than the master where the replica info file was >> created. Rob's patch 26dfbe61dd399e9c34f6f5bdeb25a197f1f461cb should ensure >> this for next version release. For 3.0 I think we will have to settle with a >> note in Documentation. >> > > There is currently a dogtag bug where when the master is dogtag 9 (or > dogtag 9 converted to 10), and the clone is dogtag 10, the clone will > fail to get the installation token from the security domain. This is > because the dogtag 10 code tries the new restful interface call -- which > is not present on a dogtag 9 subsystem. > https://fedorahosted.org/pki/ticket/334 > > > This has been fixed in the latest dogtag 10 nightly builds. And will be > in the next dogtag 10 official build, which we plan to create and > release today. > > Incidentally, to see whats coming up in the new dogtag build, look for > the 10.0.0-0.X.a2 milestone (plus some of what is closed in 9.0.24) > Okay, testing with the dogtag-devel repo, on f17. The following scenarios don't work: - Start with a master on D9 - install a replica on D10, without a CA - run ipa-ca-install on the replica ipa-replica-conncheck: error: no such option: --dogtag-master-ds-port - Start with a master on D9 - install a replica without a CA (either Dogtag version) - Update all machines - run ipa-ca-install on the replica com.netscape.certsrv.base.PKIException: com.netscape.certsrv.base.PKIException: Failed to obtain installation token from security domain I get the following errors in catalina.out on the replica: 08:40:11,149 DEBUG (org.jboss.resteasy.plugins.providers.DocumentProvider:60) - Unable to retrieve ServletContext: expandEntityReferences defaults to true 08:40:11,158 DEBUG (org.jboss.resteasy.plugins.providers.DocumentProvider:60) - Unable to retrieve ServletContext: expandEntityReferences defaults to true CMS Warning: FAILURE: Cannot build CA chain. Error java.security.cert.CertificateException: Certificate is not a PKCS #11 certificate|FAILURE: authz instance DirAclAuthz initialization failed and skipped, error=Property internaldb.ldapconn.port missing value| -- Petr? From mkosek at redhat.com Tue Oct 2 13:04:14 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 02 Oct 2012 15:04:14 +0200 Subject: [Freeipa-devel] [PATCH] 319 Make ipakrbprincipal objectclass optional In-Reply-To: <506ABF97.2040903@redhat.com> References: <5069B6A7.3020403@redhat.com> <506ABF97.2040903@redhat.com> Message-ID: <506AE64E.9010200@redhat.com> On 10/02/2012 12:19 PM, Petr Viktorin wrote: > On 10/01/2012 05:28 PM, Martin Kosek wrote: >>> From IPA 3.0, services have by default ipakrbprincipal objectclass which >> allows ipakrbprincipalalias attribute used for case-insensitive principal >> searches. However, as services created in previous version do not have >> this objectclass (and attribute), they are not listed in service list >> produced by service-find. >> >> Treat the ipakrbprincipal as optional to avoid missing services in >> service-find command. Add flag to service-mod command which can fill >> ipakrbprincipalalias attribute when case-insensitive principal searches >> for a 2.x service are required. >> >> https://fedorahosted.org/freeipa/ticket/3106 > > This works, I'm getting all services now & the tests pass. > >> >> ----- >> >> I am still pondering about a right way to fill ipakrbprincipalalias used in for >> IPA 3.0 case-insensitive searches, so far I implemented this command: >> >> ipa service-mod PRINCIPAL --update-principal-alias >> >> But I am thinking it may be a better approach to generalize it and do something >> like that: >> >> ipa service-mod PRINCIPAL --upgrade/--update >> >> This command would do a general update of service entry to an up-to-date 3.0 >> style, in this case it could do 2 things: >> * fill ipakrbprincipalalias >> * fill ipakrbauthzdata (based on default value in IPA config). > > I don't think you're generalizing enough; `service-mod --upgrade` isn't that > different from `service-mod --update-principal-alias --update-authzdata`. > Scripting this to happen for all services could be a nuisance, though. There > should be a way to upgrade all services at once, and since we already have > ipa-ldap-updater for it, it should run as part of that. > > I think we should keep ipakrbprincipal optional, in case the upgrade goes wrong. > I agree. I created an upgrade plugin which should update all services and fill ipakrbprincipalalias during upgrade (attached). I tested 2.2 -> 3.0 upgrade and it worked fine. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-319-2-fill-ipakrbprincipalalias-on-upgrades.patch Type: text/x-patch Size: 7143 bytes Desc: not available URL: From pspacek at redhat.com Tue Oct 2 13:21:08 2012 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 02 Oct 2012 15:21:08 +0200 Subject: [Freeipa-devel] [PATCH 0071] Fix potential crash caused by failing zone_register allocation. Message-ID: <506AEA44.20307@redhat.com> Hello, Fix potential crash caused by failing zone_register allocation. Problematic call flow: new_ldap_instance -> zr_create (returns failure) -> destroy_ldap_instance -> zr_get_rbt (*crash*) -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0071-Fix-potential-crash-caused-by-failing-zone_register-.patch Type: text/x-patch Size: 1244 bytes Desc: not available URL: From tbabej at redhat.com Tue Oct 2 13:33:15 2012 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 02 Oct 2012 15:33:15 +0200 Subject: [Freeipa-devel] [PATCH 0017] Improve error message in ipa-replica-manage Message-ID: <506AED1B.8010205@redhat.com> Hi, When executing ipa-replica-manage connect to an unknown or irrelevant master, we now print a sensible error message informing the user about this possiblity as well. https://fedorahosted.org/freeipa/ticket/3105 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0017-Improve-error-message-in-ipa-replica-manage.patch Type: text/x-patch Size: 1330 bytes Desc: not available URL: From rcritten at redhat.com Tue Oct 2 13:55:28 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 02 Oct 2012 09:55:28 -0400 Subject: [Freeipa-devel] [PATCH 0017] Improve error message in ipa-replica-manage In-Reply-To: <506AED1B.8010205@redhat.com> References: <506AED1B.8010205@redhat.com> Message-ID: <506AF250.2010404@redhat.com> Tomas Babej wrote: > Hi, > > When executing ipa-replica-manage connect to an unknown or irrelevant > master, we now print a sensible error message informing the user > about this possiblity as well. > > https://fedorahosted.org/freeipa/ticket/3105 > > Tomas I put a whole bunch of code into a try/except and this may be catching errors in unexpected ways. I'm not entirely sure right now what we should do, but looking at the code in the try: repl1.conn.getEntry(master1_dn, ldap.SCOPE_BASE) repl1.conn.getEntry(master2_dn, ldap.SCOPE_BASE) We take in replica1 and replica1 as arguments (the default for replica1 is the current host). If either of these raise a NotFound it means there there is no master of that name. Does that mean that the master was deleted? Well, clearly not. A lot has changed since I did this, I may have been relying on a side-effect, or just hadn't tested well-enough. I wonder if we need that message at all. Is "foo" is not an IPA server good enough? It still might be confusing if someone didn't know that "foo" was deleted and it was still running. We could probably verify that it is at least an IPA server by doing similar checking in the client, it all depends on how far we want to take it. rob From mkosek at redhat.com Tue Oct 2 15:16:43 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 02 Oct 2012 17:16:43 +0200 Subject: [Freeipa-devel] [PATCH] 320 Only use service PAC type as an override Message-ID: <506B055B.4060605@redhat.com> PAC type (ipakrbauthzdata attribute) was being filled for all new service automatically. However, the PAC type attribute was designed to serve only as an override to default PAC type configured in IPA config. With PAC type set in all services, users would have to update all services to get new PAC types configured in IPA config. Do not set PAC type for new services. Add new NONE value meaning that we do not want any PAC for the service (empty/missing attribute means that the default PAC type list from IPA config is read). https://fedorahosted.org/freeipa/ticket/2184 --- Note: the new NONE value of service PAC type was planned in a scope of ticket #2960. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-320-only-use-service-pac-type-as-an-override.patch Type: text/x-patch Size: 12852 bytes Desc: not available URL: From pviktori at redhat.com Tue Oct 2 15:34:02 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 02 Oct 2012 17:34:02 +0200 Subject: [Freeipa-devel] [PATCH] Changes to use a single database for dogtag and IPA In-Reply-To: <506AE5DB.9020605@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50640DCB.2060901@redhat.com> <50699C3B.4050200@redhat.com> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> Message-ID: <506B096A.1070406@redhat.com> On 10/02/2012 03:02 PM, Petr Viktorin wrote: > On 10/01/2012 05:02 PM, Ade Lee wrote: >> On Mon, 2012-10-01 at 16:09 +0200, Martin Kosek wrote: >>> On 10/01/2012 03:35 PM, Petr Viktorin wrote: >>>> On 09/27/2012 10:26 AM, Petr Viktorin wrote: >>>>> On 09/20/2012 05:58 AM, Ade Lee wrote: >>>>>> Changes to use a single database for dogtag and IPA >>>>>> >>>>>> New servers that are installed with dogtag 10 instances will >>>>>> use >>>>>> a single database instance for dogtag and IPA, albeit with >>>>>> different >>>>>> suffixes. Dogtag will communicate with the instance through a >>>>>> database user with permissions to modify the dogtag suffix >>>>>> only. >>>>>> This user will authenticate using client auth using the >>>>>> subsystem >>>>>> cert >>>>>> for the instance. >>>>>> >>>>>> This patch includes changes to allow the creation of masters >>>>>> and >>>>>> clones >>>>>> with single ds instances. >>>>>> >>>>>> I have tested being able to create a master and a clone using f17 and >>>>>> dogtag 10. Note that you will need to use the latest builds on the >>>>>> dogtag repo to get some changes that were checked in today. We'll >>>>>> kick >>>>>> off another official f18 dogtag build in a day or so. >>>>>> >>>>>> This is a pretty big change - so I expect many issues to come up as >>>>>> things get tested. But as this will take awhile to get resolved, its >>>>>> better to get this out for review as fast as possible. >>>>>> >>>>>> Happy reviewing. >>>>>> >>>>>> Ade >>>>>> >>>>>> >>>>> >>>>> Attaching a rebased patch with a couple of style issues fixed. >>>>> - PEP8 compliance (remove trailing whitespace, use parentheses rather >>>>> than \ for line continuation, wrap touched lines at 80 characters) >>>>> - for files, use the with statement instead of the "open/close >>>>> sandwich" >>>>> - don't mix tabs and spaces in install/share/certmap.conf.template >>>>> >>>>> I've also adjusted the spec file, as we need dogtag 10.0 and >>>>> pki-server >>>>> now obsoletes pki-setup. >>>>> >>>>> >>>>> I still need selinux in permissive mode to install on f17, and I still >>>>> need to exclude *.i686 packages when updating. >>>>> >>>> >>>> Are the following limitations expected? >>>> >>>> IPA and Dogtag have to be updated simultaneously; it's not possible >>>> to have >>>> current IPA master with Dogtag 10, or IPA with this patch with D9. >>>> >>>> It is not possible to create a replica from a machine with a single >>>> DS to an >>>> older version without the patch -- the older version will try the >>>> wrong ports. >>> >>> In this case, I think we are covered - we do not support installation >>> of a >>> replica with a lower version than the master where the replica info >>> file was >>> created. Rob's patch 26dfbe61dd399e9c34f6f5bdeb25a197f1f461cb should >>> ensure >>> this for next version release. For 3.0 I think we will have to settle >>> with a >>> note in Documentation. >>> >> >> There is currently a dogtag bug where when the master is dogtag 9 (or >> dogtag 9 converted to 10), and the clone is dogtag 10, the clone will >> fail to get the installation token from the security domain. This is >> because the dogtag 10 code tries the new restful interface call -- which >> is not present on a dogtag 9 subsystem. >> https://fedorahosted.org/pki/ticket/334 >> >> >> This has been fixed in the latest dogtag 10 nightly builds. And will be >> in the next dogtag 10 official build, which we plan to create and >> release today. >> >> Incidentally, to see whats coming up in the new dogtag build, look for >> the 10.0.0-0.X.a2 milestone (plus some of what is closed in 9.0.24) >> > > Okay, testing with the dogtag-devel repo, on f17. > > The following scenarios don't work: > > - Start with a master on D9 > - install a replica on D10, without a CA > - run ipa-ca-install on the replica > ipa-replica-conncheck: error: no such option: --dogtag-master-ds-port > > > - Start with a master on D9 > - install a replica without a CA (either Dogtag version) > - Update all machines > - run ipa-ca-install on the replica > com.netscape.certsrv.base.PKIException: > com.netscape.certsrv.base.PKIException: Failed to obtain installation > token from security domain > > I get the following errors in catalina.out on the replica: > 08:40:11,149 DEBUG > (org.jboss.resteasy.plugins.providers.DocumentProvider:60) - Unable to > retrieve ServletContext: expandEntityReferences defaults to true > 08:40:11,158 DEBUG > (org.jboss.resteasy.plugins.providers.DocumentProvider:60) - Unable to > retrieve ServletContext: expandEntityReferences defaults to true > CMS Warning: FAILURE: Cannot build CA chain. Error > java.security.cert.CertificateException: Certificate is not a PKCS #11 > certificate|FAILURE: authz instance DirAclAuthz initialization failed > and skipped, error=Property internaldb.ldapconn.port missing value| > > I did the second scenario again and got a slightly different error message: "White spaces are required between publicId and systemId." See attached logs. I started with IPA 2.2 (from f17 repos) on both machines, then updated to patched IPA w/ D10, then ran ipa-ca-install. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: replica-logs.tar.gz Type: application/x-gzip Size: 6669 bytes Desc: not available URL: From mkosek at redhat.com Tue Oct 2 15:46:11 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 02 Oct 2012 17:46:11 +0200 Subject: [Freeipa-devel] [PATCH] 319 Make ipakrbprincipal objectclass optional In-Reply-To: <506AE64E.9010200@redhat.com> References: <5069B6A7.3020403@redhat.com> <506ABF97.2040903@redhat.com> <506AE64E.9010200@redhat.com> Message-ID: <506B0C43.70206@redhat.com> On 10/02/2012 03:04 PM, Martin Kosek wrote: > On 10/02/2012 12:19 PM, Petr Viktorin wrote: >> On 10/01/2012 05:28 PM, Martin Kosek wrote: >>>> From IPA 3.0, services have by default ipakrbprincipal objectclass which >>> allows ipakrbprincipalalias attribute used for case-insensitive principal >>> searches. However, as services created in previous version do not have >>> this objectclass (and attribute), they are not listed in service list >>> produced by service-find. >>> >>> Treat the ipakrbprincipal as optional to avoid missing services in >>> service-find command. Add flag to service-mod command which can fill >>> ipakrbprincipalalias attribute when case-insensitive principal searches >>> for a 2.x service are required. >>> >>> https://fedorahosted.org/freeipa/ticket/3106 >> >> This works, I'm getting all services now & the tests pass. >> >>> >>> ----- >>> >>> I am still pondering about a right way to fill ipakrbprincipalalias used in for >>> IPA 3.0 case-insensitive searches, so far I implemented this command: >>> >>> ipa service-mod PRINCIPAL --update-principal-alias >>> >>> But I am thinking it may be a better approach to generalize it and do something >>> like that: >>> >>> ipa service-mod PRINCIPAL --upgrade/--update >>> >>> This command would do a general update of service entry to an up-to-date 3.0 >>> style, in this case it could do 2 things: >>> * fill ipakrbprincipalalias >>> * fill ipakrbauthzdata (based on default value in IPA config). >> >> I don't think you're generalizing enough; `service-mod --upgrade` isn't that >> different from `service-mod --update-principal-alias --update-authzdata`. >> Scripting this to happen for all services could be a nuisance, though. There >> should be a way to upgrade all services at once, and since we already have >> ipa-ldap-updater for it, it should run as part of that. >> >> I think we should keep ipakrbprincipal optional, in case the upgrade goes wrong. >> > > I agree. I created an upgrade plugin which should update all services and fill > ipakrbprincipalalias during upgrade (attached). I tested 2.2 -> 3.0 upgrade and > it worked fine. > > Martin > There was a glitch in the loop repeating the update when LDAP limits are hit - thanks Petr Viktorin for noticing the issue. It is working now, I tried with 10 affected services and search limit set to 1 entry - and the loop executed 10 times as it was supposed to. I also disabled size/time limits for the search in the upgrade plugin. But it would also work if default IPA search limits (100 entries) are used, it should just make things faster. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-319-3-fill-ipakrbprincipalalias-on-upgrades.patch Type: text/x-patch Size: 7200 bytes Desc: not available URL: From pvoborni at redhat.com Tue Oct 2 16:38:17 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 02 Oct 2012 18:38:17 +0200 Subject: [Freeipa-devel] [PATCH] [WIP] Firefox extension Message-ID: <506B1879.1090501@redhat.com> This effort is still a WIP but I wanted to sent it to allow comments on chosen approaches. You can visually check config pages on: http://pvoborni.fedorapeople.org/config/unauthorized.html resp. http://pvoborni.fedorapeople.org/config/browserconfig.html Note that installation of ca.crt and extentsion won't work because fedorapeople server doesn't send proper headers. If you wanto to build it and test it, to not mess up your FF profile, make a new one: firefox -ProfileManager firefox -P myprofilename --no-remote So far I tested it only on FF15. It should be functional on FF4 and later but it most likely won't work on FF3.6 (doesn't support bootstrapping ext and xul overlay not tested). I will work on FF3.6 support ASAP. I didn't test installations of replicas. Patch descriptions: Kerberos authentication extension --------------------------------- The extension should replace signed code (configure.jar) used for Firefox configuration. Using privileged code is not possible since Firefox 15 [1] [2]. Extension is bootstrapped which means it can be used without browser restart on Firefox 4 and later. How it works: Extension listens on each page's document element for event 'kerberos-auth-config' which should be raised on custom data element. Communication data is transferred through data element's attributes [3]. The only required attribute is 'method'. Currently there are two possible values: 'configure' and 'can_configure'. 'can_configure' method serves for detecting if the extension is installed. 'configure' method does the actual configuration. Possible optional options for 'configure' can be found in kerberosauth.js:kerberosauth.config_options. Currently they are: 'referer', 'native_gss_lib', 'trusted_uris', 'allow_proxies'. Result of a method is stored in data element's 'answer' attribute. When 'configure' method is used, the extension asks the user if he wants to configure the browser, it should prevent silent configuration by malicious pages. Possible enhancement: * add UI for manual edit * more configurations ie. for gss_lib, sspi (good with UI or with enhanced config page) * introspection of client (read ipa client install config and such) Ticket: https://fedorahosted.org/freeipa/ticket/3094 [1] https://bugzilla.mozilla.org/show_bug.cgi?id=546848 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=757046 [3] https://developer.mozilla.org/en-US/docs/Code_snippets/Interaction_between_privileged_and_non-privileged_pages Build and installation of Kerberos authentication extension ----------------------------------------------------------- This patch is removing files associated with configure.jar and a build of configure.jar with a build of kerberosauth.xpi (FF Kerberos authentication extension). Currently the build is done in install phase of FreeIPA server. It is to allow signing of the extension by singing certificate. The signing might not be necessary because the only outcome is that in extension installation FF doesn't show that the maker is not verified. It shows text: 'Object signing cert'. This might be a bug in httpinstance.py:262(db.create_signing_cert("Signing-Cert", "Object Signing Cert", ca_db)) The value is in place of hostname parameter. If the extension is not signed, it can be created in rpm build phase, which should make upgrades easier. Current implementation doesn't handle upgrades yet. In order to keep extension and config pages not dependent on a realm, a krb.js.teplate file was created. This template is used for creating a /usr/share/ipa/html/krb.js file in install phase which holds FreeIPA's realm and domain information. This information can be then used by config pages by importing this file. Ticket: https://fedorahosted.org/freeipa/ticket/3094 Configuration pages changed to use new FF extension --------------------------------------------------- browserconfig.html was changed to use new FF extension. The page is completely Firefox specific therefore the title was changed from 'Configure browser' to 'Firefox configuration'. Instruction to import CA cert in unauthorized.html are FF specific too, so they were moved to browserconfig.html. Unauthorized.html text was changed to distinguish FF config and other browsers. Now the page shows link for FF (browserconfig.html) and other browsers (ssbrowser.html). Ssbrowser.html should be enhanced by more configurations and browsers later [1]. Unauthorized dialog in Web UI now links to http://../unauthorized.html instead of https. This change is done because of FF strange handling of extension installations from https sites [2]. Firefox allows ext. installation from https sites only when the certificate is signed by some build-in CA. To allow custom CAs an option in about:config has to be changed which don't help us at all because we wants to avoid manual changes in about:config. The design of browserconfig is inspired by Kyle Baker's design (2.1 Enhancements_v2.odt). It is not exactly the same. Highlighting of the steps wasn't used because in some cases we can switch some steps. Ticket: https://fedorahosted.org/freeipa/ticket/3094 [1] https://fedorahosted.org/freeipa/ticket/823 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=688383 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0216-Kerberos-authentication-extension.patch Type: text/x-patch Size: 16183 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0217-Kerberos-authentication-extension-makefiles.patch Type: text/x-patch Size: 6404 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0218-Build-and-installation-of-Kerberos-authentication-ex.patch Type: text/x-patch Size: 12521 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0219-Configuration-pages-changed-to-use-new-FF-extension.patch Type: text/x-patch Size: 30228 bytes Desc: not available URL: From rcritten at redhat.com Tue Oct 2 18:23:02 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 02 Oct 2012 14:23:02 -0400 Subject: [Freeipa-devel] [PATCH] 1058 clear session key Message-ID: <506B3106.8070602@redhat.com> Clear the host session key when enrolling a client. Make sure dbdir is preserved when a new connection is created. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1058-client.patch Type: text/x-diff Size: 4645 bytes Desc: not available URL: From rcritten at redhat.com Tue Oct 2 18:24:56 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 02 Oct 2012 14:24:56 -0400 Subject: [Freeipa-devel] [PATCH] 1037 optimize restoring SELinux booleans In-Reply-To: <506AA6B4.60605@redhat.com> References: <5069AB89.6000005@redhat.com> <5069AE66.10603@redhat.com> <5069EF2D.6060004@redhat.com> <506AA6B4.60605@redhat.com> Message-ID: <506B3178.3050507@redhat.com> Petr Viktorin wrote: > On 10/01/2012 09:29 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 10/01/2012 04:41 PM, Rob Crittenden wrote: >>>> The web uninstall step can be very long because we restore two SELinux >>>> booleans individually. This patch combines them into a single step, and >>>> skips setting them if the values won't actually change. >>>> >>>> rob >>>> >>>> >>> >>> Is there a reason to not reuse the code that sets the values on install? >>> As far as I can tell it does the same thing slightly differently. >>> >> >> The differences are enough that trying to consolidate them would likely >> end up taking considerable more time, require considerable more testing, >> etc. It would be worthwhile to revisit this at the beginning of a new >> version, but at the end it seems safer to take the simplest route. >> >> rob > > Well, okay then, ACK. But please keep the bug open. > I'm going to withdraw this patch for now. I think it can wait for a more complete fix in a future release. rob From rcritten at redhat.com Tue Oct 2 18:48:31 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 02 Oct 2012 14:48:31 -0400 Subject: [Freeipa-devel] [PATCH 0016] Adds port to connection error message in ipa-client-install In-Reply-To: <5069C48B.8050104@redhat.com> References: <5062FD9A.7060802@redhat.com> <50635847.5070602@redhat.com> <5069C48B.8050104@redhat.com> Message-ID: <506B36FF.5050303@redhat.com> Tomas Babej wrote: > On 09/26/2012 09:32 PM, Rob Crittenden wrote: >> Tomas Babej wrote: >>> Hi, >>> >>> Connection error message in ipa-client-install now warns the user >>> about the need of opening 389 port for directory server. >>> >>> https://fedorahosted.org/freeipa/ticket/2816 >>> >>> I think this can be pushed as a one-liner. >> >> I think we should list all ports that are required for client enrollment. >> >> From my calculations we need at a minimum tcp ports 80 and 389, either >> or both udp/tcp for port 88 and if NTP is enabled 123 udp for >> enrollment alone. The NTP failure won't cause enrollment to fail >> though, so we may be able to skip that. >> >> Similarly 464 should be enabled but we don't use it during enrollment. >> >> rob > I improved the error message. Please check if there are any issues. > > Thanks > > Tomas This only works if port 389 is blocked, not 88 or 80. rob From sbose at redhat.com Tue Oct 2 19:29:01 2012 From: sbose at redhat.com (Sumit Bose) Date: Tue, 2 Oct 2012 21:29:01 +0200 Subject: [Freeipa-devel] [PATCH] 75-78 Add fallback group Message-ID: <20121002192901.GV6816@localhost.localdomain> Hi, this patch should fix https://fedorahosted.org/freeipa/ticket/2955 by adding a fallback group as described in comment 2 of the ticket in ipa-adtrust-install. If you prefer to use a different kind of group I can change the patch accordingly. bye, Sumit -------------- next part -------------- From 9cb3514cd7c73810ce4b5dceb82d36b739124854 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 18 Sep 2012 11:32:10 +0200 Subject: [PATCH 75/78] ipa-adtrust-install: Add fallback group --- ipaserver/install/adtrustinstance.py | 79 ++++++++++++++++++++++++++++++------ 1 Datei ge?ndert, 67 Zeilen hinzugef?gt(+), 12 Zeilen entfernt(-) diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py index c44037754dfd74cf6a9ceda4c9f4d2a6a224b1ea..1aebdad3ce8169952489d2ddce8f19917635b5e8 100644 --- a/ipaserver/install/adtrustinstance.py +++ b/ipaserver/install/adtrustinstance.py @@ -96,9 +96,11 @@ class ADTRUSTInstance(service.Service): ATTR_SID = "ipaNTSecurityIdentifier" ATTR_FLAT_NAME = "ipaNTFlatName" ATTR_GUID = "ipaNTDomainGUID" + ATTR_FALLBACK_GROUP = "ipaNTFallbackPrimaryGroup" OBJC_USER = "ipaNTUserAttrs" OBJC_GROUP = "ipaNTGroupAttrs" OBJC_DOMAIN = "ipaNTDomainAttrs" + FALLBACK_GROUP_NAME = u'fallback_primary_group' def __init__(self, fstore=None): self.fqdn = None @@ -134,6 +136,18 @@ class ADTRUSTInstance(service.Service): return "S-1-5-21-%d-%d-%d" % (sub_ids[0], sub_ids[1], sub_ids[2]) def __add_admin_sids(self): + """ + The IPA admin and the IPA admins group with get the well knows SIDs + used by AD for the administrator and the administrator group. + Additonally the well know domain users SID will be assinged to a + special fallback group. + + By default new users belong only to a user private group (UPG) and no + other Posix group since ipausers is not a Posix group anymore. To be + able to add a RID to the primary RID attribute in a PAC a fallback + group is added. + """ + admin_dn = DN(('uid', 'admin'), api.env.container_user, self.suffix) admin_group_dn = DN(('cn', 'admins'), api.env.container_group, @@ -163,24 +177,65 @@ class ADTRUSTInstance(service.Service): print "IPA admin group object not found" return - if admin_entry.getValue(self.ATTR_SID) or \ - admin_group_entry.getValue(self.ATTR_SID): - print "Admin SID already set, nothing to do" + if admin_entry.getValue(self.ATTR_SID): + self.print_msg("Admin SID already set, nothing to do") + else: + try: + self.admin_conn.modify_s(admin_dn, \ + [(ldap.MOD_ADD, "objectclass", self.OBJC_USER), \ + (ldap.MOD_ADD, self.ATTR_SID, dom_sid + "-500")]) + except: + self.print_msg("Failed to modify IPA admin object") + + if admin_group_entry.getValue(self.ATTR_SID): + self.print_msg("Admin group SID already set, nothing to do") + else: + try: + self.admin_conn.modify_s(admin_group_dn, \ + [(ldap.MOD_ADD, "objectclass", self.OBJC_GROUP), \ + (ldap.MOD_ADD, self.ATTR_SID, dom_sid + "-512")]) + except: + self.print_msg("Failed to modify IPA admin group object") + + if dom_entry.getValue(self.ATTR_FALLBACK_GROUP): + self.print_msg("Fallback group already set, nothing to do") return + fb_group_dn = DN(('cn', self.FALLBACK_GROUP_NAME), + api.env.container_group, self.suffix) + has_sid = False try: - self.admin_conn.modify_s(admin_dn, \ - [(ldap.MOD_ADD, "objectclass", self.OBJC_USER), \ - (ldap.MOD_ADD, self.ATTR_SID, dom_sid + "-500")]) - except: - print "Failed to modify IPA admin object" + fb_group = self.admin_conn.getEntry(fb_group_dn, ldap.SCOPE_BASE) + + if fb_group.getValue(self.ATTR_SID): + has_sid = True + except errors.NotFound: + try: + fallback = api.Command['group_add'](self.FALLBACK_GROUP_NAME, + description= u'Fallback group for ' \ + 'primary group RID, ' \ + 'do not add user to ' \ + 'this group', + nonposix=True) + fb_group_dn = fallback['result']['dn'] + except Exception, e: + self.print_msg("Failed to add fallback group.") + raise e + + if not has_sid: + try: + mod = [(ldap.MOD_ADD, "objectclass", self.OBJC_GROUP), \ + (ldap.MOD_ADD, self.ATTR_SID, dom_sid + "-513")] + self.admin_conn.modify_s(DN(fallback['result']['dn']), mod) + except: + self.print_msg("Failed to modify fallback group object") try: - self.admin_conn.modify_s(admin_group_dn, \ - [(ldap.MOD_ADD, "objectclass", self.OBJC_GROUP), \ - (ldap.MOD_ADD, self.ATTR_SID, dom_sid + "-512")]) + mod = [(ldap.MOD_ADD, self.ATTR_FALLBACK_GROUP, + fallback['result']['dn'])] + self.admin_conn.modify_s(self.smb_dom_dn, mod) except: - print "Failed to modify IPA admin group object" + self.print_msg("Failed to add fallback group to domain object") def __add_rid_bases(self): """ -- 1.7.11.4 -------------- next part -------------- From 40ff99524544730d1106c6e8cfe268dcc7ec2cbf Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 18 Sep 2012 11:35:57 +0200 Subject: [PATCH 76/78] ipa-adtrust-install: replace print with self.print_msg --- ipaserver/install/adtrustinstance.py | 28 ++++++++++++++-------------- 1 Datei ge?ndert, 14 Zeilen hinzugef?gt(+), 14 Zeilen entfernt(-) diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py index 1aebdad3ce8169952489d2ddce8f19917635b5e8..8b8364929a9f063ad66fac0d7bca4d13977f9543 100644 --- a/ipaserver/install/adtrustinstance.py +++ b/ipaserver/install/adtrustinstance.py @@ -156,25 +156,25 @@ class ADTRUSTInstance(service.Service): dom_entry = self.admin_conn.getEntry(self.smb_dom_dn, \ ldap.SCOPE_BASE) except errors.NotFound: - print "Samba domain object not found" + self.print_msg("Samba domain object not found") return dom_sid = dom_entry.getValue(self.ATTR_SID) if not dom_sid: - print "Samba domain object does not have a SID" + self.print_msg("Samba domain object does not have a SID") return try: admin_entry = self.admin_conn.getEntry(admin_dn, ldap.SCOPE_BASE) except: - print "IPA admin object not found" + self.print_msg("IPA admin object not found") return try: admin_group_entry = self.admin_conn.getEntry(admin_group_dn, \ ldap.SCOPE_BASE) except: - print "IPA admin group object not found" + self.print_msg("IPA admin group object not found") return if admin_entry.getValue(self.ATTR_SID): @@ -255,13 +255,13 @@ class ADTRUSTInstance(service.Service): if res[0].getValue('ipaBaseRID') or \ res[0].getValue('ipaSecondaryBaseRID'): - print "RID bases already set, nothing to do" + self.print_msg("RID bases already set, nothing to do") return size = res[0].getValue('ipaIDRangeSize') if abs(self.rid_base - self.secondary_rid_base) > size: - print "Primary and secondary RID base are too close. " \ - "They have to differ at least by %d." % size + self.print_msg("Primary and secondary RID base are too close. " \ + "They have to differ at least by %d." % size) raise RuntimeError("RID bases too close.\n") try: @@ -271,7 +271,7 @@ class ADTRUSTInstance(service.Service): (ldap.MOD_ADD, "ipaSecondaryBaseRID", \ str(self.secondary_rid_base))]) except: - print "Failed to add RID bases to the local range object" + self.print_msg("Failed to add RID bases to the local range object") except errors.NotFound as e: root_logger.critical("ID range of the local domain not found, " \ @@ -298,8 +298,8 @@ class ADTRUSTInstance(service.Service): try: name = new_dn[1].attr except Exception, e: - print 'Cannot extract RDN attribute value from "%s": %s' % \ - (new_dn, e) + self.print_msg('Cannot extract RDN attribute value from "%s": %s' % \ + (new_dn, e)) return entry.setValues("cn", name) self.admin_conn.addEntry(entry) @@ -416,12 +416,12 @@ class ADTRUSTInstance(service.Service): "as it is not defined in IPA" % zone if err_msg: - print err_msg - print "Add the following service records to your DNS server " \ - "for DNS zone %s: " % zone + self.print_msg(err_msg) + self.print_msg("Add the following service records to your DNS " \ + "server for DNS zone %s: " % zone) for (srv, rdata) in ipa_srv_rec: for suff in win_srv_suffix: - print " - %s%s" % (srv, suff) + self.print_msg(" - %s%s" % (srv, suff)) return for (srv, rdata) in ipa_srv_rec: -- 1.7.11.4 -------------- next part -------------- From afb7f3aadf8d56a7b82ca357f9a97c5aeec05742 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Mon, 24 Sep 2012 17:25:07 +0200 Subject: [PATCH 77/78] ipasam: add fallback primary group --- daemons/ipa-sam/ipa_sam.c | 148 +++++++++++++++++++++++++++++++++++++++++++++- 1 Datei ge?ndert, 147 Zeilen hinzugef?gt(+), 1 Zeile entfernt(-) diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c index db300022af0a29c32a2df5e5ef2bc12f39ed2886..7dc4549cb8f6390827642f14c4cff29539916261 100644 --- a/daemons/ipa-sam/ipa_sam.c +++ b/daemons/ipa-sam/ipa_sam.c @@ -121,6 +121,8 @@ bool secrets_store(const char *key, const void *data, size_t size); /* available #define LDAP_ATTRIBUTE_LOGON_SCRIPT "ipaNTLogonScript" #define LDAP_ATTRIBUTE_PROFILE_PATH "ipaNTProfilePath" #define LDAP_ATTRIBUTE_NTHASH "ipaNTHash" +#define LDAP_ATTRIBUTE_UIDNUMBER "uidnumber" +#define LDAP_ATTRIBUTE_GIDNUMBER "gidnumber" #define LDAP_OBJ_KRB_PRINCIPAL "krbPrincipal" #define LDAP_OBJ_KRB_PRINCIPAL_AUX "krbPrincipalAux" @@ -155,7 +157,7 @@ struct ipasam_privates { char *base_dn; char *trust_dn; char *flat_name; - char *fallback_primary_group; + struct dom_sid fallback_primary_group; char *server_princ; char *client_princ; struct sss_idmap_ctx *idmap_ctx; @@ -2677,6 +2679,141 @@ static bool ipasam_nthash_regen(struct ldapsam_privates *ldap_state, return (ret == LDAP_SUCCESS); } +static int ipasam_get_sid_by_gid(struct ldapsam_privates *ldap_state, + uint32_t gid, + struct dom_sid *_sid) +{ + int ret; + char *filter; + TALLOC_CTX *tmp_ctx; + LDAPMessage *entry = NULL; + LDAPMessage *result = NULL; + char *sid_str = NULL; + struct dom_sid *sid = NULL; + int count; + enum idmap_error_code err; + + tmp_ctx = talloc_new("ipasam_get_sid_by_gid"); + if (tmp_ctx == NULL) { + return ENOMEM; + } + + filter = talloc_asprintf(tmp_ctx, "(&(%s=%s)(%s=%lu))", + LDAP_ATTRIBUTE_OBJECTCLASS, + LDAP_OBJ_POSIXGROUP, + LDAP_ATTRIBUTE_GIDNUMBER, + (unsigned long) gid); + if (filter == NULL) { + ret = ENOMEM; + goto done; + } + + ret = smbldap_search(ldap_state->smbldap_state, + ldap_state->ipasam_privates->base_dn, + LDAP_SCOPE_SUBTREE,filter, NULL, 0, + &result); + if (ret != LDAP_SUCCESS) { + ret = ENOENT; + goto done; + } + + count = ldap_count_entries(ldap_state->smbldap_state->ldap_struct, + result); + if (count != 1) { + ret = ENOENT; + goto done; + } + + entry = ldap_first_entry(ldap_state->smbldap_state->ldap_struct, result); + if (entry == NULL) { + ret = ENOENT; + goto done; + } + + sid_str = get_single_attribute(tmp_ctx, + ldap_state->smbldap_state->ldap_struct, + entry, LDAP_ATTRIBUTE_SID); + if (sid_str == NULL) { + ret = ENOENT; + goto done; + } + + err = sss_idmap_sid_to_smb_sid(ldap_state->ipasam_privates->idmap_ctx, + sid_str, &sid); + if (err != IDMAP_SUCCESS) { + ret = EFAULT; + goto done; + } + sid_copy(_sid, sid); + + ret = 0; + +done: + talloc_free(sid); + ldap_msgfree(result); + talloc_free(tmp_ctx); + + return ret; +} + +static int ipasam_get_primary_group_sid(TALLOC_CTX *mem_ctx, + struct ldapsam_privates *ldap_state, + LDAPMessage *entry, + struct dom_sid **_group_sid) +{ + int ret; + uint32_t uid; + uint32_t gid; + struct dom_sid *group_sid; + + TALLOC_CTX *tmp_ctx = talloc_init("ipasam_get_primary_group_sid"); + if (tmp_ctx == NULL) { + return ENOMEM; + } + + if (!get_uint32_t_from_ldap_msg(ldap_state, entry, + LDAP_ATTRIBUTE_UIDNUMBER, &uid)) { + ret = ENOENT; + DEBUG(1, ("No uidnumber attribute found for this user!\n")); + goto done; + } + + if (!get_uint32_t_from_ldap_msg(ldap_state, entry, + LDAP_ATTRIBUTE_GIDNUMBER, &gid)) { + ret = ENOENT; + DEBUG(1, ("No gidnumber attribute found for this user!\n")); + goto done; + } + + group_sid = talloc(tmp_ctx, struct dom_sid); + if (group_sid == NULL) { + ret = ENOMEM; + goto done; + } + + if (uid == gid) { /* User private group, use default fallback group */ + sid_copy(group_sid, + &ldap_state->ipasam_privates->fallback_primary_group); + ret = 0; + goto done; + } else { + ret = ipasam_get_sid_by_gid(ldap_state, gid, group_sid); + if (ret != 0) { + goto done; + } + } + + ret = 0; +done: + if (ret == 0) { + *_group_sid = talloc_steal(mem_ctx, group_sid); + } + + talloc_free(tmp_ctx); + + return ret; +} + static bool init_sam_from_ldap(struct ldapsam_privates *ldap_state, struct samu * sampass, LDAPMessage * entry) @@ -2692,7 +2829,9 @@ static bool init_sam_from_ldap(struct ldapsam_privates *ldap_state, char *temp = NULL; bool ret = false; bool retval = false; + int status; DATA_BLOB nthash; + struct dom_sid *group_sid; TALLOC_CTX *tmp_ctx = talloc_init("init_sam_from_ldap"); if (!tmp_ctx) { @@ -2738,6 +2877,12 @@ static bool init_sam_from_ldap(struct ldapsam_privates *ldap_state, entry, LDAP_ATTRIBUTE_SECURITY_IDENTIFIER, tmp_ctx)) != NULL) { pdb_set_user_sid_from_string(sampass, temp, PDB_SET); + + status = ipasam_get_primary_group_sid(tmp_ctx, ldap_state, + entry, &group_sid); + if (status != 0) { + goto fn_exit; + } } else { goto fn_exit; } @@ -2872,6 +3017,7 @@ done: talloc_free(tmp_ctx); return status; } + static NTSTATUS ldapsam_getsampwnam(struct pdb_methods *methods, struct samu *user, const char *sname) -- 1.7.11.4 -------------- next part -------------- From 67ff93ca4f8ace991079662bf44144d7dc1587b0 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 25 Sep 2012 11:11:40 +0200 Subject: [PATCH 78/78] ipadb: use ipaNTGroupAttrs to search for the fallback group Since we are primarily interested in the SID of the fallback group we should use the objectclass containing it in the search filter. --- daemons/ipa-kdb/ipa_kdb_mspac.c | 2 +- 1 Datei ge?ndert, 1 Zeile hinzugef?gt(+), 1 Zeile entfernt(-) diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index b3cef97db1bfe120d00b3bbfd30ed392dbb7b385..1a03323d137a2b89a08f5b12ca00752e4e190de7 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -1590,7 +1590,7 @@ krb5_error_code ipadb_reinit_mspac(struct ipadb_context *ipactx) if (ret != ENOENT) { kerr = ipadb_simple_search(ipactx, ipactx->mspac->fallback_group, LDAP_SCOPE_BASE, - "(objectclass=posixGroup)", + "(objectclass=ipaNTGroupAttrs)", grp_attrs, &result); if (kerr && kerr != KRB5_KDB_NOENTRY) { kerr = ret; -- 1.7.11.4 From rcritten at redhat.com Tue Oct 2 19:54:53 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 02 Oct 2012 15:54:53 -0400 Subject: [Freeipa-devel] [PATCH] 314-315 Limit unindexed searches In-Reply-To: <506405E4.3060400@redhat.com> References: <5061D833.10204@redhat.com> <50635051.3060809@redhat.com> <506405E4.3060400@redhat.com> Message-ID: <506B468D.7030701@redhat.com> Martin Kosek wrote: > On 09/26/2012 08:58 PM, Rob Crittenden wrote: >> Martin Kosek wrote: >>> These 2 patches significantly limit the number of unindexed LDAP searches we do >>> in IPA. I used our unit test suite as a good source of different LDAP searches >>> run by our command suite. >>> >>> Most of the remaining unindexed searches are produced either by our general >>> term search ("ipa service-find TERM") which hit every object parameter and DNS >>> commands (idnsname is not indexed yet). I am thinking about indexing about >>> idnsName as well... >>> >> >> Patch 314 looks ok. It addresses ticket 3025 as well (ipakrbprincipalalias). >> > > I added this ticket number to the patch too. Btw. managedBy attribute mentioned > in the ticket was already added to indexed in ticket #2866. > >> For 315 I'd prefer we add a new exception type to mirror >> ldap.NOT_ALLOWED_ON_NONLEAF and catch that in delete instead of DatabaseError. > > > This is a very good catch, it will make this procedure safer when there is an > actual DatabaseError raised. > > Updated patches attached. > > Martin > ACK, pushed to master and ipa-3-0 rob From simo at redhat.com Tue Oct 2 19:56:32 2012 From: simo at redhat.com (Simo Sorce) Date: Tue, 02 Oct 2012 15:56:32 -0400 Subject: [Freeipa-devel] [PATCH] 75-78 Add fallback group In-Reply-To: <20121002192901.GV6816@localhost.localdomain> References: <20121002192901.GV6816@localhost.localdomain> Message-ID: <1349207792.22373.64.camel@willson.li.ssimo.org> On Tue, 2012-10-02 at 21:29 +0200, Sumit Bose wrote: > Hi, > > this patch should fix https://fedorahosted.org/freeipa/ticket/2955 by > adding a fallback group as described in comment 2 of the ticket in > ipa-adtrust-install. > > If you prefer to use a different kind of group I can change the patch > accordingly. Yes I think we should use a more natural group name. In my recent testing I have been using the name 'Trust Users' that pairs well with another group we create called 'Trust Admins'. But I am open to suggestions on a better name, 'Domain Users' may be better if we really want to associate the wellknown SID to this group. On the SID side I wonder if using the wellknown 'Domain Users' SID is the right thing to do. I do not see any special reasons why it shouldn't but I also do not have any special reason why we should. Anyone can think of any pros/cons of doing that ? Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Tue Oct 2 20:31:39 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 02 Oct 2012 16:31:39 -0400 Subject: [Freeipa-devel] [PATCH] 320 Only use service PAC type as an override In-Reply-To: <506B055B.4060605@redhat.com> References: <506B055B.4060605@redhat.com> Message-ID: <506B4F2B.8070807@redhat.com> Martin Kosek wrote: > PAC type (ipakrbauthzdata attribute) was being filled for all new > service automatically. However, the PAC type attribute was designed > to serve only as an override to default PAC type configured in > IPA config. With PAC type set in all services, users would have > to update all services to get new PAC types configured in IPA config. > > Do not set PAC type for new services. Add new NONE value meaning that > we do not want any PAC for the service (empty/missing attribute means > that the default PAC type list from IPA config is read). > > https://fedorahosted.org/freeipa/ticket/2184 > > --- > > Note: the new NONE value of service PAC type was planned in a scope of ticket > #2960. ACK, but before you push can you add the jist of this commit message to the help for PAC type in the service command help so users will understand the difference between NONE and blank? rob From alee at redhat.com Wed Oct 3 02:45:03 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 02 Oct 2012 22:45:03 -0400 Subject: [Freeipa-devel] [Fwd: [Pki-announce] Announcing Dogtag 10.0.0 alpha 2 release] Message-ID: <1349232304.27199.8.camel@aleeredhat.laptop> -------------- next part -------------- An embedded message was scrubbed... From: Ade Lee Subject: [Pki-announce] Announcing Dogtag 10.0.0 alpha 2 release Date: Tue, 02 Oct 2012 22:44:29 -0400 Size: 5963 URL: From mkosek at redhat.com Wed Oct 3 06:55:19 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 03 Oct 2012 08:55:19 +0200 Subject: [Freeipa-devel] [PATCH] 320 Only use service PAC type as an override In-Reply-To: <506B4F2B.8070807@redhat.com> References: <506B055B.4060605@redhat.com> <506B4F2B.8070807@redhat.com> Message-ID: <506BE157.5030007@redhat.com> On 10/02/2012 10:31 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> PAC type (ipakrbauthzdata attribute) was being filled for all new >> service automatically. However, the PAC type attribute was designed >> to serve only as an override to default PAC type configured in >> IPA config. With PAC type set in all services, users would have >> to update all services to get new PAC types configured in IPA config. >> >> Do not set PAC type for new services. Add new NONE value meaning that >> we do not want any PAC for the service (empty/missing attribute means >> that the default PAC type list from IPA config is read). >> >> https://fedorahosted.org/freeipa/ticket/2184 >> >> --- >> >> Note: the new NONE value of service PAC type was planned in a scope of ticket >> #2960. > > ACK, but before you push can you add the jist of this commit message to the > help for PAC type in the service command help so users will understand the > difference between NONE and blank? > > rob > Good idea. I updated doc of this attribute in service plugin and also doc/label of a relevant config option to help user distinguish what is a default and what is an override. Pushed to master, ipa-3-0. Martin From mkosek at redhat.com Wed Oct 3 07:18:51 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 03 Oct 2012 09:18:51 +0200 Subject: [Freeipa-devel] [PATCH 0015] Restrict admins group modifications In-Reply-To: <506ADF2E.9050502@redhat.com> References: <5061A202.2090203@redhat.com> <5061A432.3090709@redhat.com> <5061AAAB.7020801@redhat.com> <506322F5.4000901@redhat.com> <506ADF2E.9050502@redhat.com> Message-ID: <506BE6DB.8030707@redhat.com> On 10/02/2012 02:33 PM, Tomas Babej wrote: > On 09/26/2012 05:44 PM, Martin Kosek wrote: >> On 09/25/2012 02:59 PM, Tomas Babej wrote: >>> On 09/25/2012 02:31 PM, Martin Kosek wrote: >>>> On 09/25/2012 02:22 PM, Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> Group-mod command no longer allows --rename and/or --external >>>>> changes made to the admins group. In such cases, ProtectedEntryError >>>>> is being raised. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3098 >>>>> >>>>> Tomas >>>>> >>>> Just based on a quick glance, I see few issues: 1) I would like to see unit >>>> tests for this scenario 2) Some overlooked debug output: + >>>> self.log.info(str(keys)) Martin >>> I removed the unfortunate debug output and added two unit tests to test the >>> scenarios. >>> >>> Tomas >> I finally got to a proper review and here it is: >> >> 1) I think we should use some common global variable containing protected >> groups and not define it in every command separately (duplication -> errors). >> One is already used: >> >> ... >> protected_group_name = u'admins' >> ... >> >> I would like to see that to be used in both group-del and group-mod. I also >> think we should protect "trust admins" too as this group is also encoded in >> trust ACI, i.e. using a global variable like this one: >> >> PROTECTED_GROUPS = (u'admins', u'trust admins') >> >> >> 2) Minor issue, I think instead of: >> >> + is_admins_group = u'admins' in keys >> >> a more common pattern in IPA is the following: >> >> + is_admins_group = keys[-1] == u'admins' >> >> >> 3) We usually do not end our error messages in exceptions with ".": >> >> ... >> + raise errors.ProtectedEntryError(label=u'group', >> key=u'admins', reason=u'Cannot be renamed.') >> ... >> + raise errors.ProtectedEntryError(label=u'group', >> key=u'admins', reason=u'Cannot support external non-IPA members.') >> ... >> >> Otherwise the patch looks OK. >> >> Martin > I fixed the relevant issues and added few more test cases as well. > > Please check the new patch version. > > Tomas Looks good, works fine. I have just 2 minor styling issues: 1) The following blob can be simplified. From: + is_protected_group = False + if keys[-1] in PROTECTED_GROUPS: + is_protected_group = True to: is_protected_group = keys[-1] in PROTECTED_GROUPS 2) Lines with raised error messages are quite long: + raise errors.ProtectedEntryError(label=u'group', key=keys[-1], reason=u'Cannot be renamed') + raise errors.ProtectedEntryError(label=u'group', key=keys[-1], reason=u'Cannot support external non-IPA members') They should be wrapped. Martin From mkosek at redhat.com Wed Oct 3 07:39:55 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 03 Oct 2012 09:39:55 +0200 Subject: [Freeipa-devel] [PATCH 0014] Improve user addition to default group in host-add In-Reply-To: <50699CEF.30700@redhat.com> References: <5061894D.9010202@redhat.com> <506301B7.8070107@redhat.com> <50630D52.5090008@redhat.com> <50699CEF.30700@redhat.com> Message-ID: <506BEBCB.9030501@redhat.com> On 10/01/2012 03:38 PM, Tomas Babej wrote: > On 09/26/2012 04:12 PM, Martin Kosek wrote: >> On 09/26/2012 03:23 PM, Tomas Babej wrote: >>> On 09/25/2012 12:37 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> On adding new user, host-add tries to make it a member of default >>>> user group. This, however, can raise AlreadyGroupMember when the >>>> user is already member of this group due to automember rule or >>>> default group configured. This patch makes sure AlreadyGroupMember >>>> exception is caught in such cases. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3097 >>>> >>>> Tomas >>> I fixed the typo in the commit message. It refers to the proper command now. >>> >>> Tomas >> I would also like to see the tests that Petr Viktorin already asked for. >> >> Setting an automember default group to ipausers, adding a user and checking the >> result should be enough. >> >> Martin >> > I added a relevant test to the test_host_plugin.py file. > > Tomas ACK. Pushed to master, ipa-3-0. Martin From mkosek at redhat.com Wed Oct 3 08:23:29 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 03 Oct 2012 10:23:29 +0200 Subject: [Freeipa-devel] [PATCHES] 3 enhancements for the ipa-adtrust-install page In-Reply-To: <20121002075421.GR6816@localhost.localdomain> References: <20121002075421.GR6816@localhost.localdomain> Message-ID: <506BF601.4000707@redhat.com> On 10/02/2012 09:54 AM, Sumit Bose wrote: > Hi, > > the following three patches should fix > https://fedorahosted.org/freeipa/ticket/2967 > https://fedorahosted.org/freeipa/ticket/2972 > https://fedorahosted.org/freeipa/ticket/3038 respectively. > > bye, > Sumit > > 3x ACK. Pushed all three to master, ipa-3-0. Martin From sbose at redhat.com Wed Oct 3 09:35:07 2012 From: sbose at redhat.com (Sumit Bose) Date: Wed, 3 Oct 2012 11:35:07 +0200 Subject: [Freeipa-devel] [PATCH] 79 Add SIDs for existing users and groups at the end of ipa-adtrust-install Message-ID: <20121003093507.GW6816@localhost.localdomain> Hi, this patch adds a new option to ipa-adtrust-install to generate the SID for users and groups at the end of the run. This fixes https://fedorahosted.org/freeipa/ticket/3104 . bye, Sumit -------------- next part -------------- From 64f5b76c1869dbbc5e63035baa13642b43854839 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 2 Oct 2012 22:11:17 +0200 Subject: [PATCH] Add SIDs for existing users and groups at the end of ipa-adtrust-install Fixes https://fedorahosted.org/freeipa/ticket/3104 --- daemons/ipa-slapi-plugins/ipa-sidgen/Makefile.am | 1 + .../ipa-sidgen/ipa-sidgen-task-example.ldif | 10 ---------- .../ipa-sidgen/ipa-sidgen-task-run.ldif | 10 ++++++++++ install/tools/ipa-adtrust-install | 5 ++++- install/tools/man/ipa-adtrust-install.1 | 10 ++++++++++ ipaserver/install/adtrustinstance.py | 19 ++++++++++++++++++- 6 Dateien ge?ndert, 43 Zeilen hinzugef?gt(+), 12 Zeilen entfernt(-) delete mode 100644 daemons/ipa-slapi-plugins/ipa-sidgen/ipa-sidgen-task-example.ldif create mode 100644 daemons/ipa-slapi-plugins/ipa-sidgen/ipa-sidgen-task-run.ldif diff --git a/daemons/ipa-slapi-plugins/ipa-sidgen/Makefile.am b/daemons/ipa-slapi-plugins/ipa-sidgen/Makefile.am index 0d8b74e86369ae9c972e090ff0e6feddc840cfde..a0d0e9ecf366b23cc6f054945544cd88cd846cad 100644 --- a/daemons/ipa-slapi-plugins/ipa-sidgen/Makefile.am +++ b/daemons/ipa-slapi-plugins/ipa-sidgen/Makefile.am @@ -49,6 +49,7 @@ appdir = $(IPA_DATA_DIR) app_DATA = \ ipa-sidgen-conf.ldif \ ipa-sidgen-task-conf.ldif \ + ipa-sidgen-task-run.ldif \ $(NULL) EXTRA_DIST = \ diff --git a/daemons/ipa-slapi-plugins/ipa-sidgen/ipa-sidgen-task-example.ldif b/daemons/ipa-slapi-plugins/ipa-sidgen/ipa-sidgen-task-example.ldif deleted file mode 100644 index 9cfded73b1b53461c0c0aa4f563452f51d258aae..0000000000000000000000000000000000000000 --- a/daemons/ipa-slapi-plugins/ipa-sidgen/ipa-sidgen-task-example.ldif +++ /dev/null @@ -1,10 +0,0 @@ -dn: cn=sidgen,cn=ipa-sidgen-task,cn=plugins,cn=config -changetype: add -objectClass: top -objectClass: nsSlapdPlugin -objectClass: extensibleObject -cn: ipa-sidgen-task -nsslapd-pluginPath: libipa_sidgen_task -nsslapd-pluginInitfunc: sidgen_task_init -nsslapd-basedn: $SUFFIX -delay: 0 diff --git a/daemons/ipa-slapi-plugins/ipa-sidgen/ipa-sidgen-task-run.ldif b/daemons/ipa-slapi-plugins/ipa-sidgen/ipa-sidgen-task-run.ldif new file mode 100644 index 0000000000000000000000000000000000000000..663b7597b90a59c88c658dbcc5f483a6693f88dc --- /dev/null +++ b/daemons/ipa-slapi-plugins/ipa-sidgen/ipa-sidgen-task-run.ldif @@ -0,0 +1,10 @@ +dn: cn=sidgen,cn=ipa-sidgen-task,cn=tasks,cn=config +changetype: add +objectClass: top +objectClass: extensibleObject +cn: sidgen +# $SUFFIX must be replaced with the base DN of the IPA directory tree +nsslapd-basedn: $SUFFIX +# delay specifies the time the task should sleep between the generation of SIDs +# in nanoseconds +delay: 0 diff --git a/install/tools/ipa-adtrust-install b/install/tools/ipa-adtrust-install index 12e218de62dd4b4d795f7372e0108e6a208f1285..f50bb58213ac0681cd8bda0a449ae21c48e6adb8 100755 --- a/install/tools/ipa-adtrust-install +++ b/install/tools/ipa-adtrust-install @@ -61,6 +61,9 @@ def parse_options(): parser.add_option("-A", "--admin-name", sensitive=True, dest="admin_name", default='admin', help="admin user principal") + parser.add_option("--add-sids", dest="add_sids", action="store_true", + default=False, help="Add SIDs for existing users and" \ + "groups as the final step") options, args = parser.parse_args() safe_options = parser.get_safe_opts(options) @@ -254,7 +257,7 @@ def main(): smb.autobind = service.ENABLED smb.setup(api.env.host, ip_address, api.env.realm, api.env.domain, netbios_name, options.rid_base, options.secondary_rid_base, - options.no_msdcs) + options.no_msdcs, options.add_sids) smb.find_local_id_range() smb.create_instance() diff --git a/install/tools/man/ipa-adtrust-install.1 b/install/tools/man/ipa-adtrust-install.1 index fa63bca3c4859325acb5891de6ad1e21b97dc754..9204b7d5fde7493a4c268eb71693e86a63a1b4b7 100644 --- a/install/tools/man/ipa-adtrust-install.1 +++ b/install/tools/man/ipa-adtrust-install.1 @@ -71,6 +71,16 @@ are needed for the IPA domain which should point to all IPA servers: .IP \(bu _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs .TP +\fB\-\-add\-sids\fR +Add SIDs to existing users and groups as a final step of the +ipa\-adtrust\-install run. If there a many existing users and groups and a +couple of replicas in the environment this operation might lead to a high +replication traffic and a performance degradation of all IPA servers in the +environment. To avoid this the SID generation can be run after +ipa\-adtrust\-install is run and scheduled independently. To start this task +you have to load an edited version of ipa-sidgen-task-run.ldif with the +ldapmodify command info the directory server. +.TP \fB\-U\fR, \fB\-\-unattended\fR An unattended installation that will never prompt for user input .TP diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py index 8b8364929a9f063ad66fac0d7bca4d13977f9543..8822c2855eff3b9855914679ac7cedd016ea9185 100644 --- a/ipaserver/install/adtrustinstance.py +++ b/ipaserver/install/adtrustinstance.py @@ -109,6 +109,7 @@ class ADTRUSTInstance(service.Service): self.domain_name = None self.netbios_name = None self.no_msdcs = None + self.add_sids = None self.smbd_user = None self.suffix = DN() self.ldapi_socket = None @@ -332,6 +333,16 @@ class ADTRUSTInstance(service.Service): try: self._ldap_mod("ipa-sidgen-conf.ldif", self.sub_dict) self._ldap_mod("ipa-sidgen-task-conf.ldif", self.sub_dict) + except Exception: + pass + + def __add_sids(self): + """ + Add SIDs for existing users and groups + """ + + try: + self._ldap_mod("ipa-sidgen-task-run.ldif", self.sub_dict) except: pass @@ -574,7 +585,8 @@ class ADTRUSTInstance(service.Service): FQDN = self.fqdn) def setup(self, fqdn, ip_address, realm_name, domain_name, netbios_name, - rid_base, secondary_rid_base, no_msdcs=False, smbd_user="samba"): + rid_base, secondary_rid_base, no_msdcs=False, add_sids=False, + smbd_user="samba"): self.fqdn = fqdn self.ip_address = ip_address self.realm = realm_name @@ -583,6 +595,7 @@ class ADTRUSTInstance(service.Service): self.rid_base = rid_base self.secondary_rid_base = secondary_rid_base self.no_msdcs = no_msdcs + self.add_sids = add_sids self.smbd_user = smbd_user self.suffix = ipautil.realm_to_suffix(self.realm) self.ldapi_socket = "%%2fvar%%2frun%%2fslapd-%s.socket" % \ @@ -671,6 +684,10 @@ class ADTRUSTInstance(service.Service): self.__configure_selinux_for_smbd) self.step("starting CIFS services", self.__start) + if self.add_sids: + self.step("adding SIDs to existing users and groups", + self.__add_sids) + self.start_creation("Configuring CIFS:") def uninstall(self): -- 1.7.11.4 From tbabej at redhat.com Wed Oct 3 09:49:20 2012 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 03 Oct 2012 11:49:20 +0200 Subject: [Freeipa-devel] [PATCH 0015] Restrict admins group modifications In-Reply-To: <506BE6DB.8030707@redhat.com> References: <5061A202.2090203@redhat.com> <5061A432.3090709@redhat.com> <5061AAAB.7020801@redhat.com> <506322F5.4000901@redhat.com> <506ADF2E.9050502@redhat.com> <506BE6DB.8030707@redhat.com> Message-ID: <506C0A20.2040404@redhat.com> On 10/03/2012 09:18 AM, Martin Kosek wrote: > On 10/02/2012 02:33 PM, Tomas Babej wrote: >> On 09/26/2012 05:44 PM, Martin Kosek wrote: >>> On 09/25/2012 02:59 PM, Tomas Babej wrote: >>>> On 09/25/2012 02:31 PM, Martin Kosek wrote: >>>>> On 09/25/2012 02:22 PM, Tomas Babej wrote: >>>>>> Hi, >>>>>> >>>>>> Group-mod command no longer allows --rename and/or --external >>>>>> changes made to the admins group. In such cases, ProtectedEntryError >>>>>> is being raised. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3098 >>>>>> >>>>>> Tomas >>>>>> >>>>> Just based on a quick glance, I see few issues: 1) I would like to see unit >>>>> tests for this scenario 2) Some overlooked debug output: + >>>>> self.log.info(str(keys)) Martin >>>> I removed the unfortunate debug output and added two unit tests to test the >>>> scenarios. >>>> >>>> Tomas >>> I finally got to a proper review and here it is: >>> >>> 1) I think we should use some common global variable containing protected >>> groups and not define it in every command separately (duplication -> errors). >>> One is already used: >>> >>> ... >>> protected_group_name = u'admins' >>> ... >>> >>> I would like to see that to be used in both group-del and group-mod. I also >>> think we should protect "trust admins" too as this group is also encoded in >>> trust ACI, i.e. using a global variable like this one: >>> >>> PROTECTED_GROUPS = (u'admins', u'trust admins') >>> >>> >>> 2) Minor issue, I think instead of: >>> >>> + is_admins_group = u'admins' in keys >>> >>> a more common pattern in IPA is the following: >>> >>> + is_admins_group = keys[-1] == u'admins' >>> >>> >>> 3) We usually do not end our error messages in exceptions with ".": >>> >>> ... >>> + raise errors.ProtectedEntryError(label=u'group', >>> key=u'admins', reason=u'Cannot be renamed.') >>> ... >>> + raise errors.ProtectedEntryError(label=u'group', >>> key=u'admins', reason=u'Cannot support external non-IPA members.') >>> ... >>> >>> Otherwise the patch looks OK. >>> >>> Martin >> I fixed the relevant issues and added few more test cases as well. >> >> Please check the new patch version. >> >> Tomas > Looks good, works fine. I have just 2 minor styling issues: > > 1) The following blob can be simplified. From: > > + is_protected_group = False > + if keys[-1] in PROTECTED_GROUPS: > + is_protected_group = True > > to: > > is_protected_group = keys[-1] in PROTECTED_GROUPS > > > 2) Lines with raised error messages are quite long: > > + raise errors.ProtectedEntryError(label=u'group', key=keys[-1], > reason=u'Cannot be renamed') > > + raise errors.ProtectedEntryError(label=u'group', key=keys[-1], > reason=u'Cannot support external non-IPA members') > > They should be wrapped. > > Martin Styling issues corrected. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0015-4-Restrict-admins-group-modifications.patch Type: text/x-patch Size: 6816 bytes Desc: not available URL: From mkosek at redhat.com Wed Oct 3 11:35:23 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 03 Oct 2012 13:35:23 +0200 Subject: [Freeipa-devel] [PATCH 0015] Restrict admins group modifications In-Reply-To: <506C0A20.2040404@redhat.com> References: <5061A202.2090203@redhat.com> <5061A432.3090709@redhat.com> <5061AAAB.7020801@redhat.com> <506322F5.4000901@redhat.com> <506ADF2E.9050502@redhat.com> <506BE6DB.8030707@redhat.com> <506C0A20.2040404@redhat.com> Message-ID: <506C22FB.3010705@redhat.com> On 10/03/2012 11:49 AM, Tomas Babej wrote: > On 10/03/2012 09:18 AM, Martin Kosek wrote: >> On 10/02/2012 02:33 PM, Tomas Babej wrote: >>> On 09/26/2012 05:44 PM, Martin Kosek wrote: >>>> On 09/25/2012 02:59 PM, Tomas Babej wrote: >>>>> On 09/25/2012 02:31 PM, Martin Kosek wrote: >>>>>> On 09/25/2012 02:22 PM, Tomas Babej wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Group-mod command no longer allows --rename and/or --external >>>>>>> changes made to the admins group. In such cases, ProtectedEntryError >>>>>>> is being raised. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/3098 >>>>>>> >>>>>>> Tomas >>>>>>> >>>>>> Just based on a quick glance, I see few issues: 1) I would like to see unit >>>>>> tests for this scenario 2) Some overlooked debug output: + >>>>>> self.log.info(str(keys)) Martin >>>>> I removed the unfortunate debug output and added two unit tests to test the >>>>> scenarios. >>>>> >>>>> Tomas >>>> I finally got to a proper review and here it is: >>>> >>>> 1) I think we should use some common global variable containing protected >>>> groups and not define it in every command separately (duplication -> errors). >>>> One is already used: >>>> >>>> ... >>>> protected_group_name = u'admins' >>>> ... >>>> >>>> I would like to see that to be used in both group-del and group-mod. I also >>>> think we should protect "trust admins" too as this group is also encoded in >>>> trust ACI, i.e. using a global variable like this one: >>>> >>>> PROTECTED_GROUPS = (u'admins', u'trust admins') >>>> >>>> >>>> 2) Minor issue, I think instead of: >>>> >>>> + is_admins_group = u'admins' in keys >>>> >>>> a more common pattern in IPA is the following: >>>> >>>> + is_admins_group = keys[-1] == u'admins' >>>> >>>> >>>> 3) We usually do not end our error messages in exceptions with ".": >>>> >>>> ... >>>> + raise errors.ProtectedEntryError(label=u'group', >>>> key=u'admins', reason=u'Cannot be renamed.') >>>> ... >>>> + raise errors.ProtectedEntryError(label=u'group', >>>> key=u'admins', reason=u'Cannot support external non-IPA members.') >>>> ... >>>> >>>> Otherwise the patch looks OK. >>>> >>>> Martin >>> I fixed the relevant issues and added few more test cases as well. >>> >>> Please check the new patch version. >>> >>> Tomas >> Looks good, works fine. I have just 2 minor styling issues: >> >> 1) The following blob can be simplified. From: >> >> + is_protected_group = False >> + if keys[-1] in PROTECTED_GROUPS: >> + is_protected_group = True >> >> to: >> >> is_protected_group = keys[-1] in PROTECTED_GROUPS >> >> >> 2) Lines with raised error messages are quite long: >> >> + raise errors.ProtectedEntryError(label=u'group', key=keys[-1], >> reason=u'Cannot be renamed') >> >> + raise errors.ProtectedEntryError(label=u'group', key=keys[-1], >> reason=u'Cannot support external non-IPA members') >> >> They should be wrapped. >> >> Martin > Styling issues corrected. > > Tomas ACK. Pushed to master, ipa-3-0. Martin From mkosek at redhat.com Wed Oct 3 12:25:31 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 03 Oct 2012 14:25:31 +0200 Subject: [Freeipa-devel] [PATCH] 1058 clear session key In-Reply-To: <506B3106.8070602@redhat.com> References: <506B3106.8070602@redhat.com> Message-ID: <506C2EBB.7090903@redhat.com> On 10/02/2012 08:23 PM, Rob Crittenden wrote: > Clear the host session key when enrolling a client. > > Make sure dbdir is preserved when a new connection is created. > > rob > I tested repeatedly installing, uninstalling client and unlike previously, I did not receive any NSS initialization error. Other test were also OK for me, so generally I agree with the patch. I just see one potential issue in this section: + if (current_conn is not None and + hasattr(current_conn.conn._ServerProxy__transport, 'dbdir')): + dbdir = current_conn.conn._ServerProxy__transport.dbdir + self.debug('Using dbdir %s' % dbdir) If I understand that correctly, dbdir attribute in current_conn.conn._ServerProxy__transport may be changed by other thread, i.e. I would rather do something like that: if current_conn is not None: dbdir = getattr(current_conn.conn._ServerProxy__transport, 'dbdir', None) if dbdir is not None: self.debug('Using dbdir %s' % dbdir) I did not reproduce that, but I'd be afraid that some other thread may remove 'dbdir' right after our hasattr check, so the next statement would fail. Martin From rcritten at redhat.com Wed Oct 3 12:41:30 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 03 Oct 2012 08:41:30 -0400 Subject: [Freeipa-devel] [PATCH] 319 Make ipakrbprincipal objectclass optional In-Reply-To: <506B0C43.70206@redhat.com> References: <5069B6A7.3020403@redhat.com> <506ABF97.2040903@redhat.com> <506AE64E.9010200@redhat.com> <506B0C43.70206@redhat.com> Message-ID: <506C327A.4000700@redhat.com> Martin Kosek wrote: > On 10/02/2012 03:04 PM, Martin Kosek wrote: >> On 10/02/2012 12:19 PM, Petr Viktorin wrote: >>> On 10/01/2012 05:28 PM, Martin Kosek wrote: >>>>> From IPA 3.0, services have by default ipakrbprincipal objectclass which >>>> allows ipakrbprincipalalias attribute used for case-insensitive principal >>>> searches. However, as services created in previous version do not have >>>> this objectclass (and attribute), they are not listed in service list >>>> produced by service-find. >>>> >>>> Treat the ipakrbprincipal as optional to avoid missing services in >>>> service-find command. Add flag to service-mod command which can fill >>>> ipakrbprincipalalias attribute when case-insensitive principal searches >>>> for a 2.x service are required. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3106 >>> >>> This works, I'm getting all services now & the tests pass. >>> >>>> >>>> ----- >>>> >>>> I am still pondering about a right way to fill ipakrbprincipalalias used in for >>>> IPA 3.0 case-insensitive searches, so far I implemented this command: >>>> >>>> ipa service-mod PRINCIPAL --update-principal-alias >>>> >>>> But I am thinking it may be a better approach to generalize it and do something >>>> like that: >>>> >>>> ipa service-mod PRINCIPAL --upgrade/--update >>>> >>>> This command would do a general update of service entry to an up-to-date 3.0 >>>> style, in this case it could do 2 things: >>>> * fill ipakrbprincipalalias >>>> * fill ipakrbauthzdata (based on default value in IPA config). >>> >>> I don't think you're generalizing enough; `service-mod --upgrade` isn't that >>> different from `service-mod --update-principal-alias --update-authzdata`. >>> Scripting this to happen for all services could be a nuisance, though. There >>> should be a way to upgrade all services at once, and since we already have >>> ipa-ldap-updater for it, it should run as part of that. >>> >>> I think we should keep ipakrbprincipal optional, in case the upgrade goes wrong. >>> >> >> I agree. I created an upgrade plugin which should update all services and fill >> ipakrbprincipalalias during upgrade (attached). I tested 2.2 -> 3.0 upgrade and >> it worked fine. >> >> Martin >> > > There was a glitch in the loop repeating the update when LDAP limits are hit - > thanks Petr Viktorin for noticing the issue. It is working now, I tried with 10 > affected services and search limit set to 1 entry - and the loop executed 10 > times as it was supposed to. > > I also disabled size/time limits for the search in the upgrade plugin. But it > would also work if default IPA search limits (100 entries) are used, it should > just make things faster. > > Martin ACK, pushed to master and ipa-3-0. I tested with > 2500 services. rob From pviktori at redhat.com Wed Oct 3 12:42:07 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 03 Oct 2012 14:42:07 +0200 Subject: [Freeipa-devel] [PATCH] 319 Make ipakrbprincipal objectclass optional In-Reply-To: <506B0C43.70206@redhat.com> References: <5069B6A7.3020403@redhat.com> <506ABF97.2040903@redhat.com> <506AE64E.9010200@redhat.com> <506B0C43.70206@redhat.com> Message-ID: <506C329F.9010109@redhat.com> On 10/02/2012 05:46 PM, Martin Kosek wrote: > On 10/02/2012 03:04 PM, Martin Kosek wrote: >> On 10/02/2012 12:19 PM, Petr Viktorin wrote: >>> On 10/01/2012 05:28 PM, Martin Kosek wrote: >>>>> From IPA 3.0, services have by default ipakrbprincipal objectclass which >>>> allows ipakrbprincipalalias attribute used for case-insensitive principal >>>> searches. However, as services created in previous version do not have >>>> this objectclass (and attribute), they are not listed in service list >>>> produced by service-find. >>>> >>>> Treat the ipakrbprincipal as optional to avoid missing services in >>>> service-find command. Add flag to service-mod command which can fill >>>> ipakrbprincipalalias attribute when case-insensitive principal searches >>>> for a 2.x service are required. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3106 >>> >>> This works, I'm getting all services now & the tests pass. >>> >>>> >>>> ----- >>>> >>>> I am still pondering about a right way to fill ipakrbprincipalalias used in for >>>> IPA 3.0 case-insensitive searches, so far I implemented this command: >>>> >>>> ipa service-mod PRINCIPAL --update-principal-alias >>>> >>>> But I am thinking it may be a better approach to generalize it and do something >>>> like that: >>>> >>>> ipa service-mod PRINCIPAL --upgrade/--update >>>> >>>> This command would do a general update of service entry to an up-to-date 3.0 >>>> style, in this case it could do 2 things: >>>> * fill ipakrbprincipalalias >>>> * fill ipakrbauthzdata (based on default value in IPA config). >>> >>> I don't think you're generalizing enough; `service-mod --upgrade` isn't that >>> different from `service-mod --update-principal-alias --update-authzdata`. >>> Scripting this to happen for all services could be a nuisance, though. There >>> should be a way to upgrade all services at once, and since we already have >>> ipa-ldap-updater for it, it should run as part of that. >>> >>> I think we should keep ipakrbprincipal optional, in case the upgrade goes wrong. >>> >> >> I agree. I created an upgrade plugin which should update all services and fill >> ipakrbprincipalalias during upgrade (attached). I tested 2.2 -> 3.0 upgrade and >> it worked fine. >> >> Martin >> > > There was a glitch in the loop repeating the update when LDAP limits are hit - > thanks Petr Viktorin for noticing the issue. It is working now, I tried with 10 > affected services and search limit set to 1 entry - and the loop executed 10 > times as it was supposed to. > > I also disabled size/time limits for the search in the upgrade plugin. But it > would also work if default IPA search limits (100 entries) are used, it should > just make things faster. > > Martin > With the limits removed, the loop is redundant. Please decide yourself if it would be better to remove it. ACK from me if you want to push it as is. -- Petr? From tbabej at redhat.com Wed Oct 3 13:31:50 2012 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 03 Oct 2012 15:31:50 +0200 Subject: [Freeipa-devel] [PATCH 0016] Adds port to connection error message in ipa-client-install In-Reply-To: <506B36FF.5050303@redhat.com> References: <5062FD9A.7060802@redhat.com> <50635847.5070602@redhat.com> <5069C48B.8050104@redhat.com> <506B36FF.5050303@redhat.com> Message-ID: <506C3E46.20600@redhat.com> On 10/02/2012 08:48 PM, Rob Crittenden wrote: > Tomas Babej wrote: >> On 09/26/2012 09:32 PM, Rob Crittenden wrote: >>> Tomas Babej wrote: >>>> Hi, >>>> >>>> Connection error message in ipa-client-install now warns the user >>>> about the need of opening 389 port for directory server. >>>> >>>> https://fedorahosted.org/freeipa/ticket/2816 >>>> >>>> I think this can be pushed as a one-liner. >>> >>> I think we should list all ports that are required for client >>> enrollment. >>> >>> From my calculations we need at a minimum tcp ports 80 and 389, either >>> or both udp/tcp for port 88 and if NTP is enabled 123 udp for >>> enrollment alone. The NTP failure won't cause enrollment to fail >>> though, so we may be able to skip that. >>> >>> Similarly 464 should be enabled but we don't use it during enrollment. >>> >>> rob >> I improved the error message. Please check if there are any issues. >> >> Thanks >> >> Tomas > > This only works if port 389 is blocked, not 88 or 80. > > rob I tested and added the port configuration info message at the appropriate places for TCP 80, 88, 389 ports. I also added the info message at the end of installation output. Please consider if you agree with this approach. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0016-3-Adds-port-to-connection-error-message-in-ipa-client-.patch Type: text/x-patch Size: 4105 bytes Desc: not available URL: From pvoborni at redhat.com Wed Oct 3 13:50:14 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 03 Oct 2012 15:50:14 +0200 Subject: [Freeipa-devel] [PATCH] [WIP] Firefox extension In-Reply-To: <506B1879.1090501@redhat.com> References: <506B1879.1090501@redhat.com> Message-ID: <506C4296.7060904@redhat.com> As Alexander proposed in other channel. I will remove the removal of configure.jar and offer the old configuration method if user is using FF < 4 so we don't have to make the extension compatible with this ancient version. It will be done this way: If FF < 4 is detected: * in browserconfig.html steps 2 and 3 will be grayed-out and replaced with step 2a with a link to ssbrowser.html and a description explaining the problem * ssbrowser.html will be enhanced by steps for autoconfiguration of FF < 4. We can also show the steps in browserconfig, but I want to have it somehow available even if user is not using FF<4 to keep general awareness about the problem and also to be usable if version detection fails. Other possible problem with steps in browserconfig is different styles of buttons (to keep the same styles we would have to include same css files and jquery.js to configure.jar, which I don't want to do). On 10/02/2012 06:38 PM, Petr Vobornik wrote: > This effort is still a WIP but I wanted to sent it to allow comments on > chosen approaches. > > You can visually check config pages on: > http://pvoborni.fedorapeople.org/config/unauthorized.html > resp. http://pvoborni.fedorapeople.org/config/browserconfig.html > > Note that installation of ca.crt and extentsion won't work because > fedorapeople server doesn't send proper headers. > > If you wanto to build it and test it, to not mess up your FF profile, > make a new one: > firefox -ProfileManager > firefox -P myprofilename --no-remote > > So far I tested it only on FF15. It should be functional on FF4 and > later but it most likely won't work on FF3.6 (doesn't support > bootstrapping ext and xul overlay not tested). I will work on FF3.6 > support ASAP. > > I didn't test installations of replicas. > > Patch descriptions: > > Kerberos authentication extension > --------------------------------- > > The extension should replace signed code (configure.jar) used for > Firefox configuration. Using privileged code is not possible since > Firefox 15 [1] [2]. Extension is bootstrapped which means it can be used > without browser restart on Firefox 4 and later. > > How it works: > Extension listens on each page's document element for event > 'kerberos-auth-config' which should be raised on custom data element. > Communication data is transferred through data element's attributes [3]. > The only required attribute is 'method'. Currently there are two > possible values: 'configure' and 'can_configure'. > 'can_configure' method serves for detecting if the extension is > installed. 'configure' method does the actual configuration. Possible > optional options for 'configure' can be found in > kerberosauth.js:kerberosauth.config_options. Currently they are: > 'referer', 'native_gss_lib', 'trusted_uris', 'allow_proxies'. Result of > a method is stored in data element's 'answer' attribute. When > 'configure' method is used, the extension asks the user if he wants to > configure the browser, it should prevent silent configuration by > malicious pages. > > Possible enhancement: > * add UI for manual edit > * more configurations ie. for gss_lib, sspi (good with UI or with > enhanced config page) > * introspection of client (read ipa client install config and such) > > Ticket: https://fedorahosted.org/freeipa/ticket/3094 > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=546848 > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=757046 > [3] > https://developer.mozilla.org/en-US/docs/Code_snippets/Interaction_between_privileged_and_non-privileged_pages > > > Build and installation of Kerberos authentication extension > ----------------------------------------------------------- > > This patch is removing files associated with configure.jar and a build > of configure.jar with a build of kerberosauth.xpi (FF Kerberos > authentication extension). > > Currently the build is done in install phase of FreeIPA server. It is to > allow signing of the extension by singing certificate. The signing might > not be necessary because the only outcome is that in extension > installation FF doesn't show that the maker is not verified. It shows > text: 'Object signing cert'. This might be a bug in > httpinstance.py:262(db.create_signing_cert("Signing-Cert", "Object > Signing Cert", ca_db)) The value is in place of hostname parameter. > > If the extension is not signed, it can be created in rpm build phase, > which should make upgrades easier. Current implementation doesn't handle > upgrades yet. > > In order to keep extension and config pages not dependent on a realm, a > krb.js.teplate file was created. This template is used for creating a > /usr/share/ipa/html/krb.js file in install phase which holds FreeIPA's > realm and domain information. This information can be then used by > config pages by importing this file. > > Ticket: https://fedorahosted.org/freeipa/ticket/3094 > > Configuration pages changed to use new FF extension > --------------------------------------------------- > > browserconfig.html was changed to use new FF extension. The page is > completely Firefox specific therefore the title was changed from > 'Configure browser' to 'Firefox configuration'. Instruction to import CA > cert in unauthorized.html are FF specific too, so they were moved to > browserconfig.html. Unauthorized.html text was changed to distinguish FF > config and other browsers. Now the page shows link for FF > (browserconfig.html) and other browsers (ssbrowser.html). Ssbrowser.html > should be enhanced by more configurations and browsers later [1]. > > Unauthorized dialog in Web UI now links to http://../unauthorized.html > instead of https. This change is done because of FF strange handling of > extension installations from https sites [2]. Firefox allows ext. > installation from https sites only when the certificate is signed by > some build-in CA. To allow custom CAs an option in about:config has to > be changed which don't help us at all because we wants to avoid manual > changes in about:config. > > The design of browserconfig is inspired by Kyle Baker's design (2.1 > Enhancements_v2.odt). It is not exactly the same. Highlighting of the > steps wasn't used because in some cases we can switch some steps. > > Ticket: https://fedorahosted.org/freeipa/ticket/3094 > > [1] https://fedorahosted.org/freeipa/ticket/823 > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=688383 > -- Petr Vobornik From tbabej at redhat.com Wed Oct 3 13:56:56 2012 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 03 Oct 2012 15:56:56 +0200 Subject: [Freeipa-devel] [PATCH 0016] Adds port to connection error message in ipa-client-install In-Reply-To: <506C3E46.20600@redhat.com> References: <5062FD9A.7060802@redhat.com> <50635847.5070602@redhat.com> <5069C48B.8050104@redhat.com> <506B36FF.5050303@redhat.com> <506C3E46.20600@redhat.com> Message-ID: <506C4428.9090903@redhat.com> On 10/03/2012 03:31 PM, Tomas Babej wrote: > On 10/02/2012 08:48 PM, Rob Crittenden wrote: >> Tomas Babej wrote: >>> On 09/26/2012 09:32 PM, Rob Crittenden wrote: >>>> Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> Connection error message in ipa-client-install now warns the user >>>>> about the need of opening 389 port for directory server. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/2816 >>>>> >>>>> I think this can be pushed as a one-liner. >>>> >>>> I think we should list all ports that are required for client >>>> enrollment. >>>> >>>> From my calculations we need at a minimum tcp ports 80 and 389, either >>>> or both udp/tcp for port 88 and if NTP is enabled 123 udp for >>>> enrollment alone. The NTP failure won't cause enrollment to fail >>>> though, so we may be able to skip that. >>>> >>>> Similarly 464 should be enabled but we don't use it during enrollment. >>>> >>>> rob >>> I improved the error message. Please check if there are any issues. >>> >>> Thanks >>> >>> Tomas >> >> This only works if port 389 is blocked, not 88 or 80. >> >> rob > I tested and added the port configuration info message at the appropriate > places for TCP 80, 88, 389 ports. I also added the info message at the > end > of installation output. Please consider if you agree with this approach. > > Tomas I reworded the commit message, due to the scope of changes made since the first revision of the patch. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0016-4-Notify-user-about-necessary-ports-in-ipa-client-inst.patch Type: text/x-patch Size: 4332 bytes Desc: not available URL: From simo at redhat.com Wed Oct 3 14:19:04 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 03 Oct 2012 10:19:04 -0400 Subject: [Freeipa-devel] [PATCH] [WIP] Firefox extension In-Reply-To: <506C4296.7060904@redhat.com> References: <506B1879.1090501@redhat.com> <506C4296.7060904@redhat.com> Message-ID: <1349273944.22373.89.camel@willson.li.ssimo.org> On Wed, 2012-10-03 at 15:50 +0200, Petr Vobornik wrote: > As Alexander proposed in other channel. I will remove the removal of > configure.jar and offer the old configuration method if user is using FF > < 4 so we don't have to make the extension compatible with this ancient > version. It will be done this way: > > If FF < 4 is detected: > * in browserconfig.html steps 2 and 3 will be grayed-out and replaced > with step 2a with a link to ssbrowser.html and a description explaining > the problem > * ssbrowser.html will be enhanced by steps for autoconfiguration of FF > < 4. > > We can also show the steps in browserconfig, but I want to have it > somehow available even if user is not using FF<4 to keep general > awareness about the problem and also to be usable if version detection > fails. Other possible problem with steps in browserconfig is different > styles of buttons (to keep the same styles we would have to include same > css files and jquery.js to configure.jar, which I don't want to do). Excellent plan, we should try to reduce the amount of work, and letting old browsers use the old method is perfectly fine. If FF15 is the only browser that fails with the old method I would even go as far as testing exclusively with FF15 and have anything < FF15 use the old method. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Wed Oct 3 14:59:28 2012 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 03 Oct 2012 10:59:28 -0400 Subject: [Freeipa-devel] [PATCH] [WIP] Firefox extension In-Reply-To: <1349273944.22373.89.camel@willson.li.ssimo.org> References: <506B1879.1090501@redhat.com> <506C4296.7060904@redhat.com> <1349273944.22373.89.camel@willson.li.ssimo.org> Message-ID: <506C52D0.1090007@redhat.com> On 10/03/2012 10:19 AM, Simo Sorce wrote: > On Wed, 2012-10-03 at 15:50 +0200, Petr Vobornik wrote: >> As Alexander proposed in other channel. I will remove the removal of >> configure.jar and offer the old configuration method if user is using FF >> < 4 so we don't have to make the extension compatible with this ancient >> version. It will be done this way: >> >> If FF < 4 is detected: >> * in browserconfig.html steps 2 and 3 will be grayed-out and replaced >> with step 2a with a link to ssbrowser.html and a description explaining >> the problem >> * ssbrowser.html will be enhanced by steps for autoconfiguration of FF >> < 4. >> >> We can also show the steps in browserconfig, but I want to have it >> somehow available even if user is not using FF<4 to keep general >> awareness about the problem and also to be usable if version detection >> fails. Other possible problem with steps in browserconfig is different >> styles of buttons (to keep the same styles we would have to include same >> css files and jquery.js to configure.jar, which I don't want to do). > Excellent plan, we should try to reduce the amount of work, and letting > old browsers use the old method is perfectly fine. > If FF15 is the only browser that fails with the old method I would even > go as far as testing exclusively with FF15 and have anything < FF15 use > the old method. +1 > Simo. > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From mkosek at redhat.com Wed Oct 3 15:40:08 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 03 Oct 2012 17:40:08 +0200 Subject: [Freeipa-devel] [PATCH] 0084 Wait for secure Dogtag ports when starting the pki services In-Reply-To: <5061C1F0.1050501@redhat.com> References: <5061C1F0.1050501@redhat.com> Message-ID: <506C5C58.50602@redhat.com> On 09/25/2012 04:38 PM, Petr Viktorin wrote: > > Dogtag opens not only the insecure port (8080 or 9180, for d10 or > d9 respectively), but also secure ports (8443 or 9443&9444). > Wait for them when starting. > > > Part of the fix for https://fedorahosted.org/freeipa/ticket/3084. I found that > if we don't wait for the secure port, /ca/admin/ca/getStatus will give a > service unavailable error. > > I'm working on a patch to utilize the new status information. I'll submit it > after the updated Dogtag builds get in. > This shouldn't hurt, worked fine in my d9/d10 tests. ACK. Pushed to master, ipa-3-0. Martin From rcritten at redhat.com Wed Oct 3 15:49:52 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 03 Oct 2012 11:49:52 -0400 Subject: [Freeipa-devel] [PATCH] 1058 clear session key In-Reply-To: <506C2EBB.7090903@redhat.com> References: <506B3106.8070602@redhat.com> <506C2EBB.7090903@redhat.com> Message-ID: <506C5EA0.7080806@redhat.com> Martin Kosek wrote: > On 10/02/2012 08:23 PM, Rob Crittenden wrote: >> Clear the host session key when enrolling a client. >> >> Make sure dbdir is preserved when a new connection is created. >> >> rob >> > > I tested repeatedly installing, uninstalling client and unlike previously, I > did not receive any NSS initialization error. Other test were also OK for me, > so generally I agree with the patch. > > I just see one potential issue in this section: > > > + if (current_conn is not None and > + hasattr(current_conn.conn._ServerProxy__transport, 'dbdir')): > + dbdir = current_conn.conn._ServerProxy__transport.dbdir > + self.debug('Using dbdir %s' % dbdir) > > If I understand that correctly, dbdir attribute in > current_conn.conn._ServerProxy__transport may be changed by other thread, i.e. > I would rather do something like that: > > if current_conn is not None: > dbdir = getattr(current_conn.conn._ServerProxy__transport, 'dbdir', None) > if dbdir is not None: > self.debug('Using dbdir %s' % dbdir) > > I did not reproduce that, but I'd be afraid that some other thread may remove > 'dbdir' right after our hasattr check, so the next statement would fail. > > Martin Good idea, can't be too safe. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1058-2-client.patch Type: text/x-diff Size: 4625 bytes Desc: not available URL: From mkosek at redhat.com Wed Oct 3 17:24:00 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 3 Oct 2012 13:24:00 -0400 (EDT) Subject: [Freeipa-devel] [PATCH] 1058 clear session key In-Reply-To: <506C5EA0.7080806@redhat.com> Message-ID: <1845316327.5794936.1349285040960.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Rob Crittenden" > To: "Martin Kosek" > Cc: "freeipa-devel" > Sent: Wednesday, October 3, 2012 5:49:52 PM > Subject: Re: [Freeipa-devel] [PATCH] 1058 clear session key > > Martin Kosek wrote: > > On 10/02/2012 08:23 PM, Rob Crittenden wrote: > >> Clear the host session key when enrolling a client. > >> > >> Make sure dbdir is preserved when a new connection is created. > >> > >> rob > >> > > > > I tested repeatedly installing, uninstalling client and unlike > > previously, I > > did not receive any NSS initialization error. Other test were also > > OK for me, > > so generally I agree with the patch. > > > > I just see one potential issue in this section: > > > > > > + if (current_conn is not None and > > + > > hasattr(current_conn.conn._ServerProxy__transport, > > 'dbdir')): > > + dbdir = > > current_conn.conn._ServerProxy__transport.dbdir > > + self.debug('Using dbdir %s' % dbdir) > > > > If I understand that correctly, dbdir attribute in > > current_conn.conn._ServerProxy__transport may be changed by other > > thread, i.e. > > I would rather do something like that: > > > > if current_conn is not None: > > dbdir = getattr(current_conn.conn._ServerProxy__transport, > > 'dbdir', None) > > if dbdir is not None: > > self.debug('Using dbdir %s' % dbdir) > > > > I did not reproduce that, but I'd be afraid that some other thread > > may remove > > 'dbdir' right after our hasattr check, so the next statement would > > fail. > > > > Martin > > Good idea, can't be too safe. > > rob > ACK. Pushed to master, ipa-3-0. Martin From rcritten at redhat.com Wed Oct 3 17:27:17 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 03 Oct 2012 13:27:17 -0400 Subject: [Freeipa-devel] [PATCH 0016] Adds port to connection error message in ipa-client-install In-Reply-To: <506C4428.9090903@redhat.com> References: <5062FD9A.7060802@redhat.com> <50635847.5070602@redhat.com> <5069C48B.8050104@redhat.com> <506B36FF.5050303@redhat.com> <506C3E46.20600@redhat.com> <506C4428.9090903@redhat.com> Message-ID: <506C7575.20106@redhat.com> Tomas Babej wrote: > On 10/03/2012 03:31 PM, Tomas Babej wrote: >> On 10/02/2012 08:48 PM, Rob Crittenden wrote: >>> Tomas Babej wrote: >>>> On 09/26/2012 09:32 PM, Rob Crittenden wrote: >>>>> Tomas Babej wrote: >>>>>> Hi, >>>>>> >>>>>> Connection error message in ipa-client-install now warns the user >>>>>> about the need of opening 389 port for directory server. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/2816 >>>>>> >>>>>> I think this can be pushed as a one-liner. >>>>> >>>>> I think we should list all ports that are required for client >>>>> enrollment. >>>>> >>>>> From my calculations we need at a minimum tcp ports 80 and 389, either >>>>> or both udp/tcp for port 88 and if NTP is enabled 123 udp for >>>>> enrollment alone. The NTP failure won't cause enrollment to fail >>>>> though, so we may be able to skip that. >>>>> >>>>> Similarly 464 should be enabled but we don't use it during enrollment. >>>>> >>>>> rob >>>> I improved the error message. Please check if there are any issues. >>>> >>>> Thanks >>>> >>>> Tomas >>> >>> This only works if port 389 is blocked, not 88 or 80. >>> >>> rob >> I tested and added the port configuration info message at the appropriate >> places for TCP 80, 88, 389 ports. I also added the info message at the >> end >> of installation output. Please consider if you agree with this approach. >> >> Tomas > I reworded the commit message, due to the scope of changes made > since the first revision of the patch. > > Tomas Works a lot better, just a few more suggestions: 1. When we fail to retrieve the CA from the remote server we log it but don't print it. I think this would make it clearer why we think this isn't an IPA server. 2. Do we need to print the ports message at the end? If it gets this far then at least ports 80, 88 and 389 are open. I would suggest dropping the last message. I think we should also open a new ticket and do port checks on the things we need so we can confirm it up front instead of one-at-a-time. rob From SteveD at redhat.com Wed Oct 3 17:26:50 2012 From: SteveD at redhat.com (Steve Dickson) Date: Wed, 03 Oct 2012 13:26:50 -0400 Subject: [Freeipa-devel] New Kerberos-related bugzillas In-Reply-To: References: Message-ID: <506C755A.8090909@RedHat.com> Hello, These issues were found at this Fall's Bake-a-ton... On 03/10/12 13:02, Chuck Lever wrote: > > Free IPA does not support weak crypto > https://bugzilla.linux-nfs.org/show_bug.cgi?id=229 > > Confusing debugging output when configuring NFS over Kerberos > https://bugzilla.linux-nfs.org/show_bug.cgi?id=230 Thoughts?? steved. From rcritten at redhat.com Wed Oct 3 17:38:13 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 03 Oct 2012 13:38:13 -0400 Subject: [Freeipa-devel] New Kerberos-related bugzillas In-Reply-To: <506C755A.8090909@RedHat.com> References: <506C755A.8090909@RedHat.com> Message-ID: <506C7805.8040207@redhat.com> Steve Dickson wrote: > Hello, > > These issues were found at this Fall's Bake-a-ton... > > On 03/10/12 13:02, Chuck Lever wrote: >> >> Free IPA does not support weak crypto >> https://bugzilla.linux-nfs.org/show_bug.cgi?id=229 Documented in step 6 at http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/kerb-nfs.html >> Confusing debugging output when configuring NFS over Kerberos >> https://bugzilla.linux-nfs.org/show_bug.cgi?id=230 I'd need to see the Kerberos logs to know what happened with the wrong principal error. At best we can help configure around it but the error itself comes out of krb5. rob From simo at redhat.com Wed Oct 3 17:49:51 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 03 Oct 2012 13:49:51 -0400 Subject: [Freeipa-devel] New Kerberos-related bugzillas In-Reply-To: <506C755A.8090909@RedHat.com> References: <506C755A.8090909@RedHat.com> Message-ID: <1349286591.22373.108.camel@willson.li.ssimo.org> On Wed, 2012-10-03 at 13:26 -0400, Steve Dickson wrote: > Hello, > > These issues were found at this Fall's Bake-a-ton... > > On 03/10/12 13:02, Chuck Lever wrote: > > > > Free IPA does not support weak crypto > > https://bugzilla.linux-nfs.org/show_bug.cgi?id=229 DES support is disabled on purpose, IETF also has an RFC approved that finally says DES *should* not be made available anymore. DES can be cracked in a matter of hours these days which makes its use questionable. DES can be re-enabled manually by twisting a bunch of knobs if you really want to. (including enable weak crypto in krb5.conf) So I would close as NOTABUG. > > Confusing debugging output when configuring NFS over Kerberos > > https://bugzilla.linux-nfs.org/show_bug.cgi?id=230 Not much we (FreeIPA) can do about this one. GSSAPI error codes can be cryptic at time, but they are returned by libgssapi not FreeIPA. Maybe you can add more meat to the debug on the rpc.svcgssd side by printing out what principal you tried to use. If you can identify for sure what causes the error we can open a bug against MIT and see if there is a chance GSSAPI can properly identify the error. Unfortunately it doesn't help that there are many abstraction layers involved here and sometimes error messages get mangled/lost in the process :-/ (Basically KDC errors -> krb5 protocol level error -> libkrb5 level error -> libgssapi level error -> application) Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed Oct 3 18:38:43 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 03 Oct 2012 14:38:43 -0400 Subject: [Freeipa-devel] New Kerberos-related bugzillas In-Reply-To: References: <506C755A.8090909@RedHat.com> <1349286591.22373.108.camel@willson.li.ssimo.org> Message-ID: <1349289523.22373.126.camel@willson.li.ssimo.org> On Wed, 2012-10-03 at 11:03 -0700, Chuck Lever wrote: > On Oct 3, 2012, at 10:49 AM, Simo Sorce wrote: > > > On Wed, 2012-10-03 at 13:26 -0400, Steve Dickson wrote: > >> Hello, > >> > >> These issues were found at this Fall's Bake-a-ton... > >> > >> On 03/10/12 13:02, Chuck Lever wrote: > >>> > >>> Free IPA does not support weak crypto > >>> https://bugzilla.linux-nfs.org/show_bug.cgi?id=229 > > > > DES support is disabled on purpose, IETF also has an RFC approved that > > finally says DES *should* not be made available anymore. > > SHOULD NOT means the IETF acknowledges that there are still legitimate reasons to allow des-crc-cbc in some cases. Yes, that is why DES can still be re-enabled, but is off by default (will eventually be purged completely from MIT libraries though, in due time, but not in RHEL6/7 lifetime I think). > > DES can be cracked in a matter of hours these days which makes its use > > questionable. > > We know that des-crc-cbc is garbage, fwiw. The point is there are > plenty of legacy implementations that have to co-exist with Free IPA > and with implementations that use only known-secure encryption types. Yep, still we do not want to enable DES by default, we have docs for that, see Rob's message. > > DES can be re-enabled manually by twisting a bunch of knobs if you > > really want to. (including enable weak crypto in krb5.conf) > > That wasn't enough for us, it was enabled on both the NFS server and > client. Yes, we could have been "doing it wrong." :-) > > We think backwards compatibility is one reason to continue to make the > use of des-crc-cbc a first-class use case. Sorry, it is simply a too big security liability this days to keep it as a default. RHEL (starting with 6) and Fedora in general have DES support disabled (the default for weak keys is 'false' in krb5.conf) We do not want to prevent you from being able to enable it, but it should be a conscious decision by the admins involved. 'Just works' in this case is a bad trade-off as it means 'We are broken by default'. > > So I would close as NOTABUG. > > > >>> Confusing debugging output when configuring NFS over Kerberos > >>> https://bugzilla.linux-nfs.org/show_bug.cgi?id=230 > > > > Not much we (FreeIPA) can do about this one. GSSAPI error codes can be > > cryptic at time, but they are returned by libgssapi not FreeIPA. > > Maybe you can add more meat to the debug on the rpc.svcgssd side by > > printing out what principal you tried to use. > > If you can identify for sure what causes the error we can open a bug > > against MIT and see if there is a chance GSSAPI can properly identify > > the error. Unfortunately it doesn't help that there are many abstraction > > layers involved here and sometimes error messages get mangled/lost in > > the process :-/ (Basically KDC errors -> krb5 protocol level error -> > > libkrb5 level error -> libgssapi level error -> application) > > Agree, we are trying to document these issues by filing bugs like this one. Note that I fully share your pain, we have the same problem in FreeIPA at times, however the only way to make return messages more clear is to attack them one by one by describing the situation and then hoping GSSAPI/libkrb5/etc can be improved. Unfortunately in some cases the libraries/protocol simply do not have enough information on the 'intentions' of the application to be able to give a better error message. > Thanks for your comments. YW. Simo. -- Simo Sorce * Red Hat, Inc * New York From chucklever at gmail.com Wed Oct 3 18:03:07 2012 From: chucklever at gmail.com (Chuck Lever) Date: Wed, 3 Oct 2012 11:03:07 -0700 Subject: [Freeipa-devel] New Kerberos-related bugzillas In-Reply-To: <1349286591.22373.108.camel@willson.li.ssimo.org> References: <506C755A.8090909@RedHat.com> <1349286591.22373.108.camel@willson.li.ssimo.org> Message-ID: On Oct 3, 2012, at 10:49 AM, Simo Sorce wrote: > On Wed, 2012-10-03 at 13:26 -0400, Steve Dickson wrote: >> Hello, >> >> These issues were found at this Fall's Bake-a-ton... >> >> On 03/10/12 13:02, Chuck Lever wrote: >>> >>> Free IPA does not support weak crypto >>> https://bugzilla.linux-nfs.org/show_bug.cgi?id=229 > > DES support is disabled on purpose, IETF also has an RFC approved that > finally says DES *should* not be made available anymore. SHOULD NOT means the IETF acknowledges that there are still legitimate reasons to allow des-crc-cbc in some cases. > DES can be cracked in a matter of hours these days which makes its use > questionable. We know that des-crc-cbc is garbage, fwiw. The point is there are plenty of legacy implementations that have to co-exist with Free IPA and with implementations that use only known-secure encryption types. > DES can be re-enabled manually by twisting a bunch of knobs if you > really want to. (including enable weak crypto in krb5.conf) That wasn't enough for us, it was enabled on both the NFS server and client. Yes, we could have been "doing it wrong." :-) We think backwards compatibility is one reason to continue to make the use of des-crc-cbc a first-class use case. > So I would close as NOTABUG. > >>> Confusing debugging output when configuring NFS over Kerberos >>> https://bugzilla.linux-nfs.org/show_bug.cgi?id=230 > > Not much we (FreeIPA) can do about this one. GSSAPI error codes can be > cryptic at time, but they are returned by libgssapi not FreeIPA. > Maybe you can add more meat to the debug on the rpc.svcgssd side by > printing out what principal you tried to use. > If you can identify for sure what causes the error we can open a bug > against MIT and see if there is a chance GSSAPI can properly identify > the error. Unfortunately it doesn't help that there are many abstraction > layers involved here and sometimes error messages get mangled/lost in > the process :-/ (Basically KDC errors -> krb5 protocol level error -> > libkrb5 level error -> libgssapi level error -> application) Agree, we are trying to document these issues by filing bugs like this one. Thanks for your comments. -- Chuck Lever chucklever at gmail.com From pspacek at redhat.com Thu Oct 4 07:49:03 2012 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 04 Oct 2012 09:49:03 +0200 Subject: [Freeipa-devel] [PATCH 0072] Fix memory leaks in dynamic update PTR synchronization Message-ID: <506D3F6F.7090705@redhat.com> Hello, Fix memory leaks in dynamic update PTR synchronization. During settings code refactoring I found several ugly memory leaks in sync_ptr handling. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0072-Fix-memory-leaks-in-dynamic-update-PTR-synchronizati.patch Type: text/x-patch Size: 2750 bytes Desc: not available URL: From sbose at redhat.com Thu Oct 4 08:20:18 2012 From: sbose at redhat.com (Sumit Bose) Date: Thu, 4 Oct 2012 10:20:18 +0200 Subject: [Freeipa-devel] [PATCH] 80 Avoid ldapmodify error messages during ipa-adtrust-install Message-ID: <20121004082018.GX6816@localhost.localdomain> Hi, this patch tries to avoid the ldapmodiy error messages during ipa-adtrust-install by checking if the related object already exists. Fixes https://fedorahosted.org/freeipa/ticket/3012 . bye, Sumit -------------- next part -------------- From e2412c162fb4eeab6db280a207002ccba31be2d8 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Thu, 4 Oct 2012 10:15:40 +0200 Subject: [PATCH] Avoid ldapmodify error messages during ipa-adtrust-install Fixes https://fedorahosted.org/freeipa/ticket/3012 --- ipaserver/install/adtrustinstance.py | 60 ++++++++++++++++++++++++++++++------ 1 Datei ge?ndert, 50 Zeilen hinzugef?gt(+), 10 Zeilen entfernt(-) diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py index 8822c2855eff3b9855914679ac7cedd016ea9185..233ef15b5fd3dfde2dadd4665b7f0421e5364e8c 100644 --- a/ipaserver/install/adtrustinstance.py +++ b/ipaserver/install/adtrustinstance.py @@ -324,17 +324,47 @@ class ADTRUSTInstance(service.Service): conf_fd.close() def __add_cldap_module(self): + """ + Add cldap directory server plugin configuration if it not already + exists. + """ try: - self._ldap_mod("ipa-cldap-conf.ldif", self.sub_dict) - except: - pass + cldap_dn = DN(('cn', 'ipa_cldap'), ('cn', 'plugins'), + ('cn', 'config')) + self.admin_conn.getEntry(cldap_dn, ldap.SCOPE_BASE) + self.print_msg('CLDAP plugin already configured, nothing to do') + except errors.NotFound: + try: + self._ldap_mod("ipa-cldap-conf.ldif", self.sub_dict) + except Exception: + pass def __add_sidgen_module(self): + """ + Add sidgen directory server plugin configuration and the related task + if they not already exist. + """ try: - self._ldap_mod("ipa-sidgen-conf.ldif", self.sub_dict) - self._ldap_mod("ipa-sidgen-task-conf.ldif", self.sub_dict) - except Exception: - pass + sidgen_dn = DN(('cn', 'IPA SIDGEN'), ('cn', 'plugins'), + ('cn', 'config')) + self.admin_conn.getEntry(sidgen_dn, ldap.SCOPE_BASE) + self.print_msg('Sidgen plugin already configured, nothing to do') + except errors.NotFound: + try: + self._ldap_mod("ipa-sidgen-conf.ldif", self.sub_dict) + except Exception: + pass + + try: + sidgen_dn = DN(('cn', 'ipa-sidgen-task'), ('cn', 'plugins'), + ('cn', 'config')) + self.admin_conn.getEntry(sidgen_dn, ldap.SCOPE_BASE) + self.print_msg('Sidgen task already configured, nothing to do') + except errors.NotFound: + try: + self._ldap_mod("ipa-sidgen-task-conf.ldif", self.sub_dict) + except Exception: + pass def __add_sids(self): """ @@ -347,10 +377,20 @@ class ADTRUSTInstance(service.Service): pass def __add_extdom_module(self): + """ + Add directory server configuration for the extdom extended operation + if it not already exists. + """ try: - self._ldap_mod("ipa-extdom-extop-conf.ldif", self.sub_dict) - except: - pass + extop_dn = DN(('cn', 'ipa_extdom_extop'), ('cn', 'plugins'), + ('cn', 'config')) + self.admin_conn.getEntry(extop_dn, ldap.SCOPE_BASE) + self.print_msg('Extdom plugin already configured, nothing to do') + except errors.NotFound: + try: + self._ldap_mod("ipa-extdom-extop-conf.ldif", self.sub_dict) + except Exception: + pass def __write_smb_registry(self): template = os.path.join(ipautil.SHARE_DIR, "smb.conf.template") -- 1.7.11.4 From pspacek at redhat.com Thu Oct 4 08:31:24 2012 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 04 Oct 2012 10:31:24 +0200 Subject: [Freeipa-devel] [PATCH 0073] Use NOTAUTH and REFUSED response codes for dynamic updates rather than SERVFAIL Message-ID: <506D495C.8030605@redhat.com> Hello, Use NOTAUTH and REFUSED response codes for dynamic updates rather than SERVFAIL. SERVFAIL is still sent if PTR synchronization is enabled but impossible for some reason. This change should make dynamic updates debugging simpler. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0073-Use-NOTAUTH-and-REFUSED-response-codes-for-dynamic-u.patch Type: text/x-patch Size: 1225 bytes Desc: not available URL: From tbabej at redhat.com Thu Oct 4 09:06:38 2012 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 04 Oct 2012 11:06:38 +0200 Subject: [Freeipa-devel] [PATCH 0016] Adds port to connection error message in ipa-client-install In-Reply-To: <506C7575.20106@redhat.com> References: <5062FD9A.7060802@redhat.com> <50635847.5070602@redhat.com> <5069C48B.8050104@redhat.com> <506B36FF.5050303@redhat.com> <506C3E46.20600@redhat.com> <506C4428.9090903@redhat.com> <506C7575.20106@redhat.com> Message-ID: <506D519E.8090409@redhat.com> On 10/03/2012 07:27 PM, Rob Crittenden wrote: > Tomas Babej wrote: >> On 10/03/2012 03:31 PM, Tomas Babej wrote: >>> On 10/02/2012 08:48 PM, Rob Crittenden wrote: >>>> Tomas Babej wrote: >>>>> On 09/26/2012 09:32 PM, Rob Crittenden wrote: >>>>>> Tomas Babej wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Connection error message in ipa-client-install now warns the user >>>>>>> about the need of opening 389 port for directory server. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/2816 >>>>>>> >>>>>>> I think this can be pushed as a one-liner. >>>>>> >>>>>> I think we should list all ports that are required for client >>>>>> enrollment. >>>>>> >>>>>> From my calculations we need at a minimum tcp ports 80 and 389, >>>>>> either >>>>>> or both udp/tcp for port 88 and if NTP is enabled 123 udp for >>>>>> enrollment alone. The NTP failure won't cause enrollment to fail >>>>>> though, so we may be able to skip that. >>>>>> >>>>>> Similarly 464 should be enabled but we don't use it during >>>>>> enrollment. >>>>>> >>>>>> rob >>>>> I improved the error message. Please check if there are any issues. >>>>> >>>>> Thanks >>>>> >>>>> Tomas >>>> >>>> This only works if port 389 is blocked, not 88 or 80. >>>> >>>> rob >>> I tested and added the port configuration info message at the >>> appropriate >>> places for TCP 80, 88, 389 ports. I also added the info message at the >>> end >>> of installation output. Please consider if you agree with this >>> approach. >>> >>> Tomas >> I reworded the commit message, due to the scope of changes made >> since the first revision of the patch. >> >> Tomas > > Works a lot better, just a few more suggestions: > > 1. When we fail to retrieve the CA from the remote server we log it > but don't print it. I think this would make it clearer why we think > this isn't an IPA server. > > 2. Do we need to print the ports message at the end? If it gets this > far then at least ports 80, 88 and 389 are open. > > I would suggest dropping the last message. I think we should also open > a new ticket and do port checks on the things we need so we can > confirm it up front instead of one-at-a-time. > > rob 1.) Done. 2.) Well I had a feeling it was not really necessary too - it adds a lot to the output of the installation, but the user wouldn't be informed about the need of opening 464 port. However, your proposed ticket should solve this issue, and will give more specific information rather than a general advice. See more: https://fedorahosted.org/freeipa/ticket/3138 I suggest opening a similar ticket for ipa-server-install, at the end we print a general info message about which ports should be open for IPA Server to work properly. Re-using the work done in ticket 3138, we could rather check which particular ports are not opened and therefore give the user more specific information too. Tomas From abokovoy at redhat.com Thu Oct 4 09:13:57 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 4 Oct 2012 12:13:57 +0300 Subject: [Freeipa-devel] [PATCH] 80 Avoid ldapmodify error messages during ipa-adtrust-install In-Reply-To: <20121004082018.GX6816@localhost.localdomain> References: <20121004082018.GX6816@localhost.localdomain> Message-ID: <20121004091357.GK17454@redhat.com> On Thu, 04 Oct 2012, Sumit Bose wrote: >Hi, > >this patch tries to avoid the ldapmodiy error messages during >ipa-adtrust-install by checking if the related object already exists. >Fixes https://fedorahosted.org/freeipa/ticket/3012 . In general -- ACK for the approach. However, I wonder if you could create a helper method that would accept: - ldif file name, - cn component - name of the plugin for the "already configured" message Then every __add_* method would call simply the helper with appropriate arguments. -- / Alexander Bokovoy From sbose at redhat.com Thu Oct 4 09:30:21 2012 From: sbose at redhat.com (Sumit Bose) Date: Thu, 4 Oct 2012 11:30:21 +0200 Subject: [Freeipa-devel] [PATCH] 80 Avoid ldapmodify error messages during ipa-adtrust-install In-Reply-To: <20121004091357.GK17454@redhat.com> References: <20121004082018.GX6816@localhost.localdomain> <20121004091357.GK17454@redhat.com> Message-ID: <20121004093021.GY6816@localhost.localdomain> On Thu, Oct 04, 2012 at 12:13:57PM +0300, Alexander Bokovoy wrote: > On Thu, 04 Oct 2012, Sumit Bose wrote: > >Hi, > > > >this patch tries to avoid the ldapmodiy error messages during > >ipa-adtrust-install by checking if the related object already exists. > >Fixes https://fedorahosted.org/freeipa/ticket/3012 . > In general -- ACK for the approach. However, I wonder if you could create > a helper method that would accept: > - ldif file name, > - cn component > - name of the plugin for the "already configured" message > > Then every __add_* method would call simply the helper with appropriate > arguments. yes, I was thinking about the same, but I preferred this solution for now instead of refactoring the current code. Additionally it would be nice if the helper method would read the DN from the ldif file to make the code more robust. Would you mind to open a trac ticket to refactor this part of the code? bye, Sumit > > -- > / Alexander Bokovoy From abokovoy at redhat.com Thu Oct 4 09:39:07 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 4 Oct 2012 12:39:07 +0300 Subject: [Freeipa-devel] [PATCH] 80 Avoid ldapmodify error messages during ipa-adtrust-install In-Reply-To: <20121004093021.GY6816@localhost.localdomain> References: <20121004082018.GX6816@localhost.localdomain> <20121004091357.GK17454@redhat.com> <20121004093021.GY6816@localhost.localdomain> Message-ID: <20121004093907.GL17454@redhat.com> On Thu, 04 Oct 2012, Sumit Bose wrote: >On Thu, Oct 04, 2012 at 12:13:57PM +0300, Alexander Bokovoy wrote: >> On Thu, 04 Oct 2012, Sumit Bose wrote: >> >Hi, >> > >> >this patch tries to avoid the ldapmodiy error messages during >> >ipa-adtrust-install by checking if the related object already exists. >> >Fixes https://fedorahosted.org/freeipa/ticket/3012 . >> In general -- ACK for the approach. However, I wonder if you could create >> a helper method that would accept: >> - ldif file name, >> - cn component >> - name of the plugin for the "already configured" message >> >> Then every __add_* method would call simply the helper with appropriate >> arguments. > >yes, I was thinking about the same, but I preferred this solution for >now instead of refactoring the current code. Additionally it would be >nice if the helper method would read the DN from the ldif file to make >the code more robust. Would you mind to open a trac ticket to refactor >this part of the code? I would disagree here. Reading DN from ldif file adds complexity for no real gain. Refactoring this code is really simple -- your patch did already introduced bigger change than that refactoring would make. If you aren't comfort with this suggestion, I can make the change myself. Having these repeated patterns is hurting my eyes :) -- / Alexander Bokovoy From sbose at redhat.com Thu Oct 4 09:43:27 2012 From: sbose at redhat.com (Sumit Bose) Date: Thu, 4 Oct 2012 11:43:27 +0200 Subject: [Freeipa-devel] [PATCH] 81 ipa-adtrust-install: remove wrong check for dm_password Message-ID: <20121004094327.GZ6816@localhost.localdomain> Hi, this patch fixes unattended installation for ipa-adtrust-install and ticket https://fedorahosted.org/freeipa/ticket/3023 . bye, Sumit -------------- next part -------------- From 4a4532e8d57cf76c39f2d9483683edee01648f2f Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Thu, 4 Oct 2012 11:37:45 +0200 Subject: [PATCH] ipa-adtrust-install: remove wrong check for dm_password Additionally this patch removes a comment which makes no sense at this place anymore. Fixes https://fedorahosted.org/freeipa/ticket/3023 --- install/tools/ipa-adtrust-install | 4 ---- 1 Datei ge?ndert, 4 Zeilen entfernt(-) diff --git a/install/tools/ipa-adtrust-install b/install/tools/ipa-adtrust-install index f50bb58213ac0681cd8bda0a449ae21c48e6adb8..52179038e84a08ea6abb3ee26d8e668efe0a2b13 100755 --- a/install/tools/ipa-adtrust-install +++ b/install/tools/ipa-adtrust-install @@ -197,10 +197,6 @@ def main(): print "Please wait until the prompt is returned." print "" - # Create a Adtrust instance - if options.unattended and not options.dm_password: - sys.exit("\nIn unattended mode you need to provide at least the -p option") - netbios_name = options.netbios_name if not netbios_name: netbios_name = adtrustinstance.make_netbios_name(api.env.domain) -- 1.7.11.4 From abokovoy at redhat.com Thu Oct 4 09:54:20 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 4 Oct 2012 12:54:20 +0300 Subject: [Freeipa-devel] [PATCH] 81 ipa-adtrust-install: remove wrong check for dm_password In-Reply-To: <20121004094327.GZ6816@localhost.localdomain> References: <20121004094327.GZ6816@localhost.localdomain> Message-ID: <20121004095420.GM17454@redhat.com> On Thu, 04 Oct 2012, Sumit Bose wrote: >Hi, > >this patch fixes unattended installation for ipa-adtrust-install and >ticket https://fedorahosted.org/freeipa/ticket/3023 . ACK. Thanks! -- / Alexander Bokovoy From sbose at redhat.com Thu Oct 4 10:26:02 2012 From: sbose at redhat.com (Sumit Bose) Date: Thu, 4 Oct 2012 12:26:02 +0200 Subject: [Freeipa-devel] [PATCH] 80 Avoid ldapmodify error messages during ipa-adtrust-install In-Reply-To: <20121004093907.GL17454@redhat.com> References: <20121004082018.GX6816@localhost.localdomain> <20121004091357.GK17454@redhat.com> <20121004093021.GY6816@localhost.localdomain> <20121004093907.GL17454@redhat.com> Message-ID: <20121004102602.GB6816@localhost.localdomain> On Thu, Oct 04, 2012 at 12:39:07PM +0300, Alexander Bokovoy wrote: > On Thu, 04 Oct 2012, Sumit Bose wrote: > >On Thu, Oct 04, 2012 at 12:13:57PM +0300, Alexander Bokovoy wrote: > >>On Thu, 04 Oct 2012, Sumit Bose wrote: > >>>Hi, > >>> > >>>this patch tries to avoid the ldapmodiy error messages during > >>>ipa-adtrust-install by checking if the related object already exists. > >>>Fixes https://fedorahosted.org/freeipa/ticket/3012 . > >>In general -- ACK for the approach. However, I wonder if you could create > >>a helper method that would accept: > >> - ldif file name, > >> - cn component > >> - name of the plugin for the "already configured" message > >> > >>Then every __add_* method would call simply the helper with appropriate > >>arguments. > > > >yes, I was thinking about the same, but I preferred this solution for > >now instead of refactoring the current code. Additionally it would be > >nice if the helper method would read the DN from the ldif file to make > >the code more robust. Would you mind to open a trac ticket to refactor > >this part of the code? > I would disagree here. Reading DN from ldif file adds complexity for no > real gain. > > Refactoring this code is really simple -- your patch did already > introduced bigger change than that refactoring would make. > > If you aren't comfort with this suggestion, I can make the change > myself. Having these repeated patterns is hurting my eyes :) new version attached. bye, Sumit > > -- > / Alexander Bokovoy -------------- next part -------------- From f304c9ac9a1e1c46661531780f771409c7a2647c Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Thu, 4 Oct 2012 10:15:40 +0200 Subject: [PATCH] Avoid ldapmodify error messages during ipa-adtrust-install Fixes https://fedorahosted.org/freeipa/ticket/3012 --- ipaserver/install/adtrustinstance.py | 47 ++++++++++++++++++++++++++---------- 1 Datei ge?ndert, 34 Zeilen hinzugef?gt(+), 13 Zeilen entfernt(-) diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py index 8822c2855eff3b9855914679ac7cedd016ea9185..7bfb6076d7ef5d4f6c16df85c64252d0aad062df 100644 --- a/ipaserver/install/adtrustinstance.py +++ b/ipaserver/install/adtrustinstance.py @@ -323,18 +323,37 @@ class ADTRUSTInstance(service.Service): conf_fd.write('config backend = registry\n') conf_fd.close() + def __add_plugin_conf(self, name, plugin_cn, ldif_file): + """ + Add directory server plugin configuration if it not already + exists. + """ + try: + plugin_dn = DN(('cn', plugin_cn), ('cn', 'plugins'), + ('cn', 'config')) + self.admin_conn.getEntry(plugin_dn, ldap.SCOPE_BASE) + self.print_msg('%s plugin already configured, nothing to do' % name) + except errors.NotFound: + try: + self._ldap_mod(ldif_file, self.sub_dict) + except Exception: + pass + def __add_cldap_module(self): - try: - self._ldap_mod("ipa-cldap-conf.ldif", self.sub_dict) - except: - pass + """ + Add cldap directory server plugin configuration if it not already + exists. + """ + self.__add_plugin_conf('CLDAP', 'ipa_cldap', 'ipa-cldap-conf.ldif') def __add_sidgen_module(self): - try: - self._ldap_mod("ipa-sidgen-conf.ldif", self.sub_dict) - self._ldap_mod("ipa-sidgen-task-conf.ldif", self.sub_dict) - except Exception: - pass + """ + Add sidgen directory server plugin configuration and the related task + if they not already exist. + """ + self.__add_plugin_conf('Sidgen', 'IPA SIDGEN', 'ipa-sidgen-conf.ldif') + self.__add_plugin_conf('Sidgen task', 'ipa-sidgen-task', + 'ipa-sidgen-task-conf.ldif') def __add_sids(self): """ @@ -347,10 +366,12 @@ class ADTRUSTInstance(service.Service): pass def __add_extdom_module(self): - try: - self._ldap_mod("ipa-extdom-extop-conf.ldif", self.sub_dict) - except: - pass + """ + Add directory server configuration for the extdom extended operation + if it not already exists. + """ + self.__add_plugin_conf('Extdom', 'ipa_extdom_extop', + 'ipa-extdom-extop-conf.ldif') def __write_smb_registry(self): template = os.path.join(ipautil.SHARE_DIR, "smb.conf.template") -- 1.7.11.4 From sbose at redhat.com Thu Oct 4 10:49:42 2012 From: sbose at redhat.com (Sumit Bose) Date: Thu, 4 Oct 2012 12:49:42 +0200 Subject: [Freeipa-devel] [PATCH] 82 ipa-adtrust-install: print list of needed SRV records Message-ID: <20121004104942.GC6816@localhost.localdomain> Hi, this patch should fix the reopend https://fedorahosted.org/freeipa/ticket/3019 . bye, Sumit -------------- next part -------------- From 4bd788af75f04371e6f8b974340433b41bd4f8e2 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Thu, 4 Oct 2012 12:40:33 +0200 Subject: [PATCH] ipa-adtrust-install: print list of needed SRV records If --no-msdcs is given on the command line all needed SRV records will be printed. Fixes https://fedorahosted.org/freeipa/ticket/3019 --- ipaserver/install/adtrustinstance.py | 22 +++++++++++++--------- 1 Datei ge?ndert, 13 Zeilen hinzugef?gt(+), 9 Zeilen entfernt(-) diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py index 7bfb6076d7ef5d4f6c16df85c64252d0aad062df..d99c880d4980a2a8cf8810ff1311d80803c523e1 100644 --- a/ipaserver/install/adtrustinstance.py +++ b/ipaserver/install/adtrustinstance.py @@ -439,13 +439,18 @@ class ADTRUSTInstance(service.Service): ".dc._msdcs") err_msg = None - ret = api.Command['dns_is_enabled']() - if not ret['result']: - err_msg = "DNS management was not enabled at install time." + + if self.no_msdcs: + err_msg = '--no-msdcs was given, special DNS service records ' \ + 'are not added to local DNS server' else: - if not dns_zone_exists(zone): - err_msg = "DNS zone %s cannot be managed " \ - "as it is not defined in IPA" % zone + ret = api.Command['dns_is_enabled']() + if not ret['result']: + err_msg = "DNS management was not enabled at install time." + else: + if not dns_zone_exists(zone): + err_msg = "DNS zone %s cannot be managed " \ + "as it is not defined in IPA" % zone if err_msg: self.print_msg(err_msg) @@ -696,9 +701,8 @@ class ADTRUSTInstance(service.Service): self.step("activating sidgen plugin and task", self.__add_sidgen_module) self.step("activating extdom plugin", self.__add_extdom_module) self.step("configuring smbd to start on boot", self.__enable) - if not self.no_msdcs: - self.step("adding special DNS service records", \ - self.__add_dns_service_records) + self.step("adding special DNS service records", \ + self.__add_dns_service_records) self.step("restarting Directory Server to take MS PAC and LDAP plugins changes into account", \ self.__restart_dirsrv) self.step("setting SELinux booleans", \ -- 1.7.11.4 From abokovoy at redhat.com Thu Oct 4 10:54:42 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 4 Oct 2012 13:54:42 +0300 Subject: [Freeipa-devel] [PATCH] 80 Avoid ldapmodify error messages during ipa-adtrust-install In-Reply-To: <20121004102602.GB6816@localhost.localdomain> References: <20121004082018.GX6816@localhost.localdomain> <20121004091357.GK17454@redhat.com> <20121004093021.GY6816@localhost.localdomain> <20121004093907.GL17454@redhat.com> <20121004102602.GB6816@localhost.localdomain> Message-ID: <20121004105442.GN17454@redhat.com> On Thu, 04 Oct 2012, Sumit Bose wrote: >On Thu, Oct 04, 2012 at 12:39:07PM +0300, Alexander Bokovoy wrote: >> On Thu, 04 Oct 2012, Sumit Bose wrote: >> >On Thu, Oct 04, 2012 at 12:13:57PM +0300, Alexander Bokovoy wrote: >> >>On Thu, 04 Oct 2012, Sumit Bose wrote: >> >>>Hi, >> >>> >> >>>this patch tries to avoid the ldapmodiy error messages during >> >>>ipa-adtrust-install by checking if the related object already exists. >> >>>Fixes https://fedorahosted.org/freeipa/ticket/3012 . >> >>In general -- ACK for the approach. However, I wonder if you could create >> >>a helper method that would accept: >> >> - ldif file name, >> >> - cn component >> >> - name of the plugin for the "already configured" message >> >> >> >>Then every __add_* method would call simply the helper with appropriate >> >>arguments. >> > >> >yes, I was thinking about the same, but I preferred this solution for >> >now instead of refactoring the current code. Additionally it would be >> >nice if the helper method would read the DN from the ldif file to make >> >the code more robust. Would you mind to open a trac ticket to refactor >> >this part of the code? >> I would disagree here. Reading DN from ldif file adds complexity for no >> real gain. >> >> Refactoring this code is really simple -- your patch did already >> introduced bigger change than that refactoring would make. >> >> If you aren't comfort with this suggestion, I can make the change >> myself. Having these repeated patterns is hurting my eyes :) > >new version attached. ACK. Thanks! -- / Alexander Bokovoy From mkosek at redhat.com Thu Oct 4 11:08:15 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 04 Oct 2012 13:08:15 +0200 Subject: [Freeipa-devel] [PATCH] 81 ipa-adtrust-install: remove wrong check for dm_password In-Reply-To: <20121004095420.GM17454@redhat.com> References: <20121004094327.GZ6816@localhost.localdomain> <20121004095420.GM17454@redhat.com> Message-ID: <506D6E1F.50702@redhat.com> On 10/04/2012 11:54 AM, Alexander Bokovoy wrote: > On Thu, 04 Oct 2012, Sumit Bose wrote: >> Hi, >> >> this patch fixes unattended installation for ipa-adtrust-install and >> ticket https://fedorahosted.org/freeipa/ticket/3023 . > ACK. Thanks! > Pushed to master, ipa-3-0. Martin From mkosek at redhat.com Thu Oct 4 11:34:19 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 04 Oct 2012 13:34:19 +0200 Subject: [Freeipa-devel] [PATCH] 0079 support creating LDAP control by python-ldap 2.3 (RHEL) and newer versions (Fedora) In-Reply-To: <20120925143049.GL17454@redhat.com> References: <20120925143049.GL17454@redhat.com> Message-ID: <506D743B.2000203@redhat.com> On 09/25/2012 04:30 PM, Alexander Bokovoy wrote: > Hi, > > I did have bug filed against python-ldap in January and for some reason > my patch to accomodate two ways of making LDAP controls was not included > in March 2012 when I presented it as part of trusts, but yesterday we > found it is really needed for RHEL6 version of python-ldap. > > Rather than having separate patch, I'd prefer to have both versions > supported upstream. The same issue was with Fedora 16 versus Fedora 17. > Tested on F17 and RHEL 6.3 and it works fine on both systems (and Python versions). ACK if you change +except: to +except ImportError: Martin From atkac at redhat.com Thu Oct 4 11:41:29 2012 From: atkac at redhat.com (Adam Tkac) Date: Thu, 4 Oct 2012 13:41:29 +0200 Subject: [Freeipa-devel] [PATCH 0073] Use NOTAUTH and REFUSED response codes for dynamic updates rather than SERVFAIL In-Reply-To: <506D495C.8030605@redhat.com> References: <506D495C.8030605@redhat.com> Message-ID: <20121004114126.GA3868@redhat.com> On Thu, Oct 04, 2012 at 10:31:24AM +0200, Petr Spacek wrote: > Hello, > > Use NOTAUTH and REFUSED response codes for dynamic updates rather > than SERVFAIL. > > SERVFAIL is still sent if PTR synchronization is enabled but > impossible for some reason. > > This change should make dynamic updates debugging simpler. Ack > From bff8bc688c61717df67de2968492f76b4be65d2a Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Thu, 4 Oct 2012 10:26:38 +0200 > Subject: [PATCH] Use NOTAUTH and REFUSED response codes for dynamic updates > rather than SERVFAIL. > > SERVFAIL is still sent if PTR synchronization is enabled but > impossible for some reason. > > Signed-off-by: Petr Spacek > --- > src/ldap_helper.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index a7f492e1169c36a321c240fd6ff321a9ef63c2c4..24d469a562b96176ac8fffcf443b9b063096d58c 100644 > --- a/src/ldap_helper.c > +++ b/src/ldap_helper.c > @@ -2525,7 +2525,7 @@ modify_ldap_common(dns_name_t *owner, ldap_instance_t *ldap_inst, > entry = HEAD(ldap_qresult->ldap_entries); > if (entry == NULL) { > log_debug(3, "Active zone %s not found", zone_dn); > - result = ISC_R_NOTFOUND; > + result = DNS_R_NOTAUTH; > goto cleanup; > } > > @@ -2537,7 +2537,7 @@ modify_ldap_common(dns_name_t *owner, ldap_instance_t *ldap_inst, > > if (!zone_dyn_update) { > log_debug(3, "Dynamic Update is not allowed in zone %s", zone_dn); > - result = ISC_R_NOPERM; > + result = DNS_R_REFUSED; > goto cleanup; > } > > -- > 1.7.11.4 > -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Thu Oct 4 11:44:46 2012 From: atkac at redhat.com (Adam Tkac) Date: Thu, 4 Oct 2012 13:44:46 +0200 Subject: [Freeipa-devel] [PATCH 0072] Fix memory leaks in dynamic update PTR synchronization In-Reply-To: <506D3F6F.7090705@redhat.com> References: <506D3F6F.7090705@redhat.com> Message-ID: <20121004114443.GB3868@redhat.com> On Thu, Oct 04, 2012 at 09:49:03AM +0200, Petr Spacek wrote: > Hello, > > Fix memory leaks in dynamic update PTR synchronization. > > During settings code refactoring I found several ugly memory leaks > in sync_ptr handling. Ack > From 690008eb1fb6f340c735150f21a8d30a244e14bf Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Thu, 4 Oct 2012 09:46:25 +0200 > Subject: [PATCH] Fix memory leaks in dynamic update PTR synchronization. > > Signed-off-by: Petr Spacek > --- > src/ldap_helper.c | 12 ++++++++---- > 1 file changed, 8 insertions(+), 4 deletions(-) > > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index 629c76732c86af2a614e589a5afff18136068a66..a7f492e1169c36a321c240fd6ff321a9ef63c2c4 100644 > --- a/src/ldap_helper.c > +++ b/src/ldap_helper.c > @@ -2496,11 +2496,16 @@ modify_ldap_common(dns_name_t *owner, ldap_instance_t *ldap_inst, > isc_boolean_t zone_sync_ptr = ldap_inst->sync_ptr; > ld_string_t *owner_dn_ptr = NULL; > char *attrs[] = {"idnsAllowSyncPTR", "idnsAllowDynUpdate", NULL}; > + ld_string_t *str_ptr = NULL; > + ldapdb_rdatalist_t rdlist_search; > + dns_rdatalist_t *rdlist_ptr = NULL; > + char **vals = NULL; > > /* > * Find parent zone entry and check if Dynamic Update is allowed. > * @todo Try the cache first and improve split: SOA records are problematic. > */ > + ISC_LIST_INIT(rdlist_search); > CHECK(str_new(mctx, &owner_dn)); > CHECK(dnsname_to_dn(ldap_inst->zone_register, owner, owner_dn)); > char *zone_dn = strstr(str_buf(owner_dn),", "); > @@ -2606,8 +2611,6 @@ modify_ldap_common(dns_name_t *owner, ldap_instance_t *ldap_inst, > CHECK(dns_byaddr_createptrname2(&isc_ip, 0, dns_fixedname_name(&name))); > > /* Find PTR entry in LDAP. */ > - ldapdb_rdatalist_t rdlist_search; > - dns_rdatalist_t *rdlist_ptr = NULL; > result = ldapdb_rdatalist_get(mctx, ldap_inst, dns_fixedname_name(&name), > NULL, &rdlist_search); > > @@ -2682,7 +2685,6 @@ modify_ldap_common(dns_name_t *owner, ldap_instance_t *ldap_inst, > * > * @example str_ptr = "host.example.com." > */ > - ld_string_t *str_ptr = NULL; > CHECK(str_new(mctx, &str_ptr)); > CHECK(dn_to_text(str_buf(owner_dn), str_ptr, NULL)); > > @@ -2699,7 +2701,6 @@ modify_ldap_common(dns_name_t *owner, ldap_instance_t *ldap_inst, > * > */ > if (mod_op == LDAP_MOD_DELETE) { > - char **vals = NULL; > CHECK(ldap_rdata_to_char_array(mctx, HEAD(rdlist_ptr->rdata), &vals)); > if (vals != NULL && vals[0] != NULL && strcmp(vals[0], str_buf(str_ptr)) != 0) { > log_debug(3,"Cannot delete PTR record, unexpected value found " > @@ -2746,9 +2747,12 @@ cleanup: > ldap_pool_putconnection(ldap_inst->pool, &ldap_conn); > str_destroy(&owner_dn_ptr); > str_destroy(&owner_dn); > + str_destroy(&str_ptr); > free_ldapmod(mctx, &change[0]); > free_ldapmod(mctx, &change[1]); > if (change_ptr != NULL) free_ldapmod(mctx, &change_ptr); > + ldapdb_rdatalist_destroy(mctx, &rdlist_search); > + free_char_array(mctx, &vals); > > return result; > } > -- > 1.7.11.4 > -- Adam Tkac, Red Hat, Inc. From abokovoy at redhat.com Thu Oct 4 14:48:48 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 4 Oct 2012 17:48:48 +0300 Subject: [Freeipa-devel] [PATCH] 0079 support creating LDAP control by python-ldap 2.3 (RHEL) and newer versions (Fedora) In-Reply-To: <506D743B.2000203@redhat.com> References: <20120925143049.GL17454@redhat.com> <506D743B.2000203@redhat.com> Message-ID: <20121004144848.GO17454@redhat.com> On Thu, 04 Oct 2012, Martin Kosek wrote: >On 09/25/2012 04:30 PM, Alexander Bokovoy wrote: >> Hi, >> >> I did have bug filed against python-ldap in January and for some reason >> my patch to accomodate two ways of making LDAP controls was not included >> in March 2012 when I presented it as part of trusts, but yesterday we >> found it is really needed for RHEL6 version of python-ldap. >> >> Rather than having separate patch, I'd prefer to have both versions >> supported upstream. The same issue was with Fedora 16 versus Fedora 17. >> > >Tested on F17 and RHEL 6.3 and it works fine on both systems (and Python versions). > >ACK if you change > >+except: > >to > >+except ImportError: Change attached. -- / Alexander Bokovoy -------------- next part -------------- >From 535254d041451eb14442b93142f7574779e492e2 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 25 Sep 2012 17:23:33 +0300 Subject: [PATCH 1/3] Support python-ldap 2.3 way of making LDAP control This strange patch is to accomodate both python-ldap 2.3 and later versions. There was refactoring in python-ldap support for LDAP controls that split base class into two different, changing properties and method signatures. Luckily, we don't use any values passed to encodeControlValue. --- ipaserver/dcerpc.py | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index cbe28753d4ba9487165c6b9ed1721541b6fa00bf..e7b41e6d8f1922ccabef8a61bad3ff50534fa406 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -40,8 +40,12 @@ from samba.ndr import ndr_pack from samba import net import samba import random -import ldap as _ldap from Crypto.Cipher import ARC4 +try: + from ldap.controls import RequestControl as LDAPControl #pylint: disable=F0401 +except ImportError: + from ldap.controls import LDAPControl as LDAPControl #pylint: disable=F0401 +import ldap as _ldap __doc__ = _(""" Classes to manage trust joins using DCE-RPC calls @@ -81,13 +85,17 @@ def assess_dcerpc_exception(num=None,message=None): message "%(message)s" (both may be "None")''') % dict(num=num, message=message) return errors.RemoteRetrieveError(reason=reason) -class ExtendedDNControl(_ldap.controls.RequestControl): +class ExtendedDNControl(LDAPControl): + # This class attempts to implement LDAP control that would work + # with both python-ldap 2.4.x and 2.3.x, thus there is mix of properties + # from both worlds and encodeControlValue has default parameter def __init__(self): + self.controlValue = 1 self.controlType = "1.2.840.113556.1.4.529" self.criticality = False self.integerValue = 1 - def encodeControlValue(self): + def encodeControlValue(self, value=None): return '0\x03\x02\x01\x01' class DomainValidator(object): -- 1.7.12 From mkosek at redhat.com Thu Oct 4 15:02:09 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 04 Oct 2012 17:02:09 +0200 Subject: [Freeipa-devel] [PATCH] 0079 support creating LDAP control by python-ldap 2.3 (RHEL) and newer versions (Fedora) In-Reply-To: <20121004144848.GO17454@redhat.com> References: <20120925143049.GL17454@redhat.com> <506D743B.2000203@redhat.com> <20121004144848.GO17454@redhat.com> Message-ID: <506DA4F1.4060107@redhat.com> On 10/04/2012 04:48 PM, Alexander Bokovoy wrote: > On Thu, 04 Oct 2012, Martin Kosek wrote: >> On 09/25/2012 04:30 PM, Alexander Bokovoy wrote: >>> Hi, >>> >>> I did have bug filed against python-ldap in January and for some reason >>> my patch to accomodate two ways of making LDAP controls was not included >>> in March 2012 when I presented it as part of trusts, but yesterday we >>> found it is really needed for RHEL6 version of python-ldap. >>> >>> Rather than having separate patch, I'd prefer to have both versions >>> supported upstream. The same issue was with Fedora 16 versus Fedora 17. >>> >> >> Tested on F17 and RHEL 6.3 and it works fine on both systems (and Python >> versions). >> >> ACK if you change >> >> +except: >> >> to >> >> +except ImportError: > Change attached. ACK. Pushed to master, ipa-3-0. Martin From abokovoy at redhat.com Thu Oct 4 15:06:13 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 4 Oct 2012 18:06:13 +0300 Subject: [Freeipa-devel] [PATCH] 0082/0083 Handle NotFound exception when establishing trust Message-ID: <20121004150613.GP17454@redhat.com> Hi, two attached patches attempt to solve https://fedorahosted.org/freeipa/ticket/3103 We cannot make educated guess where trusted domain's DNS server is located as we ended up with NotFound exception precisely because we were unable to discover trusted domain's domain controller location. Thus, all we can do is to suggest ways to fix the issue. Since suggestion becomes relatively long (multi-line, at least), it creates few issues for current exception error message handling: - root_logger does not use textui to format output - textui is only printing to standard output - multi-line error messages thus become non-wrapped - localizing such messages would become a harder context-wise. Web UI is showing error message as a single paragraph (

), all multi-line markup would be lost. In the end, I decided to support list-based multi-line error messages in PublicError class. Its constructor will join all list-based arguments into single string per argument (first patch). In Web UI I've added special text processing of error messages that splits message into multiple lines and wraps those which start with a TAB symbol into 'error-message-hinted' span to visually separate it from the rest of error message. Trust code uses this to display suggested CLI command to set up DNS forwarder (second patch). In the end, CLI shows such error message fine (note tabulated CLI command): ----------------------------------------------------------------------- # ipa trust-add --type=ad --admin Administrator at ad.local1 --password ad.local1 Active directory domain administrator's password: ipa: ERROR: Unable to resolve domain controller for 'ad.local1' domain. IPA manages DNS, please configure forwarder to 'ad.local1' domain by using following CLI command. Please replace DNS_SERVER and IP_ADDRESS by name and address of the domain's name server: ipa dnszone-add ad.local1 --name-server=DNS_SERVER --admin-email='hostmaster at ad.local1' --force --forwarder=IP_ADDRESS --forward-policy=only When using Web UI, please create DNS zone for domain 'ad.local1' first and then set forwarder and forward policy ----------------------------------------------------------------------- Web UI looks like this: http://abbra.fedorapeople.org/.paste/ui.png -- / Alexander Bokovoy -------------- next part -------------- >From 9916c6cf35e93c4ad80b1b426785e908cf34d0db Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 4 Oct 2012 15:05:17 +0300 Subject: [PATCH 2/3] support multi-line error messages in exceptions part of fix for https://fedorahosted.org/freeipa/ticket/3103 --- install/ui/ipa.css | 9 ++++++++- install/ui/ipa.js | 14 +++++++++++++- ipalib/errors.py | 12 +++++++++--- 3 files changed, 30 insertions(+), 5 deletions(-) diff --git a/install/ui/ipa.css b/install/ui/ipa.css index c8a220e78430fd38a1781be63421babaadafc948..3146e115524a6672b80e44956710a92bba79af0a 100644 --- a/install/ui/ipa.css +++ b/install/ui/ipa.css @@ -1113,6 +1113,13 @@ table.kerberos-key-status { background-color: #daa520; } +.error-message-hinted { + color: red; + padding-top: 0.5em; + padding-bottom: 0.5em; + font-family: monospace; +} + /* ---- Table ---- */ table.scrollable thead { @@ -1755,4 +1762,4 @@ form#login { .choice-header { font-weight: bold; -} \ No newline at end of file +} diff --git a/install/ui/ipa.js b/install/ui/ipa.js index bd25aeae2b4ff53f928b6fbd7429109fa9c55f68..11ca391861c8caa5b7f29facf36afd555dcd12d7 100644 --- a/install/ui/ipa.js +++ b/install/ui/ipa.js @@ -762,6 +762,18 @@ IPA.command = function(spec) { } } + function beautify_text(text) { + lines = text.split(/\n/g); + for(var i=0; i'; + } + } + return lines.join('
\n'); + } + function success_handler(data, text_status, xhr) { if (!data) { @@ -783,7 +795,7 @@ IPA.command = function(spec) { error_handler.call(this, xhr, text_status, /* error_thrown */ { name: IPA.get_message('errors.ipa_error', 'IPA Error')+' '+data.error.code, code: data.error.code, - message: data.error.message, + message: beautify_text(data.error.message), data: data }); diff --git a/ipalib/errors.py b/ipalib/errors.py index 7bf267290b484ed9570f1c7efdb606628fb5f11d..7f1113200b6b2cd80ea9156d347211e4d978b9be 100644 --- a/ipalib/errors.py +++ b/ipalib/errors.py @@ -265,11 +265,17 @@ class PublicError(StandardError): ) self.format = format self.forwarded = False - self.msg = self.format % kw + def convert_keyword(value): + if isinstance(value, list): + result=u'\n'.join(map(lambda line: unicode(line), value)) + return result + return value + kwargs = dict(map(lambda (k,v): (k, convert_keyword(v)), kw.items())) + self.msg = self.format % kwargs if isinstance(self.format, basestring): - self.strerror = ugettext(self.format) % kw + self.strerror = ugettext(self.format) % kwargs else: - self.strerror = self.format % kw + self.strerror = self.format % kwargs else: if isinstance(message, (Gettext, NGettext)): message = unicode(message) -- 1.7.12 -------------- next part -------------- >From 9fa8b25e21b2a4f240292751ae0ea21eb6e2432f Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 4 Oct 2012 17:40:05 +0300 Subject: [PATCH 3/3] Handle NotFound exception when establishing trust Establishing trust implies discovery of the trusted domain's domain controller via DNS. If DNS discovery is not possible, NotFound exception is raised. Intercept the exception and process it to help diagnose and fix actual problem: - if IPA is managing DNS, suggest to make a forward for the domain's zone - otherwise suggest to setup DNS forwarder at upstream DNS server https://fedorahosted.org/freeipa/ticket/3103 --- ipalib/plugins/trust.py | 34 +++++++++++++++++++++++++++++++--- 1 file changed, 31 insertions(+), 3 deletions(-) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index 9d3e9a873e8f6335c12729e9f9475e59499fb3d4..28e0a7dbb7ae330017d48d290e284d17007e5b00 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -18,6 +18,7 @@ # along with this program. If not, see . from ipalib.plugins.baseldap import * +from ipalib.plugins.dns import dns_container_exists from ipalib import api, Str, StrEnum, Password, DefaultFrom, _, ngettext, Object from ipalib.parameters import Enum from ipalib import Command @@ -325,10 +326,36 @@ class trust_add(LDAPCreate): raise errors.ValidationError(name=_('AD Trust setup'), error=_('Realm administrator password should be specified')) realm_passwd = options['realm_passwd'] - result = trustinstance.join_ad_full_credentials(keys[-1], realm_server, realm_admin, realm_passwd) + try: + result = trustinstance.join_ad_full_credentials(keys[-1], realm_server, realm_admin, realm_passwd) + except errors.NotFound, e: + error_message=[_("Unable to resolve domain controller for '%s' domain. ") % (keys[-1])] + if dns_container_exists(self.obj.backend): + try: + dns_zone = api.Command.dnszone_show(keys[-1])['result'] + if ('idnsforwardpolicy' in dns_zone) and dns_zone['idnsforwardpolicy'][0] == u'only': + error_message.append(_("Forward policy is defined for it in IPA DNS, " + "perhaps forwarder points to incorrect host?")) + except (errors.NotFound, KeyError) as e: + error_message.append(_("IPA manages DNS, please configure forwarder to " + "'%(domain)s' domain using following CLI command:") % dict(domain=keys[-1])) + # tab character at the beginning of a multiline error message will be replaced + # in the web UI by a colorful hint. Does not affect CLI. + error_message.append(_("\tipa dnszone-add %(domain)s --name-server=[DNS_SERVER] " + "--admin-email='hostmaster@%(domain)s' " + "--force --forwarder=[DNS_SERVER IP ADDRESS] " + "--forward-policy=only") % dict(domain=keys[-1])) + error_message.append(_("When using Web UI, please create DNS zone for domain '%(domain)s' " + "first and then set forwarder and forward policy.") % dict(domain=keys[-1])) + else: + error_message.append(_("Since IPA does not manage DNS records, ensure DNS " + "is configured to resolve '%(domain)s' domain from " + "IPA hosts and back.") % dict(domain=keys[-1])) + raise errors.NotFound(reason=error_message) if result is None: - raise errors.ValidationError(name=_('AD Trust setup'), error=_('Unable to verify write permissions to the AD')) + raise errors.ValidationError(name=_('AD Trust setup'), + error=_('Unable to verify write permissions to the AD')) return dict(value=trustinstance.remote_domain.info['dns_domain'], verified=result['verified']) @@ -338,7 +365,8 @@ class trust_add(LDAPCreate): if 'trust_secret' in options: result = trustinstance.join_ad_ipa_half(keys[-1], realm_server, options['trust_secret']) return dict(value=trustinstance.remote_domain.info['dns_domain'], verified=result['verified']) - raise errors.ValidationError(name=_('AD Trust setup'), error=_('Not enough arguments specified to perform trust setup')) + raise errors.ValidationError(name=_('AD Trust setup'), + error=_('Not enough arguments specified to perform trust setup')) class trust_del(LDAPDelete): __doc__ = _('Delete a trust.') -- 1.7.12 From pspacek at redhat.com Thu Oct 4 16:04:27 2012 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 04 Oct 2012 18:04:27 +0200 Subject: [Freeipa-devel] [PATCH 0073] Use NOTAUTH and REFUSED response codes for dynamic updates rather than SERVFAIL In-Reply-To: <20121004114126.GA3868@redhat.com> References: <506D495C.8030605@redhat.com> <20121004114126.GA3868@redhat.com> Message-ID: <506DB38B.3040605@redhat.com> On 10/04/2012 01:41 PM, Adam Tkac wrote: > On Thu, Oct 04, 2012 at 10:31:24AM +0200, Petr Spacek wrote: >> Hello, >> >> Use NOTAUTH and REFUSED response codes for dynamic updates rather >> than SERVFAIL. >> >> SERVFAIL is still sent if PTR synchronization is enabled but >> impossible for some reason. >> >> This change should make dynamic updates debugging simpler. > > Ack Pushed to master: bf2f5dd5f9ea452aa415f53ed127070e164f2170 Petr^2 Spacek > >> From bff8bc688c61717df67de2968492f76b4be65d2a Mon Sep 17 00:00:00 2001 >> From: Petr Spacek >> Date: Thu, 4 Oct 2012 10:26:38 +0200 >> Subject: [PATCH] Use NOTAUTH and REFUSED response codes for dynamic updates >> rather than SERVFAIL. From pspacek at redhat.com Thu Oct 4 16:04:29 2012 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 04 Oct 2012 18:04:29 +0200 Subject: [Freeipa-devel] [PATCH 0072] Fix memory leaks in dynamic update PTR synchronization In-Reply-To: <20121004114443.GB3868@redhat.com> References: <506D3F6F.7090705@redhat.com> <20121004114443.GB3868@redhat.com> Message-ID: <506DB38D.4000402@redhat.com> On 10/04/2012 01:44 PM, Adam Tkac wrote: > On Thu, Oct 04, 2012 at 09:49:03AM +0200, Petr Spacek wrote: >> Hello, >> >> Fix memory leaks in dynamic update PTR synchronization. >> >> During settings code refactoring I found several ugly memory leaks >> in sync_ptr handling. > > Ack Pushed to master: cfa827718610ffe55f7a8385a66239a86515ca0c Petr^2 Spacek > >> From 690008eb1fb6f340c735150f21a8d30a244e14bf Mon Sep 17 00:00:00 2001 >> From: Petr Spacek >> Date: Thu, 4 Oct 2012 09:46:25 +0200 >> Subject: [PATCH] Fix memory leaks in dynamic update PTR synchronization. From pvoborni at redhat.com Thu Oct 4 16:14:04 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 04 Oct 2012 18:14:04 +0200 Subject: [Freeipa-devel] [PATCH] [WIP] Firefox extension In-Reply-To: <1349273944.22373.89.camel@willson.li.ssimo.org> References: <506B1879.1090501@redhat.com> <506C4296.7060904@redhat.com> <1349273944.22373.89.camel@willson.li.ssimo.org> Message-ID: <506DB5CC.4070003@redhat.com> On 10/03/2012 04:19 PM, Simo Sorce wrote: > On Wed, 2012-10-03 at 15:50 +0200, Petr Vobornik wrote: >> As Alexander proposed in other channel. I will remove the removal of >> configure.jar and offer the old configuration method if user is using FF >> < 4 so we don't have to make the extension compatible with this ancient >> version. It will be done this way: >> >> If FF < 4 is detected: >> * in browserconfig.html steps 2 and 3 will be grayed-out and replaced >> with step 2a with a link to ssbrowser.html and a description explaining >> the problem >> * ssbrowser.html will be enhanced by steps for autoconfiguration of FF >> < 4. >> >> We can also show the steps in browserconfig, but I want to have it >> somehow available even if user is not using FF<4 to keep general >> awareness about the problem and also to be usable if version detection >> fails. Other possible problem with steps in browserconfig is different >> styles of buttons (to keep the same styles we would have to include same >> css files and jquery.js to configure.jar, which I don't want to do). > > Excellent plan, we should try to reduce the amount of work, and letting > old browsers use the old method is perfectly fine. > If FF15 is the only browser that fails with the old method I would even > go as far as testing exclusively with FF15 and have anything < FF15 use > the old method. > > Simo. > Updated patches attached. browserconfig.html points to older config method for versions prior to 15. The extension is theoretically compatible with FF3.6 and then FF10 and later. There is a problem for FF4-9 with loading strings from .properties file. FF3.6 is working because it doesn't use bootstraping. I also notice that we have an existing issue when navigating to config pages right away before accepting any certificate. Those pages are using some resorces from /ui/ folder which is redirected to https. These resources are not loaded because certificate isn't imported. If user is going straight for Web UI, he won't encounter this issue, but someone might. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0216-1-Kerberos-authentication-extension.patch Type: text/x-patch Size: 15542 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0217-1-Kerberos-authentication-extension-makefiles.patch Type: text/x-patch Size: 6396 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0218-1-Build-and-installation-of-Kerberos-authentication-ex.patch Type: text/x-patch Size: 7501 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0219-1-Configuration-pages-changed-to-use-new-FF-extension.patch Type: text/x-patch Size: 34990 bytes Desc: not available URL: From rcritten at redhat.com Thu Oct 4 16:17:44 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 04 Oct 2012 12:17:44 -0400 Subject: [Freeipa-devel] [PATCH] 1059 single CRL generator Message-ID: <506DB6A8.10504@redhat.com> This changes the way IPA generates CRLs for new installs only. The first master installed is configured as the CRL generator. An entry is added to cn=masters that designates it. When a replica is installed it queries this entry so it knows where to forward CRL requests. CRL files are not available on cloned CAs (so /ipa/crl will return not found). It is possible to get a CRL directly from the clone CA via http://:9180/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1059-crl.patch Type: text/x-diff Size: 6022 bytes Desc: not available URL: From sbose at redhat.com Thu Oct 4 16:45:16 2012 From: sbose at redhat.com (Sumit Bose) Date: Thu, 4 Oct 2012 18:45:16 +0200 Subject: [Freeipa-devel] [PATCH] 83-84 Fix ipaIDobject usage Message-ID: <20121004164516.GD6816@localhost.localdomain> Hi, this is something that felt between the cracks. Some time ago we introduced a new objectclass ipaIDobject to allow objects to have an UID, GID or SID which are basically no users or groups. The DNA plugin should be aware of this new objectclass which is fix by the first patch. The second patch actually use this new objectclass in ipasam. Currenlty ipasam generates a hardcoded SID for the trusted domain user which might lead to confusion. With the second patch the trusted domain user has a proper SID. bye, Sumit -------------- next part -------------- From 1453f3920a5f54d1579f0a64506fed1cdb843658 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Thu, 4 Oct 2012 17:42:15 +0200 Subject: [PATCH 83/84] Add new ipaIDobject to DNA plugin configuraton --- install/share/dna.ldif | 2 +- install/updates/62-ranges.update | 5 +++++ 2 Dateien ge?ndert, 6 Zeilen hinzugef?gt(+), 1 Zeile entfernt(-) diff --git a/install/share/dna.ldif b/install/share/dna.ldif index 5707d3a6c7c1cbf6a6189c9fd7fffdb9c837f281..ee927fcc5ba0aa5b49cf79964359e9dffe89ee5b 100644 --- a/install/share/dna.ldif +++ b/install/share/dna.ldif @@ -10,7 +10,7 @@ dnaType: gidNumber dnaNextValue: eval($IDSTART) dnaMaxValue: eval($IDMAX) dnaMagicRegen: 999 -dnaFilter: (|(objectclass=posixAccount)(objectClass=posixGroup)) +dnaFilter: (|(objectClass=posixAccount)(objectClass=posixGroup)(objectClass=ipaIDobject)) dnaScope: $SUFFIX dnaThreshold: 500 dnaSharedCfgDN: cn=posix-ids,cn=dna,cn=ipa,cn=etc,$SUFFIX diff --git a/install/updates/62-ranges.update b/install/updates/62-ranges.update index 9ba47421312c68cd64000866b3f4866a76bfe586..79d5326d6000d038923b2a92dcdec98370fa90f4 100644 --- a/install/updates/62-ranges.update +++ b/install/updates/62-ranges.update @@ -29,3 +29,8 @@ default: nsslapd-pluginvendor: Red Hat, Inc. default: nsslapd-plugindescription: IPA Range-Check plugin default: nsslapd-plugin-depends-on-type: database default: nsslapd-basedn: $SUFFIX + +# Add new ipaIDobject to DNA plugin configuraton +dn: cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config +replace:dnaFilter:(|(objectclass=posixAccount)(objectClass=posixGroup))::(|(objectClass=posixAccount)(objectClass=posixGroup)(objectClass=ipaIDobject)) + -- 1.7.11.4 -------------- next part -------------- From a5b4bbe6a057509bfc98e63ef6c9f40222855339 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Thu, 4 Oct 2012 17:23:30 +0200 Subject: [PATCH 84/84] ipasam: generate proper SID for trusted domain object --- daemons/ipa-sam/ipa_sam.c | 57 ++++++++++++++++++++++++++++++++++++++++------- 1 Datei ge?ndert, 49 Zeilen hinzugef?gt(+), 8 Zeilen entfernt(-) diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c index 7dc4549cb8f6390827642f14c4cff29539916261..48d566046ba2ebd5f6a8cd64227e0cb2685ff724 100644 --- a/daemons/ipa-sam/ipa_sam.c +++ b/daemons/ipa-sam/ipa_sam.c @@ -93,6 +93,7 @@ bool secrets_store(const char *key, const void *data, size_t size); /* available #define LDAP_PAGE_SIZE 1024 #define LDAP_OBJ_SAMBASAMACCOUNT "ipaNTUserAttrs" #define LDAP_OBJ_TRUSTED_DOMAIN "ipaNTTrustedDomain" +#define LDAP_OBJ_ID_OBJECT "ipaIDobject" #define LDAP_ATTRIBUTE_TRUST_SID "ipaNTTrustedDomainSID" #define LDAP_ATTRIBUTE_SID "ipaNTSecurityIdentifier" #define LDAP_OBJ_GROUPMAP "ipaNTGroupAttrs" @@ -2168,6 +2169,7 @@ static NTSTATUS ipasam_set_trusted_domain(struct pdb_methods *methods, NTSTATUS status; TALLOC_CTX *tmp_ctx; char *trustpw; + char *sid; DEBUG(10, ("ipasam_set_trusted_domain called for domain %s\n", domain)); @@ -2186,6 +2188,17 @@ static NTSTATUS ipasam_set_trusted_domain(struct pdb_methods *methods, mods = NULL; smbldap_make_mod(priv2ld(ldap_state), entry, &mods, "objectClass", LDAP_OBJ_TRUSTED_DOMAIN); + smbldap_make_mod(priv2ld(ldap_state), entry, &mods, "objectClass", + LDAP_OBJ_ID_OBJECT); + + if (entry != NULL) { + sid = get_single_attribute(tmp_ctx, priv2ld(ldap_state), entry, + LDAP_ATTRIBUTE_SID); + } + if (entry == NULL || sid == NULL) { + smbldap_make_mod(priv2ld(ldap_state), entry, &mods, + LDAP_ATTRIBUTE_UIDNUMBER, IPA_MAGIC_ID_STR); + } if (td->netbios_name != NULL) { smbldap_make_mod(priv2ld(ldap_state), entry, &mods, @@ -2509,10 +2522,11 @@ static uint32_t pdb_ipasam_capabilities(struct pdb_methods *methods) } static bool init_sam_from_td(struct samu *user, struct pdb_trusted_domain *td, + LDAPMessage *entry, struct ldapsam_privates *ldap_state) { NTSTATUS status; - struct dom_sid u_sid; + struct dom_sid *u_sid; char *name; char *trustpw = NULL; char *trustpw_utf8 = NULL; @@ -2522,6 +2536,8 @@ static bool init_sam_from_td(struct samu *user, struct pdb_trusted_domain *td, struct ntlm_keys ntlm_keys; size_t converted_size; bool res; + char *sid_str; + enum idmap_error_code err; if (!pdb_set_acct_ctrl(user, ACB_DOMTRUST | ACB_TRUSTED_FOR_DELEGATION, PDB_SET)) { @@ -2545,14 +2561,27 @@ static bool init_sam_from_td(struct samu *user, struct pdb_trusted_domain *td, return false; } - /* FIXME: create a proper SID here */ - if (!sid_compose(&u_sid, &ldap_state->domain_sid, 6789)) { + sid_str = get_single_attribute(user, priv2ld(ldap_state), entry, + LDAP_ATTRIBUTE_SID); + if (sid_str == NULL) { + DEBUG(5, ("Missing SID for trusted domain object.\n")); return false; } - if (!pdb_set_user_sid(user, &u_sid, PDB_SET)) { + err = sss_idmap_sid_to_smb_sid(ldap_state->ipasam_privates->idmap_ctx, + sid_str, &u_sid); + if (err != IDMAP_SUCCESS) { + DEBUG(10, ("Could not convert string %s to sid.\n", sid_str)); + talloc_free(sid_str); return false; } + talloc_free(sid_str); + + if (!pdb_set_user_sid(user, u_sid, PDB_SET)) { + talloc_free(u_sid); + return false; + } + talloc_free(u_sid); status = get_trust_pwd(user, &td->trust_auth_incoming, &trustpw, NULL); if (!NT_STATUS_IS_OK(status)) { @@ -2982,6 +3011,7 @@ static NTSTATUS getsam_interdom_trust_account(struct pdb_methods *methods, TALLOC_CTX *tmp_ctx; struct pdb_trusted_domain *td; NTSTATUS status; + LDAPMessage *entry = NULL; /* The caller must check that (sname[lastidx] == '.') || (sname[lastidx] == '$')) * before calling this function. @@ -2999,13 +3029,24 @@ static NTSTATUS getsam_interdom_trust_account(struct pdb_methods *methods, } dom_name[lastidx] = '\0'; - status = ipasam_get_trusted_domain(methods, tmp_ctx, dom_name, &td); - if (!NT_STATUS_IS_OK(status)) { - DEBUG(5, ("ipasam_get_trusted_domain failed.\n")); + if (!get_trusted_domain_by_name_int(ldap_state, tmp_ctx, dom_name, + &entry)) { + status = NT_STATUS_UNSUCCESSFUL; + goto done; + } + if (entry == NULL) { + DEBUG(5, ("getsam_interdom_trust_account: no such trusted " \ + "domain: %s\n", dom_name)); + status = NT_STATUS_NO_SUCH_DOMAIN; + goto done; + } + + if (!fill_pdb_trusted_domain(tmp_ctx, ldap_state, entry, &td)) { + status = NT_STATUS_UNSUCCESSFUL; goto done; } - if (!init_sam_from_td(user, td, ldap_state)) { + if (!init_sam_from_td(user, td, entry, ldap_state)) { DEBUG(5, ("init_sam_from_td failed.\n")); status = NT_STATUS_NO_SUCH_USER; goto done; -- 1.7.11.4 From alee at redhat.com Thu Oct 4 20:04:16 2012 From: alee at redhat.com (Ade Lee) Date: Thu, 04 Oct 2012 16:04:16 -0400 Subject: [Freeipa-devel] [PATCH] Changes to use a single database for dogtag and IPA In-Reply-To: <506B096A.1070406@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50640DCB.2060901@redhat.com> <50699C3B.4050200@redhat.com> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> <506B096A.1070406@redhat.com> Message-ID: <1349381056.2357.8.camel@aleeredhat.laptop> Attached is a patch to handle the ipa-replica-conncheck issue. It should be applied on top of your patch. Essentially, the fix is as follows: A. If the DS_PORT = 7389, then we pass --check-ca in the ipa-replica-conncheck to be executed on the master. a1. If the master is ipa 2.x, this will prompt a check for port 7389. a2. If the master is ipa 3, this will default to dogtag_ds_port of 7389. B. Else if DS_PORT = 389, then we pass nothing to the ipa-replica-conncheck to be executed on the master. This is because we will be checking 389 in any case for the IPA DS check. Ade On Tue, 2012-10-02 at 17:34 +0200, Petr Viktorin wrote: > On 10/02/2012 03:02 PM, Petr Viktorin wrote: > > On 10/01/2012 05:02 PM, Ade Lee wrote: > >> On Mon, 2012-10-01 at 16:09 +0200, Martin Kosek wrote: > >>> On 10/01/2012 03:35 PM, Petr Viktorin wrote: > >>>> On 09/27/2012 10:26 AM, Petr Viktorin wrote: > >>>>> On 09/20/2012 05:58 AM, Ade Lee wrote: > >>>>>> Changes to use a single database for dogtag and IPA > >>>>>> > >>>>>> New servers that are installed with dogtag 10 instances will > >>>>>> use > >>>>>> a single database instance for dogtag and IPA, albeit with > >>>>>> different > >>>>>> suffixes. Dogtag will communicate with the instance through a > >>>>>> database user with permissions to modify the dogtag suffix > >>>>>> only. > >>>>>> This user will authenticate using client auth using the > >>>>>> subsystem > >>>>>> cert > >>>>>> for the instance. > >>>>>> > >>>>>> This patch includes changes to allow the creation of masters > >>>>>> and > >>>>>> clones > >>>>>> with single ds instances. > >>>>>> > >>>>>> I have tested being able to create a master and a clone using f17 and > >>>>>> dogtag 10. Note that you will need to use the latest builds on the > >>>>>> dogtag repo to get some changes that were checked in today. We'll > >>>>>> kick > >>>>>> off another official f18 dogtag build in a day or so. > >>>>>> > >>>>>> This is a pretty big change - so I expect many issues to come up as > >>>>>> things get tested. But as this will take awhile to get resolved, its > >>>>>> better to get this out for review as fast as possible. > >>>>>> > >>>>>> Happy reviewing. > >>>>>> > >>>>>> Ade > >>>>>> > >>>>>> > >>>>> > >>>>> Attaching a rebased patch with a couple of style issues fixed. > >>>>> - PEP8 compliance (remove trailing whitespace, use parentheses rather > >>>>> than \ for line continuation, wrap touched lines at 80 characters) > >>>>> - for files, use the with statement instead of the "open/close > >>>>> sandwich" > >>>>> - don't mix tabs and spaces in install/share/certmap.conf.template > >>>>> > >>>>> I've also adjusted the spec file, as we need dogtag 10.0 and > >>>>> pki-server > >>>>> now obsoletes pki-setup. > >>>>> > >>>>> > >>>>> I still need selinux in permissive mode to install on f17, and I still > >>>>> need to exclude *.i686 packages when updating. > >>>>> > >>>> > >>>> Are the following limitations expected? > >>>> > >>>> IPA and Dogtag have to be updated simultaneously; it's not possible > >>>> to have > >>>> current IPA master with Dogtag 10, or IPA with this patch with D9. > >>>> > >>>> It is not possible to create a replica from a machine with a single > >>>> DS to an > >>>> older version without the patch -- the older version will try the > >>>> wrong ports. > >>> > >>> In this case, I think we are covered - we do not support installation > >>> of a > >>> replica with a lower version than the master where the replica info > >>> file was > >>> created. Rob's patch 26dfbe61dd399e9c34f6f5bdeb25a197f1f461cb should > >>> ensure > >>> this for next version release. For 3.0 I think we will have to settle > >>> with a > >>> note in Documentation. > >>> > >> > >> There is currently a dogtag bug where when the master is dogtag 9 (or > >> dogtag 9 converted to 10), and the clone is dogtag 10, the clone will > >> fail to get the installation token from the security domain. This is > >> because the dogtag 10 code tries the new restful interface call -- which > >> is not present on a dogtag 9 subsystem. > >> https://fedorahosted.org/pki/ticket/334 > >> > >> > >> This has been fixed in the latest dogtag 10 nightly builds. And will be > >> in the next dogtag 10 official build, which we plan to create and > >> release today. > >> > >> Incidentally, to see whats coming up in the new dogtag build, look for > >> the 10.0.0-0.X.a2 milestone (plus some of what is closed in 9.0.24) > >> > > > > Okay, testing with the dogtag-devel repo, on f17. > > > > The following scenarios don't work: > > > > - Start with a master on D9 > > - install a replica on D10, without a CA > > - run ipa-ca-install on the replica > > ipa-replica-conncheck: error: no such option: --dogtag-master-ds-port > > > > > > - Start with a master on D9 > > - install a replica without a CA (either Dogtag version) > > - Update all machines > > - run ipa-ca-install on the replica > > com.netscape.certsrv.base.PKIException: > > com.netscape.certsrv.base.PKIException: Failed to obtain installation > > token from security domain > > > > I get the following errors in catalina.out on the replica: > > 08:40:11,149 DEBUG > > (org.jboss.resteasy.plugins.providers.DocumentProvider:60) - Unable to > > retrieve ServletContext: expandEntityReferences defaults to true > > 08:40:11,158 DEBUG > > (org.jboss.resteasy.plugins.providers.DocumentProvider:60) - Unable to > > retrieve ServletContext: expandEntityReferences defaults to true > > CMS Warning: FAILURE: Cannot build CA chain. Error > > java.security.cert.CertificateException: Certificate is not a PKCS #11 > > certificate|FAILURE: authz instance DirAclAuthz initialization failed > > and skipped, error=Property internaldb.ldapconn.port missing value| > > > > > > I did the second scenario again and got a slightly different error > message: "White spaces are required between publicId and systemId." See > attached logs. > I started with IPA 2.2 (from f17 repos) on both machines, then updated > to patched IPA w/ D10, then ran ipa-ca-install. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Allow-ipa-replica-conncheck-to-work-with-2.2-instanc.patch Type: text/x-patch Size: 2235 bytes Desc: not available URL: From mkosek at redhat.com Fri Oct 5 08:59:29 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 05 Oct 2012 10:59:29 +0200 Subject: [Freeipa-devel] [PATCH] 1059 single CRL generator In-Reply-To: <506DB6A8.10504@redhat.com> References: <506DB6A8.10504@redhat.com> Message-ID: <506EA171.20401@redhat.com> On 10/04/2012 06:17 PM, Rob Crittenden wrote: > This changes the way IPA generates CRLs for new installs only. > > The first master installed is configured as the CRL generator. An entry is > added to cn=masters that designates it. > > When a replica is installed it queries this entry so it knows where to forward > CRL requests. CRL files are not available on cloned CAs (so /ipa/crl will > return not found). It is possible to get a CRL directly from the clone CA via > http://:9180/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL > > rob I tested new IPA server + replica with your patch and the CRL was now generated only on the CRL master. I also tried OCSP (though this may not be relevant) and it worked for me too. 1) I do not understand the following block in set_crl_master(self, suffix): + try: + self.admin_conn.addEntry(entry) + except ldap.ALREADY_EXISTS, e: + root_logger.debug("failed to set CA as CRL generator") + raise e - when we hit ldap.ALREADY_EXISTS, we are actually OK because cn=CRL is set, right? - AFAIK, addEntry should return our errors, i.e. errors.DuplicateEntry - s/raise e/raise/ I think you may have wanted to rather catch for more general LDAP error and then report a real error and not just a debug note. 2) In get_crl_master: + except Exception, e: + root_logger.debug("Could not connect to the Directory Server on %s: %s" % (master_host, str(e))) + raise e s/raise e/raise/ + except errors.NotFound, e: + root_logger.debug("failed to find CA CRL generator") + self.crl_master = None - e is actually not used, "except errors.NotFound" would be enough 3) Majorish issue I hit with the actual CRL publishing on our server (F17). I always get 403 Forbidden error when trying to download CRL from the CRL master: # wget --ca-certificate /etc/ipa/ca.crt https://`hostname`/ipa/crl/MasterCRL.bin --2012-10-05 03:32:58-- https://vm-120.idm.lab.bos.redhat.com/ipa/crl/MasterCRL.bin Resolving vm-120.idm.lab.bos.redhat.com... 10.16.78.120 Connecting to vm-120.idm.lab.bos.redhat.com|10.16.78.120|:443... connected. HTTP request sent, awaiting response... 403 Forbidden 2012-10-05 03:32:58 ERROR 403: Forbidden. I tracked the problem down to too strict permission on /var/lib/pki-ca directory which is being published by httpd which does not have access to it: # ll /var/lib/pki-ca drwxrwx---. 11 pkiuser pkiuser 4096 Oct 5 03:00 pki-ca When I fixed the permission: # chmod o+x /var/lib/pki-ca/ I was able to get pass the Forbidden error and actually retrieved the CRL. Adding Ade on CC list to follow on this permission issue. I was thinking about usability of this new approach, we may want to make user life easier in a perspective of CRL master managing. I have following enhancements in mind: - mark CRL master in ipa-replica-manage list, or ipa-csreplica-manage list: # ipa-csreplica-manage list Directory Manager password: vm-065.idm.lab.bos.redhat.com: master [CRL] vm-120.idm.lab.bos.redhat.com: master - when removing master with CRL by "ipa-replica-manage del" we should warn user and inform him what he should do next to amend the situation. I am thinking about 2 new commands for ipa-csreplica-manage: * ipa-csreplica-manage crl-promote - promote current master as the new CRL master, enable CRL generation in CS.cfg, mark master as the new CRL master in cn=masters * ipa-csreplica-manage crl-update - update CS.cfg of current CA replica and point master.ca.agent.* to current CRL master I can work on those enhancements if we agree on them. Martin From pviktori at redhat.com Fri Oct 5 09:57:21 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 05 Oct 2012 11:57:21 +0200 Subject: [Freeipa-devel] [PATCH] Changes to use a single database for dogtag and IPA In-Reply-To: <1349381056.2357.8.camel@aleeredhat.laptop> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50640DCB.2060901@redhat.com> <50699C3B.4050200@redhat.com> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> <506B096A.1070406@redhat.com> <1349381056.2357.8.camel@aleeredhat.laptop> Message-ID: <506EAF01.4070002@redhat.com> On 10/04/2012 10:04 PM, Ade Lee wrote: > Attached is a patch to handle the ipa-replica-conncheck issue. It > should be applied on top of your patch. > > Essentially, the fix is as follows: > A. If the DS_PORT = 7389, then we pass --check-ca in the > ipa-replica-conncheck to be executed on the master. > a1. If the master is ipa 2.x, this will prompt a check for port 7389. > a2. If the master is ipa 3, this will default to dogtag_ds_port of 7389. > > B. Else if DS_PORT = 389, then we pass nothing to the > ipa-replica-conncheck to be executed on the master. This is because we > will be checking 389 in any case for the IPA DS check. > > Ade The code works, I got past the connection check, and now I'm getting the same internal server error with a clone from IPA 2.2 as with a clone from "3.0 upgraded from 2.2" (unknown object class "request"). However, since with this patch IPA will depend on Dogtag 10, install_constants.DS_PORT will always be 389, so case A will never happen. I think the two if-blocks that add the --check-ca can be dropped entirely. Assuming that even a clone from an old instance will use the single DB, conncheck's --dogtag-master-ds-port option is redundant: iff the server supports it, it uses port 389 which doesn't need re-checking. > > 0001-Allow-ipa-replica-conncheck-to-work-with-2.2-instanc.patch > > > From a9cd4cb15e6c230e5690f3fa919fda9c5728ee10 Mon Sep 17 00:00:00 2001 > From: Ade Lee > Date: Thu, 4 Oct 2012 15:55:29 -0400 > Subject: [PATCH] Allow ipa-replica-conncheck to work with 2.2 instances > > --- > install/tools/ipa-replica-conncheck | 15 +++++++-------- > 1 file changed, 7 insertions(+), 8 deletions(-) > > diff --git a/install/tools/ipa-replica-conncheck b/install/tools/ipa-replica-conncheck > index c9fb816be43d873a6ca79396e77270fd0d10aa12..498ef49e84e1dc8325b6fc2d850c8bffb9297e69 100755 > --- a/install/tools/ipa-replica-conncheck > +++ b/install/tools/ipa-replica-conncheck > @@ -282,7 +282,11 @@ def main(): > > required_ports = BASE_PORTS > if options.check_ca: > - ca_port = CheckedPort(int(options.dogtag_master_ds_port), SOCK_STREAM, > + port_val = 7389 > + if options.dogtag_master_ds_port: > + port_val = int(options.dogtag_master_ds_port) > + > + ca_port = CheckedPort(port_val, SOCK_STREAM, > "PKI-CA: Directory Service port") > required_ports.extend([ca_port]) > > @@ -359,11 +363,8 @@ def main(): > raise RuntimeError("Could not get ticket for master server: %s" % stderr) > > remote_check_opts = ['--replica %s' % options.hostname] > - if options.check_ca: > + if options.check_ca and dogtag.install_constants.DS_PORT == 7389: > remote_check_opts.append('--check-ca') > - remote_check_opts.extend(["--dogtag-master-ds-port", > - str(dogtag.install_constants.DS_PORT)]) > - > > print_info("Execute check on remote master") > > @@ -387,10 +388,8 @@ def main(): > print_info("Please run the following command on remote master:") > > remote_check_opts = ['--replica %s' % options.hostname] > - if options.check_ca: > + if options.check_ca and dogtag.install_constants.DS_PORT == 7389: > remote_check_opts.append('--check-ca') > - remote_check_opts.extend(["--dogtag-master-ds-port", > - str(dogtag.install_constants.DS_PORT)]) > > print_info("/usr/sbin/ipa-replica-conncheck " + " ".join(remote_check_opts)) > time.sleep(3600) > -- 1.7.12 > -- Petr? From sbose at redhat.com Fri Oct 5 10:17:02 2012 From: sbose at redhat.com (Sumit Bose) Date: Fri, 5 Oct 2012 12:17:02 +0200 Subject: [Freeipa-devel] [RFC] Reload trust data in ipadb Message-ID: <20121005101702.GE6816@localhost.localdomain> Hi, currently the KDC must be restarted if a new trust is added to make the KDC aware of the new domain. With the attached patch the data is reloaded automatically if a request from an unknown domain was received. It works for me, but I'm not completely sure if this is the best approach to avoid the restart of the KDC. Comments are welcome. bye Sumit -------------- next part -------------- From 5014831c66fa73bb25715725498c457777e7d796 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Fri, 5 Oct 2012 12:06:24 +0200 Subject: [PATCH] ipadb: reload trust information if domain is not know Currently the data about trusted domains is read once at startup. If a new trust is added the KDC must be restarted to know about the new trust. This patch reloads the trust data if there is a request from an unknown domain. To make DOS attacks a bit harder the data can be updated only once in a minute. --- daemons/ipa-kdb/ipa_kdb_mspac.c | 44 ++++++++++++++++++++++++++++++++--------- 1 Datei ge?ndert, 35 Zeilen hinzugef?gt(+), 9 Zeilen entfernt(-) diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index 1a03323d137a2b89a08f5b12ca00752e4e190de7..cbf74cf0b2abdf814b4254d89565399b6eeced0f 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -40,6 +40,7 @@ struct ipadb_mspac { int num_trusts; struct ipadb_adtrusts *trusts; + time_t last_update; }; #ifdef DEBUG @@ -967,6 +968,8 @@ static struct ipadb_adtrusts *get_domain_from_realm(krb5_context context, struct ipadb_context *ipactx; struct ipadb_adtrusts *domain; int i; + krb5_error_code kerr; + bool updated = false; ipactx = ipadb_get_context(context); if (!ipactx) { @@ -977,17 +980,28 @@ static struct ipadb_adtrusts *get_domain_from_realm(krb5_context context, return NULL; } - for (i = 0; i < ipactx->mspac->num_trusts; i++) { - domain = &ipactx->mspac->trusts[i]; - if (strlen(domain->domain_name) != realm.length) { - continue; + do { + for (i = 0; i < ipactx->mspac->num_trusts; i++) { + domain = &ipactx->mspac->trusts[i]; + if (strlen(domain->domain_name) != realm.length) { + continue; + } + if (strncasecmp(domain->domain_name, realm.data, + realm.length) == 0) { + return domain; + } } - if (strncasecmp(domain->domain_name, realm.data, realm.length) == 0) { - return domain; - } - } - return NULL; + if (updated) { + return NULL; + } else { + kerr = ipadb_reinit_mspac(ipactx); + if (kerr != 0) { + return NULL; + } + updated = true; + } + } while(1); } static krb5_error_code filter_logon_info(krb5_context context, @@ -1534,6 +1548,16 @@ krb5_error_code ipadb_reinit_mspac(struct ipadb_context *ipactx) struct dom_sid gsid; char *resstr; int ret; + time_t now; + + /* Do not update the mspac struct more than once a minute. This would + * avoid heavy load on the directory server if there are lots of requests + * from domains which we do not trust. */ + now = time(NULL); + if (ipactx->mspac != NULL && now > ipactx->mspac->last_update && + (now - ipactx->mspac->last_update) < 60) { + return 0; + } /* clean up in case we had old values around */ ipadb_mspac_struct_free(&ipactx->mspac); @@ -1544,6 +1568,8 @@ krb5_error_code ipadb_reinit_mspac(struct ipadb_context *ipactx) goto done; } + ipactx->mspac->last_update = now; + kerr = ipadb_simple_search(ipactx, ipactx->base, LDAP_SCOPE_SUBTREE, "(objectclass=ipaNTDomainAttrs)", dom_attrs, &result); -- 1.7.11.4 From pvoborni at redhat.com Fri Oct 5 10:43:29 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 05 Oct 2012 12:43:29 +0200 Subject: [Freeipa-devel] [PATCH] 0082/0083 Handle NotFound exception when establishing trust In-Reply-To: <20121004150613.GP17454@redhat.com> References: <20121004150613.GP17454@redhat.com> Message-ID: <506EB9D1.3090604@redhat.com> On 10/04/2012 05:06 PM, Alexander Bokovoy wrote: > > Hi, > > two attached patches attempt to solve > https://fedorahosted.org/freeipa/ticket/3103 > > We cannot make educated guess where trusted domain's DNS server is > located as we ended up with NotFound exception precisely because we were > unable to discover trusted domain's domain controller location. > > Thus, all we can do is to suggest ways to fix the issue. Since > suggestion becomes relatively long (multi-line, at least), it creates > few issues for current exception error message handling: > - root_logger does not use textui to format output > - textui is only printing to standard output > - multi-line error messages thus become non-wrapped > - localizing such messages would become a harder context-wise. > > Web UI is showing error message as a single paragraph (

), all > multi-line markup would be lost. > > In the end, I decided to support list-based multi-line error messages in > PublicError class. Its constructor will join all list-based arguments > into single string per argument (first patch). > > In Web UI I've added special text processing of error messages that > splits message into multiple lines and wraps those which start with a > TAB symbol into 'error-message-hinted' span to visually separate it from > the rest of error message. Trust code uses this to display suggested CLI > command to set up DNS forwarder (second patch). > > In the end, CLI shows such error message fine (note tabulated CLI command): > ----------------------------------------------------------------------- > # ipa trust-add --type=ad --admin Administrator at ad.local1 --password > ad.local1 > Active directory domain administrator's password: ipa: ERROR: Unable to > resolve domain controller for 'ad.local1' domain. IPA manages DNS, > please configure forwarder to 'ad.local1' domain by using following CLI > command. Please replace DNS_SERVER and IP_ADDRESS by name and address of > the domain's name server: > ipa dnszone-add ad.local1 --name-server=DNS_SERVER > --admin-email='hostmaster at ad.local1' --force --forwarder=IP_ADDRESS > --forward-policy=only > When using Web UI, please create DNS zone for domain 'ad.local1' first > and then set forwarder and forward policy > ----------------------------------------------------------------------- > > Web UI looks like this: http://abbra.fedorapeople.org/.paste/ui.png > > You have undeclared identifier: lines. I recommend to run `jsl -conf jsl.conf` command in install/ui folder to prevent these issues. I'm not convinced that "beautify" call should be in command object. I would rather see it in error_dialog. I'm not sure that all tabbed error text should be red. But I don't recall any other usage so it's probably OK. -- Petr Vobornik From pspacek at redhat.com Fri Oct 5 11:15:13 2012 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 05 Oct 2012 13:15:13 +0200 Subject: [Freeipa-devel] [PATCH 0074] Fix zone removal in persistent search update_zone() Message-ID: <506EC141.7020508@redhat.com> Hello, Fix zone removal in persistent search update_zone(). Without this patch any zone removed through ipa dnszone-del will remain active and will return SERVFAILs. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0074-Fix-zone-removal-in-persistent-search-update_zone-ha.patch Type: text/x-patch Size: 2091 bytes Desc: not available URL: From sbose at redhat.com Fri Oct 5 11:32:04 2012 From: sbose at redhat.com (Sumit Bose) Date: Fri, 5 Oct 2012 13:32:04 +0200 Subject: [Freeipa-devel] [RFC] Reload trust data in ipadb In-Reply-To: <20121005101702.GE6816@localhost.localdomain> References: <20121005101702.GE6816@localhost.localdomain> Message-ID: <20121005113204.GG6816@localhost.localdomain> On Fri, Oct 05, 2012 at 12:17:02PM +0200, Sumit Bose wrote: > Hi, > > currently the KDC must be restarted if a new trust is added to make the > KDC aware of the new domain. With the attached patch the data is > reloaded automatically if a request from an unknown domain was received. > It works for me, but I'm not completely sure if this is the best > approach to avoid the restart of the KDC. > > Comments are welcome. > > bye > Sumit I'm sorry, but the previous version of the patch depended on some unpushed patches in my tree. This new version should apply fine on master. bye, Sumit -------------- next part -------------- From f8726fe1c4a2ab71ada1297003e3dbe6068e4207 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Fri, 5 Oct 2012 12:06:24 +0200 Subject: [PATCH] ipadb: reload trust information if domain is not know Currently the data about trusted domains is read once at startup. If a new trust is added the KDC must be restarted to know about the new trust. This patch reloads the trust data if there is a request from an unknown domain. To make DOS attacks a bit harder the data can be updated only once in a minute. --- daemons/ipa-kdb/ipa_kdb_mspac.c | 44 ++++++++++++++++++++++++++++++++--------- 1 Datei ge?ndert, 35 Zeilen hinzugef?gt(+), 9 Zeilen entfernt(-) diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index b5346fed1230d02a88c94ab913507112990a1651..f0bd3bfe913705abd44efb08325f54521533637e 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -40,6 +40,7 @@ struct ipadb_mspac { int num_trusts; struct ipadb_adtrusts *trusts; + time_t last_update; }; @@ -983,6 +984,8 @@ static struct ipadb_adtrusts *get_domain_from_realm(krb5_context context, struct ipadb_context *ipactx; struct ipadb_adtrusts *domain; int i; + krb5_error_code kerr; + bool updated = false; ipactx = ipadb_get_context(context); if (!ipactx) { @@ -993,17 +996,28 @@ static struct ipadb_adtrusts *get_domain_from_realm(krb5_context context, return NULL; } - for (i = 0; i < ipactx->mspac->num_trusts; i++) { - domain = &ipactx->mspac->trusts[i]; - if (strlen(domain->domain_name) != realm.length) { - continue; + do { + for (i = 0; i < ipactx->mspac->num_trusts; i++) { + domain = &ipactx->mspac->trusts[i]; + if (strlen(domain->domain_name) != realm.length) { + continue; + } + if (strncasecmp(domain->domain_name, realm.data, + realm.length) == 0) { + return domain; + } } - if (strncasecmp(domain->domain_name, realm.data, realm.length) == 0) { - return domain; - } - } - return NULL; + if (updated) { + return NULL; + } else { + kerr = ipadb_reinit_mspac(ipactx); + if (kerr != 0) { + return NULL; + } + updated = true; + } + } while(1); } static krb5_error_code filter_logon_info(krb5_context context, @@ -1550,6 +1564,16 @@ krb5_error_code ipadb_reinit_mspac(struct ipadb_context *ipactx) struct dom_sid gsid; char *resstr; int ret; + time_t now; + + /* Do not update the mspac struct more than once a minute. This would + * avoid heavy load on the directory server if there are lots of requests + * from domains which we do not trust. */ + now = time(NULL); + if (ipactx->mspac != NULL && now > ipactx->mspac->last_update && + (now - ipactx->mspac->last_update) < 60) { + return 0; + } /* clean up in case we had old values around */ ipadb_mspac_struct_free(&ipactx->mspac); @@ -1560,6 +1584,8 @@ krb5_error_code ipadb_reinit_mspac(struct ipadb_context *ipactx) goto done; } + ipactx->mspac->last_update = now; + kerr = ipadb_simple_search(ipactx, ipactx->base, LDAP_SCOPE_SUBTREE, "(objectclass=ipaNTDomainAttrs)", dom_attrs, &result); -- 1.7.11.4 From pspacek at redhat.com Fri Oct 5 11:45:42 2012 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 05 Oct 2012 13:45:42 +0200 Subject: [Freeipa-devel] [PATCH 0075] Prevent misleading "partial match" error messages for disabled zones Message-ID: <506EC866.5070603@redhat.com> Hello, Prevent misleading "partial match" error messages for disabled zones. Following message was printed if zone "e.test" was disabled and LDAP contained zones "test" and "e.test": update_zone (psearch) failed for 'idnsName=e.test,cn=dns,dc=e,dc=org'. Zones can be outdated, run `rndc reload`: partial match -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0075-Prevent-misleading-partial-match-error-messages-for-.patch Type: text/x-patch Size: 1284 bytes Desc: not available URL: From simo at redhat.com Fri Oct 5 12:44:41 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 05 Oct 2012 08:44:41 -0400 Subject: [Freeipa-devel] [RFC] Reload trust data in ipadb In-Reply-To: <20121005113204.GG6816@localhost.localdomain> References: <20121005101702.GE6816@localhost.localdomain> <20121005113204.GG6816@localhost.localdomain> Message-ID: <1349441081.22373.180.camel@willson.li.ssimo.org> On Fri, 2012-10-05 at 13:32 +0200, Sumit Bose wrote: > From f8726fe1c4a2ab71ada1297003e3dbe6068e4207 Mon Sep 17 00:00:00 2001 > From: Sumit Bose > Date: Fri, 5 Oct 2012 12:06:24 +0200 > Subject: [PATCH] ipadb: reload trust information if domain is not know > > Currently the data about trusted domains is read once at startup. If a > new trust is added the KDC must be restarted to know about the new > trust. This patch reloads the trust data if there is a request from an > unknown domain. To make DOS attacks a bit harder the data can be > updated > only once in a minute. > --- > daemons/ipa-kdb/ipa_kdb_mspac.c | 44 > ++++++++++++++++++++++++++++++++--------- > 1 Datei ge?ndert, 35 Zeilen hinzugef?gt(+), 9 Zeilen entfernt(-) > > diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c > b/daemons/ipa-kdb/ipa_kdb_mspac.c > index > b5346fed1230d02a88c94ab913507112990a1651..f0bd3bfe913705abd44efb08325f54521533637e 100644 > --- a/daemons/ipa-kdb/ipa_kdb_mspac.c > +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c > @@ -40,6 +40,7 @@ struct ipadb_mspac { > > int num_trusts; > struct ipadb_adtrusts *trusts; > + time_t last_update; > }; > > > @@ -983,6 +984,8 @@ static struct ipadb_adtrusts > *get_domain_from_realm(krb5_context context, > struct ipadb_context *ipactx; > struct ipadb_adtrusts *domain; > int i; > + krb5_error_code kerr; > + bool updated = false; The name of this variable sounds backwards, should be called need_update or similar. > ipactx = ipadb_get_context(context); > if (!ipactx) { > @@ -993,17 +996,28 @@ static struct ipadb_adtrusts > *get_domain_from_realm(krb5_context context, > return NULL; > } > > - for (i = 0; i < ipactx->mspac->num_trusts; i++) { > - domain = &ipactx->mspac->trusts[i]; > - if (strlen(domain->domain_name) != realm.length) { > - continue; > + do { > + for (i = 0; i < ipactx->mspac->num_trusts; i++) { > + domain = &ipactx->mspac->trusts[i]; > + if (strlen(domain->domain_name) != realm.length) { > + continue; > + } > + if (strncasecmp(domain->domain_name, realm.data, > + realm.length) == 0) { > + return domain; > + } > } > - if (strncasecmp(domain->domain_name, realm.data, > realm.length) == 0) { > - return domain; > - } > - } > > - return NULL; > + if (updated) { > + return NULL; > + } else { > + kerr = ipadb_reinit_mspac(ipactx); > + if (kerr != 0) { > + return NULL; > + } > + updated = true; > + } > + } while(1); > } I do not think I like the do/while loop here, I would rather have another function that wraps the current get_domain_from_realm() like: static struct ipadb_adtrusts *get_domain_from_realm_update() { dom = get_domain_from_realm(); if (dom == NULL) { /* no dom, try to see if a new trust appeared */ kerr = ipadb_reinit_mspac(ipactx); dom = get_domain_from_realm(); } return dom; } This is clearer imo, and allows you to decide if you really want to update or if you want to call the non-updating function later on, should we need it. > static krb5_error_code filter_logon_info(krb5_context context, > @@ -1550,6 +1564,16 @@ krb5_error_code ipadb_reinit_mspac(struct > ipadb_context *ipactx) > struct dom_sid gsid; > char *resstr; > int ret; > + time_t now; > + > + /* Do not update the mspac struct more than once a minute. This > would > + * avoid heavy load on the directory server if there are lots of > requests > + * from domains which we do not trust. */ > + now = time(NULL); > + if (ipactx->mspac != NULL && now > ipactx->mspac->last_update && > + (now - ipactx->mspac->last_update) < 60) { > + return 0; > + } > > /* clean up in case we had old values around */ > ipadb_mspac_struct_free(&ipactx->mspac); > @@ -1560,6 +1584,8 @@ krb5_error_code ipadb_reinit_mspac(struct > ipadb_context *ipactx) > goto done; > } > > + ipactx->mspac->last_update = now; > + > kerr = ipadb_simple_search(ipactx, ipactx->base, > LDAP_SCOPE_SUBTREE, > "(objectclass=ipaNTDomainAttrs)", > dom_attrs, > &result); This part look fine, I wonder if we shouldn't make it even longer than 1 min. Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Fri Oct 5 13:24:25 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 5 Oct 2012 16:24:25 +0300 Subject: [Freeipa-devel] [PATCH] 0082/0083 Handle NotFound exception when establishing trust In-Reply-To: <506EB9D1.3090604@redhat.com> References: <20121004150613.GP17454@redhat.com> <506EB9D1.3090604@redhat.com> Message-ID: <20121005132424.GQ17454@redhat.com> On Fri, 05 Oct 2012, Petr Vobornik wrote: >On 10/04/2012 05:06 PM, Alexander Bokovoy wrote: >> >>Hi, >> >>two attached patches attempt to solve >>https://fedorahosted.org/freeipa/ticket/3103 >> >>We cannot make educated guess where trusted domain's DNS server is >>located as we ended up with NotFound exception precisely because we were >>unable to discover trusted domain's domain controller location. >> >>Thus, all we can do is to suggest ways to fix the issue. Since >>suggestion becomes relatively long (multi-line, at least), it creates >>few issues for current exception error message handling: >> - root_logger does not use textui to format output >> - textui is only printing to standard output >> - multi-line error messages thus become non-wrapped >> - localizing such messages would become a harder context-wise. >> >>Web UI is showing error message as a single paragraph (

), all >>multi-line markup would be lost. >> >>In the end, I decided to support list-based multi-line error messages in >>PublicError class. Its constructor will join all list-based arguments >>into single string per argument (first patch). >> >>In Web UI I've added special text processing of error messages that >>splits message into multiple lines and wraps those which start with a >>TAB symbol into 'error-message-hinted' span to visually separate it from >>the rest of error message. Trust code uses this to display suggested CLI >>command to set up DNS forwarder (second patch). >> >>In the end, CLI shows such error message fine (note tabulated CLI command): >>----------------------------------------------------------------------- >># ipa trust-add --type=ad --admin Administrator at ad.local1 --password >>ad.local1 >>Active directory domain administrator's password: ipa: ERROR: Unable to >>resolve domain controller for 'ad.local1' domain. IPA manages DNS, >>please configure forwarder to 'ad.local1' domain by using following CLI >>command. Please replace DNS_SERVER and IP_ADDRESS by name and address of >>the domain's name server: >> ipa dnszone-add ad.local1 --name-server=DNS_SERVER >>--admin-email='hostmaster at ad.local1' --force --forwarder=IP_ADDRESS >>--forward-policy=only >>When using Web UI, please create DNS zone for domain 'ad.local1' first >>and then set forwarder and forward policy >>----------------------------------------------------------------------- >> >>Web UI looks like this: http://abbra.fedorapeople.org/.paste/ui.png >> >> > >You have undeclared identifier: lines. > >I recommend to run `jsl -conf jsl.conf` command in install/ui folder >to prevent these issues. Fixed. >I'm not convinced that "beautify" call should be in command object. I >would rather see it in error_dialog. I moved everything to error_dialog and used $() selectors instead of directly playing with text. >I'm not sure that all tabbed error text should be red. But I don't >recall any other usage so it's probably OK. We don't have any, this is first one. -- / Alexander Bokovoy -------------- next part -------------- >From d7a413c0f3d57bbe788951de624f2caaf7065941 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 4 Oct 2012 15:05:17 +0300 Subject: [PATCH 01/16] support multi-line error messages in exceptions --- install/ui/ipa.css | 9 ++++++++- install/ui/ipa.js | 30 ++++++++++++++++++++++++------ ipalib/errors.py | 12 +++++++++--- 3 files changed, 41 insertions(+), 10 deletions(-) diff --git a/install/ui/ipa.css b/install/ui/ipa.css index c8a220e78430fd38a1781be63421babaadafc948..3146e115524a6672b80e44956710a92bba79af0a 100644 --- a/install/ui/ipa.css +++ b/install/ui/ipa.css @@ -1113,6 +1113,13 @@ table.kerberos-key-status { background-color: #daa520; } +.error-message-hinted { + color: red; + padding-top: 0.5em; + padding-bottom: 0.5em; + font-family: monospace; +} + /* ---- Table ---- */ table.scrollable thead { @@ -1755,4 +1762,4 @@ form#login { .choice-header { font-weight: bold; -} \ No newline at end of file +} diff --git a/install/ui/ipa.js b/install/ui/ipa.js index bd25aeae2b4ff53f928b6fbd7429109fa9c55f68..a511d788bd230f33382f0abbd9496f47b027f9a3 100644 --- a/install/ui/ipa.js +++ b/install/ui/ipa.js @@ -1419,6 +1419,24 @@ IPA.error_dialog = function(spec) { that.visible_buttons = spec.visible_buttons || ['retry', 'cancel']; }; + that.beautify_message = function(container, message) { + var lines = message.split(/\n/g); + for(var i=0; i', { + class: 'error-message-hinted', + text: lines[i].substr(1) + }).appendTo(container); + } else { + var line_span = $('

', { + text: lines[i] + }).appendTo(container); + } + } + }; + that.create = function() { if (that.error_thrown.url) { $('

', { @@ -1426,9 +1444,9 @@ IPA.error_dialog = function(spec) { }).appendTo(that.container); } - $('

', { - html: that.error_thrown.message - }).appendTo(that.container); + var error_message = $('', {}); + that.beautify_message(error_message, that.error_thrown.message); + error_message.appendTo(that.container); if(that.errors && that.errors.length > 0) { //render errors @@ -1457,9 +1475,9 @@ IPA.error_dialog = function(spec) { for(var i=0; i < that.errors.length; i++) { var error = that.errors[i]; if(error.message) { - var error_div = $('

  • ', { - text: error.message - }).appendTo(errors_container); + var error_div = $('
  • ', {}); + that.beautify_message(error_div, error.message); + error_div.appendTo(errors_container); } } diff --git a/ipalib/errors.py b/ipalib/errors.py index 7bf267290b484ed9570f1c7efdb606628fb5f11d..7f1113200b6b2cd80ea9156d347211e4d978b9be 100644 --- a/ipalib/errors.py +++ b/ipalib/errors.py @@ -265,11 +265,17 @@ class PublicError(StandardError): ) self.format = format self.forwarded = False - self.msg = self.format % kw + def convert_keyword(value): + if isinstance(value, list): + result=u'\n'.join(map(lambda line: unicode(line), value)) + return result + return value + kwargs = dict(map(lambda (k,v): (k, convert_keyword(v)), kw.items())) + self.msg = self.format % kwargs if isinstance(self.format, basestring): - self.strerror = ugettext(self.format) % kw + self.strerror = ugettext(self.format) % kwargs else: - self.strerror = self.format % kw + self.strerror = self.format % kwargs else: if isinstance(message, (Gettext, NGettext)): message = unicode(message) -- 1.7.12 -------------- next part -------------- >From 3189272314588738994b7b01f2aa3984aed169b2 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 4 Oct 2012 17:40:05 +0300 Subject: [PATCH 02/16] Handle NotFound exception when establishing trust Establishing trust implies discovery of the trusted domain's domain controller via DNS. If DNS discovery is not possible, NotFound exception is raised. Intercept the exception and process it to help diagnose and fix actual problem: - if IPA is managing DNS, suggest to make a forward for the domain's zone - otherwise suggest to setup DNS forwarder at upstream DNS server https://fedorahosted.org/freeipa/ticket/3103 --- ipalib/plugins/trust.py | 37 ++++++++++++++++++++++++++++++++++--- 1 file changed, 34 insertions(+), 3 deletions(-) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index 9d3e9a873e8f6335c12729e9f9475e59499fb3d4..793ad90c0f90dfc4bc3fbaa3d9184b301a44aa0f 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -18,6 +18,7 @@ # along with this program. If not, see . from ipalib.plugins.baseldap import * +from ipalib.plugins.dns import dns_container_exists from ipalib import api, Str, StrEnum, Password, DefaultFrom, _, ngettext, Object from ipalib.parameters import Enum from ipalib import Command @@ -325,10 +326,39 @@ class trust_add(LDAPCreate): raise errors.ValidationError(name=_('AD Trust setup'), error=_('Realm administrator password should be specified')) realm_passwd = options['realm_passwd'] - result = trustinstance.join_ad_full_credentials(keys[-1], realm_server, realm_admin, realm_passwd) + try: + result = trustinstance.join_ad_full_credentials(keys[-1], realm_server, realm_admin, realm_passwd) + except errors.NotFound, e: + error_message=[_("Unable to resolve domain controller for '%s' domain. ") % (keys[-1])] + if dns_container_exists(self.obj.backend): + try: + dns_zone = api.Command.dnszone_show(keys[-1])['result'] + if ('idnsforwardpolicy' in dns_zone) and dns_zone['idnsforwardpolicy'][0] == u'only': + error_message.append(_("Forward policy is defined for it in IPA DNS, " + "perhaps forwarder points to incorrect host?")) + except (errors.NotFound, KeyError) as e: + error_message.append(_("IPA manages DNS, please configure forwarder to " + "'%(domain)s' domain using following CLI command. " + "Make sure to replace DNS_SERVER and IP_ADDRESS by " + "actual values corresponding to the trusted domain's " + "DNS server:") % dict(domain=keys[-1])) + # tab character at the beginning of a multiline error message will be replaced + # in the web UI by a colorful hint. Does not affect CLI. + error_message.append(_("\tipa dnszone-add %(domain)s --name-server=[DNS_SERVER] " + "--admin-email='hostmaster@%(domain)s' " + "--force --forwarder=[IP_ADDRESS] " + "--forward-policy=only") % dict(domain=keys[-1])) + error_message.append(_("When using Web UI, please create DNS zone for domain '%(domain)s' " + "first and then set forwarder and forward policy.") % dict(domain=keys[-1])) + else: + error_message.append(_("Since IPA does not manage DNS records, ensure DNS " + "is configured to resolve '%(domain)s' domain from " + "IPA hosts and back.") % dict(domain=keys[-1])) + raise errors.NotFound(reason=error_message) if result is None: - raise errors.ValidationError(name=_('AD Trust setup'), error=_('Unable to verify write permissions to the AD')) + raise errors.ValidationError(name=_('AD Trust setup'), + error=_('Unable to verify write permissions to the AD')) return dict(value=trustinstance.remote_domain.info['dns_domain'], verified=result['verified']) @@ -338,7 +368,8 @@ class trust_add(LDAPCreate): if 'trust_secret' in options: result = trustinstance.join_ad_ipa_half(keys[-1], realm_server, options['trust_secret']) return dict(value=trustinstance.remote_domain.info['dns_domain'], verified=result['verified']) - raise errors.ValidationError(name=_('AD Trust setup'), error=_('Not enough arguments specified to perform trust setup')) + raise errors.ValidationError(name=_('AD Trust setup'), + error=_('Not enough arguments specified to perform trust setup')) class trust_del(LDAPDelete): __doc__ = _('Delete a trust.') -- 1.7.12 From abokovoy at redhat.com Fri Oct 5 13:27:52 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 5 Oct 2012 16:27:52 +0300 Subject: [Freeipa-devel] [PATCH] 75-78 Add fallback group In-Reply-To: <1349207792.22373.64.camel@willson.li.ssimo.org> References: <20121002192901.GV6816@localhost.localdomain> <1349207792.22373.64.camel@willson.li.ssimo.org> Message-ID: <20121005132752.GR17454@redhat.com> On Tue, 02 Oct 2012, Simo Sorce wrote: >On Tue, 2012-10-02 at 21:29 +0200, Sumit Bose wrote: >> Hi, >> >> this patch should fix https://fedorahosted.org/freeipa/ticket/2955 by >> adding a fallback group as described in comment 2 of the ticket in >> ipa-adtrust-install. >> >> If you prefer to use a different kind of group I can change the patch >> accordingly. Patch works for me, so ACK except the group name. >Yes I think we should use a more natural group name. In my recent >testing I have been using the name 'Trust Users' that pairs well with >another group we create called 'Trust Admins'. But I am open to >suggestions on a better name, 'Domain Users' may be better if we really >want to associate the wellknown SID to this group. I'm fine with 'Trust Users'. >On the SID side I wonder if using the wellknown 'Domain Users' SID is >the right thing to do. I do not see any special reasons why it shouldn't >but I also do not have any special reason why we should. >Anyone can think of any pros/cons of doing that ? Since it only has special meaning within the same domain and we are not using it for anything, it should be fine. -- / Alexander Bokovoy From abokovoy at redhat.com Fri Oct 5 13:29:19 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 5 Oct 2012 16:29:19 +0300 Subject: [Freeipa-devel] [PATCH] 83-84 Fix ipaIDobject usage In-Reply-To: <20121004164516.GD6816@localhost.localdomain> References: <20121004164516.GD6816@localhost.localdomain> Message-ID: <20121005132919.GS17454@redhat.com> On Thu, 04 Oct 2012, Sumit Bose wrote: >Hi, > >this is something that felt between the cracks. Some time ago we >introduced a new objectclass ipaIDobject to allow objects to have an >UID, GID or SID which are basically no users or groups. The DNA plugin >should be aware of this new objectclass which is fix by the first patch. > >The second patch actually use this new objectclass in ipasam. Currenlty >ipasam generates a hardcoded SID for the trusted domain user which might >lead to confusion. With the second patch the trusted domain user has a >proper SID. ACK, works for me. -- / Alexander Bokovoy From abokovoy at redhat.com Fri Oct 5 13:29:50 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 5 Oct 2012 16:29:50 +0300 Subject: [Freeipa-devel] [PATCH] 82 ipa-adtrust-install: print list of needed SRV records In-Reply-To: <20121004104942.GC6816@localhost.localdomain> References: <20121004104942.GC6816@localhost.localdomain> Message-ID: <20121005132950.GT17454@redhat.com> On Thu, 04 Oct 2012, Sumit Bose wrote: >Hi, > >this patch should fix the reopend >https://fedorahosted.org/freeipa/ticket/3019 . ACK. -- / Alexander Bokovoy From mkosek at redhat.com Fri Oct 5 13:35:15 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 05 Oct 2012 15:35:15 +0200 Subject: [Freeipa-devel] [PATCH] 75-78 Add fallback group In-Reply-To: <20121005132752.GR17454@redhat.com> References: <20121002192901.GV6816@localhost.localdomain> <1349207792.22373.64.camel@willson.li.ssimo.org> <20121005132752.GR17454@redhat.com> Message-ID: <506EE213.807@redhat.com> On 10/05/2012 03:27 PM, Alexander Bokovoy wrote: > On Tue, 02 Oct 2012, Simo Sorce wrote: >> On Tue, 2012-10-02 at 21:29 +0200, Sumit Bose wrote: >>> Hi, >>> >>> this patch should fix https://fedorahosted.org/freeipa/ticket/2955 by >>> adding a fallback group as described in comment 2 of the ticket in >>> ipa-adtrust-install. >>> >>> If you prefer to use a different kind of group I can change the patch >>> accordingly. > Patch works for me, so ACK except the group name. > >> Yes I think we should use a more natural group name. In my recent >> testing I have been using the name 'Trust Users' that pairs well with >> another group we create called 'Trust Admins'. But I am open to >> suggestions on a better name, 'Domain Users' may be better if we really >> want to associate the wellknown SID to this group. > I'm fine with 'Trust Users'. We may also want to add "Trust Users" (or other name we settle on) to PROTECTED_GROUPS list in group.py. This should prevent user accidentally deleting or renaming the group. Martin From simo at redhat.com Fri Oct 5 13:45:58 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 05 Oct 2012 09:45:58 -0400 Subject: [Freeipa-devel] [PATCH] 75-78 Add fallback group In-Reply-To: <20121005132752.GR17454@redhat.com> References: <20121002192901.GV6816@localhost.localdomain> <1349207792.22373.64.camel@willson.li.ssimo.org> <20121005132752.GR17454@redhat.com> Message-ID: <1349444758.22373.187.camel@willson.li.ssimo.org> On Fri, 2012-10-05 at 16:27 +0300, Alexander Bokovoy wrote: > On Tue, 02 Oct 2012, Simo Sorce wrote: > >On Tue, 2012-10-02 at 21:29 +0200, Sumit Bose wrote: > >> Hi, > >> > >> this patch should fix https://fedorahosted.org/freeipa/ticket/2955 by > >> adding a fallback group as described in comment 2 of the ticket in > >> ipa-adtrust-install. > >> > >> If you prefer to use a different kind of group I can change the patch > >> accordingly. > Patch works for me, so ACK except the group name. > > >Yes I think we should use a more natural group name. In my recent > >testing I have been using the name 'Trust Users' that pairs well with > >another group we create called 'Trust Admins'. But I am open to > >suggestions on a better name, 'Domain Users' may be better if we really > >want to associate the wellknown SID to this group. > I'm fine with 'Trust Users'. > > >On the SID side I wonder if using the wellknown 'Domain Users' SID is > >the right thing to do. I do not see any special reasons why it shouldn't > >but I also do not have any special reason why we should. > >Anyone can think of any pros/cons of doing that ? > Since it only has special meaning within the same domain and we are not > using it for anything, it should be fine. Well it has a special meaning for samba servers ... we may have a few in the IPA domain. I think using that SID is fine but I think then the name 'Trust Users' could be confusing to users looking at permissions. We also need to make the group a posix group btw, because samba uses the Primary Group SID for users and if it can't be resolved to uid/gids it will probably prevent authentication. What about calling it 'Default SMB Group' or similar ? Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Oct 5 13:46:24 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 05 Oct 2012 09:46:24 -0400 Subject: [Freeipa-devel] [PATCH] 75-78 Add fallback group In-Reply-To: <506EE213.807@redhat.com> References: <20121002192901.GV6816@localhost.localdomain> <1349207792.22373.64.camel@willson.li.ssimo.org> <20121005132752.GR17454@redhat.com> <506EE213.807@redhat.com> Message-ID: <1349444784.22373.188.camel@willson.li.ssimo.org> On Fri, 2012-10-05 at 15:35 +0200, Martin Kosek wrote: > On 10/05/2012 03:27 PM, Alexander Bokovoy wrote: > > On Tue, 02 Oct 2012, Simo Sorce wrote: > >> On Tue, 2012-10-02 at 21:29 +0200, Sumit Bose wrote: > >>> Hi, > >>> > >>> this patch should fix https://fedorahosted.org/freeipa/ticket/2955 by > >>> adding a fallback group as described in comment 2 of the ticket in > >>> ipa-adtrust-install. > >>> > >>> If you prefer to use a different kind of group I can change the patch > >>> accordingly. > > Patch works for me, so ACK except the group name. > > > >> Yes I think we should use a more natural group name. In my recent > >> testing I have been using the name 'Trust Users' that pairs well with > >> another group we create called 'Trust Admins'. But I am open to > >> suggestions on a better name, 'Domain Users' may be better if we really > >> want to associate the wellknown SID to this group. > > I'm fine with 'Trust Users'. > > We may also want to add "Trust Users" (or other name we settle on) to > PROTECTED_GROUPS list in group.py. This should prevent user accidentally > deleting or renaming the group. +1 Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Fri Oct 5 13:51:48 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 5 Oct 2012 16:51:48 +0300 Subject: [Freeipa-devel] [PATCH] 79 Add SIDs for existing users and groups at the end of ipa-adtrust-install In-Reply-To: <20121003093507.GW6816@localhost.localdomain> References: <20121003093507.GW6816@localhost.localdomain> Message-ID: <20121005135148.GU17454@redhat.com> On Wed, 03 Oct 2012, Sumit Bose wrote: >Hi, > >this patch adds a new option to ipa-adtrust-install to generate the SID >for users and groups at the end of the run. This fixes >https://fedorahosted.org/freeipa/ticket/3104 . ACK, works for me too. -- / Alexander Bokovoy From abokovoy at redhat.com Fri Oct 5 13:56:50 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 5 Oct 2012 16:56:50 +0300 Subject: [Freeipa-devel] [PATCH] [WIP] Firefox extension In-Reply-To: <506DB5CC.4070003@redhat.com> References: <506B1879.1090501@redhat.com> <506C4296.7060904@redhat.com> <1349273944.22373.89.camel@willson.li.ssimo.org> <506DB5CC.4070003@redhat.com> Message-ID: <20121005135650.GV17454@redhat.com> On Thu, 04 Oct 2012, Petr Vobornik wrote: > On 10/03/2012 04:19 PM, Simo Sorce wrote: >> On Wed, 2012-10-03 at 15:50 +0200, Petr Vobornik wrote: >>> As Alexander proposed in other channel. I will remove the removal of >>> configure.jar and offer the old configuration method if user is using FF >>> < 4 so we don't have to make the extension compatible with this ancient >>> version. It will be done this way: >>> >>> If FF < 4 is detected: >>> * in browserconfig.html steps 2 and 3 will be grayed-out and replaced >>> with step 2a with a link to ssbrowser.html and a description explaining >>> the problem >>> * ssbrowser.html will be enhanced by steps for autoconfiguration of FF >>> < 4. >>> >>> We can also show the steps in browserconfig, but I want to have it >>> somehow available even if user is not using FF<4 to keep general >>> awareness about the problem and also to be usable if version detection >>> fails. Other possible problem with steps in browserconfig is different >>> styles of buttons (to keep the same styles we would have to include same >>> css files and jquery.js to configure.jar, which I don't want to do). >> >> Excellent plan, we should try to reduce the amount of work, and letting >> old browsers use the old method is perfectly fine. >> If FF15 is the only browser that fails with the old method I would even >> go as far as testing exclusively with FF15 and have anything < FF15 use >> the old method. >> >> Simo. >> > > Updated patches attached. > > browserconfig.html points to older config method for versions prior to 15. > > The extension is theoretically compatible with FF3.6 and then FF10 > and later. There is a problem for FF4-9 with loading strings from > .properties file. FF3.6 is working because it doesn't use > bootstraping. > > I also notice that we have an existing issue when navigating to > config pages right away before accepting any certificate. Those > pages are using some resorces from /ui/ folder which is redirected > to https. These resources are not loaded because certificate isn't > imported. If user is going straight for Web UI, he won't encounter > this issue, but someone might. I tested this patchset and apart from the non-obvious extension description displayed when installing it, which is based on a certificate, everything is great. ACK. -- / Alexander Bokovoy From edewata at redhat.com Fri Oct 5 14:25:22 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 05 Oct 2012 09:25:22 -0500 Subject: [Freeipa-devel] [PATCH] [WIP] Firefox extension In-Reply-To: <20121005135650.GV17454@redhat.com> References: <506B1879.1090501@redhat.com> <506C4296.7060904@redhat.com> <1349273944.22373.89.camel@willson.li.ssimo.org> <506DB5CC.4070003@redhat.com> <20121005135650.GV17454@redhat.com> Message-ID: <506EEDD2.7040909@redhat.com> On 10/5/2012 8:56 AM, Alexander Bokovoy wrote: > On Thu, 04 Oct 2012, Petr Vobornik wrote: >> On 10/03/2012 04:19 PM, Simo Sorce wrote: >>> On Wed, 2012-10-03 at 15:50 +0200, Petr Vobornik wrote: >>>> As Alexander proposed in other channel. I will remove the removal of >>>> configure.jar and offer the old configuration method if user is >>>> using FF >>>> < 4 so we don't have to make the extension compatible with this ancient >>>> version. It will be done this way: >>>> >>>> If FF < 4 is detected: >>>> * in browserconfig.html steps 2 and 3 will be grayed-out and >>>> replaced >>>> with step 2a with a link to ssbrowser.html and a description explaining >>>> the problem >>>> * ssbrowser.html will be enhanced by steps for autoconfiguration >>>> of FF >>>> < 4. >>>> >>>> We can also show the steps in browserconfig, but I want to have it >>>> somehow available even if user is not using FF<4 to keep general >>>> awareness about the problem and also to be usable if version detection >>>> fails. Other possible problem with steps in browserconfig is different >>>> styles of buttons (to keep the same styles we would have to include >>>> same >>>> css files and jquery.js to configure.jar, which I don't want to do). >>> >>> Excellent plan, we should try to reduce the amount of work, and letting >>> old browsers use the old method is perfectly fine. >>> If FF15 is the only browser that fails with the old method I would even >>> go as far as testing exclusively with FF15 and have anything < FF15 use >>> the old method. >>> >>> Simo. >>> >> >> Updated patches attached. >> >> browserconfig.html points to older config method for versions prior to >> 15. >> >> The extension is theoretically compatible with FF3.6 and then FF10 and >> later. There is a problem for FF4-9 with loading strings from >> .properties file. FF3.6 is working because it doesn't use bootstraping. >> >> I also notice that we have an existing issue when navigating to config >> pages right away before accepting any certificate. Those pages are >> using some resorces from /ui/ folder which is redirected to https. >> These resources are not loaded because certificate isn't imported. If >> user is going straight for Web UI, he won't encounter this issue, but >> someone might. > I tested this patchset and apart from the non-obvious extension > description displayed when installing it, which is based on a certificate, > everything is great. > > ACK. > It works for me too. Just some questions: 1. It looks like the Firefox is limited to version 10 to 15 in install/ffextension/install.rdf. Do we need the upper limit? 10.0 15.0.* 2. In install/html/ssbrowser.html the step 5 is optional. Should we explain what's that for or why we need it? General users could be confused and stuck if they are given choices that they don't understand. It's probably better to make it a required step if it doesn't cause any problem.
  • 5. Optional: Repeat the above procedure for the network.negotiate-auth.delegation-uris entry, using the same domain.
    • -- Endi S. Dewata From abokovoy at redhat.com Fri Oct 5 14:33:08 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 5 Oct 2012 17:33:08 +0300 Subject: [Freeipa-devel] [PATCH] [WIP] Firefox extension In-Reply-To: <506EEDD2.7040909@redhat.com> References: <506B1879.1090501@redhat.com> <506C4296.7060904@redhat.com> <1349273944.22373.89.camel@willson.li.ssimo.org> <506DB5CC.4070003@redhat.com> <20121005135650.GV17454@redhat.com> <506EEDD2.7040909@redhat.com> Message-ID: <20121005143307.GW17454@redhat.com> On Fri, 05 Oct 2012, Endi Sukma Dewata wrote: >On 10/5/2012 8:56 AM, Alexander Bokovoy wrote: >>On Thu, 04 Oct 2012, Petr Vobornik wrote: >>>On 10/03/2012 04:19 PM, Simo Sorce wrote: >>>>On Wed, 2012-10-03 at 15:50 +0200, Petr Vobornik wrote: >>>>>As Alexander proposed in other channel. I will remove the removal of >>>>>configure.jar and offer the old configuration method if user is >>>>>using FF >>>>>< 4 so we don't have to make the extension compatible with this ancient >>>>>version. It will be done this way: >>>>> >>>>>If FF < 4 is detected: >>>>> * in browserconfig.html steps 2 and 3 will be grayed-out and >>>>>replaced >>>>>with step 2a with a link to ssbrowser.html and a description explaining >>>>>the problem >>>>> * ssbrowser.html will be enhanced by steps for autoconfiguration >>>>>of FF >>>>>< 4. >>>>> >>>>>We can also show the steps in browserconfig, but I want to have it >>>>>somehow available even if user is not using FF<4 to keep general >>>>>awareness about the problem and also to be usable if version detection >>>>>fails. Other possible problem with steps in browserconfig is different >>>>>styles of buttons (to keep the same styles we would have to include >>>>>same >>>>>css files and jquery.js to configure.jar, which I don't want to do). >>>> >>>>Excellent plan, we should try to reduce the amount of work, and letting >>>>old browsers use the old method is perfectly fine. >>>>If FF15 is the only browser that fails with the old method I would even >>>>go as far as testing exclusively with FF15 and have anything < FF15 use >>>>the old method. >>>> >>>>Simo. >>>> >>> >>>Updated patches attached. >>> >>>browserconfig.html points to older config method for versions prior to >>>15. >>> >>>The extension is theoretically compatible with FF3.6 and then FF10 and >>>later. There is a problem for FF4-9 with loading strings from >>>.properties file. FF3.6 is working because it doesn't use bootstraping. >>> >>>I also notice that we have an existing issue when navigating to config >>>pages right away before accepting any certificate. Those pages are >>>using some resorces from /ui/ folder which is redirected to https. >>>These resources are not loaded because certificate isn't imported. If >>>user is going straight for Web UI, he won't encounter this issue, but >>>someone might. >>I tested this patchset and apart from the non-obvious extension >>description displayed when installing it, which is based on a certificate, >>everything is great. >> >>ACK. >> > >It works for me too. Just some questions: > >1. It looks like the Firefox is limited to version 10 to 15 in >install/ffextension/install.rdf. Do we need the upper limit? > > 10.0 > 15.0.* > >2. In install/html/ssbrowser.html the step 5 is optional. Should we >explain what's that for or why we need it? General users could be >confused and stuck if they are given choices that they don't >understand. It's probably better to make it a required step if it >doesn't cause any problem. > >
  • 5. Optional: Repeat the above procedure for the >network.negotiate-auth.delegation-uris entry, using the same >domain.
    • delegation-uris setting should be removed. It is not needed since we started using s4u2proxy mechanism. -- / Alexander Bokovoy From simo at redhat.com Fri Oct 5 14:39:20 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 05 Oct 2012 10:39:20 -0400 Subject: [Freeipa-devel] [PATCH] [WIP] Firefox extension In-Reply-To: <20121005143307.GW17454@redhat.com> References: <506B1879.1090501@redhat.com> <506C4296.7060904@redhat.com> <1349273944.22373.89.camel@willson.li.ssimo.org> <506DB5CC.4070003@redhat.com> <20121005135650.GV17454@redhat.com> <506EEDD2.7040909@redhat.com> <20121005143307.GW17454@redhat.com> Message-ID: <1349447960.22373.189.camel@willson.li.ssimo.org> On Fri, 2012-10-05 at 17:33 +0300, Alexander Bokovoy wrote: > On Fri, 05 Oct 2012, Endi Sukma Dewata wrote: > >On 10/5/2012 8:56 AM, Alexander Bokovoy wrote: > >>On Thu, 04 Oct 2012, Petr Vobornik wrote: > >>>On 10/03/2012 04:19 PM, Simo Sorce wrote: > >>>>On Wed, 2012-10-03 at 15:50 +0200, Petr Vobornik wrote: > >>>>>As Alexander proposed in other channel. I will remove the removal of > >>>>>configure.jar and offer the old configuration method if user is > >>>>>using FF > >>>>>< 4 so we don't have to make the extension compatible with this ancient > >>>>>version. It will be done this way: > >>>>> > >>>>>If FF < 4 is detected: > >>>>> * in browserconfig.html steps 2 and 3 will be grayed-out and > >>>>>replaced > >>>>>with step 2a with a link to ssbrowser.html and a description explaining > >>>>>the problem > >>>>> * ssbrowser.html will be enhanced by steps for autoconfiguration > >>>>>of FF > >>>>>< 4. > >>>>> > >>>>>We can also show the steps in browserconfig, but I want to have it > >>>>>somehow available even if user is not using FF<4 to keep general > >>>>>awareness about the problem and also to be usable if version detection > >>>>>fails. Other possible problem with steps in browserconfig is different > >>>>>styles of buttons (to keep the same styles we would have to include > >>>>>same > >>>>>css files and jquery.js to configure.jar, which I don't want to do). > >>>> > >>>>Excellent plan, we should try to reduce the amount of work, and letting > >>>>old browsers use the old method is perfectly fine. > >>>>If FF15 is the only browser that fails with the old method I would even > >>>>go as far as testing exclusively with FF15 and have anything < FF15 use > >>>>the old method. > >>>> > >>>>Simo. > >>>> > >>> > >>>Updated patches attached. > >>> > >>>browserconfig.html points to older config method for versions prior to > >>>15. > >>> > >>>The extension is theoretically compatible with FF3.6 and then FF10 and > >>>later. There is a problem for FF4-9 with loading strings from > >>>.properties file. FF3.6 is working because it doesn't use bootstraping. > >>> > >>>I also notice that we have an existing issue when navigating to config > >>>pages right away before accepting any certificate. Those pages are > >>>using some resorces from /ui/ folder which is redirected to https. > >>>These resources are not loaded because certificate isn't imported. If > >>>user is going straight for Web UI, he won't encounter this issue, but > >>>someone might. > >>I tested this patchset and apart from the non-obvious extension > >>description displayed when installing it, which is based on a certificate, > >>everything is great. > >> > >>ACK. > >> > > > >It works for me too. Just some questions: > > > >1. It looks like the Firefox is limited to version 10 to 15 in > >install/ffextension/install.rdf. Do we need the upper limit? > > > > 10.0 > > 15.0.* > > > >2. In install/html/ssbrowser.html the step 5 is optional. Should we > >explain what's that for or why we need it? General users could be > >confused and stuck if they are given choices that they don't > >understand. It's probably better to make it a required step if it > >doesn't cause any problem. > > > >
  • 5. Optional: Repeat the above procedure for the > >network.negotiate-auth.delegation-uris entry, using the same > >domain.
    • > delegation-uris setting should be removed. It is not needed since we > started using s4u2proxy mechanism. Yes and we removed it because it is potentially a dangerous setting. It should be generally discouraged and enabled only for specific fqdn's not wildcard ones in future. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Fri Oct 5 14:45:47 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 05 Oct 2012 16:45:47 +0200 Subject: [Freeipa-devel] [PATCH] 1059 single CRL generator In-Reply-To: <506EA171.20401@redhat.com> References: <506DB6A8.10504@redhat.com> <506EA171.20401@redhat.com> Message-ID: <506EF29B.8000102@redhat.com> On 10/05/2012 10:59 AM, Martin Kosek wrote: > On 10/04/2012 06:17 PM, Rob Crittenden wrote: >> This changes the way IPA generates CRLs for new installs only. >> >> The first master installed is configured as the CRL generator. An entry is >> added to cn=masters that designates it. >> >> When a replica is installed it queries this entry so it knows where to forward >> CRL requests. CRL files are not available on cloned CAs (so /ipa/crl will >> return not found). It is possible to get a CRL directly from the clone CA via >> http://:9180/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL >> >> rob ... > 3) Majorish issue I hit with the actual CRL publishing on our server (F17). I > always get 403 Forbidden error when trying to download CRL from the CRL master: > > # wget --ca-certificate /etc/ipa/ca.crt https://`hostname`/ipa/crl/MasterCRL.bin > --2012-10-05 03:32:58-- > https://vm-120.idm.lab.bos.redhat.com/ipa/crl/MasterCRL.bin > Resolving vm-120.idm.lab.bos.redhat.com... 10.16.78.120 > Connecting to vm-120.idm.lab.bos.redhat.com|10.16.78.120|:443... connected. > HTTP request sent, awaiting response... 403 Forbidden > 2012-10-05 03:32:58 ERROR 403: Forbidden. > > I tracked the problem down to too strict permission on /var/lib/pki-ca > directory which is being published by httpd which does not have access to it: > > # ll /var/lib/pki-ca > > drwxrwx---. 11 pkiuser pkiuser 4096 Oct 5 03:00 pki-ca > > When I fixed the permission: > # chmod o+x /var/lib/pki-ca/ > > I was able to get pass the Forbidden error and actually retrieved the CRL. > Adding Ade on CC list to follow on this permission issue. FYI - I filed a ticket for this issue: https://fedorahosted.org/freeipa/ticket/3144 I plan to simply fix permission on /var/lib/pki-ca/ in a similar way we do for /var/lib/pki-ca/publish/ Martin From pspacek at redhat.com Fri Oct 5 15:00:14 2012 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 05 Oct 2012 17:00:14 +0200 Subject: [Freeipa-devel] [PATCH 0076] Fix crashes on BIND reload caused by improper error handling during new zone addition Message-ID: <506EF5FE.9090409@redhat.com> Hello, Fix crashes on BIND reload caused by improper error handling during new zone addition. Crash can be triggered by invalid query/transfer/update ACLs or potentially by error in zr_get_zone_ptr(). I found this problem during PATCH 75 testing, so there is a new ticket: https://fedorahosted.org/bind-dyndb-ldap/ticket/93 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0076-Fix-crashes-on-BIND-reload-caused-by-improper-error-.patch Type: text/x-patch Size: 2532 bytes Desc: not available URL: From tbabej at redhat.com Fri Oct 5 15:00:00 2012 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 05 Oct 2012 17:00:00 +0200 Subject: [Freeipa-devel] [PATCH 0017] Improve error message in ipa-replica-manage In-Reply-To: <506AF250.2010404@redhat.com> References: <506AED1B.8010205@redhat.com> <506AF250.2010404@redhat.com> Message-ID: <506EF5F0.6070806@redhat.com> On 10/02/2012 03:55 PM, Rob Crittenden wrote: > Tomas Babej wrote: >> Hi, >> >> When executing ipa-replica-manage connect to an unknown or irrelevant >> master, we now print a sensible error message informing the user >> about this possiblity as well. >> >> https://fedorahosted.org/freeipa/ticket/3105 >> >> Tomas > > I put a whole bunch of code into a try/except and this may be catching > errors in unexpected ways. > > I'm not entirely sure right now what we should do, but looking at the > code in the try: > > repl1.conn.getEntry(master1_dn, ldap.SCOPE_BASE) > repl1.conn.getEntry(master2_dn, ldap.SCOPE_BASE) > > We take in replica1 and replica1 as arguments (the default for > replica1 is the current host). > > If either of these raise a NotFound it means there there is no master > of that name. Does that mean that the master was deleted? Well, > clearly not. > > A lot has changed since I did this, I may have been relying on a > side-effect, or just hadn't tested well-enough. > > I wonder if we need that message at all. Is "foo" is not an IPA server > good enough? It still might be confusing if someone didn't know that > "foo" was deleted and it was still running. We could probably verify > that it is at least an IPA server by doing similar checking in the > client, it all depends on how far we want to take it. > > rob I modified the patch. Now if the NotFound error is encountered, we try to investigate whether we're trying to connect to an IPA server at all. Please see if you have any suggestions. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0017-2-IPA-Server-check-in-ipa-replica-manage.patch Type: text/x-patch Size: 2134 bytes Desc: not available URL: From simo at redhat.com Fri Oct 5 15:29:29 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 05 Oct 2012 11:29:29 -0400 Subject: [Freeipa-devel] [PATCH] Fix up trust attributes on trust-add Message-ID: <1349450969.26127.1.camel@willson.li.ssimo.org> A onliner but better to have it validated by a second pair of eyes. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-499-1-Fix-trust-attributes-for-ipa-trust-add.patch Type: text/x-patch Size: 1130 bytes Desc: not available URL: From rcritten at redhat.com Fri Oct 5 15:30:35 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 05 Oct 2012 11:30:35 -0400 Subject: [Freeipa-devel] [PATCH] [WIP] Firefox extension In-Reply-To: <1349447960.22373.189.camel@willson.li.ssimo.org> References: <506B1879.1090501@redhat.com> <506C4296.7060904@redhat.com> <1349273944.22373.89.camel@willson.li.ssimo.org> <506DB5CC.4070003@redhat.com> <20121005135650.GV17454@redhat.com> <506EEDD2.7040909@redhat.com> <20121005143307.GW17454@redhat.com> <1349447960.22373.189.camel@willson.li.ssimo.org> Message-ID: <506EFD1B.7030901@redhat.com> Simo Sorce wrote: > On Fri, 2012-10-05 at 17:33 +0300, Alexander Bokovoy wrote: >> On Fri, 05 Oct 2012, Endi Sukma Dewata wrote: >>> On 10/5/2012 8:56 AM, Alexander Bokovoy wrote: >>>> On Thu, 04 Oct 2012, Petr Vobornik wrote: >>>>> On 10/03/2012 04:19 PM, Simo Sorce wrote: >>>>>> On Wed, 2012-10-03 at 15:50 +0200, Petr Vobornik wrote: >>>>>>> As Alexander proposed in other channel. I will remove the removal of >>>>>>> configure.jar and offer the old configuration method if user is >>>>>>> using FF >>>>>>> < 4 so we don't have to make the extension compatible with this ancient >>>>>>> version. It will be done this way: >>>>>>> >>>>>>> If FF < 4 is detected: >>>>>>> * in browserconfig.html steps 2 and 3 will be grayed-out and >>>>>>> replaced >>>>>>> with step 2a with a link to ssbrowser.html and a description explaining >>>>>>> the problem >>>>>>> * ssbrowser.html will be enhanced by steps for autoconfiguration >>>>>>> of FF >>>>>>> < 4. >>>>>>> >>>>>>> We can also show the steps in browserconfig, but I want to have it >>>>>>> somehow available even if user is not using FF<4 to keep general >>>>>>> awareness about the problem and also to be usable if version detection >>>>>>> fails. Other possible problem with steps in browserconfig is different >>>>>>> styles of buttons (to keep the same styles we would have to include >>>>>>> same >>>>>>> css files and jquery.js to configure.jar, which I don't want to do). >>>>>> >>>>>> Excellent plan, we should try to reduce the amount of work, and letting >>>>>> old browsers use the old method is perfectly fine. >>>>>> If FF15 is the only browser that fails with the old method I would even >>>>>> go as far as testing exclusively with FF15 and have anything < FF15 use >>>>>> the old method. >>>>>> >>>>>> Simo. >>>>>> >>>>> >>>>> Updated patches attached. >>>>> >>>>> browserconfig.html points to older config method for versions prior to >>>>> 15. >>>>> >>>>> The extension is theoretically compatible with FF3.6 and then FF10 and >>>>> later. There is a problem for FF4-9 with loading strings from >>>>> .properties file. FF3.6 is working because it doesn't use bootstraping. >>>>> >>>>> I also notice that we have an existing issue when navigating to config >>>>> pages right away before accepting any certificate. Those pages are >>>>> using some resorces from /ui/ folder which is redirected to https. >>>>> These resources are not loaded because certificate isn't imported. If >>>>> user is going straight for Web UI, he won't encounter this issue, but >>>>> someone might. >>>> I tested this patchset and apart from the non-obvious extension >>>> description displayed when installing it, which is based on a certificate, >>>> everything is great. >>>> >>>> ACK. >>>> >>> >>> It works for me too. Just some questions: >>> >>> 1. It looks like the Firefox is limited to version 10 to 15 in >>> install/ffextension/install.rdf. Do we need the upper limit? >>> >>> 10.0 >>> 15.0.* >>> >>> 2. In install/html/ssbrowser.html the step 5 is optional. Should we >>> explain what's that for or why we need it? General users could be >>> confused and stuck if they are given choices that they don't >>> understand. It's probably better to make it a required step if it >>> doesn't cause any problem. >>> >>>
  • 5. Optional: Repeat the above procedure for the >>> network.negotiate-auth.delegation-uris entry, using the same >>> domain.
    • >> delegation-uris setting should be removed. It is not needed since we >> started using s4u2proxy mechanism. > > Yes and we removed it because it is potentially a dangerous setting. > It should be generally discouraged and enabled only for specific fqdn's > not wildcard ones in future. > > Simo. > I've pushed these 4 patches to master and ipa-3-0. Petr, please submit a patch to remove/clarify references to delegation-uris setting. rob From simo at redhat.com Fri Oct 5 15:42:06 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 05 Oct 2012 11:42:06 -0400 Subject: [Freeipa-devel] Automatic keytab upgrade In-Reply-To: <50567E3C.5080606@firstyear.id.au> References: <50567E3C.5080606@firstyear.id.au> Message-ID: <1349451726.26127.7.camel@willson.li.ssimo.org> On Mon, 2012-09-17 at 11:04 +0930, William Brown wrote: > Hi, > > In freeipa, we export a keytab for a service. Say we upgrade our freeipa > install, and the newer version of MIT kerberos supports a stronger > encryption type on the KDC. Does freeipa automatically refresh the > keytabs of hosts / services with a new keytab that also contains these > stronger encryption types? Does this matter if it does / doesn't happen? No FreeIPA can't, and it does matter, because FreeIPA doesn't know if the service actually does know how to use new encryption types, but most importantly FreeIPa does not have a mechanism to 'push' this change to the host. Keytabs contains shared (between KDC and service) secrets, so they have to be kept consistent and in sync between the KDC and the service, if the KDC unilaterally changes a keytab the service can't see the changes reflected in its keytab, and when a ticket will come in with the new encryption type it will have no key to decrypt it. Also even if we could somehow push an updated keytab, then if the service doesn't support the new encryption types the outcome would be that authentication would be broken, as the KDC would use the strongest enctype to encrypt tickets sent to clients and the service wouldn't be able to decrypt them even if it has a key. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York From pvoborni at redhat.com Fri Oct 5 15:43:49 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 05 Oct 2012 17:43:49 +0200 Subject: [Freeipa-devel] [PATCH] [WIP] Firefox extension In-Reply-To: <506EFD1B.7030901@redhat.com> References: <506B1879.1090501@redhat.com> <506C4296.7060904@redhat.com> <1349273944.22373.89.camel@willson.li.ssimo.org> <506DB5CC.4070003@redhat.com> <20121005135650.GV17454@redhat.com> <506EEDD2.7040909@redhat.com> <20121005143307.GW17454@redhat.com> <1349447960.22373.189.camel@willson.li.ssimo.org> <506EFD1B.7030901@redhat.com> Message-ID: <506F0035.8030406@redhat.com> On 10/05/2012 05:30 PM, Rob Crittenden wrote: > Simo Sorce wrote: >> On Fri, 2012-10-05 at 17:33 +0300, Alexander Bokovoy wrote: >>> On Fri, 05 Oct 2012, Endi Sukma Dewata wrote: >>>> On 10/5/2012 8:56 AM, Alexander Bokovoy wrote: >>>>> On Thu, 04 Oct 2012, Petr Vobornik wrote: >>>>>> On 10/03/2012 04:19 PM, Simo Sorce wrote: >>>>>>> On Wed, 2012-10-03 at 15:50 +0200, Petr Vobornik wrote: >>>>>>>> As Alexander proposed in other channel. I will remove the >>>>>>>> removal of >>>>>>>> configure.jar and offer the old configuration method if user is >>>>>>>> using FF >>>>>>>> < 4 so we don't have to make the extension compatible with this >>>>>>>> ancient >>>>>>>> version. It will be done this way: >>>>>>>> >>>>>>>> If FF < 4 is detected: >>>>>>>> * in browserconfig.html steps 2 and 3 will be grayed-out and >>>>>>>> replaced >>>>>>>> with step 2a with a link to ssbrowser.html and a description >>>>>>>> explaining >>>>>>>> the problem >>>>>>>> * ssbrowser.html will be enhanced by steps for autoconfiguration >>>>>>>> of FF >>>>>>>> < 4. >>>>>>>> >>>>>>>> We can also show the steps in browserconfig, but I want to have it >>>>>>>> somehow available even if user is not using FF<4 to keep general >>>>>>>> awareness about the problem and also to be usable if version >>>>>>>> detection >>>>>>>> fails. Other possible problem with steps in browserconfig is >>>>>>>> different >>>>>>>> styles of buttons (to keep the same styles we would have to include >>>>>>>> same >>>>>>>> css files and jquery.js to configure.jar, which I don't want to >>>>>>>> do). >>>>>>> >>>>>>> Excellent plan, we should try to reduce the amount of work, and >>>>>>> letting >>>>>>> old browsers use the old method is perfectly fine. >>>>>>> If FF15 is the only browser that fails with the old method I >>>>>>> would even >>>>>>> go as far as testing exclusively with FF15 and have anything < >>>>>>> FF15 use >>>>>>> the old method. >>>>>>> >>>>>>> Simo. >>>>>>> >>>>>> >>>>>> Updated patches attached. >>>>>> >>>>>> browserconfig.html points to older config method for versions >>>>>> prior to >>>>>> 15. >>>>>> >>>>>> The extension is theoretically compatible with FF3.6 and then FF10 >>>>>> and >>>>>> later. There is a problem for FF4-9 with loading strings from >>>>>> .properties file. FF3.6 is working because it doesn't use >>>>>> bootstraping. >>>>>> >>>>>> I also notice that we have an existing issue when navigating to >>>>>> config >>>>>> pages right away before accepting any certificate. Those pages are >>>>>> using some resorces from /ui/ folder which is redirected to https. >>>>>> These resources are not loaded because certificate isn't imported. If >>>>>> user is going straight for Web UI, he won't encounter this issue, but >>>>>> someone might. >>>>> I tested this patchset and apart from the non-obvious extension >>>>> description displayed when installing it, which is based on a >>>>> certificate, >>>>> everything is great. >>>>> >>>>> ACK. >>>>> >>>> >>>> It works for me too. Just some questions: >>>> >>>> 1. It looks like the Firefox is limited to version 10 to 15 in >>>> install/ffextension/install.rdf. Do we need the upper limit? >>>> >>>> 10.0 >>>> 15.0.* My understanding is that maxversion represents maximum tested version. [https://developer.mozilla.org/en-US/docs/Install_Manifests] but the document doesn't say if the extension stops being installable on newer versions. I tried maxversion=14.0.* on FF15 and it worked. >>>> >>>> 2. In install/html/ssbrowser.html the step 5 is optional. Should we >>>> explain what's that for or why we need it? General users could be >>>> confused and stuck if they are given choices that they don't >>>> understand. It's probably better to make it a required step if it >>>> doesn't cause any problem. >>>> >>>>
  • 5. Optional: Repeat the above procedure for the >>>> network.negotiate-auth.delegation-uris entry, using the same >>>> domain.
    • >>> delegation-uris setting should be removed. It is not needed since we >>> started using s4u2proxy mechanism. >> >> Yes and we removed it because it is potentially a dangerous setting. >> It should be generally discouraged and enabled only for specific fqdn's >> not wildcard ones in future. >> >> Simo. >> > > I've pushed these 4 patches to master and ipa-3-0. > > Petr, please submit a patch to remove/clarify references to > delegation-uris setting. Patch attached. > > rob -- -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0220-Removal-of-delegation-uris-instruction-from-browser-.patch Type: text/x-patch Size: 1345 bytes Desc: not available URL: From rcritten at redhat.com Fri Oct 5 15:50:20 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 05 Oct 2012 11:50:20 -0400 Subject: [Freeipa-devel] [PATCH] 1059 single CRL generator In-Reply-To: <506EA171.20401@redhat.com> References: <506DB6A8.10504@redhat.com> <506EA171.20401@redhat.com> Message-ID: <506F01BC.70601@redhat.com> Martin Kosek wrote: > On 10/04/2012 06:17 PM, Rob Crittenden wrote: >> This changes the way IPA generates CRLs for new installs only. >> >> The first master installed is configured as the CRL generator. An entry is >> added to cn=masters that designates it. >> >> When a replica is installed it queries this entry so it knows where to forward >> CRL requests. CRL files are not available on cloned CAs (so /ipa/crl will >> return not found). It is possible to get a CRL directly from the clone CA via >> http://:9180/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL >> >> rob > > I tested new IPA server + replica with your patch and the CRL was now generated > only on the CRL master. I also tried OCSP (though this may not be relevant) and > it worked for me too. > > 1) I do not understand the following block in set_crl_master(self, suffix): > > + try: > + self.admin_conn.addEntry(entry) > + except ldap.ALREADY_EXISTS, e: > + root_logger.debug("failed to set CA as CRL generator") > + raise e > > - when we hit ldap.ALREADY_EXISTS, we are actually OK because cn=CRL is set, right? > - AFAIK, addEntry should return our errors, i.e. errors.DuplicateEntry > - s/raise e/raise/ > > I think you may have wanted to rather catch for more general LDAP error and > then report a real error and not just a debug note. I just wanted to flag this error specifically. It should theoretically never happen because we only do this on new installs. > 2) In get_crl_master: > > + except Exception, e: > + root_logger.debug("Could not connect to the Directory Server on > %s: %s" % (master_host, str(e))) > + raise e > > s/raise e/raise/ > > + except errors.NotFound, e: > + root_logger.debug("failed to find CA CRL generator") > + self.crl_master = None > > - e is actually not used, "except errors.NotFound" would be enough Yeah, I'll remove that. I initially was raising an exception instead of setting crl_master to None, but that wasn't such a nice experience. > 3) Majorish issue I hit with the actual CRL publishing on our server (F17). I > always get 403 Forbidden error when trying to download CRL from the CRL master: > > # wget --ca-certificate /etc/ipa/ca.crt https://`hostname`/ipa/crl/MasterCRL.bin > --2012-10-05 03:32:58-- > https://vm-120.idm.lab.bos.redhat.com/ipa/crl/MasterCRL.bin > Resolving vm-120.idm.lab.bos.redhat.com... 10.16.78.120 > Connecting to vm-120.idm.lab.bos.redhat.com|10.16.78.120|:443... connected. > HTTP request sent, awaiting response... 403 Forbidden > 2012-10-05 03:32:58 ERROR 403: Forbidden. > > I tracked the problem down to too strict permission on /var/lib/pki-ca > directory which is being published by httpd which does not have access to it: > > # ll /var/lib/pki-ca > > drwxrwx---. 11 pkiuser pkiuser 4096 Oct 5 03:00 pki-ca > > When I fixed the permission: > # chmod o+x /var/lib/pki-ca/ > > I was able to get pass the Forbidden error and actually retrieved the CRL. > Adding Ade on CC list to follow on this permission issue. > > > I was thinking about usability of this new approach, we may want to make user > life easier in a perspective of CRL master managing. I have following > enhancements in mind: > > - mark CRL master in ipa-replica-manage list, or ipa-csreplica-manage list: > > # ipa-csreplica-manage list > Directory Manager password: > > vm-065.idm.lab.bos.redhat.com: master [CRL] > vm-120.idm.lab.bos.redhat.com: master > > - when removing master with CRL by "ipa-replica-manage del" we should warn user > and inform him what he should do next to amend the situation. I am thinking > about 2 new commands for ipa-csreplica-manage: > > * ipa-csreplica-manage crl-promote > - promote current master as the new CRL master, enable CRL generation in > CS.cfg, mark master as the new CRL master in cn=masters > * ipa-csreplica-manage crl-update > - update CS.cfg of current CA replica and point master.ca.agent.* to current > CRL master > > I can work on those enhancements if we agree on them. I think the display and warning parts would be quite easy. The promotion a bit more challenging and invasive. I think documentation would be adequate for a first stab a this. rob From rcritten at redhat.com Fri Oct 5 15:53:03 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 05 Oct 2012 11:53:03 -0400 Subject: [Freeipa-devel] [PATCH] [WIP] Firefox extension In-Reply-To: <506F0035.8030406@redhat.com> References: <506B1879.1090501@redhat.com> <506C4296.7060904@redhat.com> <1349273944.22373.89.camel@willson.li.ssimo.org> <506DB5CC.4070003@redhat.com> <20121005135650.GV17454@redhat.com> <506EEDD2.7040909@redhat.com> <20121005143307.GW17454@redhat.com> <1349447960.22373.189.camel@willson.li.ssimo.org> <506EFD1B.7030901@redhat.com> <506F0035.8030406@redhat.com> Message-ID: <506F025F.7090503@redhat.com> Petr Vobornik wrote: > On 10/05/2012 05:30 PM, Rob Crittenden wrote: >> Simo Sorce wrote: >>> On Fri, 2012-10-05 at 17:33 +0300, Alexander Bokovoy wrote: >>>> On Fri, 05 Oct 2012, Endi Sukma Dewata wrote: >>>>> On 10/5/2012 8:56 AM, Alexander Bokovoy wrote: >>>>>> On Thu, 04 Oct 2012, Petr Vobornik wrote: >>>>>>> On 10/03/2012 04:19 PM, Simo Sorce wrote: >>>>>>>> On Wed, 2012-10-03 at 15:50 +0200, Petr Vobornik wrote: >>>>>>>>> As Alexander proposed in other channel. I will remove the >>>>>>>>> removal of >>>>>>>>> configure.jar and offer the old configuration method if user is >>>>>>>>> using FF >>>>>>>>> < 4 so we don't have to make the extension compatible with this >>>>>>>>> ancient >>>>>>>>> version. It will be done this way: >>>>>>>>> >>>>>>>>> If FF < 4 is detected: >>>>>>>>> * in browserconfig.html steps 2 and 3 will be grayed-out and >>>>>>>>> replaced >>>>>>>>> with step 2a with a link to ssbrowser.html and a description >>>>>>>>> explaining >>>>>>>>> the problem >>>>>>>>> * ssbrowser.html will be enhanced by steps for >>>>>>>>> autoconfiguration >>>>>>>>> of FF >>>>>>>>> < 4. >>>>>>>>> >>>>>>>>> We can also show the steps in browserconfig, but I want to have it >>>>>>>>> somehow available even if user is not using FF<4 to keep general >>>>>>>>> awareness about the problem and also to be usable if version >>>>>>>>> detection >>>>>>>>> fails. Other possible problem with steps in browserconfig is >>>>>>>>> different >>>>>>>>> styles of buttons (to keep the same styles we would have to >>>>>>>>> include >>>>>>>>> same >>>>>>>>> css files and jquery.js to configure.jar, which I don't want to >>>>>>>>> do). >>>>>>>> >>>>>>>> Excellent plan, we should try to reduce the amount of work, and >>>>>>>> letting >>>>>>>> old browsers use the old method is perfectly fine. >>>>>>>> If FF15 is the only browser that fails with the old method I >>>>>>>> would even >>>>>>>> go as far as testing exclusively with FF15 and have anything < >>>>>>>> FF15 use >>>>>>>> the old method. >>>>>>>> >>>>>>>> Simo. >>>>>>>> >>>>>>> >>>>>>> Updated patches attached. >>>>>>> >>>>>>> browserconfig.html points to older config method for versions >>>>>>> prior to >>>>>>> 15. >>>>>>> >>>>>>> The extension is theoretically compatible with FF3.6 and then FF10 >>>>>>> and >>>>>>> later. There is a problem for FF4-9 with loading strings from >>>>>>> .properties file. FF3.6 is working because it doesn't use >>>>>>> bootstraping. >>>>>>> >>>>>>> I also notice that we have an existing issue when navigating to >>>>>>> config >>>>>>> pages right away before accepting any certificate. Those pages are >>>>>>> using some resorces from /ui/ folder which is redirected to https. >>>>>>> These resources are not loaded because certificate isn't >>>>>>> imported. If >>>>>>> user is going straight for Web UI, he won't encounter this issue, >>>>>>> but >>>>>>> someone might. >>>>>> I tested this patchset and apart from the non-obvious extension >>>>>> description displayed when installing it, which is based on a >>>>>> certificate, >>>>>> everything is great. >>>>>> >>>>>> ACK. >>>>>> >>>>> >>>>> It works for me too. Just some questions: >>>>> >>>>> 1. It looks like the Firefox is limited to version 10 to 15 in >>>>> install/ffextension/install.rdf. Do we need the upper limit? >>>>> >>>>> 10.0 >>>>> 15.0.* > > My understanding is that maxversion represents maximum tested version. > [https://developer.mozilla.org/en-US/docs/Install_Manifests] but the > document doesn't say if the extension stops being installable on newer > versions. I tried maxversion=14.0.* on FF15 and it worked. > >>>>> >>>>> 2. In install/html/ssbrowser.html the step 5 is optional. Should we >>>>> explain what's that for or why we need it? General users could be >>>>> confused and stuck if they are given choices that they don't >>>>> understand. It's probably better to make it a required step if it >>>>> doesn't cause any problem. >>>>> >>>>>
  • 5. Optional: Repeat the above procedure for the >>>>> network.negotiate-auth.delegation-uris entry, using the same >>>>> domain.
    • >>>> delegation-uris setting should be removed. It is not needed since we >>>> started using s4u2proxy mechanism. >>> >>> Yes and we removed it because it is potentially a dangerous setting. >>> It should be generally discouraged and enabled only for specific fqdn's >>> not wildcard ones in future. >>> >>> Simo. >>> >> >> I've pushed these 4 patches to master and ipa-3-0. >> >> Petr, please submit a patch to remove/clarify references to >> delegation-uris setting. > > Patch attached. > >> >> rob > > ACK, pushed to master and ipa-3-0 rob From alee at redhat.com Fri Oct 5 16:19:04 2012 From: alee at redhat.com (Ade Lee) Date: Fri, 05 Oct 2012 12:19:04 -0400 Subject: [Freeipa-devel] [PATCH] 1059 single CRL generator In-Reply-To: <506EF29B.8000102@redhat.com> References: <506DB6A8.10504@redhat.com> <506EA171.20401@redhat.com> <506EF29B.8000102@redhat.com> Message-ID: <1349453945.19017.18.camel@aleeredhat.laptop> On Fri, 2012-10-05 at 16:45 +0200, Martin Kosek wrote: > On 10/05/2012 10:59 AM, Martin Kosek wrote: > > On 10/04/2012 06:17 PM, Rob Crittenden wrote: > >> This changes the way IPA generates CRLs for new installs only. > >> > >> The first master installed is configured as the CRL generator. An entry is > >> added to cn=masters that designates it. > >> > >> When a replica is installed it queries this entry so it knows where to forward > >> CRL requests. CRL files are not available on cloned CAs (so /ipa/crl will > >> return not found). It is possible to get a CRL directly from the clone CA via > >> http://:9180/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL > >> > >> rob > > ... > > > 3) Majorish issue I hit with the actual CRL publishing on our server (F17). I > > always get 403 Forbidden error when trying to download CRL from the CRL master: > > > > # wget --ca-certificate /etc/ipa/ca.crt https://`hostname`/ipa/crl/MasterCRL.bin > > --2012-10-05 03:32:58-- > > https://vm-120.idm.lab.bos.redhat.com/ipa/crl/MasterCRL.bin > > Resolving vm-120.idm.lab.bos.redhat.com... 10.16.78.120 > > Connecting to vm-120.idm.lab.bos.redhat.com|10.16.78.120|:443... connected. > > HTTP request sent, awaiting response... 403 Forbidden > > 2012-10-05 03:32:58 ERROR 403: Forbidden. > > > > I tracked the problem down to too strict permission on /var/lib/pki-ca > > directory which is being published by httpd which does not have access to it: > > > > # ll /var/lib/pki-ca > > > > drwxrwx---. 11 pkiuser pkiuser 4096 Oct 5 03:00 pki-ca > > > > When I fixed the permission: > > # chmod o+x /var/lib/pki-ca/ > > > > I was able to get pass the Forbidden error and actually retrieved the CRL. > > Adding Ade on CC list to follow on this permission issue. > > FYI - I filed a ticket for this issue: > https://fedorahosted.org/freeipa/ticket/3144 > > I plan to simply fix permission on /var/lib/pki-ca/ in a similar way we do for > /var/lib/pki-ca/publish/ > Sorry, but why do you need permissions on /var/lib/pki-ca? Aren't permissions on /var/lib/pki-ca/publish sufficient? > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From pvoborni at redhat.com Fri Oct 5 16:22:12 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 05 Oct 2012 18:22:12 +0200 Subject: [Freeipa-devel] [PATCH] 0082/0083 Handle NotFound exception when establishing trust In-Reply-To: <20121005132424.GQ17454@redhat.com> References: <20121004150613.GP17454@redhat.com> <506EB9D1.3090604@redhat.com> <20121005132424.GQ17454@redhat.com> Message-ID: <506F0934.1070406@redhat.com> On 10/05/2012 03:24 PM, Alexander Bokovoy wrote: > On Fri, 05 Oct 2012, Petr Vobornik wrote: >> On 10/04/2012 05:06 PM, Alexander Bokovoy wrote: >>> >>> Hi, >>> >>> two attached patches attempt to solve >>> https://fedorahosted.org/freeipa/ticket/3103 >>> >>> We cannot make educated guess where trusted domain's DNS server is >>> located as we ended up with NotFound exception precisely because we were >>> unable to discover trusted domain's domain controller location. >>> >>> Thus, all we can do is to suggest ways to fix the issue. Since >>> suggestion becomes relatively long (multi-line, at least), it creates >>> few issues for current exception error message handling: >>> - root_logger does not use textui to format output >>> - textui is only printing to standard output >>> - multi-line error messages thus become non-wrapped >>> - localizing such messages would become a harder context-wise. >>> >>> Web UI is showing error message as a single paragraph (

    ), all >>> multi-line markup would be lost. >>> >>> In the end, I decided to support list-based multi-line error messages in >>> PublicError class. Its constructor will join all list-based arguments >>> into single string per argument (first patch). >>> >>> In Web UI I've added special text processing of error messages that >>> splits message into multiple lines and wraps those which start with a >>> TAB symbol into 'error-message-hinted' span to visually separate it from >>> the rest of error message. Trust code uses this to display suggested CLI >>> command to set up DNS forwarder (second patch). >>> >>> In the end, CLI shows such error message fine (note tabulated CLI >>> command): >>> ----------------------------------------------------------------------- >>> # ipa trust-add --type=ad --admin Administrator at ad.local1 --password >>> ad.local1 >>> Active directory domain administrator's password: ipa: ERROR: Unable to >>> resolve domain controller for 'ad.local1' domain. IPA manages DNS, >>> please configure forwarder to 'ad.local1' domain by using following CLI >>> command. Please replace DNS_SERVER and IP_ADDRESS by name and address of >>> the domain's name server: >>> ipa dnszone-add ad.local1 --name-server=DNS_SERVER >>> --admin-email='hostmaster at ad.local1' --force --forwarder=IP_ADDRESS >>> --forward-policy=only >>> When using Web UI, please create DNS zone for domain 'ad.local1' first >>> and then set forwarder and forward policy >>> ----------------------------------------------------------------------- >>> >>> Web UI looks like this: http://abbra.fedorapeople.org/.paste/ui.png >>> >>> >> >> You have undeclared identifier: lines. >> >> I recommend to run `jsl -conf jsl.conf` command in install/ui folder >> to prevent these issues. > Fixed. > > >> I'm not convinced that "beautify" call should be in command object. I >> would rather see it in error_dialog. > I moved everything to error_dialog and used $() selectors instead of > directly playing with text. 1) + var error_message = $('', {}); I would rather see a

    as a container. Span is and should contain only inline elements. 2) var line_span = $('', { class: 'error-message-hinted', text: lines[i].substr(1) }).appendTo(container); Why do you use for hinted message and

    for other lines? Shouldn't we use

    for both? 3) var line_span is declared twice. JS use function scope, not block scope. > >> I'm not sure that all tabbed error text should be red. But I don't >> recall any other usage so it's probably OK. > We don't have any, this is first one. > > -- Petr Vobornik From simo at redhat.com Fri Oct 5 16:26:28 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 05 Oct 2012 12:26:28 -0400 Subject: [Freeipa-devel] [PATCH] 1059 single CRL generator In-Reply-To: <1349453945.19017.18.camel@aleeredhat.laptop> References: <506DB6A8.10504@redhat.com> <506EA171.20401@redhat.com> <506EF29B.8000102@redhat.com> <1349453945.19017.18.camel@aleeredhat.laptop> Message-ID: <1349454388.26127.9.camel@willson.li.ssimo.org> On Fri, 2012-10-05 at 12:19 -0400, Ade Lee wrote: > On Fri, 2012-10-05 at 16:45 +0200, Martin Kosek wrote: > > On 10/05/2012 10:59 AM, Martin Kosek wrote: > > > On 10/04/2012 06:17 PM, Rob Crittenden wrote: > > >> This changes the way IPA generates CRLs for new installs only. > > >> > > >> The first master installed is configured as the CRL generator. An entry is > > >> added to cn=masters that designates it. > > >> > > >> When a replica is installed it queries this entry so it knows where to forward > > >> CRL requests. CRL files are not available on cloned CAs (so /ipa/crl will > > >> return not found). It is possible to get a CRL directly from the clone CA via > > >> http://:9180/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL > > >> > > >> rob > > > > ... > > > > > 3) Majorish issue I hit with the actual CRL publishing on our server (F17). I > > > always get 403 Forbidden error when trying to download CRL from the CRL master: > > > > > > # wget --ca-certificate /etc/ipa/ca.crt https://`hostname`/ipa/crl/MasterCRL.bin > > > --2012-10-05 03:32:58-- > > > https://vm-120.idm.lab.bos.redhat.com/ipa/crl/MasterCRL.bin > > > Resolving vm-120.idm.lab.bos.redhat.com... 10.16.78.120 > > > Connecting to vm-120.idm.lab.bos.redhat.com|10.16.78.120|:443... connected. > > > HTTP request sent, awaiting response... 403 Forbidden > > > 2012-10-05 03:32:58 ERROR 403: Forbidden. > > > > > > I tracked the problem down to too strict permission on /var/lib/pki-ca > > > directory which is being published by httpd which does not have access to it: > > > > > > # ll /var/lib/pki-ca > > > > > > drwxrwx---. 11 pkiuser pkiuser 4096 Oct 5 03:00 pki-ca > > > > > > When I fixed the permission: > > > # chmod o+x /var/lib/pki-ca/ > > > > > > I was able to get pass the Forbidden error and actually retrieved the CRL. > > > Adding Ade on CC list to follow on this permission issue. > > > > FYI - I filed a ticket for this issue: > > https://fedorahosted.org/freeipa/ticket/3144 > > > > I plan to simply fix permission on /var/lib/pki-ca/ in a similar way we do for > > /var/lib/pki-ca/publish/ > > > > Sorry, but why do you need permissions on /var/lib/pki-ca? Aren't > permissions on /var/lib/pki-ca/publish sufficient? Ade, on unix filesystems you cannot traverse a directory path if you do not have permission all the way through. If 'others' can't access /var/lib/pki-ca they will never even reach the point where they can see that they have access to a subdirectory. The very minimum permission you need to be able to traverse directories is to have the 'traverse' (x) bit set. (note that you do not need the read (r) bit set just to traverse). Simo. -- Simo Sorce * Red Hat, Inc * New York From sbose at redhat.com Fri Oct 5 16:34:25 2012 From: sbose at redhat.com (Sumit Bose) Date: Fri, 5 Oct 2012 18:34:25 +0200 Subject: [Freeipa-devel] [PATCH] 75-78 Add fallback group In-Reply-To: <1349444758.22373.187.camel@willson.li.ssimo.org> References: <20121002192901.GV6816@localhost.localdomain> <1349207792.22373.64.camel@willson.li.ssimo.org> <20121005132752.GR17454@redhat.com> <1349444758.22373.187.camel@willson.li.ssimo.org> Message-ID: <20121005163425.GI6816@localhost.localdomain> On Fri, Oct 05, 2012 at 09:45:58AM -0400, Simo Sorce wrote: > On Fri, 2012-10-05 at 16:27 +0300, Alexander Bokovoy wrote: > > On Tue, 02 Oct 2012, Simo Sorce wrote: > > >On Tue, 2012-10-02 at 21:29 +0200, Sumit Bose wrote: > > >> Hi, > > >> > > >> this patch should fix https://fedorahosted.org/freeipa/ticket/2955 by > > >> adding a fallback group as described in comment 2 of the ticket in > > >> ipa-adtrust-install. > > >> > > >> If you prefer to use a different kind of group I can change the patch > > >> accordingly. > > Patch works for me, so ACK except the group name. > > > > >Yes I think we should use a more natural group name. In my recent > > >testing I have been using the name 'Trust Users' that pairs well with > > >another group we create called 'Trust Admins'. But I am open to > > >suggestions on a better name, 'Domain Users' may be better if we really > > >want to associate the wellknown SID to this group. > > I'm fine with 'Trust Users'. > > > > >On the SID side I wonder if using the wellknown 'Domain Users' SID is > > >the right thing to do. I do not see any special reasons why it shouldn't > > >but I also do not have any special reason why we should. > > >Anyone can think of any pros/cons of doing that ? > > Since it only has special meaning within the same domain and we are not > > using it for anything, it should be fine. > > Well it has a special meaning for samba servers ... we may have a few in > the IPA domain. > I think using that SID is fine but I think then the name 'Trust Users' > could be confusing to users looking at permissions. > > We also need to make the group a posix group btw, because samba uses the > Primary Group SID for users and if it can't be resolved to uid/gids it > will probably prevent authentication. > > What about calling it 'Default SMB Group' or similar ? > > Simo. ok new version attached. The group is now a Posix with an automatically assigned SID called 'default_smb_group' and in the protected list. bye, Sumit > > -- > Simo Sorce * Red Hat, Inc * New York > -------------- next part -------------- From f48001acd9b8b6719e118fbc620204a788378922 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 18 Sep 2012 11:32:10 +0200 Subject: [PATCH] ipa-adtrust-install: Add fallback group --- ipalib/plugins/group.py | 2 +- ipaserver/install/adtrustinstance.py | 104 +++++++++++++++++++++++++++++++---- 2 Dateien ge?ndert, 93 Zeilen hinzugef?gt(+), 13 Zeilen entfernt(-) diff --git a/ipalib/plugins/group.py b/ipalib/plugins/group.py index 45758d320bb58f3933938ce579d211a83d56ce09..1611e422bbef3d1ee9c71a819b7f9cc13cd819ab 100644 --- a/ipalib/plugins/group.py +++ b/ipalib/plugins/group.py @@ -107,7 +107,7 @@ Example: ipa group-add-member ad_admins --groups ad_admins_external """) -PROTECTED_GROUPS = (u'admins', u'trust admins') +PROTECTED_GROUPS = (u'admins', u'trust admins', u'default_smb_group') class group(LDAPObject): """ diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py index c44037754dfd74cf6a9ceda4c9f4d2a6a224b1ea..fe44ef36dab1c124c062db84207995adb4649723 100644 --- a/ipaserver/install/adtrustinstance.py +++ b/ipaserver/install/adtrustinstance.py @@ -22,6 +22,7 @@ import errno import ldap import tempfile import uuid +import krbV from ipaserver import ipaldap from ipaserver.install import installutils from ipaserver.install import service @@ -96,9 +97,11 @@ class ADTRUSTInstance(service.Service): ATTR_SID = "ipaNTSecurityIdentifier" ATTR_FLAT_NAME = "ipaNTFlatName" ATTR_GUID = "ipaNTDomainGUID" + ATTR_FALLBACK_GROUP = "ipaNTFallbackPrimaryGroup" OBJC_USER = "ipaNTUserAttrs" OBJC_GROUP = "ipaNTGroupAttrs" OBJC_DOMAIN = "ipaNTDomainAttrs" + FALLBACK_GROUP_NAME = u'Default_SMB_Group' def __init__(self, fstore=None): self.fqdn = None @@ -134,6 +137,18 @@ class ADTRUSTInstance(service.Service): return "S-1-5-21-%d-%d-%d" % (sub_ids[0], sub_ids[1], sub_ids[2]) def __add_admin_sids(self): + """ + The IPA admin and the IPA admins group with get the well knows SIDs + used by AD for the administrator and the administrator group. + Additonally the well know domain users SID will be assinged to a + special fallback group. + + By default new users belong only to a user private group (UPG) and no + other Posix group since ipausers is not a Posix group anymore. To be + able to add a RID to the primary RID attribute in a PAC a fallback + group is added. + """ + admin_dn = DN(('uid', 'admin'), api.env.container_user, self.suffix) admin_group_dn = DN(('cn', 'admins'), api.env.container_group, @@ -163,24 +178,88 @@ class ADTRUSTInstance(service.Service): print "IPA admin group object not found" return - if admin_entry.getValue(self.ATTR_SID) or \ - admin_group_entry.getValue(self.ATTR_SID): - print "Admin SID already set, nothing to do" + if admin_entry.getValue(self.ATTR_SID): + self.print_msg("Admin SID already set, nothing to do") + else: + try: + self.admin_conn.modify_s(admin_dn, \ + [(ldap.MOD_ADD, "objectclass", self.OBJC_USER), \ + (ldap.MOD_ADD, self.ATTR_SID, dom_sid + "-500")]) + except: + self.print_msg("Failed to modify IPA admin object") + + if admin_group_entry.getValue(self.ATTR_SID): + self.print_msg("Admin group SID already set, nothing to do") + else: + try: + self.admin_conn.modify_s(admin_group_dn, \ + [(ldap.MOD_ADD, "objectclass", self.OBJC_GROUP), \ + (ldap.MOD_ADD, self.ATTR_SID, dom_sid + "-512")]) + except: + self.print_msg("Failed to modify IPA admin group object") + + + def __add_fallback_group(self): + """ + By default new users belong only to a user private group (UPG) and no + other Posix group since ipausers is not a Posix group anymore. To be + able to add a RID to the primary RID attribute in a PAC a fallback + group is added. + + Since this method must be run after a restart of the directory server + to enable the sidgen plugin we have to reconnect to the directory + server. + """ + + self.ldap_connect() + try: + ctx = krbV.default_context() + ccache = ctx.default_ccache() + except krbV.Krb5Error, e: + sys.exit("Must have Kerberos credentials to setup AD trusts on server") + + try: + api.Backend.ldap2.disconnect() + api.Backend.ldap2.connect(ccache.name) + except errors.ACIError, e: + sys.exit("Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket") + except errors.DatabaseError, e: + sys.exit("Cannot connect to the LDAP database. Please check if IPA is running") + + try: + dom_entry = self.admin_conn.getEntry(self.smb_dom_dn, \ + ldap.SCOPE_BASE) + except errors.NotFound: + self.print_msg("Samba domain object not found") return + if dom_entry.getValue(self.ATTR_FALLBACK_GROUP): + self.print_msg("Fallback group already set, nothing to do") + return + + fb_group_dn = DN(('cn', self.FALLBACK_GROUP_NAME), + api.env.container_group, self.suffix) try: - self.admin_conn.modify_s(admin_dn, \ - [(ldap.MOD_ADD, "objectclass", self.OBJC_USER), \ - (ldap.MOD_ADD, self.ATTR_SID, dom_sid + "-500")]) - except: - print "Failed to modify IPA admin object" + self.admin_conn.getEntry(fb_group_dn, ldap.SCOPE_BASE) + except errors.NotFound: + try: + fallback = api.Command['group_add'](self.FALLBACK_GROUP_NAME, + description= u'Fallback group for ' \ + 'primary group RID, ' \ + 'do not add user to ' \ + 'this group', + nonposix=False) + fb_group_dn = fallback['result']['dn'] + except Exception, e: + self.print_msg("Failed to add fallback group.") + raise e try: - self.admin_conn.modify_s(admin_group_dn, \ - [(ldap.MOD_ADD, "objectclass", self.OBJC_GROUP), \ - (ldap.MOD_ADD, self.ATTR_SID, dom_sid + "-512")]) + mod = [(ldap.MOD_ADD, self.ATTR_FALLBACK_GROUP, + fallback['result']['dn'])] + self.admin_conn.modify_s(self.smb_dom_dn, mod) except: - print "Failed to modify IPA admin group object" + self.print_msg("Failed to add fallback group to domain object") def __add_rid_bases(self): """ @@ -612,6 +691,7 @@ class ADTRUSTInstance(service.Service): self.__add_dns_service_records) self.step("restarting Directory Server to take MS PAC and LDAP plugins changes into account", \ self.__restart_dirsrv) + self.step("adding fallback group", self.__add_fallback_group) self.step("setting SELinux booleans", \ self.__configure_selinux_for_smbd) self.step("starting CIFS services", self.__start) -- 1.7.11.4 -------------- next part -------------- From 0071498c8e5f29e1541cbc8b8674dc62d9e7c556 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 18 Sep 2012 11:35:57 +0200 Subject: [PATCH 76/78] ipa-adtrust-install: replace print with self.print_msg --- ipaserver/install/adtrustinstance.py | 28 ++++++++++++++-------------- 1 Datei ge?ndert, 14 Zeilen hinzugef?gt(+), 14 Zeilen entfernt(-) diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py index fe44ef36dab1c124c062db84207995adb4649723..cdad99c8ec994a1170ed58a8b31596bca03c89a6 100644 --- a/ipaserver/install/adtrustinstance.py +++ b/ipaserver/install/adtrustinstance.py @@ -157,25 +157,25 @@ class ADTRUSTInstance(service.Service): dom_entry = self.admin_conn.getEntry(self.smb_dom_dn, \ ldap.SCOPE_BASE) except errors.NotFound: - print "Samba domain object not found" + self.print_msg("Samba domain object not found") return dom_sid = dom_entry.getValue(self.ATTR_SID) if not dom_sid: - print "Samba domain object does not have a SID" + self.print_msg("Samba domain object does not have a SID") return try: admin_entry = self.admin_conn.getEntry(admin_dn, ldap.SCOPE_BASE) except: - print "IPA admin object not found" + self.print_msg("IPA admin object not found") return try: admin_group_entry = self.admin_conn.getEntry(admin_group_dn, \ ldap.SCOPE_BASE) except: - print "IPA admin group object not found" + self.print_msg("IPA admin group object not found") return if admin_entry.getValue(self.ATTR_SID): @@ -279,13 +279,13 @@ class ADTRUSTInstance(service.Service): if res[0].getValue('ipaBaseRID') or \ res[0].getValue('ipaSecondaryBaseRID'): - print "RID bases already set, nothing to do" + self.print_msg("RID bases already set, nothing to do") return size = res[0].getValue('ipaIDRangeSize') if abs(self.rid_base - self.secondary_rid_base) > size: - print "Primary and secondary RID base are too close. " \ - "They have to differ at least by %d." % size + self.print_msg("Primary and secondary RID base are too close. " \ + "They have to differ at least by %d." % size) raise RuntimeError("RID bases too close.\n") try: @@ -295,7 +295,7 @@ class ADTRUSTInstance(service.Service): (ldap.MOD_ADD, "ipaSecondaryBaseRID", \ str(self.secondary_rid_base))]) except: - print "Failed to add RID bases to the local range object" + self.print_msg("Failed to add RID bases to the local range object") except errors.NotFound as e: root_logger.critical("ID range of the local domain not found, " \ @@ -322,8 +322,8 @@ class ADTRUSTInstance(service.Service): try: name = new_dn[1].attr except Exception, e: - print 'Cannot extract RDN attribute value from "%s": %s' % \ - (new_dn, e) + self.print_msg('Cannot extract RDN attribute value from "%s": %s' % \ + (new_dn, e)) return entry.setValues("cn", name) self.admin_conn.addEntry(entry) @@ -440,12 +440,12 @@ class ADTRUSTInstance(service.Service): "as it is not defined in IPA" % zone if err_msg: - print err_msg - print "Add the following service records to your DNS server " \ - "for DNS zone %s: " % zone + self.print_msg(err_msg) + self.print_msg("Add the following service records to your DNS " \ + "server for DNS zone %s: " % zone) for (srv, rdata) in ipa_srv_rec: for suff in win_srv_suffix: - print " - %s%s" % (srv, suff) + self.print_msg(" - %s%s" % (srv, suff)) return for (srv, rdata) in ipa_srv_rec: -- 1.7.11.4 -------------- next part -------------- From 2fb8f182b2dd465c1c5ac9a0b6ca33c15d21971f Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Mon, 24 Sep 2012 17:25:07 +0200 Subject: [PATCH 77/78] ipasam: add fallback primary group --- daemons/ipa-sam/ipa_sam.c | 237 ++++++++++++++++++++++++++++++++++++++++++++-- 1 Datei ge?ndert, 230 Zeilen hinzugef?gt(+), 7 Zeilen entfernt(-) diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c index db300022af0a29c32a2df5e5ef2bc12f39ed2886..2453eb09ce1d168c3d4389c09265cd63d65c5c9d 100644 --- a/daemons/ipa-sam/ipa_sam.c +++ b/daemons/ipa-sam/ipa_sam.c @@ -121,6 +121,8 @@ bool secrets_store(const char *key, const void *data, size_t size); /* available #define LDAP_ATTRIBUTE_LOGON_SCRIPT "ipaNTLogonScript" #define LDAP_ATTRIBUTE_PROFILE_PATH "ipaNTProfilePath" #define LDAP_ATTRIBUTE_NTHASH "ipaNTHash" +#define LDAP_ATTRIBUTE_UIDNUMBER "uidnumber" +#define LDAP_ATTRIBUTE_GIDNUMBER "gidnumber" #define LDAP_OBJ_KRB_PRINCIPAL "krbPrincipal" #define LDAP_OBJ_KRB_PRINCIPAL_AUX "krbPrincipalAux" @@ -155,7 +157,7 @@ struct ipasam_privates { char *base_dn; char *trust_dn; char *flat_name; - char *fallback_primary_group; + struct dom_sid fallback_primary_group; char *server_princ; char *client_princ; struct sss_idmap_ctx *idmap_ctx; @@ -2677,6 +2679,141 @@ static bool ipasam_nthash_regen(struct ldapsam_privates *ldap_state, return (ret == LDAP_SUCCESS); } +static int ipasam_get_sid_by_gid(struct ldapsam_privates *ldap_state, + uint32_t gid, + struct dom_sid *_sid) +{ + int ret; + char *filter; + TALLOC_CTX *tmp_ctx; + LDAPMessage *entry = NULL; + LDAPMessage *result = NULL; + char *sid_str = NULL; + struct dom_sid *sid = NULL; + int count; + enum idmap_error_code err; + + tmp_ctx = talloc_new("ipasam_get_sid_by_gid"); + if (tmp_ctx == NULL) { + return ENOMEM; + } + + filter = talloc_asprintf(tmp_ctx, "(&(%s=%s)(%s=%lu))", + LDAP_ATTRIBUTE_OBJECTCLASS, + LDAP_OBJ_POSIXGROUP, + LDAP_ATTRIBUTE_GIDNUMBER, + (unsigned long) gid); + if (filter == NULL) { + ret = ENOMEM; + goto done; + } + + ret = smbldap_search(ldap_state->smbldap_state, + ldap_state->ipasam_privates->base_dn, + LDAP_SCOPE_SUBTREE,filter, NULL, 0, + &result); + if (ret != LDAP_SUCCESS) { + ret = ENOENT; + goto done; + } + + count = ldap_count_entries(ldap_state->smbldap_state->ldap_struct, + result); + if (count != 1) { + ret = ENOENT; + goto done; + } + + entry = ldap_first_entry(ldap_state->smbldap_state->ldap_struct, result); + if (entry == NULL) { + ret = ENOENT; + goto done; + } + + sid_str = get_single_attribute(tmp_ctx, + ldap_state->smbldap_state->ldap_struct, + entry, LDAP_ATTRIBUTE_SID); + if (sid_str == NULL) { + ret = ENOENT; + goto done; + } + + err = sss_idmap_sid_to_smb_sid(ldap_state->ipasam_privates->idmap_ctx, + sid_str, &sid); + if (err != IDMAP_SUCCESS) { + ret = EFAULT; + goto done; + } + sid_copy(_sid, sid); + + ret = 0; + +done: + talloc_free(sid); + ldap_msgfree(result); + talloc_free(tmp_ctx); + + return ret; +} + +static int ipasam_get_primary_group_sid(TALLOC_CTX *mem_ctx, + struct ldapsam_privates *ldap_state, + LDAPMessage *entry, + struct dom_sid **_group_sid) +{ + int ret; + uint32_t uid; + uint32_t gid; + struct dom_sid *group_sid; + + TALLOC_CTX *tmp_ctx = talloc_init("ipasam_get_primary_group_sid"); + if (tmp_ctx == NULL) { + return ENOMEM; + } + + if (!get_uint32_t_from_ldap_msg(ldap_state, entry, + LDAP_ATTRIBUTE_UIDNUMBER, &uid)) { + ret = ENOENT; + DEBUG(1, ("No uidnumber attribute found for this user!\n")); + goto done; + } + + if (!get_uint32_t_from_ldap_msg(ldap_state, entry, + LDAP_ATTRIBUTE_GIDNUMBER, &gid)) { + ret = ENOENT; + DEBUG(1, ("No gidnumber attribute found for this user!\n")); + goto done; + } + + group_sid = talloc(tmp_ctx, struct dom_sid); + if (group_sid == NULL) { + ret = ENOMEM; + goto done; + } + + if (uid == gid) { /* User private group, use default fallback group */ + sid_copy(group_sid, + &ldap_state->ipasam_privates->fallback_primary_group); + ret = 0; + goto done; + } else { + ret = ipasam_get_sid_by_gid(ldap_state, gid, group_sid); + if (ret != 0) { + goto done; + } + } + + ret = 0; +done: + if (ret == 0) { + *_group_sid = talloc_steal(mem_ctx, group_sid); + } + + talloc_free(tmp_ctx); + + return ret; +} + static bool init_sam_from_ldap(struct ldapsam_privates *ldap_state, struct samu * sampass, LDAPMessage * entry) @@ -2692,7 +2829,9 @@ static bool init_sam_from_ldap(struct ldapsam_privates *ldap_state, char *temp = NULL; bool ret = false; bool retval = false; + int status; DATA_BLOB nthash; + struct dom_sid *group_sid; TALLOC_CTX *tmp_ctx = talloc_init("init_sam_from_ldap"); if (!tmp_ctx) { @@ -2738,6 +2877,12 @@ static bool init_sam_from_ldap(struct ldapsam_privates *ldap_state, entry, LDAP_ATTRIBUTE_SECURITY_IDENTIFIER, tmp_ctx)) != NULL) { pdb_set_user_sid_from_string(sampass, temp, PDB_SET); + + status = ipasam_get_primary_group_sid(tmp_ctx, ldap_state, + entry, &group_sid); + if (status != 0) { + goto fn_exit; + } } else { goto fn_exit; } @@ -2872,6 +3017,7 @@ done: talloc_free(tmp_ctx); return status; } + static NTSTATUS ldapsam_getsampwnam(struct pdb_methods *methods, struct samu *user, const char *sname) @@ -3105,6 +3251,70 @@ static void ipasam_free_private_data(void **vp) /* No need to free any further, as it is talloc()ed */ } +static struct dom_sid *get_fallback_group_sid(TALLOC_CTX *mem_ctx, + struct smbldap_state *ldap_state, + struct sss_idmap_ctx *idmap_ctx, + LDAPMessage *dom_entry) +{ + char *dn; + char *sid; + int ret; + const char *filter = "objectClass=*"; + const char *attr_list[] = { + LDAP_ATTRIBUTE_SID, + NULL}; + LDAPMessage *result; + LDAPMessage *entry; + enum idmap_error_code err; + struct dom_sid *fallback_group_sid; + + dn = get_single_attribute(mem_ctx, ldap_state->ldap_struct, + dom_entry, + LDAP_ATTRIBUTE_FALLBACK_PRIMARY_GROUP); + if (dn == NULL) { + DEBUG(0, ("Missing mandatory attribute %s.\n", + LDAP_ATTRIBUTE_FALLBACK_PRIMARY_GROUP)); + return NULL; + } + + ret = smbldap_search(ldap_state, dn, LDAP_SCOPE_BASE, filter, attr_list, + 0, &result); + talloc_free(dn); + if (ret != LDAP_SUCCESS) { + DEBUG(2,("Failed to read faillback group [%s].", dn)); + return NULL; + } + + entry = ldap_first_entry(ldap_state->ldap_struct, result); + if (entry == NULL) { + DEBUG(0, ("Could not get fallback group entry\n")); + ldap_msgfree(result); + return NULL; + } + + sid = get_single_attribute(mem_ctx, ldap_state->ldap_struct, + entry, LDAP_ATTRIBUTE_SID); + if (sid == NULL) { + DEBUG(0, ("Missing mandatory attribute %s.\n", + LDAP_ATTRIBUTE_SID)); + ldap_msgfree(result); + return NULL; + } + + err = sss_idmap_sid_to_smb_sid(idmap_ctx, sid, &fallback_group_sid); + if (err != IDMAP_SUCCESS) { + DEBUG(1, ("SID [%s] could not be converted\n", sid)); + ldap_msgfree(result); + talloc_free(sid); + return NULL; + } + + ldap_msgfree(result); + talloc_free(sid); + + return fallback_group_sid; +} + static NTSTATUS ipasam_search_domain_info(struct smbldap_state *ldap_state, LDAPMessage ** result) { @@ -3686,6 +3896,7 @@ static NTSTATUS pdb_init_ipasam(struct pdb_methods **pdb_method, char *dn = NULL; char *domain_sid_string = NULL; struct dom_sid *ldap_domain_sid = NULL; + struct dom_sid *fallback_group_sid = NULL; LDAPMessage *result = NULL; LDAPMessage *entry = NULL; @@ -3815,12 +4026,6 @@ static NTSTATUS pdb_init_ipasam(struct pdb_methods **pdb_method, return NT_STATUS_INVALID_PARAMETER; } - domain_sid_string = get_single_attribute( - ldap_state, - ldap_state->smbldap_state->ldap_struct, - entry, - LDAP_ATTRIBUTE_SID); - err = sss_idmap_init(idmap_talloc, ldap_state->ipasam_privates, idmap_talloc_free, &ldap_state->ipasam_privates->idmap_ctx); @@ -3829,6 +4034,24 @@ static NTSTATUS pdb_init_ipasam(struct pdb_methods **pdb_method, return NT_STATUS_UNSUCCESSFUL; } + fallback_group_sid = get_fallback_group_sid(ldap_state, + ldap_state->smbldap_state, + ldap_state->ipasam_privates->idmap_ctx, + result); + if (fallback_group_sid == NULL) { + DEBUG(0, ("Cannot find SID of fallback group.\n")); + return NT_STATUS_INVALID_PARAMETER; + } + sid_copy(&ldap_state->ipasam_privates->fallback_primary_group, + fallback_group_sid); + talloc_free(fallback_group_sid); + + domain_sid_string = get_single_attribute( + ldap_state, + ldap_state->smbldap_state->ldap_struct, + entry, + LDAP_ATTRIBUTE_SID); + if (domain_sid_string) { err = sss_idmap_sid_to_smb_sid(ldap_state->ipasam_privates->idmap_ctx, domain_sid_string, -- 1.7.11.4 -------------- next part -------------- From 706872e48515d54c70f14ffee35c81ab2b8000c4 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 25 Sep 2012 11:11:40 +0200 Subject: [PATCH 78/78] ipadb: use ipaNTGroupAttrs to search for the fallback group Since we are primarily interested in the SID of the fallback group we should use the objectclass containing it in the search filter. --- daemons/ipa-kdb/ipa_kdb_mspac.c | 2 +- 1 Datei ge?ndert, 1 Zeile hinzugef?gt(+), 1 Zeile entfernt(-) diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index b3cef97db1bfe120d00b3bbfd30ed392dbb7b385..1a03323d137a2b89a08f5b12ca00752e4e190de7 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -1590,7 +1590,7 @@ krb5_error_code ipadb_reinit_mspac(struct ipadb_context *ipactx) if (ret != ENOENT) { kerr = ipadb_simple_search(ipactx, ipactx->mspac->fallback_group, LDAP_SCOPE_BASE, - "(objectclass=posixGroup)", + "(objectclass=ipaNTGroupAttrs)", grp_attrs, &result); if (kerr && kerr != KRB5_KDB_NOENTRY) { kerr = ret; -- 1.7.11.4 From edewata at redhat.com Fri Oct 5 16:58:14 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 05 Oct 2012 11:58:14 -0500 Subject: [Freeipa-devel] [PATCH] [WIP] Firefox extension In-Reply-To: <506F0035.8030406@redhat.com> References: <506B1879.1090501@redhat.com> <506C4296.7060904@redhat.com> <1349273944.22373.89.camel@willson.li.ssimo.org> <506DB5CC.4070003@redhat.com> <20121005135650.GV17454@redhat.com> <506EEDD2.7040909@redhat.com> <20121005143307.GW17454@redhat.com> <1349447960.22373.189.camel@willson.li.ssimo.org> <506EFD1B.7030901@redhat.com> <506F0035.8030406@redhat.com> Message-ID: <506F11A6.9040908@redhat.com> On 10/5/2012 10:43 AM, Petr Vobornik wrote: >>>>> 1. It looks like the Firefox is limited to version 10 to 15 in >>>>> install/ffextension/install.rdf. Do we need the upper limit? >>>>> >>>>> 10.0 >>>>> 15.0.* > > My understanding is that maxversion represents maximum tested version. > [https://developer.mozilla.org/en-US/docs/Install_Manifests] but the > document doesn't say if the extension stops being installable on newer > versions. I tried maxversion=14.0.* on FF15 and it worked. I see in that page there's a separate parameter for that: strictCompatibility. By default it's false, so we're OK. -- Endi S. Dewata From sbose at redhat.com Fri Oct 5 17:02:33 2012 From: sbose at redhat.com (Sumit Bose) Date: Fri, 5 Oct 2012 19:02:33 +0200 Subject: [Freeipa-devel] [PATCH] 75-78 Add fallback group In-Reply-To: <20121005163425.GI6816@localhost.localdomain> References: <20121002192901.GV6816@localhost.localdomain> <1349207792.22373.64.camel@willson.li.ssimo.org> <20121005132752.GR17454@redhat.com> <1349444758.22373.187.camel@willson.li.ssimo.org> <20121005163425.GI6816@localhost.localdomain> Message-ID: <20121005170232.GJ6816@localhost.localdomain> On Fri, Oct 05, 2012 at 06:34:25PM +0200, Sumit Bose wrote: > On Fri, Oct 05, 2012 at 09:45:58AM -0400, Simo Sorce wrote: > > On Fri, 2012-10-05 at 16:27 +0300, Alexander Bokovoy wrote: > > > On Tue, 02 Oct 2012, Simo Sorce wrote: > > > >On Tue, 2012-10-02 at 21:29 +0200, Sumit Bose wrote: > > > >> Hi, > > > >> > > > >> this patch should fix https://fedorahosted.org/freeipa/ticket/2955 by > > > >> adding a fallback group as described in comment 2 of the ticket in > > > >> ipa-adtrust-install. > > > >> > > > >> If you prefer to use a different kind of group I can change the patch > > > >> accordingly. > > > Patch works for me, so ACK except the group name. > > > > > > >Yes I think we should use a more natural group name. In my recent > > > >testing I have been using the name 'Trust Users' that pairs well with > > > >another group we create called 'Trust Admins'. But I am open to > > > >suggestions on a better name, 'Domain Users' may be better if we really > > > >want to associate the wellknown SID to this group. > > > I'm fine with 'Trust Users'. > > > > > > >On the SID side I wonder if using the wellknown 'Domain Users' SID is > > > >the right thing to do. I do not see any special reasons why it shouldn't > > > >but I also do not have any special reason why we should. > > > >Anyone can think of any pros/cons of doing that ? > > > Since it only has special meaning within the same domain and we are not > > > using it for anything, it should be fine. > > > > Well it has a special meaning for samba servers ... we may have a few in > > the IPA domain. > > I think using that SID is fine but I think then the name 'Trust Users' > > could be confusing to users looking at permissions. > > > > We also need to make the group a posix group btw, because samba uses the > > Primary Group SID for users and if it can't be resolved to uid/gids it > > will probably prevent authentication. > > > > What about calling it 'Default SMB Group' or similar ? > > > > Simo. > > ok new version attached. The group is now a Posix with an > automatically assigned SID called 'default_smb_group' and in the > protected list. > > bye, > Sumit > > > > -- > > Simo Sorce * Red Hat, Inc * New York > > I found a copy-and-paste issue in the first patch, new version attached. bye, Sumit -------------- next part -------------- From a855b06f390791e873cf9ee6b49ec7d7f63733c4 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 18 Sep 2012 11:32:10 +0200 Subject: [PATCH] ipa-adtrust-install: Add fallback group --- ipalib/plugins/group.py | 2 +- ipaserver/install/adtrustinstance.py | 110 +++++++++++++++++++++++++++++++---- 2 Dateien ge?ndert, 99 Zeilen hinzugef?gt(+), 13 Zeilen entfernt(-) diff --git a/ipalib/plugins/group.py b/ipalib/plugins/group.py index 45758d320bb58f3933938ce579d211a83d56ce09..1611e422bbef3d1ee9c71a819b7f9cc13cd819ab 100644 --- a/ipalib/plugins/group.py +++ b/ipalib/plugins/group.py @@ -107,7 +107,7 @@ Example: ipa group-add-member ad_admins --groups ad_admins_external """) -PROTECTED_GROUPS = (u'admins', u'trust admins') +PROTECTED_GROUPS = (u'admins', u'trust admins', u'default_smb_group') class group(LDAPObject): """ diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py index c44037754dfd74cf6a9ceda4c9f4d2a6a224b1ea..3c7aeb578cc7b1062f2b5b78e434a8af69be1aaa 100644 --- a/ipaserver/install/adtrustinstance.py +++ b/ipaserver/install/adtrustinstance.py @@ -22,6 +22,7 @@ import errno import ldap import tempfile import uuid +import krbV from ipaserver import ipaldap from ipaserver.install import installutils from ipaserver.install import service @@ -96,9 +97,11 @@ class ADTRUSTInstance(service.Service): ATTR_SID = "ipaNTSecurityIdentifier" ATTR_FLAT_NAME = "ipaNTFlatName" ATTR_GUID = "ipaNTDomainGUID" + ATTR_FALLBACK_GROUP = "ipaNTFallbackPrimaryGroup" OBJC_USER = "ipaNTUserAttrs" OBJC_GROUP = "ipaNTGroupAttrs" OBJC_DOMAIN = "ipaNTDomainAttrs" + FALLBACK_GROUP_NAME = u'Default_SMB_Group' def __init__(self, fstore=None): self.fqdn = None @@ -134,6 +137,18 @@ class ADTRUSTInstance(service.Service): return "S-1-5-21-%d-%d-%d" % (sub_ids[0], sub_ids[1], sub_ids[2]) def __add_admin_sids(self): + """ + The IPA admin and the IPA admins group with get the well knows SIDs + used by AD for the administrator and the administrator group. + Additonally the well know domain users SID will be assinged to a + special fallback group. + + By default new users belong only to a user private group (UPG) and no + other Posix group since ipausers is not a Posix group anymore. To be + able to add a RID to the primary RID attribute in a PAC a fallback + group is added. + """ + admin_dn = DN(('uid', 'admin'), api.env.container_user, self.suffix) admin_group_dn = DN(('cn', 'admins'), api.env.container_group, @@ -163,24 +178,94 @@ class ADTRUSTInstance(service.Service): print "IPA admin group object not found" return - if admin_entry.getValue(self.ATTR_SID) or \ - admin_group_entry.getValue(self.ATTR_SID): - print "Admin SID already set, nothing to do" + if admin_entry.getValue(self.ATTR_SID): + self.print_msg("Admin SID already set, nothing to do") + else: + try: + self.admin_conn.modify_s(admin_dn, \ + [(ldap.MOD_ADD, "objectclass", self.OBJC_USER), \ + (ldap.MOD_ADD, self.ATTR_SID, dom_sid + "-500")]) + except: + self.print_msg("Failed to modify IPA admin object") + + if admin_group_entry.getValue(self.ATTR_SID): + self.print_msg("Admin group SID already set, nothing to do") + else: + try: + self.admin_conn.modify_s(admin_group_dn, \ + [(ldap.MOD_ADD, "objectclass", self.OBJC_GROUP), \ + (ldap.MOD_ADD, self.ATTR_SID, dom_sid + "-512")]) + except: + self.print_msg("Failed to modify IPA admin group object") + + + def __add_fallback_group(self): + """ + By default new users belong only to a user private group (UPG) and no + other Posix group since ipausers is not a Posix group anymore. To be + able to add a RID to the primary RID attribute in a PAC a fallback + group is added. + + Since this method must be run after a restart of the directory server + to enable the sidgen plugin we have to reconnect to the directory + server. + """ + + self.ldap_connect() + try: + ctx = krbV.default_context() + ccache = ctx.default_ccache() + except krbV.Krb5Error, e: + self.print_msg("Must have Kerberos credentials to setup " \ + "AD trusts on server") return try: - self.admin_conn.modify_s(admin_dn, \ - [(ldap.MOD_ADD, "objectclass", self.OBJC_USER), \ - (ldap.MOD_ADD, self.ATTR_SID, dom_sid + "-500")]) - except: - print "Failed to modify IPA admin object" + api.Backend.ldap2.disconnect() + api.Backend.ldap2.connect(ccache.name) + except errors.ACIError, e: + self.print_msg("Outdated Kerberos credentials. " \ + "Use kdestroy and kinit to update your ticket") + return + except errors.DatabaseError, e: + self.print_msg("Cannot connect to the LDAP database. " \ + "Please check if IPA is running") + return + + try: + dom_entry = self.admin_conn.getEntry(self.smb_dom_dn, \ + ldap.SCOPE_BASE) + except errors.NotFound: + self.print_msg("Samba domain object not found") + return + + if dom_entry.getValue(self.ATTR_FALLBACK_GROUP): + self.print_msg("Fallback group already set, nothing to do") + return + + fb_group_dn = DN(('cn', self.FALLBACK_GROUP_NAME), + api.env.container_group, self.suffix) + try: + self.admin_conn.getEntry(fb_group_dn, ldap.SCOPE_BASE) + except errors.NotFound: + try: + fallback = api.Command['group_add'](self.FALLBACK_GROUP_NAME, + description= u'Fallback group for ' \ + 'primary group RID, ' \ + 'do not add user to ' \ + 'this group', + nonposix=False) + fb_group_dn = fallback['result']['dn'] + except Exception, e: + self.print_msg("Failed to add fallback group.") + raise e try: - self.admin_conn.modify_s(admin_group_dn, \ - [(ldap.MOD_ADD, "objectclass", self.OBJC_GROUP), \ - (ldap.MOD_ADD, self.ATTR_SID, dom_sid + "-512")]) + mod = [(ldap.MOD_ADD, self.ATTR_FALLBACK_GROUP, + fallback['result']['dn'])] + self.admin_conn.modify_s(self.smb_dom_dn, mod) except: - print "Failed to modify IPA admin group object" + self.print_msg("Failed to add fallback group to domain object") def __add_rid_bases(self): """ @@ -612,6 +697,7 @@ class ADTRUSTInstance(service.Service): self.__add_dns_service_records) self.step("restarting Directory Server to take MS PAC and LDAP plugins changes into account", \ self.__restart_dirsrv) + self.step("adding fallback group", self.__add_fallback_group) self.step("setting SELinux booleans", \ self.__configure_selinux_for_smbd) self.step("starting CIFS services", self.__start) -- 1.7.11.4 -------------- next part -------------- From 0071498c8e5f29e1541cbc8b8674dc62d9e7c556 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 18 Sep 2012 11:35:57 +0200 Subject: [PATCH 76/78] ipa-adtrust-install: replace print with self.print_msg --- ipaserver/install/adtrustinstance.py | 28 ++++++++++++++-------------- 1 Datei ge?ndert, 14 Zeilen hinzugef?gt(+), 14 Zeilen entfernt(-) diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py index fe44ef36dab1c124c062db84207995adb4649723..cdad99c8ec994a1170ed58a8b31596bca03c89a6 100644 --- a/ipaserver/install/adtrustinstance.py +++ b/ipaserver/install/adtrustinstance.py @@ -157,25 +157,25 @@ class ADTRUSTInstance(service.Service): dom_entry = self.admin_conn.getEntry(self.smb_dom_dn, \ ldap.SCOPE_BASE) except errors.NotFound: - print "Samba domain object not found" + self.print_msg("Samba domain object not found") return dom_sid = dom_entry.getValue(self.ATTR_SID) if not dom_sid: - print "Samba domain object does not have a SID" + self.print_msg("Samba domain object does not have a SID") return try: admin_entry = self.admin_conn.getEntry(admin_dn, ldap.SCOPE_BASE) except: - print "IPA admin object not found" + self.print_msg("IPA admin object not found") return try: admin_group_entry = self.admin_conn.getEntry(admin_group_dn, \ ldap.SCOPE_BASE) except: - print "IPA admin group object not found" + self.print_msg("IPA admin group object not found") return if admin_entry.getValue(self.ATTR_SID): @@ -279,13 +279,13 @@ class ADTRUSTInstance(service.Service): if res[0].getValue('ipaBaseRID') or \ res[0].getValue('ipaSecondaryBaseRID'): - print "RID bases already set, nothing to do" + self.print_msg("RID bases already set, nothing to do") return size = res[0].getValue('ipaIDRangeSize') if abs(self.rid_base - self.secondary_rid_base) > size: - print "Primary and secondary RID base are too close. " \ - "They have to differ at least by %d." % size + self.print_msg("Primary and secondary RID base are too close. " \ + "They have to differ at least by %d." % size) raise RuntimeError("RID bases too close.\n") try: @@ -295,7 +295,7 @@ class ADTRUSTInstance(service.Service): (ldap.MOD_ADD, "ipaSecondaryBaseRID", \ str(self.secondary_rid_base))]) except: - print "Failed to add RID bases to the local range object" + self.print_msg("Failed to add RID bases to the local range object") except errors.NotFound as e: root_logger.critical("ID range of the local domain not found, " \ @@ -322,8 +322,8 @@ class ADTRUSTInstance(service.Service): try: name = new_dn[1].attr except Exception, e: - print 'Cannot extract RDN attribute value from "%s": %s' % \ - (new_dn, e) + self.print_msg('Cannot extract RDN attribute value from "%s": %s' % \ + (new_dn, e)) return entry.setValues("cn", name) self.admin_conn.addEntry(entry) @@ -440,12 +440,12 @@ class ADTRUSTInstance(service.Service): "as it is not defined in IPA" % zone if err_msg: - print err_msg - print "Add the following service records to your DNS server " \ - "for DNS zone %s: " % zone + self.print_msg(err_msg) + self.print_msg("Add the following service records to your DNS " \ + "server for DNS zone %s: " % zone) for (srv, rdata) in ipa_srv_rec: for suff in win_srv_suffix: - print " - %s%s" % (srv, suff) + self.print_msg(" - %s%s" % (srv, suff)) return for (srv, rdata) in ipa_srv_rec: -- 1.7.11.4 -------------- next part -------------- From 2fb8f182b2dd465c1c5ac9a0b6ca33c15d21971f Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Mon, 24 Sep 2012 17:25:07 +0200 Subject: [PATCH 77/78] ipasam: add fallback primary group --- daemons/ipa-sam/ipa_sam.c | 237 ++++++++++++++++++++++++++++++++++++++++++++-- 1 Datei ge?ndert, 230 Zeilen hinzugef?gt(+), 7 Zeilen entfernt(-) diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c index db300022af0a29c32a2df5e5ef2bc12f39ed2886..2453eb09ce1d168c3d4389c09265cd63d65c5c9d 100644 --- a/daemons/ipa-sam/ipa_sam.c +++ b/daemons/ipa-sam/ipa_sam.c @@ -121,6 +121,8 @@ bool secrets_store(const char *key, const void *data, size_t size); /* available #define LDAP_ATTRIBUTE_LOGON_SCRIPT "ipaNTLogonScript" #define LDAP_ATTRIBUTE_PROFILE_PATH "ipaNTProfilePath" #define LDAP_ATTRIBUTE_NTHASH "ipaNTHash" +#define LDAP_ATTRIBUTE_UIDNUMBER "uidnumber" +#define LDAP_ATTRIBUTE_GIDNUMBER "gidnumber" #define LDAP_OBJ_KRB_PRINCIPAL "krbPrincipal" #define LDAP_OBJ_KRB_PRINCIPAL_AUX "krbPrincipalAux" @@ -155,7 +157,7 @@ struct ipasam_privates { char *base_dn; char *trust_dn; char *flat_name; - char *fallback_primary_group; + struct dom_sid fallback_primary_group; char *server_princ; char *client_princ; struct sss_idmap_ctx *idmap_ctx; @@ -2677,6 +2679,141 @@ static bool ipasam_nthash_regen(struct ldapsam_privates *ldap_state, return (ret == LDAP_SUCCESS); } +static int ipasam_get_sid_by_gid(struct ldapsam_privates *ldap_state, + uint32_t gid, + struct dom_sid *_sid) +{ + int ret; + char *filter; + TALLOC_CTX *tmp_ctx; + LDAPMessage *entry = NULL; + LDAPMessage *result = NULL; + char *sid_str = NULL; + struct dom_sid *sid = NULL; + int count; + enum idmap_error_code err; + + tmp_ctx = talloc_new("ipasam_get_sid_by_gid"); + if (tmp_ctx == NULL) { + return ENOMEM; + } + + filter = talloc_asprintf(tmp_ctx, "(&(%s=%s)(%s=%lu))", + LDAP_ATTRIBUTE_OBJECTCLASS, + LDAP_OBJ_POSIXGROUP, + LDAP_ATTRIBUTE_GIDNUMBER, + (unsigned long) gid); + if (filter == NULL) { + ret = ENOMEM; + goto done; + } + + ret = smbldap_search(ldap_state->smbldap_state, + ldap_state->ipasam_privates->base_dn, + LDAP_SCOPE_SUBTREE,filter, NULL, 0, + &result); + if (ret != LDAP_SUCCESS) { + ret = ENOENT; + goto done; + } + + count = ldap_count_entries(ldap_state->smbldap_state->ldap_struct, + result); + if (count != 1) { + ret = ENOENT; + goto done; + } + + entry = ldap_first_entry(ldap_state->smbldap_state->ldap_struct, result); + if (entry == NULL) { + ret = ENOENT; + goto done; + } + + sid_str = get_single_attribute(tmp_ctx, + ldap_state->smbldap_state->ldap_struct, + entry, LDAP_ATTRIBUTE_SID); + if (sid_str == NULL) { + ret = ENOENT; + goto done; + } + + err = sss_idmap_sid_to_smb_sid(ldap_state->ipasam_privates->idmap_ctx, + sid_str, &sid); + if (err != IDMAP_SUCCESS) { + ret = EFAULT; + goto done; + } + sid_copy(_sid, sid); + + ret = 0; + +done: + talloc_free(sid); + ldap_msgfree(result); + talloc_free(tmp_ctx); + + return ret; +} + +static int ipasam_get_primary_group_sid(TALLOC_CTX *mem_ctx, + struct ldapsam_privates *ldap_state, + LDAPMessage *entry, + struct dom_sid **_group_sid) +{ + int ret; + uint32_t uid; + uint32_t gid; + struct dom_sid *group_sid; + + TALLOC_CTX *tmp_ctx = talloc_init("ipasam_get_primary_group_sid"); + if (tmp_ctx == NULL) { + return ENOMEM; + } + + if (!get_uint32_t_from_ldap_msg(ldap_state, entry, + LDAP_ATTRIBUTE_UIDNUMBER, &uid)) { + ret = ENOENT; + DEBUG(1, ("No uidnumber attribute found for this user!\n")); + goto done; + } + + if (!get_uint32_t_from_ldap_msg(ldap_state, entry, + LDAP_ATTRIBUTE_GIDNUMBER, &gid)) { + ret = ENOENT; + DEBUG(1, ("No gidnumber attribute found for this user!\n")); + goto done; + } + + group_sid = talloc(tmp_ctx, struct dom_sid); + if (group_sid == NULL) { + ret = ENOMEM; + goto done; + } + + if (uid == gid) { /* User private group, use default fallback group */ + sid_copy(group_sid, + &ldap_state->ipasam_privates->fallback_primary_group); + ret = 0; + goto done; + } else { + ret = ipasam_get_sid_by_gid(ldap_state, gid, group_sid); + if (ret != 0) { + goto done; + } + } + + ret = 0; +done: + if (ret == 0) { + *_group_sid = talloc_steal(mem_ctx, group_sid); + } + + talloc_free(tmp_ctx); + + return ret; +} + static bool init_sam_from_ldap(struct ldapsam_privates *ldap_state, struct samu * sampass, LDAPMessage * entry) @@ -2692,7 +2829,9 @@ static bool init_sam_from_ldap(struct ldapsam_privates *ldap_state, char *temp = NULL; bool ret = false; bool retval = false; + int status; DATA_BLOB nthash; + struct dom_sid *group_sid; TALLOC_CTX *tmp_ctx = talloc_init("init_sam_from_ldap"); if (!tmp_ctx) { @@ -2738,6 +2877,12 @@ static bool init_sam_from_ldap(struct ldapsam_privates *ldap_state, entry, LDAP_ATTRIBUTE_SECURITY_IDENTIFIER, tmp_ctx)) != NULL) { pdb_set_user_sid_from_string(sampass, temp, PDB_SET); + + status = ipasam_get_primary_group_sid(tmp_ctx, ldap_state, + entry, &group_sid); + if (status != 0) { + goto fn_exit; + } } else { goto fn_exit; } @@ -2872,6 +3017,7 @@ done: talloc_free(tmp_ctx); return status; } + static NTSTATUS ldapsam_getsampwnam(struct pdb_methods *methods, struct samu *user, const char *sname) @@ -3105,6 +3251,70 @@ static void ipasam_free_private_data(void **vp) /* No need to free any further, as it is talloc()ed */ } +static struct dom_sid *get_fallback_group_sid(TALLOC_CTX *mem_ctx, + struct smbldap_state *ldap_state, + struct sss_idmap_ctx *idmap_ctx, + LDAPMessage *dom_entry) +{ + char *dn; + char *sid; + int ret; + const char *filter = "objectClass=*"; + const char *attr_list[] = { + LDAP_ATTRIBUTE_SID, + NULL}; + LDAPMessage *result; + LDAPMessage *entry; + enum idmap_error_code err; + struct dom_sid *fallback_group_sid; + + dn = get_single_attribute(mem_ctx, ldap_state->ldap_struct, + dom_entry, + LDAP_ATTRIBUTE_FALLBACK_PRIMARY_GROUP); + if (dn == NULL) { + DEBUG(0, ("Missing mandatory attribute %s.\n", + LDAP_ATTRIBUTE_FALLBACK_PRIMARY_GROUP)); + return NULL; + } + + ret = smbldap_search(ldap_state, dn, LDAP_SCOPE_BASE, filter, attr_list, + 0, &result); + talloc_free(dn); + if (ret != LDAP_SUCCESS) { + DEBUG(2,("Failed to read faillback group [%s].", dn)); + return NULL; + } + + entry = ldap_first_entry(ldap_state->ldap_struct, result); + if (entry == NULL) { + DEBUG(0, ("Could not get fallback group entry\n")); + ldap_msgfree(result); + return NULL; + } + + sid = get_single_attribute(mem_ctx, ldap_state->ldap_struct, + entry, LDAP_ATTRIBUTE_SID); + if (sid == NULL) { + DEBUG(0, ("Missing mandatory attribute %s.\n", + LDAP_ATTRIBUTE_SID)); + ldap_msgfree(result); + return NULL; + } + + err = sss_idmap_sid_to_smb_sid(idmap_ctx, sid, &fallback_group_sid); + if (err != IDMAP_SUCCESS) { + DEBUG(1, ("SID [%s] could not be converted\n", sid)); + ldap_msgfree(result); + talloc_free(sid); + return NULL; + } + + ldap_msgfree(result); + talloc_free(sid); + + return fallback_group_sid; +} + static NTSTATUS ipasam_search_domain_info(struct smbldap_state *ldap_state, LDAPMessage ** result) { @@ -3686,6 +3896,7 @@ static NTSTATUS pdb_init_ipasam(struct pdb_methods **pdb_method, char *dn = NULL; char *domain_sid_string = NULL; struct dom_sid *ldap_domain_sid = NULL; + struct dom_sid *fallback_group_sid = NULL; LDAPMessage *result = NULL; LDAPMessage *entry = NULL; @@ -3815,12 +4026,6 @@ static NTSTATUS pdb_init_ipasam(struct pdb_methods **pdb_method, return NT_STATUS_INVALID_PARAMETER; } - domain_sid_string = get_single_attribute( - ldap_state, - ldap_state->smbldap_state->ldap_struct, - entry, - LDAP_ATTRIBUTE_SID); - err = sss_idmap_init(idmap_talloc, ldap_state->ipasam_privates, idmap_talloc_free, &ldap_state->ipasam_privates->idmap_ctx); @@ -3829,6 +4034,24 @@ static NTSTATUS pdb_init_ipasam(struct pdb_methods **pdb_method, return NT_STATUS_UNSUCCESSFUL; } + fallback_group_sid = get_fallback_group_sid(ldap_state, + ldap_state->smbldap_state, + ldap_state->ipasam_privates->idmap_ctx, + result); + if (fallback_group_sid == NULL) { + DEBUG(0, ("Cannot find SID of fallback group.\n")); + return NT_STATUS_INVALID_PARAMETER; + } + sid_copy(&ldap_state->ipasam_privates->fallback_primary_group, + fallback_group_sid); + talloc_free(fallback_group_sid); + + domain_sid_string = get_single_attribute( + ldap_state, + ldap_state->smbldap_state->ldap_struct, + entry, + LDAP_ATTRIBUTE_SID); + if (domain_sid_string) { err = sss_idmap_sid_to_smb_sid(ldap_state->ipasam_privates->idmap_ctx, domain_sid_string, -- 1.7.11.4 -------------- next part -------------- From 706872e48515d54c70f14ffee35c81ab2b8000c4 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 25 Sep 2012 11:11:40 +0200 Subject: [PATCH 78/78] ipadb: use ipaNTGroupAttrs to search for the fallback group Since we are primarily interested in the SID of the fallback group we should use the objectclass containing it in the search filter. --- daemons/ipa-kdb/ipa_kdb_mspac.c | 2 +- 1 Datei ge?ndert, 1 Zeile hinzugef?gt(+), 1 Zeile entfernt(-) diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index b3cef97db1bfe120d00b3bbfd30ed392dbb7b385..1a03323d137a2b89a08f5b12ca00752e4e190de7 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -1590,7 +1590,7 @@ krb5_error_code ipadb_reinit_mspac(struct ipadb_context *ipactx) if (ret != ENOENT) { kerr = ipadb_simple_search(ipactx, ipactx->mspac->fallback_group, LDAP_SCOPE_BASE, - "(objectclass=posixGroup)", + "(objectclass=ipaNTGroupAttrs)", grp_attrs, &result); if (kerr && kerr != KRB5_KDB_NOENTRY) { kerr = ret; -- 1.7.11.4 From simo at redhat.com Fri Oct 5 17:50:45 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 05 Oct 2012 13:50:45 -0400 Subject: [Freeipa-devel] [PATCH] 75-78 Add fallback group In-Reply-To: <20121005170232.GJ6816@localhost.localdomain> References: <20121002192901.GV6816@localhost.localdomain> <1349207792.22373.64.camel@willson.li.ssimo.org> <20121005132752.GR17454@redhat.com> <1349444758.22373.187.camel@willson.li.ssimo.org> <20121005163425.GI6816@localhost.localdomain> <20121005170232.GJ6816@localhost.localdomain> Message-ID: <1349459445.26127.25.camel@willson.li.ssimo.org> On Fri, 2012-10-05 at 19:02 +0200, Sumit Bose wrote: > On Fri, Oct 05, 2012 at 06:34:25PM +0200, Sumit Bose wrote: > > On Fri, Oct 05, 2012 at 09:45:58AM -0400, Simo Sorce wrote: > > > On Fri, 2012-10-05 at 16:27 +0300, Alexander Bokovoy wrote: > > > > On Tue, 02 Oct 2012, Simo Sorce wrote: > > > > >On Tue, 2012-10-02 at 21:29 +0200, Sumit Bose wrote: > > > > >> Hi, > > > > >> > > > > >> this patch should fix https://fedorahosted.org/freeipa/ticket/2955 by > > > > >> adding a fallback group as described in comment 2 of the ticket in > > > > >> ipa-adtrust-install. > > > > >> > > > > >> If you prefer to use a different kind of group I can change the patch > > > > >> accordingly. > > > > Patch works for me, so ACK except the group name. > > > > > > > > >Yes I think we should use a more natural group name. In my recent > > > > >testing I have been using the name 'Trust Users' that pairs well with > > > > >another group we create called 'Trust Admins'. But I am open to > > > > >suggestions on a better name, 'Domain Users' may be better if we really > > > > >want to associate the wellknown SID to this group. > > > > I'm fine with 'Trust Users'. > > > > > > > > >On the SID side I wonder if using the wellknown 'Domain Users' SID is > > > > >the right thing to do. I do not see any special reasons why it shouldn't > > > > >but I also do not have any special reason why we should. > > > > >Anyone can think of any pros/cons of doing that ? > > > > Since it only has special meaning within the same domain and we are not > > > > using it for anything, it should be fine. > > > > > > Well it has a special meaning for samba servers ... we may have a few in > > > the IPA domain. > > > I think using that SID is fine but I think then the name 'Trust Users' > > > could be confusing to users looking at permissions. > > > > > > We also need to make the group a posix group btw, because samba uses the > > > Primary Group SID for users and if it can't be resolved to uid/gids it > > > will probably prevent authentication. > > > > > > What about calling it 'Default SMB Group' or similar ? > > > > > > Simo. > > > > ok new version attached. The group is now a Posix with an > > automatically assigned SID called 'default_smb_group' and in the > > protected list. > > > > bye, > > Sumit > > > > > > -- > > > Simo Sorce * Red Hat, Inc * New York > > > > > I found a copy-and-paste issue in the first patch, new version attached. > > bye, > Sumit 0075: I think we should default_smb_group -> 'default smb group', Default_SMB_Group -> 'Default SMB Group' etc... not sure why we shouldn't use spaces here ? 'Trust Admins' has spaces we should be consistent and use the same conventions everywhere for builtin groups. The comment in __add_admin_sids() is now wrong, we do not associate the wellknown 'Domain Users' sid to the fallback group. The second phrase of the docstring should simply be dropped. The description attribute of the group_add command in __add_fallback_group() should use 'users' (plural) not 'user' I think. 0076: Ack 0077: I am going to Ack this patch but please open a ticket to fix edtection of UPGs. It's not enough to have uidnumber to match the pgid gidnumber to tell that the group is actually a upg. In cases where admins decide to override the DNA plugin and user their own uid/gid allocation, they may have users that use a real group as primary group (potentially with the same name of the user too). We will need to verify we can use the secondary rid range and to mangle the group name if that happens, but we shouldn't fallback to the primary group fallback I think. However I do not think this is should hold back the patchset, so Ack. Nitpicks faillback -> fallback in get_fallback_group_sid() 0078: Nack, I think you had in mind the fact that the group we were using had no posix IDs, but that should never be the case, samba needs the primary group to be a posix group. So I think we should just drop this patch, we do create the Default_SMB_Group as a posix group. Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Fri Oct 5 18:14:52 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 5 Oct 2012 21:14:52 +0300 Subject: [Freeipa-devel] [PATCH] 0082/0083 Handle NotFound exception when establishing trust In-Reply-To: <506F0934.1070406@redhat.com> References: <20121004150613.GP17454@redhat.com> <506EB9D1.3090604@redhat.com> <20121005132424.GQ17454@redhat.com> <506F0934.1070406@redhat.com> Message-ID: <20121005181452.GX17454@redhat.com> On Fri, 05 Oct 2012, Petr Vobornik wrote: >On 10/05/2012 03:24 PM, Alexander Bokovoy wrote: >>On Fri, 05 Oct 2012, Petr Vobornik wrote: >>>On 10/04/2012 05:06 PM, Alexander Bokovoy wrote: >>>> >>>>Hi, >>>> >>>>two attached patches attempt to solve >>>>https://fedorahosted.org/freeipa/ticket/3103 >>>> >>>>We cannot make educated guess where trusted domain's DNS server is >>>>located as we ended up with NotFound exception precisely because we were >>>>unable to discover trusted domain's domain controller location. >>>> >>>>Thus, all we can do is to suggest ways to fix the issue. Since >>>>suggestion becomes relatively long (multi-line, at least), it creates >>>>few issues for current exception error message handling: >>>> - root_logger does not use textui to format output >>>> - textui is only printing to standard output >>>> - multi-line error messages thus become non-wrapped >>>> - localizing such messages would become a harder context-wise. >>>> >>>>Web UI is showing error message as a single paragraph (

    ), all >>>>multi-line markup would be lost. >>>> >>>>In the end, I decided to support list-based multi-line error messages in >>>>PublicError class. Its constructor will join all list-based arguments >>>>into single string per argument (first patch). >>>> >>>>In Web UI I've added special text processing of error messages that >>>>splits message into multiple lines and wraps those which start with a >>>>TAB symbol into 'error-message-hinted' span to visually separate it from >>>>the rest of error message. Trust code uses this to display suggested CLI >>>>command to set up DNS forwarder (second patch). >>>> >>>>In the end, CLI shows such error message fine (note tabulated CLI >>>>command): >>>>----------------------------------------------------------------------- >>>># ipa trust-add --type=ad --admin Administrator at ad.local1 --password >>>>ad.local1 >>>>Active directory domain administrator's password: ipa: ERROR: Unable to >>>>resolve domain controller for 'ad.local1' domain. IPA manages DNS, >>>>please configure forwarder to 'ad.local1' domain by using following CLI >>>>command. Please replace DNS_SERVER and IP_ADDRESS by name and address of >>>>the domain's name server: >>>> ipa dnszone-add ad.local1 --name-server=DNS_SERVER >>>>--admin-email='hostmaster at ad.local1' --force --forwarder=IP_ADDRESS >>>>--forward-policy=only >>>>When using Web UI, please create DNS zone for domain 'ad.local1' first >>>>and then set forwarder and forward policy >>>>----------------------------------------------------------------------- >>>> >>>>Web UI looks like this: http://abbra.fedorapeople.org/.paste/ui.png >>>> >>>> >>> >>>You have undeclared identifier: lines. >>> >>>I recommend to run `jsl -conf jsl.conf` command in install/ui folder >>>to prevent these issues. >>Fixed. >> >> >>>I'm not convinced that "beautify" call should be in command object. I >>>would rather see it in error_dialog. >>I moved everything to error_dialog and used $() selectors instead of >>directly playing with text. > >1) >+ var error_message = $('', {}); > >I would rather see a

    as a container. Span is and should >contain only inline elements. Fixed. >2) >var line_span = $('', { > class: 'error-message-hinted', > text: lines[i].substr(1) > }).appendTo(container); > >Why do you use for hinted message and

    for other lines? >Shouldn't we use

    for both? Fixed to use

    everywhere. >3) var line_span is declared twice. JS use function scope, not block scope. Fixed. Thanks for the review. New patch 0082 attached. -- / Alexander Bokovoy -------------- next part -------------- >From 5a85259e688aae66d740ba6407e60a0fcc601964 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 4 Oct 2012 15:05:17 +0300 Subject: [PATCH 01/12] support multi-line error messages in exceptions --- install/ui/ipa.css | 9 ++++++++- install/ui/ipa.js | 31 +++++++++++++++++++++++++------ ipalib/errors.py | 12 +++++++++--- 3 files changed, 42 insertions(+), 10 deletions(-) diff --git a/install/ui/ipa.css b/install/ui/ipa.css index bc971dce4aa3377fc9918ed3c16a89565f505c94..4e51c3051e75846f386910c8998f73db7afbddaa 100644 --- a/install/ui/ipa.css +++ b/install/ui/ipa.css @@ -1112,6 +1112,13 @@ table.kerberos-key-status { background-color: #daa520; } +.error-message-hinted { + color: red; + padding-top: 0.5em; + padding-bottom: 0.5em; + font-family: monospace; +} + /* ---- Table ---- */ table.scrollable thead { @@ -1784,4 +1791,4 @@ form#login { .choice-header { font-weight: bold; -} \ No newline at end of file +} diff --git a/install/ui/ipa.js b/install/ui/ipa.js index 45195bc499f874426020cd400a1ae9a5c1ef5f0f..8f924b9d29262282f3ad771653e64892c2945efc 100644 --- a/install/ui/ipa.js +++ b/install/ui/ipa.js @@ -1419,6 +1419,25 @@ IPA.error_dialog = function(spec) { that.visible_buttons = spec.visible_buttons || ['retry', 'cancel']; }; + that.beautify_message = function(container, message) { + var lines = message.split(/\n/g); + var line_span; + for(var i=0; i', { + class: 'error-message-hinted', + text: lines[i].substr(1) + }).appendTo(container); + } else { + line_span = $('

    ', { + text: lines[i] + }).appendTo(container); + } + } + }; + that.create = function() { if (that.error_thrown.url) { $('

    ', { @@ -1426,9 +1445,9 @@ IPA.error_dialog = function(spec) { }).appendTo(that.container); } - $('

    ', { - html: that.error_thrown.message - }).appendTo(that.container); + var error_message = $('

    ', {}); + that.beautify_message(error_message, that.error_thrown.message); + error_message.appendTo(that.container); if(that.errors && that.errors.length > 0) { //render errors @@ -1457,9 +1476,9 @@ IPA.error_dialog = function(spec) { for(var i=0; i < that.errors.length; i++) { var error = that.errors[i]; if(error.message) { - var error_div = $('
  • ', { - text: error.message - }).appendTo(errors_container); + var error_div = $('
  • ', {}); + that.beautify_message(error_div, error.message); + error_div.appendTo(errors_container); } } diff --git a/ipalib/errors.py b/ipalib/errors.py index 7bf267290b484ed9570f1c7efdb606628fb5f11d..7f1113200b6b2cd80ea9156d347211e4d978b9be 100644 --- a/ipalib/errors.py +++ b/ipalib/errors.py @@ -265,11 +265,17 @@ class PublicError(StandardError): ) self.format = format self.forwarded = False - self.msg = self.format % kw + def convert_keyword(value): + if isinstance(value, list): + result=u'\n'.join(map(lambda line: unicode(line), value)) + return result + return value + kwargs = dict(map(lambda (k,v): (k, convert_keyword(v)), kw.items())) + self.msg = self.format % kwargs if isinstance(self.format, basestring): - self.strerror = ugettext(self.format) % kw + self.strerror = ugettext(self.format) % kwargs else: - self.strerror = self.format % kw + self.strerror = self.format % kwargs else: if isinstance(message, (Gettext, NGettext)): message = unicode(message) -- 1.7.12 From abokovoy at redhat.com Fri Oct 5 18:17:47 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 5 Oct 2012 21:17:47 +0300 Subject: [Freeipa-devel] [PATCH] Fix up trust attributes on trust-add In-Reply-To: <1349450969.26127.1.camel@willson.li.ssimo.org> References: <1349450969.26127.1.camel@willson.li.ssimo.org> Message-ID: <20121005181747.GY17454@redhat.com> On Fri, 05 Oct 2012, Simo Sorce wrote: >A onliner but better to have it validated by a second pair of eyes. Yep. Go ahead. The origin of USES_RC4_ENCRYPTION comes from Samba 3 code in net utility that Sumit implemented ~1.5 year ago. -- / Alexander Bokovoy From sbingram at gmail.com Fri Oct 5 19:02:52 2012 From: sbingram at gmail.com (Stephen Ingram) Date: Fri, 5 Oct 2012 12:02:52 -0700 Subject: [Freeipa-devel] slow response In-Reply-To: References: <500729EA.4040507@redhat.com> <500D7DE7.8080405@redhat.com> <50170A58.9030901@redhat.com> <501799C6.3090002@redhat.com> <1343831702.20530.79.camel@willson.li.ssimo.org> <1343928209.20530.132.camel@willson.li.ssimo.org> <501AB9CC.1040509@redhat.com> <501AC1A6.3090600@redhat.com> <1343937842.20530.150.camel@willson.li.ssimo.org> <1344372819.20530.314.camel@willson.li.ssimo.org> <504FF402.1040803@redhat.com> Message-ID: On Tue, Sep 11, 2012 at 9:17 PM, Stephen Ingram wrote: > On Tue, Sep 11, 2012 at 7:31 PM, Rob Crittenden wrote: >> Stephen Ingram wrote: >>> >>> On Tue, Aug 7, 2012 at 1:53 PM, Simo Sorce wrote: >>>> >>>> On Tue, 2012-08-07 at 13:30 -0700, Stephen Ingram wrote: >>>>> >>>>> On Thu, Aug 2, 2012 at 1:04 PM, Simo Sorce wrote: >>>>>> >>>>>> Quick heads up in this thread, >>>>>> >>>>>> apparently we have isolated the issue to libkrb5 and its selinux >>>>>> integration. >>>>>> I have made the whole delay go away by disabling selinux entirely >>>>>> (which >>>>>> makes libkrb5 stop trying to do some selinux related operations). >>>>>> >>>>>> We will be working on a fix to have libkrb5 not cause this delay (F17 >>>>>> doesn't have it). >>>>>> >>>>>> You can follow progress on this bugzilla: >>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=845125 As I'm thinking this might also solve my IPA large memory usage issue, I've been following this bug and see there is now a patch for it. I also see it is in QA along with several other IPA-related (and non-IPA-related) Kerberos fixes. I thought at some point an errata release would happen during the RHEL 6.3 time-frame, but as I'm not too familiar with how this works, so I'm not sure. Is this a possibility, or are these being held back for some reason like additional QA time? Steve From alee at redhat.com Fri Oct 5 19:24:57 2012 From: alee at redhat.com (Ade Lee) Date: Fri, 05 Oct 2012 15:24:57 -0400 Subject: [Freeipa-devel] [PATCH] Changes to use a single database for dogtag and IPA In-Reply-To: <506EAF01.4070002@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50640DCB.2060901@redhat.com> <50699C3B.4050200@redhat.com> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> <506B096A.1070406@redhat.com> <1349381056.2357.8.camel@aleeredhat.laptop> <506EAF01.4070002@redhat.com> Message-ID: <1349465098.19017.22.camel@aleeredhat.laptop> Agreed with your assessment that the --check-ca is not needed, as we will be checking this into 3.1 (and not 3.0). Attached is a patch for the "request object" issue. Basically, the replication was not working because ipa-replica-prepare was passing in the wrong port when creating the replica package. Let me know if you have issues - and remember to add the missing link to the master. That fix to add that link will be checked in today and should be in the dogtag developer nightly build as of tommorow. Ade On Fri, 2012-10-05 at 11:57 +0200, Petr Viktorin wrote: > On 10/04/2012 10:04 PM, Ade Lee wrote: > > Attached is a patch to handle the ipa-replica-conncheck issue. It > > should be applied on top of your patch. > > > > Essentially, the fix is as follows: > > A. If the DS_PORT = 7389, then we pass --check-ca in the > > ipa-replica-conncheck to be executed on the master. > > a1. If the master is ipa 2.x, this will prompt a check for port 7389. > > a2. If the master is ipa 3, this will default to dogtag_ds_port of 7389. > > > > B. Else if DS_PORT = 389, then we pass nothing to the > > ipa-replica-conncheck to be executed on the master. This is because we > > will be checking 389 in any case for the IPA DS check. > > > > Ade > > The code works, I got past the connection check, and now I'm getting the > same internal server error with a clone from IPA 2.2 as with a clone > from "3.0 upgraded from 2.2" (unknown object class "request"). > > However, since with this patch IPA will depend on Dogtag 10, > install_constants.DS_PORT will always be 389, so case A will never > happen. I think the two if-blocks that add the --check-ca can be dropped > entirely. > > Assuming that even a clone from an old instance will use the single DB, > conncheck's --dogtag-master-ds-port option is redundant: iff the server > supports it, it uses port 389 which doesn't need re-checking. > > > > > 0001-Allow-ipa-replica-conncheck-to-work-with-2.2-instanc.patch > > > > > > From a9cd4cb15e6c230e5690f3fa919fda9c5728ee10 Mon Sep 17 00:00:00 2001 > > From: Ade Lee > > Date: Thu, 4 Oct 2012 15:55:29 -0400 > > Subject: [PATCH] Allow ipa-replica-conncheck to work with 2.2 instances > > > > --- > > install/tools/ipa-replica-conncheck | 15 +++++++-------- > > 1 file changed, 7 insertions(+), 8 deletions(-) > > > > diff --git a/install/tools/ipa-replica-conncheck b/install/tools/ipa-replica-conncheck > > index c9fb816be43d873a6ca79396e77270fd0d10aa12..498ef49e84e1dc8325b6fc2d850c8bffb9297e69 100755 > > --- a/install/tools/ipa-replica-conncheck > > +++ b/install/tools/ipa-replica-conncheck > > @@ -282,7 +282,11 @@ def main(): > > > > required_ports = BASE_PORTS > > if options.check_ca: > > - ca_port = CheckedPort(int(options.dogtag_master_ds_port), SOCK_STREAM, > > + port_val = 7389 > > + if options.dogtag_master_ds_port: > > + port_val = int(options.dogtag_master_ds_port) > > + > > + ca_port = CheckedPort(port_val, SOCK_STREAM, > > "PKI-CA: Directory Service port") > > required_ports.extend([ca_port]) > > > > @@ -359,11 +363,8 @@ def main(): > > raise RuntimeError("Could not get ticket for master server: %s" % stderr) > > > > remote_check_opts = ['--replica %s' % options.hostname] > > - if options.check_ca: > > + if options.check_ca and dogtag.install_constants.DS_PORT == 7389: > > remote_check_opts.append('--check-ca') > > - remote_check_opts.extend(["--dogtag-master-ds-port", > > - str(dogtag.install_constants.DS_PORT)]) > > - > > > > print_info("Execute check on remote master") > > > > @@ -387,10 +388,8 @@ def main(): > > print_info("Please run the following command on remote master:") > > > > remote_check_opts = ['--replica %s' % options.hostname] > > - if options.check_ca: > > + if options.check_ca and dogtag.install_constants.DS_PORT == 7389: > > remote_check_opts.append('--check-ca') > > - remote_check_opts.extend(["--dogtag-master-ds-port", > > - str(dogtag.install_constants.DS_PORT)]) > > > > print_info("/usr/sbin/ipa-replica-conncheck " + " ".join(remote_check_opts)) > > time.sleep(3600) > > -- 1.7.12 > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-ipa-replica-prepare-to-include-correct-port.patch Type: text/x-patch Size: 967 bytes Desc: not available URL: From nalin at redhat.com Fri Oct 5 19:31:21 2012 From: nalin at redhat.com (Nalin Dahyabhai) Date: Fri, 5 Oct 2012 15:31:21 -0400 Subject: [Freeipa-devel] slow response In-Reply-To: References: <501AB9CC.1040509@redhat.com> <501AC1A6.3090600@redhat.com> <1343937842.20530.150.camel@willson.li.ssimo.org> <1344372819.20530.314.camel@willson.li.ssimo.org> <504FF402.1040803@redhat.com> Message-ID: <20121005193121.GA10103@redhat.com> On Fri, Oct 05, 2012 at 12:02:52PM -0700, Stephen Ingram wrote: > As I'm thinking this might also solve my IPA large memory usage issue, > I've been following this bug and see there is now a patch for it. I > also see it is in QA along with several other IPA-related (and > non-IPA-related) Kerberos fixes. That group is currently slated for a later update. > I thought at some point an errata > release would happen during the RHEL 6.3 time-frame, but as I'm not > too familiar with how this works, so I'm not sure. Is this a > possibility, or are these being held back for some reason like > additional QA time? The isolated fix was pushed as RHBA-2012:1294. Cheers, Nalin From alee at redhat.com Fri Oct 5 19:36:05 2012 From: alee at redhat.com (Ade Lee) Date: Fri, 05 Oct 2012 15:36:05 -0400 Subject: [Freeipa-devel] [PATCH] 1059 single CRL generator In-Reply-To: <1349454388.26127.9.camel@willson.li.ssimo.org> References: <506DB6A8.10504@redhat.com> <506EA171.20401@redhat.com> <506EF29B.8000102@redhat.com> <1349453945.19017.18.camel@aleeredhat.laptop> <1349454388.26127.9.camel@willson.li.ssimo.org> Message-ID: <1349465766.19017.31.camel@aleeredhat.laptop> On Fri, 2012-10-05 at 12:26 -0400, Simo Sorce wrote: > On Fri, 2012-10-05 at 12:19 -0400, Ade Lee wrote: > > On Fri, 2012-10-05 at 16:45 +0200, Martin Kosek wrote: > > > On 10/05/2012 10:59 AM, Martin Kosek wrote: > > > > On 10/04/2012 06:17 PM, Rob Crittenden wrote: > > > >> This changes the way IPA generates CRLs for new installs only. > > > >> > > > >> The first master installed is configured as the CRL generator. An entry is > > > >> added to cn=masters that designates it. > > > >> > > > >> When a replica is installed it queries this entry so it knows where to forward > > > >> CRL requests. CRL files are not available on cloned CAs (so /ipa/crl will > > > >> return not found). It is possible to get a CRL directly from the clone CA via > > > >> http://:9180/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL > > > >> > > > >> rob > > > > > > ... > > > > > > > 3) Majorish issue I hit with the actual CRL publishing on our server (F17). I > > > > always get 403 Forbidden error when trying to download CRL from the CRL master: > > > > > > > > # wget --ca-certificate /etc/ipa/ca.crt https://`hostname`/ipa/crl/MasterCRL.bin > > > > --2012-10-05 03:32:58-- > > > > https://vm-120.idm.lab.bos.redhat.com/ipa/crl/MasterCRL.bin > > > > Resolving vm-120.idm.lab.bos.redhat.com... 10.16.78.120 > > > > Connecting to vm-120.idm.lab.bos.redhat.com|10.16.78.120|:443... connected. > > > > HTTP request sent, awaiting response... 403 Forbidden > > > > 2012-10-05 03:32:58 ERROR 403: Forbidden. > > > > > > > > I tracked the problem down to too strict permission on /var/lib/pki-ca > > > > directory which is being published by httpd which does not have access to it: > > > > > > > > # ll /var/lib/pki-ca > > > > > > > > drwxrwx---. 11 pkiuser pkiuser 4096 Oct 5 03:00 pki-ca > > > > > > > > When I fixed the permission: > > > > # chmod o+x /var/lib/pki-ca/ > > > > > > > > I was able to get pass the Forbidden error and actually retrieved the CRL. > > > > Adding Ade on CC list to follow on this permission issue. > > > > > > FYI - I filed a ticket for this issue: > > > https://fedorahosted.org/freeipa/ticket/3144 > > > > > > I plan to simply fix permission on /var/lib/pki-ca/ in a similar way we do for > > > /var/lib/pki-ca/publish/ > > > > > > > Sorry, but why do you need permissions on /var/lib/pki-ca? Aren't > > permissions on /var/lib/pki-ca/publish sufficient? > > Ade, > on unix filesystems you cannot traverse a directory path if you do not > have permission all the way through. > If 'others' can't access /var/lib/pki-ca they will never even reach the > point where they can see that they have access to a subdirectory. > The very minimum permission you need to be able to traverse directories > is to have the 'traverse' (x) bit set. (note that you do not need the > read (r) bit set just to traverse). > I suspected as much, but wanted to confirm. The decision to publish the CRL to /var/lib/pki-ca/publish is an IPA deployment decision. This is a directory that is created by the IPA install scripts. Other folks who deploy Dogtag may choose to publish elsewhere - like under /var/www/... for instance. A location outside of the pki-ca tree seems like a safer option to me, rather than allowing "other" to step through /var/lib/pki-ca ... In any case, if you do decide to leave the publishing directory in that location, you will need to also set the +x permissions for other on /var/lib/pki-ca in the IPA install scripts. Ade > Simo. > From rcritten at redhat.com Fri Oct 5 19:49:37 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 05 Oct 2012 15:49:37 -0400 Subject: [Freeipa-devel] [PATCH] 83-84 Fix ipaIDobject usage In-Reply-To: <20121005132919.GS17454@redhat.com> References: <20121004164516.GD6816@localhost.localdomain> <20121005132919.GS17454@redhat.com> Message-ID: <506F39D1.2090604@redhat.com> Alexander Bokovoy wrote: > On Thu, 04 Oct 2012, Sumit Bose wrote: >> Hi, >> >> this is something that felt between the cracks. Some time ago we >> introduced a new objectclass ipaIDobject to allow objects to have an >> UID, GID or SID which are basically no users or groups. The DNA plugin >> should be aware of this new objectclass which is fix by the first patch. >> >> The second patch actually use this new objectclass in ipasam. Currenlty >> ipasam generates a hardcoded SID for the trusted domain user which might >> lead to confusion. With the second patch the trusted domain user has a >> proper SID. > ACK, works for me. > pushed to master and ipa-3-0 rob From rcritten at redhat.com Fri Oct 5 19:50:26 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 05 Oct 2012 15:50:26 -0400 Subject: [Freeipa-devel] [PATCH] 75-78 Add fallback group In-Reply-To: <1349459445.26127.25.camel@willson.li.ssimo.org> References: <20121002192901.GV6816@localhost.localdomain> <1349207792.22373.64.camel@willson.li.ssimo.org> <20121005132752.GR17454@redhat.com> <1349444758.22373.187.camel@willson.li.ssimo.org> <20121005163425.GI6816@localhost.localdomain> <20121005170232.GJ6816@localhost.localdomain> <1349459445.26127.25.camel@willson.li.ssimo.org> Message-ID: <506F3A02.3080004@redhat.com> Simo Sorce wrote: > On Fri, 2012-10-05 at 19:02 +0200, Sumit Bose wrote: >> On Fri, Oct 05, 2012 at 06:34:25PM +0200, Sumit Bose wrote: >>> On Fri, Oct 05, 2012 at 09:45:58AM -0400, Simo Sorce wrote: >>>> On Fri, 2012-10-05 at 16:27 +0300, Alexander Bokovoy wrote: >>>>> On Tue, 02 Oct 2012, Simo Sorce wrote: >>>>>> On Tue, 2012-10-02 at 21:29 +0200, Sumit Bose wrote: >>>>>>> Hi, >>>>>>> >>>>>>> this patch should fix https://fedorahosted.org/freeipa/ticket/2955 by >>>>>>> adding a fallback group as described in comment 2 of the ticket in >>>>>>> ipa-adtrust-install. >>>>>>> >>>>>>> If you prefer to use a different kind of group I can change the patch >>>>>>> accordingly. >>>>> Patch works for me, so ACK except the group name. >>>>> >>>>>> Yes I think we should use a more natural group name. In my recent >>>>>> testing I have been using the name 'Trust Users' that pairs well with >>>>>> another group we create called 'Trust Admins'. But I am open to >>>>>> suggestions on a better name, 'Domain Users' may be better if we really >>>>>> want to associate the wellknown SID to this group. >>>>> I'm fine with 'Trust Users'. >>>>> >>>>>> On the SID side I wonder if using the wellknown 'Domain Users' SID is >>>>>> the right thing to do. I do not see any special reasons why it shouldn't >>>>>> but I also do not have any special reason why we should. >>>>>> Anyone can think of any pros/cons of doing that ? >>>>> Since it only has special meaning within the same domain and we are not >>>>> using it for anything, it should be fine. >>>> >>>> Well it has a special meaning for samba servers ... we may have a few in >>>> the IPA domain. >>>> I think using that SID is fine but I think then the name 'Trust Users' >>>> could be confusing to users looking at permissions. >>>> >>>> We also need to make the group a posix group btw, because samba uses the >>>> Primary Group SID for users and if it can't be resolved to uid/gids it >>>> will probably prevent authentication. >>>> >>>> What about calling it 'Default SMB Group' or similar ? >>>> >>>> Simo. >>> >>> ok new version attached. The group is now a Posix with an >>> automatically assigned SID called 'default_smb_group' and in the >>> protected list. >>> >>> bye, >>> Sumit >>>> >>>> -- >>>> Simo Sorce * Red Hat, Inc * New York >>>> >> >> I found a copy-and-paste issue in the first patch, new version attached. >> >> bye, >> Sumit > > 0075: > > I think we should default_smb_group -> 'default smb group', > Default_SMB_Group -> 'Default SMB Group' etc... not sure why we > shouldn't use spaces here ? 'Trust Admins' has spaces we should be > consistent and use the same conventions everywhere for builtin groups. > > The comment in __add_admin_sids() is now wrong, we do not associate the > wellknown 'Domain Users' sid to the fallback group. The second phrase of > the docstring should simply be dropped. > > The description attribute of the group_add command in > __add_fallback_group() should use 'users' (plural) not 'user' I think. > > 0076: > > Ack > > 0077: > > I am going to Ack this patch but please open a ticket to fix edtection > of UPGs. It's not enough to have uidnumber to match the pgid gidnumber > to tell that the group is actually a upg. In cases where admins decide > to override the DNA plugin and user their own uid/gid allocation, they > may have users that use a real group as primary group (potentially with > the same name of the user too). We will need to verify we can use the > secondary rid range and to mangle the group name if that happens, but we > shouldn't fallback to the primary group fallback I think. > > However I do not think this is should hold back the patchset, so Ack. > > Nitpicks faillback -> fallback in get_fallback_group_sid() > > 0078: > > Nack, I think you had in mind the fact that the group we were using had > no posix IDs, but that should never be the case, samba needs the primary > group to be a posix group. > So I think we should just drop this patch, we do create the > Default_SMB_Group as a posix group. > > > Simo. > pushed 75-77 to master and ipa-3-0 rob From rcritten at redhat.com Fri Oct 5 19:50:42 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 05 Oct 2012 15:50:42 -0400 Subject: [Freeipa-devel] [PATCH] 82 ipa-adtrust-install: print list of needed SRV records In-Reply-To: <20121005132950.GT17454@redhat.com> References: <20121004104942.GC6816@localhost.localdomain> <20121005132950.GT17454@redhat.com> Message-ID: <506F3A12.90406@redhat.com> Alexander Bokovoy wrote: > On Thu, 04 Oct 2012, Sumit Bose wrote: >> Hi, >> >> this patch should fix the reopend >> https://fedorahosted.org/freeipa/ticket/3019 . > > ACK. > pushed to master and ipa-3-0 From rcritten at redhat.com Fri Oct 5 19:51:06 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 05 Oct 2012 15:51:06 -0400 Subject: [Freeipa-devel] [PATCH] 80 Avoid ldapmodify error messages during ipa-adtrust-install In-Reply-To: <20121004105442.GN17454@redhat.com> References: <20121004082018.GX6816@localhost.localdomain> <20121004091357.GK17454@redhat.com> <20121004093021.GY6816@localhost.localdomain> <20121004093907.GL17454@redhat.com> <20121004102602.GB6816@localhost.localdomain> <20121004105442.GN17454@redhat.com> Message-ID: <506F3A2A.2090301@redhat.com> Alexander Bokovoy wrote: > On Thu, 04 Oct 2012, Sumit Bose wrote: >> On Thu, Oct 04, 2012 at 12:39:07PM +0300, Alexander Bokovoy wrote: >>> On Thu, 04 Oct 2012, Sumit Bose wrote: >>> >On Thu, Oct 04, 2012 at 12:13:57PM +0300, Alexander Bokovoy wrote: >>> >>On Thu, 04 Oct 2012, Sumit Bose wrote: >>> >>>Hi, >>> >>> >>> >>>this patch tries to avoid the ldapmodiy error messages during >>> >>>ipa-adtrust-install by checking if the related object already exists. >>> >>>Fixes https://fedorahosted.org/freeipa/ticket/3012 . >>> >>In general -- ACK for the approach. However, I wonder if you could >>> create >>> >>a helper method that would accept: >>> >> - ldif file name, >>> >> - cn component >>> >> - name of the plugin for the "already configured" message >>> >> >>> >>Then every __add_* method would call simply the helper with >>> appropriate >>> >>arguments. >>> > >>> >yes, I was thinking about the same, but I preferred this solution for >>> >now instead of refactoring the current code. Additionally it would be >>> >nice if the helper method would read the DN from the ldif file to make >>> >the code more robust. Would you mind to open a trac ticket to refactor >>> >this part of the code? >>> I would disagree here. Reading DN from ldif file adds complexity for no >>> real gain. >>> >>> Refactoring this code is really simple -- your patch did already >>> introduced bigger change than that refactoring would make. >>> >>> If you aren't comfort with this suggestion, I can make the change >>> myself. Having these repeated patterns is hurting my eyes :) >> >> new version attached. > ACK. Thanks! > pushed to master and ipa-3-0 From mkosek at redhat.com Mon Oct 8 06:35:59 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 08 Oct 2012 08:35:59 +0200 Subject: [Freeipa-devel] [PATCH] 1059 single CRL generator In-Reply-To: <1349465766.19017.31.camel@aleeredhat.laptop> References: <506DB6A8.10504@redhat.com> <506EA171.20401@redhat.com> <506EF29B.8000102@redhat.com> <1349453945.19017.18.camel@aleeredhat.laptop> <1349454388.26127.9.camel@willson.li.ssimo.org> <1349465766.19017.31.camel@aleeredhat.laptop> Message-ID: <5072744F.30803@redhat.com> On 10/05/2012 09:36 PM, Ade Lee wrote: > On Fri, 2012-10-05 at 12:26 -0400, Simo Sorce wrote: >> On Fri, 2012-10-05 at 12:19 -0400, Ade Lee wrote: >>> On Fri, 2012-10-05 at 16:45 +0200, Martin Kosek wrote: >>>> On 10/05/2012 10:59 AM, Martin Kosek wrote: >>>>> On 10/04/2012 06:17 PM, Rob Crittenden wrote: >>>>>> This changes the way IPA generates CRLs for new installs only. >>>>>> >>>>>> The first master installed is configured as the CRL generator. An entry is >>>>>> added to cn=masters that designates it. >>>>>> >>>>>> When a replica is installed it queries this entry so it knows where to forward >>>>>> CRL requests. CRL files are not available on cloned CAs (so /ipa/crl will >>>>>> return not found). It is possible to get a CRL directly from the clone CA via >>>>>> http://:9180/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL >>>>>> >>>>>> rob >>>> >>>> ... >>>> >>>>> 3) Majorish issue I hit with the actual CRL publishing on our server (F17). I >>>>> always get 403 Forbidden error when trying to download CRL from the CRL master: >>>>> >>>>> # wget --ca-certificate /etc/ipa/ca.crt https://`hostname`/ipa/crl/MasterCRL.bin >>>>> --2012-10-05 03:32:58-- >>>>> https://vm-120.idm.lab.bos.redhat.com/ipa/crl/MasterCRL.bin >>>>> Resolving vm-120.idm.lab.bos.redhat.com... 10.16.78.120 >>>>> Connecting to vm-120.idm.lab.bos.redhat.com|10.16.78.120|:443... connected. >>>>> HTTP request sent, awaiting response... 403 Forbidden >>>>> 2012-10-05 03:32:58 ERROR 403: Forbidden. >>>>> >>>>> I tracked the problem down to too strict permission on /var/lib/pki-ca >>>>> directory which is being published by httpd which does not have access to it: >>>>> >>>>> # ll /var/lib/pki-ca >>>>> >>>>> drwxrwx---. 11 pkiuser pkiuser 4096 Oct 5 03:00 pki-ca >>>>> >>>>> When I fixed the permission: >>>>> # chmod o+x /var/lib/pki-ca/ >>>>> >>>>> I was able to get pass the Forbidden error and actually retrieved the CRL. >>>>> Adding Ade on CC list to follow on this permission issue. >>>> >>>> FYI - I filed a ticket for this issue: >>>> https://fedorahosted.org/freeipa/ticket/3144 >>>> >>>> I plan to simply fix permission on /var/lib/pki-ca/ in a similar way we do for >>>> /var/lib/pki-ca/publish/ >>>> >>> >>> Sorry, but why do you need permissions on /var/lib/pki-ca? Aren't >>> permissions on /var/lib/pki-ca/publish sufficient? >> >> Ade, >> on unix filesystems you cannot traverse a directory path if you do not >> have permission all the way through. >> If 'others' can't access /var/lib/pki-ca they will never even reach the >> point where they can see that they have access to a subdirectory. >> The very minimum permission you need to be able to traverse directories >> is to have the 'traverse' (x) bit set. (note that you do not need the >> read (r) bit set just to traverse). >> > > I suspected as much, but wanted to confirm. > > The decision to publish the CRL to /var/lib/pki-ca/publish is an IPA > deployment decision. This is a directory that is created by the IPA > install scripts. Other folks who deploy Dogtag may choose to publish > elsewhere - like under /var/www/... for instance. A location outside of > the pki-ca tree seems like a safer option to me, rather than allowing > "other" to step through /var/lib/pki-ca ... > > In any case, if you do decide to leave the publishing directory in that > location, you will need to also set the +x permissions for other > on /var/lib/pki-ca in the IPA install scripts. > > Ade Ok, I see 2 possible solutions here: 1) Add X permission to others all along the way to /var/lib/pki-ca/publish (dogtag9) or /var/lib/pki/pki-tomcat/ca/publish (dogtag10). 2) Move CRL publishing directory to tree controlled by IPA as Ade suggested. /var/lib/ipa/pki-ca/publish looks as a good target to me. I think this is a long-term solution than (mis)using pki-ca directory structure - which may change along the way as it did with dogtag10. Plus, we would no longer get SELinux warning during RPM upgrades when it cannot find dogtag9/dogtag10 path respectively. If we go with option 2), I wonder if it is doable in IPA 3.0 timeframe. I plan to try to poke at it today and see how it goes. Martin From pviktori at redhat.com Mon Oct 8 10:40:12 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 08 Oct 2012 12:40:12 +0200 Subject: [Freeipa-devel] [PATCH] [WIP] Firefox extension In-Reply-To: <506DB5CC.4070003@redhat.com> References: <506B1879.1090501@redhat.com> <506C4296.7060904@redhat.com> <1349273944.22373.89.camel@willson.li.ssimo.org> <506DB5CC.4070003@redhat.com> Message-ID: <5072AD8C.7070306@redhat.com> On 10/04/2012 06:14 PM, Petr Vobornik wrote: > > Updated patches attached. > > browserconfig.html points to older config method for versions prior to 15. > > The extension is theoretically compatible with FF3.6 and then FF10 and > later. There is a problem for FF4-9 with loading strings from > .properties file. FF3.6 is working because it doesn't use bootstraping. > > I also notice that we have an existing issue when navigating to config > pages right away before accepting any certificate. Those pages are using > some resorces from /ui/ folder which is redirected to https. These > resources are not loaded because certificate isn't imported. If user is > going straight for Web UI, he won't encounter this issue, but someone > might. > -- > Petr Vobornik > This breaks making replicas from masters upgraded from 2.2: > diff --git a/install/tools/ipa-replica-prepare b/install/tools/ipa-replica-prepare > index 56f132a380fc344ca069d554cc1e9ce8653aedb9..5ed8439ad305014c669e16ca3ff09aec697d65e3 100755 > --- a/install/tools/ipa-replica-prepare > +++ b/install/tools/ipa-replica-prepare > @@ -225,6 +225,8 @@ def copy_files(realm_name, dir): > try: > shutil.copy("/usr/share/ipa/html/ca.crt", dir + "/ca.crt") > if ipautil.file_exists("/usr/share/ipa/html/preferences.html"): > + shutil.copy("/usr/share/ipa/html/krb.js", dir + "/krb.js") > + shutil.copy("/usr/share/ipa/html/kerberosauth.xpi", dir + "/kerberosauth.xpi") These files aren't present on upgraded servers. I'll look into creating them on upgrade. -- Petr? From sbose at redhat.com Mon Oct 8 11:29:58 2012 From: sbose at redhat.com (Sumit Bose) Date: Mon, 8 Oct 2012 13:29:58 +0200 Subject: [Freeipa-devel] [PATCH] ipa-adtrust-install: create fallback group with ldif file Message-ID: <20121008112958.GQ6816@localhost.localdomain> Hi, this patch fixes https://fedorahosted.org/freeipa/ticket/3147 by adding the default fallback group with an LDIF file instead of using the framework. bye, Sumit -------------- next part -------------- From 2cd6a4e0f93c34df60a221ea7e96a5c2735ece4d Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Mon, 8 Oct 2012 10:44:07 +0200 Subject: [PATCH] ipa-adtrust-install: create fallback group with ldif file Currently the framework is used to add the group but we want to avoid that users are added explicitly to the group by removing the objectclasses groupofnames, ipausergroup and nestedgroup and we want to use a name with spaces in it. Both it not easy possible with the framework, a LDIF file is used instead to create the group. Fixes https://fedorahosted.org/freeipa/ticket/3147 --- install/share/Makefile.am | 1 + install/share/default-smb-group.ldif | 8 +++++++ ipaserver/install/adtrustinstance.py | 41 ++++++++++-------------------------- 3 Dateien ge?ndert, 20 Zeilen hinzugef?gt(+), 30 Zeilen entfernt(-) create mode 100644 install/share/default-smb-group.ldif diff --git a/install/share/Makefile.am b/install/share/Makefile.am index 03fef9a66f2f4c64e5685d4947c6f9139ac69ad0..23cd766a5a82ca514ffff9ebad82e0ee7db9ae77 100644 --- a/install/share/Makefile.am +++ b/install/share/Makefile.am @@ -16,6 +16,7 @@ app_DATA = \ caJarSigningCert.cfg.template \ default-aci.ldif \ default-hbac.ldif \ + default-smb-group.ldif \ delegation.ldif \ replica-acis.ldif \ ds-nfiles.ldif \ diff --git a/install/share/default-smb-group.ldif b/install/share/default-smb-group.ldif new file mode 100644 index 0000000000000000000000000000000000000000..8d89f67cc7d8be66375c9accb038b3c20a4d4be4 --- /dev/null +++ b/install/share/default-smb-group.ldif @@ -0,0 +1,8 @@ +dn: cn=Default SMB Group,cn=groups,cn=accounts,$SUFFIX +changetype: add +cn: Default SMB Group +description: Fallback group for primary group RID, do not add user to this group +gidnumber: 999 +objectclass: top +objectclass: ipaobject +objectclass: posixgroup diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py index 3f3924eb3ce9f56ac66407347645c40f96eb6430..41030223d1f644ba6a6557ac90d8f518fcba9c29 100644 --- a/ipaserver/install/adtrustinstance.py +++ b/ipaserver/install/adtrustinstance.py @@ -22,7 +22,6 @@ import errno import ldap import tempfile import uuid -import krbV from ipaserver import ipaldap from ipaserver.install import installutils from ipaserver.install import service @@ -101,7 +100,7 @@ class ADTRUSTInstance(service.Service): OBJC_USER = "ipaNTUserAttrs" OBJC_GROUP = "ipaNTGroupAttrs" OBJC_DOMAIN = "ipaNTDomainAttrs" - FALLBACK_GROUP_NAME = u'Default_SMB_Group' + FALLBACK_GROUP_NAME = u'Default SMB Group' def __init__(self, fstore=None): self.fqdn = None @@ -211,25 +210,6 @@ class ADTRUSTInstance(service.Service): """ self.ldap_connect() - try: - ctx = krbV.default_context() - ccache = ctx.default_ccache() - except krbV.Krb5Error, e: - self.print_msg("Must have Kerberos credentials to setup " \ - "AD trusts on server") - return - - try: - api.Backend.ldap2.disconnect() - api.Backend.ldap2.connect(ccache.name) - except errors.ACIError, e: - self.print_msg("Outdated Kerberos credentials. " \ - "Use kdestroy and kinit to update your ticket") - return - except errors.DatabaseError, e: - self.print_msg("Cannot connect to the LDAP database. " \ - "Please check if IPA is running") - return try: dom_entry = self.admin_conn.getEntry(self.smb_dom_dn, \ @@ -248,20 +228,21 @@ class ADTRUSTInstance(service.Service): self.admin_conn.getEntry(fb_group_dn, ldap.SCOPE_BASE) except errors.NotFound: try: - fallback = api.Command['group_add'](self.FALLBACK_GROUP_NAME, - description= u'Fallback group for ' \ - 'primary group RID, ' \ - 'do not add user to ' \ - 'this group', - nonposix=False) - fb_group_dn = fallback['result']['dn'] + self._ldap_mod('default-smb-group.ldif', self.sub_dict) except Exception, e: self.print_msg("Failed to add fallback group.") raise e + # _ldap_mod does not return useful error codes, so we must check again + # if the fallback group was created properly. try: - mod = [(ldap.MOD_ADD, self.ATTR_FALLBACK_GROUP, - fallback['result']['dn'])] + self.admin_conn.getEntry(fb_group_dn, ldap.SCOPE_BASE) + except errors.NotFound: + self.print_msg("Failed to add fallback group.") + return + + try: + mod = [(ldap.MOD_ADD, self.ATTR_FALLBACK_GROUP, fb_group_dn)] self.admin_conn.modify_s(self.smb_dom_dn, mod) except: self.print_msg("Failed to add fallback group to domain object") -- 1.7.11.4 From pvoborni at redhat.com Mon Oct 8 11:59:05 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 08 Oct 2012 13:59:05 +0200 Subject: [Freeipa-devel] [PATCH] 0082/0083 Handle NotFound exception when establishing trust In-Reply-To: <20121005181452.GX17454@redhat.com> References: <20121004150613.GP17454@redhat.com> <506EB9D1.3090604@redhat.com> <20121005132424.GQ17454@redhat.com> <506F0934.1070406@redhat.com> <20121005181452.GX17454@redhat.com> Message-ID: <5072C009.3080102@redhat.com> On 10/05/2012 08:14 PM, Alexander Bokovoy wrote: > On Fri, 05 Oct 2012, Petr Vobornik wrote: >> On 10/05/2012 03:24 PM, Alexander Bokovoy wrote: >>> On Fri, 05 Oct 2012, Petr Vobornik wrote: >>>> On 10/04/2012 05:06 PM, Alexander Bokovoy wrote: >>>>> >>>>> Hi, >>>>> >>>>> two attached patches attempt to solve >>>>> https://fedorahosted.org/freeipa/ticket/3103 >>>>> >>>>> We cannot make educated guess where trusted domain's DNS server is >>>>> located as we ended up with NotFound exception precisely because we >>>>> were >>>>> unable to discover trusted domain's domain controller location. >>>>> >>>>> Thus, all we can do is to suggest ways to fix the issue. Since >>>>> suggestion becomes relatively long (multi-line, at least), it creates >>>>> few issues for current exception error message handling: >>>>> - root_logger does not use textui to format output >>>>> - textui is only printing to standard output >>>>> - multi-line error messages thus become non-wrapped >>>>> - localizing such messages would become a harder context-wise. >>>>> >>>>> Web UI is showing error message as a single paragraph (

    ), all >>>>> multi-line markup would be lost. >>>>> >>>>> In the end, I decided to support list-based multi-line error >>>>> messages in >>>>> PublicError class. Its constructor will join all list-based arguments >>>>> into single string per argument (first patch). >>>>> >>>>> In Web UI I've added special text processing of error messages that >>>>> splits message into multiple lines and wraps those which start with a >>>>> TAB symbol into 'error-message-hinted' span to visually separate it >>>>> from >>>>> the rest of error message. Trust code uses this to display >>>>> suggested CLI >>>>> command to set up DNS forwarder (second patch). >>>>> >>>>> In the end, CLI shows such error message fine (note tabulated CLI >>>>> command): >>>>> ----------------------------------------------------------------------- >>>>> >>>>> # ipa trust-add --type=ad --admin Administrator at ad.local1 --password >>>>> ad.local1 >>>>> Active directory domain administrator's password: ipa: ERROR: >>>>> Unable to >>>>> resolve domain controller for 'ad.local1' domain. IPA manages DNS, >>>>> please configure forwarder to 'ad.local1' domain by using following >>>>> CLI >>>>> command. Please replace DNS_SERVER and IP_ADDRESS by name and >>>>> address of >>>>> the domain's name server: >>>>> ipa dnszone-add ad.local1 --name-server=DNS_SERVER >>>>> --admin-email='hostmaster at ad.local1' --force --forwarder=IP_ADDRESS >>>>> --forward-policy=only >>>>> When using Web UI, please create DNS zone for domain 'ad.local1' first >>>>> and then set forwarder and forward policy >>>>> ----------------------------------------------------------------------- >>>>> >>>>> >>>>> Web UI looks like this: http://abbra.fedorapeople.org/.paste/ui.png >>>>> >>>>> >>>> >>>> You have undeclared identifier: lines. >>>> >>>> I recommend to run `jsl -conf jsl.conf` command in install/ui folder >>>> to prevent these issues. >>> Fixed. >>> >>> >>>> I'm not convinced that "beautify" call should be in command object. I >>>> would rather see it in error_dialog. >>> I moved everything to error_dialog and used $() selectors instead of >>> directly playing with text. >> >> 1) >> + var error_message = $('', {}); >> >> I would rather see a

    as a container. Span is and should >> contain only inline elements. > Fixed. > >> 2) >> var line_span = $('', { >> class: 'error-message-hinted', >> text: lines[i].substr(1) >> }).appendTo(container); >> >> Why do you use for hinted message and

    for other lines? >> Shouldn't we use

    for both? > Fixed to use

    everywhere. > > >> 3) var line_span is declared twice. JS use function scope, not block >> scope. > Fixed. > > Thanks for the review. New patch 0082 attached. > > ACK on the UI part with a little change (updated patch attached): class: 'error-message-hinted', needs to be changed to 'class': 'error-message-hinted', because class is a keyword and should not be used this way. Sorry that I missed it before. The patch works as advertised. I would give ACK to the python part of 82 and patch 83 as well but probably someone more skilled in python and ipa internals should do it. Why do you have to concatenate the value in PublicErrors' __init__ method? Shouldn't it be a responsibility of error source (in this case 'execute_ad' method)? - just a question, not an issue -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-abbra-0082-support-multi-line-error-messages-in-exceptions-3.patch Type: text/x-patch Size: 4358 bytes Desc: not available URL: From abokovoy at redhat.com Mon Oct 8 12:22:29 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 8 Oct 2012 15:22:29 +0300 Subject: [Freeipa-devel] [PATCH] 0082/0083 Handle NotFound exception when establishing trust In-Reply-To: <5072C009.3080102@redhat.com> References: <20121004150613.GP17454@redhat.com> <506EB9D1.3090604@redhat.com> <20121005132424.GQ17454@redhat.com> <506F0934.1070406@redhat.com> <20121005181452.GX17454@redhat.com> <5072C009.3080102@redhat.com> Message-ID: <20121008122228.GB17454@redhat.com> On Mon, 08 Oct 2012, Petr Vobornik wrote: >On 10/05/2012 08:14 PM, Alexander Bokovoy wrote: >>On Fri, 05 Oct 2012, Petr Vobornik wrote: >>>On 10/05/2012 03:24 PM, Alexander Bokovoy wrote: >>>>On Fri, 05 Oct 2012, Petr Vobornik wrote: >>>>>On 10/04/2012 05:06 PM, Alexander Bokovoy wrote: >>>>>> >>>>>>Hi, >>>>>> >>>>>>two attached patches attempt to solve >>>>>>https://fedorahosted.org/freeipa/ticket/3103 >>>>>> >>>>>>We cannot make educated guess where trusted domain's DNS server is >>>>>>located as we ended up with NotFound exception precisely because we >>>>>>were >>>>>>unable to discover trusted domain's domain controller location. >>>>>> >>>>>>Thus, all we can do is to suggest ways to fix the issue. Since >>>>>>suggestion becomes relatively long (multi-line, at least), it creates >>>>>>few issues for current exception error message handling: >>>>>>- root_logger does not use textui to format output >>>>>>- textui is only printing to standard output >>>>>>- multi-line error messages thus become non-wrapped >>>>>>- localizing such messages would become a harder context-wise. >>>>>> >>>>>>Web UI is showing error message as a single paragraph (

    ), all >>>>>>multi-line markup would be lost. >>>>>> >>>>>>In the end, I decided to support list-based multi-line error >>>>>>messages in >>>>>>PublicError class. Its constructor will join all list-based arguments >>>>>>into single string per argument (first patch). >>>>>> >>>>>>In Web UI I've added special text processing of error messages that >>>>>>splits message into multiple lines and wraps those which start with a >>>>>>TAB symbol into 'error-message-hinted' span to visually separate it >>>>>>from >>>>>>the rest of error message. Trust code uses this to display >>>>>>suggested CLI >>>>>>command to set up DNS forwarder (second patch). >>>>>> >>>>>>In the end, CLI shows such error message fine (note tabulated CLI >>>>>>command): >>>>>>----------------------------------------------------------------------- >>>>>> >>>>>># ipa trust-add --type=ad --admin Administrator at ad.local1 --password >>>>>>ad.local1 >>>>>>Active directory domain administrator's password: ipa: ERROR: >>>>>>Unable to >>>>>>resolve domain controller for 'ad.local1' domain. IPA manages DNS, >>>>>>please configure forwarder to 'ad.local1' domain by using following >>>>>>CLI >>>>>>command. Please replace DNS_SERVER and IP_ADDRESS by name and >>>>>>address of >>>>>>the domain's name server: >>>>>> ipa dnszone-add ad.local1 --name-server=DNS_SERVER >>>>>>--admin-email='hostmaster at ad.local1' --force --forwarder=IP_ADDRESS >>>>>>--forward-policy=only >>>>>>When using Web UI, please create DNS zone for domain 'ad.local1' first >>>>>>and then set forwarder and forward policy >>>>>>----------------------------------------------------------------------- >>>>>> >>>>>> >>>>>>Web UI looks like this: http://abbra.fedorapeople.org/.paste/ui.png >>>>>> >>>>>> >>>>> >>>>>You have undeclared identifier: lines. >>>>> >>>>>I recommend to run `jsl -conf jsl.conf` command in install/ui folder >>>>>to prevent these issues. >>>>Fixed. >>>> >>>> >>>>>I'm not convinced that "beautify" call should be in command object. I >>>>>would rather see it in error_dialog. >>>>I moved everything to error_dialog and used $() selectors instead of >>>>directly playing with text. >>> >>>1) >>>+ var error_message = $('', {}); >>> >>>I would rather see a

    as a container. Span is and should >>>contain only inline elements. >>Fixed. >> >>>2) >>>var line_span = $('', { >>> class: 'error-message-hinted', >>> text: lines[i].substr(1) >>> }).appendTo(container); >>> >>>Why do you use for hinted message and

    for other lines? >>>Shouldn't we use

    for both? >>Fixed to use

    everywhere. >> >> >>>3) var line_span is declared twice. JS use function scope, not block >>>scope. >>Fixed. >> >>Thanks for the review. New patch 0082 attached. >> >> >ACK on the UI part with a little change (updated patch attached): > class: 'error-message-hinted', >needs to be changed to > 'class': 'error-message-hinted', >because class is a keyword and should not be used this way. Sorry >that I missed it before. Thanks! >The patch works as advertised. I would give ACK to the python part of >82 and patch 83 as well but probably someone more skilled in python >and ipa internals should do it. > >Why do you have to concatenate the value in PublicErrors' __init__ >method? Shouldn't it be a responsibility of error source (in this >case 'execute_ad' method)? - just a question, not an issue This is a good question and gives me some space to explain why certain decisions are made. The whole idea of the patch is to introduce a way to provide multi-line error messages as a feature of error handling in the FreeIPA framework. Suppose we had to join multiple lines always before creating an error object. This means we would have hundreds of '\n'.join() calls across the code. Besides maintenance burden, it would also make computational burden later if we would add proper content formating (which we don't do now for errors) -- since we would need to split strings later to reformat them. Python is flexible enough to discover parameter types which allows to design APIs that easer to use. "Easier to use" means least surprise for the caller rather than callee. So, if you pass multiple lines (list) of error message, each array element gets processed separately before displaying. So, in the end there is only one place where this processing happens, and it encapsulates all the knowledge required to accept multi-lines messages, regardless how they come, since it is applied uniformly to every argument of a constructor of a PublicError-derived class. -- / Alexander Bokovoy From simo at redhat.com Mon Oct 8 13:11:59 2012 From: simo at redhat.com (Simo Sorce) Date: Mon, 08 Oct 2012 09:11:59 -0400 Subject: [Freeipa-devel] [PATCH] ipa-adtrust-install: create fallback group with ldif file In-Reply-To: <20121008112958.GQ6816@localhost.localdomain> References: <20121008112958.GQ6816@localhost.localdomain> Message-ID: <1349701919.26127.111.camel@willson.li.ssimo.org> On Mon, 2012-10-08 at 13:29 +0200, Sumit Bose wrote: > Hi, > > this patch fixes https://fedorahosted.org/freeipa/ticket/3147 by > adding > the default fallback group with an LDIF file instead of using the > framework. > > bye, > Sumit > > > > > > > > plain text > document > attachment > (freeipa-sbose-0085-ipa-adtrust-install-create-fallback-group-with-ldif-.patch) > > From 2cd6a4e0f93c34df60a221ea7e96a5c2735ece4d Mon Sep 17 00:00:00 2001 > From: Sumit Bose > Date: Mon, 8 Oct 2012 10:44:07 +0200 > Subject: [PATCH] ipa-adtrust-install: create fallback group with ldif > file > > Currently the framework is used to add the group but we want to avoid > that users are added explicitly to the group by removing the > objectclasses groupofnames, ipausergroup and nestedgroup and we want > to > use a name with spaces in it. Both it not easy possible with the > framework, a LDIF file is used instead to create the group. > > Fixes https://fedorahosted.org/freeipa/ticket/3147 > --- > install/share/Makefile.am | 1 + > install/share/default-smb-group.ldif | 8 +++++++ > ipaserver/install/adtrustinstance.py | 41 > ++++++++++-------------------------- > 3 Dateien ge?ndert, 20 Zeilen hinzugef?gt(+), 30 Zeilen entfernt(-) > create mode 100644 install/share/default-smb-group.ldif > > diff --git a/install/share/Makefile.am b/install/share/Makefile.am > index > 03fef9a66f2f4c64e5685d4947c6f9139ac69ad0..23cd766a5a82ca514ffff9ebad82e0ee7db9ae77 100644 > --- a/install/share/Makefile.am > +++ b/install/share/Makefile.am > @@ -16,6 +16,7 @@ app_DATA = \ > caJarSigningCert.cfg.template \ > default-aci.ldif \ > default-hbac.ldif \ > + default-smb-group.ldif \ > delegation.ldif \ > replica-acis.ldif \ > ds-nfiles.ldif \ > diff --git a/install/share/default-smb-group.ldif > b/install/share/default-smb-group.ldif > new file mode 100644 > index > 0000000000000000000000000000000000000000..8d89f67cc7d8be66375c9accb038b3c20a4d4be4 > --- /dev/null > +++ b/install/share/default-smb-group.ldif > @@ -0,0 +1,8 @@ > +dn: cn=Default SMB Group,cn=groups,cn=accounts,$SUFFIX > +changetype: add > +cn: Default SMB Group > +description: Fallback group for primary group RID, do not add user to > this group Please change user -> users > +gidnumber: 999 > +objectclass: top > +objectclass: ipaobject > +objectclass: posixgroup > diff --git a/ipaserver/install/adtrustinstance.py > b/ipaserver/install/adtrustinstance.py > index > 3f3924eb3ce9f56ac66407347645c40f96eb6430..41030223d1f644ba6a6557ac90d8f518fcba9c29 100644 > --- a/ipaserver/install/adtrustinstance.py > +++ b/ipaserver/install/adtrustinstance.py > @@ -22,7 +22,6 @@ import errno > import ldap > import tempfile > import uuid > -import krbV > from ipaserver import ipaldap > from ipaserver.install import installutils > from ipaserver.install import service > @@ -101,7 +100,7 @@ class ADTRUSTInstance(service.Service): > OBJC_USER = "ipaNTUserAttrs" > OBJC_GROUP = "ipaNTGroupAttrs" > OBJC_DOMAIN = "ipaNTDomainAttrs" > - FALLBACK_GROUP_NAME = u'Default_SMB_Group' > + FALLBACK_GROUP_NAME = u'Default SMB Group' > > def __init__(self, fstore=None): > self.fqdn = None > @@ -211,25 +210,6 @@ class ADTRUSTInstance(service.Service): > """ > > self.ldap_connect() > - try: > - ctx = krbV.default_context() > - ccache = ctx.default_ccache() > - except krbV.Krb5Error, e: > - self.print_msg("Must have Kerberos credentials to setup " > \ > - "AD trusts on server") > - return > - > - try: > - api.Backend.ldap2.disconnect() > - api.Backend.ldap2.connect(ccache.name) > - except errors.ACIError, e: > - self.print_msg("Outdated Kerberos credentials. " \ > - "Use kdestroy and kinit to update your > ticket") > - return > - except errors.DatabaseError, e: > - self.print_msg("Cannot connect to the LDAP database. " \ > - "Please check if IPA is running") > - return > > try: > dom_entry = self.admin_conn.getEntry(self.smb_dom_dn, \ > @@ -248,20 +228,21 @@ class ADTRUSTInstance(service.Service): > self.admin_conn.getEntry(fb_group_dn, ldap.SCOPE_BASE) > except errors.NotFound: > try: > - fallback = > api.Command['group_add'](self.FALLBACK_GROUP_NAME, > - description= u'Fallback > group for ' \ > - 'primary > group RID, ' \ > - 'do not add > user to ' \ > - 'this > group', > - nonposix=False) > - fb_group_dn = fallback['result']['dn'] > + self._ldap_mod('default-smb-group.ldif', > self.sub_dict) > except Exception, e: > self.print_msg("Failed to add fallback group.") > raise e > > + # _ldap_mod does not return useful error codes, so we must > check again > + # if the fallback group was created properly. > try: > - mod = [(ldap.MOD_ADD, self.ATTR_FALLBACK_GROUP, > - fallback['result']['dn'])] > + self.admin_conn.getEntry(fb_group_dn, ldap.SCOPE_BASE) > + except errors.NotFound: > + self.print_msg("Failed to add fallback group.") > + return This exception block looks like on the wrong indentation (8 vs 4) ? > + > + try: > + mod = [(ldap.MOD_ADD, self.ATTR_FALLBACK_GROUP, > fb_group_dn)] > self.admin_conn.modify_s(self.smb_dom_dn, mod) > except: > self.print_msg("Failed to add fallback group to domain > object") Other than these minor issues, ack. Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Mon Oct 8 13:29:53 2012 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 08 Oct 2012 15:29:53 +0200 Subject: [Freeipa-devel] [PATCH 0077] Refactor settings subsystem Message-ID: <5072D551.10703@redhat.com> Hello, this patch refactors setting subsystem. After some experimenting I chosen simple implementation with static arrays, no RBT trees involved. Speed can be improved by reordering items in arrays. Commit message: Refactor settings subsystem. Settings are stored in tree of settings_set_t structures. All settings should be accessed only through setting* functions. Mutual exclusion during write is done by switching to single thread mode. Setting_get() function doesn't copy strings, so changing the original string can lead to obscure bugs. This way is okay as long as strings are not changed dynamically at run-time. Unknown setting in configuration file leads to failure rather than silent ignoring it. https://fedorahosted.org/bind-dyndb-ldap/ticket/53 https://fedorahosted.org/bind-dyndb-ldap/ticket/81 Adam, I'm still looking for way how to handle strings in settings. We have to prevent string change/deallocation as long as somebody has a pointer to the string (I mean pointer obtained through setting_get("name_of_setting") call). The only way which I can see is returning setting_string structure like setting_string struct { isc_refcount_t counter; isc_mem_t *mctx; char *str; }; Caller has to call setting_string_free() when string can be freed. Setting_string_free() will decrement counter by one and free whole structure if and only if counter reaches 0. Is it meaningful? Should I separate setting_get_* for each datatype? Or just for setting_get_string() and let setting_get() universal for integers and booleans? -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0077-Refactor-settings-subsystem.patch Type: text/x-patch Size: 86363 bytes Desc: not available URL: From mkosek at redhat.com Mon Oct 8 14:18:59 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 08 Oct 2012 16:18:59 +0200 Subject: [Freeipa-devel] [PATCH] 321 Move CRL publish directory to IPA owned directory Message-ID: <5072E0D3.10600@redhat.com> Currently, CRL files are being exported to /var/lib/pki-ca sub-directory, which is then served by httpd to clients. However, this approach has several disadvantages: * We depend on pki-ca directory structure and relevant permissions. If pki-ca changes directory structure or permissions on upgrade, IPA may break. This is also a root cause of the latest error, where the pki-ca directory does not have X permission for others and CRL publishing by httpd breaks. * Since the directory is not static and is generated during ipa-server-install, RPM upgrade of IPA packages report errors when defining SELinux policy for these directories. Move CRL publish directory to /var/lib/ipa/pki-ca/publish (common for both dogtag 9 and 10) which is created on RPM upgrade, i.e. SELinux policy configuration does not report any error. The new CRL publish directory is used for both new IPA installs and upgrades, where contents of the directory (CRLs) is first migrated to the new location and then the actual configuration change is made. https://fedorahosted.org/freeipa/ticket/3144 ------- We may choose to postpone this patch to later version, it is quite disruptive. I can produce a hotfix in that case, which would only fix the permission of the pki-ca directory. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-321-move-crl-publish-directory-to-ipa-owned-directory.patch Type: text/x-patch Size: 16797 bytes Desc: not available URL: From pspacek at redhat.com Mon Oct 8 14:46:54 2012 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 08 Oct 2012 16:46:54 +0200 Subject: [Freeipa-devel] [PATCH 0078] Use automatic connection management in LDAP modification code to prevent potential deadlock Message-ID: <5072E75E.1050305@redhat.com> Hello, Use automatic connection management in LDAP modification code to prevent potential deadlock. Without this patch the plugin will deadlock when modify_ldap_common() is called with PTR synchronization enabled and only single connection is available in the connection pool. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0078-Use-automatic-connection-management-in-LDAP-modifica.patch Type: text/x-patch Size: 2838 bytes Desc: not available URL: From rcritten at redhat.com Mon Oct 8 15:07:17 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 08 Oct 2012 11:07:17 -0400 Subject: [Freeipa-devel] Announcing FreeIPA v3.0.0 release candidate 2 Message-ID: <5072EC25.2000303@redhat.com> The FreeIPA team is proud to announce version FreeIPA v3.0.0 rc 2. It can be downloaded from http://www.freeipa.org/page/Downloads. Builds are not yet available but we plan builds for Fedora 18 and rawhide. The tarball is available on the Downloads page. For additional information see the AD Trust design page http://freeipa.org/page/IPAv3_AD_trust and the AD Trust testing page http://freeipa.org/page/IPAv3_testing_AD_trust. == Highlights since 3.0.0 rc 1 == * Python changes to work with python-ldap 2.3. * Add missing indices for automount and principal aliases which will improve performance. * Provide a new Firefox extension for configuring the browser. Firefox 15 deprecated the interface we used in the past to set the Kerberos negotiation directives. This new extension will be used on Firefox 15 and beyond, and the older interface for older browsers. * Man page improvements * A SID can be created as the last step of ipa-adtrust-install. * Create a default fallback group for AD trust users. == Upgrading == An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. Please note, that 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 should work but has not been fully tested. Proceed with caution. 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-devel mailing list: http://www.redhat.com/mailman/listinfo/freeipa-devel == Detailed changelog == Alexander Bokovoy (3): * Make sure external group members are listed for the external group * Change the way SID comparison is done for belonging to trusted domain * Support python-ldap 2.3 way of making LDAP control Martin Kosek (9): * Use custom zonemgr for reverse zones * Validate SELinux users in config-mod * Improve StrEnum validation error message * Add support for unified samba packages * Improve DN usage in ipa-client-install * Index ipakrbprincipalalias and ipaautomountkey attributes * Do not produce unindexed search on every DEL command * Only use service PAC type as an override * Fill ipakrbprincipalalias on upgrades Petr Viktorin (4): * Always handle NotFound error in dnsrecord-mod * Don't use bare except: clauses in ipa-client-install * Fix NS records in installation * Wait for secure Dogtag ports when starting the pki services Petr Vobornik (5): * Kerberos authentication extension * Kerberos authentication extension makefiles * Build and installation of Kerberos authentication extension * Configuration pages changed to use new FF extension * Removal of delegation-uris instruction from browser config Rob Crittenden (3): * Fix python syntax in ipa-client-automount * Clear kernel keyring in client installer, save dbdir on new connections * Become IPA v3 RC 2 (3.0.0.rc2) Sumit Bose (12): * Add man page paragraph about running ipa-adtrust-install multiple times * Enhance description of --no-msdcs in man page * Add --rid-base and --secondary-rid-base to ipa-adtrust-install man page * ipa-adtrust-install: remove wrong check for dm_password * ipa-adtrust-install: Add fallback group * ipa-adtrust-install: replace print with self.print_msg * ipasam: add fallback primary group * Add SIDs for existing users and groups at the end of ipa-adtrust-install * Avoid ldapmodify error messages during ipa-adtrust-install * ipa-adtrust-install: print list of needed SRV records * Add new ipaIDobject to DNA plugin configuraton * ipasam: generate proper SID for trusted domain object Tomas Babej (2): * Improve user addition to default group in user-add * Restrict admins group modifications From jcholast at redhat.com Mon Oct 8 15:12:12 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 08 Oct 2012 17:12:12 +0200 Subject: [Freeipa-devel] [PATCH] 1051 Fix CS replica management In-Reply-To: <505B5490.80303@redhat.com> References: <5040F7DA.5020606@redhat.com> <505AF524.5050405@redhat.com> <505B5490.80303@redhat.com> Message-ID: <5072ED4C.4070604@redhat.com> Hi, On 20.9.2012 19:38, Rob Crittenden wrote: > Jan Cholasta wrote: >> Hi, >> >> Dne 31.8.2012 19:43, Rob Crittenden napsal(a): >>> The naming in CS replication agreements is different from IPA >>> agreements, we have to live with what the create. The master side should >>> be on the local side, replica1, not the remote. This required reversing >>> a few master variables. >>> >>> Pass in the force flag to del_link. >>> >>> Do a better job of finding the agreements on each side. >>> >>> This should be ipa-csreplica-manage more in line with >>> ipa-replica-manage. >>> >>> rob >>> >> >> Rob, can you please rebase the patch on top of current master? There >> were some dogtag 10 related changes to ipa-csreplica-manage since you >> posted the patch. >> >> Honza >> > > I re-tested after the merge and found some problems with my initial > approach. The problem stems from the naming convention that dogtag uses > when creating the initial agreements. It is hard to predict how things > were set up later so rather than trying to reconstruct the DN we search > for it and pass it when deleting agreements. > > rob So far I have found this: * Deleting a "bridge" link that connects two "islands" of replicas works, but it should not (I was told that this is expected, as no complex graph algorithms are engaged to detect this kind of errors). * I have 5 masters, master1 to master5 (master1 was installed by ipa-server-install, the rest by ipa-replica-install & ipa-ca-install). I have created this replication topology: master3 - master2 - master1 - master4 - master5 from the initial replication topology: master2 master4 > master1 < master3 master5 by issuing: # ipa-csreplica-manage connect master2 master3 # ipa-csreplica-manage disconnect master1 master3 # ipa-csreplica-manage connect master4 master5 # ipa-csreplica-manage disconnect master1 master5 * When I do: # ipa-csreplica-manage disconnect master3 master5 it complains that "cannot remove the last replication link of 'master5", but there is no replication link between the two hosts. The problem persists even if I temporarily connect and disconnect the two hosts before trying to disconnect them again. If I connect master2 to master5 or master3 to master4 (or both of these), the problem goes away. * When I do: # ipa-csreplica-manage del master1 on master1, it complains that "'master1' has no replication agreement for 'master1'". When I do it on master2, it complains that "There were issues removing a connection: expected string or buffer" (this seems to happen every time the del command should in fact succeed, so it is probably broken). Investigating this further, I found that it is possible to delete masters only from a master that is directly connected to it. Shouldn't it be possible to delete masters from anywhere (as it is possible to add/delete links from anywhere)? * Any of these commands can be repeated infinitely: # ipa-csreplica-manage connect master1 master2 # ipa-csreplica-manage connect master2 master3 # ipa-csreplica-manage connect master1 master4 # ipa-csreplica-manage connect master4 master5 i.e. the "replication agreement already exists" check is not effective at all. An attempt to disconnect master2 from master3 or master4 from master5 always fails with "Cannot remove the last replication link of ", no matter how many times connect was called before. Honza -- Jan Cholasta From pviktori at redhat.com Mon Oct 8 15:37:10 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 08 Oct 2012 17:37:10 +0200 Subject: [Freeipa-devel] [PATCH] Changes to use a single database for dogtag and IPA In-Reply-To: <1349465098.19017.22.camel@aleeredhat.laptop> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50640DCB.2060901@redhat.com> <50699C3B.4050200@redhat.com> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> <506B096A.1070406@redhat.com> <1349381056.2357.8.camel@aleeredhat.laptop> <506EAF01.4070002@redhat.com> <1349465098.19017.22.camel@aleeredhat.laptop> Message-ID: <5072F326.4040500@redhat.com> On 10/05/2012 09:24 PM, Ade Lee wrote: > Agreed with your assessment that the --check-ca is not needed, as we > will be checking this into 3.1 (and not 3.0). Attaching patch that does this. It also removes the unneeded --dogtag-master-ds-port option. I'll squash it into the big patch later. > Attached is a patch for the "request object" issue. Basically, the > replication was not working because ipa-replica-prepare was passing in > the wrong port when creating the replica package. > > Let me know if you have issues - and remember to add the missing link to > the master. That fix to add that link will be checked in today and > should be in the dogtag developer nightly build as of tommorow. We are working on the issues off-list. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0086-Remove-unneeded-dogtag-master-ds-port-option-in-repl.patch Type: text/x-patch Size: 4628 bytes Desc: not available URL: From jhrozek at redhat.com Mon Oct 8 16:17:26 2012 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 8 Oct 2012 18:17:26 +0200 Subject: [Freeipa-devel] [PATCH] client: include the directory with domain-realm mappings in krb5.conf In-Reply-To: <223750653.6801841.1345220427417.JavaMail.root@redhat.com> References: <20120817114430.GC24190@zeppelin.brq.redhat.com> <223750653.6801841.1345220427417.JavaMail.root@redhat.com> Message-ID: <20121008161726.GF685@hendrix.brq.redhat.com> On Fri, Aug 17, 2012 at 12:20:27PM -0400, Simo Sorce wrote: > > > ----- Original Message ----- > > Hi, > > > > the attached patches add the directory the SSSD writes domain-realm > > mappings as includedir to krb5.conf when installing the client. > > > > [PATCH 1/3] ipachangeconf: allow specifying non-default delimeter for > > options > > ipachangeconf only allows one delimeter between keys and values. This > > patch adds the possibility of also specifying "delim" in the option > > dictionary to override the default delimeter. > > > > On a slightly-unrelated note, we really should think about adopting > > Augeas. Changing configuration with home-grown scripts is getting > > tricky. > > > > [PATCH 2/3] Specify includedir in krb5.conf on new installs > > This patch utilizes the new functionality from the previous patch to > > add > > the includedir on top of the krb5.conf file > > > > [PATCH 3/3] Add the includedir to krb5.conf on upgrades > > This patch is completely untested and I'm only posting it to get > > opinions. At first I was going to use an upgrade script in %post but > > then I thought it would be overengineering when all we want to do is > > prepend one line.. Would a simple munging like this be acceptable or > > shall I write a full script? > > NACK, using a scriptlet is fine, but not the way you did, as it has a huge race condition where krb5.conf exists and has only one line in it (the include line). > > You should first create the new file: echo "include ..." > /etc/krb.conf.ipanew > Then cat the contents of the existing file in i:t cat /etc/krb.conf >> /etc/krb.conf.ipanew > And finally atomically rename it: mv /etc/krb.conf.ipanew /etc/krb.conf > > This method is also safe wrt something killing the yum process ... > > Simo. I'm attaching a new revision of the patches not even two months after the original nack. I also think it might be nice to have a more general way of upgrading the client config so I filed https://fedorahosted.org/freeipa/ticket/3149 -------------- next part -------------- >From f93e181d4812dd66eda7cbc2cd9fc8ccc603e0c5 Mon Sep 17 00:00:00 2001 From: Jakub Hrozek Date: Fri, 17 Aug 2012 11:19:03 +0200 Subject: [PATCH 1/3] ipachangeconf: allow specifying non-default delimeter for options --- ipa-client/ipaclient/ipachangeconf.py | 37 +++++++++++++++++++++++------------ 1 file changed, 25 insertions(+), 12 deletions(-) diff --git a/ipa-client/ipaclient/ipachangeconf.py b/ipa-client/ipaclient/ipachangeconf.py index 6cf47b807957c245fe03ff4259e35526c49175a9..087e096920854bdd822d83182102723a2082af2a 100644 --- a/ipa-client/ipaclient/ipachangeconf.py +++ b/ipa-client/ipaclient/ipachangeconf.py @@ -174,9 +174,13 @@ class IPAChangeConf: self.subsectdel[1])) continue if o['type'] == "option": + delim = o.get('delim', self.dassign) + if delim not in self.assign: + raise ValueError('Unknown delim "%s" must be one of "%s"' % (delim, " ".join([d for d in self.assign]))) + output += self.indent[level]+o['name']+delim+o['value']+self.deol output.append(self._dump_line(self.indent[level], o['name'], - self.dassign, + delim, o['value'])) continue if o['type'] == "comment": @@ -200,13 +204,21 @@ class IPAChangeConf: 'type': 'comment', 'value': value.rstrip()} # pylint: disable=E1103 + o = dict() parts = line.split(self.dassign, 1) if len(parts) < 2: - raise SyntaxError('Syntax Error: Unknown line format') + # The default assign didn't match, try the non-default + for d in self.assign[1:]: + parts = line.split(d, 1) + if len(parts) >= 2: + o['delim'] = d + break - return {'name': parts[0].strip(), - 'type': 'option', - 'value': parts[1].rstrip()} + if 'delim' not in o: + raise SyntaxError, 'Syntax Error: Unknown line format' + + o.update({'name':parts[0].strip(), 'type':'option', 'value':parts[1].rstrip()}) + return o def findOpts(self, opts, type, name, exclude_sections=False): @@ -256,13 +268,14 @@ class IPAChangeConf: 'value': val}) continue if o['type'] == 'option': - val = self._dump_line(self.indent[level], - o['name'], - self.dassign, - o['value']) - opts.append({'name': 'comment', - 'type': 'comment', - 'value': val}) + delim = o.get('delim', self.dassign) + if delim not in self.assign: + val = self.indent[level]+o['name']+delim+o['value'] + val = self._dump_line(self.indent[level], + o['name'], + delim, + o['value']) + opts.append({'name':'comment', 'type':'comment', 'value':val}) continue if o['type'] == 'comment': opts.append(o) -- 1.7.11.4 -------------- next part -------------- >From 2e54029779e7930d72d51b5121eff25bf1d685ca Mon Sep 17 00:00:00 2001 From: Jakub Hrozek Date: Sun, 5 Aug 2012 20:47:12 +0200 Subject: [PATCH 2/3] Specify includedir in krb5.conf on new installs --- ipa-client/ipa-install/ipa-client-install | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install index 7b057a9878c566343d606ea7399cc9e4509e65b6..705e5dd0ca0bfe8e15bc68b79ca5e2f0a62ffe38 100755 --- a/ipa-client/ipa-install/ipa-client-install +++ b/ipa-client/ipa-install/ipa-client-install @@ -729,7 +729,7 @@ def configure_krb5_conf(cli_realm, cli_domain, cli_server, cli_kdc, dnsok, options, filename, client_domain): krbconf = ipaclient.ipachangeconf.IPAChangeConf("IPA Installer") - krbconf.setOptionAssignment(" = ") + krbconf.setOptionAssignment((" = ", " ")) krbconf.setSectionNameDelimiters(("[","]")) krbconf.setSubSectionDelimiters(("{","}")) krbconf.setIndent((""," "," ")) @@ -737,6 +737,10 @@ def configure_krb5_conf(cli_realm, cli_domain, cli_server, cli_kdc, dnsok, opts = [{'name':'comment', 'type':'comment', 'value':'File modified by ipa-client-install'}, {'name':'empty', 'type':'empty'}] + # SSSD include dir + opts.append({'name':'includedir', 'type':'option', 'value':'/var/lib/sss/pubconf/krb5.include.d/', 'delim':' '}) + opts.append({'name':'empty', 'type':'empty'}) + #[libdefaults] libopts = [{'name':'default_realm', 'type':'option', 'value':cli_realm}] if not dnsok or not cli_kdc or options.force: -- 1.7.11.4 -------------- next part -------------- >From 559697661223dc93cfef77d30efc01a2b21db1e4 Mon Sep 17 00:00:00 2001 From: Jakub Hrozek Date: Mon, 8 Oct 2012 15:25:53 +0200 Subject: [PATCH 3/3] Add the includedir to krb5.conf on upgrades --- freeipa.spec.in | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/freeipa.spec.in b/freeipa.spec.in index 7c8314a04dbd01303c9122b4822b074bc7bbff88..11534c1fa2f75d1348ccb3390ef3f274e90c8809 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -569,6 +569,16 @@ fi fi %endif +%post client +if egrep -q 'File modified by ipa-client-install' /etc/krb5.conf 2>/dev/null ; then + if ! egrep -q '/var/lib/sss/pubconf/krb5.include.d/' /etc/krb5.conf 2>/dev/null ; then + echo "includedir /var/lib/sss/pubconf/krb5.include.d/" > /etc/krb5.conf.ipanew + cat /etc/krb5.conf >> /etc/krb5.conf.ipanew + mv /etc/krb5.conf.ipanew /etc/krb5.conf + fi +fi + + %if ! %{ONLY_CLIENT} %files server -f server-python.list -- 1.7.11.4 From sbose at redhat.com Mon Oct 8 16:32:30 2012 From: sbose at redhat.com (Sumit Bose) Date: Mon, 8 Oct 2012 18:32:30 +0200 Subject: [Freeipa-devel] [PATCH] Fix up trust attributes on trust-add In-Reply-To: <20121005181747.GY17454@redhat.com> References: <1349450969.26127.1.camel@willson.li.ssimo.org> <20121005181747.GY17454@redhat.com> Message-ID: <20121008163230.GS6816@localhost.localdomain> On Fri, Oct 05, 2012 at 09:17:47PM +0300, Alexander Bokovoy wrote: > On Fri, 05 Oct 2012, Simo Sorce wrote: > >A onliner but better to have it validated by a second pair of eyes. > Yep. Go ahead. > > The origin of USES_RC4_ENCRYPTION comes from Samba 3 code in net utility > that Sumit implemented ~1.5 year ago. I didn't found any issues while testing. ACK bye, Sumit > > -- > / Alexander Bokovoy > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From sbose at redhat.com Mon Oct 8 16:35:21 2012 From: sbose at redhat.com (Sumit Bose) Date: Mon, 8 Oct 2012 18:35:21 +0200 Subject: [Freeipa-devel] [PATCH] ipa-adtrust-install: create fallback group with ldif file In-Reply-To: <1349701919.26127.111.camel@willson.li.ssimo.org> References: <20121008112958.GQ6816@localhost.localdomain> <1349701919.26127.111.camel@willson.li.ssimo.org> Message-ID: <20121008163521.GT6816@localhost.localdomain> On Mon, Oct 08, 2012 at 09:11:59AM -0400, Simo Sorce wrote: > On Mon, 2012-10-08 at 13:29 +0200, Sumit Bose wrote: > > Hi, > > > > this patch fixes https://fedorahosted.org/freeipa/ticket/3147 by > > adding > > the default fallback group with an LDIF file instead of using the > > framework. > > > > bye, > > Sumit > > > > > > > > > > > > > > > > plain text > > document > > attachment > > (freeipa-sbose-0085-ipa-adtrust-install-create-fallback-group-with-ldif-.patch) > > > > From 2cd6a4e0f93c34df60a221ea7e96a5c2735ece4d Mon Sep 17 00:00:00 2001 > > From: Sumit Bose > > Date: Mon, 8 Oct 2012 10:44:07 +0200 > > Subject: [PATCH] ipa-adtrust-install: create fallback group with ldif > > file > > > > Currently the framework is used to add the group but we want to avoid > > that users are added explicitly to the group by removing the > > objectclasses groupofnames, ipausergroup and nestedgroup and we want > > to > > use a name with spaces in it. Both it not easy possible with the > > framework, a LDIF file is used instead to create the group. > > > > Fixes https://fedorahosted.org/freeipa/ticket/3147 > > --- > > install/share/Makefile.am | 1 + > > install/share/default-smb-group.ldif | 8 +++++++ > > ipaserver/install/adtrustinstance.py | 41 > > ++++++++++-------------------------- > > 3 Dateien ge?ndert, 20 Zeilen hinzugef?gt(+), 30 Zeilen entfernt(-) > > create mode 100644 install/share/default-smb-group.ldif > > > > diff --git a/install/share/Makefile.am b/install/share/Makefile.am > > index > > 03fef9a66f2f4c64e5685d4947c6f9139ac69ad0..23cd766a5a82ca514ffff9ebad82e0ee7db9ae77 100644 > > --- a/install/share/Makefile.am > > +++ b/install/share/Makefile.am > > @@ -16,6 +16,7 @@ app_DATA = \ > > caJarSigningCert.cfg.template \ > > default-aci.ldif \ > > default-hbac.ldif \ > > + default-smb-group.ldif \ > > delegation.ldif \ > > replica-acis.ldif \ > > ds-nfiles.ldif \ > > diff --git a/install/share/default-smb-group.ldif > > b/install/share/default-smb-group.ldif > > new file mode 100644 > > index > > 0000000000000000000000000000000000000000..8d89f67cc7d8be66375c9accb038b3c20a4d4be4 > > --- /dev/null > > +++ b/install/share/default-smb-group.ldif > > @@ -0,0 +1,8 @@ > > +dn: cn=Default SMB Group,cn=groups,cn=accounts,$SUFFIX > > +changetype: add > > +cn: Default SMB Group > > +description: Fallback group for primary group RID, do not add user to > > this group > > Please change user -> users > > > +gidnumber: 999 > > +objectclass: top > > +objectclass: ipaobject > > +objectclass: posixgroup > > diff --git a/ipaserver/install/adtrustinstance.py > > b/ipaserver/install/adtrustinstance.py > > index > > 3f3924eb3ce9f56ac66407347645c40f96eb6430..41030223d1f644ba6a6557ac90d8f518fcba9c29 100644 > > --- a/ipaserver/install/adtrustinstance.py > > +++ b/ipaserver/install/adtrustinstance.py > > @@ -22,7 +22,6 @@ import errno > > import ldap > > import tempfile > > import uuid > > -import krbV > > from ipaserver import ipaldap > > from ipaserver.install import installutils > > from ipaserver.install import service > > @@ -101,7 +100,7 @@ class ADTRUSTInstance(service.Service): > > OBJC_USER = "ipaNTUserAttrs" > > OBJC_GROUP = "ipaNTGroupAttrs" > > OBJC_DOMAIN = "ipaNTDomainAttrs" > > - FALLBACK_GROUP_NAME = u'Default_SMB_Group' > > + FALLBACK_GROUP_NAME = u'Default SMB Group' > > > > def __init__(self, fstore=None): > > self.fqdn = None > > @@ -211,25 +210,6 @@ class ADTRUSTInstance(service.Service): > > """ > > > > self.ldap_connect() > > - try: > > - ctx = krbV.default_context() > > - ccache = ctx.default_ccache() > > - except krbV.Krb5Error, e: > > - self.print_msg("Must have Kerberos credentials to setup " > > \ > > - "AD trusts on server") > > - return > > - > > - try: > > - api.Backend.ldap2.disconnect() > > - api.Backend.ldap2.connect(ccache.name) > > - except errors.ACIError, e: > > - self.print_msg("Outdated Kerberos credentials. " \ > > - "Use kdestroy and kinit to update your > > ticket") > > - return > > - except errors.DatabaseError, e: > > - self.print_msg("Cannot connect to the LDAP database. " \ > > - "Please check if IPA is running") > > - return > > > > try: > > dom_entry = self.admin_conn.getEntry(self.smb_dom_dn, \ > > @@ -248,20 +228,21 @@ class ADTRUSTInstance(service.Service): > > self.admin_conn.getEntry(fb_group_dn, ldap.SCOPE_BASE) > > except errors.NotFound: > > try: > > - fallback = > > api.Command['group_add'](self.FALLBACK_GROUP_NAME, > > - description= u'Fallback > > group for ' \ > > - 'primary > > group RID, ' \ > > - 'do not add > > user to ' \ > > - 'this > > group', > > - nonposix=False) > > - fb_group_dn = fallback['result']['dn'] > > + self._ldap_mod('default-smb-group.ldif', > > self.sub_dict) > > except Exception, e: > > self.print_msg("Failed to add fallback group.") > > raise e > > > > + # _ldap_mod does not return useful error codes, so we must > > check again > > + # if the fallback group was created properly. > > try: > > - mod = [(ldap.MOD_ADD, self.ATTR_FALLBACK_GROUP, > > - fallback['result']['dn'])] > > + self.admin_conn.getEntry(fb_group_dn, ldap.SCOPE_BASE) > > + except errors.NotFound: > > + self.print_msg("Failed to add fallback group.") > > + return > > This exception block looks like on the wrong indentation (8 vs 4) ? > > > + > > + try: > > + mod = [(ldap.MOD_ADD, self.ATTR_FALLBACK_GROUP, > > fb_group_dn)] > > self.admin_conn.modify_s(self.smb_dom_dn, mod) > > except: > > self.print_msg("Failed to add fallback group to domain > > object") > > Other than these minor issues, ack. > > Simo. Thank you for the review, both issues are fixed in the new version. bye, Sumit > > -- > Simo Sorce * Red Hat, Inc * New York > -------------- next part -------------- From c901796f86f4a2cece790dc1e84614c7cb2a40ea Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Mon, 8 Oct 2012 10:44:07 +0200 Subject: [PATCH] ipa-adtrust-install: create fallback group with ldif file Currently the framework is used to add the group but we want to avoid that users are added explicitly to the group by removing the objectclasses groupofnames, ipausergroup and nestedgroup and we want to use a name with spaces in it. Both it not easy possible with the framework, a LDIF file is used instead to create the group. Fixes https://fedorahosted.org/freeipa/ticket/3147 --- install/share/Makefile.am | 1 + install/share/default-smb-group.ldif | 8 +++++++ ipaserver/install/adtrustinstance.py | 41 ++++++++++-------------------------- 3 Dateien ge?ndert, 20 Zeilen hinzugef?gt(+), 30 Zeilen entfernt(-) create mode 100644 install/share/default-smb-group.ldif diff --git a/install/share/Makefile.am b/install/share/Makefile.am index 03fef9a66f2f4c64e5685d4947c6f9139ac69ad0..23cd766a5a82ca514ffff9ebad82e0ee7db9ae77 100644 --- a/install/share/Makefile.am +++ b/install/share/Makefile.am @@ -16,6 +16,7 @@ app_DATA = \ caJarSigningCert.cfg.template \ default-aci.ldif \ default-hbac.ldif \ + default-smb-group.ldif \ delegation.ldif \ replica-acis.ldif \ ds-nfiles.ldif \ diff --git a/install/share/default-smb-group.ldif b/install/share/default-smb-group.ldif new file mode 100644 index 0000000000000000000000000000000000000000..abcc8a945a8187529044beeb73262b5434070b48 --- /dev/null +++ b/install/share/default-smb-group.ldif @@ -0,0 +1,8 @@ +dn: cn=Default SMB Group,cn=groups,cn=accounts,$SUFFIX +changetype: add +cn: Default SMB Group +description: Fallback group for primary group RID, do not add users to this group +gidnumber: 999 +objectclass: top +objectclass: ipaobject +objectclass: posixgroup diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py index 3f3924eb3ce9f56ac66407347645c40f96eb6430..d86f9f51463912c3541a27118843c30d88439ae5 100644 --- a/ipaserver/install/adtrustinstance.py +++ b/ipaserver/install/adtrustinstance.py @@ -22,7 +22,6 @@ import errno import ldap import tempfile import uuid -import krbV from ipaserver import ipaldap from ipaserver.install import installutils from ipaserver.install import service @@ -101,7 +100,7 @@ class ADTRUSTInstance(service.Service): OBJC_USER = "ipaNTUserAttrs" OBJC_GROUP = "ipaNTGroupAttrs" OBJC_DOMAIN = "ipaNTDomainAttrs" - FALLBACK_GROUP_NAME = u'Default_SMB_Group' + FALLBACK_GROUP_NAME = u'Default SMB Group' def __init__(self, fstore=None): self.fqdn = None @@ -211,25 +210,6 @@ class ADTRUSTInstance(service.Service): """ self.ldap_connect() - try: - ctx = krbV.default_context() - ccache = ctx.default_ccache() - except krbV.Krb5Error, e: - self.print_msg("Must have Kerberos credentials to setup " \ - "AD trusts on server") - return - - try: - api.Backend.ldap2.disconnect() - api.Backend.ldap2.connect(ccache.name) - except errors.ACIError, e: - self.print_msg("Outdated Kerberos credentials. " \ - "Use kdestroy and kinit to update your ticket") - return - except errors.DatabaseError, e: - self.print_msg("Cannot connect to the LDAP database. " \ - "Please check if IPA is running") - return try: dom_entry = self.admin_conn.getEntry(self.smb_dom_dn, \ @@ -248,20 +228,21 @@ class ADTRUSTInstance(service.Service): self.admin_conn.getEntry(fb_group_dn, ldap.SCOPE_BASE) except errors.NotFound: try: - fallback = api.Command['group_add'](self.FALLBACK_GROUP_NAME, - description= u'Fallback group for ' \ - 'primary group RID, ' \ - 'do not add user to ' \ - 'this group', - nonposix=False) - fb_group_dn = fallback['result']['dn'] + self._ldap_mod('default-smb-group.ldif', self.sub_dict) except Exception, e: self.print_msg("Failed to add fallback group.") raise e + # _ldap_mod does not return useful error codes, so we must check again + # if the fallback group was created properly. try: - mod = [(ldap.MOD_ADD, self.ATTR_FALLBACK_GROUP, - fallback['result']['dn'])] + self.admin_conn.getEntry(fb_group_dn, ldap.SCOPE_BASE) + except errors.NotFound: + self.print_msg("Failed to add fallback group.") + return + + try: + mod = [(ldap.MOD_ADD, self.ATTR_FALLBACK_GROUP, fb_group_dn)] self.admin_conn.modify_s(self.smb_dom_dn, mod) except: self.print_msg("Failed to add fallback group to domain object") -- 1.7.11.4 From abokovoy at redhat.com Mon Oct 8 17:31:52 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 8 Oct 2012 20:31:52 +0300 Subject: [Freeipa-devel] [PATCH] 0084 Add cifs principal to S4U2Proxy targets only when running ipa-adtrust-install Message-ID: <20121008173152.GD17454@redhat.com> Hi, attached patch moves S4U2Proxy configuration for CIFS service to ipa-adtrust-install. Since CIFS service is only available after running ipa-adtrust-install, we cannot reference its principal in advance. This means bootstrap template and updates processes cannot reference it directly or upgrading from older versions would not be possible due to referencing non-existent principal in updates. https://fedorahosted.org/freeipa/ticket/3041 -- / Alexander Bokovoy -------------- next part -------------- >From 2c29b1ee8e4bc0752be61889f254fb37f701dcbc Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Mon, 8 Oct 2012 13:27:16 +0300 Subject: [PATCH 3/4] Add cifs principal to S4U2Proxy targets only when running ipa-adtrust-install Since CIFS principal is generated by ipa-adtrust-install and is only usable after setting CIFS configuration, there is no need to include it into default setup. This should fix upgrades from 2.2 to 3.0 where CIFS principal does not exist by default. https://fedorahosted.org/freeipa/ticket/3041 --- install/share/bootstrap-template.ldif | 1 - install/share/replica-s4u2proxy.ldif | 6 ---- install/updates/60-trusts.update | 4 --- install/updates/61-trusts-s4u2proxy.update | 9 ++---- ipaserver/install/adtrustinstance.py | 46 ++++++++++++++++++++++++++---- 5 files changed, 42 insertions(+), 24 deletions(-) diff --git a/install/share/bootstrap-template.ldif b/install/share/bootstrap-template.ldif index 24804e475427ad7e5b2ae7c69d6cfb54cafbef38..a17f2518fce89232e6339fa1fdce508dd2c8f45c 100644 --- a/install/share/bootstrap-template.ldif +++ b/install/share/bootstrap-template.ldif @@ -195,7 +195,6 @@ changetype: add objectClass: groupOfPrincipals objectClass: top cn: ipa-cifs-delegation-targets -memberPrincipal: cifs/$HOST@$REALM dn: uid=admin,cn=users,cn=accounts,$SUFFIX changetype: add diff --git a/install/share/replica-s4u2proxy.ldif b/install/share/replica-s4u2proxy.ldif index 98de46fa7760965ea28fe15b29a16e88310e4992..c7ced5ee290103b1bc92e44d849835fda57ba03d 100644 --- a/install/share/replica-s4u2proxy.ldif +++ b/install/share/replica-s4u2proxy.ldif @@ -12,9 +12,3 @@ dn: cn=ipa-ldap-delegation-targets,cn=s4u2proxy,cn=etc,$SUFFIX changetype: modify add: memberPrincipal memberPrincipal: ldap/$FQDN@$REALM - -dn: cn=ipa-cifs-delegation-targets,cn=s4u2proxy,cn=etc,$SUFFIX -changetype: modify -add: memberPrincipal -memberPrincipal: cifs/$FQDN@$REALM - diff --git a/install/updates/60-trusts.update b/install/updates/60-trusts.update index cc9a771df901a90b457357c570dc06d34c0db4c8..bf2c58daa9bc6abb2bbcefecec98d0dca9a89d60 100644 --- a/install/updates/60-trusts.update +++ b/install/updates/60-trusts.update @@ -40,10 +40,6 @@ dn: cn=adtrust agents,cn=sysaccounts,cn=etc,$SUFFIX default: objectClass: GroupOfNames default: objectClass: top default: cn: adtrust agents -default: member: krbprincipalname=cifs/$FQDN@$REALM,cn=services,cn=accounts,$SUFFIX - -dn: cn=adtrust agents,cn=sysaccounts,cn=etc,$SUFFIX -add: member: krbprincipalname=cifs/$FQDN@$REALM,cn=services,cn=accounts,$SUFFIX dn: cn=trusts,$SUFFIX default: objectClass: top diff --git a/install/updates/61-trusts-s4u2proxy.update b/install/updates/61-trusts-s4u2proxy.update index 4a71148bc6bfd8a5464fef21153d5357e2f4ad9d..7504a068e2a3d773eb34fc09a959d324ff0d9430 100644 --- a/install/updates/61-trusts-s4u2proxy.update +++ b/install/updates/61-trusts-s4u2proxy.update @@ -1,12 +1,7 @@ -dn: cn=ipa-http-delegation,cn=s4u2proxy,cn=etc,$SUFFIX -add: ipaAllowedTarget: 'cn=ipa-cifs-delegation-targets,cn=s4u2proxy,cn=etc,$SUFFIX' - dn: cn=ipa-cifs-delegation-targets,cn=s4u2proxy,cn=etc,$SUFFIX default: objectClass: groupOfPrincipals default: objectClass: top default: cn: ipa-cifs-delegation-targets -default: memberPrincipal: cifs/$FQDN@$REALM - -dn: cn=ipa-cifs-delegation-targets,cn=s4u2proxy,cn=etc,$SUFFIX -add: memberPrincipal: cifs/$FQDN@$REALM +dn: cn=ipa-http-delegation,cn=s4u2proxy,cn=etc,$SUFFIX +add: ipaAllowedTarget: 'cn=ipa-cifs-delegation-targets,cn=s4u2proxy,cn=etc,$SUFFIX' diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py index 3f3924eb3ce9f56ac66407347645c40f96eb6430..4c4197a8a7650055a8c19ab7af31dd1477c05298 100644 --- a/ipaserver/install/adtrustinstance.py +++ b/ipaserver/install/adtrustinstance.py @@ -53,6 +53,13 @@ change with the command: Try updating the policycoreutils and selinux-policy packages. """ +UPGRADE_ERROR = """ +Entry %(dn)s does not exist. +This means upgrade from IPA 2.x to 3.x did not went well and required S4U2Proxy +configuration was not set up properly. Please run ipa-ldap-updater manually +and re-run ipa-adtrust-instal again afterwards. +""" + def check_inst(): for smbfile in ['/usr/sbin/smbd', '/usr/bin/net', '/usr/bin/smbpasswd']: if not os.path.exists(smbfile): @@ -401,6 +408,25 @@ class ADTRUSTInstance(service.Service): self.__add_plugin_conf('Extdom', 'ipa_extdom_extop', 'ipa-extdom-extop-conf.ldif') + def __add_s4u2proxy_target(self): + """ + Add CIFS principal to S4U2Proxy target + """ + + targets_dn = DN(('cn', 'ipa-cifs-delegation-targets'), ('cn', 's4u2proxy'), + ('cn', 'etc'), self.suffix) + try: + targets = self.admin_conn.getEntry(targets_dn, ldap.SCOPE_BASE) + current = ipaldap.Entry((targets_dn, targets.toDict())) + members = current.getValues('memberPrincipal') or [] + if not(self.cifs_principal in members): + current.setValues("memberPrincipal", members + [self.cifs_principal]) + self.admin_conn.updateEntry(targets_dn, targets.toDict(), current.toDict()) + else: + self.print_msg('cifs principal already targeted, nothing to do.') + except errors.NotFound: + self.print_msg(UPGRADE_ERROR % dict(dn=targets_dn)) + def __write_smb_registry(self): template = os.path.join(ipautil.SHARE_DIR, "smb.conf.template") conf = ipautil.template_file(template, self.sub_dict) @@ -421,12 +447,19 @@ class ADTRUSTInstance(service.Service): # Add the principal to the 'adtrust agents' group # as 389-ds only operates with GroupOfNames, we have to use # the principal's proper dn as defined in self.cifs_agent - entry = self.admin_conn.getEntry(self.smb_dn, ldap.SCOPE_BASE) - current = ipaldap.Entry(self.smb_dn, entry.toDict()) - if not('member' in current): - current['member'] = [] - entry.setValues("member", current['member'] + [self.cifs_agent]) - self.admin_conn.updateEntry(self.smb_dn, current, entry) + try: + entry = self.admin_conn.getEntry(self.smb_dn, ldap.SCOPE_BASE) + current = ipaldap.Entry((self.smb_dn, entry.toDict())) + members = current.getValues('member') or [] + if not(self.cifs_agent in members): + current.setValues("member", members + [self.cifs_agent]) + self.admin_conn.updateEntry(self.smb_dn, entry.toDict(), current.toDict()) + except errors.NotFound: + entry = ipaldap.Entry(self.smb_dn) + entry.setValues("objectclass", ["top", "GroupOfNames"]) + entry.setValues("cn", self.smb_dn['cn']) + entry.setValues("member", [self.cifs_agent]) + self.admin_conn.addEntry(entry) except Exception, e: # CIFS principal already exists, it is not the first time adtrustinstance is managed # That's fine, we we'll re-extract the key again. @@ -722,6 +755,7 @@ class ADTRUSTInstance(service.Service): self.step("creating samba config registry", self.__write_smb_registry) self.step("writing samba config file", self.__write_smb_conf) self.step("adding cifs Kerberos principal", self.__setup_principal) + self.step("adding cifs principal to S4U2Proxy targets", self.__add_s4u2proxy_target) self.step("adding admin(group) SIDs", self.__add_admin_sids) self.step("adding RID bases", self.__add_rid_bases) self.step("updating Kerberos config", self.__update_krb5_conf) -- 1.7.12 From abokovoy at redhat.com Mon Oct 8 17:34:19 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 8 Oct 2012 20:34:19 +0300 Subject: [Freeipa-devel] [PATCH] 0085 optimize SELinux setup in ipa-adtrust-install Message-ID: <20121008173419.GE17454@redhat.com> Hi, this patch avoids reconfiguring SELinux if required variable is already enabled. This would save you couple minutes on re-run of ipa-adtrust-install. No ticket for it yet and the patch might wait until 3.0.1 but "I had enogh patience" :) -- / Alexander Bokovoy -------------- next part -------------- >From 9a7df7115dfc4eaf22a6e5b33d5f20c1a13c09dd Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Mon, 8 Oct 2012 19:53:28 +0300 Subject: [PATCH 4/4] Avoid modifying SELinux variables when they already set while running ipa-adtrust-install This would save few minutes on re-run of ipa-adtrust-install --- ipaserver/install/adtrustinstance.py | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py index 4c4197a8a7650055a8c19ab7af31dd1477c05298..3c5c446658bec4fc9e5cdb733c8826b2ea95b0b4 100644 --- a/ipaserver/install/adtrustinstance.py +++ b/ipaserver/install/adtrustinstance.py @@ -553,8 +553,12 @@ class ADTRUSTInstance(service.Service): try: (stdout, stderr, returncode) = ipautil.run(["/usr/sbin/getsebool", var]) if stdout and not stderr and returncode == 0: - self.backup_state(var, stdout.split()[2]) - sebools.append(var) + value = stdout.split()[2] + self.backup_state(var, value) + if value.lower() == 'off': + sebools.append(var) + else: + self.print_msg("SELinux variable %s is already set, skipping" % (var)) except: pass -- 1.7.12 From simo at redhat.com Mon Oct 8 17:50:10 2012 From: simo at redhat.com (Simo Sorce) Date: Mon, 08 Oct 2012 13:50:10 -0400 Subject: [Freeipa-devel] [PATCH] ipa-adtrust-install: create fallback group with ldif file In-Reply-To: <20121008163521.GT6816@localhost.localdomain> References: <20121008112958.GQ6816@localhost.localdomain> <1349701919.26127.111.camel@willson.li.ssimo.org> <20121008163521.GT6816@localhost.localdomain> Message-ID: <1349718610.26127.113.camel@willson.li.ssimo.org> On Mon, 2012-10-08 at 18:35 +0200, Sumit Bose wrote: > > Thank you for the review, both issues are fixed in the new version. > Ack, Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Mon Oct 8 18:01:43 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 08 Oct 2012 14:01:43 -0400 Subject: [Freeipa-devel] [PATCH] 79 Add SIDs for existing users and groups at the end of ipa-adtrust-install In-Reply-To: <20121005135148.GU17454@redhat.com> References: <20121003093507.GW6816@localhost.localdomain> <20121005135148.GU17454@redhat.com> Message-ID: <50731507.6080804@redhat.com> Alexander Bokovoy wrote: > On Wed, 03 Oct 2012, Sumit Bose wrote: >> Hi, >> >> this patch adds a new option to ipa-adtrust-install to generate the SID >> for users and groups at the end of the run. This fixes >> https://fedorahosted.org/freeipa/ticket/3104 . > ACK, works for me too. > pushed to master and ipa-3-0 last Friday rob From simo at redhat.com Mon Oct 8 18:07:12 2012 From: simo at redhat.com (Simo Sorce) Date: Mon, 08 Oct 2012 14:07:12 -0400 Subject: [Freeipa-devel] [PATCH] client: include the directory with domain-realm mappings in krb5.conf In-Reply-To: <20121008161726.GF685@hendrix.brq.redhat.com> References: <20120817114430.GC24190@zeppelin.brq.redhat.com> <223750653.6801841.1345220427417.JavaMail.root@redhat.com> <20121008161726.GF685@hendrix.brq.redhat.com> Message-ID: <1349719632.26127.114.camel@willson.li.ssimo.org> On Mon, 2012-10-08 at 18:17 +0200, Jakub Hrozek wrote: > On Fri, Aug 17, 2012 at 12:20:27PM -0400, Simo Sorce wrote: > > > > > > ----- Original Message ----- > > > Hi, > > > > > > the attached patches add the directory the SSSD writes domain-realm > > > mappings as includedir to krb5.conf when installing the client. > > > > > > [PATCH 1/3] ipachangeconf: allow specifying non-default delimeter for > > > options > > > ipachangeconf only allows one delimeter between keys and values. This > > > patch adds the possibility of also specifying "delim" in the option > > > dictionary to override the default delimeter. > > > > > > On a slightly-unrelated note, we really should think about adopting > > > Augeas. Changing configuration with home-grown scripts is getting > > > tricky. > > > > > > [PATCH 2/3] Specify includedir in krb5.conf on new installs > > > This patch utilizes the new functionality from the previous patch to > > > add > > > the includedir on top of the krb5.conf file > > > > > > [PATCH 3/3] Add the includedir to krb5.conf on upgrades > > > This patch is completely untested and I'm only posting it to get > > > opinions. At first I was going to use an upgrade script in %post but > > > then I thought it would be overengineering when all we want to do is > > > prepend one line.. Would a simple munging like this be acceptable or > > > shall I write a full script? > > > > NACK, using a scriptlet is fine, but not the way you did, as it has a huge race condition where krb5.conf exists and has only one line in it (the include line). > > > > You should first create the new file: echo "include ..." > /etc/krb.conf.ipanew > > Then cat the contents of the existing file in i:t cat /etc/krb.conf >> /etc/krb.conf.ipanew > > And finally atomically rename it: mv /etc/krb.conf.ipanew /etc/krb.conf > > > > This method is also safe wrt something killing the yum process ... > > > > Simo. > > I'm attaching a new revision of the patches not even two months after > the original nack. > > I also think it might be nice to have a more general way of upgrading > the client config so I filed > https://fedorahosted.org/freeipa/ticket/3149 ACK Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Mon Oct 8 18:18:47 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 08 Oct 2012 14:18:47 -0400 Subject: [Freeipa-devel] [PATCH] 321 Move CRL publish directory to IPA owned directory In-Reply-To: <5072E0D3.10600@redhat.com> References: <5072E0D3.10600@redhat.com> Message-ID: <50731907.3060602@redhat.com> Martin Kosek wrote: > Currently, CRL files are being exported to /var/lib/pki-ca > sub-directory, which is then served by httpd to clients. However, > this approach has several disadvantages: > * We depend on pki-ca directory structure and relevant permissions. > If pki-ca changes directory structure or permissions on upgrade, > IPA may break. This is also a root cause of the latest error, where > the pki-ca directory does not have X permission for others and CRL > publishing by httpd breaks. > * Since the directory is not static and is generated during > ipa-server-install, RPM upgrade of IPA packages report errors when > defining SELinux policy for these directories. > > Move CRL publish directory to /var/lib/ipa/pki-ca/publish (common for > both dogtag 9 and 10) which is created on RPM upgrade, i.e. SELinux policy > configuration does not report any error. The new CRL publish directory > is used for both new IPA installs and upgrades, where contents of > the directory (CRLs) is first migrated to the new location and then the > actual configuration change is made. > > https://fedorahosted.org/freeipa/ticket/3144 > > > ------- > > We may choose to postpone this patch to later version, it is quite disruptive. > I can produce a hotfix in that case, which would only fix the permission of the > pki-ca directory. > > Martin This looks good, just a couple of questions. Should the old files be removed? Should some error handling be added around the copy to ensure it is successful? This would blow up if the disk was full, for example. rob From rcritten at redhat.com Mon Oct 8 18:27:15 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 08 Oct 2012 14:27:15 -0400 Subject: [Freeipa-devel] [PATCH] client: include the directory with domain-realm mappings in krb5.conf In-Reply-To: <20121008161726.GF685@hendrix.brq.redhat.com> References: <20120817114430.GC24190@zeppelin.brq.redhat.com> <223750653.6801841.1345220427417.JavaMail.root@redhat.com> <20121008161726.GF685@hendrix.brq.redhat.com> Message-ID: <50731B03.2080604@redhat.com> Jakub Hrozek wrote: > On Fri, Aug 17, 2012 at 12:20:27PM -0400, Simo Sorce wrote: >> >> >> ----- Original Message ----- >>> Hi, >>> >>> the attached patches add the directory the SSSD writes domain-realm >>> mappings as includedir to krb5.conf when installing the client. >>> >>> [PATCH 1/3] ipachangeconf: allow specifying non-default delimeter for >>> options >>> ipachangeconf only allows one delimeter between keys and values. This >>> patch adds the possibility of also specifying "delim" in the option >>> dictionary to override the default delimeter. >>> >>> On a slightly-unrelated note, we really should think about adopting >>> Augeas. Changing configuration with home-grown scripts is getting >>> tricky. >>> >>> [PATCH 2/3] Specify includedir in krb5.conf on new installs >>> This patch utilizes the new functionality from the previous patch to >>> add >>> the includedir on top of the krb5.conf file >>> >>> [PATCH 3/3] Add the includedir to krb5.conf on upgrades >>> This patch is completely untested and I'm only posting it to get >>> opinions. At first I was going to use an upgrade script in %post but >>> then I thought it would be overengineering when all we want to do is >>> prepend one line.. Would a simple munging like this be acceptable or >>> shall I write a full script? >> >> NACK, using a scriptlet is fine, but not the way you did, as it has a huge race condition where krb5.conf exists and has only one line in it (the include line). >> >> You should first create the new file: echo "include ..." > /etc/krb.conf.ipanew >> Then cat the contents of the existing file in i:t cat /etc/krb.conf >> /etc/krb.conf.ipanew >> And finally atomically rename it: mv /etc/krb.conf.ipanew /etc/krb.conf >> >> This method is also safe wrt something killing the yum process ... >> >> Simo. > > I'm attaching a new revision of the patches not even two months after > the original nack. > > I also think it might be nice to have a more general way of upgrading > the client config so I filed > https://fedorahosted.org/freeipa/ticket/3149 I don't think grepping for a string is an effective way to determine if the client has been configured. Someone could have removed that line. I'd prefer using /var/lib/ipa-client/sysrestore/sysrestore.index. If it exists and has more than 2 lines in it ([files] + one other file) then it is safe to say the client is configured, or at least partially configured. rob From mkosek at redhat.com Mon Oct 8 18:55:11 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 8 Oct 2012 14:55:11 -0400 (EDT) Subject: [Freeipa-devel] [PATCH] 321 Move CRL publish directory to IPA owned directory In-Reply-To: <50731907.3060602@redhat.com> Message-ID: <436570478.11020758.1349722511483.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Rob Crittenden" > To: "Martin Kosek" > Cc: freeipa-devel at redhat.com > Sent: Monday, October 8, 2012 8:18:47 PM > Subject: Re: [Freeipa-devel] [PATCH] 321 Move CRL publish directory to IPA owned directory > > Martin Kosek wrote: > > Currently, CRL files are being exported to /var/lib/pki-ca > > sub-directory, which is then served by httpd to clients. However, > > this approach has several disadvantages: > > * We depend on pki-ca directory structure and relevant > > permissions. > > If pki-ca changes directory structure or permissions on > > upgrade, > > IPA may break. This is also a root cause of the latest error, > > where > > the pki-ca directory does not have X permission for others and > > CRL > > publishing by httpd breaks. > > * Since the directory is not static and is generated during > > ipa-server-install, RPM upgrade of IPA packages report errors > > when > > defining SELinux policy for these directories. > > > > Move CRL publish directory to /var/lib/ipa/pki-ca/publish (common > > for > > both dogtag 9 and 10) which is created on RPM upgrade, i.e. SELinux > > policy > > configuration does not report any error. The new CRL publish > > directory > > is used for both new IPA installs and upgrades, where contents of > > the directory (CRLs) is first migrated to the new location and then > > the > > actual configuration change is made. > > > > https://fedorahosted.org/freeipa/ticket/3144 > > > > > > ------- > > > > We may choose to postpone this patch to later version, it is quite > > disruptive. > > I can produce a hotfix in that case, which would only fix the > > permission of the > > pki-ca directory. > > > > Martin > > This looks good, just a couple of questions. > > Should the old files be removed? Yeah, this is something I wonder about too. One one side, users may be get confused if there are 2 publish directories with the same content (a least until a next CRL generation). But on the other side, I was cautious not to delete something important in a case when something goes wrong. But maybe I am just being over-cautious and we can delete it, or maybe move directory to "publish.deleted". In a worst case scenario, CRLs should be generated again, in about 4 hours... > > Should some error handling be added around the copy to ensure it is > successful? This would blow up if the disk was full, for example. I think this is covered, I have there a try..except clause for this case: + for f in crl_files: + try: + copy_crl_file(f) + except Exception, e: + root_logger.error('Cannot move CRL file to new directory: %s', e) Just the exception is caught on a higher level and error is reported to user. Not sure what to do in this case - report error to user, do not change the location and ask user to resolve the error? Or just report error and continue with CRL publish directory change as I do currently? Martin From rcritten at redhat.com Mon Oct 8 19:29:42 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 08 Oct 2012 15:29:42 -0400 Subject: [Freeipa-devel] [PATCH] 321 Move CRL publish directory to IPA owned directory In-Reply-To: <436570478.11020758.1349722511483.JavaMail.root@redhat.com> References: <436570478.11020758.1349722511483.JavaMail.root@redhat.com> Message-ID: <507329A6.1090503@redhat.com> Martin Kosek wrote: > ----- Original Message ----- >> From: "Rob Crittenden" >> To: "Martin Kosek" >> Cc: freeipa-devel at redhat.com >> Sent: Monday, October 8, 2012 8:18:47 PM >> Subject: Re: [Freeipa-devel] [PATCH] 321 Move CRL publish directory to IPA owned directory >> >> Martin Kosek wrote: >>> Currently, CRL files are being exported to /var/lib/pki-ca >>> sub-directory, which is then served by httpd to clients. However, >>> this approach has several disadvantages: >>> * We depend on pki-ca directory structure and relevant >>> permissions. >>> If pki-ca changes directory structure or permissions on >>> upgrade, >>> IPA may break. This is also a root cause of the latest error, >>> where >>> the pki-ca directory does not have X permission for others and >>> CRL >>> publishing by httpd breaks. >>> * Since the directory is not static and is generated during >>> ipa-server-install, RPM upgrade of IPA packages report errors >>> when >>> defining SELinux policy for these directories. >>> >>> Move CRL publish directory to /var/lib/ipa/pki-ca/publish (common >>> for >>> both dogtag 9 and 10) which is created on RPM upgrade, i.e. SELinux >>> policy >>> configuration does not report any error. The new CRL publish >>> directory >>> is used for both new IPA installs and upgrades, where contents of >>> the directory (CRLs) is first migrated to the new location and then >>> the >>> actual configuration change is made. >>> >>> https://fedorahosted.org/freeipa/ticket/3144 >>> >>> >>> ------- >>> >>> We may choose to postpone this patch to later version, it is quite >>> disruptive. >>> I can produce a hotfix in that case, which would only fix the >>> permission of the >>> pki-ca directory. >>> >>> Martin >> >> This looks good, just a couple of questions. >> >> Should the old files be removed? > > Yeah, this is something I wonder about too. One one side, users may be get confused if there are 2 publish directories with the same content (a least until a next CRL generation). But on the other side, I was cautious not to delete something important in a case when something goes wrong. But maybe I am just being over-cautious and we can delete it, or maybe move directory to "publish.deleted". In a worst case scenario, CRLs should be generated again, in about 4 hours... > >> >> Should some error handling be added around the copy to ensure it is >> successful? This would blow up if the disk was full, for example. > > I think this is covered, I have there a try..except clause for this case: > > + for f in crl_files: > + try: > + copy_crl_file(f) > + except Exception, e: > + root_logger.error('Cannot move CRL file to new directory: %s', e) > > Just the exception is caught on a higher level and error is reported to user. Not sure what to do in this case - report error to user, do not change the location and ask user to resolve the error? Or just report error and continue with CRL publish directory change as I do currently? > > Martin > Ah, I was looking at too low a level. I think this is fine. I wonder if we should log/document somewhere in big flashing letters that the stuff has been moved. It is rather clear in the logs now, I suppose, if you look carefully. I guess it isn't really that big a deal now since we just have server certs. It would take a whole ton of revocations to grow the CRLs that quickly, so maybe my concerns are overblown. rob From sbose at redhat.com Mon Oct 8 20:40:14 2012 From: sbose at redhat.com (Sumit Bose) Date: Mon, 8 Oct 2012 22:40:14 +0200 Subject: [Freeipa-devel] [RFC] Reload trust data in ipadb In-Reply-To: <1349441081.22373.180.camel@willson.li.ssimo.org> References: <20121005101702.GE6816@localhost.localdomain> <20121005113204.GG6816@localhost.localdomain> <1349441081.22373.180.camel@willson.li.ssimo.org> Message-ID: <20121008204014.GV6816@localhost.localdomain> On Fri, Oct 05, 2012 at 08:44:41AM -0400, Simo Sorce wrote: > On Fri, 2012-10-05 at 13:32 +0200, Sumit Bose wrote: > > From f8726fe1c4a2ab71ada1297003e3dbe6068e4207 Mon Sep 17 00:00:00 2001 > > From: Sumit Bose > > Date: Fri, 5 Oct 2012 12:06:24 +0200 > > Subject: [PATCH] ipadb: reload trust information if domain is not know > > > > Currently the data about trusted domains is read once at startup. If a > > new trust is added the KDC must be restarted to know about the new > > trust. This patch reloads the trust data if there is a request from an > > unknown domain. To make DOS attacks a bit harder the data can be > > updated > > only once in a minute. > > --- > > daemons/ipa-kdb/ipa_kdb_mspac.c | 44 > > ++++++++++++++++++++++++++++++++--------- > > 1 Datei ge?ndert, 35 Zeilen hinzugef?gt(+), 9 Zeilen entfernt(-) > > > > diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c > > b/daemons/ipa-kdb/ipa_kdb_mspac.c > > index > > b5346fed1230d02a88c94ab913507112990a1651..f0bd3bfe913705abd44efb08325f54521533637e 100644 > > --- a/daemons/ipa-kdb/ipa_kdb_mspac.c > > +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c > > @@ -40,6 +40,7 @@ struct ipadb_mspac { > > > > int num_trusts; > > struct ipadb_adtrusts *trusts; > > + time_t last_update; > > }; > > > > > > @@ -983,6 +984,8 @@ static struct ipadb_adtrusts > > *get_domain_from_realm(krb5_context context, > > struct ipadb_context *ipactx; > > struct ipadb_adtrusts *domain; > > int i; > > + krb5_error_code kerr; > > + bool updated = false; > > The name of this variable sounds backwards, should be called need_update > or similar. this variable is not needed anymore > > > ipactx = ipadb_get_context(context); > > if (!ipactx) { > > @@ -993,17 +996,28 @@ static struct ipadb_adtrusts > > *get_domain_from_realm(krb5_context context, > > return NULL; > > } > > > > - for (i = 0; i < ipactx->mspac->num_trusts; i++) { > > - domain = &ipactx->mspac->trusts[i]; > > - if (strlen(domain->domain_name) != realm.length) { > > - continue; > > + do { > > + for (i = 0; i < ipactx->mspac->num_trusts; i++) { > > + domain = &ipactx->mspac->trusts[i]; > > + if (strlen(domain->domain_name) != realm.length) { > > + continue; > > + } > > + if (strncasecmp(domain->domain_name, realm.data, > > + realm.length) == 0) { > > + return domain; > > + } > > } > > - if (strncasecmp(domain->domain_name, realm.data, > > realm.length) == 0) { > > - return domain; > > - } > > - } > > > > - return NULL; > > + if (updated) { > > + return NULL; > > + } else { > > + kerr = ipadb_reinit_mspac(ipactx); > > + if (kerr != 0) { > > + return NULL; > > + } > > + updated = true; > > + } > > + } while(1); > > } > > I do not think I like the do/while loop here, I would rather have > another function that wraps the current get_domain_from_realm() like: > > static struct ipadb_adtrusts *get_domain_from_realm_update() > { > dom = get_domain_from_realm(); > if (dom == NULL) { > /* no dom, try to see if a new trust appeared */ > kerr = ipadb_reinit_mspac(ipactx); > dom = get_domain_from_realm(); > } > return dom; > } > > This is clearer imo, and allows you to decide if you really want to > update or if you want to call the non-updating function later on, should > we need it. done > > > static krb5_error_code filter_logon_info(krb5_context context, > > @@ -1550,6 +1564,16 @@ krb5_error_code ipadb_reinit_mspac(struct > > ipadb_context *ipactx) > > struct dom_sid gsid; > > char *resstr; > > int ret; > > + time_t now; > > + > > + /* Do not update the mspac struct more than once a minute. This > > would > > + * avoid heavy load on the directory server if there are lots of > > requests > > + * from domains which we do not trust. */ > > + now = time(NULL); > > + if (ipactx->mspac != NULL && now > ipactx->mspac->last_update && > > + (now - ipactx->mspac->last_update) < 60) { > > + return 0; > > + } > > > > /* clean up in case we had old values around */ > > ipadb_mspac_struct_free(&ipactx->mspac); > > @@ -1560,6 +1584,8 @@ krb5_error_code ipadb_reinit_mspac(struct > > ipadb_context *ipactx) > > goto done; > > } > > > > + ipactx->mspac->last_update = now; > > + > > kerr = ipadb_simple_search(ipactx, ipactx->base, > > LDAP_SCOPE_SUBTREE, > > "(objectclass=ipaNTDomainAttrs)", > > dom_attrs, > > &result); > > This part look fine, I wonder if we shouldn't make it even longer than 1 > min. I would prefer to keep it 1 minute to make the user experience better in the case where trust is added to more than one domain. I have opened https://fedorahosted.org/freeipa/ticket/3156 to track the reload issue. New version attatched. bye, Sumit > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > -------------- next part -------------- From 8c3eef19fb76e0f66d09a188946b7504696f284c Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Fri, 5 Oct 2012 12:06:24 +0200 Subject: [PATCH] ipadb: reload trust information if domain is not known Currently the data about trusted domains is read once at startup. If a new trust is added the KDC must be restarted to know about the new trust. This patch reloads the trust data if there is a request from an unknown domain. To make DOS attacks a bit harder the data can be updated only once in a minute. Fixes https://fedorahosted.org/freeipa/ticket/3156 --- daemons/ipa-kdb/ipa_kdb_mspac.c | 40 +++++++++++++++++++++++++++++++++++++++- 1 Datei ge?ndert, 39 Zeilen hinzugef?gt(+), 1 Zeile entfernt(-) diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index b3cef97db1bfe120d00b3bbfd30ed392dbb7b385..cf13ca37da96632caab6b2e4de6497184c4a51fa 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -40,6 +40,7 @@ struct ipadb_mspac { int num_trusts; struct ipadb_adtrusts *trusts; + time_t last_update; }; #ifdef DEBUG @@ -990,6 +991,31 @@ static struct ipadb_adtrusts *get_domain_from_realm(krb5_context context, return NULL; } +static struct ipadb_adtrusts *get_domain_from_realm_update(krb5_context context, + krb5_data realm) +{ + struct ipadb_context *ipactx; + struct ipadb_adtrusts *domain; + krb5_error_code kerr; + + domain = get_domain_from_realm(context, realm); + if (domain == NULL) { + ipactx = ipadb_get_context(context); + if (!ipactx) { + return NULL; + } + + kerr = ipadb_reinit_mspac(ipactx); + if (kerr != 0) { + return NULL; + } + + domain = get_domain_from_realm(context, realm); + } + + return domain; +} + static krb5_error_code filter_logon_info(krb5_context context, TALLOC_CTX *memctx, krb5_data realm, @@ -1004,7 +1030,7 @@ static krb5_error_code filter_logon_info(krb5_context context, struct ipadb_adtrusts *domain; char *domsid; - domain = get_domain_from_realm(context, realm); + domain = get_domain_from_realm_update(context, realm); if (!domain) { return EINVAL; } @@ -1534,6 +1560,16 @@ krb5_error_code ipadb_reinit_mspac(struct ipadb_context *ipactx) struct dom_sid gsid; char *resstr; int ret; + time_t now; + + /* Do not update the mspac struct more than once a minute. This would + * avoid heavy load on the directory server if there are lots of requests + * from domains which we do not trust. */ + now = time(NULL); + if (ipactx->mspac != NULL && now > ipactx->mspac->last_update && + (now - ipactx->mspac->last_update) < 60) { + return 0; + } /* clean up in case we had old values around */ ipadb_mspac_struct_free(&ipactx->mspac); @@ -1544,6 +1580,8 @@ krb5_error_code ipadb_reinit_mspac(struct ipadb_context *ipactx) goto done; } + ipactx->mspac->last_update = now; + kerr = ipadb_simple_search(ipactx, ipactx->base, LDAP_SCOPE_SUBTREE, "(objectclass=ipaNTDomainAttrs)", dom_attrs, &result); -- 1.7.11.4 From simo at redhat.com Mon Oct 8 20:54:02 2012 From: simo at redhat.com (Simo Sorce) Date: Mon, 08 Oct 2012 16:54:02 -0400 Subject: [Freeipa-devel] [RFC] Reload trust data in ipadb In-Reply-To: <20121008204014.GV6816@localhost.localdomain> References: <20121005101702.GE6816@localhost.localdomain> <20121005113204.GG6816@localhost.localdomain> <1349441081.22373.180.camel@willson.li.ssimo.org> <20121008204014.GV6816@localhost.localdomain> Message-ID: <1349729642.26127.119.camel@willson.li.ssimo.org> On Mon, 2012-10-08 at 22:40 +0200, Sumit Bose wrote: > On Fri, Oct 05, 2012 at 08:44:41AM -0400, Simo Sorce wrote: > > On Fri, 2012-10-05 at 13:32 +0200, Sumit Bose wrote: > > This part look fine, I wonder if we shouldn't make it even longer than 1 > > min. > > I would prefer to keep it 1 minute to make the user experience better in > the case where trust is added to more than one domain. > > I have opened https://fedorahosted.org/freeipa/ticket/3156 to track the > reload issue. > > New version attatched. ACK, Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Tue Oct 9 07:57:00 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 09 Oct 2012 09:57:00 +0200 Subject: [Freeipa-devel] [PATCH] 1051 Fix CS replica management In-Reply-To: <5072ED4C.4070604@redhat.com> References: <5040F7DA.5020606@redhat.com> <505AF524.5050405@redhat.com> <505B5490.80303@redhat.com> <5072ED4C.4070604@redhat.com> Message-ID: <5073D8CC.1040505@redhat.com> On 10/08/2012 05:12 PM, Jan Cholasta wrote: > Hi, > > On 20.9.2012 19:38, Rob Crittenden wrote: >> Jan Cholasta wrote: >>> Hi, >>> >>> Dne 31.8.2012 19:43, Rob Crittenden napsal(a): >>>> The naming in CS replication agreements is different from IPA >>>> agreements, we have to live with what the create. The master side should >>>> be on the local side, replica1, not the remote. This required reversing >>>> a few master variables. >>>> >>>> Pass in the force flag to del_link. >>>> >>>> Do a better job of finding the agreements on each side. >>>> >>>> This should be ipa-csreplica-manage more in line with >>>> ipa-replica-manage. >>>> >>>> rob >>>> >>> >>> Rob, can you please rebase the patch on top of current master? There >>> were some dogtag 10 related changes to ipa-csreplica-manage since you >>> posted the patch. >>> >>> Honza >>> >> >> I re-tested after the merge and found some problems with my initial >> approach. The problem stems from the naming convention that dogtag uses >> when creating the initial agreements. It is hard to predict how things >> were set up later so rather than trying to reconstruct the DN we search >> for it and pass it when deleting agreements. >> >> rob > > So far I have found this: > > * Deleting a "bridge" link that connects two "islands" of replicas works, but > it should not (I was told that this is expected, as no complex graph algorithms > are engaged to detect this kind of errors). Exactly, I hit this error when I was a similar Rob's patch for ipa-replica-manage (ticket 2797). I used topology "A - B - C - D - E" and I was able to delete C. We may want to log an enhancement ticket for this. Martin From mkosek at redhat.com Tue Oct 9 08:21:20 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 09 Oct 2012 10:21:20 +0200 Subject: [Freeipa-devel] [PATCH] 0082/0083 Handle NotFound exception when establishing trust In-Reply-To: <20121008122228.GB17454@redhat.com> References: <20121004150613.GP17454@redhat.com> <506EB9D1.3090604@redhat.com> <20121005132424.GQ17454@redhat.com> <506F0934.1070406@redhat.com> <20121005181452.GX17454@redhat.com> <5072C009.3080102@redhat.com> <20121008122228.GB17454@redhat.com> Message-ID: <5073DE80.3050600@redhat.com> On 10/08/2012 02:22 PM, Alexander Bokovoy wrote: > On Mon, 08 Oct 2012, Petr Vobornik wrote: >> On 10/05/2012 08:14 PM, Alexander Bokovoy wrote: >>> On Fri, 05 Oct 2012, Petr Vobornik wrote: >>>> On 10/05/2012 03:24 PM, Alexander Bokovoy wrote: >>>>> On Fri, 05 Oct 2012, Petr Vobornik wrote: >>>>>> On 10/04/2012 05:06 PM, Alexander Bokovoy wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> two attached patches attempt to solve >>>>>>> https://fedorahosted.org/freeipa/ticket/3103 >>>>>>> >>>>>>> We cannot make educated guess where trusted domain's DNS server is >>>>>>> located as we ended up with NotFound exception precisely because we >>>>>>> were >>>>>>> unable to discover trusted domain's domain controller location. >>>>>>> >>>>>>> Thus, all we can do is to suggest ways to fix the issue. Since >>>>>>> suggestion becomes relatively long (multi-line, at least), it creates >>>>>>> few issues for current exception error message handling: >>>>>>> - root_logger does not use textui to format output >>>>>>> - textui is only printing to standard output >>>>>>> - multi-line error messages thus become non-wrapped >>>>>>> - localizing such messages would become a harder context-wise. >>>>>>> >>>>>>> Web UI is showing error message as a single paragraph (

    ), all >>>>>>> multi-line markup would be lost. >>>>>>> >>>>>>> In the end, I decided to support list-based multi-line error >>>>>>> messages in >>>>>>> PublicError class. Its constructor will join all list-based arguments >>>>>>> into single string per argument (first patch). >>>>>>> >>>>>>> In Web UI I've added special text processing of error messages that >>>>>>> splits message into multiple lines and wraps those which start with a >>>>>>> TAB symbol into 'error-message-hinted' span to visually separate it >>>>>>> from >>>>>>> the rest of error message. Trust code uses this to display >>>>>>> suggested CLI >>>>>>> command to set up DNS forwarder (second patch). >>>>>>> >>>>>>> In the end, CLI shows such error message fine (note tabulated CLI >>>>>>> command): >>>>>>> ----------------------------------------------------------------------- >>>>>>> >>>>>>> # ipa trust-add --type=ad --admin Administrator at ad.local1 --password >>>>>>> ad.local1 >>>>>>> Active directory domain administrator's password: ipa: ERROR: >>>>>>> Unable to >>>>>>> resolve domain controller for 'ad.local1' domain. IPA manages DNS, >>>>>>> please configure forwarder to 'ad.local1' domain by using following >>>>>>> CLI >>>>>>> command. Please replace DNS_SERVER and IP_ADDRESS by name and >>>>>>> address of >>>>>>> the domain's name server: >>>>>>> ipa dnszone-add ad.local1 --name-server=DNS_SERVER >>>>>>> --admin-email='hostmaster at ad.local1' --force --forwarder=IP_ADDRESS >>>>>>> --forward-policy=only >>>>>>> When using Web UI, please create DNS zone for domain 'ad.local1' first >>>>>>> and then set forwarder and forward policy >>>>>>> ----------------------------------------------------------------------- >>>>>>> >>>>>>> >>>>>>> Web UI looks like this: http://abbra.fedorapeople.org/.paste/ui.png >>>>>>> >>>>>>> >>>>>> >>>>>> You have undeclared identifier: lines. >>>>>> >>>>>> I recommend to run `jsl -conf jsl.conf` command in install/ui folder >>>>>> to prevent these issues. >>>>> Fixed. >>>>> >>>>> >>>>>> I'm not convinced that "beautify" call should be in command object. I >>>>>> would rather see it in error_dialog. >>>>> I moved everything to error_dialog and used $() selectors instead of >>>>> directly playing with text. >>>> >>>> 1) >>>> + var error_message = $('', {}); >>>> >>>> I would rather see a

    as a container. Span is and should >>>> contain only inline elements. >>> Fixed. >>> >>>> 2) >>>> var line_span = $('', { >>>> class: 'error-message-hinted', >>>> text: lines[i].substr(1) >>>> }).appendTo(container); >>>> >>>> Why do you use for hinted message and

    for other lines? >>>> Shouldn't we use

    for both? >>> Fixed to use

    everywhere. >>> >>> >>>> 3) var line_span is declared twice. JS use function scope, not block >>>> scope. >>> Fixed. >>> >>> Thanks for the review. New patch 0082 attached. >>> >>> >> ACK on the UI part with a little change (updated patch attached): >> class: 'error-message-hinted', >> needs to be changed to >> 'class': 'error-message-hinted', >> because class is a keyword and should not be used this way. Sorry that I >> missed it before. > Thanks! > > >> The patch works as advertised. I would give ACK to the python part of 82 and >> patch 83 as well but probably someone more skilled in python and ipa >> internals should do it. >> >> Why do you have to concatenate the value in PublicErrors' __init__ method? >> Shouldn't it be a responsibility of error source (in this case 'execute_ad' >> method)? - just a question, not an issue > This is a good question and gives me some space to explain why certain > decisions are made. > > The whole idea of the patch is to introduce a way to provide multi-line > error messages as a feature of error handling in the FreeIPA framework. > > Suppose we had to join multiple lines always before creating an error > object. This means we would have hundreds of '\n'.join() calls across > the code. Besides maintenance burden, it would also make computational > burden later if we would add proper content formating (which we don't do > now for errors) -- since we would need to split strings later to > reformat them. > > Python is flexible enough to discover parameter types which > allows to design APIs that easer to use. "Easier to use" means least > surprise for the caller rather than callee. So, if you pass multiple > lines (list) of error message, each array element gets processed > separately before displaying. > So, in the end there is only one place where this processing happens, > and it encapsulates all the knowledge required to accept multi-lines > messages, regardless how they come, since it is applied uniformly to every > argument of a constructor of a PublicError-derived class. > Pushed both patches to master, ipa-3-0. Martin From mkosek at redhat.com Tue Oct 9 08:23:12 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 09 Oct 2012 10:23:12 +0200 Subject: [Freeipa-devel] [PATCH] ipa-adtrust-install: create fallback group with ldif file In-Reply-To: <1349718610.26127.113.camel@willson.li.ssimo.org> References: <20121008112958.GQ6816@localhost.localdomain> <1349701919.26127.111.camel@willson.li.ssimo.org> <20121008163521.GT6816@localhost.localdomain> <1349718610.26127.113.camel@willson.li.ssimo.org> Message-ID: <5073DEF0.9080002@redhat.com> On 10/08/2012 07:50 PM, Simo Sorce wrote: > On Mon, 2012-10-08 at 18:35 +0200, Sumit Bose wrote: >> >> Thank you for the review, both issues are fixed in the new version. >> > Ack, > Simo. > Pushed to master, ipa-3-0. Martin From mkosek at redhat.com Tue Oct 9 08:32:09 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 09 Oct 2012 10:32:09 +0200 Subject: [Freeipa-devel] [RFC] Reload trust data in ipadb In-Reply-To: <1349729642.26127.119.camel@willson.li.ssimo.org> References: <20121005101702.GE6816@localhost.localdomain> <20121005113204.GG6816@localhost.localdomain> <1349441081.22373.180.camel@willson.li.ssimo.org> <20121008204014.GV6816@localhost.localdomain> <1349729642.26127.119.camel@willson.li.ssimo.org> Message-ID: <5073E109.9010001@redhat.com> On 10/08/2012 10:54 PM, Simo Sorce wrote: > On Mon, 2012-10-08 at 22:40 +0200, Sumit Bose wrote: >> On Fri, Oct 05, 2012 at 08:44:41AM -0400, Simo Sorce wrote: >>> On Fri, 2012-10-05 at 13:32 +0200, Sumit Bose wrote: > >>> This part look fine, I wonder if we shouldn't make it even longer than 1 >>> min. >> >> I would prefer to keep it 1 minute to make the user experience better in >> the case where trust is added to more than one domain. >> >> I have opened https://fedorahosted.org/freeipa/ticket/3156 to track the >> reload issue. >> >> New version attatched. > > ACK, > Simo. > Rebased and pushed to master, ipa-3-0. Martin From mkosek at redhat.com Tue Oct 9 08:33:25 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 09 Oct 2012 10:33:25 +0200 Subject: [Freeipa-devel] [PATCH] Fix up trust attributes on trust-add In-Reply-To: <20121008163230.GS6816@localhost.localdomain> References: <1349450969.26127.1.camel@willson.li.ssimo.org> <20121005181747.GY17454@redhat.com> <20121008163230.GS6816@localhost.localdomain> Message-ID: <5073E155.601@redhat.com> On 10/08/2012 06:32 PM, Sumit Bose wrote: > On Fri, Oct 05, 2012 at 09:17:47PM +0300, Alexander Bokovoy wrote: >> On Fri, 05 Oct 2012, Simo Sorce wrote: >>> A onliner but better to have it validated by a second pair of eyes. >> Yep. Go ahead. >> >> The origin of USES_RC4_ENCRYPTION comes from Samba 3 code in net utility >> that Sumit implemented ~1.5 year ago. > > I didn't found any issues while testing. ACK > > bye, > Sumit > Pushed to master, ipa-3-0. Martin From mkosek at redhat.com Tue Oct 9 10:20:57 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 09 Oct 2012 12:20:57 +0200 Subject: [Freeipa-devel] [PATCH] ipa-adtrust-install: create fallback group with ldif file In-Reply-To: <5073DEF0.9080002@redhat.com> References: <20121008112958.GQ6816@localhost.localdomain> <1349701919.26127.111.camel@willson.li.ssimo.org> <20121008163521.GT6816@localhost.localdomain> <1349718610.26127.113.camel@willson.li.ssimo.org> <5073DEF0.9080002@redhat.com> Message-ID: <5073FA89.7000501@redhat.com> On 10/09/2012 10:23 AM, Martin Kosek wrote: > On 10/08/2012 07:50 PM, Simo Sorce wrote: >> On Mon, 2012-10-08 at 18:35 +0200, Sumit Bose wrote: >>> >>> Thank you for the review, both issues are fixed in the new version. >>> >> Ack, >> Simo. >> > > Pushed to master, ipa-3-0. > > Martin > I accidentally pushed older version of Sumit's patch, so I prepared an interdiff of these 2 patches. While at it, I squashed a one-liner amending a name of the default SMB group in a list of protected groups in group.py (patch attached), Pushed to master, ipa-3-0. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Minor-fixes-for-default-SMB-group.patch Type: text/x-patch Size: 2461 bytes Desc: not available URL: From atkac at redhat.com Tue Oct 9 11:08:23 2012 From: atkac at redhat.com (Adam Tkac) Date: Tue, 9 Oct 2012 13:08:23 +0200 Subject: [Freeipa-devel] [PATCH 0074] Fix zone removal in persistent search update_zone() In-Reply-To: <506EC141.7020508@redhat.com> References: <506EC141.7020508@redhat.com> Message-ID: <20121009110823.GB2593@redhat.com> On Fri, Oct 05, 2012 at 01:15:13PM +0200, Petr Spacek wrote: > Hello, > > Fix zone removal in persistent search update_zone(). > > Without this patch any zone removed through ipa dnszone-del will > remain active and will return SERVFAILs. Ack > From e09eebf3c370ff4106013cdeda10a80782e26611 Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Fri, 5 Oct 2012 13:02:37 +0200 > Subject: [PATCH] Fix zone removal in persistent search update_zone() handler. > > Signed-off-by: Petr Spacek > --- > src/ldap_helper.c | 20 ++++++++++---------- > 1 file changed, 10 insertions(+), 10 deletions(-) > > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index 68b635f84b4c9015752667510c0497e5f56bc7ab..199b345bb604c30bfa8a3690afc844ca8b264e89 100644 > --- a/src/ldap_helper.c > +++ b/src/ldap_helper.c > @@ -3056,7 +3056,6 @@ update_zone(isc_task_t *task, isc_event_t *event) > ldap_qresult_t *ldap_qresult_record = NULL; > ldap_entry_t *entry_zone = NULL; > ldap_entry_t *entry_record = NULL; > - isc_boolean_t delete = ISC_TRUE; > isc_mem_t *mctx; > dns_name_t prevname; > char *attrs_zone[] = { > @@ -3073,14 +3072,16 @@ update_zone(isc_task_t *task, isc_event_t *event) > dns_name_init(&prevname, NULL); > > CHECK(manager_get_ldap_instance(pevent->dbname, &inst)); > - CHECK(ldap_query(inst, NULL, &ldap_qresult_zone, pevent->dn, > + > + result = ldap_query(inst, NULL, &ldap_qresult_zone, pevent->dn, > LDAP_SCOPE_BASE, attrs_zone, 0, > - "(&(objectClass=idnsZone)(idnsZoneActive=TRUE))")); > + "(&(objectClass=idnsZone)(idnsZoneActive=TRUE))"); > + if (result != ISC_R_SUCCESS && result != ISC_R_NOTFOUND) > + CLEANUP_WITH(result); > > - for (entry_zone = HEAD(ldap_qresult_zone->ldap_entries); > - entry_zone != NULL; > - entry_zone = NEXT(entry_zone, link)) { > - delete = ISC_FALSE; > + if (result == ISC_R_SUCCESS && > + HEAD(ldap_qresult_zone->ldap_entries) != NULL) { > + entry_zone = HEAD(ldap_qresult_zone->ldap_entries); > CHECK(ldap_parse_zoneentry(entry_zone, inst)); > > if (PSEARCH_MODDN(pevent->chgtype)) { > @@ -3106,10 +3107,9 @@ update_zone(isc_task_t *task, isc_event_t *event) > } > > INSIST(NEXT(entry_zone, link) == NULL); /* no multiple zones with same DN */ > - } > - > - if (delete) > + } else { > CHECK(ldap_delete_zone(inst, pevent->dn, ISC_TRUE)); > + } > > cleanup: > if (result != ISC_R_SUCCESS) > -- > 1.7.11.4 > -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Tue Oct 9 11:09:20 2012 From: atkac at redhat.com (Adam Tkac) Date: Tue, 9 Oct 2012 13:09:20 +0200 Subject: [Freeipa-devel] [PATCH 0075] Prevent misleading "partial match" error messages for disabled zones In-Reply-To: <506EC866.5070603@redhat.com> References: <506EC866.5070603@redhat.com> Message-ID: <20121009110920.GC2593@redhat.com> On Fri, Oct 05, 2012 at 01:45:42PM +0200, Petr Spacek wrote: > Hello, > > Prevent misleading "partial match" error messages for disabled zones. > > Following message was printed if zone "e.test" was disabled and LDAP > contained zones "test" and "e.test": > update_zone (psearch) failed for > 'idnsName=e.test,cn=dns,dc=e,dc=org'. Zones can be outdated, run > `rndc reload`: partial match Ack > From e7f7a7d6e4fb3c9e47bac22d3291d09aa3d885ab Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Fri, 5 Oct 2012 13:37:18 +0200 > Subject: [PATCH] Prevent misleading "partial match" error messages for > disabled zones. > > Following message was printed if zone "e.test" was disabled and LDAP > contained zones "test" and "e.test": > update_zone (psearch) failed for 'idnsName=e.test,cn=dns,dc=e,dc=org'. Zones can be outdated, run `rndc reload`: partial match > > Signed-off-by: Petr Spacek > --- > src/ldap_helper.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index 199b345bb604c30bfa8a3690afc844ca8b264e89..d4bb6db10b0e79f8777fde3c5f344298af87ce56 100644 > --- a/src/ldap_helper.c > +++ b/src/ldap_helper.c > @@ -815,10 +815,9 @@ ldap_delete_zone2(ldap_instance_t *inst, dns_name_t *name, isc_boolean_t lock) > } > > result = zr_get_zone_ptr(inst->zone_register, name, &zone); > - if (result == ISC_R_NOTFOUND) { > + if (result == ISC_R_NOTFOUND || result == DNS_R_PARTIALMATCH) { > log_debug(1, "zone '%s' not found in zone register", zone_name_char); > - result = ISC_R_SUCCESS; > - goto cleanup; > + CLEANUP_WITH(ISC_R_SUCCESS); > } else if (result != ISC_R_SUCCESS) > goto cleanup; > > -- > 1.7.11.4 > -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Tue Oct 9 11:12:25 2012 From: atkac at redhat.com (Adam Tkac) Date: Tue, 9 Oct 2012 13:12:25 +0200 Subject: [Freeipa-devel] [PATCH 0071] Fix potential crash caused by failing zone_register allocation. In-Reply-To: <506AEA44.20307@redhat.com> References: <506AEA44.20307@redhat.com> Message-ID: <20121009111225.GD2593@redhat.com> On Tue, Oct 02, 2012 at 03:21:08PM +0200, Petr Spacek wrote: > Hello, > > Fix potential crash caused by failing zone_register allocation. > > Problematic call flow: > new_ldap_instance -> zr_create (returns failure) -> > destroy_ldap_instance -> zr_get_rbt (*crash*) Ack > From 9d96a9c4a4ac5b592ed5874132e0618b1b259de0 Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Tue, 2 Oct 2012 15:16:27 +0200 > Subject: [PATCH] Fix potential crash caused by failing zone_register > allocation. > > Signed-off-by: Petr Spacek > --- > src/ldap_helper.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index 38d86afa521dcf0e6b58ebb38635ff0fffbedd2a..629c76732c86af2a614e589a5afff18136068a66 100644 > --- a/src/ldap_helper.c > +++ b/src/ldap_helper.c > @@ -516,7 +516,7 @@ destroy_ldap_instance(ldap_instance_t **ldap_instp) > { > ldap_instance_t *ldap_inst; > dns_rbtnodechain_t chain; > - dns_rbt_t *rbt; > + dns_rbt_t *rbt = NULL; > isc_result_t result = ISC_R_SUCCESS; > const char *db_name; > > @@ -530,7 +530,10 @@ destroy_ldap_instance(ldap_instance_t **ldap_instp) > * > * NOTE: This should be probably done in zone_register.c > */ > - rbt = zr_get_rbt(ldap_inst->zone_register); > + if (ldap_inst->zone_register != NULL) > + rbt = zr_get_rbt(ldap_inst->zone_register); > + if (rbt == NULL) > + result = ISC_R_NOTFOUND; > > /* Potentially ISC_R_NOSPACE can occur. Destroy codepath has no way to > * return errors, so kill BIND. > -- > 1.7.11.4 > -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Tue Oct 9 11:15:01 2012 From: atkac at redhat.com (Adam Tkac) Date: Tue, 9 Oct 2012 13:15:01 +0200 Subject: [Freeipa-devel] [PATCH 0076] Fix crashes on BIND reload caused by improper error handling during new zone addition In-Reply-To: <506EF5FE.9090409@redhat.com> References: <506EF5FE.9090409@redhat.com> Message-ID: <20121009111501.GE2593@redhat.com> On Fri, Oct 05, 2012 at 05:00:14PM +0200, Petr Spacek wrote: > Hello, > > Fix crashes on BIND reload caused by improper error handling > during new zone addition. > > Crash can be triggered by invalid query/transfer/update ACLs > or potentially by error in zr_get_zone_ptr(). > > I found this problem during PATCH 75 testing, so there is a new ticket: > https://fedorahosted.org/bind-dyndb-ldap/ticket/93 Ack > From d0e958cac75035b212f87f00fade080b025d0a23 Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Fri, 5 Oct 2012 14:41:57 +0200 > Subject: [PATCH] Fix crashes on BIND reload caused by improper error handling > during new zone addition. > > Crash can be triggered by invalid query/transfer/update ACLs > or potentially by error in zr_get_zone_ptr(). > > https://fedorahosted.org/bind-dyndb-ldap/ticket/93 > > Signed-off-by: Petr Spacek > --- > src/ldap_helper.c | 14 ++++++++++++-- > 1 file changed, 12 insertions(+), 2 deletions(-) > > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index d4bb6db10b0e79f8777fde3c5f344298af87ce56..0e1cf6f7a6986db126aaa5329dbe9abbc98c8bf4 100644 > --- a/src/ldap_helper.c > +++ b/src/ldap_helper.c > @@ -1031,6 +1031,7 @@ ldap_parse_zoneentry(ldap_entry_t *entry, ldap_instance_t *inst) > isc_result_t result; > isc_boolean_t unlock = ISC_FALSE; > isc_boolean_t publish = ISC_FALSE; > + isc_boolean_t published = ISC_FALSE; > isc_task_t *task = inst->task; > isc_uint32_t ldap_serial; > isc_uint32_t zr_serial; /* SOA serial value from in-memory zone register */ > @@ -1074,12 +1075,13 @@ ldap_parse_zoneentry(ldap_entry_t *entry, ldap_instance_t *inst) > > /* Check if we are already serving given zone */ > result = zr_get_zone_ptr(inst->zone_register, &name, &zone); > - if (result != ISC_R_SUCCESS) { /* TODO: What about other errors? */ > + if (result == ISC_R_NOTFOUND || result == DNS_R_PARTIALMATCH) { > CHECK(create_zone(inst, &name, &zone)); > CHECK(zr_add_zone(inst->zone_register, zone, dn)); > publish = ISC_TRUE; > log_debug(2, "created zone %p: %s", zone, dn); > - } > + } else if (result != ISC_R_SUCCESS) > + CLEANUP_WITH(result); > > log_debug(2, "Setting SSU table for %p: %s", zone, dn); > /* Get the update policy and update the zone with it. */ > @@ -1119,6 +1121,7 @@ ldap_parse_zoneentry(ldap_entry_t *entry, ldap_instance_t *inst) > if (publish) { > /* Everything is set correctly, publish zone */ > CHECK(publish_zone(inst, zone)); > + published = ISC_TRUE; > } > > /* > @@ -1178,6 +1181,13 @@ ldap_parse_zoneentry(ldap_entry_t *entry, ldap_instance_t *inst) > } > > cleanup: > + if (publish && !published) { /* Failure in ACL parsing or so. */ > + log_error_r("zone '%s': publishing failed, rolling back due to", > + entry->dn); > + result = zr_del_zone(inst->zone_register, &name); > + if (result != ISC_R_SUCCESS) > + log_error_r("zone '%s': rollback failed", entry->dn); > + } > if (unlock) > isc_task_endexclusive(task); > if (dns_name_dynamic(&name)) > -- > 1.7.11.4 > -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Tue Oct 9 11:21:58 2012 From: atkac at redhat.com (Adam Tkac) Date: Tue, 9 Oct 2012 13:21:58 +0200 Subject: [Freeipa-devel] [PATCH 0078] Use automatic connection management in LDAP modification code to prevent potential deadlock In-Reply-To: <5072E75E.1050305@redhat.com> References: <5072E75E.1050305@redhat.com> Message-ID: <20121009112157.GF2593@redhat.com> On Mon, Oct 08, 2012 at 04:46:54PM +0200, Petr Spacek wrote: > Hello, > > Use automatic connection management in LDAP modification code to > prevent potential deadlock. > > Without this patch the plugin will deadlock when modify_ldap_common() > is called with PTR synchronization enabled and only single > connection is available in the connection pool. Nack If I read the patch correctly, it leaves unused ldap_conn parameters in ldap_modify_do() and modify_soa_record() functions. Those params are always NULL so they can be safely removed. Please also remove the "autoconn" variable from ldap_modify_do() Regards, Adam > From 5ad686a95510b1584c85d672ec845b27504f746c Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Mon, 8 Oct 2012 16:41:40 +0200 > Subject: [PATCH] Use automatic connection management in LDAP modification > code to prevent potential deadlock. > > Without this patch the plugin will deadlock when modify_ldap_common() > is called with PTR synchronization enabled and only single > connection is available in the connection pool. > > Signed-off-by: Petr Spacek > --- > src/ldap_helper.c | 11 ++++------- > 1 file changed, 4 insertions(+), 7 deletions(-) > > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index f8df1b29871c28a1eeecfa93d5d91edd1aee3944..03adb83bdc34593ec527facd3e3fc60755a4de22 100644 > --- a/src/ldap_helper.c > +++ b/src/ldap_helper.c > @@ -2593,7 +2593,6 @@ modify_ldap_common(dns_name_t *owner, ldap_instance_t *ldap_inst, > { > isc_result_t result; > isc_mem_t *mctx = ldap_inst->mctx; > - ldap_connection_t *ldap_conn = NULL; > ld_string_t *owner_dn = NULL; > LDAPMod *change[3] = { NULL }; > LDAPMod *change_ptr = NULL; > @@ -2630,8 +2629,6 @@ modify_ldap_common(dns_name_t *owner, ldap_instance_t *ldap_inst, > > CHECK(dn_to_dnsname(mctx, zone_dn, &zone_name, NULL)); > > - CHECK(ldap_pool_getconnection(ldap_inst->pool, &ldap_conn)); > - > result = zr_get_zone_settings(ldap_inst->zone_register, &zone_name, > &zone_settings); > if (result != ISC_R_SUCCESS) { > @@ -2655,7 +2652,7 @@ modify_ldap_common(dns_name_t *owner, ldap_instance_t *ldap_inst, > CHECK(discard_from_cache(cache, owner)); > > if (rdlist->type == dns_rdatatype_soa) { > - result = modify_soa_record(ldap_inst, ldap_conn, str_buf(owner_dn), > + result = modify_soa_record(ldap_inst, NULL, str_buf(owner_dn), > HEAD(rdlist->rdata)); > goto cleanup; > } > @@ -2666,7 +2663,7 @@ modify_ldap_common(dns_name_t *owner, ldap_instance_t *ldap_inst, > CHECK(ldap_rdttl_to_ldapmod(mctx, rdlist, &change[1])); > } > > - CHECK(ldap_modify_do(ldap_inst, ldap_conn, str_buf(owner_dn), change, delete_node)); > + CHECK(ldap_modify_do(ldap_inst, NULL, str_buf(owner_dn), change, delete_node)); > > /* Keep the PTR of corresponding A/AAAA record synchronized. */ > if (rdlist->type == dns_rdatatype_a || rdlist->type == dns_rdatatype_aaaa) { > @@ -2824,13 +2821,13 @@ modify_ldap_common(dns_name_t *owner, ldap_instance_t *ldap_inst, > change_ptr = NULL; > > /* Modify PTR record. */ > - CHECK(ldap_modify_do(ldap_inst, ldap_conn, str_buf(owner_dn_ptr), change, delete_node)); > + CHECK(ldap_modify_do(ldap_inst, NULL, str_buf(owner_dn_ptr), > + change, delete_node)); > (void) discard_from_cache(ldap_instance_getcache(ldap_inst), > dns_fixedname_name(&ptr_name)); > } > > cleanup: > - ldap_pool_putconnection(ldap_inst->pool, &ldap_conn); > str_destroy(&owner_dn_ptr); > str_destroy(&owner_dn); > str_destroy(&str_ptr); > -- > 1.7.11.4 > -- Adam Tkac, Red Hat, Inc. From pviktori at redhat.com Tue Oct 9 11:25:15 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 09 Oct 2012 13:25:15 +0200 Subject: [Freeipa-devel] Cannot create signed Firefox extension on a replica Message-ID: <5074099B.8030904@redhat.com> While working on https://fedorahosted.org/freeipa/ticket/3150, I came across this scenario: I have a 2.2 master I don't want to upgrade. I want to create a 3.0 replica from it. I found that when creating the replica file, the Signing-Cert (used to sign the browser config .jar and, newly, .xpi) is not included. It never leaves the original master. And the original master can't sign the extension because it's 2.2, so it only knows how to sign the old .jar (and only on install). Similarly, 2.2 replicas that get upgraded to 3.0 can't sign the new extension. And they don't even know which server has the "original" Signing-Cert, so even a trick like SSHing to it to steal the cert won't work. Old 2.2 installations where the original master was destroyed won't have the Signing-Cert at all any more. Am I right? I must admit my grasp of the code could be better. Can I generate a new signing cert in replica-install to sign the extension? Would that clash with the old one (and with ones from other replicas)? Can we distribute an unsigned extension? -- Petr? From mkosek at redhat.com Tue Oct 9 11:29:59 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 09 Oct 2012 13:29:59 +0200 Subject: [Freeipa-devel] [PATCH] 321 Move CRL publish directory to IPA owned directory In-Reply-To: <507329A6.1090503@redhat.com> References: <436570478.11020758.1349722511483.JavaMail.root@redhat.com> <507329A6.1090503@redhat.com> Message-ID: <50740AB7.3060209@redhat.com> On 10/08/2012 09:29 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> ----- Original Message ----- >>> From: "Rob Crittenden" >>> To: "Martin Kosek" >>> Cc: freeipa-devel at redhat.com >>> Sent: Monday, October 8, 2012 8:18:47 PM >>> Subject: Re: [Freeipa-devel] [PATCH] 321 Move CRL publish directory to IPA >>> owned directory >>> >>> Martin Kosek wrote: >>>> Currently, CRL files are being exported to /var/lib/pki-ca >>>> sub-directory, which is then served by httpd to clients. However, >>>> this approach has several disadvantages: >>>> * We depend on pki-ca directory structure and relevant >>>> permissions. >>>> If pki-ca changes directory structure or permissions on >>>> upgrade, >>>> IPA may break. This is also a root cause of the latest error, >>>> where >>>> the pki-ca directory does not have X permission for others and >>>> CRL >>>> publishing by httpd breaks. >>>> * Since the directory is not static and is generated during >>>> ipa-server-install, RPM upgrade of IPA packages report errors >>>> when >>>> defining SELinux policy for these directories. >>>> >>>> Move CRL publish directory to /var/lib/ipa/pki-ca/publish (common >>>> for >>>> both dogtag 9 and 10) which is created on RPM upgrade, i.e. SELinux >>>> policy >>>> configuration does not report any error. The new CRL publish >>>> directory >>>> is used for both new IPA installs and upgrades, where contents of >>>> the directory (CRLs) is first migrated to the new location and then >>>> the >>>> actual configuration change is made. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3144 >>>> >>>> >>>> ------- >>>> >>>> We may choose to postpone this patch to later version, it is quite >>>> disruptive. >>>> I can produce a hotfix in that case, which would only fix the >>>> permission of the >>>> pki-ca directory. >>>> >>>> Martin >>> >>> This looks good, just a couple of questions. >>> >>> Should the old files be removed? >> >> Yeah, this is something I wonder about too. One one side, users may be get >> confused if there are 2 publish directories with the same content (a least >> until a next CRL generation). But on the other side, I was cautious not to >> delete something important in a case when something goes wrong. But maybe I >> am just being over-cautious and we can delete it, or maybe move directory to >> "publish.deleted". In a worst case scenario, CRLs should be generated again, >> in about 4 hours... >> >>> >>> Should some error handling be added around the copy to ensure it is >>> successful? This would blow up if the disk was full, for example. >> >> I think this is covered, I have there a try..except clause for this case: >> >> + for f in crl_files: >> + try: >> + copy_crl_file(f) >> + except Exception, e: >> + root_logger.error('Cannot move CRL file to new directory: >> %s', e) >> >> Just the exception is caught on a higher level and error is reported to user. >> Not sure what to do in this case - report error to user, do not change the >> location and ask user to resolve the error? Or just report error and continue >> with CRL publish directory change as I do currently? >> >> Martin >> > > Ah, I was looking at too low a level. > > I think this is fine. I wonder if we should log/document somewhere in big > flashing letters that the stuff has been moved. It is rather clear in the logs > now, I suppose, if you look carefully. > > I guess it isn't really that big a deal now since we just have server certs. It > would take a whole ton of revocations to grow the CRLs that quickly, so maybe > my concerns are overblown. > > rob CRL size may quickly grown for someone who rapidly adds/removes client hosts or services as we revoke such certificates with 4 - superseded.. About the user info - maybe we should also allow output of ipa-upgradeconfig's stderr stream as we did with ipa-ldap-updater. This way, user would receive error message when CRL copy operation fails. Martin From pvoborni at redhat.com Tue Oct 9 11:43:29 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 09 Oct 2012 13:43:29 +0200 Subject: [Freeipa-devel] [PATCH] 221 Add mime type to httpd ipa.conf for xpi exetension Message-ID: <50740DE1.9050500@redhat.com> Some configuration doesn't give proper mime type to xpi files. This patch explicitly sets it. https://fedorahosted.org/freeipa/ticket/3094 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0221-Add-mime-type-to-httpd-ipa.conf-for-xpi-exetension.patch Type: text/x-patch Size: 1105 bytes Desc: not available URL: From abokovoy at redhat.com Tue Oct 9 11:51:54 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 9 Oct 2012 14:51:54 +0300 Subject: [Freeipa-devel] Cannot create signed Firefox extension on a replica In-Reply-To: <5074099B.8030904@redhat.com> References: <5074099B.8030904@redhat.com> Message-ID: <20121009115154.GF17454@redhat.com> On Tue, 09 Oct 2012, Petr Viktorin wrote: >While working on https://fedorahosted.org/freeipa/ticket/3150, I came >across this scenario: > >I have a 2.2 master I don't want to upgrade. I want to create a 3.0 >replica from it. > >I found that when creating the replica file, the Signing-Cert (used >to sign the browser config .jar and, newly, .xpi) is not included. It >never leaves the original master. And the original master can't sign >the extension because it's 2.2, so it only knows how to sign the old >.jar (and only on install). > >Similarly, 2.2 replicas that get upgraded to 3.0 can't sign the new >extension. And they don't even know which server has the "original" >Signing-Cert, so even a trick like SSHing to it to steal the cert >won't work. > >Old 2.2 installations where the original master was destroyed won't >have the Signing-Cert at all any more. > >Am I right? I must admit my grasp of the code could be better. > > >Can I generate a new signing cert in replica-install to sign the >extension? Would that clash with the old one (and with ones from >other replicas)? >Can we distribute an unsigned extension? We can distribute it unsigned. But your question sparkled another one: should we backport firefox extension work to 2.2? Since it is client-side that gets upgraded to Firefox 15, chances are high that soon existing 2.2 installs would not be manageable via browser on newer clients unless manually configured. -- / Alexander Bokovoy From abokovoy at redhat.com Tue Oct 9 11:52:22 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 9 Oct 2012 14:52:22 +0300 Subject: [Freeipa-devel] [PATCH] 221 Add mime type to httpd ipa.conf for xpi exetension In-Reply-To: <50740DE1.9050500@redhat.com> References: <50740DE1.9050500@redhat.com> Message-ID: <20121009115222.GG17454@redhat.com> On Tue, 09 Oct 2012, Petr Vobornik wrote: >Some configuration doesn't give proper mime type to xpi files. This >patch explicitly sets it. > >https://fedorahosted.org/freeipa/ticket/3094 >-- >Petr Vobornik >From f35fd8856fdb9e16361b977aba62266c71c9e76f Mon Sep 17 00:00:00 2001 >From: Petr Vobornik >Date: Tue, 9 Oct 2012 10:17:16 +0200 >Subject: [PATCH] Add mime type to httpd ipa.conf for xpi exetension > >Some configuration doesn't give proper mime type to xpi files. This patch explicitly sets it. > >https://fedorahosted.org/freeipa/ticket/3094 ACK. -- / Alexander Bokovoy From pvoborni at redhat.com Tue Oct 9 11:52:57 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 09 Oct 2012 13:52:57 +0200 Subject: [Freeipa-devel] Cannot create signed Firefox extension on a replica In-Reply-To: <5074099B.8030904@redhat.com> References: <5074099B.8030904@redhat.com> Message-ID: <50741019.1040008@redhat.com> On 10/09/2012 01:25 PM, Petr Viktorin wrote: > While working on https://fedorahosted.org/freeipa/ticket/3150, I came > across this scenario: > > I have a 2.2 master I don't want to upgrade. I want to create a 3.0 > replica from it. > > I found that when creating the replica file, the Signing-Cert (used to > sign the browser config .jar and, newly, .xpi) is not included. It never > leaves the original master. And the original master can't sign the > extension because it's 2.2, so it only knows how to sign the old .jar > (and only on install). > > Similarly, 2.2 replicas that get upgraded to 3.0 can't sign the new > extension. And they don't even know which server has the "original" > Signing-Cert, so even a trick like SSHing to it to steal the cert won't > work. > > Old 2.2 installations where the original master was destroyed won't have > the Signing-Cert at all any more. > > Am I right? I must admit my grasp of the code could be better. > > > Can I generate a new signing cert in replica-install to sign the > extension? Would that clash with the old one (and with ones from other > replicas)? > Can we distribute an unsigned extension? > > Just some additional info: * The extension doesn't have to be signed to be installable. It just shows that the source is not verified. * The signing cert has a weird label (hostname?) "Object Signing Cert" which is really confusing when used in Firefox dialog while installing the extension * The signing cert doesn't auto renew https://fedorahosted.org/freeipa/ticket/3032 -- Petr Vobornik From pspacek at redhat.com Tue Oct 9 13:25:58 2012 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 09 Oct 2012 15:25:58 +0200 Subject: [Freeipa-devel] [PATCH 0076] Fix crashes on BIND reload caused by improper error handling during new zone addition In-Reply-To: <20121009111501.GE2593@redhat.com> References: <506EF5FE.9090409@redhat.com> <20121009111501.GE2593@redhat.com> Message-ID: <507425E6.9040901@redhat.com> On 10/09/2012 01:15 PM, Adam Tkac wrote: > On Fri, Oct 05, 2012 at 05:00:14PM +0200, Petr Spacek wrote: >> Hello, >> >> Fix crashes on BIND reload caused by improper error handling >> during new zone addition. >> >> Crash can be triggered by invalid query/transfer/update ACLs >> or potentially by error in zr_get_zone_ptr(). >> >> I found this problem during PATCH 75 testing, so there is a new ticket: >> https://fedorahosted.org/bind-dyndb-ldap/ticket/93 > > Ack Pushed to master: 6a86b1fd08ca37c64435690efd49115c828871a9 Petr^2 Spacek > >> From d0e958cac75035b212f87f00fade080b025d0a23 Mon Sep 17 00:00:00 2001 >> From: Petr Spacek >> Date: Fri, 5 Oct 2012 14:41:57 +0200 >> Subject: [PATCH] Fix crashes on BIND reload caused by improper error handling >> during new zone addition. From pspacek at redhat.com Tue Oct 9 13:26:09 2012 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 09 Oct 2012 15:26:09 +0200 Subject: [Freeipa-devel] [PATCH 0075] Prevent misleading "partial match" error messages for disabled zones In-Reply-To: <20121009110920.GC2593@redhat.com> References: <506EC866.5070603@redhat.com> <20121009110920.GC2593@redhat.com> Message-ID: <507425F1.7010808@redhat.com> On 10/09/2012 01:09 PM, Adam Tkac wrote: > On Fri, Oct 05, 2012 at 01:45:42PM +0200, Petr Spacek wrote: >> Hello, >> >> Prevent misleading "partial match" error messages for disabled zones. >> >> Following message was printed if zone "e.test" was disabled and LDAP >> contained zones "test" and "e.test": >> update_zone (psearch) failed for >> 'idnsName=e.test,cn=dns,dc=e,dc=org'. Zones can be outdated, run >> `rndc reload`: partial match > > Ack Pushed to master: 8b45aeadbf75b732bd6c95151d762d8fe89d9ea8 Petr^2 Spacek > >> From e7f7a7d6e4fb3c9e47bac22d3291d09aa3d885ab Mon Sep 17 00:00:00 2001 >> From: Petr Spacek >> Date: Fri, 5 Oct 2012 13:37:18 +0200 >> Subject: [PATCH] Prevent misleading "partial match" error messages for >> disabled zones. From pspacek at redhat.com Tue Oct 9 13:26:15 2012 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 09 Oct 2012 15:26:15 +0200 Subject: [Freeipa-devel] [PATCH 0074] Fix zone removal in persistent search update_zone() In-Reply-To: <20121009110823.GB2593@redhat.com> References: <506EC141.7020508@redhat.com> <20121009110823.GB2593@redhat.com> Message-ID: <507425F7.6040203@redhat.com> On 10/09/2012 01:08 PM, Adam Tkac wrote: > On Fri, Oct 05, 2012 at 01:15:13PM +0200, Petr Spacek wrote: >> Hello, >> >> Fix zone removal in persistent search update_zone(). >> >> Without this patch any zone removed through ipa dnszone-del will >> remain active and will return SERVFAILs. > > Ack Pushed to master: 7edccd62fd9c03ba1431a2a4595072938a58d986 Petr^2 Spacek > >> From e09eebf3c370ff4106013cdeda10a80782e26611 Mon Sep 17 00:00:00 2001 >> From: Petr Spacek >> Date: Fri, 5 Oct 2012 13:02:37 +0200 >> Subject: [PATCH] Fix zone removal in persistent search update_zone() handler. From pspacek at redhat.com Tue Oct 9 13:26:24 2012 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 09 Oct 2012 15:26:24 +0200 Subject: [Freeipa-devel] [PATCH 0071] Fix potential crash caused by failing zone_register allocation. In-Reply-To: <20121009111225.GD2593@redhat.com> References: <506AEA44.20307@redhat.com> <20121009111225.GD2593@redhat.com> Message-ID: <50742600.9080301@redhat.com> On 10/09/2012 01:12 PM, Adam Tkac wrote: > On Tue, Oct 02, 2012 at 03:21:08PM +0200, Petr Spacek wrote: >> Hello, >> >> Fix potential crash caused by failing zone_register allocation. >> >> Problematic call flow: >> new_ldap_instance -> zr_create (returns failure) -> >> destroy_ldap_instance -> zr_get_rbt (*crash*) > > Ack Pushed to master: 01bfbeb77db85780312dadddcda7d9979ef13633 Petr^2 Spacek > >> From 9d96a9c4a4ac5b592ed5874132e0618b1b259de0 Mon Sep 17 00:00:00 2001 >> From: Petr Spacek >> Date: Tue, 2 Oct 2012 15:16:27 +0200 >> Subject: [PATCH] Fix potential crash caused by failing zone_register >> allocation. From mkosek at redhat.com Tue Oct 9 13:43:30 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 09 Oct 2012 15:43:30 +0200 Subject: [Freeipa-devel] [PATCH] 221 Add mime type to httpd ipa.conf for xpi exetension In-Reply-To: <20121009115222.GG17454@redhat.com> References: <50740DE1.9050500@redhat.com> <20121009115222.GG17454@redhat.com> Message-ID: <50742A02.8000005@redhat.com> On 10/09/2012 01:52 PM, Alexander Bokovoy wrote: > On Tue, 09 Oct 2012, Petr Vobornik wrote: >> Some configuration doesn't give proper mime type to xpi files. This patch >> explicitly sets it. >> >> https://fedorahosted.org/freeipa/ticket/3094 >> -- >> Petr Vobornik > >> From f35fd8856fdb9e16361b977aba62266c71c9e76f Mon Sep 17 00:00:00 2001 >> From: Petr Vobornik >> Date: Tue, 9 Oct 2012 10:17:16 +0200 >> Subject: [PATCH] Add mime type to httpd ipa.conf for xpi exetension >> >> Some configuration doesn't give proper mime type to xpi files. This patch >> explicitly sets it. >> >> https://fedorahosted.org/freeipa/ticket/3094 > ACK. > Pushed to master, ipa-3-0. Martin From rcritten at redhat.com Tue Oct 9 13:48:39 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 09 Oct 2012 09:48:39 -0400 Subject: [Freeipa-devel] [PATCH] 321 Move CRL publish directory to IPA owned directory In-Reply-To: <50740AB7.3060209@redhat.com> References: <436570478.11020758.1349722511483.JavaMail.root@redhat.com> <507329A6.1090503@redhat.com> <50740AB7.3060209@redhat.com> Message-ID: <50742B37.80401@redhat.com> Martin Kosek wrote: > On 10/08/2012 09:29 PM, Rob Crittenden wrote: >> Martin Kosek wrote: >>> ----- Original Message ----- >>>> From: "Rob Crittenden" >>>> To: "Martin Kosek" >>>> Cc: freeipa-devel at redhat.com >>>> Sent: Monday, October 8, 2012 8:18:47 PM >>>> Subject: Re: [Freeipa-devel] [PATCH] 321 Move CRL publish directory to IPA >>>> owned directory >>>> >>>> Martin Kosek wrote: >>>>> Currently, CRL files are being exported to /var/lib/pki-ca >>>>> sub-directory, which is then served by httpd to clients. However, >>>>> this approach has several disadvantages: >>>>> * We depend on pki-ca directory structure and relevant >>>>> permissions. >>>>> If pki-ca changes directory structure or permissions on >>>>> upgrade, >>>>> IPA may break. This is also a root cause of the latest error, >>>>> where >>>>> the pki-ca directory does not have X permission for others and >>>>> CRL >>>>> publishing by httpd breaks. >>>>> * Since the directory is not static and is generated during >>>>> ipa-server-install, RPM upgrade of IPA packages report errors >>>>> when >>>>> defining SELinux policy for these directories. >>>>> >>>>> Move CRL publish directory to /var/lib/ipa/pki-ca/publish (common >>>>> for >>>>> both dogtag 9 and 10) which is created on RPM upgrade, i.e. SELinux >>>>> policy >>>>> configuration does not report any error. The new CRL publish >>>>> directory >>>>> is used for both new IPA installs and upgrades, where contents of >>>>> the directory (CRLs) is first migrated to the new location and then >>>>> the >>>>> actual configuration change is made. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3144 >>>>> >>>>> >>>>> ------- >>>>> >>>>> We may choose to postpone this patch to later version, it is quite >>>>> disruptive. >>>>> I can produce a hotfix in that case, which would only fix the >>>>> permission of the >>>>> pki-ca directory. >>>>> >>>>> Martin >>>> >>>> This looks good, just a couple of questions. >>>> >>>> Should the old files be removed? >>> >>> Yeah, this is something I wonder about too. One one side, users may be get >>> confused if there are 2 publish directories with the same content (a least >>> until a next CRL generation). But on the other side, I was cautious not to >>> delete something important in a case when something goes wrong. But maybe I >>> am just being over-cautious and we can delete it, or maybe move directory to >>> "publish.deleted". In a worst case scenario, CRLs should be generated again, >>> in about 4 hours... >>> >>>> >>>> Should some error handling be added around the copy to ensure it is >>>> successful? This would blow up if the disk was full, for example. >>> >>> I think this is covered, I have there a try..except clause for this case: >>> >>> + for f in crl_files: >>> + try: >>> + copy_crl_file(f) >>> + except Exception, e: >>> + root_logger.error('Cannot move CRL file to new directory: >>> %s', e) >>> >>> Just the exception is caught on a higher level and error is reported to user. >>> Not sure what to do in this case - report error to user, do not change the >>> location and ask user to resolve the error? Or just report error and continue >>> with CRL publish directory change as I do currently? >>> >>> Martin >>> >> >> Ah, I was looking at too low a level. >> >> I think this is fine. I wonder if we should log/document somewhere in big >> flashing letters that the stuff has been moved. It is rather clear in the logs >> now, I suppose, if you look carefully. >> >> I guess it isn't really that big a deal now since we just have server certs. It >> would take a whole ton of revocations to grow the CRLs that quickly, so maybe >> my concerns are overblown. >> >> rob > > CRL size may quickly grown for someone who rapidly adds/removes client hosts or > services as we revoke such certificates with 4 - superseded.. About the user > info - maybe we should also allow output of ipa-upgradeconfig's stderr stream > as we did with ipa-ldap-updater. This way, user would receive error message > when CRL copy operation fails. > > Martin > I think the patch is fine as-is. Can you open a new ticket on a mechanism to alert the user to upgrade things to review? ACK rob From pspacek at redhat.com Tue Oct 9 13:49:47 2012 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 09 Oct 2012 15:49:47 +0200 Subject: [Freeipa-devel] [PATCH 0078] Use automatic connection management in LDAP modification code to prevent potential deadlock In-Reply-To: <20121009112157.GF2593@redhat.com> References: <5072E75E.1050305@redhat.com> <20121009112157.GF2593@redhat.com> Message-ID: <50742B7B.2070205@redhat.com> On 10/09/2012 01:21 PM, Adam Tkac wrote: > On Mon, Oct 08, 2012 at 04:46:54PM +0200, Petr Spacek wrote: >> Hello, >> >> Use automatic connection management in LDAP modification code to >> prevent potential deadlock. >> >> Without this patch the plugin will deadlock when modify_ldap_common() >> is called with PTR synchronization enabled and only single >> connection is available in the connection pool. > > Nack > > If I read the patch correctly, it leaves unused ldap_conn parameters in > ldap_modify_do() and modify_soa_record() functions. > > Those params are always NULL so they can be safely removed. Please also remove > the "autoconn" variable from ldap_modify_do() My intent was to keep the same connection management abilities as are in ldap_query(): You can avoid repetitive ldap_pool_get/putconnection() calls by passing connection via parameter. I can remove it if it isn't worth. (Actually *_modify_*() functions do not use this capability now.) Petr^2 Spacek > > Regards, Adam > >> From 5ad686a95510b1584c85d672ec845b27504f746c Mon Sep 17 00:00:00 2001 >> From: Petr Spacek >> Date: Mon, 8 Oct 2012 16:41:40 +0200 >> Subject: [PATCH] Use automatic connection management in LDAP modification >> code to prevent potential deadlock. From mkosek at redhat.com Tue Oct 9 14:11:58 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 09 Oct 2012 16:11:58 +0200 Subject: [Freeipa-devel] [PATCH] 321 Move CRL publish directory to IPA owned directory In-Reply-To: <50742B37.80401@redhat.com> References: <436570478.11020758.1349722511483.JavaMail.root@redhat.com> <507329A6.1090503@redhat.com> <50740AB7.3060209@redhat.com> <50742B37.80401@redhat.com> Message-ID: <507430AE.5080307@redhat.com> On 10/09/2012 03:48 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> On 10/08/2012 09:29 PM, Rob Crittenden wrote: >>> Martin Kosek wrote: >>>> ----- Original Message ----- >>>>> From: "Rob Crittenden" >>>>> To: "Martin Kosek" >>>>> Cc: freeipa-devel at redhat.com >>>>> Sent: Monday, October 8, 2012 8:18:47 PM >>>>> Subject: Re: [Freeipa-devel] [PATCH] 321 Move CRL publish directory to IPA >>>>> owned directory >>>>> >>>>> Martin Kosek wrote: >>>>>> Currently, CRL files are being exported to /var/lib/pki-ca >>>>>> sub-directory, which is then served by httpd to clients. However, >>>>>> this approach has several disadvantages: >>>>>> * We depend on pki-ca directory structure and relevant >>>>>> permissions. >>>>>> If pki-ca changes directory structure or permissions on >>>>>> upgrade, >>>>>> IPA may break. This is also a root cause of the latest error, >>>>>> where >>>>>> the pki-ca directory does not have X permission for others and >>>>>> CRL >>>>>> publishing by httpd breaks. >>>>>> * Since the directory is not static and is generated during >>>>>> ipa-server-install, RPM upgrade of IPA packages report errors >>>>>> when >>>>>> defining SELinux policy for these directories. >>>>>> >>>>>> Move CRL publish directory to /var/lib/ipa/pki-ca/publish (common >>>>>> for >>>>>> both dogtag 9 and 10) which is created on RPM upgrade, i.e. SELinux >>>>>> policy >>>>>> configuration does not report any error. The new CRL publish >>>>>> directory >>>>>> is used for both new IPA installs and upgrades, where contents of >>>>>> the directory (CRLs) is first migrated to the new location and then >>>>>> the >>>>>> actual configuration change is made. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3144 >>>>>> >>>>>> >>>>>> ------- >>>>>> >>>>>> We may choose to postpone this patch to later version, it is quite >>>>>> disruptive. >>>>>> I can produce a hotfix in that case, which would only fix the >>>>>> permission of the >>>>>> pki-ca directory. >>>>>> >>>>>> Martin >>>>> >>>>> This looks good, just a couple of questions. >>>>> >>>>> Should the old files be removed? >>>> >>>> Yeah, this is something I wonder about too. One one side, users may be get >>>> confused if there are 2 publish directories with the same content (a least >>>> until a next CRL generation). But on the other side, I was cautious not to >>>> delete something important in a case when something goes wrong. But maybe I >>>> am just being over-cautious and we can delete it, or maybe move directory to >>>> "publish.deleted". In a worst case scenario, CRLs should be generated again, >>>> in about 4 hours... >>>> >>>>> >>>>> Should some error handling be added around the copy to ensure it is >>>>> successful? This would blow up if the disk was full, for example. >>>> >>>> I think this is covered, I have there a try..except clause for this case: >>>> >>>> + for f in crl_files: >>>> + try: >>>> + copy_crl_file(f) >>>> + except Exception, e: >>>> + root_logger.error('Cannot move CRL file to new directory: >>>> %s', e) >>>> >>>> Just the exception is caught on a higher level and error is reported to user. >>>> Not sure what to do in this case - report error to user, do not change the >>>> location and ask user to resolve the error? Or just report error and continue >>>> with CRL publish directory change as I do currently? >>>> >>>> Martin >>>> >>> >>> Ah, I was looking at too low a level. >>> >>> I think this is fine. I wonder if we should log/document somewhere in big >>> flashing letters that the stuff has been moved. It is rather clear in the logs >>> now, I suppose, if you look carefully. >>> >>> I guess it isn't really that big a deal now since we just have server certs. It >>> would take a whole ton of revocations to grow the CRLs that quickly, so maybe >>> my concerns are overblown. >>> >>> rob >> >> CRL size may quickly grown for someone who rapidly adds/removes client hosts or >> services as we revoke such certificates with 4 - superseded.. About the user >> info - maybe we should also allow output of ipa-upgradeconfig's stderr stream >> as we did with ipa-ldap-updater. This way, user would receive error message >> when CRL copy operation fails. >> >> Martin >> > > I think the patch is fine as-is. Can you open a new ticket on a mechanism to > alert the user to upgrade things to review? https://fedorahosted.org/freeipa/ticket/3157 > > ACK > > rob > Rebased and pushed to master, ipa-3-0. Martin From mkosek at redhat.com Tue Oct 9 14:39:53 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 09 Oct 2012 16:39:53 +0200 Subject: [Freeipa-devel] [PATCH] 1055 update audit cert renewal time In-Reply-To: <505B9AAC.8080603@redhat.com> References: <5050EFA5.7050804@redhat.com> <505B918D.9070302@redhat.com> <505B9AAC.8080603@redhat.com> Message-ID: <50743739.2000005@redhat.com> On 09/21/2012 12:37 AM, yi zhang wrote: > On 09/20/2012 02:58 PM, Rob Crittenden wrote: >> Updated patch. The value of >> policyset.caLogSigningSet.2.constraint.params.range needs to be bumped to 720 >> as well. > I keep doing my test and let everyone know the test result. > > Yi > Hello Yi, any updates with your certificate tests with regards to this patch? Thanks, Martin From rcritten at redhat.com Tue Oct 9 14:43:46 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 09 Oct 2012 10:43:46 -0400 Subject: [Freeipa-devel] [PATCH] 1059 single CRL generator In-Reply-To: <506EA171.20401@redhat.com> References: <506DB6A8.10504@redhat.com> <506EA171.20401@redhat.com> Message-ID: <50743822.1090306@redhat.com> Martin Kosek wrote: > On 10/04/2012 06:17 PM, Rob Crittenden wrote: >> This changes the way IPA generates CRLs for new installs only. >> >> The first master installed is configured as the CRL generator. An entry is >> added to cn=masters that designates it. >> >> When a replica is installed it queries this entry so it knows where to forward >> CRL requests. CRL files are not available on cloned CAs (so /ipa/crl will >> return not found). It is possible to get a CRL directly from the clone CA via >> http://:9180/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL >> >> rob > > I tested new IPA server + replica with your patch and the CRL was now generated > only on the CRL master. I also tried OCSP (though this may not be relevant) and > it worked for me too. > > 1) I do not understand the following block in set_crl_master(self, suffix): > > + try: > + self.admin_conn.addEntry(entry) > + except ldap.ALREADY_EXISTS, e: > + root_logger.debug("failed to set CA as CRL generator") > + raise e > > - when we hit ldap.ALREADY_EXISTS, we are actually OK because cn=CRL is set, right? > - AFAIK, addEntry should return our errors, i.e. errors.DuplicateEntry > - s/raise e/raise/ > > I think you may have wanted to rather catch for more general LDAP error and > then report a real error and not just a debug note. > > 2) In get_crl_master: > > + except Exception, e: > + root_logger.debug("Could not connect to the Directory Server on > %s: %s" % (master_host, str(e))) > + raise e > > s/raise e/raise/ > > + except errors.NotFound, e: > + root_logger.debug("failed to find CA CRL generator") > + self.crl_master = None > > - e is actually not used, "except errors.NotFound" would be enough > > 3) Majorish issue I hit with the actual CRL publishing on our server (F17). I > always get 403 Forbidden error when trying to download CRL from the CRL master: > > # wget --ca-certificate /etc/ipa/ca.crt https://`hostname`/ipa/crl/MasterCRL.bin > --2012-10-05 03:32:58-- > https://vm-120.idm.lab.bos.redhat.com/ipa/crl/MasterCRL.bin > Resolving vm-120.idm.lab.bos.redhat.com... 10.16.78.120 > Connecting to vm-120.idm.lab.bos.redhat.com|10.16.78.120|:443... connected. > HTTP request sent, awaiting response... 403 Forbidden > 2012-10-05 03:32:58 ERROR 403: Forbidden. > > I tracked the problem down to too strict permission on /var/lib/pki-ca > directory which is being published by httpd which does not have access to it: > > # ll /var/lib/pki-ca > > drwxrwx---. 11 pkiuser pkiuser 4096 Oct 5 03:00 pki-ca > > When I fixed the permission: > # chmod o+x /var/lib/pki-ca/ > > I was able to get pass the Forbidden error and actually retrieved the CRL. > Adding Ade on CC list to follow on this permission issue. > > > I was thinking about usability of this new approach, we may want to make user > life easier in a perspective of CRL master managing. I have following > enhancements in mind: > > - mark CRL master in ipa-replica-manage list, or ipa-csreplica-manage list: > > # ipa-csreplica-manage list > Directory Manager password: > > vm-065.idm.lab.bos.redhat.com: master [CRL] > vm-120.idm.lab.bos.redhat.com: master > > - when removing master with CRL by "ipa-replica-manage del" we should warn user > and inform him what he should do next to amend the situation. I am thinking > about 2 new commands for ipa-csreplica-manage: > > * ipa-csreplica-manage crl-promote > - promote current master as the new CRL master, enable CRL generation in > CS.cfg, mark master as the new CRL master in cn=masters > * ipa-csreplica-manage crl-update > - update CS.cfg of current CA replica and point master.ca.agent.* to current > CRL master > > I can work on those enhancements if we agree on them. > > Martin > Andrew provided some feedback out-of-band and my solution was overly complex. Here is a much simpler patch which does away with all the hand-waving around knowing who the CRL generator is. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1059-2-crl.patch Type: text/x-diff Size: 2066 bytes Desc: not available URL: From alee at redhat.com Tue Oct 9 15:04:46 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 09 Oct 2012 11:04:46 -0400 Subject: [Freeipa-devel] [Fwd: [Pki-announce] Announcing Dogtag 10.0.0 beta 1 release] Message-ID: <1349795087.19017.103.camel@aleeredhat.laptop> -------------- next part -------------- An embedded message was scrubbed... From: Ade Lee Subject: [Pki-announce] Announcing Dogtag 10.0.0 beta 1 release Date: Tue, 09 Oct 2012 11:03:40 -0400 Size: 5722 URL: From pviktori at redhat.com Tue Oct 9 15:16:30 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 09 Oct 2012 17:16:30 +0200 Subject: [Freeipa-devel] [PATCHES] 0086-0088 Generate Firefox extension on upgrades Message-ID: <50743FCE.5050307@redhat.com> https://fedorahosted.org/freeipa/ticket/3150 Patch 0086: I found an old unused function while working on this, the patch removes it. Patch 0087: Replica files generated on older masters don't contain the Firefox extension files. Skip installing them in this case. Patch 0088: Servers upgraded from IPA 2.2 need the Firefox extension installed. This is done in ipa-upgradeconfig if they're missing. I made the setup_firefox_extension method independent on the httpinstance state (which is mostly set in create_instance). Similarly, the files are installed ipa-replica-install if they're missing (i.e. skipped by the previous patch). If the Signing-Cert is not on this master, create an unsigned extension using the "zip" command. I needed to add Popen's `cwd` argument to ipautil.run() to get the right filenames out of zip. The patches add "copy_template_file" and "copy_file_if_exists" utilities I've written for some of my WIP patches, expect me to use them more when I get time to work on the installer code. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0086-ipa-upgradeconfig-Remove-the-upgrade_httpd_selinux-f.patch Type: text/x-patch Size: 1181 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0087-replica-install-Don-t-copy-Firefox-config-extension-.patch Type: text/x-patch Size: 2204 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0088-Create-Firefox-extension-on-upgrade-and-replica-inst.patch Type: text/x-patch Size: 8358 bytes Desc: not available URL: From mkosek at redhat.com Tue Oct 9 15:19:49 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 09 Oct 2012 17:19:49 +0200 Subject: [Freeipa-devel] [PATCH] 1055 update audit cert renewal time In-Reply-To: <505B918D.9070302@redhat.com> References: <5050EFA5.7050804@redhat.com> <505B918D.9070302@redhat.com> Message-ID: <50744095.1030607@redhat.com> On 09/20/2012 11:58 PM, Rob Crittenden wrote: > Rob Crittenden wrote: >> The CA audit certificate is initially valid for two years but its >> profile has it renewing at six months. This bumps the value up to two >> years to match the other certificates. >> >> This relies on Petr's and Ade's dogtag 10 patches. > > Updated patch. The value of policyset.caLogSigningSet.2.constraint.params.range > needs to be bumped to 720 as well. > > rob > 1) I do not see the updated patch with the described change 2) Patch needs a rebase 3) In upgrade_ipa_profile function, please rather adopt the concept of restarting the CA just once ("ca_restart" variable), at the end of the ipa-upgraceconfig. With your change, CA would be restarted at least twice - once for audit cert renewal update and then for CRL location change. Otherwise it works OK - profile is updated. Martin From pviktori at redhat.com Tue Oct 9 15:26:30 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 09 Oct 2012 17:26:30 +0200 Subject: [Freeipa-devel] [PATCHES] 0086-0088 Generate Firefox extension on upgrades In-Reply-To: <50743FCE.5050307@redhat.com> References: <50743FCE.5050307@redhat.com> Message-ID: <50744226.90007@redhat.com> On 10/09/2012 05:16 PM, Petr Viktorin wrote: > https://fedorahosted.org/freeipa/ticket/3150 > > > Patch 0086: > I found an old unused function while working on this, the patch removes it. > > Patch 0087: > Replica files generated on older masters don't contain the Firefox > extension files. Skip installing them in this case. > > Patch 0088: > Servers upgraded from IPA 2.2 need the Firefox extension installed. This > is done in ipa-upgradeconfig if they're missing. > I made the setup_firefox_extension method independent on the > httpinstance state (which is mostly set in create_instance). > Similarly, the files are installed ipa-replica-install if they're > missing (i.e. skipped by the previous patch). > If the Signing-Cert is not on this master, create an unsigned extension > using the "zip" command. I needed to add Popen's `cwd` argument to > ipautil.run() to get the right filenames out of zip. > > The patches add "copy_template_file" and "copy_file_if_exists" utilities > I've written for some of my WIP patches, expect me to use them more when > I get time to work on the installer code. > In my previous mail I've attached an old version of patch 88. Please use this one. Sorry! -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0088-01-Create-Firefox-extnsion-on-upgrade-and-replica-inst.patch Type: text/x-patch Size: 9095 bytes Desc: not available URL: From rcritten at redhat.com Tue Oct 9 15:29:20 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 09 Oct 2012 11:29:20 -0400 Subject: [Freeipa-devel] [PATCH] 1055 update audit cert renewal time In-Reply-To: <50744095.1030607@redhat.com> References: <5050EFA5.7050804@redhat.com> <505B918D.9070302@redhat.com> <50744095.1030607@redhat.com> Message-ID: <507442D0.2090408@redhat.com> Martin Kosek wrote: > On 09/20/2012 11:58 PM, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> The CA audit certificate is initially valid for two years but its >>> profile has it renewing at six months. This bumps the value up to two >>> years to match the other certificates. >>> >>> This relies on Petr's and Ade's dogtag 10 patches. >> >> Updated patch. The value of policyset.caLogSigningSet.2.constraint.params.range >> needs to be bumped to 720 as well. >> >> rob >> > > 1) I do not see the updated patch with the described change > > 2) Patch needs a rebase > > 3) In upgrade_ipa_profile function, please rather adopt the concept of > restarting the CA just once ("ca_restart" variable), at the end of the > ipa-upgraceconfig. With your change, CA would be restarted at least twice - > once for audit cert renewal update and then for CRL location change. > > Otherwise it works OK - profile is updated. > > Martin > done rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1055-3-auditrenewal.patch Type: text/x-diff Size: 5913 bytes Desc: not available URL: From mkosek at redhat.com Tue Oct 9 15:40:14 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 09 Oct 2012 17:40:14 +0200 Subject: [Freeipa-devel] [PATCH] 1056 sudorule cn uniqueness In-Reply-To: <505349B3.10305@redhat.com> References: <50523093.7040704@redhat.com> <505349B3.10305@redhat.com> Message-ID: <5074455E.5090704@redhat.com> On 09/14/2012 05:13 PM, Rob Crittenden wrote: > Rob Crittenden wrote: >> A sudorule dn uses ipaUniqueId as the cn so we have to do a search to >> ensure uniqueness. This leaves us vulnerable to a race. Configure the >> uniqueness plugin to ensure no dups. >> >> rob > > Add missing attribute to the fresh install ldif. I had already fixed this in > the update, missed it on fresh install. > > rob > Works fine. Reproduced the issue with simple ldapadd. ACK if you change the whitespace error below: # git apply /home/mkosek/freeipa-rcrit-1056-2-sudorule-uniqueness.patch /home/mkosek/freeipa-rcrit-1056-2-sudorule-uniqueness.patch:70: new blank line at EOF. + warning: 1 line adds whitespace errors. Martin From rcritten at redhat.com Tue Oct 9 15:49:54 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 09 Oct 2012 11:49:54 -0400 Subject: [Freeipa-devel] [PATCH] 1056 sudorule cn uniqueness In-Reply-To: <5074455E.5090704@redhat.com> References: <50523093.7040704@redhat.com> <505349B3.10305@redhat.com> <5074455E.5090704@redhat.com> Message-ID: <507447A2.7060001@redhat.com> Martin Kosek wrote: > On 09/14/2012 05:13 PM, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> A sudorule dn uses ipaUniqueId as the cn so we have to do a search to >>> ensure uniqueness. This leaves us vulnerable to a race. Configure the >>> uniqueness plugin to ensure no dups. >>> >>> rob >> >> Add missing attribute to the fresh install ldif. I had already fixed this in >> the update, missed it on fresh install. >> >> rob >> > > Works fine. Reproduced the issue with simple ldapadd. > > ACK if you change the whitespace error below: > > # git apply /home/mkosek/freeipa-rcrit-1056-2-sudorule-uniqueness.patch > /home/mkosek/freeipa-rcrit-1056-2-sudorule-uniqueness.patch:70: new blank line > at EOF. > + > warning: 1 line adds whitespace errors. > > Martin > Fixed and pushed to master and ipa-3-0 rob From mkosek at redhat.com Tue Oct 9 15:52:26 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 09 Oct 2012 17:52:26 +0200 Subject: [Freeipa-devel] [PATCH] 1055 update audit cert renewal time In-Reply-To: <507442D0.2090408@redhat.com> References: <5050EFA5.7050804@redhat.com> <505B918D.9070302@redhat.com> <50744095.1030607@redhat.com> <507442D0.2090408@redhat.com> Message-ID: <5074483A.9000902@redhat.com> On 10/09/2012 05:29 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> On 09/20/2012 11:58 PM, Rob Crittenden wrote: >>> Rob Crittenden wrote: >>>> The CA audit certificate is initially valid for two years but its >>>> profile has it renewing at six months. This bumps the value up to two >>>> years to match the other certificates. >>>> >>>> This relies on Petr's and Ade's dogtag 10 patches. >>> >>> Updated patch. The value of policyset.caLogSigningSet.2.constraint.params.range >>> needs to be bumped to 720 as well. >>> >>> rob >>> >> >> 1) I do not see the updated patch with the described change >> >> 2) Patch needs a rebase >> >> 3) In upgrade_ipa_profile function, please rather adopt the concept of >> restarting the CA just once ("ca_restart" variable), at the end of the >> ipa-upgraceconfig. With your change, CA would be restarted at least twice - >> once for audit cert renewal update and then for CRL location change. >> >> Otherwise it works OK - profile is updated. >> >> Martin >> > > done > > rob ACK. Pushed to master, ipa-3-0. Martin From mkosek at redhat.com Tue Oct 9 16:00:37 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 09 Oct 2012 18:00:37 +0200 Subject: [Freeipa-devel] [PATCH] 1059 single CRL generator In-Reply-To: <50743822.1090306@redhat.com> References: <506DB6A8.10504@redhat.com> <506EA171.20401@redhat.com> <50743822.1090306@redhat.com> Message-ID: <50744A25.8010504@redhat.com> On 10/09/2012 04:43 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> On 10/04/2012 06:17 PM, Rob Crittenden wrote: >>> This changes the way IPA generates CRLs for new installs only. >>> >>> The first master installed is configured as the CRL generator. An entry is >>> added to cn=masters that designates it. >>> >>> When a replica is installed it queries this entry so it knows where to forward >>> CRL requests. CRL files are not available on cloned CAs (so /ipa/crl will >>> return not found). It is possible to get a CRL directly from the clone CA via >>> http://:9180/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL >>> >>> rob >> >> I tested new IPA server + replica with your patch and the CRL was now generated >> only on the CRL master. I also tried OCSP (though this may not be relevant) and >> it worked for me too. >> >> 1) I do not understand the following block in set_crl_master(self, suffix): >> >> + try: >> + self.admin_conn.addEntry(entry) >> + except ldap.ALREADY_EXISTS, e: >> + root_logger.debug("failed to set CA as CRL generator") >> + raise e >> >> - when we hit ldap.ALREADY_EXISTS, we are actually OK because cn=CRL is set, >> right? >> - AFAIK, addEntry should return our errors, i.e. errors.DuplicateEntry >> - s/raise e/raise/ >> >> I think you may have wanted to rather catch for more general LDAP error and >> then report a real error and not just a debug note. >> >> 2) In get_crl_master: >> >> + except Exception, e: >> + root_logger.debug("Could not connect to the Directory Server on >> %s: %s" % (master_host, str(e))) >> + raise e >> >> s/raise e/raise/ >> >> + except errors.NotFound, e: >> + root_logger.debug("failed to find CA CRL generator") >> + self.crl_master = None >> >> - e is actually not used, "except errors.NotFound" would be enough >> >> 3) Majorish issue I hit with the actual CRL publishing on our server (F17). I >> always get 403 Forbidden error when trying to download CRL from the CRL master: >> >> # wget --ca-certificate /etc/ipa/ca.crt https://`hostname`/ipa/crl/MasterCRL.bin >> --2012-10-05 03:32:58-- >> https://vm-120.idm.lab.bos.redhat.com/ipa/crl/MasterCRL.bin >> Resolving vm-120.idm.lab.bos.redhat.com... 10.16.78.120 >> Connecting to vm-120.idm.lab.bos.redhat.com|10.16.78.120|:443... connected. >> HTTP request sent, awaiting response... 403 Forbidden >> 2012-10-05 03:32:58 ERROR 403: Forbidden. >> >> I tracked the problem down to too strict permission on /var/lib/pki-ca >> directory which is being published by httpd which does not have access to it: >> >> # ll /var/lib/pki-ca >> >> drwxrwx---. 11 pkiuser pkiuser 4096 Oct 5 03:00 pki-ca >> >> When I fixed the permission: >> # chmod o+x /var/lib/pki-ca/ >> >> I was able to get pass the Forbidden error and actually retrieved the CRL. >> Adding Ade on CC list to follow on this permission issue. >> >> >> I was thinking about usability of this new approach, we may want to make user >> life easier in a perspective of CRL master managing. I have following >> enhancements in mind: >> >> - mark CRL master in ipa-replica-manage list, or ipa-csreplica-manage list: >> >> # ipa-csreplica-manage list >> Directory Manager password: >> >> vm-065.idm.lab.bos.redhat.com: master [CRL] >> vm-120.idm.lab.bos.redhat.com: master >> >> - when removing master with CRL by "ipa-replica-manage del" we should warn user >> and inform him what he should do next to amend the situation. I am thinking >> about 2 new commands for ipa-csreplica-manage: >> >> * ipa-csreplica-manage crl-promote >> - promote current master as the new CRL master, enable CRL generation in >> CS.cfg, mark master as the new CRL master in cn=masters >> * ipa-csreplica-manage crl-update >> - update CS.cfg of current CA replica and point master.ca.agent.* to current >> CRL master >> >> I can work on those enhancements if we agree on them. >> >> Martin >> > > Andrew provided some feedback out-of-band and my solution was overly complex. > Here is a much simpler patch which does away with all the hand-waving around > knowing who the CRL generator is. > > rob This looks OK code-wise, I will wait for dogtag guys to confirm that this is the right approach. Btw. I think we may want to file a RFE to implement some command to promote a replica to CRL master (like "ipa-csreplica-manage crl-promote" proposed earlier). Users may want to promote a replica when the master crashes or is to be replaced. Some way to migrate CRL list (if not replicated already) to the promoted replica would also be needed. Martin From pvoborni at redhat.com Tue Oct 9 16:01:29 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 09 Oct 2012 18:01:29 +0200 Subject: [Freeipa-devel] [PATCHES] 0086-0088 Generate Firefox extension on upgrades In-Reply-To: <50744226.90007@redhat.com> References: <50743FCE.5050307@redhat.com> <50744226.90007@redhat.com> Message-ID: <50744A59.2050308@redhat.com> On 10/09/2012 05:26 PM, Petr Viktorin wrote: > On 10/09/2012 05:16 PM, Petr Viktorin wrote: >> https://fedorahosted.org/freeipa/ticket/3150 >> >> >> Patch 0086: >> I found an old unused function while working on this, the patch >> removes it. >> >> Patch 0087: >> Replica files generated on older masters don't contain the Firefox >> extension files. Skip installing them in this case. >> >> Patch 0088: >> Servers upgraded from IPA 2.2 need the Firefox extension installed. This >> is done in ipa-upgradeconfig if they're missing. >> I made the setup_firefox_extension method independent on the >> httpinstance state (which is mostly set in create_instance). >> Similarly, the files are installed ipa-replica-install if they're >> missing (i.e. skipped by the previous patch). >> If the Signing-Cert is not on this master, create an unsigned extension >> using the "zip" command. I needed to add Popen's `cwd` argument to >> ipautil.run() to get the right filenames out of zip. >> >> The patches add "copy_template_file" and "copy_file_if_exists" utilities >> I've written for some of my WIP patches, expect me to use them more when >> I get time to work on the installer code. >> > > In my previous mail I've attached an old version of patch 88. Please use > this one. Sorry! > > nack 1) patch 83-01 doesn't apply. 2) When pwd is supplied to setup_firefox_extension `db = certs.CertDB(realm, subject_base=subject_base)` is skipped and therefore `db.has_nickname` will fail. -- Petr Vobornik From rcritten at redhat.com Tue Oct 9 18:54:13 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 09 Oct 2012 14:54:13 -0400 Subject: [Freeipa-devel] [PATCH] 1059 single CRL generator In-Reply-To: <50744A25.8010504@redhat.com> References: <506DB6A8.10504@redhat.com> <506EA171.20401@redhat.com> <50743822.1090306@redhat.com> <50744A25.8010504@redhat.com> Message-ID: <507472D5.4080406@redhat.com> Martin Kosek wrote: > On 10/09/2012 04:43 PM, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On 10/04/2012 06:17 PM, Rob Crittenden wrote: >>>> This changes the way IPA generates CRLs for new installs only. >>>> >>>> The first master installed is configured as the CRL generator. An entry is >>>> added to cn=masters that designates it. >>>> >>>> When a replica is installed it queries this entry so it knows where to forward >>>> CRL requests. CRL files are not available on cloned CAs (so /ipa/crl will >>>> return not found). It is possible to get a CRL directly from the clone CA via >>>> http://:9180/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL >>>> >>>> rob >>> >>> I tested new IPA server + replica with your patch and the CRL was now generated >>> only on the CRL master. I also tried OCSP (though this may not be relevant) and >>> it worked for me too. >>> >>> 1) I do not understand the following block in set_crl_master(self, suffix): >>> >>> + try: >>> + self.admin_conn.addEntry(entry) >>> + except ldap.ALREADY_EXISTS, e: >>> + root_logger.debug("failed to set CA as CRL generator") >>> + raise e >>> >>> - when we hit ldap.ALREADY_EXISTS, we are actually OK because cn=CRL is set, >>> right? >>> - AFAIK, addEntry should return our errors, i.e. errors.DuplicateEntry >>> - s/raise e/raise/ >>> >>> I think you may have wanted to rather catch for more general LDAP error and >>> then report a real error and not just a debug note. >>> >>> 2) In get_crl_master: >>> >>> + except Exception, e: >>> + root_logger.debug("Could not connect to the Directory Server on >>> %s: %s" % (master_host, str(e))) >>> + raise e >>> >>> s/raise e/raise/ >>> >>> + except errors.NotFound, e: >>> + root_logger.debug("failed to find CA CRL generator") >>> + self.crl_master = None >>> >>> - e is actually not used, "except errors.NotFound" would be enough >>> >>> 3) Majorish issue I hit with the actual CRL publishing on our server (F17). I >>> always get 403 Forbidden error when trying to download CRL from the CRL master: >>> >>> # wget --ca-certificate /etc/ipa/ca.crt https://`hostname`/ipa/crl/MasterCRL.bin >>> --2012-10-05 03:32:58-- >>> https://vm-120.idm.lab.bos.redhat.com/ipa/crl/MasterCRL.bin >>> Resolving vm-120.idm.lab.bos.redhat.com... 10.16.78.120 >>> Connecting to vm-120.idm.lab.bos.redhat.com|10.16.78.120|:443... connected. >>> HTTP request sent, awaiting response... 403 Forbidden >>> 2012-10-05 03:32:58 ERROR 403: Forbidden. >>> >>> I tracked the problem down to too strict permission on /var/lib/pki-ca >>> directory which is being published by httpd which does not have access to it: >>> >>> # ll /var/lib/pki-ca >>> >>> drwxrwx---. 11 pkiuser pkiuser 4096 Oct 5 03:00 pki-ca >>> >>> When I fixed the permission: >>> # chmod o+x /var/lib/pki-ca/ >>> >>> I was able to get pass the Forbidden error and actually retrieved the CRL. >>> Adding Ade on CC list to follow on this permission issue. >>> >>> >>> I was thinking about usability of this new approach, we may want to make user >>> life easier in a perspective of CRL master managing. I have following >>> enhancements in mind: >>> >>> - mark CRL master in ipa-replica-manage list, or ipa-csreplica-manage list: >>> >>> # ipa-csreplica-manage list >>> Directory Manager password: >>> >>> vm-065.idm.lab.bos.redhat.com: master [CRL] >>> vm-120.idm.lab.bos.redhat.com: master >>> >>> - when removing master with CRL by "ipa-replica-manage del" we should warn user >>> and inform him what he should do next to amend the situation. I am thinking >>> about 2 new commands for ipa-csreplica-manage: >>> >>> * ipa-csreplica-manage crl-promote >>> - promote current master as the new CRL master, enable CRL generation in >>> CS.cfg, mark master as the new CRL master in cn=masters >>> * ipa-csreplica-manage crl-update >>> - update CS.cfg of current CA replica and point master.ca.agent.* to current >>> CRL master >>> >>> I can work on those enhancements if we agree on them. >>> >>> Martin >>> >> >> Andrew provided some feedback out-of-band and my solution was overly complex. >> Here is a much simpler patch which does away with all the hand-waving around >> knowing who the CRL generator is. >> >> rob > > This looks OK code-wise, I will wait for dogtag guys to confirm that this is > the right approach. > > Btw. I think we may want to file a RFE to implement some command to promote a > replica to CRL master (like "ipa-csreplica-manage crl-promote" proposed > earlier). Users may want to promote a replica when the master crashes or is to > be replaced. Some way to migrate CRL list (if not replicated already) to the > promoted replica would also be needed. > > Martin > Andrew suggested I specify that we do not monitor cloned revocations on the server not generating CRLs, so I added that. The last question is what we do about redirecting users on the non-generating masters. We can do it easily with a line like this in Apache: RewriteRule ^/ipa/crl/MasterCRL.bin https://$FQDN:9444/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL [L,R=301,NC] The tricky part is writing this properly. The CA can be added post-install so I don't think simply adding this to ipa-rewrite.conf will work well. Is adding another template configuration file for Apache overkill? rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1059-3-crl.patch Type: text/x-diff Size: 2188 bytes Desc: not available URL: From rcritten at redhat.com Tue Oct 9 19:31:19 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 09 Oct 2012 15:31:19 -0400 Subject: [Freeipa-devel] [PATCH] 1051 Fix CS replica management In-Reply-To: <5073D8CC.1040505@redhat.com> References: <5040F7DA.5020606@redhat.com> <505AF524.5050405@redhat.com> <505B5490.80303@redhat.com> <5072ED4C.4070604@redhat.com> <5073D8CC.1040505@redhat.com> Message-ID: <50747B87.6010309@redhat.com> Martin Kosek wrote: > On 10/08/2012 05:12 PM, Jan Cholasta wrote: >> Hi, >> >> On 20.9.2012 19:38, Rob Crittenden wrote: >>> Jan Cholasta wrote: >>>> Hi, >>>> >>>> Dne 31.8.2012 19:43, Rob Crittenden napsal(a): >>>>> The naming in CS replication agreements is different from IPA >>>>> agreements, we have to live with what the create. The master side should >>>>> be on the local side, replica1, not the remote. This required reversing >>>>> a few master variables. >>>>> >>>>> Pass in the force flag to del_link. >>>>> >>>>> Do a better job of finding the agreements on each side. >>>>> >>>>> This should be ipa-csreplica-manage more in line with >>>>> ipa-replica-manage. >>>>> >>>>> rob >>>>> >>>> >>>> Rob, can you please rebase the patch on top of current master? There >>>> were some dogtag 10 related changes to ipa-csreplica-manage since you >>>> posted the patch. >>>> >>>> Honza >>>> >>> >>> I re-tested after the merge and found some problems with my initial >>> approach. The problem stems from the naming convention that dogtag uses >>> when creating the initial agreements. It is hard to predict how things >>> were set up later so rather than trying to reconstruct the DN we search >>> for it and pass it when deleting agreements. >>> >>> rob >> >> So far I have found this: >> >> * Deleting a "bridge" link that connects two "islands" of replicas works, but >> it should not (I was told that this is expected, as no complex graph algorithms >> are engaged to detect this kind of errors). > > Exactly, I hit this error when I was a similar Rob's patch for > ipa-replica-manage (ticket 2797). I used topology "A - B - C - D - E" and I was > able to delete C. We may want to log an enhancement ticket for this. > > Martin > Right, and ipa-csreplica-manage doesn't even have the basic last_link checking code that ipa-replica-manage has, nor the ruv code. We decided to push that to a future release. This patch should fix up the basics. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1051-3-csmanage.patch Type: text/x-diff Size: 9477 bytes Desc: not available URL: From rcritten at redhat.com Tue Oct 9 22:46:58 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 09 Oct 2012 18:46:58 -0400 Subject: [Freeipa-devel] [PATCH] 1059 single CRL generator In-Reply-To: <507472D5.4080406@redhat.com> References: <506DB6A8.10504@redhat.com> <506EA171.20401@redhat.com> <50743822.1090306@redhat.com> <50744A25.8010504@redhat.com> <507472D5.4080406@redhat.com> Message-ID: <5074A962.7010300@redhat.com> Rob Crittenden wrote: > Martin Kosek wrote: >> On 10/09/2012 04:43 PM, Rob Crittenden wrote: >>> Martin Kosek wrote: >>>> On 10/04/2012 06:17 PM, Rob Crittenden wrote: >>>>> This changes the way IPA generates CRLs for new installs only. >>>>> >>>>> The first master installed is configured as the CRL generator. An >>>>> entry is >>>>> added to cn=masters that designates it. >>>>> >>>>> When a replica is installed it queries this entry so it knows where >>>>> to forward >>>>> CRL requests. CRL files are not available on cloned CAs (so >>>>> /ipa/crl will >>>>> return not found). It is possible to get a CRL directly from the >>>>> clone CA via >>>>> http://:9180/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL >>>>> >>>>> >>>>> rob >>>> >>>> I tested new IPA server + replica with your patch and the CRL was >>>> now generated >>>> only on the CRL master. I also tried OCSP (though this may not be >>>> relevant) and >>>> it worked for me too. >>>> >>>> 1) I do not understand the following block in set_crl_master(self, >>>> suffix): >>>> >>>> + try: >>>> + self.admin_conn.addEntry(entry) >>>> + except ldap.ALREADY_EXISTS, e: >>>> + root_logger.debug("failed to set CA as CRL generator") >>>> + raise e >>>> >>>> - when we hit ldap.ALREADY_EXISTS, we are actually OK because cn=CRL >>>> is set, >>>> right? >>>> - AFAIK, addEntry should return our errors, i.e. errors.DuplicateEntry >>>> - s/raise e/raise/ >>>> >>>> I think you may have wanted to rather catch for more general LDAP >>>> error and >>>> then report a real error and not just a debug note. >>>> >>>> 2) In get_crl_master: >>>> >>>> + except Exception, e: >>>> + root_logger.debug("Could not connect to the Directory >>>> Server on >>>> %s: %s" % (master_host, str(e))) >>>> + raise e >>>> >>>> s/raise e/raise/ >>>> >>>> + except errors.NotFound, e: >>>> + root_logger.debug("failed to find CA CRL generator") >>>> + self.crl_master = None >>>> >>>> - e is actually not used, "except errors.NotFound" would be enough >>>> >>>> 3) Majorish issue I hit with the actual CRL publishing on our server >>>> (F17). I >>>> always get 403 Forbidden error when trying to download CRL from the >>>> CRL master: >>>> >>>> # wget --ca-certificate /etc/ipa/ca.crt >>>> https://`hostname`/ipa/crl/MasterCRL.bin >>>> --2012-10-05 03:32:58-- >>>> https://vm-120.idm.lab.bos.redhat.com/ipa/crl/MasterCRL.bin >>>> Resolving vm-120.idm.lab.bos.redhat.com... 10.16.78.120 >>>> Connecting to vm-120.idm.lab.bos.redhat.com|10.16.78.120|:443... >>>> connected. >>>> HTTP request sent, awaiting response... 403 Forbidden >>>> 2012-10-05 03:32:58 ERROR 403: Forbidden. >>>> >>>> I tracked the problem down to too strict permission on /var/lib/pki-ca >>>> directory which is being published by httpd which does not have >>>> access to it: >>>> >>>> # ll /var/lib/pki-ca >>>> >>>> drwxrwx---. 11 pkiuser pkiuser 4096 Oct 5 03:00 pki-ca >>>> >>>> When I fixed the permission: >>>> # chmod o+x /var/lib/pki-ca/ >>>> >>>> I was able to get pass the Forbidden error and actually retrieved >>>> the CRL. >>>> Adding Ade on CC list to follow on this permission issue. >>>> >>>> >>>> I was thinking about usability of this new approach, we may want to >>>> make user >>>> life easier in a perspective of CRL master managing. I have following >>>> enhancements in mind: >>>> >>>> - mark CRL master in ipa-replica-manage list, or >>>> ipa-csreplica-manage list: >>>> >>>> # ipa-csreplica-manage list >>>> Directory Manager password: >>>> >>>> vm-065.idm.lab.bos.redhat.com: master [CRL] >>>> vm-120.idm.lab.bos.redhat.com: master >>>> >>>> - when removing master with CRL by "ipa-replica-manage del" we >>>> should warn user >>>> and inform him what he should do next to amend the situation. I am >>>> thinking >>>> about 2 new commands for ipa-csreplica-manage: >>>> >>>> * ipa-csreplica-manage crl-promote >>>> - promote current master as the new CRL master, enable CRL >>>> generation in >>>> CS.cfg, mark master as the new CRL master in cn=masters >>>> * ipa-csreplica-manage crl-update >>>> - update CS.cfg of current CA replica and point >>>> master.ca.agent.* to current >>>> CRL master >>>> >>>> I can work on those enhancements if we agree on them. >>>> >>>> Martin >>>> >>> >>> Andrew provided some feedback out-of-band and my solution was overly >>> complex. >>> Here is a much simpler patch which does away with all the hand-waving >>> around >>> knowing who the CRL generator is. >>> >>> rob >> >> This looks OK code-wise, I will wait for dogtag guys to confirm that >> this is >> the right approach. >> >> Btw. I think we may want to file a RFE to implement some command to >> promote a >> replica to CRL master (like "ipa-csreplica-manage crl-promote" proposed >> earlier). Users may want to promote a replica when the master crashes >> or is to >> be replaced. Some way to migrate CRL list (if not replicated already) >> to the >> promoted replica would also be needed. >> >> Martin >> > > Andrew suggested I specify that we do not monitor cloned revocations on > the server not generating CRLs, so I added that. > > The last question is what we do about redirecting users on the > non-generating masters. > > We can do it easily with a line like this in Apache: > > RewriteRule ^/ipa/crl/MasterCRL.bin > https://$FQDN:9444/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL > [L,R=301,NC] > > The tricky part is writing this properly. The CA can be added > post-install so I don't think simply adding this to ipa-rewrite.conf > will work well. Is adding another template configuration file for Apache > overkill? > > rob Here is my WIP for auto-configuring redirect on clones. It works ok for me and isn't too invasive IMHO. The basic idea is to allow proxying of the getCRL servlet and redirect to that on requests to the clone server. Browsing won't work, but you can fetch the MasterCRL.bin with: # wget --ca-certificate=/etc/ipa/ca.crt http://replica.example.com/ipa/crl/MasterCRL.bin diff --git a/install/conf/ipa-pki-proxy.conf b/install/conf/ipa-pki-proxy.conf index 20c0921..8c4f3a9 100644 --- a/install/conf/ipa-pki-proxy.conf +++ b/install/conf/ipa-pki-proxy.conf @@ -3,7 +3,7 @@ ProxyRequests Off # matches for ee port - + NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate NSSVerifyClient none ProxyPassMatch ajp://localhost:$DOGTAG_PORT @@ -25,3 +25,6 @@ ProxyRequests Off ProxyPassMatch ajp://localhost:$DOGTAG_PORT ProxyPassReverse ajp://localhost:$DOGTAG_PORT + +# Only enable this on servers that are not generating a CRL +${CLONE}RewriteRule ^/ipa/crl/MasterCRL.bin https://$FQDN/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL [L,R=301,NC] diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index 0ac895e..aabbba3 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -1304,7 +1304,11 @@ class CAInstance(service.Service): def __http_proxy(self): template_filename = ipautil.SHARE_DIR + "ipa-pki-proxy.conf" - sub_dict = dict(DOGTAG_PORT=self.dogtag_constants.AJP_PORT) + sub_dict = dict( + DOGTAG_PORT=self.dogtag_constants.AJP_PORT, + CLONE='' if self.clone else '#', + FQDN=self.fqdn, + ) template = ipautil.template_file(template_filename, sub_dict) with open(HTTPD_CONFD + "ipa-pki-proxy.conf", "w") as fd: fd.write(template) From abokovoy at redhat.com Wed Oct 10 07:49:31 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 10 Oct 2012 10:49:31 +0300 Subject: [Freeipa-devel] [PATCH] 0086 Make sure samba{, 4}-winbind-krb5-locator package is not installed when trusts are in use Message-ID: <20121010074930.GI17454@redhat.com> Hi, Since use of winbind on FreeIPA server that is configured with trusts is conflicting with krb5 locator based on winbind, make sure there is conflict that will force removing samba{,4}-winbind-krb5-locator package when -server-trust-ad subpackage is installed. Please note that since feature-wise the two packages would be conflicting in use, one has to play tricks with rpm to enforce automatic removal of the samba{,4}-winbind-krb5-locator with Obsoletes: in addtion to Conflicts: tag. This allows to ensure the two packages never installed together: Conflicts: tag would prevent installing samba{,4}-winbind-krb5-locator after freeipa-server-trust-ad subpackage is installed. Obsoletes: tag would force removal of samba{,4}-winbind-krb5-locator during the install of freeipa-server-trust-ad. https://fedorahosted.org/freeipa/ticket/3102 -- / Alexander Bokovoy -------------- next part -------------- >From 81f31e5fef0e21cc256bd8f8bffa6e551b72da89 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 10 Oct 2012 09:46:08 +0300 Subject: [PATCH 3/5] Make sure samba{,4}-winbind-krb5-locator package is not installed when trusts are in use Since use of winbind on FreeIPA server that is configured with trusts is conflicting with krb5 locator based on winbind, make sure there is conflict that will force removing samba{,4}-winbind-krb5-locator package when -server-trust-ad subpackage is installed. https://fedorahosted.org/freeipa/ticket/3102 --- freeipa.spec.in | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/freeipa.spec.in b/freeipa.spec.in index cc27ffe43758eaedcaaf31b7f55d35d689cec0ae..a9cb05002831cb85f3446b70572828e6f60c7649 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -230,6 +230,12 @@ Requires: samba4 Requires: samba4-winbind %endif Requires: libsss_idmap +# There should be no winbind-based krb5 locator plugin installed on the server where +# trusts are configured since the configurations basically contradict each other +Conflicts: samba4-winbind-krb5-locator +Conflicts: samba-winbind-krb5-locator +Obsoletes: samba4-winbind-krb5-locator +Obsoletes: samba-winbind-krb5-locator %description server-trust-ad Cross-realm trusts with Active Directory in IPA require working Samba 4 installation. @@ -786,6 +792,9 @@ fi %ghost %attr(0644,root,apache) %config(noreplace) %{_sysconfdir}/ipa/ca.crt %changelog +* Wed Oct 10 2012 Alexander Bokovoy - 2.99.0-49 +- Make sure server-trust-ad subpackage conflicts with samba{,4}-winbind-krb5-locator + * Mon Oct 8 2012 Martin Kosek - 2.99.0-48 - Add directory /var/lib/ipa/pki-ca/publish for CRL published by pki-ca -- 1.7.12 From abokovoy at redhat.com Wed Oct 10 07:51:11 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 10 Oct 2012 10:51:11 +0300 Subject: [Freeipa-devel] [PATCH] 0087 Warn about DNA plugin configuration when working with local ID ranges Message-ID: <20121010075111.GJ17454@redhat.com> Warn about manual DNA plugin configuration when working with local ID ranges since we currently do not support automatic pick up of the changed settings for local ID ranges by the DNA plugin. https://fedorahosted.org/freeipa/ticket/3116 -- / Alexander Bokovoy -------------- next part -------------- >From 2c98296a26b2176d2ae07257078a1fd460dd90ec Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 10 Oct 2012 10:03:40 +0300 Subject: [PATCH 4/5] Warn about DNA plugin configuration when working with local ID ranges https://fedorahosted.org/freeipa/ticket/3116 --- ipalib/plugins/idrange.py | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/ipalib/plugins/idrange.py b/ipalib/plugins/idrange.py index 8f2d4efdc0463e7d81cd72fba7769e38dc0c638b..ef712de4f8663f374097eb737a5f4c71097b61f6 100644 --- a/ipalib/plugins/idrange.py +++ b/ipalib/plugins/idrange.py @@ -111,7 +111,6 @@ Typically the creation of ID ranges happens behind the scenes and this CLI must not be used at all. The ID range for the local domain will be created during installation or upgrade from an older version. The ID range for a trusted domain will be created together with the trust by 'ipa trust-add ...'. -The use cases for this CLI are USE CASES: @@ -141,6 +140,15 @@ the domain SID. E.g. if the domain SID is S-1-5-21-123-456-789 and a user from this domain has the SID S-1-5-21-123-456-789-1010 then 1010 id the RID of the user. RIDs are unique in a domain, 32bit values and are used for users and groups. + +WARNING: + +DNA plugin in 389-ds will allocate IDs based on the ranges configured for the +local domain. Currently the DNA plugin *cannot* be reconfigured itself based +on the local ranges set via this family of commands. + +Manual configuration change has to be done in the DNA plugin configuration to +match with the new range. """) class idrange(LDAPObject): -- 1.7.12 From abokovoy at redhat.com Wed Oct 10 07:52:18 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 10 Oct 2012 10:52:18 +0300 Subject: [Freeipa-devel] [PATCH] 0088 Fix typo in the documentation for trusts: RID for Domain Admins is -512 Message-ID: <20121010075218.GK17454@redhat.com> Hi, Domain Admins RID is -512, not -513. Fix the documentation text. -- / Alexander Bokovoy -------------- next part -------------- >From 152c2f7aae533594599bd86f5779978cf656e600 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 10 Oct 2012 10:04:25 +0300 Subject: [PATCH 5/5] Fix wrong RID for Domain Admins in the examples of trust commands --- ipalib/plugins/trust.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index 793ad90c0f90dfc4bc3fbaa3d9184b301a44aa0f..845f96e1fdd09d1e85f6f900d3f1c241445b9c6b 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -88,9 +88,9 @@ Example: ipa group-add --desc=' admins' ad_admins 3. Add security identifier of Domain Admins of the to the ad_admins_external - group (security identifier of -513 is Domain Admins group): + group (security identifier of -512 is Domain Admins group): - ipa group-add-member ad_admins_external --external ${domainsid}-513 + ipa group-add-member ad_admins_external --external ${domainsid}-512 4. Allow members of ad_admins_external group to be associated with ad_admins POSIX group: -- 1.7.12 From abokovoy at redhat.com Wed Oct 10 08:24:32 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 10 Oct 2012 11:24:32 +0300 Subject: [Freeipa-devel] [PATCH] 0086 Make sure samba{, 4}-winbind-krb5-locator package is not installed when trusts are in use In-Reply-To: <20121010074930.GI17454@redhat.com> References: <20121010074930.GI17454@redhat.com> Message-ID: <20121010082432.GL17454@redhat.com> On Wed, 10 Oct 2012, Alexander Bokovoy wrote: >Hi, > >Since use of winbind on FreeIPA server that is configured with trusts is >conflicting with krb5 locator based on winbind, make sure there is >conflict that will force removing samba{,4}-winbind-krb5-locator package >when -server-trust-ad subpackage is installed. > >Please note that since feature-wise the two packages would be >conflicting in use, one has to play tricks with rpm to enforce >automatic removal of the samba{,4}-winbind-krb5-locator with Obsoletes: >in addtion to Conflicts: tag. This allows to ensure the two packages >never installed together: > >Conflicts: tag would prevent installing samba{,4}-winbind-krb5-locator after >freeipa-server-trust-ad subpackage is installed. > >Obsoletes: tag would force removal of samba{,4}-winbind-krb5-locator >during the install of freeipa-server-trust-ad. Unfortunately, the side-effect of the Obsoletes: tag is that freeipa-server-trust-ad would always be selected from the repository whenever one wants to install samba{,4}-winbind-krb5-locator, so this approach does not work. We can keep pure Conflicts: tags because they would prevent co-install of the packages. They alone would not be able to provide way to solve conflicts. I'm working on a bit more complex variant with alternatives. -- / Alexander Bokovoy From pviktori at redhat.com Wed Oct 10 08:55:59 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 10 Oct 2012 10:55:59 +0200 Subject: [Freeipa-devel] [PATCHES] 0086-0088 Generate Firefox extension on upgrades In-Reply-To: <50744A59.2050308@redhat.com> References: <50743FCE.5050307@redhat.com> <50744226.90007@redhat.com> <50744A59.2050308@redhat.com> Message-ID: <5075381F.7020804@redhat.com> On 10/09/2012 06:01 PM, Petr Vobornik wrote: > On 10/09/2012 05:26 PM, Petr Viktorin wrote: >> On 10/09/2012 05:16 PM, Petr Viktorin wrote: >>> https://fedorahosted.org/freeipa/ticket/3150 >>> >>> >>> Patch 0086: >>> I found an old unused function while working on this, the patch >>> removes it. >>> >>> Patch 0087: >>> Replica files generated on older masters don't contain the Firefox >>> extension files. Skip installing them in this case. >>> >>> Patch 0088: >>> Servers upgraded from IPA 2.2 need the Firefox extension installed. This >>> is done in ipa-upgradeconfig if they're missing. >>> I made the setup_firefox_extension method independent on the >>> httpinstance state (which is mostly set in create_instance). >>> Similarly, the files are installed ipa-replica-install if they're >>> missing (i.e. skipped by the previous patch). >>> If the Signing-Cert is not on this master, create an unsigned extension >>> using the "zip" command. I needed to add Popen's `cwd` argument to >>> ipautil.run() to get the right filenames out of zip. >>> >>> The patches add "copy_template_file" and "copy_file_if_exists" utilities >>> I've written for some of my WIP patches, expect me to use them more when >>> I get time to work on the installer code. >>> >> >> In my previous mail I've attached an old version of patch 88. Please use >> this one. Sorry! >> >> > > nack > > 1) patch 83-01 doesn't apply. There were conflicts with recent CRL and audit cert renewal patches. Rebased. > 2) When pwd is supplied to setup_firefox_extension `db = > certs.CertDB(realm, subject_base=subject_base)` is skipped and therefore > `db.has_nickname` will fail. Thanks for the catch, fixed. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0086-01-ipa-upgradeconfig-Remove-the-upgrade_httpd_selinux-f.patch Type: text/x-patch Size: 1056 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0087-01-replica-install-Don-t-copy-Firefox-config-extension-.patch Type: text/x-patch Size: 1589 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0088-02-Create-Firefox-extension-on-upgrade-and-replica-inst.patch Type: text/x-patch Size: 8830 bytes Desc: not available URL: From abokovoy at redhat.com Wed Oct 10 09:04:06 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 10 Oct 2012 12:04:06 +0300 Subject: [Freeipa-devel] [PATCH] 0086 Make sure samba{, 4}-winbind-krb5-locator package is not installed when trusts are in use In-Reply-To: <20121010082432.GL17454@redhat.com> References: <20121010074930.GI17454@redhat.com> <20121010082432.GL17454@redhat.com> Message-ID: <20121010090406.GM17454@redhat.com> On Wed, 10 Oct 2012, Alexander Bokovoy wrote: >On Wed, 10 Oct 2012, Alexander Bokovoy wrote: >>Hi, >> >>Since use of winbind on FreeIPA server that is configured with trusts is >>conflicting with krb5 locator based on winbind, make sure there is >>conflict that will force removing samba{,4}-winbind-krb5-locator package >>when -server-trust-ad subpackage is installed. >> >>Please note that since feature-wise the two packages would be >>conflicting in use, one has to play tricks with rpm to enforce >>automatic removal of the samba{,4}-winbind-krb5-locator with Obsoletes: >>in addtion to Conflicts: tag. This allows to ensure the two packages >>never installed together: >> >>Conflicts: tag would prevent installing samba{,4}-winbind-krb5-locator after >>freeipa-server-trust-ad subpackage is installed. >> >>Obsoletes: tag would force removal of samba{,4}-winbind-krb5-locator >>during the install of freeipa-server-trust-ad. >Unfortunately, the side-effect of the Obsoletes: tag is that >freeipa-server-trust-ad would always be selected from the repository >whenever one wants to install samba{,4}-winbind-krb5-locator, so this >approach does not work. > >We can keep pure Conflicts: tags because they would prevent co-install >of the packages. They alone would not be able to provide way to solve >conflicts. > >I'm working on a bit more complex variant with alternatives. New patch attached. I verified that it works but in order to make it useful, samba{,4} package needs to be updated to include alternatives for winbind_krb5_locator.so plugin. Working on that now. -- / Alexander Bokovoy -------------- next part -------------- >From ce35a07c652bfafd68c2be6878d92675f15d810c Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 10 Oct 2012 09:46:08 +0300 Subject: [PATCH 3/5] Make sure samba{,4}-winbind-krb5-locator package is not used when trusts are in going to be configured Since use of winbind on FreeIPA server that is configured with trusts is conflicting with krb5 locator based on winbind, use alternatives mechanism to turn off the locator plugin by symlinking it to /dev/null. https://fedorahosted.org/freeipa/ticket/3102 --- freeipa.spec.in | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/freeipa.spec.in b/freeipa.spec.in index cc27ffe43758eaedcaaf31b7f55d35d689cec0ae..97aa501b3153243ddb213c1b6d85d7a46cc00b70 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -230,6 +230,13 @@ Requires: samba4 Requires: samba4-winbind %endif Requires: libsss_idmap +# 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 +# since Winbindd will be configured in a different mode +Requires(post): %{_sbindir}/update-alternatives +Requires(postun): %{_sbindir}/update-alternatives +Requires(preun): %{_sbindir}/update-alternatives %description server-trust-ad Cross-realm trusts with Active Directory in IPA require working Samba 4 installation. @@ -438,6 +445,9 @@ install -m 0644 init/systemd/ipa.conf.tmpfiles %{buildroot}%{_sysconfdir}/tmpfil mkdir -p %{buildroot}%{_localstatedir}/run/ install -d -m 0700 %{buildroot}%{_localstatedir}/run/ipa_memcached/ +mkdir -p %{buildroot}%{_libdir}/krb5/plugins/libkrb5 +touch %{buildroot}%{_libdir}/krb5/plugins/libkrb5/winbind_krb5_locator.so + %if 0%{?fedora} >= 16 # Default to systemd initscripts for F16 and above mkdir -p %{buildroot}%{_unitdir} @@ -568,6 +578,22 @@ if [ $? == 0 -a "${SELINUXTYPE}" == targeted -a -f ${FILE_CONTEXT}.%{name} ]; t rm -f ${FILE_CONTEXT}.%name fi fi + +%postun server-trust-ad +if [ "$1" -ge "1" ]; then + if [ "`readlink %{_sysconfdir}/alternatives/winbind_krb5_locator.so`" == "/dev/null" ]; then + %{_sbindir}/alternatives --set winbind_krb5_locator.so /dev/null + fi +fi + +%post server-trust-ad +%{_sbindir}/update-alternatives --install %{_libdir}/krb5/plugins/libkrb5/winbind_krb5_locator.so \ + winbind_krb5_locator.so /dev/null 90 + +%preun server-trust-ad +if [ $1 -eq 0 ]; then + %{_sbindir}/update-alternatives --remove winbind_krb5_locator.so /dev/null +fi %endif @@ -733,6 +759,7 @@ fi %{_mandir}/man1/ipa-adtrust-install.1.gz %{python_sitelib}/ipaserver/dcerpc* %{python_sitelib}/ipaserver/install/adtrustinstance* +%ghost %{_libdir}/krb5/plugins/libkrb5/winbind_krb5_locator.so %endif %files client @@ -786,6 +813,10 @@ fi %ghost %attr(0644,root,apache) %config(noreplace) %{_sysconfdir}/ipa/ca.crt %changelog +* Wed Oct 10 2012 Alexander Bokovoy - 2.99.0-49 +- Make sure server-trust-ad subpackage alternates winbind_krb5_locator.so + plugin to /dev/null since they cannot be used when trusts are configured + * Mon Oct 8 2012 Martin Kosek - 2.99.0-48 - Add directory /var/lib/ipa/pki-ca/publish for CRL published by pki-ca -- 1.7.12 From pviktori at redhat.com Wed Oct 10 09:07:24 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 10 Oct 2012 11:07:24 +0200 Subject: [Freeipa-devel] [PATCH] 321 Move CRL publish directory to IPA owned directory In-Reply-To: <507430AE.5080307@redhat.com> References: <436570478.11020758.1349722511483.JavaMail.root@redhat.com> <507329A6.1090503@redhat.com> <50740AB7.3060209@redhat.com> <50742B37.80401@redhat.com> <507430AE.5080307@redhat.com> Message-ID: <50753ACC.7090002@redhat.com> On 10/09/2012 04:11 PM, Martin Kosek wrote: > On 10/09/2012 03:48 PM, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On 10/08/2012 09:29 PM, Rob Crittenden wrote: >>>> Martin Kosek wrote: >>>>> ----- Original Message ----- >>>>>> From: "Rob Crittenden" >>>>>> To: "Martin Kosek" >>>>>> Cc: freeipa-devel at redhat.com >>>>>> Sent: Monday, October 8, 2012 8:18:47 PM >>>>>> Subject: Re: [Freeipa-devel] [PATCH] 321 Move CRL publish directory to IPA >>>>>> owned directory >>>>>> >>>>>> Martin Kosek wrote: >>>>>>> Currently, CRL files are being exported to /var/lib/pki-ca >>>>>>> sub-directory, which is then served by httpd to clients. However, >>>>>>> this approach has several disadvantages: >>>>>>> * We depend on pki-ca directory structure and relevant >>>>>>> permissions. >>>>>>> If pki-ca changes directory structure or permissions on >>>>>>> upgrade, >>>>>>> IPA may break. This is also a root cause of the latest error, >>>>>>> where >>>>>>> the pki-ca directory does not have X permission for others and >>>>>>> CRL >>>>>>> publishing by httpd breaks. >>>>>>> * Since the directory is not static and is generated during >>>>>>> ipa-server-install, RPM upgrade of IPA packages report errors >>>>>>> when >>>>>>> defining SELinux policy for these directories. >>>>>>> >>>>>>> Move CRL publish directory to /var/lib/ipa/pki-ca/publish (common >>>>>>> for >>>>>>> both dogtag 9 and 10) which is created on RPM upgrade, i.e. SELinux >>>>>>> policy >>>>>>> configuration does not report any error. The new CRL publish >>>>>>> directory >>>>>>> is used for both new IPA installs and upgrades, where contents of >>>>>>> the directory (CRLs) is first migrated to the new location and then >>>>>>> the >>>>>>> actual configuration change is made. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/3144 >>>>>>> >>>>>>> >>>>>>> ------- >>>>>>> >>>>>>> We may choose to postpone this patch to later version, it is quite >>>>>>> disruptive. >>>>>>> I can produce a hotfix in that case, which would only fix the >>>>>>> permission of the >>>>>>> pki-ca directory. >>>>>>> >>>>>>> Martin >>>>>> >>>>>> This looks good, just a couple of questions. >>>>>> >>>>>> Should the old files be removed? >>>>> >>>>> Yeah, this is something I wonder about too. One one side, users may be get >>>>> confused if there are 2 publish directories with the same content (a least >>>>> until a next CRL generation). But on the other side, I was cautious not to >>>>> delete something important in a case when something goes wrong. But maybe I >>>>> am just being over-cautious and we can delete it, or maybe move directory to >>>>> "publish.deleted". In a worst case scenario, CRLs should be generated again, >>>>> in about 4 hours... >>>>> >>>>>> >>>>>> Should some error handling be added around the copy to ensure it is >>>>>> successful? This would blow up if the disk was full, for example. >>>>> >>>>> I think this is covered, I have there a try..except clause for this case: >>>>> >>>>> + for f in crl_files: >>>>> + try: >>>>> + copy_crl_file(f) >>>>> + except Exception, e: >>>>> + root_logger.error('Cannot move CRL file to new directory: >>>>> %s', e) >>>>> >>>>> Just the exception is caught on a higher level and error is reported to user. >>>>> Not sure what to do in this case - report error to user, do not change the >>>>> location and ask user to resolve the error? Or just report error and continue >>>>> with CRL publish directory change as I do currently? >>>>> >>>>> Martin >>>>> >>>> >>>> Ah, I was looking at too low a level. >>>> >>>> I think this is fine. I wonder if we should log/document somewhere in big >>>> flashing letters that the stuff has been moved. It is rather clear in the logs >>>> now, I suppose, if you look carefully. >>>> >>>> I guess it isn't really that big a deal now since we just have server certs. It >>>> would take a whole ton of revocations to grow the CRLs that quickly, so maybe >>>> my concerns are overblown. >>>> >>>> rob >>> >>> CRL size may quickly grown for someone who rapidly adds/removes client hosts or >>> services as we revoke such certificates with 4 - superseded.. About the user >>> info - maybe we should also allow output of ipa-upgradeconfig's stderr stream >>> as we did with ipa-ldap-updater. This way, user would receive error message >>> when CRL copy operation fails. >>> >>> Martin >>> >> >> I think the patch is fine as-is. Can you open a new ticket on a mechanism to >> alert the user to upgrade things to review? > > https://fedorahosted.org/freeipa/ticket/3157 > >> >> ACK >> >> rob >> > > Rebased and pushed to master, ipa-3-0. > > Martin > The upgrade is done even on a replica without a CA. On such a system, rpm update just silently fails. https://fedorahosted.org/freeipa/ticket/3159 -- Petr? From abokovoy at redhat.com Wed Oct 10 09:29:28 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 10 Oct 2012 12:29:28 +0300 Subject: [Freeipa-devel] [PATCH] 0086 Make sure samba{, 4}-winbind-krb5-locator package is not installed when trusts are in use In-Reply-To: <20121010090406.GM17454@redhat.com> References: <20121010074930.GI17454@redhat.com> <20121010082432.GL17454@redhat.com> <20121010090406.GM17454@redhat.com> Message-ID: <20121010092928.GN17454@redhat.com> On Wed, 10 Oct 2012, Alexander Bokovoy wrote: >On Wed, 10 Oct 2012, Alexander Bokovoy wrote: >>On Wed, 10 Oct 2012, Alexander Bokovoy wrote: >>>Hi, >>> >>>Since use of winbind on FreeIPA server that is configured with trusts is >>>conflicting with krb5 locator based on winbind, make sure there is >>>conflict that will force removing samba{,4}-winbind-krb5-locator package >>>when -server-trust-ad subpackage is installed. >>> >>>Please note that since feature-wise the two packages would be >>>conflicting in use, one has to play tricks with rpm to enforce >>>automatic removal of the samba{,4}-winbind-krb5-locator with Obsoletes: >>>in addtion to Conflicts: tag. This allows to ensure the two packages >>>never installed together: >>> >>>Conflicts: tag would prevent installing samba{,4}-winbind-krb5-locator after >>>freeipa-server-trust-ad subpackage is installed. >>> >>>Obsoletes: tag would force removal of samba{,4}-winbind-krb5-locator >>>during the install of freeipa-server-trust-ad. >>Unfortunately, the side-effect of the Obsoletes: tag is that >>freeipa-server-trust-ad would always be selected from the repository >>whenever one wants to install samba{,4}-winbind-krb5-locator, so this >>approach does not work. >> >>We can keep pure Conflicts: tags because they would prevent co-install >>of the packages. They alone would not be able to provide way to solve >>conflicts. >> >>I'm working on a bit more complex variant with alternatives. >New patch attached. I verified that it works but in order to make it >useful, samba{,4} package needs to be updated to include alternatives >for winbind_krb5_locator.so plugin. Working on that now. Attached is the patch for samba (f18, rawhide). -- / Alexander Bokovoy -------------- next part -------------- >From a78139d777deab75e3bf500472d88cba6a720484 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 10 Oct 2012 12:21:42 +0300 Subject: [PATCH] Move winbind_krb5_locator.so to back to %_libdir and use alternatives instead This is required to support IPA AD trusts where winbind_krb5_locator.so should be disabled. The only way to disable it without uninstalling the package is to make it configurable via alternatives system. --- samba.spec | 36 ++++++++++++++++++++++++++++++++---- 1 file changed, 32 insertions(+), 4 deletions(-) diff --git a/samba.spec b/samba.spec index 292fd7e90221795982788dc7a7606fa907dfa4e3..a3cc66b326f7cf83b4c81939aa70d35b80fcae0b 100644 --- a/samba.spec +++ b/samba.spec @@ -1,4 +1,4 @@ -%define main_release 152 +%define main_release 153 %define samba_version 4.0.0 %define talloc_version 2.0.7 @@ -279,6 +279,14 @@ Requires: %{name}-libs = %{samba_depver} Provides: samba4-winbind-krb5-locator = %{samba_depver} Obsoletes: samba4-winbind-krb5-locator < %{samba_depver} +# Handle winbind_krb5_locator.so as alternatives to allow +# IPA AD trusts case where it should not be used by libkrb5 +# The plugin will be diverted to /dev/null by the FreeIPA +# freeipa-server-trust-ad subpackage due to higher priority +# and restored to the proper one on uninstall +Requires(post): %{_sbindir}/update-alternatives +Requires(postun): %{_sbindir}/update-alternatives +Requires(preun): %{_sbindir}/update-alternatives %description winbind-krb5-locator The winbind krb5 locator is a plugin for the system kerberos library to allow @@ -538,8 +546,7 @@ done # winbind krb5 locator install -d -m 0755 %{buildroot}%{_libdir}/krb5/plugins/libkrb5 -install -m 755 %{buildroot}/%{_libdir}/winbind_krb5_locator.so %{buildroot}/%{_libdir}/krb5/plugins/libkrb5/winbind_krb5_locator.so -rm -f %{buildroot}/%{_libdir}/winbind_krb5_locator.so +touch %{buildroot}%{_libdir}/krb5/plugins/libkrb5/winbind_krb5_locator.so # cleanup stuff that does not belong here rm -f %{buildroot}/%{_mandir}/man3/ldb.3* @@ -557,6 +564,7 @@ rm -rf %{buildroot}%{perl_vendorlib}/Parse/Yapp # Fix up permission on perl install. %{_fixperms} %{buildroot}%{perl_vendorlib} + # Remove stuff the buildsystem did not handle correctly rm -f %{buildroot}%{_libdir}/security/pam_smbpass.so rm -f %{buildroot}%{python_sitelib}/tevent.py @@ -622,6 +630,22 @@ rm -f %{buildroot}%{python_sitelib}/tevent.py %postun -n libwbclient -p /sbin/ldconfig %endif # with_libwbclient +%postun winbind-krb5-locator +if [ "$1" -ge "1" ]; then + if [ "`readlink %{_sysconfdir}/alternatives/winbind_krb5_locator.so`" == "%{_libdir}/winbind_krb5_locator.so" ]; then + %{_sbindir}/alternatives --set winbind_krb5_locator %{_libdir}/winbind_krb5_locator.so + fi +fi + +%post winbind-krb5-locator +%{_sbindir}/update-alternatives --install %{_libdir}/krb5/plugins/libkrb5/winbind_krb5_locator.so \ + winbind_krb5_locator.so %{_libdir}/winbind_krb5_locator.so 10 + +%preun winbind-krb5-locator +if [ $1 -eq 0 ]; then + %{_sbindir}/update-alternatives --remove winbind_krb5_locator.so %{_libdir}/winbind_krb5_locator.so +fi + %clean rm -rf %{buildroot} @@ -905,7 +929,8 @@ rm -rf %{buildroot} %files winbind-krb5-locator %defattr(-,root,root) -%{_libdir}/krb5/plugins/libkrb5/winbind_krb5_locator.so +%ghost %{_libdir}/krb5/plugins/libkrb5/winbind_krb5_locator.so +%{_libdir}/winbind_krb5_locator.so %{_mandir}/man7/winbind_krb5_locator.7* %files winbind-clients @@ -1255,6 +1280,9 @@ rm -rf %{buildroot} %endif # with_libwbclient %changelog +* Wed Oct 10 2012 - Alexander Bokovoy - 2:4.0.0-153.rc1 +- Use alternatives to configure winbind_krb5_locator.so + * Thu Oct 04 2012 - Andreas Schneider - 2:4.0.0-152.rc1 - Add kerberos AES support. - Fix printing initialization. -- 1.7.12 From sbose at redhat.com Wed Oct 10 09:40:47 2012 From: sbose at redhat.com (Sumit Bose) Date: Wed, 10 Oct 2012 11:40:47 +0200 Subject: [Freeipa-devel] [PATCH] 0088 Fix typo in the documentation for trusts: RID for Domain Admins is -512 In-Reply-To: <20121010075218.GK17454@redhat.com> References: <20121010075218.GK17454@redhat.com> Message-ID: <20121010094047.GB2134@localhost.localdomain> On Wed, Oct 10, 2012 at 10:52:18AM +0300, Alexander Bokovoy wrote: > Hi, > > Domain Admins RID is -512, not -513. Fix the documentation text. > > > -- > / Alexander Bokovoy ACK bye, Sumit From sbose at redhat.com Wed Oct 10 09:47:44 2012 From: sbose at redhat.com (Sumit Bose) Date: Wed, 10 Oct 2012 11:47:44 +0200 Subject: [Freeipa-devel] [PATCH] 0087 Warn about DNA plugin configuration when working with local ID ranges In-Reply-To: <20121010075111.GJ17454@redhat.com> References: <20121010075111.GJ17454@redhat.com> Message-ID: <20121010094744.GC2134@localhost.localdomain> On Wed, Oct 10, 2012 at 10:51:11AM +0300, Alexander Bokovoy wrote: > > Warn about manual DNA plugin configuration when working with local ID ranges > since we currently do not support automatic pick up of the changed > settings for local ID ranges by the DNA plugin. > https://fedorahosted.org/freeipa/ticket/3116 > > > -- > / Alexander Bokovoy > >From 2c98296a26b2176d2ae07257078a1fd460dd90ec Mon Sep 17 00:00:00 2001 > From: Alexander Bokovoy > Date: Wed, 10 Oct 2012 10:03:40 +0300 > Subject: [PATCH 4/5] Warn about DNA plugin configuration when working with > local ID ranges > > https://fedorahosted.org/freeipa/ticket/3116 > --- > ipalib/plugins/idrange.py | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/ipalib/plugins/idrange.py b/ipalib/plugins/idrange.py > index 8f2d4efdc0463e7d81cd72fba7769e38dc0c638b..ef712de4f8663f374097eb737a5f4c71097b61f6 100644 > --- a/ipalib/plugins/idrange.py > +++ b/ipalib/plugins/idrange.py > @@ -111,7 +111,6 @@ Typically the creation of ID ranges happens behind the scenes and this CLI > must not be used at all. The ID range for the local domain will be created > during installation or upgrade from an older version. The ID range for a > trusted domain will be created together with the trust by 'ipa trust-add ...'. > -The use cases for this CLI are > > USE CASES: > > @@ -141,6 +140,15 @@ the domain SID. E.g. if the domain SID is S-1-5-21-123-456-789 and a user from > this domain has the SID S-1-5-21-123-456-789-1010 then 1010 id the RID of the > user. RIDs are unique in a domain, 32bit values and are used for users and > groups. > + > +WARNING: > + > +DNA plugin in 389-ds will allocate IDs based on the ranges configured for the > +local domain. Currently the DNA plugin *cannot* be reconfigured itself based > +on the local ranges set via this family of commands. > + > +Manual configuration change has to be done in the DNA plugin configuration to > +match with the new range. > """) I wonder if we should add a sentence like "See section 'Managing Unique UID and GID Number Assignments' in the FreeIPA Documentation for details' to point the admin to the right directory? Or replace the last sentence with something more explicit like 'The dnaNextRange attribute of 'cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config' has to be modified to match the new range'? bye, Sumit > > class idrange(LDAPObject): > -- > 1.7.12 > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From abokovoy at redhat.com Wed Oct 10 09:59:53 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 10 Oct 2012 12:59:53 +0300 Subject: [Freeipa-devel] [PATCH] 0087 Warn about DNA plugin configuration when working with local ID ranges In-Reply-To: <20121010094744.GC2134@localhost.localdomain> References: <20121010075111.GJ17454@redhat.com> <20121010094744.GC2134@localhost.localdomain> Message-ID: <20121010095953.GP17454@redhat.com> On Wed, 10 Oct 2012, Sumit Bose wrote: >On Wed, Oct 10, 2012 at 10:51:11AM +0300, Alexander Bokovoy wrote: >> >> Warn about manual DNA plugin configuration when working with local ID ranges >> since we currently do not support automatic pick up of the changed >> settings for local ID ranges by the DNA plugin. >> https://fedorahosted.org/freeipa/ticket/3116 >> >> >> -- >> / Alexander Bokovoy > >> >From 2c98296a26b2176d2ae07257078a1fd460dd90ec Mon Sep 17 00:00:00 2001 >> From: Alexander Bokovoy >> Date: Wed, 10 Oct 2012 10:03:40 +0300 >> Subject: [PATCH 4/5] Warn about DNA plugin configuration when working with >> local ID ranges >> >> https://fedorahosted.org/freeipa/ticket/3116 >> --- >> ipalib/plugins/idrange.py | 10 +++++++++- >> 1 file changed, 9 insertions(+), 1 deletion(-) >> >> diff --git a/ipalib/plugins/idrange.py b/ipalib/plugins/idrange.py >> index 8f2d4efdc0463e7d81cd72fba7769e38dc0c638b..ef712de4f8663f374097eb737a5f4c71097b61f6 100644 >> --- a/ipalib/plugins/idrange.py >> +++ b/ipalib/plugins/idrange.py >> @@ -111,7 +111,6 @@ Typically the creation of ID ranges happens behind the scenes and this CLI >> must not be used at all. The ID range for the local domain will be created >> during installation or upgrade from an older version. The ID range for a >> trusted domain will be created together with the trust by 'ipa trust-add ...'. >> -The use cases for this CLI are >> >> USE CASES: >> >> @@ -141,6 +140,15 @@ the domain SID. E.g. if the domain SID is S-1-5-21-123-456-789 and a user from >> this domain has the SID S-1-5-21-123-456-789-1010 then 1010 id the RID of the >> user. RIDs are unique in a domain, 32bit values and are used for users and >> groups. >> + >> +WARNING: >> + >> +DNA plugin in 389-ds will allocate IDs based on the ranges configured for the >> +local domain. Currently the DNA plugin *cannot* be reconfigured itself based >> +on the local ranges set via this family of commands. >> + >> +Manual configuration change has to be done in the DNA plugin configuration to >> +match with the new range. >> """) > >I wonder if we should add a sentence like "See section 'Managing Unique >UID and GID Number Assignments' in the FreeIPA Documentation for >details' to point the admin to the right directory? Or replace the last >sentence with something more explicit like 'The dnaNextRange attribute >of 'cn=Posix IDs,cn=Distributed Numeric Assignment >Plugin,cn=plugins,cn=config' has to be modified to match the new range'? Updated the patch, also adding the same warning to the 'idrange-add' help. -- / Alexander Bokovoy -------------- next part -------------- >From d3fcc6f4202ae610b287535a696098040180f026 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 10 Oct 2012 10:03:40 +0300 Subject: [PATCH 4/5] Warn about DNA plugin configuration when working with local ID ranges https://fedorahosted.org/freeipa/ticket/3116 --- ipalib/plugins/idrange.py | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/ipalib/plugins/idrange.py b/ipalib/plugins/idrange.py index 8f2d4efdc0463e7d81cd72fba7769e38dc0c638b..75470811750f745c9b89268074830439bfc06bce 100644 --- a/ipalib/plugins/idrange.py +++ b/ipalib/plugins/idrange.py @@ -111,7 +111,6 @@ Typically the creation of ID ranges happens behind the scenes and this CLI must not be used at all. The ID range for the local domain will be created during installation or upgrade from an older version. The ID range for a trusted domain will be created together with the trust by 'ipa trust-add ...'. -The use cases for this CLI are USE CASES: @@ -141,6 +140,17 @@ the domain SID. E.g. if the domain SID is S-1-5-21-123-456-789 and a user from this domain has the SID S-1-5-21-123-456-789-1010 then 1010 id the RID of the user. RIDs are unique in a domain, 32bit values and are used for users and groups. + +WARNING: + +DNA plugin in 389-ds will allocate IDs based on the ranges configured for the +local domain. Currently the DNA plugin *cannot* be reconfigured itself based +on the local ranges set via this family of commands. + +Manual configuration change has to be done in the DNA plugin configuration for +the new local range. Specifically, The dnaNextRange attribute of 'cn=Posix +IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config' has to be +modified to match the new range. """) class idrange(LDAPObject): @@ -287,6 +297,17 @@ class idrange_add(LDAPCreate): --dom-sid must be given to add a new range for a trusted AD domain. + + WARNING: + + DNA plugin in 389-ds will allocate IDs based on the ranges configured for the + local domain. Currently the DNA plugin *cannot* be reconfigured itself based + on the local ranges set via this family of commands. + + Manual configuration change has to be done in the DNA plugin configuration for + the new local range. Specifically, The dnaNextRange attribute of 'cn=Posix + IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config' has to be + modified to match the new range. """) msg_summary = _('Added ID range "%(value)s"') -- 1.7.12 From jcholast at redhat.com Wed Oct 10 10:23:42 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 10 Oct 2012 12:23:42 +0200 Subject: [Freeipa-devel] [PATCH] 1051 Fix CS replica management In-Reply-To: <50747B87.6010309@redhat.com> References: <5040F7DA.5020606@redhat.com> <505AF524.5050405@redhat.com> <505B5490.80303@redhat.com> <5072ED4C.4070604@redhat.com> <5073D8CC.1040505@redhat.com> <50747B87.6010309@redhat.com> Message-ID: <50754CAE.3070006@redhat.com> On 9.10.2012 21:31, Rob Crittenden wrote: > Martin Kosek wrote: >> On 10/08/2012 05:12 PM, Jan Cholasta wrote: >>> Hi, >>> >>> On 20.9.2012 19:38, Rob Crittenden wrote: >>>> Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> Dne 31.8.2012 19:43, Rob Crittenden napsal(a): >>>>>> The naming in CS replication agreements is different from IPA >>>>>> agreements, we have to live with what the create. The master side >>>>>> should >>>>>> be on the local side, replica1, not the remote. This required >>>>>> reversing >>>>>> a few master variables. >>>>>> >>>>>> Pass in the force flag to del_link. >>>>>> >>>>>> Do a better job of finding the agreements on each side. >>>>>> >>>>>> This should be ipa-csreplica-manage more in line with >>>>>> ipa-replica-manage. >>>>>> >>>>>> rob >>>>>> >>>>> >>>>> Rob, can you please rebase the patch on top of current master? There >>>>> were some dogtag 10 related changes to ipa-csreplica-manage since you >>>>> posted the patch. >>>>> >>>>> Honza >>>>> >>>> >>>> I re-tested after the merge and found some problems with my initial >>>> approach. The problem stems from the naming convention that dogtag uses >>>> when creating the initial agreements. It is hard to predict how things >>>> were set up later so rather than trying to reconstruct the DN we search >>>> for it and pass it when deleting agreements. >>>> >>>> rob >>> >>> So far I have found this: >>> >>> * Deleting a "bridge" link that connects two "islands" of replicas >>> works, but >>> it should not (I was told that this is expected, as no complex graph >>> algorithms >>> are engaged to detect this kind of errors). >> >> Exactly, I hit this error when I was a similar Rob's patch for >> ipa-replica-manage (ticket 2797). I used topology "A - B - C - D - E" >> and I was >> able to delete C. We may want to log an enhancement ticket for this. >> >> Martin >> > > Right, and ipa-csreplica-manage doesn't even have the basic last_link > checking code that ipa-replica-manage has, nor the ruv code. We decided > to push that to a future release. > > This patch should fix up the basics. > > rob This fixes everything except I'm still unable to delete a master from a master that is not directly connected to it. If this is OK, then ACK. Honza -- Jan Cholasta From mkosek at redhat.com Wed Oct 10 10:39:20 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 10 Oct 2012 12:39:20 +0200 Subject: [Freeipa-devel] [PATCH] 321 Move CRL publish directory to IPA owned directory In-Reply-To: <50753ACC.7090002@redhat.com> References: <436570478.11020758.1349722511483.JavaMail.root@redhat.com> <507329A6.1090503@redhat.com> <50740AB7.3060209@redhat.com> <50742B37.80401@redhat.com> <507430AE.5080307@redhat.com> <50753ACC.7090002@redhat.com> Message-ID: <50755058.9090707@redhat.com> On 10/10/2012 11:07 AM, Petr Viktorin wrote: > On 10/09/2012 04:11 PM, Martin Kosek wrote: >> On 10/09/2012 03:48 PM, Rob Crittenden wrote: >>> Martin Kosek wrote: >>>> On 10/08/2012 09:29 PM, Rob Crittenden wrote: >>>>> Martin Kosek wrote: >>>>>> ----- Original Message ----- >>>>>>> From: "Rob Crittenden" >>>>>>> To: "Martin Kosek" >>>>>>> Cc: freeipa-devel at redhat.com >>>>>>> Sent: Monday, October 8, 2012 8:18:47 PM >>>>>>> Subject: Re: [Freeipa-devel] [PATCH] 321 Move CRL publish directory to IPA >>>>>>> owned directory >>>>>>> >>>>>>> Martin Kosek wrote: >>>>>>>> Currently, CRL files are being exported to /var/lib/pki-ca >>>>>>>> sub-directory, which is then served by httpd to clients. However, >>>>>>>> this approach has several disadvantages: >>>>>>>> * We depend on pki-ca directory structure and relevant >>>>>>>> permissions. >>>>>>>> If pki-ca changes directory structure or permissions on >>>>>>>> upgrade, >>>>>>>> IPA may break. This is also a root cause of the latest error, >>>>>>>> where >>>>>>>> the pki-ca directory does not have X permission for others and >>>>>>>> CRL >>>>>>>> publishing by httpd breaks. >>>>>>>> * Since the directory is not static and is generated during >>>>>>>> ipa-server-install, RPM upgrade of IPA packages report errors >>>>>>>> when >>>>>>>> defining SELinux policy for these directories. >>>>>>>> >>>>>>>> Move CRL publish directory to /var/lib/ipa/pki-ca/publish (common >>>>>>>> for >>>>>>>> both dogtag 9 and 10) which is created on RPM upgrade, i.e. SELinux >>>>>>>> policy >>>>>>>> configuration does not report any error. The new CRL publish >>>>>>>> directory >>>>>>>> is used for both new IPA installs and upgrades, where contents of >>>>>>>> the directory (CRLs) is first migrated to the new location and then >>>>>>>> the >>>>>>>> actual configuration change is made. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/3144 >>>>>>>> >>>>>>>> >>>>>>>> ------- >>>>>>>> >>>>>>>> We may choose to postpone this patch to later version, it is quite >>>>>>>> disruptive. >>>>>>>> I can produce a hotfix in that case, which would only fix the >>>>>>>> permission of the >>>>>>>> pki-ca directory. >>>>>>>> >>>>>>>> Martin >>>>>>> >>>>>>> This looks good, just a couple of questions. >>>>>>> >>>>>>> Should the old files be removed? >>>>>> >>>>>> Yeah, this is something I wonder about too. One one side, users may be get >>>>>> confused if there are 2 publish directories with the same content (a least >>>>>> until a next CRL generation). But on the other side, I was cautious not to >>>>>> delete something important in a case when something goes wrong. But maybe I >>>>>> am just being over-cautious and we can delete it, or maybe move directory to >>>>>> "publish.deleted". In a worst case scenario, CRLs should be generated again, >>>>>> in about 4 hours... >>>>>> >>>>>>> >>>>>>> Should some error handling be added around the copy to ensure it is >>>>>>> successful? This would blow up if the disk was full, for example. >>>>>> >>>>>> I think this is covered, I have there a try..except clause for this case: >>>>>> >>>>>> + for f in crl_files: >>>>>> + try: >>>>>> + copy_crl_file(f) >>>>>> + except Exception, e: >>>>>> + root_logger.error('Cannot move CRL file to new directory: >>>>>> %s', e) >>>>>> >>>>>> Just the exception is caught on a higher level and error is reported to >>>>>> user. >>>>>> Not sure what to do in this case - report error to user, do not change the >>>>>> location and ask user to resolve the error? Or just report error and >>>>>> continue >>>>>> with CRL publish directory change as I do currently? >>>>>> >>>>>> Martin >>>>>> >>>>> >>>>> Ah, I was looking at too low a level. >>>>> >>>>> I think this is fine. I wonder if we should log/document somewhere in big >>>>> flashing letters that the stuff has been moved. It is rather clear in the >>>>> logs >>>>> now, I suppose, if you look carefully. >>>>> >>>>> I guess it isn't really that big a deal now since we just have server >>>>> certs. It >>>>> would take a whole ton of revocations to grow the CRLs that quickly, so maybe >>>>> my concerns are overblown. >>>>> >>>>> rob >>>> >>>> CRL size may quickly grown for someone who rapidly adds/removes client >>>> hosts or >>>> services as we revoke such certificates with 4 - superseded.. About the user >>>> info - maybe we should also allow output of ipa-upgradeconfig's stderr stream >>>> as we did with ipa-ldap-updater. This way, user would receive error message >>>> when CRL copy operation fails. >>>> >>>> Martin >>>> >>> >>> I think the patch is fine as-is. Can you open a new ticket on a mechanism to >>> alert the user to upgrade things to review? >> >> https://fedorahosted.org/freeipa/ticket/3157 >> >>> >>> ACK >>> >>> rob >>> >> >> Rebased and pushed to master, ipa-3-0. >> >> Martin >> > > The upgrade is done even on a replica without a CA. > On such a system, rpm update just silently fails. > > https://fedorahosted.org/freeipa/ticket/3159 > Thanks, this is a very good catch. I will send a patch fixing this issue in few minutes. Martin From mkosek at redhat.com Wed Oct 10 11:05:11 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 10 Oct 2012 13:05:11 +0200 Subject: [Freeipa-devel] [PATCH] 322 Fix CA CRL migration crash in ipa-upgradeconfig Message-ID: <50755667.5020909@redhat.com> CRL migrate procedure did not check if a CA was actually configured on an updated master/replica. This caused ipa-upgradeconfig to crash on replicas without a CA. Make sure that CRL migrate procedure is not run when CA is not configured on given master. Also add few try..except clauses to make the procedure more robust. There is also a small refactoring of " is not configured" log messages, so that they have matching log level and message. dogtag.py constants were updated to have a correct path to new CRL directory on Fedora 18 (dogtag 10). https://fedorahosted.org/freeipa/ticket/3159 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-322-fix-ca-crl-migration-crash-in-ipa-upgradeconfig.patch Type: text/x-patch Size: 6557 bytes Desc: not available URL: From pviktori at redhat.com Wed Oct 10 12:13:01 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 10 Oct 2012 14:13:01 +0200 Subject: [Freeipa-devel] [PATCH] 322 Fix CA CRL migration crash in ipa-upgradeconfig In-Reply-To: <50755667.5020909@redhat.com> References: <50755667.5020909@redhat.com> Message-ID: <5075664D.4010606@redhat.com> On 10/10/2012 01:05 PM, Martin Kosek wrote: > CRL migrate procedure did not check if a CA was actually configured > on an updated master/replica. This caused ipa-upgradeconfig to > crash on replicas without a CA. > > Make sure that CRL migrate procedure is not run when CA is not > configured on given master. Also add few try..except clauses to > make the procedure more robust. There is also a small refactoring of > " is not configured" log messages, so that they have matching > log level and message. > > dogtag.py constants were updated to have a correct path to new CRL > directory on Fedora 18 (dogtag 10). > > https://fedorahosted.org/freeipa/ticket/3159 > ACK, I no longer get the upgrade errors. -- Petr? From mkosek at redhat.com Wed Oct 10 12:16:57 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 10 Oct 2012 14:16:57 +0200 Subject: [Freeipa-devel] [PATCH] 322 Fix CA CRL migration crash in ipa-upgradeconfig In-Reply-To: <5075664D.4010606@redhat.com> References: <50755667.5020909@redhat.com> <5075664D.4010606@redhat.com> Message-ID: <50756739.8000805@redhat.com> On 10/10/2012 02:13 PM, Petr Viktorin wrote: > On 10/10/2012 01:05 PM, Martin Kosek wrote: >> CRL migrate procedure did not check if a CA was actually configured >> on an updated master/replica. This caused ipa-upgradeconfig to >> crash on replicas without a CA. >> >> Make sure that CRL migrate procedure is not run when CA is not >> configured on given master. Also add few try..except clauses to >> make the procedure more robust. There is also a small refactoring of >> " is not configured" log messages, so that they have matching >> log level and message. >> >> dogtag.py constants were updated to have a correct path to new CRL >> directory on Fedora 18 (dogtag 10). >> >> https://fedorahosted.org/freeipa/ticket/3159 >> > > ACK, I no longer get the upgrade errors. > Pushed to master, ipa-3-0. Martin From sbose at redhat.com Wed Oct 10 12:31:04 2012 From: sbose at redhat.com (Sumit Bose) Date: Wed, 10 Oct 2012 14:31:04 +0200 Subject: [Freeipa-devel] [PATCH] 0086 Make sure samba{, 4}-winbind-krb5-locator package is not installed when trusts are in use In-Reply-To: <20121010090406.GM17454@redhat.com> References: <20121010074930.GI17454@redhat.com> <20121010082432.GL17454@redhat.com> <20121010090406.GM17454@redhat.com> Message-ID: <20121010123104.GF2134@localhost.localdomain> On Wed, Oct 10, 2012 at 12:04:06PM +0300, Alexander Bokovoy wrote: > On Wed, 10 Oct 2012, Alexander Bokovoy wrote: > >On Wed, 10 Oct 2012, Alexander Bokovoy wrote: > >>Hi, > >> > >>Since use of winbind on FreeIPA server that is configured with trusts is > >>conflicting with krb5 locator based on winbind, make sure there is > >>conflict that will force removing samba{,4}-winbind-krb5-locator package > >>when -server-trust-ad subpackage is installed. > >> > >>Please note that since feature-wise the two packages would be > >>conflicting in use, one has to play tricks with rpm to enforce > >>automatic removal of the samba{,4}-winbind-krb5-locator with Obsoletes: > >>in addtion to Conflicts: tag. This allows to ensure the two packages > >>never installed together: > >> > >>Conflicts: tag would prevent installing samba{,4}-winbind-krb5-locator after > >>freeipa-server-trust-ad subpackage is installed. > >> > >>Obsoletes: tag would force removal of samba{,4}-winbind-krb5-locator > >>during the install of freeipa-server-trust-ad. > >Unfortunately, the side-effect of the Obsoletes: tag is that > >freeipa-server-trust-ad would always be selected from the repository > >whenever one wants to install samba{,4}-winbind-krb5-locator, so this > >approach does not work. > > > >We can keep pure Conflicts: tags because they would prevent co-install > >of the packages. They alone would not be able to provide way to solve > >conflicts. > > > >I'm working on a bit more complex variant with alternatives. > New patch attached. I verified that it works but in order to make it > useful, samba{,4} package needs to be updated to include alternatives > for winbind_krb5_locator.so plugin. Working on that now. > > -- > / Alexander Bokovoy it works for me as well, so ACK. But I think we should add some minimal version to 'Requires: samba4' as well to make sure that it will work with the installed samba version. Shall we add this with a second patch later when the packages are available or hold the whole patch? bye, Sumit From abokovoy at redhat.com Wed Oct 10 12:40:17 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 10 Oct 2012 15:40:17 +0300 Subject: [Freeipa-devel] [PATCH] 0086 Make sure samba{, 4}-winbind-krb5-locator package is not installed when trusts are in use In-Reply-To: <20121010123104.GF2134@localhost.localdomain> References: <20121010074930.GI17454@redhat.com> <20121010082432.GL17454@redhat.com> <20121010090406.GM17454@redhat.com> <20121010123104.GF2134@localhost.localdomain> Message-ID: <20121010124017.GV17454@redhat.com> On Wed, 10 Oct 2012, Sumit Bose wrote: >On Wed, Oct 10, 2012 at 12:04:06PM +0300, Alexander Bokovoy wrote: >> On Wed, 10 Oct 2012, Alexander Bokovoy wrote: >> >On Wed, 10 Oct 2012, Alexander Bokovoy wrote: >> >>Hi, >> >> >> >>Since use of winbind on FreeIPA server that is configured with trusts is >> >>conflicting with krb5 locator based on winbind, make sure there is >> >>conflict that will force removing samba{,4}-winbind-krb5-locator package >> >>when -server-trust-ad subpackage is installed. >> >> >> >>Please note that since feature-wise the two packages would be >> >>conflicting in use, one has to play tricks with rpm to enforce >> >>automatic removal of the samba{,4}-winbind-krb5-locator with Obsoletes: >> >>in addtion to Conflicts: tag. This allows to ensure the two packages >> >>never installed together: >> >> >> >>Conflicts: tag would prevent installing samba{,4}-winbind-krb5-locator after >> >>freeipa-server-trust-ad subpackage is installed. >> >> >> >>Obsoletes: tag would force removal of samba{,4}-winbind-krb5-locator >> >>during the install of freeipa-server-trust-ad. >> >Unfortunately, the side-effect of the Obsoletes: tag is that >> >freeipa-server-trust-ad would always be selected from the repository >> >whenever one wants to install samba{,4}-winbind-krb5-locator, so this >> >approach does not work. >> > >> >We can keep pure Conflicts: tags because they would prevent co-install >> >of the packages. They alone would not be able to provide way to solve >> >conflicts. >> > >> >I'm working on a bit more complex variant with alternatives. >> New patch attached. I verified that it works but in order to make it >> useful, samba{,4} package needs to be updated to include alternatives >> for winbind_krb5_locator.so plugin. Working on that now. >> >> -- >> / Alexander Bokovoy > >it works for me as well, so ACK. But I think we should add some minimal version >to 'Requires: samba4' as well to make sure that it will work with the >installed samba version. Shall we add this with a second patch later >when the packages are available or hold the whole patch? Since alternatives do not change the target if it is not a symlink, we can safely make a second patch once Andreas makes new packages available. -- / Alexander Bokovoy From mkosek at redhat.com Wed Oct 10 12:53:58 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 10 Oct 2012 14:53:58 +0200 Subject: [Freeipa-devel] [PATCH] 0088 Fix typo in the documentation for trusts: RID for Domain Admins is -512 In-Reply-To: <20121010094047.GB2134@localhost.localdomain> References: <20121010075218.GK17454@redhat.com> <20121010094047.GB2134@localhost.localdomain> Message-ID: <50756FE6.60307@redhat.com> On 10/10/2012 11:40 AM, Sumit Bose wrote: > On Wed, Oct 10, 2012 at 10:52:18AM +0300, Alexander Bokovoy wrote: >> Hi, >> >> Domain Admins RID is -512, not -513. Fix the documentation text. >> >> >> -- >> / Alexander Bokovoy > > ACK > > bye, > Sumit > Pushed to master, ipa-3-0. Martin From rcritten at redhat.com Wed Oct 10 13:03:20 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 10 Oct 2012 09:03:20 -0400 Subject: [Freeipa-devel] [PATCH] 1051 Fix CS replica management In-Reply-To: <50754CAE.3070006@redhat.com> References: <5040F7DA.5020606@redhat.com> <505AF524.5050405@redhat.com> <505B5490.80303@redhat.com> <5072ED4C.4070604@redhat.com> <5073D8CC.1040505@redhat.com> <50747B87.6010309@redhat.com> <50754CAE.3070006@redhat.com> Message-ID: <50757218.4090904@redhat.com> Jan Cholasta wrote: > On 9.10.2012 21:31, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On 10/08/2012 05:12 PM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 20.9.2012 19:38, Rob Crittenden wrote: >>>>> Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> Dne 31.8.2012 19:43, Rob Crittenden napsal(a): >>>>>>> The naming in CS replication agreements is different from IPA >>>>>>> agreements, we have to live with what the create. The master side >>>>>>> should >>>>>>> be on the local side, replica1, not the remote. This required >>>>>>> reversing >>>>>>> a few master variables. >>>>>>> >>>>>>> Pass in the force flag to del_link. >>>>>>> >>>>>>> Do a better job of finding the agreements on each side. >>>>>>> >>>>>>> This should be ipa-csreplica-manage more in line with >>>>>>> ipa-replica-manage. >>>>>>> >>>>>>> rob >>>>>>> >>>>>> >>>>>> Rob, can you please rebase the patch on top of current master? There >>>>>> were some dogtag 10 related changes to ipa-csreplica-manage since you >>>>>> posted the patch. >>>>>> >>>>>> Honza >>>>>> >>>>> >>>>> I re-tested after the merge and found some problems with my initial >>>>> approach. The problem stems from the naming convention that dogtag >>>>> uses >>>>> when creating the initial agreements. It is hard to predict how things >>>>> were set up later so rather than trying to reconstruct the DN we >>>>> search >>>>> for it and pass it when deleting agreements. >>>>> >>>>> rob >>>> >>>> So far I have found this: >>>> >>>> * Deleting a "bridge" link that connects two "islands" of replicas >>>> works, but >>>> it should not (I was told that this is expected, as no complex graph >>>> algorithms >>>> are engaged to detect this kind of errors). >>> >>> Exactly, I hit this error when I was a similar Rob's patch for >>> ipa-replica-manage (ticket 2797). I used topology "A - B - C - D - E" >>> and I was >>> able to delete C. We may want to log an enhancement ticket for this. >>> >>> Martin >>> >> >> Right, and ipa-csreplica-manage doesn't even have the basic last_link >> checking code that ipa-replica-manage has, nor the ruv code. We decided >> to push that to a future release. >> >> This patch should fix up the basics. >> >> rob > > This fixes everything except I'm still unable to delete a master from a > master that is not directly connected to it. If this is OK, then ACK. > > Honza > The equivalent happens in ipa-replica-manage. I filed https://fedorahosted.org/freeipa/ticket/3160 to track this. Pushed to master and ipa-3-0 thanks rob From rcritten at redhat.com Wed Oct 10 13:10:32 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 10 Oct 2012 09:10:32 -0400 Subject: [Freeipa-devel] [PATCH] 0085 optimize SELinux setup in ipa-adtrust-install In-Reply-To: <20121008173419.GE17454@redhat.com> References: <20121008173419.GE17454@redhat.com> Message-ID: <507573C8.7030602@redhat.com> Alexander Bokovoy wrote: > Hi, > > this patch avoids reconfiguring SELinux if required variable is already > enabled. This would save you couple minutes on re-run of > ipa-adtrust-install. > > No ticket for it yet and the patch might wait until 3.0.1 but > "I had enogh patience" :) I think we need a set of generic set/unset functions. I got a patch nacked for the same reason :-( It gets a little complex because we need to save or restore the current state as well and only attempt the setsebool if the state actually changed, and if we do end up calling setsebool, execute it only once if possible. My ticket is 2934 if you want to reference it. thanks rob From tbabej at redhat.com Wed Oct 10 13:30:35 2012 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 10 Oct 2012 15:30:35 +0200 Subject: [Freeipa-devel] [PATCH 0016] Adds port to connection error message in ipa-client-install In-Reply-To: <506D519E.8090409@redhat.com> References: <5062FD9A.7060802@redhat.com> <50635847.5070602@redhat.com> <5069C48B.8050104@redhat.com> <506B36FF.5050303@redhat.com> <506C3E46.20600@redhat.com> <506C4428.9090903@redhat.com> <506C7575.20106@redhat.com> <506D519E.8090409@redhat.com> Message-ID: <5075787B.6000201@redhat.com> On 10/04/2012 11:06 AM, Tomas Babej wrote: > On 10/03/2012 07:27 PM, Rob Crittenden wrote: >> Tomas Babej wrote: >>> On 10/03/2012 03:31 PM, Tomas Babej wrote: >>>> On 10/02/2012 08:48 PM, Rob Crittenden wrote: >>>>> Tomas Babej wrote: >>>>>> On 09/26/2012 09:32 PM, Rob Crittenden wrote: >>>>>>> Tomas Babej wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Connection error message in ipa-client-install now warns the user >>>>>>>> about the need of opening 389 port for directory server. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/2816 >>>>>>>> >>>>>>>> I think this can be pushed as a one-liner. >>>>>>> >>>>>>> I think we should list all ports that are required for client >>>>>>> enrollment. >>>>>>> >>>>>>> From my calculations we need at a minimum tcp ports 80 and 389, >>>>>>> either >>>>>>> or both udp/tcp for port 88 and if NTP is enabled 123 udp for >>>>>>> enrollment alone. The NTP failure won't cause enrollment to fail >>>>>>> though, so we may be able to skip that. >>>>>>> >>>>>>> Similarly 464 should be enabled but we don't use it during >>>>>>> enrollment. >>>>>>> >>>>>>> rob >>>>>> I improved the error message. Please check if there are any issues. >>>>>> >>>>>> Thanks >>>>>> >>>>>> Tomas >>>>> >>>>> This only works if port 389 is blocked, not 88 or 80. >>>>> >>>>> rob >>>> I tested and added the port configuration info message at the >>>> appropriate >>>> places for TCP 80, 88, 389 ports. I also added the info message at the >>>> end >>>> of installation output. Please consider if you agree with this >>>> approach. >>>> >>>> Tomas >>> I reworded the commit message, due to the scope of changes made >>> since the first revision of the patch. >>> >>> Tomas >> >> Works a lot better, just a few more suggestions: >> >> 1. When we fail to retrieve the CA from the remote server we log it >> but don't print it. I think this would make it clearer why we think >> this isn't an IPA server. >> >> 2. Do we need to print the ports message at the end? If it gets this >> far then at least ports 80, 88 and 389 are open. >> >> I would suggest dropping the last message. I think we should also >> open a new ticket and do port checks on the things we need so we can >> confirm it up front instead of one-at-a-time. >> >> rob > 1.) Done. > 2.) Well I had a feeling it was not really necessary too - it adds a > lot to the output of the installation, but the user wouldn't be > informed about the need of opening 464 port. However, your proposed > ticket should solve this issue, and will give more specific > information rather than a general advice. See more: > > https://fedorahosted.org/freeipa/ticket/3138 > > I suggest opening a similar ticket for ipa-server-install, at the end > we print a general info message about which ports should be open for > IPA Server to work properly. Re-using the work done in ticket 3138, we > could rather check which particular ports are not opened and therefore > give the user more specific information too. > > Tomas Patch now attached, sorry. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0016-5-Notify-user-about-necessary-ports-in-ipa-client-inst.patch Type: text/x-patch Size: 4836 bytes Desc: not available URL: From mkosek at redhat.com Wed Oct 10 13:33:54 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 10 Oct 2012 15:33:54 +0200 Subject: [Freeipa-devel] [PATCH] 1059 single CRL generator In-Reply-To: <5074A962.7010300@redhat.com> References: <506DB6A8.10504@redhat.com> <506EA171.20401@redhat.com> <50743822.1090306@redhat.com> <50744A25.8010504@redhat.com> <507472D5.4080406@redhat.com> <5074A962.7010300@redhat.com> Message-ID: <50757942.5080102@redhat.com> On 10/10/2012 12:46 AM, Rob Crittenden wrote: > Rob Crittenden wrote: >> Martin Kosek wrote: >>> On 10/09/2012 04:43 PM, Rob Crittenden wrote: >>>> Martin Kosek wrote: >>>>> On 10/04/2012 06:17 PM, Rob Crittenden wrote: >>>>>> This changes the way IPA generates CRLs for new installs only. >>>>>> >>>>>> The first master installed is configured as the CRL generator. An >>>>>> entry is >>>>>> added to cn=masters that designates it. >>>>>> >>>>>> When a replica is installed it queries this entry so it knows where >>>>>> to forward >>>>>> CRL requests. CRL files are not available on cloned CAs (so >>>>>> /ipa/crl will >>>>>> return not found). It is possible to get a CRL directly from the >>>>>> clone CA via >>>>>> http://:9180/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL >>>>>> >>>>>> >>>>>> rob >>>>> >>>>> I tested new IPA server + replica with your patch and the CRL was >>>>> now generated >>>>> only on the CRL master. I also tried OCSP (though this may not be >>>>> relevant) and >>>>> it worked for me too. >>>>> >>>>> 1) I do not understand the following block in set_crl_master(self, >>>>> suffix): >>>>> >>>>> + try: >>>>> + self.admin_conn.addEntry(entry) >>>>> + except ldap.ALREADY_EXISTS, e: >>>>> + root_logger.debug("failed to set CA as CRL generator") >>>>> + raise e >>>>> >>>>> - when we hit ldap.ALREADY_EXISTS, we are actually OK because cn=CRL >>>>> is set, >>>>> right? >>>>> - AFAIK, addEntry should return our errors, i.e. errors.DuplicateEntry >>>>> - s/raise e/raise/ >>>>> >>>>> I think you may have wanted to rather catch for more general LDAP >>>>> error and >>>>> then report a real error and not just a debug note. >>>>> >>>>> 2) In get_crl_master: >>>>> >>>>> + except Exception, e: >>>>> + root_logger.debug("Could not connect to the Directory >>>>> Server on >>>>> %s: %s" % (master_host, str(e))) >>>>> + raise e >>>>> >>>>> s/raise e/raise/ >>>>> >>>>> + except errors.NotFound, e: >>>>> + root_logger.debug("failed to find CA CRL generator") >>>>> + self.crl_master = None >>>>> >>>>> - e is actually not used, "except errors.NotFound" would be enough >>>>> >>>>> 3) Majorish issue I hit with the actual CRL publishing on our server >>>>> (F17). I >>>>> always get 403 Forbidden error when trying to download CRL from the >>>>> CRL master: >>>>> >>>>> # wget --ca-certificate /etc/ipa/ca.crt >>>>> https://`hostname`/ipa/crl/MasterCRL.bin >>>>> --2012-10-05 03:32:58-- >>>>> https://vm-120.idm.lab.bos.redhat.com/ipa/crl/MasterCRL.bin >>>>> Resolving vm-120.idm.lab.bos.redhat.com... 10.16.78.120 >>>>> Connecting to vm-120.idm.lab.bos.redhat.com|10.16.78.120|:443... >>>>> connected. >>>>> HTTP request sent, awaiting response... 403 Forbidden >>>>> 2012-10-05 03:32:58 ERROR 403: Forbidden. >>>>> >>>>> I tracked the problem down to too strict permission on /var/lib/pki-ca >>>>> directory which is being published by httpd which does not have >>>>> access to it: >>>>> >>>>> # ll /var/lib/pki-ca >>>>> >>>>> drwxrwx---. 11 pkiuser pkiuser 4096 Oct 5 03:00 pki-ca >>>>> >>>>> When I fixed the permission: >>>>> # chmod o+x /var/lib/pki-ca/ >>>>> >>>>> I was able to get pass the Forbidden error and actually retrieved >>>>> the CRL. >>>>> Adding Ade on CC list to follow on this permission issue. >>>>> >>>>> >>>>> I was thinking about usability of this new approach, we may want to >>>>> make user >>>>> life easier in a perspective of CRL master managing. I have following >>>>> enhancements in mind: >>>>> >>>>> - mark CRL master in ipa-replica-manage list, or >>>>> ipa-csreplica-manage list: >>>>> >>>>> # ipa-csreplica-manage list >>>>> Directory Manager password: >>>>> >>>>> vm-065.idm.lab.bos.redhat.com: master [CRL] >>>>> vm-120.idm.lab.bos.redhat.com: master >>>>> >>>>> - when removing master with CRL by "ipa-replica-manage del" we >>>>> should warn user >>>>> and inform him what he should do next to amend the situation. I am >>>>> thinking >>>>> about 2 new commands for ipa-csreplica-manage: >>>>> >>>>> * ipa-csreplica-manage crl-promote >>>>> - promote current master as the new CRL master, enable CRL >>>>> generation in >>>>> CS.cfg, mark master as the new CRL master in cn=masters >>>>> * ipa-csreplica-manage crl-update >>>>> - update CS.cfg of current CA replica and point >>>>> master.ca.agent.* to current >>>>> CRL master >>>>> >>>>> I can work on those enhancements if we agree on them. >>>>> >>>>> Martin >>>>> >>>> >>>> Andrew provided some feedback out-of-band and my solution was overly >>>> complex. >>>> Here is a much simpler patch which does away with all the hand-waving >>>> around >>>> knowing who the CRL generator is. >>>> >>>> rob >>> >>> This looks OK code-wise, I will wait for dogtag guys to confirm that >>> this is >>> the right approach. >>> >>> Btw. I think we may want to file a RFE to implement some command to >>> promote a >>> replica to CRL master (like "ipa-csreplica-manage crl-promote" proposed >>> earlier). Users may want to promote a replica when the master crashes >>> or is to >>> be replaced. Some way to migrate CRL list (if not replicated already) >>> to the >>> promoted replica would also be needed. >>> >>> Martin >>> >> >> Andrew suggested I specify that we do not monitor cloned revocations on >> the server not generating CRLs, so I added that. >> >> The last question is what we do about redirecting users on the >> non-generating masters. >> >> We can do it easily with a line like this in Apache: >> >> RewriteRule ^/ipa/crl/MasterCRL.bin >> https://$FQDN:9444/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL >> [L,R=301,NC] >> >> The tricky part is writing this properly. The CA can be added >> post-install so I don't think simply adding this to ipa-rewrite.conf >> will work well. Is adding another template configuration file for Apache >> overkill? >> >> rob > > Here is my WIP for auto-configuring redirect on clones. It works ok for me and > isn't too invasive IMHO. The basic idea is to allow proxying of the getCRL > servlet and redirect to that on requests to the clone server. > > Browsing won't work, but you can fetch the MasterCRL.bin with: > > # wget --ca-certificate=/etc/ipa/ca.crt > http://replica.example.com/ipa/crl/MasterCRL.bin > > diff --git a/install/conf/ipa-pki-proxy.conf b/install/conf/ipa-pki-proxy.conf > index 20c0921..8c4f3a9 100644 > --- a/install/conf/ipa-pki-proxy.conf > +++ b/install/conf/ipa-pki-proxy.conf > @@ -3,7 +3,7 @@ > ProxyRequests Off > > # matches for ee port > - "^/ca/ee/ca/checkRequest|^/ca/ee/ca/getCertChain|^/ca/ee/ca/getTokenInfo|^/ca/ee/ca/tokenAuthenticate|^/ca/ocsp|^/ca/ee/ca/updateNumberRange"> > > + "^/ca/ee/ca/checkRequest|^/ca/ee/ca/getCertChain|^/ca/ee/ca/getTokenInfo|^/ca/ee/ca/tokenAuthenticate|^/ca/ocsp|^/ca/ee/ca/updateNumberRange|^/ca/ee/ca/getCRL"> > > NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate > NSSVerifyClient none > ProxyPassMatch ajp://localhost:$DOGTAG_PORT > @@ -25,3 +25,6 @@ ProxyRequests Off > ProxyPassMatch ajp://localhost:$DOGTAG_PORT > ProxyPassReverse ajp://localhost:$DOGTAG_PORT > > + > +# Only enable this on servers that are not generating a CRL > +${CLONE}RewriteRule ^/ipa/crl/MasterCRL.bin > https://$FQDN/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL [L,R=301,NC] > diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py > index 0ac895e..aabbba3 100644 > --- a/ipaserver/install/cainstance.py > +++ b/ipaserver/install/cainstance.py > @@ -1304,7 +1304,11 @@ class CAInstance(service.Service): > > def __http_proxy(self): > template_filename = ipautil.SHARE_DIR + "ipa-pki-proxy.conf" > - sub_dict = dict(DOGTAG_PORT=self.dogtag_constants.AJP_PORT) > + sub_dict = dict( > + DOGTAG_PORT=self.dogtag_constants.AJP_PORT, > + CLONE='' if self.clone else '#', > + FQDN=self.fqdn, > + ) > template = ipautil.template_file(template_filename, sub_dict) > with open(HTTPD_CONFD + "ipa-pki-proxy.conf", "w") as fd: > fd.write(template) The approach looks OK, just please do not forget to also add CLONE to sub_dict in ipa-upgradeconfig, it just crashed when I was testing the change: CRL tree already moved File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 614, in run_script return_value = main_function() File "/sbin/ipa-upgradeconfig", line 601, in main upgrade(sub_dict, "/etc/httpd/conf.d/ipa-pki-proxy.conf", ipautil.SHARE_DIR + "ipa-pki-proxy.conf", add=True) File "/sbin/ipa-upgradeconfig", line 187, in upgrade update_conf(sub_dict, filename, template) File "/sbin/ipa-upgradeconfig", line 110, in update_conf template = ipautil.template_file(template_filename, sub_dict) File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 228, in template_file return template_str(f.read(), vars) File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 215, in template_str val = string.Template(txt).substitute(vars) File "/usr/lib64/python2.7/string.py", line 172, in substitute return self.pattern.sub(convert, self.template) File "/usr/lib64/python2.7/string.py", line 162, in convert val = mapping[named] The ipa-upgradeconfig command failed, exception: KeyError: 'CLONE' Unexpected error KeyError: 'CLONE' Martin From mkosek at redhat.com Wed Oct 10 13:37:33 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 10 Oct 2012 15:37:33 +0200 Subject: [Freeipa-devel] [PATCHES] 0086-0088 Generate Firefox extension on upgrades In-Reply-To: <5075381F.7020804@redhat.com> References: <50743FCE.5050307@redhat.com> <50744226.90007@redhat.com> <50744A59.2050308@redhat.com> <5075381F.7020804@redhat.com> Message-ID: <50757A1D.40301@redhat.com> On 10/10/2012 10:55 AM, Petr Viktorin wrote: > On 10/09/2012 06:01 PM, Petr Vobornik wrote: >> On 10/09/2012 05:26 PM, Petr Viktorin wrote: >>> On 10/09/2012 05:16 PM, Petr Viktorin wrote: >>>> https://fedorahosted.org/freeipa/ticket/3150 >>>> >>>> >>>> Patch 0086: >>>> I found an old unused function while working on this, the patch >>>> removes it. >>>> >>>> Patch 0087: >>>> Replica files generated on older masters don't contain the Firefox >>>> extension files. Skip installing them in this case. >>>> >>>> Patch 0088: >>>> Servers upgraded from IPA 2.2 need the Firefox extension installed. This >>>> is done in ipa-upgradeconfig if they're missing. >>>> I made the setup_firefox_extension method independent on the >>>> httpinstance state (which is mostly set in create_instance). >>>> Similarly, the files are installed ipa-replica-install if they're >>>> missing (i.e. skipped by the previous patch). >>>> If the Signing-Cert is not on this master, create an unsigned extension >>>> using the "zip" command. I needed to add Popen's `cwd` argument to >>>> ipautil.run() to get the right filenames out of zip. >>>> >>>> The patches add "copy_template_file" and "copy_file_if_exists" utilities >>>> I've written for some of my WIP patches, expect me to use them more when >>>> I get time to work on the installer code. >>>> >>> >>> In my previous mail I've attached an old version of patch 88. Please use >>> this one. Sorry! >>> >>> >> >> nack >> >> 1) patch 83-01 doesn't apply. > > There were conflicts with recent CRL and audit cert renewal patches. Rebased. > >> 2) When pwd is supplied to setup_firefox_extension `db = >> certs.CertDB(realm, subject_base=subject_base)` is skipped and therefore >> `db.has_nickname` will fail. > > Thanks for the catch, fixed. > I tried different installation and upgrade procedures and it seems to work fine. I have found few minorish issues when inspecting the code: Patch 0086-01 looks OK. Patch 0087-01 looks OK. Patch 0088-02: 1) In http.setup_firefox_extension() - why do you require subject_base? AFAIK, it is not needed for the signtool and you do not have it right anyway: a) You use 0=$REALM, i.e. *zero*=$REALM, which would not be a valid subject base anyway b) Even when it would be used, a correct subject base is in IPA config (it does not have to be O=$REALM. Thus, I would not require it at all, it would safe us some code and potential confusion if subject base would be actually used. 2) [nitpick] In http.setup_firefox_extension() I would not format the string before logging: + root_logger.info( + '%s exists, skipping install of Firefox extension' % + target_fname) A desired pattern would be to pass formatting parameters as standard function parameters, it may save us few cycles in some situations. 3) In httpinstance.py, I would like to see an absolute path to zip executable. It is a common pattern in IPA and more secure: + ipautil.run(['zip', '-r', target_fname] + filenames, cwd=extdir) Martin From rcritten at redhat.com Wed Oct 10 14:12:46 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 10 Oct 2012 10:12:46 -0400 Subject: [Freeipa-devel] [PATCH] 1059 single CRL generator In-Reply-To: <50757942.5080102@redhat.com> References: <506DB6A8.10504@redhat.com> <506EA171.20401@redhat.com> <50743822.1090306@redhat.com> <50744A25.8010504@redhat.com> <507472D5.4080406@redhat.com> <5074A962.7010300@redhat.com> <50757942.5080102@redhat.com> Message-ID: <5075825E.8070809@redhat.com> Martin Kosek wrote: > On 10/10/2012 12:46 AM, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> Martin Kosek wrote: >>>> On 10/09/2012 04:43 PM, Rob Crittenden wrote: >>>>> Martin Kosek wrote: >>>>>> On 10/04/2012 06:17 PM, Rob Crittenden wrote: >>>>>>> This changes the way IPA generates CRLs for new installs only. >>>>>>> >>>>>>> The first master installed is configured as the CRL generator. An >>>>>>> entry is >>>>>>> added to cn=masters that designates it. >>>>>>> >>>>>>> When a replica is installed it queries this entry so it knows where >>>>>>> to forward >>>>>>> CRL requests. CRL files are not available on cloned CAs (so >>>>>>> /ipa/crl will >>>>>>> return not found). It is possible to get a CRL directly from the >>>>>>> clone CA via >>>>>>> http://:9180/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL >>>>>>> >>>>>>> >>>>>>> rob >>>>>> >>>>>> I tested new IPA server + replica with your patch and the CRL was >>>>>> now generated >>>>>> only on the CRL master. I also tried OCSP (though this may not be >>>>>> relevant) and >>>>>> it worked for me too. >>>>>> >>>>>> 1) I do not understand the following block in set_crl_master(self, >>>>>> suffix): >>>>>> >>>>>> + try: >>>>>> + self.admin_conn.addEntry(entry) >>>>>> + except ldap.ALREADY_EXISTS, e: >>>>>> + root_logger.debug("failed to set CA as CRL generator") >>>>>> + raise e >>>>>> >>>>>> - when we hit ldap.ALREADY_EXISTS, we are actually OK because cn=CRL >>>>>> is set, >>>>>> right? >>>>>> - AFAIK, addEntry should return our errors, i.e. errors.DuplicateEntry >>>>>> - s/raise e/raise/ >>>>>> >>>>>> I think you may have wanted to rather catch for more general LDAP >>>>>> error and >>>>>> then report a real error and not just a debug note. >>>>>> >>>>>> 2) In get_crl_master: >>>>>> >>>>>> + except Exception, e: >>>>>> + root_logger.debug("Could not connect to the Directory >>>>>> Server on >>>>>> %s: %s" % (master_host, str(e))) >>>>>> + raise e >>>>>> >>>>>> s/raise e/raise/ >>>>>> >>>>>> + except errors.NotFound, e: >>>>>> + root_logger.debug("failed to find CA CRL generator") >>>>>> + self.crl_master = None >>>>>> >>>>>> - e is actually not used, "except errors.NotFound" would be enough >>>>>> >>>>>> 3) Majorish issue I hit with the actual CRL publishing on our server >>>>>> (F17). I >>>>>> always get 403 Forbidden error when trying to download CRL from the >>>>>> CRL master: >>>>>> >>>>>> # wget --ca-certificate /etc/ipa/ca.crt >>>>>> https://`hostname`/ipa/crl/MasterCRL.bin >>>>>> --2012-10-05 03:32:58-- >>>>>> https://vm-120.idm.lab.bos.redhat.com/ipa/crl/MasterCRL.bin >>>>>> Resolving vm-120.idm.lab.bos.redhat.com... 10.16.78.120 >>>>>> Connecting to vm-120.idm.lab.bos.redhat.com|10.16.78.120|:443... >>>>>> connected. >>>>>> HTTP request sent, awaiting response... 403 Forbidden >>>>>> 2012-10-05 03:32:58 ERROR 403: Forbidden. >>>>>> >>>>>> I tracked the problem down to too strict permission on /var/lib/pki-ca >>>>>> directory which is being published by httpd which does not have >>>>>> access to it: >>>>>> >>>>>> # ll /var/lib/pki-ca >>>>>> >>>>>> drwxrwx---. 11 pkiuser pkiuser 4096 Oct 5 03:00 pki-ca >>>>>> >>>>>> When I fixed the permission: >>>>>> # chmod o+x /var/lib/pki-ca/ >>>>>> >>>>>> I was able to get pass the Forbidden error and actually retrieved >>>>>> the CRL. >>>>>> Adding Ade on CC list to follow on this permission issue. >>>>>> >>>>>> >>>>>> I was thinking about usability of this new approach, we may want to >>>>>> make user >>>>>> life easier in a perspective of CRL master managing. I have following >>>>>> enhancements in mind: >>>>>> >>>>>> - mark CRL master in ipa-replica-manage list, or >>>>>> ipa-csreplica-manage list: >>>>>> >>>>>> # ipa-csreplica-manage list >>>>>> Directory Manager password: >>>>>> >>>>>> vm-065.idm.lab.bos.redhat.com: master [CRL] >>>>>> vm-120.idm.lab.bos.redhat.com: master >>>>>> >>>>>> - when removing master with CRL by "ipa-replica-manage del" we >>>>>> should warn user >>>>>> and inform him what he should do next to amend the situation. I am >>>>>> thinking >>>>>> about 2 new commands for ipa-csreplica-manage: >>>>>> >>>>>> * ipa-csreplica-manage crl-promote >>>>>> - promote current master as the new CRL master, enable CRL >>>>>> generation in >>>>>> CS.cfg, mark master as the new CRL master in cn=masters >>>>>> * ipa-csreplica-manage crl-update >>>>>> - update CS.cfg of current CA replica and point >>>>>> master.ca.agent.* to current >>>>>> CRL master >>>>>> >>>>>> I can work on those enhancements if we agree on them. >>>>>> >>>>>> Martin >>>>>> >>>>> >>>>> Andrew provided some feedback out-of-band and my solution was overly >>>>> complex. >>>>> Here is a much simpler patch which does away with all the hand-waving >>>>> around >>>>> knowing who the CRL generator is. >>>>> >>>>> rob >>>> >>>> This looks OK code-wise, I will wait for dogtag guys to confirm that >>>> this is >>>> the right approach. >>>> >>>> Btw. I think we may want to file a RFE to implement some command to >>>> promote a >>>> replica to CRL master (like "ipa-csreplica-manage crl-promote" proposed >>>> earlier). Users may want to promote a replica when the master crashes >>>> or is to >>>> be replaced. Some way to migrate CRL list (if not replicated already) >>>> to the >>>> promoted replica would also be needed. >>>> >>>> Martin >>>> >>> >>> Andrew suggested I specify that we do not monitor cloned revocations on >>> the server not generating CRLs, so I added that. >>> >>> The last question is what we do about redirecting users on the >>> non-generating masters. >>> >>> We can do it easily with a line like this in Apache: >>> >>> RewriteRule ^/ipa/crl/MasterCRL.bin >>> https://$FQDN:9444/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL >>> [L,R=301,NC] >>> >>> The tricky part is writing this properly. The CA can be added >>> post-install so I don't think simply adding this to ipa-rewrite.conf >>> will work well. Is adding another template configuration file for Apache >>> overkill? >>> >>> rob >> >> Here is my WIP for auto-configuring redirect on clones. It works ok for me and >> isn't too invasive IMHO. The basic idea is to allow proxying of the getCRL >> servlet and redirect to that on requests to the clone server. >> >> Browsing won't work, but you can fetch the MasterCRL.bin with: >> >> # wget --ca-certificate=/etc/ipa/ca.crt >> http://replica.example.com/ipa/crl/MasterCRL.bin >> >> diff --git a/install/conf/ipa-pki-proxy.conf b/install/conf/ipa-pki-proxy.conf >> index 20c0921..8c4f3a9 100644 >> --- a/install/conf/ipa-pki-proxy.conf >> +++ b/install/conf/ipa-pki-proxy.conf >> @@ -3,7 +3,7 @@ >> ProxyRequests Off >> >> # matches for ee port >> -> "^/ca/ee/ca/checkRequest|^/ca/ee/ca/getCertChain|^/ca/ee/ca/getTokenInfo|^/ca/ee/ca/tokenAuthenticate|^/ca/ocsp|^/ca/ee/ca/updateNumberRange"> >> >> +> "^/ca/ee/ca/checkRequest|^/ca/ee/ca/getCertChain|^/ca/ee/ca/getTokenInfo|^/ca/ee/ca/tokenAuthenticate|^/ca/ocsp|^/ca/ee/ca/updateNumberRange|^/ca/ee/ca/getCRL"> >> >> NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate >> NSSVerifyClient none >> ProxyPassMatch ajp://localhost:$DOGTAG_PORT >> @@ -25,3 +25,6 @@ ProxyRequests Off >> ProxyPassMatch ajp://localhost:$DOGTAG_PORT >> ProxyPassReverse ajp://localhost:$DOGTAG_PORT >> >> + >> +# Only enable this on servers that are not generating a CRL >> +${CLONE}RewriteRule ^/ipa/crl/MasterCRL.bin >> https://$FQDN/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL [L,R=301,NC] >> diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py >> index 0ac895e..aabbba3 100644 >> --- a/ipaserver/install/cainstance.py >> +++ b/ipaserver/install/cainstance.py >> @@ -1304,7 +1304,11 @@ class CAInstance(service.Service): >> >> def __http_proxy(self): >> template_filename = ipautil.SHARE_DIR + "ipa-pki-proxy.conf" >> - sub_dict = dict(DOGTAG_PORT=self.dogtag_constants.AJP_PORT) >> + sub_dict = dict( >> + DOGTAG_PORT=self.dogtag_constants.AJP_PORT, >> + CLONE='' if self.clone else '#', >> + FQDN=self.fqdn, >> + ) >> template = ipautil.template_file(template_filename, sub_dict) >> with open(HTTPD_CONFD + "ipa-pki-proxy.conf", "w") as fd: >> fd.write(template) > > The approach looks OK, just please do not forget to also add CLONE to sub_dict > in ipa-upgradeconfig, it just crashed when I was testing the change: > > CRL tree already moved > File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", > line 614, in run_script > return_value = main_function() > > File "/sbin/ipa-upgradeconfig", line 601, in main > upgrade(sub_dict, "/etc/httpd/conf.d/ipa-pki-proxy.conf", ipautil.SHARE_DIR > + "ipa-pki-proxy.conf", add=True) > > File "/sbin/ipa-upgradeconfig", line 187, in upgrade > update_conf(sub_dict, filename, template) > > File "/sbin/ipa-upgradeconfig", line 110, in update_conf > template = ipautil.template_file(template_filename, sub_dict) > > File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 228, in > template_file > return template_str(f.read(), vars) > > File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 215, in > template_str > val = string.Template(txt).substitute(vars) > > File "/usr/lib64/python2.7/string.py", line 172, in substitute > return self.pattern.sub(convert, self.template) > > File "/usr/lib64/python2.7/string.py", line 162, in convert > val = mapping[named] > > The ipa-upgradeconfig command failed, exception: KeyError: 'CLONE' > Unexpected error > KeyError: 'CLONE' > > Martin > Fixed and merged into a single patch. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1059-4-crl.patch Type: text/x-diff Size: 4848 bytes Desc: not available URL: From rcritten at redhat.com Wed Oct 10 14:15:54 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 10 Oct 2012 10:15:54 -0400 Subject: [Freeipa-devel] [PATCH 0016] Adds port to connection error message in ipa-client-install In-Reply-To: <5075787B.6000201@redhat.com> References: <5062FD9A.7060802@redhat.com> <50635847.5070602@redhat.com> <5069C48B.8050104@redhat.com> <506B36FF.5050303@redhat.com> <506C3E46.20600@redhat.com> <506C4428.9090903@redhat.com> <506C7575.20106@redhat.com> <506D519E.8090409@redhat.com> <5075787B.6000201@redhat.com> Message-ID: <5075831A.5020301@redhat.com> Tomas Babej wrote: > On 10/04/2012 11:06 AM, Tomas Babej wrote: >> On 10/03/2012 07:27 PM, Rob Crittenden wrote: >>> Tomas Babej wrote: >>>> On 10/03/2012 03:31 PM, Tomas Babej wrote: >>>>> On 10/02/2012 08:48 PM, Rob Crittenden wrote: >>>>>> Tomas Babej wrote: >>>>>>> On 09/26/2012 09:32 PM, Rob Crittenden wrote: >>>>>>>> Tomas Babej wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Connection error message in ipa-client-install now warns the user >>>>>>>>> about the need of opening 389 port for directory server. >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/2816 >>>>>>>>> >>>>>>>>> I think this can be pushed as a one-liner. >>>>>>>> >>>>>>>> I think we should list all ports that are required for client >>>>>>>> enrollment. >>>>>>>> >>>>>>>> From my calculations we need at a minimum tcp ports 80 and 389, >>>>>>>> either >>>>>>>> or both udp/tcp for port 88 and if NTP is enabled 123 udp for >>>>>>>> enrollment alone. The NTP failure won't cause enrollment to fail >>>>>>>> though, so we may be able to skip that. >>>>>>>> >>>>>>>> Similarly 464 should be enabled but we don't use it during >>>>>>>> enrollment. >>>>>>>> >>>>>>>> rob >>>>>>> I improved the error message. Please check if there are any issues. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Tomas >>>>>> >>>>>> This only works if port 389 is blocked, not 88 or 80. >>>>>> >>>>>> rob >>>>> I tested and added the port configuration info message at the >>>>> appropriate >>>>> places for TCP 80, 88, 389 ports. I also added the info message at the >>>>> end >>>>> of installation output. Please consider if you agree with this >>>>> approach. >>>>> >>>>> Tomas >>>> I reworded the commit message, due to the scope of changes made >>>> since the first revision of the patch. >>>> >>>> Tomas >>> >>> Works a lot better, just a few more suggestions: >>> >>> 1. When we fail to retrieve the CA from the remote server we log it >>> but don't print it. I think this would make it clearer why we think >>> this isn't an IPA server. >>> >>> 2. Do we need to print the ports message at the end? If it gets this >>> far then at least ports 80, 88 and 389 are open. >>> >>> I would suggest dropping the last message. I think we should also >>> open a new ticket and do port checks on the things we need so we can >>> confirm it up front instead of one-at-a-time. >>> >>> rob >> 1.) Done. >> 2.) Well I had a feeling it was not really necessary too - it adds a >> lot to the output of the installation, but the user wouldn't be >> informed about the need of opening 464 port. However, your proposed >> ticket should solve this issue, and will give more specific >> information rather than a general advice. See more: >> >> https://fedorahosted.org/freeipa/ticket/3138 >> >> I suggest opening a similar ticket for ipa-server-install, at the end >> we print a general info message about which ports should be open for >> IPA Server to work properly. Re-using the work done in ticket 3138, we >> could rather check which particular ports are not opened and therefore >> give the user more specific information too. >> >> Tomas > > Patch now attached, sorry. > > Tomas ACK, pushed to master and ipa-3-0 rob From pviktori at redhat.com Wed Oct 10 14:23:41 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 10 Oct 2012 16:23:41 +0200 Subject: [Freeipa-devel] [PATCHES] 0086-0088 Generate Firefox extension on upgrades In-Reply-To: <50757A1D.40301@redhat.com> References: <50743FCE.5050307@redhat.com> <50744226.90007@redhat.com> <50744A59.2050308@redhat.com> <5075381F.7020804@redhat.com> <50757A1D.40301@redhat.com> Message-ID: <507584ED.1070106@redhat.com> On 10/10/2012 03:37 PM, Martin Kosek wrote: > On 10/10/2012 10:55 AM, Petr Viktorin wrote: >> On 10/09/2012 06:01 PM, Petr Vobornik wrote: >>> On 10/09/2012 05:26 PM, Petr Viktorin wrote: >>>> On 10/09/2012 05:16 PM, Petr Viktorin wrote: >>>>> https://fedorahosted.org/freeipa/ticket/3150 >>>>> >>>>> >>>>> Patch 0086: >>>>> I found an old unused function while working on this, the patch >>>>> removes it. >>>>> >>>>> Patch 0087: >>>>> Replica files generated on older masters don't contain the Firefox >>>>> extension files. Skip installing them in this case. >>>>> >>>>> Patch 0088: >>>>> Servers upgraded from IPA 2.2 need the Firefox extension installed. This >>>>> is done in ipa-upgradeconfig if they're missing. >>>>> I made the setup_firefox_extension method independent on the >>>>> httpinstance state (which is mostly set in create_instance). >>>>> Similarly, the files are installed ipa-replica-install if they're >>>>> missing (i.e. skipped by the previous patch). >>>>> If the Signing-Cert is not on this master, create an unsigned extension >>>>> using the "zip" command. I needed to add Popen's `cwd` argument to >>>>> ipautil.run() to get the right filenames out of zip. >>>>> >>>>> The patches add "copy_template_file" and "copy_file_if_exists" utilities >>>>> I've written for some of my WIP patches, expect me to use them more when >>>>> I get time to work on the installer code. >>>>> >>>> >>>> In my previous mail I've attached an old version of patch 88. Please use >>>> this one. Sorry! >>>> >>>> >>> >>> nack >>> >>> 1) patch 83-01 doesn't apply. >> >> There were conflicts with recent CRL and audit cert renewal patches. Rebased. >> >>> 2) When pwd is supplied to setup_firefox_extension `db = >>> certs.CertDB(realm, subject_base=subject_base)` is skipped and therefore >>> `db.has_nickname` will fail. >> >> Thanks for the catch, fixed. >> > > I tried different installation and upgrade procedures and it seems to work > fine. I have found few minorish issues when inspecting the code: > > Patch 0086-01 looks OK. > > Patch 0087-01 looks OK. > > Patch 0088-02: > > 1) In http.setup_firefox_extension() - why do you require subject_base? AFAIK, > it is not needed for the signtool and you do not have it right anyway: > a) You use 0=$REALM, i.e. *zero*=$REALM, which would not be a valid subject > base anyway > b) Even when it would be used, a correct subject base is in IPA config (it > does not have to be O=$REALM. > > Thus, I would not require it at all, it would safe us some code and potential > confusion if subject base would be actually used. > > > 2) [nitpick] In http.setup_firefox_extension() I would not format the string > before logging: > > + root_logger.info( > + '%s exists, skipping install of Firefox extension' % > + target_fname) > > A desired pattern would be to pass formatting parameters as standard function > parameters, it may save us few cycles in some situations. > > > 3) In httpinstance.py, I would like to see an absolute path to zip executable. > It is a common pattern in IPA and more secure: > > + ipautil.run(['zip', '-r', target_fname] + filenames, cwd=extdir) > > > Martin > Thanks, fixed in attached patch. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0088-03-Create-Firefox-extension-on-upgrade-and-replica-inst.patch Type: text/x-patch Size: 8685 bytes Desc: not available URL: From mkosek at redhat.com Wed Oct 10 14:32:29 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 10 Oct 2012 16:32:29 +0200 Subject: [Freeipa-devel] [PATCH] 1059 single CRL generator In-Reply-To: <5075825E.8070809@redhat.com> References: <506DB6A8.10504@redhat.com> <506EA171.20401@redhat.com> <50743822.1090306@redhat.com> <50744A25.8010504@redhat.com> <507472D5.4080406@redhat.com> <5074A962.7010300@redhat.com> <50757942.5080102@redhat.com> <5075825E.8070809@redhat.com> Message-ID: <507586FD.4020905@redhat.com> On 10/10/2012 04:12 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> On 10/10/2012 12:46 AM, Rob Crittenden wrote: >>> Rob Crittenden wrote: >>>> Martin Kosek wrote: >>>>> On 10/09/2012 04:43 PM, Rob Crittenden wrote: >>>>>> Martin Kosek wrote: >>>>>>> On 10/04/2012 06:17 PM, Rob Crittenden wrote: >>>>>>>> This changes the way IPA generates CRLs for new installs only. >>>>>>>> >>>>>>>> The first master installed is configured as the CRL generator. An >>>>>>>> entry is >>>>>>>> added to cn=masters that designates it. >>>>>>>> >>>>>>>> When a replica is installed it queries this entry so it knows where >>>>>>>> to forward >>>>>>>> CRL requests. CRL files are not available on cloned CAs (so >>>>>>>> /ipa/crl will >>>>>>>> return not found). It is possible to get a CRL directly from the >>>>>>>> clone CA via >>>>>>>> http://:9180/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL >>>>>>>> >>>>>>>> >>>>>>>> rob >>>>>>> >>>>>>> I tested new IPA server + replica with your patch and the CRL was >>>>>>> now generated >>>>>>> only on the CRL master. I also tried OCSP (though this may not be >>>>>>> relevant) and >>>>>>> it worked for me too. >>>>>>> >>>>>>> 1) I do not understand the following block in set_crl_master(self, >>>>>>> suffix): >>>>>>> >>>>>>> + try: >>>>>>> + self.admin_conn.addEntry(entry) >>>>>>> + except ldap.ALREADY_EXISTS, e: >>>>>>> + root_logger.debug("failed to set CA as CRL generator") >>>>>>> + raise e >>>>>>> >>>>>>> - when we hit ldap.ALREADY_EXISTS, we are actually OK because cn=CRL >>>>>>> is set, >>>>>>> right? >>>>>>> - AFAIK, addEntry should return our errors, i.e. errors.DuplicateEntry >>>>>>> - s/raise e/raise/ >>>>>>> >>>>>>> I think you may have wanted to rather catch for more general LDAP >>>>>>> error and >>>>>>> then report a real error and not just a debug note. >>>>>>> >>>>>>> 2) In get_crl_master: >>>>>>> >>>>>>> + except Exception, e: >>>>>>> + root_logger.debug("Could not connect to the Directory >>>>>>> Server on >>>>>>> %s: %s" % (master_host, str(e))) >>>>>>> + raise e >>>>>>> >>>>>>> s/raise e/raise/ >>>>>>> >>>>>>> + except errors.NotFound, e: >>>>>>> + root_logger.debug("failed to find CA CRL generator") >>>>>>> + self.crl_master = None >>>>>>> >>>>>>> - e is actually not used, "except errors.NotFound" would be enough >>>>>>> >>>>>>> 3) Majorish issue I hit with the actual CRL publishing on our server >>>>>>> (F17). I >>>>>>> always get 403 Forbidden error when trying to download CRL from the >>>>>>> CRL master: >>>>>>> >>>>>>> # wget --ca-certificate /etc/ipa/ca.crt >>>>>>> https://`hostname`/ipa/crl/MasterCRL.bin >>>>>>> --2012-10-05 03:32:58-- >>>>>>> https://vm-120.idm.lab.bos.redhat.com/ipa/crl/MasterCRL.bin >>>>>>> Resolving vm-120.idm.lab.bos.redhat.com... 10.16.78.120 >>>>>>> Connecting to vm-120.idm.lab.bos.redhat.com|10.16.78.120|:443... >>>>>>> connected. >>>>>>> HTTP request sent, awaiting response... 403 Forbidden >>>>>>> 2012-10-05 03:32:58 ERROR 403: Forbidden. >>>>>>> >>>>>>> I tracked the problem down to too strict permission on /var/lib/pki-ca >>>>>>> directory which is being published by httpd which does not have >>>>>>> access to it: >>>>>>> >>>>>>> # ll /var/lib/pki-ca >>>>>>> >>>>>>> drwxrwx---. 11 pkiuser pkiuser 4096 Oct 5 03:00 pki-ca >>>>>>> >>>>>>> When I fixed the permission: >>>>>>> # chmod o+x /var/lib/pki-ca/ >>>>>>> >>>>>>> I was able to get pass the Forbidden error and actually retrieved >>>>>>> the CRL. >>>>>>> Adding Ade on CC list to follow on this permission issue. >>>>>>> >>>>>>> >>>>>>> I was thinking about usability of this new approach, we may want to >>>>>>> make user >>>>>>> life easier in a perspective of CRL master managing. I have following >>>>>>> enhancements in mind: >>>>>>> >>>>>>> - mark CRL master in ipa-replica-manage list, or >>>>>>> ipa-csreplica-manage list: >>>>>>> >>>>>>> # ipa-csreplica-manage list >>>>>>> Directory Manager password: >>>>>>> >>>>>>> vm-065.idm.lab.bos.redhat.com: master [CRL] >>>>>>> vm-120.idm.lab.bos.redhat.com: master >>>>>>> >>>>>>> - when removing master with CRL by "ipa-replica-manage del" we >>>>>>> should warn user >>>>>>> and inform him what he should do next to amend the situation. I am >>>>>>> thinking >>>>>>> about 2 new commands for ipa-csreplica-manage: >>>>>>> >>>>>>> * ipa-csreplica-manage crl-promote >>>>>>> - promote current master as the new CRL master, enable CRL >>>>>>> generation in >>>>>>> CS.cfg, mark master as the new CRL master in cn=masters >>>>>>> * ipa-csreplica-manage crl-update >>>>>>> - update CS.cfg of current CA replica and point >>>>>>> master.ca.agent.* to current >>>>>>> CRL master >>>>>>> >>>>>>> I can work on those enhancements if we agree on them. >>>>>>> >>>>>>> Martin >>>>>>> >>>>>> >>>>>> Andrew provided some feedback out-of-band and my solution was overly >>>>>> complex. >>>>>> Here is a much simpler patch which does away with all the hand-waving >>>>>> around >>>>>> knowing who the CRL generator is. >>>>>> >>>>>> rob >>>>> >>>>> This looks OK code-wise, I will wait for dogtag guys to confirm that >>>>> this is >>>>> the right approach. >>>>> >>>>> Btw. I think we may want to file a RFE to implement some command to >>>>> promote a >>>>> replica to CRL master (like "ipa-csreplica-manage crl-promote" proposed >>>>> earlier). Users may want to promote a replica when the master crashes >>>>> or is to >>>>> be replaced. Some way to migrate CRL list (if not replicated already) >>>>> to the >>>>> promoted replica would also be needed. >>>>> >>>>> Martin >>>>> >>>> >>>> Andrew suggested I specify that we do not monitor cloned revocations on >>>> the server not generating CRLs, so I added that. >>>> >>>> The last question is what we do about redirecting users on the >>>> non-generating masters. >>>> >>>> We can do it easily with a line like this in Apache: >>>> >>>> RewriteRule ^/ipa/crl/MasterCRL.bin >>>> https://$FQDN:9444/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL >>>> [L,R=301,NC] >>>> >>>> The tricky part is writing this properly. The CA can be added >>>> post-install so I don't think simply adding this to ipa-rewrite.conf >>>> will work well. Is adding another template configuration file for Apache >>>> overkill? >>>> >>>> rob >>> >>> Here is my WIP for auto-configuring redirect on clones. It works ok for me and >>> isn't too invasive IMHO. The basic idea is to allow proxying of the getCRL >>> servlet and redirect to that on requests to the clone server. >>> >>> Browsing won't work, but you can fetch the MasterCRL.bin with: >>> >>> # wget --ca-certificate=/etc/ipa/ca.crt >>> http://replica.example.com/ipa/crl/MasterCRL.bin >>> >>> diff --git a/install/conf/ipa-pki-proxy.conf b/install/conf/ipa-pki-proxy.conf >>> index 20c0921..8c4f3a9 100644 >>> --- a/install/conf/ipa-pki-proxy.conf >>> +++ b/install/conf/ipa-pki-proxy.conf >>> @@ -3,7 +3,7 @@ >>> ProxyRequests Off >>> >>> # matches for ee port >>> ->> "^/ca/ee/ca/checkRequest|^/ca/ee/ca/getCertChain|^/ca/ee/ca/getTokenInfo|^/ca/ee/ca/tokenAuthenticate|^/ca/ocsp|^/ca/ee/ca/updateNumberRange"> >>> >>> >>> +>> "^/ca/ee/ca/checkRequest|^/ca/ee/ca/getCertChain|^/ca/ee/ca/getTokenInfo|^/ca/ee/ca/tokenAuthenticate|^/ca/ocsp|^/ca/ee/ca/updateNumberRange|^/ca/ee/ca/getCRL"> >>> >>> >>> NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate >>> NSSVerifyClient none >>> ProxyPassMatch ajp://localhost:$DOGTAG_PORT >>> @@ -25,3 +25,6 @@ ProxyRequests Off >>> ProxyPassMatch ajp://localhost:$DOGTAG_PORT >>> ProxyPassReverse ajp://localhost:$DOGTAG_PORT >>> >>> + >>> +# Only enable this on servers that are not generating a CRL >>> +${CLONE}RewriteRule ^/ipa/crl/MasterCRL.bin >>> https://$FQDN/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL [L,R=301,NC] >>> diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py >>> index 0ac895e..aabbba3 100644 >>> --- a/ipaserver/install/cainstance.py >>> +++ b/ipaserver/install/cainstance.py >>> @@ -1304,7 +1304,11 @@ class CAInstance(service.Service): >>> >>> def __http_proxy(self): >>> template_filename = ipautil.SHARE_DIR + "ipa-pki-proxy.conf" >>> - sub_dict = dict(DOGTAG_PORT=self.dogtag_constants.AJP_PORT) >>> + sub_dict = dict( >>> + DOGTAG_PORT=self.dogtag_constants.AJP_PORT, >>> + CLONE='' if self.clone else '#', >>> + FQDN=self.fqdn, >>> + ) >>> template = ipautil.template_file(template_filename, sub_dict) >>> with open(HTTPD_CONFD + "ipa-pki-proxy.conf", "w") as fd: >>> fd.write(template) >> >> The approach looks OK, just please do not forget to also add CLONE to sub_dict >> in ipa-upgradeconfig, it just crashed when I was testing the change: >> >> CRL tree already moved >> File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >> line 614, in run_script >> return_value = main_function() >> >> File "/sbin/ipa-upgradeconfig", line 601, in main >> upgrade(sub_dict, "/etc/httpd/conf.d/ipa-pki-proxy.conf", ipautil.SHARE_DIR >> + "ipa-pki-proxy.conf", add=True) >> >> File "/sbin/ipa-upgradeconfig", line 187, in upgrade >> update_conf(sub_dict, filename, template) >> >> File "/sbin/ipa-upgradeconfig", line 110, in update_conf >> template = ipautil.template_file(template_filename, sub_dict) >> >> File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 228, in >> template_file >> return template_str(f.read(), vars) >> >> File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 215, in >> template_str >> val = string.Template(txt).substitute(vars) >> >> File "/usr/lib64/python2.7/string.py", line 172, in substitute >> return self.pattern.sub(convert, self.template) >> >> File "/usr/lib64/python2.7/string.py", line 162, in convert >> val = mapping[named] >> >> The ipa-upgradeconfig command failed, exception: KeyError: 'CLONE' >> Unexpected error >> KeyError: 'CLONE' >> >> Martin >> > > Fixed and merged into a single patch. > > rob This will crash when upgrading a replica without a CA or server with self-sign: + + crl = installutils.get_directive(configured_constants.CS_CFG_PATH, + 'ca.crl.MasterCRL.enableCRLUpdates', '=') This line can be run only when CA is actually configured. Martin From rcritten at redhat.com Wed Oct 10 14:54:53 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 10 Oct 2012 10:54:53 -0400 Subject: [Freeipa-devel] [PATCH] 1060 - one-liner to fix update file Message-ID: <50758C3D.2000009@redhat.com> I was tempted to push this as a one-liner but an extra set of eyes won't hurt. The lack of quotes around this member causes it to be comma-parsed so it adds each component separately as a member. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1060-agent.patch Type: text/x-diff Size: 982 bytes Desc: not available URL: From abokovoy at redhat.com Wed Oct 10 15:01:50 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 10 Oct 2012 18:01:50 +0300 Subject: [Freeipa-devel] [PATCH] 1060 - one-liner to fix update file In-Reply-To: <50758C3D.2000009@redhat.com> References: <50758C3D.2000009@redhat.com> Message-ID: <20121010150150.GX17454@redhat.com> On Wed, 10 Oct 2012, Rob Crittenden wrote: >I was tempted to push this as a one-liner but an extra set of eyes >won't hurt. > >The lack of quotes around this member causes it to be comma-parsed so >it adds each component separately as a member. I removed this code in my patch 0084 so it is preferrable to get that one in instead. :) -- / Alexander Bokovoy From abokovoy at redhat.com Wed Oct 10 15:05:02 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 10 Oct 2012 18:05:02 +0300 Subject: [Freeipa-devel] [PATCH] 0089 Clarify trust-add help regarding multiple runs against the same domain Message-ID: <20121010150502.GY17454@redhat.com> Hi, this patch originated from off-list discussion regarding multiple runs of ipa trust-add against the same domain. Since trust-add re-establishes the trust every time it is run and all the other information fetched from the remote domain controller stays the same, it can be run multiple times. The only change would occur is update of trust relationship credentials -- they are supposed to be updated periodically by underlying infrastructure anyway. So the patch adds some clarity to the help and changes summary message when trust was re-established instead of created. -- / Alexander Bokovoy -------------- next part -------------- >From 44550cf83aac289363e3ca2acc789bc81cef351d Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 10 Oct 2012 15:33:50 +0300 Subject: [PATCH 5/5] Clarify trust-add help regarding multiple runs against the same domain Since trust-add re-establishes the trust every time it is run and all the other information fetched from the remote domain controller stays the same, it can be run multiple times. The only change would occur is update of trust relationship credentials -- they are supposed to be updated periodically by underlying infrastructure anyway. --- ipalib/plugins/trust.py | 28 +++++++++++++++++++++++++--- 1 file changed, 25 insertions(+), 3 deletions(-) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index 845f96e1fdd09d1e85f6f900d3f1c241445b9c6b..8632d42df578d81b6fdbcd9e5be8979994699206 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -179,7 +179,19 @@ def make_trust_dn(env, trust_type, dn): return dn class trust_add(LDAPCreate): - __doc__ = _('Add new trust to use') + __doc__ = _(''' + Add new trust to use. + + This command establishes trust relationship to another domain + which becomes 'trusted'. As result, users of the trusted domain + may access resources of this domain. + + Only trusts to Active Directory domains are supported right now. + + The command can be safely run multiple times against the same domain, + this will cause change to trust relationship credentials on both + sides. + ''') takes_options = LDAPCreate.takes_options + ( StrEnum('trust_type', @@ -309,6 +321,11 @@ class trust_add(LDAPCreate): reason=_('''Cannot perform join operation without own domain configured. Make sure you have run ipa-adtrust-install on the IPA server first''')) + try: + existing_trust = api.Command['trust_show'](keys[-1]) + summary = _('Re-established trust to domain "%(value)s"') + except errors.NotFound: + summary = self.msg_summary # 1. Full access to the remote domain. Use admin credentials and # generate random trustdom password to do work on both sides if 'realm_admin' in options: @@ -360,14 +377,19 @@ class trust_add(LDAPCreate): raise errors.ValidationError(name=_('AD Trust setup'), error=_('Unable to verify write permissions to the AD')) - return dict(value=trustinstance.remote_domain.info['dns_domain'], verified=result['verified']) + ret = dict(value=trustinstance.remote_domain.info['dns_domain'], verified=result['verified']) + ret['summary'] = summary % ret + return ret + # 2. We don't have access to the remote domain and trustdom password # is provided. Do the work on our side and inform what to do on remote # side. if 'trust_secret' in options: result = trustinstance.join_ad_ipa_half(keys[-1], realm_server, options['trust_secret']) - return dict(value=trustinstance.remote_domain.info['dns_domain'], verified=result['verified']) + ret = dict(value=trustinstance.remote_domain.info['dns_domain'], verified=result['verified']) + ret['summary'] = summary % ret + return ret raise errors.ValidationError(name=_('AD Trust setup'), error=_('Not enough arguments specified to perform trust setup')) -- 1.7.12 From rcritten at redhat.com Wed Oct 10 15:29:23 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 10 Oct 2012 11:29:23 -0400 Subject: [Freeipa-devel] [PATCH] 1059 single CRL generator In-Reply-To: <507586FD.4020905@redhat.com> References: <506DB6A8.10504@redhat.com> <506EA171.20401@redhat.com> <50743822.1090306@redhat.com> <50744A25.8010504@redhat.com> <507472D5.4080406@redhat.com> <5074A962.7010300@redhat.com> <50757942.5080102@redhat.com> <5075825E.8070809@redhat.com> <507586FD.4020905@redhat.com> Message-ID: <50759453.50304@redhat.com> Martin Kosek wrote: > On 10/10/2012 04:12 PM, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On 10/10/2012 12:46 AM, Rob Crittenden wrote: >>>> Rob Crittenden wrote: >>>>> Martin Kosek wrote: >>>>>> On 10/09/2012 04:43 PM, Rob Crittenden wrote: >>>>>>> Martin Kosek wrote: >>>>>>>> On 10/04/2012 06:17 PM, Rob Crittenden wrote: >>>>>>>>> This changes the way IPA generates CRLs for new installs only. >>>>>>>>> >>>>>>>>> The first master installed is configured as the CRL generator. An >>>>>>>>> entry is >>>>>>>>> added to cn=masters that designates it. >>>>>>>>> >>>>>>>>> When a replica is installed it queries this entry so it knows where >>>>>>>>> to forward >>>>>>>>> CRL requests. CRL files are not available on cloned CAs (so >>>>>>>>> /ipa/crl will >>>>>>>>> return not found). It is possible to get a CRL directly from the >>>>>>>>> clone CA via >>>>>>>>> http://:9180/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL >>>>>>>>> >>>>>>>>> >>>>>>>>> rob >>>>>>>> >>>>>>>> I tested new IPA server + replica with your patch and the CRL was >>>>>>>> now generated >>>>>>>> only on the CRL master. I also tried OCSP (though this may not be >>>>>>>> relevant) and >>>>>>>> it worked for me too. >>>>>>>> >>>>>>>> 1) I do not understand the following block in set_crl_master(self, >>>>>>>> suffix): >>>>>>>> >>>>>>>> + try: >>>>>>>> + self.admin_conn.addEntry(entry) >>>>>>>> + except ldap.ALREADY_EXISTS, e: >>>>>>>> + root_logger.debug("failed to set CA as CRL generator") >>>>>>>> + raise e >>>>>>>> >>>>>>>> - when we hit ldap.ALREADY_EXISTS, we are actually OK because cn=CRL >>>>>>>> is set, >>>>>>>> right? >>>>>>>> - AFAIK, addEntry should return our errors, i.e. errors.DuplicateEntry >>>>>>>> - s/raise e/raise/ >>>>>>>> >>>>>>>> I think you may have wanted to rather catch for more general LDAP >>>>>>>> error and >>>>>>>> then report a real error and not just a debug note. >>>>>>>> >>>>>>>> 2) In get_crl_master: >>>>>>>> >>>>>>>> + except Exception, e: >>>>>>>> + root_logger.debug("Could not connect to the Directory >>>>>>>> Server on >>>>>>>> %s: %s" % (master_host, str(e))) >>>>>>>> + raise e >>>>>>>> >>>>>>>> s/raise e/raise/ >>>>>>>> >>>>>>>> + except errors.NotFound, e: >>>>>>>> + root_logger.debug("failed to find CA CRL generator") >>>>>>>> + self.crl_master = None >>>>>>>> >>>>>>>> - e is actually not used, "except errors.NotFound" would be enough >>>>>>>> >>>>>>>> 3) Majorish issue I hit with the actual CRL publishing on our server >>>>>>>> (F17). I >>>>>>>> always get 403 Forbidden error when trying to download CRL from the >>>>>>>> CRL master: >>>>>>>> >>>>>>>> # wget --ca-certificate /etc/ipa/ca.crt >>>>>>>> https://`hostname`/ipa/crl/MasterCRL.bin >>>>>>>> --2012-10-05 03:32:58-- >>>>>>>> https://vm-120.idm.lab.bos.redhat.com/ipa/crl/MasterCRL.bin >>>>>>>> Resolving vm-120.idm.lab.bos.redhat.com... 10.16.78.120 >>>>>>>> Connecting to vm-120.idm.lab.bos.redhat.com|10.16.78.120|:443... >>>>>>>> connected. >>>>>>>> HTTP request sent, awaiting response... 403 Forbidden >>>>>>>> 2012-10-05 03:32:58 ERROR 403: Forbidden. >>>>>>>> >>>>>>>> I tracked the problem down to too strict permission on /var/lib/pki-ca >>>>>>>> directory which is being published by httpd which does not have >>>>>>>> access to it: >>>>>>>> >>>>>>>> # ll /var/lib/pki-ca >>>>>>>> >>>>>>>> drwxrwx---. 11 pkiuser pkiuser 4096 Oct 5 03:00 pki-ca >>>>>>>> >>>>>>>> When I fixed the permission: >>>>>>>> # chmod o+x /var/lib/pki-ca/ >>>>>>>> >>>>>>>> I was able to get pass the Forbidden error and actually retrieved >>>>>>>> the CRL. >>>>>>>> Adding Ade on CC list to follow on this permission issue. >>>>>>>> >>>>>>>> >>>>>>>> I was thinking about usability of this new approach, we may want to >>>>>>>> make user >>>>>>>> life easier in a perspective of CRL master managing. I have following >>>>>>>> enhancements in mind: >>>>>>>> >>>>>>>> - mark CRL master in ipa-replica-manage list, or >>>>>>>> ipa-csreplica-manage list: >>>>>>>> >>>>>>>> # ipa-csreplica-manage list >>>>>>>> Directory Manager password: >>>>>>>> >>>>>>>> vm-065.idm.lab.bos.redhat.com: master [CRL] >>>>>>>> vm-120.idm.lab.bos.redhat.com: master >>>>>>>> >>>>>>>> - when removing master with CRL by "ipa-replica-manage del" we >>>>>>>> should warn user >>>>>>>> and inform him what he should do next to amend the situation. I am >>>>>>>> thinking >>>>>>>> about 2 new commands for ipa-csreplica-manage: >>>>>>>> >>>>>>>> * ipa-csreplica-manage crl-promote >>>>>>>> - promote current master as the new CRL master, enable CRL >>>>>>>> generation in >>>>>>>> CS.cfg, mark master as the new CRL master in cn=masters >>>>>>>> * ipa-csreplica-manage crl-update >>>>>>>> - update CS.cfg of current CA replica and point >>>>>>>> master.ca.agent.* to current >>>>>>>> CRL master >>>>>>>> >>>>>>>> I can work on those enhancements if we agree on them. >>>>>>>> >>>>>>>> Martin >>>>>>>> >>>>>>> >>>>>>> Andrew provided some feedback out-of-band and my solution was overly >>>>>>> complex. >>>>>>> Here is a much simpler patch which does away with all the hand-waving >>>>>>> around >>>>>>> knowing who the CRL generator is. >>>>>>> >>>>>>> rob >>>>>> >>>>>> This looks OK code-wise, I will wait for dogtag guys to confirm that >>>>>> this is >>>>>> the right approach. >>>>>> >>>>>> Btw. I think we may want to file a RFE to implement some command to >>>>>> promote a >>>>>> replica to CRL master (like "ipa-csreplica-manage crl-promote" proposed >>>>>> earlier). Users may want to promote a replica when the master crashes >>>>>> or is to >>>>>> be replaced. Some way to migrate CRL list (if not replicated already) >>>>>> to the >>>>>> promoted replica would also be needed. >>>>>> >>>>>> Martin >>>>>> >>>>> >>>>> Andrew suggested I specify that we do not monitor cloned revocations on >>>>> the server not generating CRLs, so I added that. >>>>> >>>>> The last question is what we do about redirecting users on the >>>>> non-generating masters. >>>>> >>>>> We can do it easily with a line like this in Apache: >>>>> >>>>> RewriteRule ^/ipa/crl/MasterCRL.bin >>>>> https://$FQDN:9444/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL >>>>> [L,R=301,NC] >>>>> >>>>> The tricky part is writing this properly. The CA can be added >>>>> post-install so I don't think simply adding this to ipa-rewrite.conf >>>>> will work well. Is adding another template configuration file for Apache >>>>> overkill? >>>>> >>>>> rob >>>> >>>> Here is my WIP for auto-configuring redirect on clones. It works ok for me and >>>> isn't too invasive IMHO. The basic idea is to allow proxying of the getCRL >>>> servlet and redirect to that on requests to the clone server. >>>> >>>> Browsing won't work, but you can fetch the MasterCRL.bin with: >>>> >>>> # wget --ca-certificate=/etc/ipa/ca.crt >>>> http://replica.example.com/ipa/crl/MasterCRL.bin >>>> >>>> diff --git a/install/conf/ipa-pki-proxy.conf b/install/conf/ipa-pki-proxy.conf >>>> index 20c0921..8c4f3a9 100644 >>>> --- a/install/conf/ipa-pki-proxy.conf >>>> +++ b/install/conf/ipa-pki-proxy.conf >>>> @@ -3,7 +3,7 @@ >>>> ProxyRequests Off >>>> >>>> # matches for ee port >>>> ->>> "^/ca/ee/ca/checkRequest|^/ca/ee/ca/getCertChain|^/ca/ee/ca/getTokenInfo|^/ca/ee/ca/tokenAuthenticate|^/ca/ocsp|^/ca/ee/ca/updateNumberRange"> >>>> >>>> >>>> +>>> "^/ca/ee/ca/checkRequest|^/ca/ee/ca/getCertChain|^/ca/ee/ca/getTokenInfo|^/ca/ee/ca/tokenAuthenticate|^/ca/ocsp|^/ca/ee/ca/updateNumberRange|^/ca/ee/ca/getCRL"> >>>> >>>> >>>> NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate >>>> NSSVerifyClient none >>>> ProxyPassMatch ajp://localhost:$DOGTAG_PORT >>>> @@ -25,3 +25,6 @@ ProxyRequests Off >>>> ProxyPassMatch ajp://localhost:$DOGTAG_PORT >>>> ProxyPassReverse ajp://localhost:$DOGTAG_PORT >>>> >>>> + >>>> +# Only enable this on servers that are not generating a CRL >>>> +${CLONE}RewriteRule ^/ipa/crl/MasterCRL.bin >>>> https://$FQDN/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL [L,R=301,NC] >>>> diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py >>>> index 0ac895e..aabbba3 100644 >>>> --- a/ipaserver/install/cainstance.py >>>> +++ b/ipaserver/install/cainstance.py >>>> @@ -1304,7 +1304,11 @@ class CAInstance(service.Service): >>>> >>>> def __http_proxy(self): >>>> template_filename = ipautil.SHARE_DIR + "ipa-pki-proxy.conf" >>>> - sub_dict = dict(DOGTAG_PORT=self.dogtag_constants.AJP_PORT) >>>> + sub_dict = dict( >>>> + DOGTAG_PORT=self.dogtag_constants.AJP_PORT, >>>> + CLONE='' if self.clone else '#', >>>> + FQDN=self.fqdn, >>>> + ) >>>> template = ipautil.template_file(template_filename, sub_dict) >>>> with open(HTTPD_CONFD + "ipa-pki-proxy.conf", "w") as fd: >>>> fd.write(template) >>> >>> The approach looks OK, just please do not forget to also add CLONE to sub_dict >>> in ipa-upgradeconfig, it just crashed when I was testing the change: >>> >>> CRL tree already moved >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>> line 614, in run_script >>> return_value = main_function() >>> >>> File "/sbin/ipa-upgradeconfig", line 601, in main >>> upgrade(sub_dict, "/etc/httpd/conf.d/ipa-pki-proxy.conf", ipautil.SHARE_DIR >>> + "ipa-pki-proxy.conf", add=True) >>> >>> File "/sbin/ipa-upgradeconfig", line 187, in upgrade >>> update_conf(sub_dict, filename, template) >>> >>> File "/sbin/ipa-upgradeconfig", line 110, in update_conf >>> template = ipautil.template_file(template_filename, sub_dict) >>> >>> File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 228, in >>> template_file >>> return template_str(f.read(), vars) >>> >>> File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 215, in >>> template_str >>> val = string.Template(txt).substitute(vars) >>> >>> File "/usr/lib64/python2.7/string.py", line 172, in substitute >>> return self.pattern.sub(convert, self.template) >>> >>> File "/usr/lib64/python2.7/string.py", line 162, in convert >>> val = mapping[named] >>> >>> The ipa-upgradeconfig command failed, exception: KeyError: 'CLONE' >>> Unexpected error >>> KeyError: 'CLONE' >>> >>> Martin >>> >> >> Fixed and merged into a single patch. >> >> rob > > This will crash when upgrading a replica without a CA or server with self-sign: > > + > + crl = installutils.get_directive(configured_constants.CS_CFG_PATH, > + 'ca.crl.MasterCRL.enableCRLUpdates', '=') > > This line can be run only when CA is actually configured. > > Martin > Right you are. Fixed. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1059-5-crl.patch Type: text/x-diff Size: 5049 bytes Desc: not available URL: From rcritten at redhat.com Wed Oct 10 15:32:52 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 10 Oct 2012 11:32:52 -0400 Subject: [Freeipa-devel] [PATCH] 0084 Add cifs principal to S4U2Proxy targets only when running ipa-adtrust-install In-Reply-To: <20121008173152.GD17454@redhat.com> References: <20121008173152.GD17454@redhat.com> Message-ID: <50759524.9010701@redhat.com> Alexander Bokovoy wrote: > Hi, > > attached patch moves S4U2Proxy configuration for CIFS service to > ipa-adtrust-install. Since CIFS service is only available after running > ipa-adtrust-install, we cannot reference its principal in advance. This > means bootstrap template and updates processes cannot reference it > directly or upgrading from older versions would not be possible due to > referencing non-existent principal in updates. > > https://fedorahosted.org/freeipa/ticket/3041 ACK, pushed to master and ipa-3-0 rob From rcritten at redhat.com Wed Oct 10 15:33:04 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 10 Oct 2012 11:33:04 -0400 Subject: [Freeipa-devel] [PATCH] 1060 - one-liner to fix update file In-Reply-To: <20121010150150.GX17454@redhat.com> References: <50758C3D.2000009@redhat.com> <20121010150150.GX17454@redhat.com> Message-ID: <50759530.7090303@redhat.com> Alexander Bokovoy wrote: > On Wed, 10 Oct 2012, Rob Crittenden wrote: >> I was tempted to push this as a one-liner but an extra set of eyes >> won't hurt. >> >> The lack of quotes around this member causes it to be comma-parsed so >> it adds each component separately as a member. > I removed this code in my patch 0084 so it is preferrable to get that > one in instead. :) > > Yup, withdrawn. rob From mkosek at redhat.com Wed Oct 10 15:36:57 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 10 Oct 2012 17:36:57 +0200 Subject: [Freeipa-devel] [PATCHES] 0086-0088 Generate Firefox extension on upgrades In-Reply-To: <507584ED.1070106@redhat.com> References: <50743FCE.5050307@redhat.com> <50744226.90007@redhat.com> <50744A59.2050308@redhat.com> <5075381F.7020804@redhat.com> <50757A1D.40301@redhat.com> <507584ED.1070106@redhat.com> Message-ID: <50759619.5000503@redhat.com> On 10/10/2012 04:23 PM, Petr Viktorin wrote: > On 10/10/2012 03:37 PM, Martin Kosek wrote: >> On 10/10/2012 10:55 AM, Petr Viktorin wrote: >>> On 10/09/2012 06:01 PM, Petr Vobornik wrote: >>>> On 10/09/2012 05:26 PM, Petr Viktorin wrote: >>>>> On 10/09/2012 05:16 PM, Petr Viktorin wrote: >>>>>> https://fedorahosted.org/freeipa/ticket/3150 >>>>>> >>>>>> >>>>>> Patch 0086: >>>>>> I found an old unused function while working on this, the patch >>>>>> removes it. >>>>>> >>>>>> Patch 0087: >>>>>> Replica files generated on older masters don't contain the Firefox >>>>>> extension files. Skip installing them in this case. >>>>>> >>>>>> Patch 0088: >>>>>> Servers upgraded from IPA 2.2 need the Firefox extension installed. This >>>>>> is done in ipa-upgradeconfig if they're missing. >>>>>> I made the setup_firefox_extension method independent on the >>>>>> httpinstance state (which is mostly set in create_instance). >>>>>> Similarly, the files are installed ipa-replica-install if they're >>>>>> missing (i.e. skipped by the previous patch). >>>>>> If the Signing-Cert is not on this master, create an unsigned extension >>>>>> using the "zip" command. I needed to add Popen's `cwd` argument to >>>>>> ipautil.run() to get the right filenames out of zip. >>>>>> >>>>>> The patches add "copy_template_file" and "copy_file_if_exists" utilities >>>>>> I've written for some of my WIP patches, expect me to use them more when >>>>>> I get time to work on the installer code. >>>>>> >>>>> >>>>> In my previous mail I've attached an old version of patch 88. Please use >>>>> this one. Sorry! >>>>> >>>>> >>>> >>>> nack >>>> >>>> 1) patch 83-01 doesn't apply. >>> >>> There were conflicts with recent CRL and audit cert renewal patches. Rebased. >>> >>>> 2) When pwd is supplied to setup_firefox_extension `db = >>>> certs.CertDB(realm, subject_base=subject_base)` is skipped and therefore >>>> `db.has_nickname` will fail. >>> >>> Thanks for the catch, fixed. >>> >> >> I tried different installation and upgrade procedures and it seems to work >> fine. I have found few minorish issues when inspecting the code: >> >> Patch 0086-01 looks OK. >> >> Patch 0087-01 looks OK. >> >> Patch 0088-02: >> >> 1) In http.setup_firefox_extension() - why do you require subject_base? AFAIK, >> it is not needed for the signtool and you do not have it right anyway: >> a) You use 0=$REALM, i.e. *zero*=$REALM, which would not be a valid subject >> base anyway >> b) Even when it would be used, a correct subject base is in IPA config (it >> does not have to be O=$REALM. >> >> Thus, I would not require it at all, it would safe us some code and potential >> confusion if subject base would be actually used. >> >> >> 2) [nitpick] In http.setup_firefox_extension() I would not format the string >> before logging: >> >> + root_logger.info( >> + '%s exists, skipping install of Firefox extension' % >> + target_fname) >> >> A desired pattern would be to pass formatting parameters as standard function >> parameters, it may save us few cycles in some situations. >> >> >> 3) In httpinstance.py, I would like to see an absolute path to zip executable. >> It is a common pattern in IPA and more secure: >> >> + ipautil.run(['zip', '-r', target_fname] + filenames, cwd=extdir) >> >> >> Martin >> > > Thanks, fixed in attached patch. > ACK. Pushed all three patches to master, ipa-3-0. Martin From asn at redhat.com Wed Oct 10 15:57:13 2012 From: asn at redhat.com (Andreas Schneider) Date: Wed, 10 Oct 2012 17:57:13 +0200 Subject: [Freeipa-devel] [PATCH] 0086 Make sure samba{, 4}-winbind-krb5-locator package is not installed when trusts are in use In-Reply-To: <20121010124017.GV17454@redhat.com> References: <20121010074930.GI17454@redhat.com> <20121010123104.GF2134@localhost.localdomain> <20121010124017.GV17454@redhat.com> Message-ID: <12624783.QQjlyxMb66@magrathea> On Wednesday 10 October 2012 15:40:17 Alexander Bokovoy wrote: > On Wed, 10 Oct 2012, Sumit Bose wrote: > >On Wed, Oct 10, 2012 at 12:04:06PM +0300, Alexander Bokovoy wrote: > >> On Wed, 10 Oct 2012, Alexander Bokovoy wrote: > >> >On Wed, 10 Oct 2012, Alexander Bokovoy wrote: > >> >>Hi, > >> >> > >> >>Since use of winbind on FreeIPA server that is configured with trusts > >> >>is > >> >>conflicting with krb5 locator based on winbind, make sure there is > >> >>conflict that will force removing samba{,4}-winbind-krb5-locator > >> >>package > >> >>when -server-trust-ad subpackage is installed. > >> >> > >> >>Please note that since feature-wise the two packages would be > >> >>conflicting in use, one has to play tricks with rpm to enforce > >> >>automatic removal of the samba{,4}-winbind-krb5-locator with Obsoletes: > >> >>in addtion to Conflicts: tag. This allows to ensure the two packages > >> >>never installed together: > >> >> > >> >>Conflicts: tag would prevent installing samba{,4}-winbind-krb5-locator > >> >>after freeipa-server-trust-ad subpackage is installed. > >> >> > >> >>Obsoletes: tag would force removal of samba{,4}-winbind-krb5-locator > >> >>during the install of freeipa-server-trust-ad. > >> > > >> >Unfortunately, the side-effect of the Obsoletes: tag is that > >> >freeipa-server-trust-ad would always be selected from the repository > >> >whenever one wants to install samba{,4}-winbind-krb5-locator, so this > >> >approach does not work. > >> > > >> >We can keep pure Conflicts: tags because they would prevent co-install > >> >of the packages. They alone would not be able to provide way to solve > >> >conflicts. > >> > > >> >I'm working on a bit more complex variant with alternatives. > >> > >> New patch attached. I verified that it works but in order to make it > >> useful, samba{,4} package needs to be updated to include alternatives > >> for winbind_krb5_locator.so plugin. Working on that now. > >> > >> -- > >> / Alexander Bokovoy > > > >it works for me as well, so ACK. But I think we should add some minimal > >version to 'Requires: samba4' as well to make sure that it will work with > >the installed samba version. Shall we add this with a second patch later > >when the packages are available or hold the whole patch? > > Since alternatives do not change the target if it is not a symlink, we > can safely make a second patch once Andreas makes new packages > available. Packages with the patch are build and available at: https://admin.fedoraproject.org/updates/samba-4.0.0-153.fc18.rc2 RHEL6 packages are building and will be available in a few hours. -- andreas -- Andreas Schneider GPG-ID: 8B7EB4B8 Red Hat asn at redhat.com Samba Team asn at samba.org From mkosek at redhat.com Wed Oct 10 16:06:55 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 10 Oct 2012 18:06:55 +0200 Subject: [Freeipa-devel] [PATCH] 1059 single CRL generator In-Reply-To: <50759453.50304@redhat.com> References: <506DB6A8.10504@redhat.com> <506EA171.20401@redhat.com> <50743822.1090306@redhat.com> <50744A25.8010504@redhat.com> <507472D5.4080406@redhat.com> <5074A962.7010300@redhat.com> <50757942.5080102@redhat.com> <5075825E.8070809@redhat.com> <507586FD.4020905@redhat.com> <50759453.50304@redhat.com> Message-ID: <50759D1F.6080106@redhat.com> On 10/10/2012 05:29 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> On 10/10/2012 04:12 PM, Rob Crittenden wrote: >>> Martin Kosek wrote: >>>> On 10/10/2012 12:46 AM, Rob Crittenden wrote: >>>>> Rob Crittenden wrote: >>>>>> Martin Kosek wrote: >>>>>>> On 10/09/2012 04:43 PM, Rob Crittenden wrote: >>>>>>>> Martin Kosek wrote: >>>>>>>>> On 10/04/2012 06:17 PM, Rob Crittenden wrote: >>>>>>>>>> This changes the way IPA generates CRLs for new installs only. >>>>>>>>>> >>>>>>>>>> The first master installed is configured as the CRL generator. An >>>>>>>>>> entry is >>>>>>>>>> added to cn=masters that designates it. >>>>>>>>>> >>>>>>>>>> When a replica is installed it queries this entry so it knows where >>>>>>>>>> to forward >>>>>>>>>> CRL requests. CRL files are not available on cloned CAs (so >>>>>>>>>> /ipa/crl will >>>>>>>>>> return not found). It is possible to get a CRL directly from the >>>>>>>>>> clone CA via >>>>>>>>>> http://:9180/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> rob >>>>>>>>> >>>>>>>>> I tested new IPA server + replica with your patch and the CRL was >>>>>>>>> now generated >>>>>>>>> only on the CRL master. I also tried OCSP (though this may not be >>>>>>>>> relevant) and >>>>>>>>> it worked for me too. >>>>>>>>> >>>>>>>>> 1) I do not understand the following block in set_crl_master(self, >>>>>>>>> suffix): >>>>>>>>> >>>>>>>>> + try: >>>>>>>>> + self.admin_conn.addEntry(entry) >>>>>>>>> + except ldap.ALREADY_EXISTS, e: >>>>>>>>> + root_logger.debug("failed to set CA as CRL generator") >>>>>>>>> + raise e >>>>>>>>> >>>>>>>>> - when we hit ldap.ALREADY_EXISTS, we are actually OK because cn=CRL >>>>>>>>> is set, >>>>>>>>> right? >>>>>>>>> - AFAIK, addEntry should return our errors, i.e. errors.DuplicateEntry >>>>>>>>> - s/raise e/raise/ >>>>>>>>> >>>>>>>>> I think you may have wanted to rather catch for more general LDAP >>>>>>>>> error and >>>>>>>>> then report a real error and not just a debug note. >>>>>>>>> >>>>>>>>> 2) In get_crl_master: >>>>>>>>> >>>>>>>>> + except Exception, e: >>>>>>>>> + root_logger.debug("Could not connect to the Directory >>>>>>>>> Server on >>>>>>>>> %s: %s" % (master_host, str(e))) >>>>>>>>> + raise e >>>>>>>>> >>>>>>>>> s/raise e/raise/ >>>>>>>>> >>>>>>>>> + except errors.NotFound, e: >>>>>>>>> + root_logger.debug("failed to find CA CRL generator") >>>>>>>>> + self.crl_master = None >>>>>>>>> >>>>>>>>> - e is actually not used, "except errors.NotFound" would be enough >>>>>>>>> >>>>>>>>> 3) Majorish issue I hit with the actual CRL publishing on our server >>>>>>>>> (F17). I >>>>>>>>> always get 403 Forbidden error when trying to download CRL from the >>>>>>>>> CRL master: >>>>>>>>> >>>>>>>>> # wget --ca-certificate /etc/ipa/ca.crt >>>>>>>>> https://`hostname`/ipa/crl/MasterCRL.bin >>>>>>>>> --2012-10-05 03:32:58-- >>>>>>>>> https://vm-120.idm.lab.bos.redhat.com/ipa/crl/MasterCRL.bin >>>>>>>>> Resolving vm-120.idm.lab.bos.redhat.com... 10.16.78.120 >>>>>>>>> Connecting to vm-120.idm.lab.bos.redhat.com|10.16.78.120|:443... >>>>>>>>> connected. >>>>>>>>> HTTP request sent, awaiting response... 403 Forbidden >>>>>>>>> 2012-10-05 03:32:58 ERROR 403: Forbidden. >>>>>>>>> >>>>>>>>> I tracked the problem down to too strict permission on /var/lib/pki-ca >>>>>>>>> directory which is being published by httpd which does not have >>>>>>>>> access to it: >>>>>>>>> >>>>>>>>> # ll /var/lib/pki-ca >>>>>>>>> >>>>>>>>> drwxrwx---. 11 pkiuser pkiuser 4096 Oct 5 03:00 pki-ca >>>>>>>>> >>>>>>>>> When I fixed the permission: >>>>>>>>> # chmod o+x /var/lib/pki-ca/ >>>>>>>>> >>>>>>>>> I was able to get pass the Forbidden error and actually retrieved >>>>>>>>> the CRL. >>>>>>>>> Adding Ade on CC list to follow on this permission issue. >>>>>>>>> >>>>>>>>> >>>>>>>>> I was thinking about usability of this new approach, we may want to >>>>>>>>> make user >>>>>>>>> life easier in a perspective of CRL master managing. I have following >>>>>>>>> enhancements in mind: >>>>>>>>> >>>>>>>>> - mark CRL master in ipa-replica-manage list, or >>>>>>>>> ipa-csreplica-manage list: >>>>>>>>> >>>>>>>>> # ipa-csreplica-manage list >>>>>>>>> Directory Manager password: >>>>>>>>> >>>>>>>>> vm-065.idm.lab.bos.redhat.com: master [CRL] >>>>>>>>> vm-120.idm.lab.bos.redhat.com: master >>>>>>>>> >>>>>>>>> - when removing master with CRL by "ipa-replica-manage del" we >>>>>>>>> should warn user >>>>>>>>> and inform him what he should do next to amend the situation. I am >>>>>>>>> thinking >>>>>>>>> about 2 new commands for ipa-csreplica-manage: >>>>>>>>> >>>>>>>>> * ipa-csreplica-manage crl-promote >>>>>>>>> - promote current master as the new CRL master, enable CRL >>>>>>>>> generation in >>>>>>>>> CS.cfg, mark master as the new CRL master in cn=masters >>>>>>>>> * ipa-csreplica-manage crl-update >>>>>>>>> - update CS.cfg of current CA replica and point >>>>>>>>> master.ca.agent.* to current >>>>>>>>> CRL master >>>>>>>>> >>>>>>>>> I can work on those enhancements if we agree on them. >>>>>>>>> >>>>>>>>> Martin >>>>>>>>> >>>>>>>> >>>>>>>> Andrew provided some feedback out-of-band and my solution was overly >>>>>>>> complex. >>>>>>>> Here is a much simpler patch which does away with all the hand-waving >>>>>>>> around >>>>>>>> knowing who the CRL generator is. >>>>>>>> >>>>>>>> rob >>>>>>> >>>>>>> This looks OK code-wise, I will wait for dogtag guys to confirm that >>>>>>> this is >>>>>>> the right approach. >>>>>>> >>>>>>> Btw. I think we may want to file a RFE to implement some command to >>>>>>> promote a >>>>>>> replica to CRL master (like "ipa-csreplica-manage crl-promote" proposed >>>>>>> earlier). Users may want to promote a replica when the master crashes >>>>>>> or is to >>>>>>> be replaced. Some way to migrate CRL list (if not replicated already) >>>>>>> to the >>>>>>> promoted replica would also be needed. >>>>>>> >>>>>>> Martin >>>>>>> >>>>>> >>>>>> Andrew suggested I specify that we do not monitor cloned revocations on >>>>>> the server not generating CRLs, so I added that. >>>>>> >>>>>> The last question is what we do about redirecting users on the >>>>>> non-generating masters. >>>>>> >>>>>> We can do it easily with a line like this in Apache: >>>>>> >>>>>> RewriteRule ^/ipa/crl/MasterCRL.bin >>>>>> https://$FQDN:9444/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL >>>>>> [L,R=301,NC] >>>>>> >>>>>> The tricky part is writing this properly. The CA can be added >>>>>> post-install so I don't think simply adding this to ipa-rewrite.conf >>>>>> will work well. Is adding another template configuration file for Apache >>>>>> overkill? >>>>>> >>>>>> rob >>>>> >>>>> Here is my WIP for auto-configuring redirect on clones. It works ok for me >>>>> and >>>>> isn't too invasive IMHO. The basic idea is to allow proxying of the getCRL >>>>> servlet and redirect to that on requests to the clone server. >>>>> >>>>> Browsing won't work, but you can fetch the MasterCRL.bin with: >>>>> >>>>> # wget --ca-certificate=/etc/ipa/ca.crt >>>>> http://replica.example.com/ipa/crl/MasterCRL.bin >>>>> >>>>> diff --git a/install/conf/ipa-pki-proxy.conf >>>>> b/install/conf/ipa-pki-proxy.conf >>>>> index 20c0921..8c4f3a9 100644 >>>>> --- a/install/conf/ipa-pki-proxy.conf >>>>> +++ b/install/conf/ipa-pki-proxy.conf >>>>> @@ -3,7 +3,7 @@ >>>>> ProxyRequests Off >>>>> >>>>> # matches for ee port >>>>> ->>>> "^/ca/ee/ca/checkRequest|^/ca/ee/ca/getCertChain|^/ca/ee/ca/getTokenInfo|^/ca/ee/ca/tokenAuthenticate|^/ca/ocsp|^/ca/ee/ca/updateNumberRange"> >>>>> >>>>> >>>>> >>>>> +>>>> "^/ca/ee/ca/checkRequest|^/ca/ee/ca/getCertChain|^/ca/ee/ca/getTokenInfo|^/ca/ee/ca/tokenAuthenticate|^/ca/ocsp|^/ca/ee/ca/updateNumberRange|^/ca/ee/ca/getCRL"> >>>>> >>>>> >>>>> >>>>> NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate >>>>> NSSVerifyClient none >>>>> ProxyPassMatch ajp://localhost:$DOGTAG_PORT >>>>> @@ -25,3 +25,6 @@ ProxyRequests Off >>>>> ProxyPassMatch ajp://localhost:$DOGTAG_PORT >>>>> ProxyPassReverse ajp://localhost:$DOGTAG_PORT >>>>> >>>>> + >>>>> +# Only enable this on servers that are not generating a CRL >>>>> +${CLONE}RewriteRule ^/ipa/crl/MasterCRL.bin >>>>> https://$FQDN/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL >>>>> [L,R=301,NC] >>>>> diff --git a/ipaserver/install/cainstance.py >>>>> b/ipaserver/install/cainstance.py >>>>> index 0ac895e..aabbba3 100644 >>>>> --- a/ipaserver/install/cainstance.py >>>>> +++ b/ipaserver/install/cainstance.py >>>>> @@ -1304,7 +1304,11 @@ class CAInstance(service.Service): >>>>> >>>>> def __http_proxy(self): >>>>> template_filename = ipautil.SHARE_DIR + "ipa-pki-proxy.conf" >>>>> - sub_dict = dict(DOGTAG_PORT=self.dogtag_constants.AJP_PORT) >>>>> + sub_dict = dict( >>>>> + DOGTAG_PORT=self.dogtag_constants.AJP_PORT, >>>>> + CLONE='' if self.clone else '#', >>>>> + FQDN=self.fqdn, >>>>> + ) >>>>> template = ipautil.template_file(template_filename, sub_dict) >>>>> with open(HTTPD_CONFD + "ipa-pki-proxy.conf", "w") as fd: >>>>> fd.write(template) >>>> >>>> The approach looks OK, just please do not forget to also add CLONE to sub_dict >>>> in ipa-upgradeconfig, it just crashed when I was testing the change: >>>> >>>> CRL tree already moved >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>>> line 614, in run_script >>>> return_value = main_function() >>>> >>>> File "/sbin/ipa-upgradeconfig", line 601, in main >>>> upgrade(sub_dict, "/etc/httpd/conf.d/ipa-pki-proxy.conf", >>>> ipautil.SHARE_DIR >>>> + "ipa-pki-proxy.conf", add=True) >>>> >>>> File "/sbin/ipa-upgradeconfig", line 187, in upgrade >>>> update_conf(sub_dict, filename, template) >>>> >>>> File "/sbin/ipa-upgradeconfig", line 110, in update_conf >>>> template = ipautil.template_file(template_filename, sub_dict) >>>> >>>> File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 228, in >>>> template_file >>>> return template_str(f.read(), vars) >>>> >>>> File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 215, in >>>> template_str >>>> val = string.Template(txt).substitute(vars) >>>> >>>> File "/usr/lib64/python2.7/string.py", line 172, in substitute >>>> return self.pattern.sub(convert, self.template) >>>> >>>> File "/usr/lib64/python2.7/string.py", line 162, in convert >>>> val = mapping[named] >>>> >>>> The ipa-upgradeconfig command failed, exception: KeyError: 'CLONE' >>>> Unexpected error >>>> KeyError: 'CLONE' >>>> >>>> Martin >>>> >>> >>> Fixed and merged into a single patch. >>> >>> rob >> >> This will crash when upgrading a replica without a CA or server with self-sign: >> >> + >> + crl = installutils.get_directive(configured_constants.CS_CFG_PATH, >> + 'ca.crl.MasterCRL.enableCRLUpdates', '=') >> >> This line can be run only when CA is actually configured. >> >> Martin >> > > Right you are. Fixed. > > rob ACK. Works fine, I was able to get MasterCRL.bin on both master and replica. Please just amend the block below a bit: # migrate CRL publish dir before the location in ipa.conf is updated ca = cainstance.CAInstance(api.env.realm, certs.NSS_DIR) + if ca.is_configured(): + crl = installutils.get_directive(configured_constants.CS_CFG_PATH, + 'ca.crl.MasterCRL.enableCRLUpdates', + '=') + sub_dict['CLONE']='#' if crl.lower() == 'true' else '' ca_restart = migrate_crl_publish_dir(ca) "ca_restart = migrate_crl_publish_dir(ca)" should be closer to the comment above, otherwise it may be confusing. Martin From rcritten at redhat.com Wed Oct 10 16:41:42 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 10 Oct 2012 12:41:42 -0400 Subject: [Freeipa-devel] [PATCH] 1059 single CRL generator In-Reply-To: <50759D1F.6080106@redhat.com> References: <506DB6A8.10504@redhat.com> <506EA171.20401@redhat.com> <50743822.1090306@redhat.com> <50744A25.8010504@redhat.com> <507472D5.4080406@redhat.com> <5074A962.7010300@redhat.com> <50757942.5080102@redhat.com> <5075825E.8070809@redhat.com> <507586FD.4020905@redhat.com> <50759453.50304@redhat.com> <50759D1F.6080106@redhat.com> Message-ID: <5075A546.2020607@redhat.com> Martin Kosek wrote: > On 10/10/2012 05:29 PM, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On 10/10/2012 04:12 PM, Rob Crittenden wrote: >>>> Martin Kosek wrote: >>>>> On 10/10/2012 12:46 AM, Rob Crittenden wrote: >>>>>> Rob Crittenden wrote: >>>>>>> Martin Kosek wrote: >>>>>>>> On 10/09/2012 04:43 PM, Rob Crittenden wrote: >>>>>>>>> Martin Kosek wrote: >>>>>>>>>> On 10/04/2012 06:17 PM, Rob Crittenden wrote: >>>>>>>>>>> This changes the way IPA generates CRLs for new installs only. >>>>>>>>>>> >>>>>>>>>>> The first master installed is configured as the CRL generator. An >>>>>>>>>>> entry is >>>>>>>>>>> added to cn=masters that designates it. >>>>>>>>>>> >>>>>>>>>>> When a replica is installed it queries this entry so it knows where >>>>>>>>>>> to forward >>>>>>>>>>> CRL requests. CRL files are not available on cloned CAs (so >>>>>>>>>>> /ipa/crl will >>>>>>>>>>> return not found). It is possible to get a CRL directly from the >>>>>>>>>>> clone CA via >>>>>>>>>>> http://:9180/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> rob >>>>>>>>>> >>>>>>>>>> I tested new IPA server + replica with your patch and the CRL was >>>>>>>>>> now generated >>>>>>>>>> only on the CRL master. I also tried OCSP (though this may not be >>>>>>>>>> relevant) and >>>>>>>>>> it worked for me too. >>>>>>>>>> >>>>>>>>>> 1) I do not understand the following block in set_crl_master(self, >>>>>>>>>> suffix): >>>>>>>>>> >>>>>>>>>> + try: >>>>>>>>>> + self.admin_conn.addEntry(entry) >>>>>>>>>> + except ldap.ALREADY_EXISTS, e: >>>>>>>>>> + root_logger.debug("failed to set CA as CRL generator") >>>>>>>>>> + raise e >>>>>>>>>> >>>>>>>>>> - when we hit ldap.ALREADY_EXISTS, we are actually OK because cn=CRL >>>>>>>>>> is set, >>>>>>>>>> right? >>>>>>>>>> - AFAIK, addEntry should return our errors, i.e. errors.DuplicateEntry >>>>>>>>>> - s/raise e/raise/ >>>>>>>>>> >>>>>>>>>> I think you may have wanted to rather catch for more general LDAP >>>>>>>>>> error and >>>>>>>>>> then report a real error and not just a debug note. >>>>>>>>>> >>>>>>>>>> 2) In get_crl_master: >>>>>>>>>> >>>>>>>>>> + except Exception, e: >>>>>>>>>> + root_logger.debug("Could not connect to the Directory >>>>>>>>>> Server on >>>>>>>>>> %s: %s" % (master_host, str(e))) >>>>>>>>>> + raise e >>>>>>>>>> >>>>>>>>>> s/raise e/raise/ >>>>>>>>>> >>>>>>>>>> + except errors.NotFound, e: >>>>>>>>>> + root_logger.debug("failed to find CA CRL generator") >>>>>>>>>> + self.crl_master = None >>>>>>>>>> >>>>>>>>>> - e is actually not used, "except errors.NotFound" would be enough >>>>>>>>>> >>>>>>>>>> 3) Majorish issue I hit with the actual CRL publishing on our server >>>>>>>>>> (F17). I >>>>>>>>>> always get 403 Forbidden error when trying to download CRL from the >>>>>>>>>> CRL master: >>>>>>>>>> >>>>>>>>>> # wget --ca-certificate /etc/ipa/ca.crt >>>>>>>>>> https://`hostname`/ipa/crl/MasterCRL.bin >>>>>>>>>> --2012-10-05 03:32:58-- >>>>>>>>>> https://vm-120.idm.lab.bos.redhat.com/ipa/crl/MasterCRL.bin >>>>>>>>>> Resolving vm-120.idm.lab.bos.redhat.com... 10.16.78.120 >>>>>>>>>> Connecting to vm-120.idm.lab.bos.redhat.com|10.16.78.120|:443... >>>>>>>>>> connected. >>>>>>>>>> HTTP request sent, awaiting response... 403 Forbidden >>>>>>>>>> 2012-10-05 03:32:58 ERROR 403: Forbidden. >>>>>>>>>> >>>>>>>>>> I tracked the problem down to too strict permission on /var/lib/pki-ca >>>>>>>>>> directory which is being published by httpd which does not have >>>>>>>>>> access to it: >>>>>>>>>> >>>>>>>>>> # ll /var/lib/pki-ca >>>>>>>>>> >>>>>>>>>> drwxrwx---. 11 pkiuser pkiuser 4096 Oct 5 03:00 pki-ca >>>>>>>>>> >>>>>>>>>> When I fixed the permission: >>>>>>>>>> # chmod o+x /var/lib/pki-ca/ >>>>>>>>>> >>>>>>>>>> I was able to get pass the Forbidden error and actually retrieved >>>>>>>>>> the CRL. >>>>>>>>>> Adding Ade on CC list to follow on this permission issue. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I was thinking about usability of this new approach, we may want to >>>>>>>>>> make user >>>>>>>>>> life easier in a perspective of CRL master managing. I have following >>>>>>>>>> enhancements in mind: >>>>>>>>>> >>>>>>>>>> - mark CRL master in ipa-replica-manage list, or >>>>>>>>>> ipa-csreplica-manage list: >>>>>>>>>> >>>>>>>>>> # ipa-csreplica-manage list >>>>>>>>>> Directory Manager password: >>>>>>>>>> >>>>>>>>>> vm-065.idm.lab.bos.redhat.com: master [CRL] >>>>>>>>>> vm-120.idm.lab.bos.redhat.com: master >>>>>>>>>> >>>>>>>>>> - when removing master with CRL by "ipa-replica-manage del" we >>>>>>>>>> should warn user >>>>>>>>>> and inform him what he should do next to amend the situation. I am >>>>>>>>>> thinking >>>>>>>>>> about 2 new commands for ipa-csreplica-manage: >>>>>>>>>> >>>>>>>>>> * ipa-csreplica-manage crl-promote >>>>>>>>>> - promote current master as the new CRL master, enable CRL >>>>>>>>>> generation in >>>>>>>>>> CS.cfg, mark master as the new CRL master in cn=masters >>>>>>>>>> * ipa-csreplica-manage crl-update >>>>>>>>>> - update CS.cfg of current CA replica and point >>>>>>>>>> master.ca.agent.* to current >>>>>>>>>> CRL master >>>>>>>>>> >>>>>>>>>> I can work on those enhancements if we agree on them. >>>>>>>>>> >>>>>>>>>> Martin >>>>>>>>>> >>>>>>>>> >>>>>>>>> Andrew provided some feedback out-of-band and my solution was overly >>>>>>>>> complex. >>>>>>>>> Here is a much simpler patch which does away with all the hand-waving >>>>>>>>> around >>>>>>>>> knowing who the CRL generator is. >>>>>>>>> >>>>>>>>> rob >>>>>>>> >>>>>>>> This looks OK code-wise, I will wait for dogtag guys to confirm that >>>>>>>> this is >>>>>>>> the right approach. >>>>>>>> >>>>>>>> Btw. I think we may want to file a RFE to implement some command to >>>>>>>> promote a >>>>>>>> replica to CRL master (like "ipa-csreplica-manage crl-promote" proposed >>>>>>>> earlier). Users may want to promote a replica when the master crashes >>>>>>>> or is to >>>>>>>> be replaced. Some way to migrate CRL list (if not replicated already) >>>>>>>> to the >>>>>>>> promoted replica would also be needed. >>>>>>>> >>>>>>>> Martin >>>>>>>> >>>>>>> >>>>>>> Andrew suggested I specify that we do not monitor cloned revocations on >>>>>>> the server not generating CRLs, so I added that. >>>>>>> >>>>>>> The last question is what we do about redirecting users on the >>>>>>> non-generating masters. >>>>>>> >>>>>>> We can do it easily with a line like this in Apache: >>>>>>> >>>>>>> RewriteRule ^/ipa/crl/MasterCRL.bin >>>>>>> https://$FQDN:9444/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL >>>>>>> [L,R=301,NC] >>>>>>> >>>>>>> The tricky part is writing this properly. The CA can be added >>>>>>> post-install so I don't think simply adding this to ipa-rewrite.conf >>>>>>> will work well. Is adding another template configuration file for Apache >>>>>>> overkill? >>>>>>> >>>>>>> rob >>>>>> >>>>>> Here is my WIP for auto-configuring redirect on clones. It works ok for me >>>>>> and >>>>>> isn't too invasive IMHO. The basic idea is to allow proxying of the getCRL >>>>>> servlet and redirect to that on requests to the clone server. >>>>>> >>>>>> Browsing won't work, but you can fetch the MasterCRL.bin with: >>>>>> >>>>>> # wget --ca-certificate=/etc/ipa/ca.crt >>>>>> http://replica.example.com/ipa/crl/MasterCRL.bin >>>>>> >>>>>> diff --git a/install/conf/ipa-pki-proxy.conf >>>>>> b/install/conf/ipa-pki-proxy.conf >>>>>> index 20c0921..8c4f3a9 100644 >>>>>> --- a/install/conf/ipa-pki-proxy.conf >>>>>> +++ b/install/conf/ipa-pki-proxy.conf >>>>>> @@ -3,7 +3,7 @@ >>>>>> ProxyRequests Off >>>>>> >>>>>> # matches for ee port >>>>>> ->>>>> "^/ca/ee/ca/checkRequest|^/ca/ee/ca/getCertChain|^/ca/ee/ca/getTokenInfo|^/ca/ee/ca/tokenAuthenticate|^/ca/ocsp|^/ca/ee/ca/updateNumberRange"> >>>>>> >>>>>> >>>>>> >>>>>> +>>>>> "^/ca/ee/ca/checkRequest|^/ca/ee/ca/getCertChain|^/ca/ee/ca/getTokenInfo|^/ca/ee/ca/tokenAuthenticate|^/ca/ocsp|^/ca/ee/ca/updateNumberRange|^/ca/ee/ca/getCRL"> >>>>>> >>>>>> >>>>>> >>>>>> NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate >>>>>> NSSVerifyClient none >>>>>> ProxyPassMatch ajp://localhost:$DOGTAG_PORT >>>>>> @@ -25,3 +25,6 @@ ProxyRequests Off >>>>>> ProxyPassMatch ajp://localhost:$DOGTAG_PORT >>>>>> ProxyPassReverse ajp://localhost:$DOGTAG_PORT >>>>>> >>>>>> + >>>>>> +# Only enable this on servers that are not generating a CRL >>>>>> +${CLONE}RewriteRule ^/ipa/crl/MasterCRL.bin >>>>>> https://$FQDN/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL >>>>>> [L,R=301,NC] >>>>>> diff --git a/ipaserver/install/cainstance.py >>>>>> b/ipaserver/install/cainstance.py >>>>>> index 0ac895e..aabbba3 100644 >>>>>> --- a/ipaserver/install/cainstance.py >>>>>> +++ b/ipaserver/install/cainstance.py >>>>>> @@ -1304,7 +1304,11 @@ class CAInstance(service.Service): >>>>>> >>>>>> def __http_proxy(self): >>>>>> template_filename = ipautil.SHARE_DIR + "ipa-pki-proxy.conf" >>>>>> - sub_dict = dict(DOGTAG_PORT=self.dogtag_constants.AJP_PORT) >>>>>> + sub_dict = dict( >>>>>> + DOGTAG_PORT=self.dogtag_constants.AJP_PORT, >>>>>> + CLONE='' if self.clone else '#', >>>>>> + FQDN=self.fqdn, >>>>>> + ) >>>>>> template = ipautil.template_file(template_filename, sub_dict) >>>>>> with open(HTTPD_CONFD + "ipa-pki-proxy.conf", "w") as fd: >>>>>> fd.write(template) >>>>> >>>>> The approach looks OK, just please do not forget to also add CLONE to sub_dict >>>>> in ipa-upgradeconfig, it just crashed when I was testing the change: >>>>> >>>>> CRL tree already moved >>>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>>>> line 614, in run_script >>>>> return_value = main_function() >>>>> >>>>> File "/sbin/ipa-upgradeconfig", line 601, in main >>>>> upgrade(sub_dict, "/etc/httpd/conf.d/ipa-pki-proxy.conf", >>>>> ipautil.SHARE_DIR >>>>> + "ipa-pki-proxy.conf", add=True) >>>>> >>>>> File "/sbin/ipa-upgradeconfig", line 187, in upgrade >>>>> update_conf(sub_dict, filename, template) >>>>> >>>>> File "/sbin/ipa-upgradeconfig", line 110, in update_conf >>>>> template = ipautil.template_file(template_filename, sub_dict) >>>>> >>>>> File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 228, in >>>>> template_file >>>>> return template_str(f.read(), vars) >>>>> >>>>> File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 215, in >>>>> template_str >>>>> val = string.Template(txt).substitute(vars) >>>>> >>>>> File "/usr/lib64/python2.7/string.py", line 172, in substitute >>>>> return self.pattern.sub(convert, self.template) >>>>> >>>>> File "/usr/lib64/python2.7/string.py", line 162, in convert >>>>> val = mapping[named] >>>>> >>>>> The ipa-upgradeconfig command failed, exception: KeyError: 'CLONE' >>>>> Unexpected error >>>>> KeyError: 'CLONE' >>>>> >>>>> Martin >>>>> >>>> >>>> Fixed and merged into a single patch. >>>> >>>> rob >>> >>> This will crash when upgrading a replica without a CA or server with self-sign: >>> >>> + >>> + crl = installutils.get_directive(configured_constants.CS_CFG_PATH, >>> + 'ca.crl.MasterCRL.enableCRLUpdates', '=') >>> >>> This line can be run only when CA is actually configured. >>> >>> Martin >>> >> >> Right you are. Fixed. >> >> rob > > ACK. Works fine, I was able to get MasterCRL.bin on both master and replica. > > > Please just amend the block below a bit: > > # migrate CRL publish dir before the location in ipa.conf is updated > ca = cainstance.CAInstance(api.env.realm, certs.NSS_DIR) > + if ca.is_configured(): > + crl = installutils.get_directive(configured_constants.CS_CFG_PATH, > + 'ca.crl.MasterCRL.enableCRLUpdates', > + '=') > + sub_dict['CLONE']='#' if crl.lower() == 'true' else '' > ca_restart = migrate_crl_publish_dir(ca) > > "ca_restart = migrate_crl_publish_dir(ca)" should be closer to the comment > above, otherwise it may be confusing. > > Martin > fixed and pushed to master and ipa-3-0 rob From simo at redhat.com Wed Oct 10 19:16:36 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 10 Oct 2012 15:16:36 -0400 Subject: [Freeipa-devel] [PATCH] 0086 Make sure samba{, 4}-winbind-krb5-locator package is not installed when trusts are in use In-Reply-To: <12624783.QQjlyxMb66@magrathea> References: <20121010074930.GI17454@redhat.com> <20121010123104.GF2134@localhost.localdomain> <20121010124017.GV17454@redhat.com> <12624783.QQjlyxMb66@magrathea> Message-ID: <1349896596.10587.8.camel@willson.li.ssimo.org> On Wed, 2012-10-10 at 17:57 +0200, Andreas Schneider wrote: > On Wednesday 10 October 2012 15:40:17 Alexander Bokovoy wrote: > > On Wed, 10 Oct 2012, Sumit Bose wrote: > > >On Wed, Oct 10, 2012 at 12:04:06PM +0300, Alexander Bokovoy wrote: > > >> On Wed, 10 Oct 2012, Alexander Bokovoy wrote: > > >> >On Wed, 10 Oct 2012, Alexander Bokovoy wrote: > > >> >>Hi, > > >> >> > > >> >>Since use of winbind on FreeIPA server that is configured with trusts > > >> >>is > > >> >>conflicting with krb5 locator based on winbind, make sure there is > > >> >>conflict that will force removing samba{,4}-winbind-krb5-locator > > >> >>package > > >> >>when -server-trust-ad subpackage is installed. > > >> >> > > >> >>Please note that since feature-wise the two packages would be > > >> >>conflicting in use, one has to play tricks with rpm to enforce > > >> >>automatic removal of the samba{,4}-winbind-krb5-locator with Obsoletes: > > >> >>in addtion to Conflicts: tag. This allows to ensure the two packages > > >> >>never installed together: > > >> >> > > >> >>Conflicts: tag would prevent installing samba{,4}-winbind-krb5-locator > > >> >>after freeipa-server-trust-ad subpackage is installed. > > >> >> > > >> >>Obsoletes: tag would force removal of samba{,4}-winbind-krb5-locator > > >> >>during the install of freeipa-server-trust-ad. > > >> > > > >> >Unfortunately, the side-effect of the Obsoletes: tag is that > > >> >freeipa-server-trust-ad would always be selected from the repository > > >> >whenever one wants to install samba{,4}-winbind-krb5-locator, so this > > >> >approach does not work. > > >> > > > >> >We can keep pure Conflicts: tags because they would prevent co-install > > >> >of the packages. They alone would not be able to provide way to solve > > >> >conflicts. > > >> > > > >> >I'm working on a bit more complex variant with alternatives. > > >> > > >> New patch attached. I verified that it works but in order to make it > > >> useful, samba{,4} package needs to be updated to include alternatives > > >> for winbind_krb5_locator.so plugin. Working on that now. > > >> > > >> -- > > >> / Alexander Bokovoy > > > > > >it works for me as well, so ACK. But I think we should add some minimal > > >version to 'Requires: samba4' as well to make sure that it will work with > > >the installed samba version. Shall we add this with a second patch later > > >when the packages are available or hold the whole patch? > > > > Since alternatives do not change the target if it is not a symlink, we > > can safely make a second patch once Andreas makes new packages > > available. > > Packages with the patch are build and available at: > > https://admin.fedoraproject.org/updates/samba-4.0.0-153.fc18.rc2 > > RHEL6 packages are building and will be available in a few hours. Tested with all packages in place and after an upgrade from 2.2.0 to 3.0 ACK all around. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Wed Oct 10 19:43:08 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 10 Oct 2012 15:43:08 -0400 Subject: [Freeipa-devel] [PATCH] 0086 Make sure samba{, 4}-winbind-krb5-locator package is not installed when trusts are in use In-Reply-To: <1349896596.10587.8.camel@willson.li.ssimo.org> References: <20121010074930.GI17454@redhat.com> <20121010123104.GF2134@localhost.localdomain> <20121010124017.GV17454@redhat.com> <12624783.QQjlyxMb66@magrathea> <1349896596.10587.8.camel@willson.li.ssimo.org> Message-ID: <5075CFCC.90703@redhat.com> Simo Sorce wrote: > On Wed, 2012-10-10 at 17:57 +0200, Andreas Schneider wrote: >> On Wednesday 10 October 2012 15:40:17 Alexander Bokovoy wrote: >>> On Wed, 10 Oct 2012, Sumit Bose wrote: >>>> On Wed, Oct 10, 2012 at 12:04:06PM +0300, Alexander Bokovoy wrote: >>>>> On Wed, 10 Oct 2012, Alexander Bokovoy wrote: >>>>>> On Wed, 10 Oct 2012, Alexander Bokovoy wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Since use of winbind on FreeIPA server that is configured with trusts >>>>>>> is >>>>>>> conflicting with krb5 locator based on winbind, make sure there is >>>>>>> conflict that will force removing samba{,4}-winbind-krb5-locator >>>>>>> package >>>>>>> when -server-trust-ad subpackage is installed. >>>>>>> >>>>>>> Please note that since feature-wise the two packages would be >>>>>>> conflicting in use, one has to play tricks with rpm to enforce >>>>>>> automatic removal of the samba{,4}-winbind-krb5-locator with Obsoletes: >>>>>>> in addtion to Conflicts: tag. This allows to ensure the two packages >>>>>>> never installed together: >>>>>>> >>>>>>> Conflicts: tag would prevent installing samba{,4}-winbind-krb5-locator >>>>>>> after freeipa-server-trust-ad subpackage is installed. >>>>>>> >>>>>>> Obsoletes: tag would force removal of samba{,4}-winbind-krb5-locator >>>>>>> during the install of freeipa-server-trust-ad. >>>>>> >>>>>> Unfortunately, the side-effect of the Obsoletes: tag is that >>>>>> freeipa-server-trust-ad would always be selected from the repository >>>>>> whenever one wants to install samba{,4}-winbind-krb5-locator, so this >>>>>> approach does not work. >>>>>> >>>>>> We can keep pure Conflicts: tags because they would prevent co-install >>>>>> of the packages. They alone would not be able to provide way to solve >>>>>> conflicts. >>>>>> >>>>>> I'm working on a bit more complex variant with alternatives. >>>>> >>>>> New patch attached. I verified that it works but in order to make it >>>>> useful, samba{,4} package needs to be updated to include alternatives >>>>> for winbind_krb5_locator.so plugin. Working on that now. >>>>> >>>>> -- >>>>> / Alexander Bokovoy >>>> >>>> it works for me as well, so ACK. But I think we should add some minimal >>>> version to 'Requires: samba4' as well to make sure that it will work with >>>> the installed samba version. Shall we add this with a second patch later >>>> when the packages are available or hold the whole patch? >>> >>> Since alternatives do not change the target if it is not a symlink, we >>> can safely make a second patch once Andreas makes new packages >>> available. >> >> Packages with the patch are build and available at: >> >> https://admin.fedoraproject.org/updates/samba-4.0.0-153.fc18.rc2 >> >> RHEL6 packages are building and will be available in a few hours. > > Tested with all packages in place and after an upgrade from 2.2.0 to 3.0 > > ACK all around. > > Simo. > Pushed Alexander's patch to master and ipa-3-0 rob From simo at redhat.com Wed Oct 10 21:14:12 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 10 Oct 2012 17:14:12 -0400 Subject: [Freeipa-devel] FYI: pushed oneliner to improve spec requires Message-ID: <1349903652.10587.17.camel@willson.li.ssimo.org> Hi I pushed the following oneliner: Subject: Use stricter requirement for krb5-server Our code strictly depends on 1.10 as the KDC DAL plugin interface is not guaranteed stable and indeed is different in 1.9 and will be different in 1.11 So we cannot allow upgrades to 1.11 until we can provide a plugin that matches 1.11's interface. --- diff --git a/freeipa.spec.in b/freeipa.spec.in index 37d4fc0..060f09b 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -111,6 +111,7 @@ Requires: openldap-clients Requires: nss Requires: nss-tools Requires: krb5-server >= 1.10 +Requires: krb5-server < 1.11 Requires: krb5-pkinit-openssl Requires: cyrus-sasl-gssapi%{?_isa} Requires: ntp -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Oct 11 02:45:12 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 10 Oct 2012 22:45:12 -0400 Subject: [Freeipa-devel] [PATCH] 1061 disable betxn plugins Message-ID: <507632B8.7060602@redhat.com> 389-ds-base 1.3.0 was released to Fedora 18 updates-testing this week. There is the chance of deadlock in the schema compat plugin at the moment. We have a candidate patch for addressing it but it is not yet reviewed. This is an interim patch that disables betxn explicitly for now. It should be reversible later by reversing the update file. I have the update file for anyone that tries upgrading from F-17 to F-18, or has an existing F-18 install with 389-ds-base. Perhaps this is overkill and we can just go with the ldif for now. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1061-betxn.patch Type: text/x-diff Size: 6137 bytes Desc: not available URL: From pviktori at redhat.com Thu Oct 11 09:16:35 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 11 Oct 2012 11:16:35 +0200 Subject: [Freeipa-devel] [PATCH] 0082/0083 Handle NotFound exception when establishing trust In-Reply-To: <20121008122228.GB17454@redhat.com> References: <20121004150613.GP17454@redhat.com> <506EB9D1.3090604@redhat.com> <20121005132424.GQ17454@redhat.com> <506F0934.1070406@redhat.com> <20121005181452.GX17454@redhat.com> <5072C009.3080102@redhat.com> <20121008122228.GB17454@redhat.com> Message-ID: <50768E73.1080603@redhat.com> On 10/08/2012 02:22 PM, Alexander Bokovoy wrote: > On Mon, 08 Oct 2012, Petr Vobornik wrote: >> On 10/05/2012 08:14 PM, Alexander Bokovoy wrote: >>> On Fri, 05 Oct 2012, Petr Vobornik wrote: >>>> On 10/05/2012 03:24 PM, Alexander Bokovoy wrote: >>>>> On Fri, 05 Oct 2012, Petr Vobornik wrote: >>>>>> On 10/04/2012 05:06 PM, Alexander Bokovoy wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> two attached patches attempt to solve >>>>>>> https://fedorahosted.org/freeipa/ticket/3103 >>>>>>> >>>>>>> We cannot make educated guess where trusted domain's DNS server is >>>>>>> located as we ended up with NotFound exception precisely because we >>>>>>> were >>>>>>> unable to discover trusted domain's domain controller location. >>>>>>> >>>>>>> Thus, all we can do is to suggest ways to fix the issue. Since >>>>>>> suggestion becomes relatively long (multi-line, at least), it >>>>>>> creates >>>>>>> few issues for current exception error message handling: >>>>>>> - root_logger does not use textui to format output >>>>>>> - textui is only printing to standard output >>>>>>> - multi-line error messages thus become non-wrapped >>>>>>> - localizing such messages would become a harder context-wise. >>>>>>> >>>>>>> Web UI is showing error message as a single paragraph (

    ), all >>>>>>> multi-line markup would be lost. >>>>>>> >>>>>>> In the end, I decided to support list-based multi-line error >>>>>>> messages in >>>>>>> PublicError class. Its constructor will join all list-based >>>>>>> arguments >>>>>>> into single string per argument (first patch). >>>>>>> >>>>>>> In Web UI I've added special text processing of error messages that >>>>>>> splits message into multiple lines and wraps those which start >>>>>>> with a >>>>>>> TAB symbol into 'error-message-hinted' span to visually separate it >>>>>>> from >>>>>>> the rest of error message. Trust code uses this to display >>>>>>> suggested CLI >>>>>>> command to set up DNS forwarder (second patch). >>>>>>> >>>>>>> In the end, CLI shows such error message fine (note tabulated CLI >>>>>>> command): >>>>>>> ----------------------------------------------------------------------- >>>>>>> >>>>>>> >>>>>>> # ipa trust-add --type=ad --admin Administrator at ad.local1 --password >>>>>>> ad.local1 >>>>>>> Active directory domain administrator's password: ipa: ERROR: >>>>>>> Unable to >>>>>>> resolve domain controller for 'ad.local1' domain. IPA manages DNS, >>>>>>> please configure forwarder to 'ad.local1' domain by using following >>>>>>> CLI >>>>>>> command. Please replace DNS_SERVER and IP_ADDRESS by name and >>>>>>> address of >>>>>>> the domain's name server: >>>>>>> ipa dnszone-add ad.local1 --name-server=DNS_SERVER >>>>>>> --admin-email='hostmaster at ad.local1' --force --forwarder=IP_ADDRESS >>>>>>> --forward-policy=only >>>>>>> When using Web UI, please create DNS zone for domain 'ad.local1' >>>>>>> first >>>>>>> and then set forwarder and forward policy >>>>>>> ----------------------------------------------------------------------- >>>>>>> >>>>>>> >>>>>>> >>>>>>> Web UI looks like this: http://abbra.fedorapeople.org/.paste/ui.png >>>>>>> >>>>>>> >>>>>> >>>>>> You have undeclared identifier: lines. >>>>>> >>>>>> I recommend to run `jsl -conf jsl.conf` command in install/ui folder >>>>>> to prevent these issues. >>>>> Fixed. >>>>> >>>>> >>>>>> I'm not convinced that "beautify" call should be in command object. I >>>>>> would rather see it in error_dialog. >>>>> I moved everything to error_dialog and used $() selectors instead of >>>>> directly playing with text. >>>> >>>> 1) >>>> + var error_message = $('', {}); >>>> >>>> I would rather see a

    as a container. Span is and should >>>> contain only inline elements. >>> Fixed. >>> >>>> 2) >>>> var line_span = $('', { >>>> class: 'error-message-hinted', >>>> text: lines[i].substr(1) >>>> }).appendTo(container); >>>> >>>> Why do you use for hinted message and

    for other lines? >>>> Shouldn't we use

    for both? >>> Fixed to use

    everywhere. >>> >>> >>>> 3) var line_span is declared twice. JS use function scope, not block >>>> scope. >>> Fixed. >>> >>> Thanks for the review. New patch 0082 attached. >>> >>> >> ACK on the UI part with a little change (updated patch attached): >> class: 'error-message-hinted', >> needs to be changed to >> 'class': 'error-message-hinted', >> because class is a keyword and should not be used this way. Sorry that >> I missed it before. > Thanks! > > >> The patch works as advertised. I would give ACK to the python part of >> 82 and patch 83 as well but probably someone more skilled in python >> and ipa internals should do it. >> >> Why do you have to concatenate the value in PublicErrors' __init__ >> method? Shouldn't it be a responsibility of error source (in this case >> 'execute_ad' method)? - just a question, not an issue > This is a good question and gives me some space to explain why certain > decisions are made. > > The whole idea of the patch is to introduce a way to provide multi-line > error messages as a feature of error handling in the FreeIPA framework. > > Suppose we had to join multiple lines always before creating an error > object. This means we would have hundreds of '\n'.join() calls across > the code. Besides maintenance burden, it would also make computational > burden later if we would add proper content formating (which we don't do > now for errors) -- since we would need to split strings later to > reformat them. > > Python is flexible enough to discover parameter types which > allows to design APIs that easer to use. "Easier to use" means least > surprise for the caller rather than callee. So, if you pass multiple > lines (list) of error message, each array element gets processed > separately before displaying. > So, in the end there is only one place where this processing happens, > and it encapsulates all the knowledge required to accept multi-lines > messages, regardless how they come, since it is applied uniformly to every > argument of a constructor of a PublicError-derived class. > Some of our errors already accept lists. From our doctest suite: File "/home/pviktori/freeipa/ipalib/errors.py", line 731, in ipalib.errors.OverlapError Failed example: raise OverlapError(names=['givenname', 'login']) Expected: Traceback (most recent call last): ... OverlapError: overlapping arguments and options: ['givenname', 'login'] Got: Traceback (most recent call last): File "/usr/lib64/python2.7/doctest.py", line 1289, in __run compileflags, 1) in test.globs File "", line 1, in raise OverlapError(names=['givenname', 'login']) OverlapError: overlapping arguments and options: u'givenname\nlogin' In this case, ['givenname', 'login'] is much better than u'givenname\nlogin' (or givennamelogin, if we switched the message from %r to %s). I don't think what's best for trust-add's NotFound is the best thing to do everywhere. -- Petr? From jcholast at redhat.com Thu Oct 11 09:25:14 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 11 Oct 2012 11:25:14 +0200 Subject: [Freeipa-devel] [PATCH] 87 Do not show full SSH public keys in command output by default Message-ID: <5076907A.30105@redhat.com> Hi, in my fix for I have accidentally changed the behavior of user and host commands to always show full SSH public keys in their output. The attached patch fixes this. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-87-Do-not-show-full-SSH-public-keys-in-command-output-b.patch Type: text/x-patch Size: 1234 bytes Desc: not available URL: From mkosek at redhat.com Thu Oct 11 10:20:02 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 11 Oct 2012 12:20:02 +0200 Subject: [Freeipa-devel] [PATCH] 87 Do not show full SSH public keys in command output by default In-Reply-To: <5076907A.30105@redhat.com> References: <5076907A.30105@redhat.com> Message-ID: <50769D52.5000804@redhat.com> On 10/11/2012 11:25 AM, Jan Cholasta wrote: > Hi, > > in my fix for I have > accidentally changed the behavior of user and host commands to always show full > SSH public keys in their output. The attached patch fixes this. > > Honza > Works fine, ACK. Pushed to master, ipa-3-0. Martin From tbabej at redhat.com Thu Oct 11 10:26:12 2012 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 11 Oct 2012 12:26:12 +0200 Subject: [Freeipa-devel] [PATCH 0018] Make service naming in ipa-server-install consistent Message-ID: <50769EC4.10001@redhat.com> Hi, This patch forces more consistency into ipa-server-install output. All descriptions of services that are not instances of SimpleServiceInstance are now in the following format: () Furthermore, start_creation method has been modified to support custom start and end messages. Sample output produced by this patch attached. https://fedorahosted.org/freeipa/ticket/3059 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0018-Make-service-naming-in-ipa-server-install-consistent.patch Type: text/x-patch Size: 9920 bytes Desc: not available URL: -------------- next part -------------- The log file for this installation can be found in /var/log/ipaserver-install.log ============================================================================== This program will set up the FreeIPA Server. This includes: * Configure a stand-alone CA (dogtag) for certificate management * Configure the Network Time Daemon (ntpd) * Create and configure an instance of Directory Server * Create and configure a Kerberos Key Distribution Center (KDC) * Configure Apache (httpd) * Configure DNS (bind) To accept the default shown in brackets, press the Enter key. Warning: skipping DNS resolution of host vm-116.idm.lab.bos.redhat.com The domain name has been determined based on the host name. Using reverse zone 78.16.10.in-addr.arpa. The IPA Master Server will be configured with: Hostname: vm-116.idm.lab.bos.redhat.com IP address: 10.16.78.116 Domain name: idm.lab.bos.redhat.com Realm name: IDM.LAB.BOS.REDHAT.COM BIND DNS server will be configured to serve IPA domain with: Forwarders: 10.16.255.2 Reverse zone: 78.16.10.in-addr.arpa. Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd Done configuring NTP daemon (ntpd). Configuring directory server for the CA (pkids): Estimated time 30 seconds [1/3]: creating directory server user [2/3]: creating directory server instance [3/3]: restarting directory server Done configuring directory server for the CA (pkids). Configuring directory server for the CA (pki-cad): Estimated time 3 minutes 30 seconds [1/21]: creating certificate server user [2/21]: creating pki-ca instance [3/21]: configuring certificate server instance [4/21]: disabling nonces [5/21]: creating CA agent PKCS#12 file in /root [6/21]: creating RA agent certificate database [7/21]: importing CA chain to RA certificate database [8/21]: fixing RA database permissions [9/21]: setting up signing cert profile [10/21]: set up CRL publishing [11/21]: set certificate subject base [12/21]: enabling Subject Key Identifier [13/21]: setting audit signing renewal to 2 years [14/21]: configuring certificate server to start on boot [15/21]: restarting certificate server [16/21]: requesting RA certificate from CA [17/21]: issuing RA agent certificate [18/21]: adding RA agent as a trusted user [19/21]: configure certificate renewals [20/21]: configure Server-Cert certificate renewal [21/21]: Configure HTTP to proxy connections Done configuring directory server for the CA (pki-cad). Configuring directory server (dirsrv): Estimated time 1 minute [1/36]: creating directory server user [2/36]: creating directory server instance [3/36]: adding default schema [4/36]: enabling memberof plugin [5/36]: enabling winsync plugin [6/36]: configuring replication version plugin [7/36]: enabling IPA enrollment plugin [8/36]: enabling ldapi [9/36]: configuring uniqueness plugin [10/36]: configuring uuid plugin [11/36]: configuring modrdn plugin [12/36]: enabling entryUSN plugin [13/36]: configuring lockout plugin [14/36]: creating indices [15/36]: enabling referential integrity plugin [16/36]: configuring ssl for ds instance [17/36]: configuring certmap.conf [18/36]: configure autobind for root [19/36]: configure new location for managed entries [20/36]: restarting directory server [21/36]: adding default layout [22/36]: adding delegation layout [23/36]: adding replication acis [24/36]: creating container for managed entries [25/36]: configuring user private groups [26/36]: configuring netgroups from hostgroups [27/36]: creating default Sudo bind user [28/36]: creating default Auto Member layout [29/36]: adding range check plugin [30/36]: creating default HBAC rule allow_all [31/36]: initializing group membership [32/36]: adding master entry [33/36]: configuring Posix uid/gid generation [34/36]: enabling compatibility plugin [35/36]: tuning directory server [36/36]: configuring directory to start on boot Done configuring directory server (dirsrv). Configuring Kerberos KDC (krb5kdc): Estimated time 30 seconds [1/10]: adding sasl mappings to the directory [2/10]: adding kerberos container to the directory [3/10]: configuring KDC [4/10]: initialize kerberos container [5/10]: adding default ACIs [6/10]: creating a keytab for the directory [7/10]: creating a keytab for the machine [8/10]: adding the password extension to the directory [9/10]: starting the KDC [10/10]: configuring KDC to start on boot Done configuring Kerberos KDC (krb5kdc). Configuring kadmin [1/2]: starting kadmin [2/2]: configuring kadmin to start on boot Done. Configuring ipa_memcached [1/2]: starting ipa_memcached [2/2]: configuring ipa_memcached to start on boot Done. Configuring the web interface (httpd): Estimated time 1 minute [1/14]: disabling mod_ssl in httpd [2/14]: setting mod_nss port to 443 [3/14]: setting mod_nss password file [4/14]: enabling mod_nss renegotiate [5/14]: adding URL rewriting rules [6/14]: configuring httpd [7/14]: setting up ssl [8/14]: setting up browser autoconfig [9/14]: publish CA cert [10/14]: creating a keytab for httpd [11/14]: clean up any existing httpd ccache [12/14]: configuring SELinux for httpd [13/14]: restarting httpd [14/14]: configuring httpd to start on boot Done configuring the web interface (httpd). Applying LDAP updates Restarting the directory server Restarting the KDC Configuring DNS (named) [1/9]: adding DNS container [2/9]: setting up our zone [3/9]: setting up reverse zone [4/9]: setting up our own record [5/9]: setting up kerberos principal [6/9]: setting up named.conf [7/9]: restarting named [8/9]: configuring named to start on boot [9/9]: changing resolv.conf to point to ourselves Done configuring DNS (named). Global DNS configuration in LDAP server is empty You can use 'dnsconfig-mod' command to set global DNS options that would override settings in local named.conf files Restarting the web server ============================================================================== Setup complete Next steps: 1. You must make sure these network ports are open: TCP Ports: * 80, 443: HTTP/HTTPS * 389, 636: LDAP/LDAPS * 88, 464: kerberos * 53: bind UDP Ports: * 88, 464: kerberos * 53: bind * 123: ntp 2. You can now obtain a kerberos ticket using the command: 'kinit admin' This ticket will allow you to use the IPA tools (e.g., ipa user-add) and the web user interface. Be sure to back up the CA certificate stored in /root/cacert.p12 This file is required to create replicas. The password for this file is the Directory Manager password Password for admin at IDM.LAB.BOS.REDHAT.COM: From sbose at redhat.com Thu Oct 11 10:26:20 2012 From: sbose at redhat.com (Sumit Bose) Date: Thu, 11 Oct 2012 12:26:20 +0200 Subject: [Freeipa-devel] [PATCH] 87 extdom: handle INP_POSIX_UID and INP_POSIX_GID requests Message-ID: <20121011102620.GB23959@localhost.localdomain> Hi, I found this issue while working on a related sssd bug https://fedorahosted.org/sssd/ticket/1561 . This patch allows the clients to send a request map a UID or GID for a trusted user to the name of the user. To achieve this the Posix ID is mapped to the corresponding SID and then the SID is looked up. FreeIPA ticket is https://fedorahosted.org/freeipa/ticket/3166 . bye, Sumit -------------- next part -------------- From 014f92f1beda9788721282f54fae285f57f29f95 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Thu, 11 Oct 2012 12:13:53 +0200 Subject: [PATCH] extdom: handle INP_POSIX_UID and INP_POSIX_GID requests Fixes https://fedorahosted.org/freeipa/ticket/3166 --- .../ipa-extdom-extop/ipa_extdom_common.c | 38 ++++++++++++++++++---- 1 Datei ge?ndert, 32 Zeilen hinzugef?gt(+), 6 Zeilen entfernt(-) diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c index 47d4d68d1d7f5e4f02ad68849b840eaa63f7c33d..0c054fb84d375b4e429b35af8f2dc896a475cb2b 100644 --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c @@ -329,20 +329,46 @@ int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, char *name; enum wbcSidType name_type; struct domain_info *domain_info = NULL; + uint32_t id; + enum idmap_error_code err; + char *sid_str; ret = get_domain_info(ctx, req->data.name.domain_name, &domain_info); if (ret != 0) { return LDAP_OPERATIONS_ERROR; } + if (req->input_type == INP_POSIX_UID || req->input_type == INP_POSIX_GID) { + if (req->input_type == INP_POSIX_UID) { + id = req->data.posix_uid.uid; + } else { + id = req->data.posix_gid.gid; + } + + err = sss_idmap_unix_to_sid(domain_info->idmap_ctx, id, &sid_str); + if (err != IDMAP_SUCCESS) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + werr = wbcStringToSid(sid_str, &sid); + free(sid_str); + if (!WBC_ERROR_IS_OK(werr)) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + } else if (req->input_type == INP_SID) { + werr = wbcStringToSid(req->data.sid, &sid); + if (!WBC_ERROR_IS_OK(werr)) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + } switch (req->input_type) { + case INP_POSIX_UID: + case INP_POSIX_GID: case INP_SID: - werr = wbcStringToSid(req->data.sid, &sid); - if (!WBC_ERROR_IS_OK(werr)) { - ret = LDAP_OPERATIONS_ERROR; - goto done; - } - werr = wbcLookupSid(&sid, &domain_name, &name, &name_type); if (!WBC_ERROR_IS_OK(werr)) { ret = LDAP_OPERATIONS_ERROR; -- 1.7.11.4 From abokovoy at redhat.com Thu Oct 11 10:27:09 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 11 Oct 2012 13:27:09 +0300 Subject: [Freeipa-devel] [PATCH] 0082/0083 Handle NotFound exception when establishing trust In-Reply-To: <50768E73.1080603@redhat.com> References: <20121004150613.GP17454@redhat.com> <506EB9D1.3090604@redhat.com> <20121005132424.GQ17454@redhat.com> <506F0934.1070406@redhat.com> <20121005181452.GX17454@redhat.com> <5072C009.3080102@redhat.com> <20121008122228.GB17454@redhat.com> <50768E73.1080603@redhat.com> Message-ID: <20121011102709.GA17454@redhat.com> On Thu, 11 Oct 2012, Petr Viktorin wrote: >On 10/08/2012 02:22 PM, Alexander Bokovoy wrote: >>On Mon, 08 Oct 2012, Petr Vobornik wrote: >>>On 10/05/2012 08:14 PM, Alexander Bokovoy wrote: >>>>On Fri, 05 Oct 2012, Petr Vobornik wrote: >>>>>On 10/05/2012 03:24 PM, Alexander Bokovoy wrote: >>>>>>On Fri, 05 Oct 2012, Petr Vobornik wrote: >>>>>>>On 10/04/2012 05:06 PM, Alexander Bokovoy wrote: >>>>>>>> >>>>>>>>Hi, >>>>>>>> >>>>>>>>two attached patches attempt to solve >>>>>>>>https://fedorahosted.org/freeipa/ticket/3103 >>>>>>>> >>>>>>>>We cannot make educated guess where trusted domain's DNS server is >>>>>>>>located as we ended up with NotFound exception precisely because we >>>>>>>>were >>>>>>>>unable to discover trusted domain's domain controller location. >>>>>>>> >>>>>>>>Thus, all we can do is to suggest ways to fix the issue. Since >>>>>>>>suggestion becomes relatively long (multi-line, at least), it >>>>>>>>creates >>>>>>>>few issues for current exception error message handling: >>>>>>>>- root_logger does not use textui to format output >>>>>>>>- textui is only printing to standard output >>>>>>>>- multi-line error messages thus become non-wrapped >>>>>>>>- localizing such messages would become a harder context-wise. >>>>>>>> >>>>>>>>Web UI is showing error message as a single paragraph (

    ), all >>>>>>>>multi-line markup would be lost. >>>>>>>> >>>>>>>>In the end, I decided to support list-based multi-line error >>>>>>>>messages in >>>>>>>>PublicError class. Its constructor will join all list-based >>>>>>>>arguments >>>>>>>>into single string per argument (first patch). >>>>>>>> >>>>>>>>In Web UI I've added special text processing of error messages that >>>>>>>>splits message into multiple lines and wraps those which start >>>>>>>>with a >>>>>>>>TAB symbol into 'error-message-hinted' span to visually separate it >>>>>>>>from >>>>>>>>the rest of error message. Trust code uses this to display >>>>>>>>suggested CLI >>>>>>>>command to set up DNS forwarder (second patch). >>>>>>>> >>>>>>>>In the end, CLI shows such error message fine (note tabulated CLI >>>>>>>>command): >>>>>>>>----------------------------------------------------------------------- >>>>>>>> >>>>>>>> >>>>>>>># ipa trust-add --type=ad --admin Administrator at ad.local1 --password >>>>>>>>ad.local1 >>>>>>>>Active directory domain administrator's password: ipa: ERROR: >>>>>>>>Unable to >>>>>>>>resolve domain controller for 'ad.local1' domain. IPA manages DNS, >>>>>>>>please configure forwarder to 'ad.local1' domain by using following >>>>>>>>CLI >>>>>>>>command. Please replace DNS_SERVER and IP_ADDRESS by name and >>>>>>>>address of >>>>>>>>the domain's name server: >>>>>>>> ipa dnszone-add ad.local1 --name-server=DNS_SERVER >>>>>>>>--admin-email='hostmaster at ad.local1' --force --forwarder=IP_ADDRESS >>>>>>>>--forward-policy=only >>>>>>>>When using Web UI, please create DNS zone for domain 'ad.local1' >>>>>>>>first >>>>>>>>and then set forwarder and forward policy >>>>>>>>----------------------------------------------------------------------- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>Web UI looks like this: http://abbra.fedorapeople.org/.paste/ui.png >>>>>>>> >>>>>>>> >>>>>>> >>>>>>>You have undeclared identifier: lines. >>>>>>> >>>>>>>I recommend to run `jsl -conf jsl.conf` command in install/ui folder >>>>>>>to prevent these issues. >>>>>>Fixed. >>>>>> >>>>>> >>>>>>>I'm not convinced that "beautify" call should be in command object. I >>>>>>>would rather see it in error_dialog. >>>>>>I moved everything to error_dialog and used $() selectors instead of >>>>>>directly playing with text. >>>>> >>>>>1) >>>>>+ var error_message = $('', {}); >>>>> >>>>>I would rather see a

    as a container. Span is and should >>>>>contain only inline elements. >>>>Fixed. >>>> >>>>>2) >>>>>var line_span = $('', { >>>>> class: 'error-message-hinted', >>>>> text: lines[i].substr(1) >>>>> }).appendTo(container); >>>>> >>>>>Why do you use for hinted message and

    for other lines? >>>>>Shouldn't we use

    for both? >>>>Fixed to use

    everywhere. >>>> >>>> >>>>>3) var line_span is declared twice. JS use function scope, not block >>>>>scope. >>>>Fixed. >>>> >>>>Thanks for the review. New patch 0082 attached. >>>> >>>> >>>ACK on the UI part with a little change (updated patch attached): >>> class: 'error-message-hinted', >>>needs to be changed to >>> 'class': 'error-message-hinted', >>>because class is a keyword and should not be used this way. Sorry that >>>I missed it before. >>Thanks! >> >> >>>The patch works as advertised. I would give ACK to the python part of >>>82 and patch 83 as well but probably someone more skilled in python >>>and ipa internals should do it. >>> >>>Why do you have to concatenate the value in PublicErrors' __init__ >>>method? Shouldn't it be a responsibility of error source (in this case >>>'execute_ad' method)? - just a question, not an issue >>This is a good question and gives me some space to explain why certain >>decisions are made. >> >>The whole idea of the patch is to introduce a way to provide multi-line >>error messages as a feature of error handling in the FreeIPA framework. >> >>Suppose we had to join multiple lines always before creating an error >>object. This means we would have hundreds of '\n'.join() calls across >>the code. Besides maintenance burden, it would also make computational >>burden later if we would add proper content formating (which we don't do >>now for errors) -- since we would need to split strings later to >>reformat them. >> >>Python is flexible enough to discover parameter types which >>allows to design APIs that easer to use. "Easier to use" means least >>surprise for the caller rather than callee. So, if you pass multiple >>lines (list) of error message, each array element gets processed >>separately before displaying. >>So, in the end there is only one place where this processing happens, >>and it encapsulates all the knowledge required to accept multi-lines >>messages, regardless how they come, since it is applied uniformly to every >>argument of a constructor of a PublicError-derived class. >> > >Some of our errors already accept lists. From our doctest suite: > >File "/home/pviktori/freeipa/ipalib/errors.py", line 731, in >ipalib.errors.OverlapError >Failed example: > raise OverlapError(names=['givenname', 'login']) >Expected: > Traceback (most recent call last): > ... > OverlapError: overlapping arguments and options: ['givenname', 'login'] >Got: > Traceback (most recent call last): > File "/usr/lib64/python2.7/doctest.py", line 1289, in __run > compileflags, 1) in test.globs > File "", line 1, in > raise OverlapError(names=['givenname', 'login']) > OverlapError: overlapping arguments and options: u'givenname\nlogin' > >In this case, ['givenname', 'login'] is much better than >u'givenname\nlogin' (or givennamelogin, if we switched the >message from %r to %s). > > >I don't think what's best for trust-add's NotFound is the best thing >to do everywhere. Sure. Could you make a ticket so that I can investigate it more and find appropriate way to handle this? Perhaps an error class could define how it wants to treat its arguments? With the following patch I have this behavior: >>> from ipalib import errors >>> raise errors.PublicError(lines=['foo','bar'], format="You've got a message: %(lines)s") Traceback (most recent call last): File "", line 1, in PublicError: You've got a message: foo bar >>> raise errors.OverlapError(names=['foo','bar']) Traceback (most recent call last): File "", line 1, in OverlapError: overlapping arguments and options: ['foo', 'bar'] -- / Alexander Bokovoy -------------- next part -------------- >From 3f5999237b2585701a7e40ad196933989fa4bc6c Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 11 Oct 2012 13:23:28 +0300 Subject: [PATCH 7/7] Introduce multiline flag to PublicError In order to control whether arguments should be converged into a single string or left as they are, add PublicError.multiline boolean flag. If PublicError.multiline is True, all arguments to an error instance would be joined with '\n' to a single string to support multi-lined arguments. --- ipalib/errors.py | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/ipalib/errors.py b/ipalib/errors.py index 7f1113200b6b2cd80ea9156d347211e4d978b9be..13a054b33217af43b90ea0c3c7c999070466693d 100644 --- a/ipalib/errors.py +++ b/ipalib/errors.py @@ -248,6 +248,7 @@ class PublicError(StandardError): errno = 900 rval = 1 format = None + multiline = True def __init__(self, format=None, message=None, **kw): self.kw = kw @@ -270,7 +271,10 @@ class PublicError(StandardError): result=u'\n'.join(map(lambda line: unicode(line), value)) return result return value - kwargs = dict(map(lambda (k,v): (k, convert_keyword(v)), kw.items())) + if self.multiline: + kwargs = dict(map(lambda (k,v): (k, convert_keyword(v)), kw.items())) + else: + kwargs = kw self.msg = self.format % kwargs if isinstance(self.format, basestring): self.strerror = ugettext(self.format) % kwargs @@ -736,6 +740,7 @@ class OverlapError(InvocationError): errno = 3006 format = _('overlapping arguments and options: %(names)r') + multiline = False class RequirementError(InvocationError): -- 1.7.12 From mkosek at redhat.com Thu Oct 11 10:32:07 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 11 Oct 2012 12:32:07 +0200 Subject: [Freeipa-devel] [PATCH 0018] Make service naming in ipa-server-install consistent In-Reply-To: <50769EC4.10001@redhat.com> References: <50769EC4.10001@redhat.com> Message-ID: <5076A027.4090009@redhat.com> On 10/11/2012 12:26 PM, Tomas Babej wrote: > Hi, > > This patch forces more consistency into ipa-server-install output. All > descriptions of services that are not instances of > SimpleServiceInstance are now in the following format: > > () > > Furthermore, start_creation method has been modified to support > custom start and end messages. > > Sample output produced by this patch attached. > > https://fedorahosted.org/freeipa/ticket/3059 > > Tomas > Just based on reading the patch, this does not look right: - self.start_creation("Configuring certificate server", 210) + self.start_creation("Configuring directory server for the CA", + end_message="Done configuring directory server for the CA", + show_service_name=True, runtime=210) Martin From pviktori at redhat.com Thu Oct 11 11:05:24 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 11 Oct 2012 13:05:24 +0200 Subject: [Freeipa-devel] [PATCH] 0082/0083 Handle NotFound exception when establishing trust In-Reply-To: <20121011102709.GA17454@redhat.com> References: <20121004150613.GP17454@redhat.com> <506EB9D1.3090604@redhat.com> <20121005132424.GQ17454@redhat.com> <506F0934.1070406@redhat.com> <20121005181452.GX17454@redhat.com> <5072C009.3080102@redhat.com> <20121008122228.GB17454@redhat.com> <50768E73.1080603@redhat.com> <20121011102709.GA17454@redhat.com> Message-ID: <5076A7F4.8000103@redhat.com> On 10/11/2012 12:27 PM, Alexander Bokovoy wrote: > On Thu, 11 Oct 2012, Petr Viktorin wrote: >> On 10/08/2012 02:22 PM, Alexander Bokovoy wrote: >>> On Mon, 08 Oct 2012, Petr Vobornik wrote: >>>> On 10/05/2012 08:14 PM, Alexander Bokovoy wrote: >>>>> On Fri, 05 Oct 2012, Petr Vobornik wrote: >>>>>> On 10/05/2012 03:24 PM, Alexander Bokovoy wrote: >>>>>>> On Fri, 05 Oct 2012, Petr Vobornik wrote: >>>>>>>> On 10/04/2012 05:06 PM, Alexander Bokovoy wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> two attached patches attempt to solve >>>>>>>>> https://fedorahosted.org/freeipa/ticket/3103 >>>>>>>>> >>>>>>>>> We cannot make educated guess where trusted domain's DNS server is >>>>>>>>> located as we ended up with NotFound exception precisely >>>>>>>>> because we >>>>>>>>> were >>>>>>>>> unable to discover trusted domain's domain controller location. >>>>>>>>> >>>>>>>>> Thus, all we can do is to suggest ways to fix the issue. Since >>>>>>>>> suggestion becomes relatively long (multi-line, at least), it >>>>>>>>> creates >>>>>>>>> few issues for current exception error message handling: >>>>>>>>> - root_logger does not use textui to format output >>>>>>>>> - textui is only printing to standard output >>>>>>>>> - multi-line error messages thus become non-wrapped >>>>>>>>> - localizing such messages would become a harder context-wise. >>>>>>>>> >>>>>>>>> Web UI is showing error message as a single paragraph (

    ), all >>>>>>>>> multi-line markup would be lost. >>>>>>>>> >>>>>>>>> In the end, I decided to support list-based multi-line error >>>>>>>>> messages in >>>>>>>>> PublicError class. Its constructor will join all list-based >>>>>>>>> arguments >>>>>>>>> into single string per argument (first patch). >>>>>>>>> >>>>>>>>> In Web UI I've added special text processing of error messages >>>>>>>>> that >>>>>>>>> splits message into multiple lines and wraps those which start >>>>>>>>> with a >>>>>>>>> TAB symbol into 'error-message-hinted' span to visually >>>>>>>>> separate it >>>>>>>>> from >>>>>>>>> the rest of error message. Trust code uses this to display >>>>>>>>> suggested CLI >>>>>>>>> command to set up DNS forwarder (second patch). >>>>>>>>> >>>>>>>>> In the end, CLI shows such error message fine (note tabulated CLI >>>>>>>>> command): >>>>>>>>> ----------------------------------------------------------------------- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> # ipa trust-add --type=ad --admin Administrator at ad.local1 >>>>>>>>> --password >>>>>>>>> ad.local1 >>>>>>>>> Active directory domain administrator's password: ipa: ERROR: >>>>>>>>> Unable to >>>>>>>>> resolve domain controller for 'ad.local1' domain. IPA manages DNS, >>>>>>>>> please configure forwarder to 'ad.local1' domain by using >>>>>>>>> following >>>>>>>>> CLI >>>>>>>>> command. Please replace DNS_SERVER and IP_ADDRESS by name and >>>>>>>>> address of >>>>>>>>> the domain's name server: >>>>>>>>> ipa dnszone-add ad.local1 --name-server=DNS_SERVER >>>>>>>>> --admin-email='hostmaster at ad.local1' --force >>>>>>>>> --forwarder=IP_ADDRESS >>>>>>>>> --forward-policy=only >>>>>>>>> When using Web UI, please create DNS zone for domain 'ad.local1' >>>>>>>>> first >>>>>>>>> and then set forwarder and forward policy >>>>>>>>> ----------------------------------------------------------------------- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Web UI looks like this: >>>>>>>>> http://abbra.fedorapeople.org/.paste/ui.png >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> You have undeclared identifier: lines. >>>>>>>> >>>>>>>> I recommend to run `jsl -conf jsl.conf` command in install/ui >>>>>>>> folder >>>>>>>> to prevent these issues. >>>>>>> Fixed. >>>>>>> >>>>>>> >>>>>>>> I'm not convinced that "beautify" call should be in command >>>>>>>> object. I >>>>>>>> would rather see it in error_dialog. >>>>>>> I moved everything to error_dialog and used $() selectors instead of >>>>>>> directly playing with text. >>>>>> >>>>>> 1) >>>>>> + var error_message = $('', {}); >>>>>> >>>>>> I would rather see a

    as a container. Span is and should >>>>>> contain only inline elements. >>>>> Fixed. >>>>> >>>>>> 2) >>>>>> var line_span = $('', { >>>>>> class: 'error-message-hinted', >>>>>> text: lines[i].substr(1) >>>>>> }).appendTo(container); >>>>>> >>>>>> Why do you use for hinted message and

    for other lines? >>>>>> Shouldn't we use

    for both? >>>>> Fixed to use

    everywhere. >>>>> >>>>> >>>>>> 3) var line_span is declared twice. JS use function scope, not block >>>>>> scope. >>>>> Fixed. >>>>> >>>>> Thanks for the review. New patch 0082 attached. >>>>> >>>>> >>>> ACK on the UI part with a little change (updated patch attached): >>>> class: 'error-message-hinted', >>>> needs to be changed to >>>> 'class': 'error-message-hinted', >>>> because class is a keyword and should not be used this way. Sorry that >>>> I missed it before. >>> Thanks! >>> >>> >>>> The patch works as advertised. I would give ACK to the python part of >>>> 82 and patch 83 as well but probably someone more skilled in python >>>> and ipa internals should do it. >>>> >>>> Why do you have to concatenate the value in PublicErrors' __init__ >>>> method? Shouldn't it be a responsibility of error source (in this case >>>> 'execute_ad' method)? - just a question, not an issue >>> This is a good question and gives me some space to explain why certain >>> decisions are made. >>> >>> The whole idea of the patch is to introduce a way to provide multi-line >>> error messages as a feature of error handling in the FreeIPA framework. >>> >>> Suppose we had to join multiple lines always before creating an error >>> object. This means we would have hundreds of '\n'.join() calls across >>> the code. Besides maintenance burden, it would also make computational >>> burden later if we would add proper content formating (which we don't do >>> now for errors) -- since we would need to split strings later to >>> reformat them. >>> >>> Python is flexible enough to discover parameter types which >>> allows to design APIs that easer to use. "Easier to use" means least >>> surprise for the caller rather than callee. So, if you pass multiple >>> lines (list) of error message, each array element gets processed >>> separately before displaying. >>> So, in the end there is only one place where this processing happens, >>> and it encapsulates all the knowledge required to accept multi-lines >>> messages, regardless how they come, since it is applied uniformly to >>> every >>> argument of a constructor of a PublicError-derived class. >>> >> >> Some of our errors already accept lists. From our doctest suite: >> >> File "/home/pviktori/freeipa/ipalib/errors.py", line 731, in >> ipalib.errors.OverlapError >> Failed example: >> raise OverlapError(names=['givenname', 'login']) >> Expected: >> Traceback (most recent call last): >> ... >> OverlapError: overlapping arguments and options: ['givenname', >> 'login'] >> Got: >> Traceback (most recent call last): >> File "/usr/lib64/python2.7/doctest.py", line 1289, in __run >> compileflags, 1) in test.globs >> File "", line 1, in >> raise OverlapError(names=['givenname', 'login']) >> OverlapError: overlapping arguments and options: u'givenname\nlogin' >> >> In this case, ['givenname', 'login'] is much better than >> u'givenname\nlogin' (or givennamelogin, if we switched the >> message from %r to %s). >> >> >> I don't think what's best for trust-add's NotFound is the best thing >> to do everywhere. > Sure. Could you make a ticket so that I can investigate it more and find > appropriate way to handle this? Perhaps an error class could define how > it wants to treat its arguments? Sure. Please share findings of your investigation, then. https://fedorahosted.org/freeipa/ticket/3167 Basically, I think you generalized too much. The result is much more complex (=less understandable, maintainable, changeable) than a '\n'.join() when creating the error. > > With the following patch I have this behavior: >>>> from ipalib import errors >>>> raise errors.PublicError(lines=['foo','bar'], format="You've got a >>>> message: %(lines)s") > Traceback (most recent call last): > File "", line 1, in > PublicError: You've got a message: foo > bar >>>> raise errors.OverlapError(names=['foo','bar']) > Traceback (most recent call last): > File "", line 1, in > OverlapError: overlapping arguments and options: ['foo', 'bar'] The new patch adds even more complexity. Adding the conversions only to error classes that need them (if any), as opposed to PublicError with an option to turn them off, would be much more straightforward. -- Petr? From mkosek at redhat.com Thu Oct 11 12:25:06 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 11 Oct 2012 14:25:06 +0200 Subject: [Freeipa-devel] [PATCH] 1061 disable betxn plugins In-Reply-To: <507632B8.7060602@redhat.com> References: <507632B8.7060602@redhat.com> Message-ID: <5076BAA2.8080908@redhat.com> On 10/11/2012 04:45 AM, Rob Crittenden wrote: > 389-ds-base 1.3.0 was released to Fedora 18 updates-testing this week. There is > the chance of deadlock in the schema compat plugin at the moment. We have a > candidate patch for addressing it but it is not yet reviewed. > > This is an interim patch that disables betxn explicitly for now. It should be > reversible later by reversing the update file. > > I have the update file for anyone that tries upgrading from F-17 to F-18, or > has an existing F-18 install with 389-ds-base. Perhaps this is overkill and we > can just go with the ldif for now. > > rob > I do not think that update file is an overkill, there might be people upgrading from F17, right? I found following issues: 1) Few whitespace errors: # git apply /home/mkosek/freeipa-rcrit-1061-betxn.patch /home/mkosek/freeipa-rcrit-1061-betxn.patch:100: new blank line at EOF. + /home/mkosek/freeipa-rcrit-1061-betxn.patch:145: new blank line at EOF. + warning: 2 lines add whitespace errors. 2) Why do we replace "nsslapd-pluginType: preoperation" for all different plugins? They already have nsslapd-pluginType set. Wouldn't updates that set "nsslapd-pluginbetxn: off: be enough? Martin From rcritten at redhat.com Thu Oct 11 12:31:37 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 11 Oct 2012 08:31:37 -0400 Subject: [Freeipa-devel] [PATCH] 1061 disable betxn plugins In-Reply-To: <5076BAA2.8080908@redhat.com> References: <507632B8.7060602@redhat.com> <5076BAA2.8080908@redhat.com> Message-ID: <5076BC29.5030708@redhat.com> Martin Kosek wrote: > On 10/11/2012 04:45 AM, Rob Crittenden wrote: >> 389-ds-base 1.3.0 was released to Fedora 18 updates-testing this week. There is >> the chance of deadlock in the schema compat plugin at the moment. We have a >> candidate patch for addressing it but it is not yet reviewed. >> >> This is an interim patch that disables betxn explicitly for now. It should be >> reversible later by reversing the update file. >> >> I have the update file for anyone that tries upgrading from F-17 to F-18, or >> has an existing F-18 install with 389-ds-base. Perhaps this is overkill and we >> can just go with the ldif for now. >> >> rob >> > > > I do not think that update file is an overkill, there might be people upgrading > from F17, right? > > I found following issues: > > 1) Few whitespace errors: > > # git apply /home/mkosek/freeipa-rcrit-1061-betxn.patch > /home/mkosek/freeipa-rcrit-1061-betxn.patch:100: new blank line at EOF. > + > /home/mkosek/freeipa-rcrit-1061-betxn.patch:145: new blank line at EOF. > + > warning: 2 lines add whitespace errors. > > 2) Why do we replace "nsslapd-pluginType: preoperation" for all different > plugins? They already have nsslapd-pluginType set. > > Wouldn't updates that set "nsslapd-pluginbetxn: off: be enough? > > Martin > This was the recommendation from the 389-ds team. rob From abokovoy at redhat.com Thu Oct 11 12:44:04 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 11 Oct 2012 15:44:04 +0300 Subject: [Freeipa-devel] [PATCH] 0082/0083 Handle NotFound exception when establishing trust In-Reply-To: <5076A7F4.8000103@redhat.com> References: <20121004150613.GP17454@redhat.com> <506EB9D1.3090604@redhat.com> <20121005132424.GQ17454@redhat.com> <506F0934.1070406@redhat.com> <20121005181452.GX17454@redhat.com> <5072C009.3080102@redhat.com> <20121008122228.GB17454@redhat.com> <50768E73.1080603@redhat.com> <20121011102709.GA17454@redhat.com> <5076A7F4.8000103@redhat.com> Message-ID: <20121011124404.GB17454@redhat.com> On Thu, 11 Oct 2012, Petr Viktorin wrote: >On 10/11/2012 12:27 PM, Alexander Bokovoy wrote: >>On Thu, 11 Oct 2012, Petr Viktorin wrote: >>>On 10/08/2012 02:22 PM, Alexander Bokovoy wrote: >>>>On Mon, 08 Oct 2012, Petr Vobornik wrote: >>>>>On 10/05/2012 08:14 PM, Alexander Bokovoy wrote: >>>>>>On Fri, 05 Oct 2012, Petr Vobornik wrote: >>>>>>>On 10/05/2012 03:24 PM, Alexander Bokovoy wrote: >>>>>>>>On Fri, 05 Oct 2012, Petr Vobornik wrote: >>>>>>>>>On 10/04/2012 05:06 PM, Alexander Bokovoy wrote: >>>>>>>>>> >>>>>>>>>>Hi, >>>>>>>>>> >>>>>>>>>>two attached patches attempt to solve >>>>>>>>>>https://fedorahosted.org/freeipa/ticket/3103 >>>>>>>>>> >>>>>>>>>>We cannot make educated guess where trusted domain's DNS server is >>>>>>>>>>located as we ended up with NotFound exception precisely >>>>>>>>>>because we >>>>>>>>>>were >>>>>>>>>>unable to discover trusted domain's domain controller location. >>>>>>>>>> >>>>>>>>>>Thus, all we can do is to suggest ways to fix the issue. Since >>>>>>>>>>suggestion becomes relatively long (multi-line, at least), it >>>>>>>>>>creates >>>>>>>>>>few issues for current exception error message handling: >>>>>>>>>>- root_logger does not use textui to format output >>>>>>>>>>- textui is only printing to standard output >>>>>>>>>>- multi-line error messages thus become non-wrapped >>>>>>>>>>- localizing such messages would become a harder context-wise. >>>>>>>>>> >>>>>>>>>>Web UI is showing error message as a single paragraph (

    ), all >>>>>>>>>>multi-line markup would be lost. >>>>>>>>>> >>>>>>>>>>In the end, I decided to support list-based multi-line error >>>>>>>>>>messages in >>>>>>>>>>PublicError class. Its constructor will join all list-based >>>>>>>>>>arguments >>>>>>>>>>into single string per argument (first patch). >>>>>>>>>> >>>>>>>>>>In Web UI I've added special text processing of error messages >>>>>>>>>>that >>>>>>>>>>splits message into multiple lines and wraps those which start >>>>>>>>>>with a >>>>>>>>>>TAB symbol into 'error-message-hinted' span to visually >>>>>>>>>>separate it >>>>>>>>>>from >>>>>>>>>>the rest of error message. Trust code uses this to display >>>>>>>>>>suggested CLI >>>>>>>>>>command to set up DNS forwarder (second patch). >>>>>>>>>> >>>>>>>>>>In the end, CLI shows such error message fine (note tabulated CLI >>>>>>>>>>command): >>>>>>>>>>----------------------------------------------------------------------- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>># ipa trust-add --type=ad --admin Administrator at ad.local1 >>>>>>>>>>--password >>>>>>>>>>ad.local1 >>>>>>>>>>Active directory domain administrator's password: ipa: ERROR: >>>>>>>>>>Unable to >>>>>>>>>>resolve domain controller for 'ad.local1' domain. IPA manages DNS, >>>>>>>>>>please configure forwarder to 'ad.local1' domain by using >>>>>>>>>>following >>>>>>>>>>CLI >>>>>>>>>>command. Please replace DNS_SERVER and IP_ADDRESS by name and >>>>>>>>>>address of >>>>>>>>>>the domain's name server: >>>>>>>>>> ipa dnszone-add ad.local1 --name-server=DNS_SERVER >>>>>>>>>>--admin-email='hostmaster at ad.local1' --force >>>>>>>>>>--forwarder=IP_ADDRESS >>>>>>>>>>--forward-policy=only >>>>>>>>>>When using Web UI, please create DNS zone for domain 'ad.local1' >>>>>>>>>>first >>>>>>>>>>and then set forwarder and forward policy >>>>>>>>>>----------------------------------------------------------------------- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>Web UI looks like this: >>>>>>>>>>http://abbra.fedorapeople.org/.paste/ui.png >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>>You have undeclared identifier: lines. >>>>>>>>> >>>>>>>>>I recommend to run `jsl -conf jsl.conf` command in install/ui >>>>>>>>>folder >>>>>>>>>to prevent these issues. >>>>>>>>Fixed. >>>>>>>> >>>>>>>> >>>>>>>>>I'm not convinced that "beautify" call should be in command >>>>>>>>>object. I >>>>>>>>>would rather see it in error_dialog. >>>>>>>>I moved everything to error_dialog and used $() selectors instead of >>>>>>>>directly playing with text. >>>>>>> >>>>>>>1) >>>>>>>+ var error_message = $('', {}); >>>>>>> >>>>>>>I would rather see a

    as a container. Span is and should >>>>>>>contain only inline elements. >>>>>>Fixed. >>>>>> >>>>>>>2) >>>>>>>var line_span = $('', { >>>>>>> class: 'error-message-hinted', >>>>>>> text: lines[i].substr(1) >>>>>>> }).appendTo(container); >>>>>>> >>>>>>>Why do you use for hinted message and

    for other lines? >>>>>>>Shouldn't we use

    for both? >>>>>>Fixed to use

    everywhere. >>>>>> >>>>>> >>>>>>>3) var line_span is declared twice. JS use function scope, not block >>>>>>>scope. >>>>>>Fixed. >>>>>> >>>>>>Thanks for the review. New patch 0082 attached. >>>>>> >>>>>> >>>>>ACK on the UI part with a little change (updated patch attached): >>>>> class: 'error-message-hinted', >>>>>needs to be changed to >>>>> 'class': 'error-message-hinted', >>>>>because class is a keyword and should not be used this way. Sorry that >>>>>I missed it before. >>>>Thanks! >>>> >>>> >>>>>The patch works as advertised. I would give ACK to the python part of >>>>>82 and patch 83 as well but probably someone more skilled in python >>>>>and ipa internals should do it. >>>>> >>>>>Why do you have to concatenate the value in PublicErrors' __init__ >>>>>method? Shouldn't it be a responsibility of error source (in this case >>>>>'execute_ad' method)? - just a question, not an issue >>>>This is a good question and gives me some space to explain why certain >>>>decisions are made. >>>> >>>>The whole idea of the patch is to introduce a way to provide multi-line >>>>error messages as a feature of error handling in the FreeIPA framework. >>>> >>>>Suppose we had to join multiple lines always before creating an error >>>>object. This means we would have hundreds of '\n'.join() calls across >>>>the code. Besides maintenance burden, it would also make computational >>>>burden later if we would add proper content formating (which we don't do >>>>now for errors) -- since we would need to split strings later to >>>>reformat them. >>>> >>>>Python is flexible enough to discover parameter types which >>>>allows to design APIs that easer to use. "Easier to use" means least >>>>surprise for the caller rather than callee. So, if you pass multiple >>>>lines (list) of error message, each array element gets processed >>>>separately before displaying. >>>>So, in the end there is only one place where this processing happens, >>>>and it encapsulates all the knowledge required to accept multi-lines >>>>messages, regardless how they come, since it is applied uniformly to >>>>every >>>>argument of a constructor of a PublicError-derived class. >>>> >>> >>>Some of our errors already accept lists. From our doctest suite: >>> >>>File "/home/pviktori/freeipa/ipalib/errors.py", line 731, in >>>ipalib.errors.OverlapError >>>Failed example: >>> raise OverlapError(names=['givenname', 'login']) >>>Expected: >>> Traceback (most recent call last): >>> ... >>> OverlapError: overlapping arguments and options: ['givenname', >>>'login'] >>>Got: >>> Traceback (most recent call last): >>> File "/usr/lib64/python2.7/doctest.py", line 1289, in __run >>> compileflags, 1) in test.globs >>> File "", line 1, in >>> raise OverlapError(names=['givenname', 'login']) >>> OverlapError: overlapping arguments and options: u'givenname\nlogin' >>> >>>In this case, ['givenname', 'login'] is much better than >>>u'givenname\nlogin' (or givennamelogin, if we switched the >>>message from %r to %s). >>> >>> >>>I don't think what's best for trust-add's NotFound is the best thing >>>to do everywhere. >>Sure. Could you make a ticket so that I can investigate it more and find >>appropriate way to handle this? Perhaps an error class could define how >>it wants to treat its arguments? > >Sure. Please share findings of your investigation, then. > >https://fedorahosted.org/freeipa/ticket/3167 > >Basically, I think you generalized too much. The result is much more >complex (=less understandable, maintainable, changeable) than a >'\n'.join() when creating the error. > >> >>With the following patch I have this behavior: >>>>>from ipalib import errors >>>>>raise errors.PublicError(lines=['foo','bar'], format="You've got a >>>>>message: %(lines)s") >>Traceback (most recent call last): >> File "", line 1, in >>PublicError: You've got a message: foo >>bar >>>>>raise errors.OverlapError(names=['foo','bar']) >>Traceback (most recent call last): >> File "", line 1, in >>OverlapError: overlapping arguments and options: ['foo', 'bar'] > >The new patch adds even more complexity. Adding the conversions only >to error classes that need them (if any), as opposed to PublicError >with an option to turn them off, would be much more straightforward. After discussing more with Petr on irc, I came up with the following patch: allow `instructions' additional parameter to PublicError() to add instructions to an error message. Trust's error message is converted to show its use. -- / Alexander Bokovoy -------------- next part -------------- >From 6c7113197cbcc9a495147f4ce240d7dffc4a6540 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 11 Oct 2012 13:23:28 +0300 Subject: [PATCH 7/7] Add instructions support to PublicError When long additional text should follow the error message, one can supply instructions parameter to a class derived from PublicError. This will cause following text added to the error message: Additional instructions: `instructions' optional parameter could be a list or anything that coerces into unicode(). List entries will be joined with '\n'. https://fedorahosted.org/freeipa/ticket/3167 --- ipalib/errors.py | 11 +++++++---- ipalib/plugins/trust.py | 15 ++++++++------- 2 files changed, 15 insertions(+), 11 deletions(-) diff --git a/ipalib/errors.py b/ipalib/errors.py index 7f1113200b6b2cd80ea9156d347211e4d978b9be..99950011744d929bc372f6a3d5dea4f614fcaf76 100644 --- a/ipalib/errors.py +++ b/ipalib/errors.py @@ -270,12 +270,15 @@ class PublicError(StandardError): result=u'\n'.join(map(lambda line: unicode(line), value)) return result return value - kwargs = dict(map(lambda (k,v): (k, convert_keyword(v)), kw.items())) - self.msg = self.format % kwargs + self.msg = self.format % kw if isinstance(self.format, basestring): - self.strerror = ugettext(self.format) % kwargs + self.strerror = ugettext(self.format) % kw else: - self.strerror = self.format % kwargs + self.strerror = self.format % kw + if 'instructions' in kw: + instructions = u'\n'.join((unicode(_('Additional instructions:')), convert_keyword(kw['instructions']))) + self.strerror = u'\n'.join((self.strerror, instructions)) + self.msg = u'\n'.join((self.msg, instructions)) else: if isinstance(message, (Gettext, NGettext)): message = unicode(message) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index 8632d42df578d81b6fdbcd9e5be8979994699206..9fc6c5ad4638fa237632876207cc85c64ade6503 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -346,32 +346,33 @@ class trust_add(LDAPCreate): try: result = trustinstance.join_ad_full_credentials(keys[-1], realm_server, realm_admin, realm_passwd) except errors.NotFound, e: - error_message=[_("Unable to resolve domain controller for '%s' domain. ") % (keys[-1])] + error_message=_("Unable to resolve domain controller for '%s' domain. ") % (keys[-1]) + instructions=[] if dns_container_exists(self.obj.backend): try: dns_zone = api.Command.dnszone_show(keys[-1])['result'] if ('idnsforwardpolicy' in dns_zone) and dns_zone['idnsforwardpolicy'][0] == u'only': - error_message.append(_("Forward policy is defined for it in IPA DNS, " + instructions.append(_("Forward policy is defined for it in IPA DNS, " "perhaps forwarder points to incorrect host?")) except (errors.NotFound, KeyError) as e: - error_message.append(_("IPA manages DNS, please configure forwarder to " + instructions.append(_("IPA manages DNS, please configure forwarder to " "'%(domain)s' domain using following CLI command. " "Make sure to replace DNS_SERVER and IP_ADDRESS by " "actual values corresponding to the trusted domain's " "DNS server:") % dict(domain=keys[-1])) # tab character at the beginning of a multiline error message will be replaced # in the web UI by a colorful hint. Does not affect CLI. - error_message.append(_("\tipa dnszone-add %(domain)s --name-server=[DNS_SERVER] " + instructions.append(_("\tipa dnszone-add %(domain)s --name-server=[DNS_SERVER] " "--admin-email='hostmaster@%(domain)s' " "--force --forwarder=[IP_ADDRESS] " "--forward-policy=only") % dict(domain=keys[-1])) - error_message.append(_("When using Web UI, please create DNS zone for domain '%(domain)s' " + instructions.append(_("When using Web UI, please create DNS zone for domain '%(domain)s' " "first and then set forwarder and forward policy.") % dict(domain=keys[-1])) else: - error_message.append(_("Since IPA does not manage DNS records, ensure DNS " + instructions.append(_("Since IPA does not manage DNS records, ensure DNS " "is configured to resolve '%(domain)s' domain from " "IPA hosts and back.") % dict(domain=keys[-1])) - raise errors.NotFound(reason=error_message) + raise errors.NotFound(reason=error_message, instructions=instructions) if result is None: raise errors.ValidationError(name=_('AD Trust setup'), -- 1.7.12 From pvoborni at redhat.com Thu Oct 11 12:55:49 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 11 Oct 2012 14:55:49 +0200 Subject: [Freeipa-devel] [PATCHES] backport of Firefox extension to FreeIPA 2.2 Message-ID: <5076C1D5.20403@redhat.com> This bunch of patches is a backport of Firefox extension to FreeIPA 2.2. First apply pvoborni's patches then pviktori's. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0087-2-2-replica-install-Don-t-copy-Firefox-config-extension-.patch Type: text/x-patch Size: 1597 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0088-2-2-Create-Firefox-extension-on-upgrade-and-replica-inst.patch Type: text/x-patch Size: 9246 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0216-2-2-Kerberos-authentication-extension.patch Type: text/x-patch Size: 15550 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0217-2-2-Kerberos-authentication-extension-makefiles.patch Type: text/x-patch Size: 6384 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0218-2-2-Build-and-installation-of-Kerberos-authentication-ex.patch Type: text/x-patch Size: 7432 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0219-2-2-Configuration-pages-changed-to-use-new-FF-extension.patch Type: text/x-patch Size: 34658 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0221-2-2-Add-mime-type-to-httpd-ipa.conf-for-xpi-extension.patch Type: text/x-patch Size: 1168 bytes Desc: not available URL: From rcritten at redhat.com Thu Oct 11 13:03:02 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 11 Oct 2012 09:03:02 -0400 Subject: [Freeipa-devel] [PATCH] 1061 disable betxn plugins In-Reply-To: <5076BC29.5030708@redhat.com> References: <507632B8.7060602@redhat.com> <5076BAA2.8080908@redhat.com> <5076BC29.5030708@redhat.com> Message-ID: <5076C386.7040706@redhat.com> Rob Crittenden wrote: > Martin Kosek wrote: >> On 10/11/2012 04:45 AM, Rob Crittenden wrote: >>> 389-ds-base 1.3.0 was released to Fedora 18 updates-testing this >>> week. There is >>> the chance of deadlock in the schema compat plugin at the moment. We >>> have a >>> candidate patch for addressing it but it is not yet reviewed. >>> >>> This is an interim patch that disables betxn explicitly for now. It >>> should be >>> reversible later by reversing the update file. >>> >>> I have the update file for anyone that tries upgrading from F-17 to >>> F-18, or >>> has an existing F-18 install with 389-ds-base. Perhaps this is >>> overkill and we >>> can just go with the ldif for now. >>> >>> rob >>> >> >> >> I do not think that update file is an overkill, there might be people >> upgrading >> from F17, right? >> >> I found following issues: >> >> 1) Few whitespace errors: >> >> # git apply /home/mkosek/freeipa-rcrit-1061-betxn.patch >> /home/mkosek/freeipa-rcrit-1061-betxn.patch:100: new blank line at EOF. >> + >> /home/mkosek/freeipa-rcrit-1061-betxn.patch:145: new blank line at EOF. >> + >> warning: 2 lines add whitespace errors. >> >> 2) Why do we replace "nsslapd-pluginType: preoperation" for all different >> plugins? They already have nsslapd-pluginType set. >> >> Wouldn't updates that set "nsslapd-pluginbetxn: off: be enough? >> >> Martin >> > > This was the recommendation from the 389-ds team. > > rob Whitespace removed. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1061-2-betxn.patch Type: text/x-diff Size: 6129 bytes Desc: not available URL: From pviktori at redhat.com Thu Oct 11 13:22:29 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 11 Oct 2012 15:22:29 +0200 Subject: [Freeipa-devel] [PATCH] 0082/0083 Handle NotFound exception when establishing trust In-Reply-To: <20121011124404.GB17454@redhat.com> References: <20121004150613.GP17454@redhat.com> <506EB9D1.3090604@redhat.com> <20121005132424.GQ17454@redhat.com> <506F0934.1070406@redhat.com> <20121005181452.GX17454@redhat.com> <5072C009.3080102@redhat.com> <20121008122228.GB17454@redhat.com> <50768E73.1080603@redhat.com> <20121011102709.GA17454@redhat.com> <5076A7F4.8000103@redhat.com> <20121011124404.GB17454@redhat.com> Message-ID: <5076C815.9020500@redhat.com> On 10/11/2012 02:44 PM, Alexander Bokovoy wrote: > On Thu, 11 Oct 2012, Petr Viktorin wrote: >> On 10/11/2012 12:27 PM, Alexander Bokovoy wrote: >>> On Thu, 11 Oct 2012, Petr Viktorin wrote: >>>> On 10/08/2012 02:22 PM, Alexander Bokovoy wrote: >>>>> On Mon, 08 Oct 2012, Petr Vobornik wrote: >>>>>> On 10/05/2012 08:14 PM, Alexander Bokovoy wrote: >>>>>>> On Fri, 05 Oct 2012, Petr Vobornik wrote: >>>>>>>> On 10/05/2012 03:24 PM, Alexander Bokovoy wrote: >>>>>>>>> On Fri, 05 Oct 2012, Petr Vobornik wrote: >>>>>>>>>> On 10/04/2012 05:06 PM, Alexander Bokovoy wrote: >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> two attached patches attempt to solve >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3103 >>>>>>>>>>> >>>>>>>>>>> We cannot make educated guess where trusted domain's DNS >>>>>>>>>>> server is >>>>>>>>>>> located as we ended up with NotFound exception precisely >>>>>>>>>>> because we >>>>>>>>>>> were >>>>>>>>>>> unable to discover trusted domain's domain controller location. >>>>>>>>>>> >>>>>>>>>>> Thus, all we can do is to suggest ways to fix the issue. Since >>>>>>>>>>> suggestion becomes relatively long (multi-line, at least), it >>>>>>>>>>> creates >>>>>>>>>>> few issues for current exception error message handling: >>>>>>>>>>> - root_logger does not use textui to format output >>>>>>>>>>> - textui is only printing to standard output >>>>>>>>>>> - multi-line error messages thus become non-wrapped >>>>>>>>>>> - localizing such messages would become a harder context-wise. >>>>>>>>>>> >>>>>>>>>>> Web UI is showing error message as a single paragraph (

    ), >>>>>>>>>>> all >>>>>>>>>>> multi-line markup would be lost. >>>>>>>>>>> >>>>>>>>>>> In the end, I decided to support list-based multi-line error >>>>>>>>>>> messages in >>>>>>>>>>> PublicError class. Its constructor will join all list-based >>>>>>>>>>> arguments >>>>>>>>>>> into single string per argument (first patch). >>>>>>>>>>> >>>>>>>>>>> In Web UI I've added special text processing of error messages >>>>>>>>>>> that >>>>>>>>>>> splits message into multiple lines and wraps those which start >>>>>>>>>>> with a >>>>>>>>>>> TAB symbol into 'error-message-hinted' span to visually >>>>>>>>>>> separate it >>>>>>>>>>> from >>>>>>>>>>> the rest of error message. Trust code uses this to display >>>>>>>>>>> suggested CLI >>>>>>>>>>> command to set up DNS forwarder (second patch). >>>>>>>>>>> >>>>>>>>>>> In the end, CLI shows such error message fine (note tabulated >>>>>>>>>>> CLI >>>>>>>>>>> command): >>>>>>>>>>> ----------------------------------------------------------------------- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> # ipa trust-add --type=ad --admin Administrator at ad.local1 >>>>>>>>>>> --password >>>>>>>>>>> ad.local1 >>>>>>>>>>> Active directory domain administrator's password: ipa: ERROR: >>>>>>>>>>> Unable to >>>>>>>>>>> resolve domain controller for 'ad.local1' domain. IPA manages >>>>>>>>>>> DNS, >>>>>>>>>>> please configure forwarder to 'ad.local1' domain by using >>>>>>>>>>> following >>>>>>>>>>> CLI >>>>>>>>>>> command. Please replace DNS_SERVER and IP_ADDRESS by name and >>>>>>>>>>> address of >>>>>>>>>>> the domain's name server: >>>>>>>>>>> ipa dnszone-add ad.local1 --name-server=DNS_SERVER >>>>>>>>>>> --admin-email='hostmaster at ad.local1' --force >>>>>>>>>>> --forwarder=IP_ADDRESS >>>>>>>>>>> --forward-policy=only >>>>>>>>>>> When using Web UI, please create DNS zone for domain 'ad.local1' >>>>>>>>>>> first >>>>>>>>>>> and then set forwarder and forward policy >>>>>>>>>>> ----------------------------------------------------------------------- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Web UI looks like this: >>>>>>>>>>> http://abbra.fedorapeople.org/.paste/ui.png >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> You have undeclared identifier: lines. >>>>>>>>>> >>>>>>>>>> I recommend to run `jsl -conf jsl.conf` command in install/ui >>>>>>>>>> folder >>>>>>>>>> to prevent these issues. >>>>>>>>> Fixed. >>>>>>>>> >>>>>>>>> >>>>>>>>>> I'm not convinced that "beautify" call should be in command >>>>>>>>>> object. I >>>>>>>>>> would rather see it in error_dialog. >>>>>>>>> I moved everything to error_dialog and used $() selectors >>>>>>>>> instead of >>>>>>>>> directly playing with text. >>>>>>>> >>>>>>>> 1) >>>>>>>> + var error_message = $('', {}); >>>>>>>> >>>>>>>> I would rather see a

    as a container. Span is and should >>>>>>>> contain only inline elements. >>>>>>> Fixed. >>>>>>> >>>>>>>> 2) >>>>>>>> var line_span = $('', { >>>>>>>> class: 'error-message-hinted', >>>>>>>> text: lines[i].substr(1) >>>>>>>> }).appendTo(container); >>>>>>>> >>>>>>>> Why do you use for hinted message and

    for other lines? >>>>>>>> Shouldn't we use

    for both? >>>>>>> Fixed to use

    everywhere. >>>>>>> >>>>>>> >>>>>>>> 3) var line_span is declared twice. JS use function scope, not >>>>>>>> block >>>>>>>> scope. >>>>>>> Fixed. >>>>>>> >>>>>>> Thanks for the review. New patch 0082 attached. >>>>>>> >>>>>>> >>>>>> ACK on the UI part with a little change (updated patch attached): >>>>>> class: 'error-message-hinted', >>>>>> needs to be changed to >>>>>> 'class': 'error-message-hinted', >>>>>> because class is a keyword and should not be used this way. Sorry >>>>>> that >>>>>> I missed it before. >>>>> Thanks! >>>>> >>>>> >>>>>> The patch works as advertised. I would give ACK to the python part of >>>>>> 82 and patch 83 as well but probably someone more skilled in python >>>>>> and ipa internals should do it. >>>>>> >>>>>> Why do you have to concatenate the value in PublicErrors' __init__ >>>>>> method? Shouldn't it be a responsibility of error source (in this >>>>>> case >>>>>> 'execute_ad' method)? - just a question, not an issue >>>>> This is a good question and gives me some space to explain why certain >>>>> decisions are made. >>>>> >>>>> The whole idea of the patch is to introduce a way to provide >>>>> multi-line >>>>> error messages as a feature of error handling in the FreeIPA >>>>> framework. >>>>> >>>>> Suppose we had to join multiple lines always before creating an error >>>>> object. This means we would have hundreds of '\n'.join() calls across >>>>> the code. Besides maintenance burden, it would also make computational >>>>> burden later if we would add proper content formating (which we >>>>> don't do >>>>> now for errors) -- since we would need to split strings later to >>>>> reformat them. >>>>> >>>>> Python is flexible enough to discover parameter types which >>>>> allows to design APIs that easer to use. "Easier to use" means least >>>>> surprise for the caller rather than callee. So, if you pass multiple >>>>> lines (list) of error message, each array element gets processed >>>>> separately before displaying. >>>>> So, in the end there is only one place where this processing happens, >>>>> and it encapsulates all the knowledge required to accept multi-lines >>>>> messages, regardless how they come, since it is applied uniformly to >>>>> every >>>>> argument of a constructor of a PublicError-derived class. >>>>> >>>> >>>> Some of our errors already accept lists. From our doctest suite: >>>> >>>> File "/home/pviktori/freeipa/ipalib/errors.py", line 731, in >>>> ipalib.errors.OverlapError >>>> Failed example: >>>> raise OverlapError(names=['givenname', 'login']) >>>> Expected: >>>> Traceback (most recent call last): >>>> ... >>>> OverlapError: overlapping arguments and options: ['givenname', >>>> 'login'] >>>> Got: >>>> Traceback (most recent call last): >>>> File "/usr/lib64/python2.7/doctest.py", line 1289, in __run >>>> compileflags, 1) in test.globs >>>> File "", line 1, in >>>> raise OverlapError(names=['givenname', 'login']) >>>> OverlapError: overlapping arguments and options: u'givenname\nlogin' >>>> >>>> In this case, ['givenname', 'login'] is much better than >>>> u'givenname\nlogin' (or givennamelogin, if we switched the >>>> message from %r to %s). >>>> >>>> >>>> I don't think what's best for trust-add's NotFound is the best thing >>>> to do everywhere. >>> Sure. Could you make a ticket so that I can investigate it more and find >>> appropriate way to handle this? Perhaps an error class could define how >>> it wants to treat its arguments? >> >> Sure. Please share findings of your investigation, then. >> >> https://fedorahosted.org/freeipa/ticket/3167 >> >> Basically, I think you generalized too much. The result is much more >> complex (=less understandable, maintainable, changeable) than a >> '\n'.join() when creating the error. >> >>> >>> With the following patch I have this behavior: >>>>>> from ipalib import errors >>>>>> raise errors.PublicError(lines=['foo','bar'], format="You've got a >>>>>> message: %(lines)s") >>> Traceback (most recent call last): >>> File "", line 1, in >>> PublicError: You've got a message: foo >>> bar >>>>>> raise errors.OverlapError(names=['foo','bar']) >>> Traceback (most recent call last): >>> File "", line 1, in >>> OverlapError: overlapping arguments and options: ['foo', 'bar'] >> >> The new patch adds even more complexity. Adding the conversions only >> to error classes that need them (if any), as opposed to PublicError >> with an option to turn them off, would be much more straightforward. > After discussing more with Petr on irc, I came up with the following > patch: allow `instructions' additional parameter to PublicError() to > add instructions to an error message. > > Trust's error message is converted to show its use. > The rationale: The need for multi-line error messages was prompted by requests that IPA should either fix/prevent errors itself, or print out more detailed instructions for the user. Automatic joining of lists is problematic, because it repurposes a standard datatype for the needs of a fairly specific use case. Converting individual arguments that need it is better than a blanket approach. An extra argument for instructions allows us to separate the error message and instructions in the future, if we need to e.g. add more complex formatting than the \t. Patch comments: This needs some tests to verify it's right and prevent regressions. Please rename the convert_keyword function to e.g. format_instructions. It's not necessary to add the instructions to self.msg, that one is not user-friendly. Please wrap the long line in errors.py. -- Petr? From pviktori at redhat.com Thu Oct 11 14:44:27 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 11 Oct 2012 16:44:27 +0200 Subject: [Freeipa-devel] [PATCH by nkondras] Add uninstall command hints to ipa-*-install Message-ID: <5076DB4B.8000904@redhat.com> The patch was submitted via Trac at https://fedorahosted.org/freeipa/ticket/3065. Thanks, Nikolai! Please use this list next time to speed things up. I took the liberty of adding one more message, re-formatting the code a bit, and mentioning the ticket in the commit message. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0089-Add-uninstall-command-hints-to-ipa-install.patch Type: text/x-patch Size: 3913 bytes Desc: not available URL: From tbabej at redhat.com Thu Oct 11 15:11:45 2012 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 11 Oct 2012 17:11:45 +0200 Subject: [Freeipa-devel] [PATCH 0018] Make service naming in ipa-server-install consistent In-Reply-To: <5076A027.4090009@redhat.com> References: <50769EC4.10001@redhat.com> <5076A027.4090009@redhat.com> Message-ID: <5076E1B1.70205@redhat.com> On 10/11/2012 12:32 PM, Martin Kosek wrote: > On 10/11/2012 12:26 PM, Tomas Babej wrote: >> Hi, >> >> This patch forces more consistency into ipa-server-install output. All >> descriptions of services that are not instances of >> SimpleServiceInstance are now in the following format: >> >> () >> >> Furthermore, start_creation method has been modified to support >> custom start and end messages. >> >> Sample output produced by this patch attached. >> >> https://fedorahosted.org/freeipa/ticket/3059 >> >> Tomas >> > Just based on reading the patch, this does not look right: > > - self.start_creation("Configuring certificate server", 210) > + self.start_creation("Configuring directory server for the CA", > + end_message="Done configuring directory server for the CA", > + show_service_name=True, runtime=210) > > Martin > Thanks, glitch fixed. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0018-2-Make-service-naming-in-ipa-server-install-consistent.patch Type: text/x-patch Size: 9902 bytes Desc: not available URL: From mkosek at redhat.com Thu Oct 11 15:14:18 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 11 Oct 2012 17:14:18 +0200 Subject: [Freeipa-devel] [PATCH] 1061 disable betxn plugins In-Reply-To: <5076C386.7040706@redhat.com> References: <507632B8.7060602@redhat.com> <5076BAA2.8080908@redhat.com> <5076BC29.5030708@redhat.com> <5076C386.7040706@redhat.com> Message-ID: <5076E24A.2040601@redhat.com> On 10/11/2012 03:03 PM, Rob Crittenden wrote: > Rob Crittenden wrote: >> Martin Kosek wrote: >>> On 10/11/2012 04:45 AM, Rob Crittenden wrote: >>>> 389-ds-base 1.3.0 was released to Fedora 18 updates-testing this >>>> week. There is >>>> the chance of deadlock in the schema compat plugin at the moment. We >>>> have a >>>> candidate patch for addressing it but it is not yet reviewed. >>>> >>>> This is an interim patch that disables betxn explicitly for now. It >>>> should be >>>> reversible later by reversing the update file. >>>> >>>> I have the update file for anyone that tries upgrading from F-17 to >>>> F-18, or >>>> has an existing F-18 install with 389-ds-base. Perhaps this is >>>> overkill and we >>>> can just go with the ldif for now. >>>> >>>> rob >>>> >>> >>> >>> I do not think that update file is an overkill, there might be people >>> upgrading >>> from F17, right? >>> >>> I found following issues: >>> >>> 1) Few whitespace errors: >>> >>> # git apply /home/mkosek/freeipa-rcrit-1061-betxn.patch >>> /home/mkosek/freeipa-rcrit-1061-betxn.patch:100: new blank line at EOF. >>> + >>> /home/mkosek/freeipa-rcrit-1061-betxn.patch:145: new blank line at EOF. >>> + >>> warning: 2 lines add whitespace errors. >>> >>> 2) Why do we replace "nsslapd-pluginType: preoperation" for all different >>> plugins? They already have nsslapd-pluginType set. >>> >>> Wouldn't updates that set "nsslapd-pluginbetxn: off: be enough? >>> >>> Martin >>> >> >> This was the recommendation from the 389-ds team. >> >> rob > > Whitespace removed. > > rob > Looks OK, I did not see any hangs. So ACK. Martin From jdennis at redhat.com Thu Oct 11 16:53:34 2012 From: jdennis at redhat.com (John Dennis) Date: Thu, 11 Oct 2012 12:53:34 -0400 Subject: [Freeipa-devel] [PATCH 75] log dogtag errors In-Reply-To: <4F9BF5BF.5030302@redhat.com> References: <201204201807.q3KI7VuR019115@int-mx11.intmail.prod.int.phx2.redhat.com> <4F9A5C8D.9000004@redhat.com> <4F9BF5BF.5030302@redhat.com> Message-ID: <5076F98E.7020901@redhat.com> On 04/28/2012 09:50 AM, John Dennis wrote: > On 04/27/2012 04:45 AM, Petr Viktorin wrote: >> On 04/20/2012 08:07 PM, John Dennis wrote: >>> Ticket #2622 >>> >>> If we get an error from dogtag we always did raise a >>> CertificateOperationError exception with a message describing the >>> problem. Unfortuanately that error message did not go into the log, >>> just sent back to the caller. The fix is to format the error message >>> and send the same message to both the log and use it to initialize the >>> CertificateOperationError exception. >>> >> >> The patch contains five hunks with almost exactly the same code, >> applying the same changes in each case. >> Wouldn't it make sense to move the _sslget call, parsing, and error >> handling to a common method? >> > > Yes it would and ordinarily I would have taken that approach. However on > IRC (or phone?) with Rob we decided not to perturb the code too much for > this particular issue because we intend to refactor the code later. This > was one of the last patches destined for 2.2 which is why we took the > more conservative approach. > I went back and looked at this. It's not practical to collapse everything into a common subroutine unless you paramaterize the heck out of a common subroutine. That's because all the patched locations have subtly different things going on, different parameters to sslget followed by different result parsing and handling. In retrospect I think it's clearer to keep things separate rather than one subroutine that needs a lot of parameters and/or convoluted logic to handle each unique case. Part of the problem is the dogtag interface. Every command has the potential to behave differently making it difficult to work with. I wrote this code originally and got it reduced to as many common parts as I could. At some point soon we'll be switching to a new dogtag REST interface which hopefully will allow for greater commonality due to interface consistency. In summary: I still stand by the original patch. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Thu Oct 11 17:41:38 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 11 Oct 2012 13:41:38 -0400 Subject: [Freeipa-devel] [PATCH] 1061 disable betxn plugins In-Reply-To: <5076E24A.2040601@redhat.com> References: <507632B8.7060602@redhat.com> <5076BAA2.8080908@redhat.com> <5076BC29.5030708@redhat.com> <5076C386.7040706@redhat.com> <5076E24A.2040601@redhat.com> Message-ID: <507704D2.4040104@redhat.com> Martin Kosek wrote: > On 10/11/2012 03:03 PM, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> Martin Kosek wrote: >>>> On 10/11/2012 04:45 AM, Rob Crittenden wrote: >>>>> 389-ds-base 1.3.0 was released to Fedora 18 updates-testing this >>>>> week. There is >>>>> the chance of deadlock in the schema compat plugin at the moment. We >>>>> have a >>>>> candidate patch for addressing it but it is not yet reviewed. >>>>> >>>>> This is an interim patch that disables betxn explicitly for now. It >>>>> should be >>>>> reversible later by reversing the update file. >>>>> >>>>> I have the update file for anyone that tries upgrading from F-17 to >>>>> F-18, or >>>>> has an existing F-18 install with 389-ds-base. Perhaps this is >>>>> overkill and we >>>>> can just go with the ldif for now. >>>>> >>>>> rob >>>>> >>>> >>>> >>>> I do not think that update file is an overkill, there might be people >>>> upgrading >>>> from F17, right? >>>> >>>> I found following issues: >>>> >>>> 1) Few whitespace errors: >>>> >>>> # git apply /home/mkosek/freeipa-rcrit-1061-betxn.patch >>>> /home/mkosek/freeipa-rcrit-1061-betxn.patch:100: new blank line at EOF. >>>> + >>>> /home/mkosek/freeipa-rcrit-1061-betxn.patch:145: new blank line at EOF. >>>> + >>>> warning: 2 lines add whitespace errors. >>>> >>>> 2) Why do we replace "nsslapd-pluginType: preoperation" for all different >>>> plugins? They already have nsslapd-pluginType set. >>>> >>>> Wouldn't updates that set "nsslapd-pluginbetxn: off: be enough? >>>> >>>> Martin >>>> >>> >>> This was the recommendation from the 389-ds team. >>> >>> rob >> >> Whitespace removed. >> >> rob >> > > Looks OK, I did not see any hangs. So ACK. > > Martin > pushed to master and ipa-3-0 rob From pviktori at redhat.com Fri Oct 12 08:12:44 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 12 Oct 2012 10:12:44 +0200 Subject: [Freeipa-devel] [PATCH] 0090 Pull translation files from Transifex Message-ID: <5077D0FC.9060300@redhat.com> Hello, There are lots of new translations, especially for French and Ukrainian. Unfortunately we didn't have a string freeze, 35 messages are new/changed since last POT push. Patch generated by: cd install/po make pull-po make update-po Message stats: ipa.pot has 1981 messages. There are 13 po translation files. bn_IN: 12/1981 0.6% 1969 untranslated, 0 fuzzy de: 32/1981 1.6% 1949 untranslated, 0 fuzzy es: 889/1981 44.9% 1092 untranslated, 0 fuzzy fr: 1803/1981 91.0% 178 untranslated, 0 fuzzy id: 85/1981 4.3% 1896 untranslated, 0 fuzzy ja: 140/1981 7.1% 1841 untranslated, 0 fuzzy kn: 235/1981 11.9% 1746 untranslated, 0 fuzzy nl: 1/1981 0.1% 1980 untranslated, 0 fuzzy pl: 451/1981 22.8% 1530 untranslated, 0 fuzzy ru: 366/1981 18.5% 1615 untranslated, 0 fuzzy tg: 105/1981 5.3% 1876 untranslated, 0 fuzzy uk: 1946/1981 98.2% 35 untranslated, 0 fuzzy zh_CN: 130/1981 6.6% 1851 untranslated, 0 fuzzy -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0090-Pull-translation-files-from-Transifex.patch Type: text/x-patch Size: 421732 bytes Desc: not available URL: From pviktori at redhat.com Fri Oct 12 08:35:24 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 12 Oct 2012 10:35:24 +0200 Subject: [Freeipa-devel] [PATCH 75] log dogtag errors In-Reply-To: <5076F98E.7020901@redhat.com> References: <201204201807.q3KI7VuR019115@int-mx11.intmail.prod.int.phx2.redhat.com> <4F9A5C8D.9000004@redhat.com> <4F9BF5BF.5030302@redhat.com> <5076F98E.7020901@redhat.com> Message-ID: <5077D64C.1080701@redhat.com> On 10/11/2012 06:53 PM, John Dennis wrote: > On 04/28/2012 09:50 AM, John Dennis wrote: >> On 04/27/2012 04:45 AM, Petr Viktorin wrote: >>> On 04/20/2012 08:07 PM, John Dennis wrote: >>>> Ticket #2622 >>>> >>>> If we get an error from dogtag we always did raise a >>>> CertificateOperationError exception with a message describing the >>>> problem. Unfortuanately that error message did not go into the log, >>>> just sent back to the caller. The fix is to format the error message >>>> and send the same message to both the log and use it to initialize the >>>> CertificateOperationError exception. >>>> >>> >>> The patch contains five hunks with almost exactly the same code, >>> applying the same changes in each case. >>> Wouldn't it make sense to move the _sslget call, parsing, and error >>> handling to a common method? >>> >> >> Yes it would and ordinarily I would have taken that approach. However on >> IRC (or phone?) with Rob we decided not to perturb the code too much for >> this particular issue because we intend to refactor the code later. This >> was one of the last patches destined for 2.2 which is why we took the >> more conservative approach. >> > > I went back and looked at this. It's not practical to collapse > everything into a common subroutine unless you paramaterize the heck out > of a common subroutine. That's because all the patched locations have > subtly different things going on, different parameters to sslget > followed by different result parsing and handling. In retrospect I think > it's clearer to keep things separate rather than one subroutine that > needs a lot of parameters and/or convoluted logic to handle each unique > case. I don't agree that it's clearer, but I guess that's debatable. > Part of the problem is the dogtag interface. Every command has the > potential to behave differently making it difficult to work with. I > wrote this code originally and got it reduced to as many common parts as > I could. At some point soon we'll be switching to a new dogtag REST > interface which hopefully will allow for greater commonality due to > interface consistency. > > In summary: I still stand by the original patch. > However, I see no reason to not use a method such as: def raise_certop_error(self, method_name, error=None, detail=None): """Log and raise a CertificateOperationError :param method_name: Name of the method in which the error occured :param error: Error string. If None, "Unable to communicate with CMS" is used. :param detail: Detailed or low-level information. Will be put in parentheses. """ to at least get rid of the repetition this patch is adding - almost the same format+log+raise sequence is used twice in each of the five hunks. -- Petr? From abokovoy at redhat.com Fri Oct 12 09:20:09 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 12 Oct 2012 12:20:09 +0300 Subject: [Freeipa-devel] [PATCH] 0082/0083 Handle NotFound exception when establishing trust In-Reply-To: <5076C815.9020500@redhat.com> References: <20121005132424.GQ17454@redhat.com> <506F0934.1070406@redhat.com> <20121005181452.GX17454@redhat.com> <5072C009.3080102@redhat.com> <20121008122228.GB17454@redhat.com> <50768E73.1080603@redhat.com> <20121011102709.GA17454@redhat.com> <5076A7F4.8000103@redhat.com> <20121011124404.GB17454@redhat.com> <5076C815.9020500@redhat.com> Message-ID: <20121012092009.GC17454@redhat.com> On Thu, 11 Oct 2012, Petr Viktorin wrote: >On 10/11/2012 02:44 PM, Alexander Bokovoy wrote: >>On Thu, 11 Oct 2012, Petr Viktorin wrote: >>>On 10/11/2012 12:27 PM, Alexander Bokovoy wrote: >>>>On Thu, 11 Oct 2012, Petr Viktorin wrote: >>>>>On 10/08/2012 02:22 PM, Alexander Bokovoy wrote: >>>>>>On Mon, 08 Oct 2012, Petr Vobornik wrote: >>>>>>>On 10/05/2012 08:14 PM, Alexander Bokovoy wrote: >>>>>>>>On Fri, 05 Oct 2012, Petr Vobornik wrote: >>>>>>>>>On 10/05/2012 03:24 PM, Alexander Bokovoy wrote: >>>>>>>>>>On Fri, 05 Oct 2012, Petr Vobornik wrote: >>>>>>>>>>>On 10/04/2012 05:06 PM, Alexander Bokovoy wrote: >>>>>>>>>>>> >>>>>>>>>>>>Hi, >>>>>>>>>>>> >>>>>>>>>>>>two attached patches attempt to solve >>>>>>>>>>>>https://fedorahosted.org/freeipa/ticket/3103 >>>>>>>>>>>> >>>>>>>>>>>>We cannot make educated guess where trusted domain's DNS >>>>>>>>>>>>server is >>>>>>>>>>>>located as we ended up with NotFound exception precisely >>>>>>>>>>>>because we >>>>>>>>>>>>were >>>>>>>>>>>>unable to discover trusted domain's domain controller location. >>>>>>>>>>>> >>>>>>>>>>>>Thus, all we can do is to suggest ways to fix the issue. Since >>>>>>>>>>>>suggestion becomes relatively long (multi-line, at least), it >>>>>>>>>>>>creates >>>>>>>>>>>>few issues for current exception error message handling: >>>>>>>>>>>>- root_logger does not use textui to format output >>>>>>>>>>>>- textui is only printing to standard output >>>>>>>>>>>>- multi-line error messages thus become non-wrapped >>>>>>>>>>>>- localizing such messages would become a harder context-wise. >>>>>>>>>>>> >>>>>>>>>>>>Web UI is showing error message as a single paragraph (

    ), >>>>>>>>>>>>all >>>>>>>>>>>>multi-line markup would be lost. >>>>>>>>>>>> >>>>>>>>>>>>In the end, I decided to support list-based multi-line error >>>>>>>>>>>>messages in >>>>>>>>>>>>PublicError class. Its constructor will join all list-based >>>>>>>>>>>>arguments >>>>>>>>>>>>into single string per argument (first patch). >>>>>>>>>>>> >>>>>>>>>>>>In Web UI I've added special text processing of error messages >>>>>>>>>>>>that >>>>>>>>>>>>splits message into multiple lines and wraps those which start >>>>>>>>>>>>with a >>>>>>>>>>>>TAB symbol into 'error-message-hinted' span to visually >>>>>>>>>>>>separate it >>>>>>>>>>>>from >>>>>>>>>>>>the rest of error message. Trust code uses this to display >>>>>>>>>>>>suggested CLI >>>>>>>>>>>>command to set up DNS forwarder (second patch). >>>>>>>>>>>> >>>>>>>>>>>>In the end, CLI shows such error message fine (note tabulated >>>>>>>>>>>>CLI >>>>>>>>>>>>command): >>>>>>>>>>>>----------------------------------------------------------------------- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>># ipa trust-add --type=ad --admin Administrator at ad.local1 >>>>>>>>>>>>--password >>>>>>>>>>>>ad.local1 >>>>>>>>>>>>Active directory domain administrator's password: ipa: ERROR: >>>>>>>>>>>>Unable to >>>>>>>>>>>>resolve domain controller for 'ad.local1' domain. IPA manages >>>>>>>>>>>>DNS, >>>>>>>>>>>>please configure forwarder to 'ad.local1' domain by using >>>>>>>>>>>>following >>>>>>>>>>>>CLI >>>>>>>>>>>>command. Please replace DNS_SERVER and IP_ADDRESS by name and >>>>>>>>>>>>address of >>>>>>>>>>>>the domain's name server: >>>>>>>>>>>>ipa dnszone-add ad.local1 --name-server=DNS_SERVER >>>>>>>>>>>>--admin-email='hostmaster at ad.local1' --force >>>>>>>>>>>>--forwarder=IP_ADDRESS >>>>>>>>>>>>--forward-policy=only >>>>>>>>>>>>When using Web UI, please create DNS zone for domain 'ad.local1' >>>>>>>>>>>>first >>>>>>>>>>>>and then set forwarder and forward policy >>>>>>>>>>>>----------------------------------------------------------------------- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>Web UI looks like this: >>>>>>>>>>>>http://abbra.fedorapeople.org/.paste/ui.png >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>You have undeclared identifier: lines. >>>>>>>>>>> >>>>>>>>>>>I recommend to run `jsl -conf jsl.conf` command in install/ui >>>>>>>>>>>folder >>>>>>>>>>>to prevent these issues. >>>>>>>>>>Fixed. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>I'm not convinced that "beautify" call should be in command >>>>>>>>>>>object. I >>>>>>>>>>>would rather see it in error_dialog. >>>>>>>>>>I moved everything to error_dialog and used $() selectors >>>>>>>>>>instead of >>>>>>>>>>directly playing with text. >>>>>>>>> >>>>>>>>>1) >>>>>>>>>+ var error_message = $('', {}); >>>>>>>>> >>>>>>>>>I would rather see a

    as a container. Span is and should >>>>>>>>>contain only inline elements. >>>>>>>>Fixed. >>>>>>>> >>>>>>>>>2) >>>>>>>>>var line_span = $('', { >>>>>>>>> class: 'error-message-hinted', >>>>>>>>> text: lines[i].substr(1) >>>>>>>>> }).appendTo(container); >>>>>>>>> >>>>>>>>>Why do you use for hinted message and

    for other lines? >>>>>>>>>Shouldn't we use

    for both? >>>>>>>>Fixed to use

    everywhere. >>>>>>>> >>>>>>>> >>>>>>>>>3) var line_span is declared twice. JS use function scope, not >>>>>>>>>block >>>>>>>>>scope. >>>>>>>>Fixed. >>>>>>>> >>>>>>>>Thanks for the review. New patch 0082 attached. >>>>>>>> >>>>>>>> >>>>>>>ACK on the UI part with a little change (updated patch attached): >>>>>>> class: 'error-message-hinted', >>>>>>>needs to be changed to >>>>>>> 'class': 'error-message-hinted', >>>>>>>because class is a keyword and should not be used this way. Sorry >>>>>>>that >>>>>>>I missed it before. >>>>>>Thanks! >>>>>> >>>>>> >>>>>>>The patch works as advertised. I would give ACK to the python part of >>>>>>>82 and patch 83 as well but probably someone more skilled in python >>>>>>>and ipa internals should do it. >>>>>>> >>>>>>>Why do you have to concatenate the value in PublicErrors' __init__ >>>>>>>method? Shouldn't it be a responsibility of error source (in this >>>>>>>case >>>>>>>'execute_ad' method)? - just a question, not an issue >>>>>>This is a good question and gives me some space to explain why certain >>>>>>decisions are made. >>>>>> >>>>>>The whole idea of the patch is to introduce a way to provide >>>>>>multi-line >>>>>>error messages as a feature of error handling in the FreeIPA >>>>>>framework. >>>>>> >>>>>>Suppose we had to join multiple lines always before creating an error >>>>>>object. This means we would have hundreds of '\n'.join() calls across >>>>>>the code. Besides maintenance burden, it would also make computational >>>>>>burden later if we would add proper content formating (which we >>>>>>don't do >>>>>>now for errors) -- since we would need to split strings later to >>>>>>reformat them. >>>>>> >>>>>>Python is flexible enough to discover parameter types which >>>>>>allows to design APIs that easer to use. "Easier to use" means least >>>>>>surprise for the caller rather than callee. So, if you pass multiple >>>>>>lines (list) of error message, each array element gets processed >>>>>>separately before displaying. >>>>>>So, in the end there is only one place where this processing happens, >>>>>>and it encapsulates all the knowledge required to accept multi-lines >>>>>>messages, regardless how they come, since it is applied uniformly to >>>>>>every >>>>>>argument of a constructor of a PublicError-derived class. >>>>>> >>>>> >>>>>Some of our errors already accept lists. From our doctest suite: >>>>> >>>>>File "/home/pviktori/freeipa/ipalib/errors.py", line 731, in >>>>>ipalib.errors.OverlapError >>>>>Failed example: >>>>> raise OverlapError(names=['givenname', 'login']) >>>>>Expected: >>>>> Traceback (most recent call last): >>>>> ... >>>>> OverlapError: overlapping arguments and options: ['givenname', >>>>>'login'] >>>>>Got: >>>>> Traceback (most recent call last): >>>>> File "/usr/lib64/python2.7/doctest.py", line 1289, in __run >>>>> compileflags, 1) in test.globs >>>>> File "", line 1, in >>>>> raise OverlapError(names=['givenname', 'login']) >>>>> OverlapError: overlapping arguments and options: u'givenname\nlogin' >>>>> >>>>>In this case, ['givenname', 'login'] is much better than >>>>>u'givenname\nlogin' (or givennamelogin, if we switched the >>>>>message from %r to %s). >>>>> >>>>> >>>>>I don't think what's best for trust-add's NotFound is the best thing >>>>>to do everywhere. >>>>Sure. Could you make a ticket so that I can investigate it more and find >>>>appropriate way to handle this? Perhaps an error class could define how >>>>it wants to treat its arguments? >>> >>>Sure. Please share findings of your investigation, then. >>> >>>https://fedorahosted.org/freeipa/ticket/3167 >>> >>>Basically, I think you generalized too much. The result is much more >>>complex (=less understandable, maintainable, changeable) than a >>>'\n'.join() when creating the error. >>> >>>> >>>>With the following patch I have this behavior: >>>>>>>from ipalib import errors >>>>>>>raise errors.PublicError(lines=['foo','bar'], format="You've got a >>>>>>>message: %(lines)s") >>>>Traceback (most recent call last): >>>> File "", line 1, in >>>>PublicError: You've got a message: foo >>>>bar >>>>>>>raise errors.OverlapError(names=['foo','bar']) >>>>Traceback (most recent call last): >>>> File "", line 1, in >>>>OverlapError: overlapping arguments and options: ['foo', 'bar'] >>> >>>The new patch adds even more complexity. Adding the conversions only >>>to error classes that need them (if any), as opposed to PublicError >>>with an option to turn them off, would be much more straightforward. >>After discussing more with Petr on irc, I came up with the following >>patch: allow `instructions' additional parameter to PublicError() to >>add instructions to an error message. >> >>Trust's error message is converted to show its use. >> > >The rationale: >The need for multi-line error messages was prompted by requests that >IPA should either fix/prevent errors itself, or print out more >detailed instructions for the user. >Automatic joining of lists is problematic, because it repurposes a >standard datatype for the needs of a fairly specific use case. >Converting individual arguments that need it is better than a blanket >approach. >An extra argument for instructions allows us to separate the error >message and instructions in the future, if we need to e.g. add more >complex formatting than the \t. > > >Patch comments: >This needs some tests to verify it's right and prevent regressions. >Please rename the convert_keyword function to e.g. format_instructions. >It's not necessary to add the instructions to self.msg, that one is >not user-friendly. >Please wrap the long line in errors.py. Updated the patch with new test case and fixes. Also split out trust.py changes to a separate patch. Both attached. -- / Alexander Bokovoy -------------- next part -------------- >From 317f59aab403f17ef280832ba8202d63250f5c18 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 12 Oct 2012 12:13:59 +0300 Subject: [PATCH 7/8] Add instructions support to PublicError When long additional text should follow the error message, one can supply instructions parameter to a class derived from PublicError. This will cause following text added to the error message: Additional instructions: `instructions' optional parameter could be a list or anything that coerces into unicode(). List entries will be joined with '\n'. https://fedorahosted.org/freeipa/ticket/3167 --- ipalib/errors.py | 21 ++++++++++++--------- tests/test_ipalib/test_errors.py | 17 +++++++++++++++++ 2 files changed, 29 insertions(+), 9 deletions(-) diff --git a/ipalib/errors.py b/ipalib/errors.py index 7f1113200b6b2cd80ea9156d347211e4d978b9be..a6c8e76836c0b4c9809f891a423abaf51d057108 100644 --- a/ipalib/errors.py +++ b/ipalib/errors.py @@ -265,17 +265,20 @@ class PublicError(StandardError): ) self.format = format self.forwarded = False - def convert_keyword(value): - if isinstance(value, list): - result=u'\n'.join(map(lambda line: unicode(line), value)) - return result - return value - kwargs = dict(map(lambda (k,v): (k, convert_keyword(v)), kw.items())) - self.msg = self.format % kwargs + self.msg = self.format % kw if isinstance(self.format, basestring): - self.strerror = ugettext(self.format) % kwargs + self.strerror = ugettext(self.format) % kw else: - self.strerror = self.format % kwargs + self.strerror = self.format % kw + if 'instructions' in kw: + def convert_instructions(value): + if isinstance(value, list): + result=u'\n'.join(map(lambda line: unicode(line), value)) + return result + return value + instructions = u'\n'.join((unicode(_('Additional instructions:')), + convert_instructions(kw['instructions']))) + self.strerror = u'\n'.join((self.strerror, instructions)) else: if isinstance(message, (Gettext, NGettext)): message = unicode(message) diff --git a/tests/test_ipalib/test_errors.py b/tests/test_ipalib/test_errors.py index 2fcdc56c804891b89870adc8fb7eeaed9a686803..1421e7844a7068605568bccf78715669dfe0d8ec 100644 --- a/tests/test_ipalib/test_errors.py +++ b/tests/test_ipalib/test_errors.py @@ -318,6 +318,23 @@ class test_PublicError(PublicExceptionTester): assert inst.text is kw['text'] assert inst.number is kw['number'] + # Test with instructions: + # first build up "instructions", then get error and search for + # lines of instructions appended to the end of the strerror + # despite the parameter 'instructions' not existing in the format + instructions = u"The quick brown fox jumps over the lazy dog".split() + # this expression checks if each word of instructions + # exists in a string as a separate line, with right order + regexp = re.compile('(?ims).*' + + ''.join(map(lambda x: '(%s).*' % (x), + instructions)) + + '$') + inst = subclass(instructions=instructions, **kw) + assert inst.format is subclass.format + assert_equal(inst.instructions, instructions) + inst_match = regexp.match(inst.strerror).groups() + assert_equal(list(inst_match),list(instructions)) + def test_public_errors(): """ -- 1.7.12 -------------- next part -------------- >From d386180e7d60cef609e5c9d85b769de6425a4614 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 12 Oct 2012 12:14:24 +0300 Subject: [PATCH 8/8] Use PublicError instructions support for trust-add case when domain is not found https://fedorahosted.org/freeipa/ticket/3167 --- ipalib/plugins/trust.py | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index 8632d42df578d81b6fdbcd9e5be8979994699206..9fc6c5ad4638fa237632876207cc85c64ade6503 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -346,32 +346,33 @@ class trust_add(LDAPCreate): try: result = trustinstance.join_ad_full_credentials(keys[-1], realm_server, realm_admin, realm_passwd) except errors.NotFound, e: - error_message=[_("Unable to resolve domain controller for '%s' domain. ") % (keys[-1])] + error_message=_("Unable to resolve domain controller for '%s' domain. ") % (keys[-1]) + instructions=[] if dns_container_exists(self.obj.backend): try: dns_zone = api.Command.dnszone_show(keys[-1])['result'] if ('idnsforwardpolicy' in dns_zone) and dns_zone['idnsforwardpolicy'][0] == u'only': - error_message.append(_("Forward policy is defined for it in IPA DNS, " + instructions.append(_("Forward policy is defined for it in IPA DNS, " "perhaps forwarder points to incorrect host?")) except (errors.NotFound, KeyError) as e: - error_message.append(_("IPA manages DNS, please configure forwarder to " + instructions.append(_("IPA manages DNS, please configure forwarder to " "'%(domain)s' domain using following CLI command. " "Make sure to replace DNS_SERVER and IP_ADDRESS by " "actual values corresponding to the trusted domain's " "DNS server:") % dict(domain=keys[-1])) # tab character at the beginning of a multiline error message will be replaced # in the web UI by a colorful hint. Does not affect CLI. - error_message.append(_("\tipa dnszone-add %(domain)s --name-server=[DNS_SERVER] " + instructions.append(_("\tipa dnszone-add %(domain)s --name-server=[DNS_SERVER] " "--admin-email='hostmaster@%(domain)s' " "--force --forwarder=[IP_ADDRESS] " "--forward-policy=only") % dict(domain=keys[-1])) - error_message.append(_("When using Web UI, please create DNS zone for domain '%(domain)s' " + instructions.append(_("When using Web UI, please create DNS zone for domain '%(domain)s' " "first and then set forwarder and forward policy.") % dict(domain=keys[-1])) else: - error_message.append(_("Since IPA does not manage DNS records, ensure DNS " + instructions.append(_("Since IPA does not manage DNS records, ensure DNS " "is configured to resolve '%(domain)s' domain from " "IPA hosts and back.") % dict(domain=keys[-1])) - raise errors.NotFound(reason=error_message) + raise errors.NotFound(reason=error_message, instructions=instructions) if result is None: raise errors.ValidationError(name=_('AD Trust setup'), -- 1.7.12 From pviktori at redhat.com Fri Oct 12 10:55:29 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 12 Oct 2012 12:55:29 +0200 Subject: [Freeipa-devel] [PATCHES] backport of Firefox extension to FreeIPA 2.2 In-Reply-To: <5076C1D5.20403@redhat.com> References: <5076C1D5.20403@redhat.com> Message-ID: <5077F721.5060003@redhat.com> On 10/11/2012 02:55 PM, Petr Vobornik wrote: > This bunch of patches is a backport of Firefox extension to FreeIPA 2.2. > > First apply pvoborni's patches then pviktori's. > I tested several replication/upgrade scenarios. Upgrading from 2.2.0 and to master works fine. ACK for the Python part. -- Petr? From pviktori at redhat.com Fri Oct 12 11:30:01 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 12 Oct 2012 13:30:01 +0200 Subject: [Freeipa-devel] [PATCH] 0082/0083 Handle NotFound exception when establishing trust In-Reply-To: <20121012092009.GC17454@redhat.com> References: <20121005132424.GQ17454@redhat.com> <506F0934.1070406@redhat.com> <20121005181452.GX17454@redhat.com> <5072C009.3080102@redhat.com> <20121008122228.GB17454@redhat.com> <50768E73.1080603@redhat.com> <20121011102709.GA17454@redhat.com> <5076A7F4.8000103@redhat.com> <20121011124404.GB17454@redhat.com> <5076C815.9020500@redhat.com> <20121012092009.GC17454@redhat.com> Message-ID: <5077FF39.9040905@redhat.com> On 10/12/2012 11:20 AM, Alexander Bokovoy wrote: > On Thu, 11 Oct 2012, Petr Viktorin wrote: >> On 10/11/2012 02:44 PM, Alexander Bokovoy wrote: >>> On Thu, 11 Oct 2012, Petr Viktorin wrote: >>>> On 10/11/2012 12:27 PM, Alexander Bokovoy wrote: >>>>> On Thu, 11 Oct 2012, Petr Viktorin wrote: >>>>>> On 10/08/2012 02:22 PM, Alexander Bokovoy wrote: >>>>>>> On Mon, 08 Oct 2012, Petr Vobornik wrote: >>>>>>>> On 10/05/2012 08:14 PM, Alexander Bokovoy wrote: >>>>>>>>> On Fri, 05 Oct 2012, Petr Vobornik wrote: >>>>>>>>>> On 10/05/2012 03:24 PM, Alexander Bokovoy wrote: >>>>>>>>>>> On Fri, 05 Oct 2012, Petr Vobornik wrote: >>>>>>>>>>>> On 10/04/2012 05:06 PM, Alexander Bokovoy wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> two attached patches attempt to solve >>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3103 >>>>>>>>>>>>> >>>>>>>>>>>>> We cannot make educated guess where trusted domain's DNS >>>>>>>>>>>>> server is >>>>>>>>>>>>> located as we ended up with NotFound exception precisely >>>>>>>>>>>>> because we >>>>>>>>>>>>> were >>>>>>>>>>>>> unable to discover trusted domain's domain controller >>>>>>>>>>>>> location. >>>>>>>>>>>>> >>>>>>>>>>>>> Thus, all we can do is to suggest ways to fix the issue. Since >>>>>>>>>>>>> suggestion becomes relatively long (multi-line, at least), it >>>>>>>>>>>>> creates >>>>>>>>>>>>> few issues for current exception error message handling: >>>>>>>>>>>>> - root_logger does not use textui to format output >>>>>>>>>>>>> - textui is only printing to standard output >>>>>>>>>>>>> - multi-line error messages thus become non-wrapped >>>>>>>>>>>>> - localizing such messages would become a harder context-wise. >>>>>>>>>>>>> >>>>>>>>>>>>> Web UI is showing error message as a single paragraph (

    ), >>>>>>>>>>>>> all >>>>>>>>>>>>> multi-line markup would be lost. >>>>>>>>>>>>> >>>>>>>>>>>>> In the end, I decided to support list-based multi-line error >>>>>>>>>>>>> messages in >>>>>>>>>>>>> PublicError class. Its constructor will join all list-based >>>>>>>>>>>>> arguments >>>>>>>>>>>>> into single string per argument (first patch). >>>>>>>>>>>>> >>>>>>>>>>>>> In Web UI I've added special text processing of error messages >>>>>>>>>>>>> that >>>>>>>>>>>>> splits message into multiple lines and wraps those which start >>>>>>>>>>>>> with a >>>>>>>>>>>>> TAB symbol into 'error-message-hinted' span to visually >>>>>>>>>>>>> separate it >>>>>>>>>>>>> from >>>>>>>>>>>>> the rest of error message. Trust code uses this to display >>>>>>>>>>>>> suggested CLI >>>>>>>>>>>>> command to set up DNS forwarder (second patch). >>>>>>>>>>>>> >>>>>>>>>>>>> In the end, CLI shows such error message fine (note tabulated >>>>>>>>>>>>> CLI >>>>>>>>>>>>> command): >>>>>>>>>>>>> ----------------------------------------------------------------------- >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> # ipa trust-add --type=ad --admin Administrator at ad.local1 >>>>>>>>>>>>> --password >>>>>>>>>>>>> ad.local1 >>>>>>>>>>>>> Active directory domain administrator's password: ipa: ERROR: >>>>>>>>>>>>> Unable to >>>>>>>>>>>>> resolve domain controller for 'ad.local1' domain. IPA manages >>>>>>>>>>>>> DNS, >>>>>>>>>>>>> please configure forwarder to 'ad.local1' domain by using >>>>>>>>>>>>> following >>>>>>>>>>>>> CLI >>>>>>>>>>>>> command. Please replace DNS_SERVER and IP_ADDRESS by name and >>>>>>>>>>>>> address of >>>>>>>>>>>>> the domain's name server: >>>>>>>>>>>>> ipa dnszone-add ad.local1 --name-server=DNS_SERVER >>>>>>>>>>>>> --admin-email='hostmaster at ad.local1' --force >>>>>>>>>>>>> --forwarder=IP_ADDRESS >>>>>>>>>>>>> --forward-policy=only >>>>>>>>>>>>> When using Web UI, please create DNS zone for domain >>>>>>>>>>>>> 'ad.local1' >>>>>>>>>>>>> first >>>>>>>>>>>>> and then set forwarder and forward policy >>>>>>>>>>>>> ----------------------------------------------------------------------- >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Web UI looks like this: >>>>>>>>>>>>> http://abbra.fedorapeople.org/.paste/ui.png >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> You have undeclared identifier: lines. >>>>>>>>>>>> >>>>>>>>>>>> I recommend to run `jsl -conf jsl.conf` command in install/ui >>>>>>>>>>>> folder >>>>>>>>>>>> to prevent these issues. >>>>>>>>>>> Fixed. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> I'm not convinced that "beautify" call should be in command >>>>>>>>>>>> object. I >>>>>>>>>>>> would rather see it in error_dialog. >>>>>>>>>>> I moved everything to error_dialog and used $() selectors >>>>>>>>>>> instead of >>>>>>>>>>> directly playing with text. >>>>>>>>>> >>>>>>>>>> 1) >>>>>>>>>> + var error_message = $('', {}); >>>>>>>>>> >>>>>>>>>> I would rather see a

    as a container. Span is and should >>>>>>>>>> contain only inline elements. >>>>>>>>> Fixed. >>>>>>>>> >>>>>>>>>> 2) >>>>>>>>>> var line_span = $('', { >>>>>>>>>> class: 'error-message-hinted', >>>>>>>>>> text: lines[i].substr(1) >>>>>>>>>> }).appendTo(container); >>>>>>>>>> >>>>>>>>>> Why do you use for hinted message and

    for other lines? >>>>>>>>>> Shouldn't we use

    for both? >>>>>>>>> Fixed to use

    everywhere. >>>>>>>>> >>>>>>>>> >>>>>>>>>> 3) var line_span is declared twice. JS use function scope, not >>>>>>>>>> block >>>>>>>>>> scope. >>>>>>>>> Fixed. >>>>>>>>> >>>>>>>>> Thanks for the review. New patch 0082 attached. >>>>>>>>> >>>>>>>>> >>>>>>>> ACK on the UI part with a little change (updated patch attached): >>>>>>>> class: 'error-message-hinted', >>>>>>>> needs to be changed to >>>>>>>> 'class': 'error-message-hinted', >>>>>>>> because class is a keyword and should not be used this way. Sorry >>>>>>>> that >>>>>>>> I missed it before. >>>>>>> Thanks! >>>>>>> >>>>>>> >>>>>>>> The patch works as advertised. I would give ACK to the python >>>>>>>> part of >>>>>>>> 82 and patch 83 as well but probably someone more skilled in python >>>>>>>> and ipa internals should do it. >>>>>>>> >>>>>>>> Why do you have to concatenate the value in PublicErrors' __init__ >>>>>>>> method? Shouldn't it be a responsibility of error source (in this >>>>>>>> case >>>>>>>> 'execute_ad' method)? - just a question, not an issue >>>>>>> This is a good question and gives me some space to explain why >>>>>>> certain >>>>>>> decisions are made. >>>>>>> >>>>>>> The whole idea of the patch is to introduce a way to provide >>>>>>> multi-line >>>>>>> error messages as a feature of error handling in the FreeIPA >>>>>>> framework. >>>>>>> >>>>>>> Suppose we had to join multiple lines always before creating an >>>>>>> error >>>>>>> object. This means we would have hundreds of '\n'.join() calls >>>>>>> across >>>>>>> the code. Besides maintenance burden, it would also make >>>>>>> computational >>>>>>> burden later if we would add proper content formating (which we >>>>>>> don't do >>>>>>> now for errors) -- since we would need to split strings later to >>>>>>> reformat them. >>>>>>> >>>>>>> Python is flexible enough to discover parameter types which >>>>>>> allows to design APIs that easer to use. "Easier to use" means least >>>>>>> surprise for the caller rather than callee. So, if you pass multiple >>>>>>> lines (list) of error message, each array element gets processed >>>>>>> separately before displaying. >>>>>>> So, in the end there is only one place where this processing >>>>>>> happens, >>>>>>> and it encapsulates all the knowledge required to accept multi-lines >>>>>>> messages, regardless how they come, since it is applied uniformly to >>>>>>> every >>>>>>> argument of a constructor of a PublicError-derived class. >>>>>>> >>>>>> >>>>>> Some of our errors already accept lists. From our doctest suite: >>>>>> >>>>>> File "/home/pviktori/freeipa/ipalib/errors.py", line 731, in >>>>>> ipalib.errors.OverlapError >>>>>> Failed example: >>>>>> raise OverlapError(names=['givenname', 'login']) >>>>>> Expected: >>>>>> Traceback (most recent call last): >>>>>> ... >>>>>> OverlapError: overlapping arguments and options: ['givenname', >>>>>> 'login'] >>>>>> Got: >>>>>> Traceback (most recent call last): >>>>>> File "/usr/lib64/python2.7/doctest.py", line 1289, in __run >>>>>> compileflags, 1) in test.globs >>>>>> File "", line 1, in >>>>>> >>>>>> raise OverlapError(names=['givenname', 'login']) >>>>>> OverlapError: overlapping arguments and options: u'givenname\nlogin' >>>>>> >>>>>> In this case, ['givenname', 'login'] is much better than >>>>>> u'givenname\nlogin' (or givennamelogin, if we switched the >>>>>> message from %r to %s). >>>>>> >>>>>> >>>>>> I don't think what's best for trust-add's NotFound is the best thing >>>>>> to do everywhere. >>>>> Sure. Could you make a ticket so that I can investigate it more and >>>>> find >>>>> appropriate way to handle this? Perhaps an error class could define >>>>> how >>>>> it wants to treat its arguments? >>>> >>>> Sure. Please share findings of your investigation, then. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3167 >>>> >>>> Basically, I think you generalized too much. The result is much more >>>> complex (=less understandable, maintainable, changeable) than a >>>> '\n'.join() when creating the error. >>>> >>>>> >>>>> With the following patch I have this behavior: >>>>>>>> from ipalib import errors >>>>>>>> raise errors.PublicError(lines=['foo','bar'], format="You've got a >>>>>>>> message: %(lines)s") >>>>> Traceback (most recent call last): >>>>> File "", line 1, in >>>>> PublicError: You've got a message: foo >>>>> bar >>>>>>>> raise errors.OverlapError(names=['foo','bar']) >>>>> Traceback (most recent call last): >>>>> File "", line 1, in >>>>> OverlapError: overlapping arguments and options: ['foo', 'bar'] >>>> >>>> The new patch adds even more complexity. Adding the conversions only >>>> to error classes that need them (if any), as opposed to PublicError >>>> with an option to turn them off, would be much more straightforward. >>> After discussing more with Petr on irc, I came up with the following >>> patch: allow `instructions' additional parameter to PublicError() to >>> add instructions to an error message. >>> >>> Trust's error message is converted to show its use. >>> >> >> The rationale: >> The need for multi-line error messages was prompted by requests that >> IPA should either fix/prevent errors itself, or print out more >> detailed instructions for the user. >> Automatic joining of lists is problematic, because it repurposes a >> standard datatype for the needs of a fairly specific use case. >> Converting individual arguments that need it is better than a blanket >> approach. >> An extra argument for instructions allows us to separate the error >> message and instructions in the future, if we need to e.g. add more >> complex formatting than the \t. >> >> >> Patch comments: >> This needs some tests to verify it's right and prevent regressions. >> Please rename the convert_keyword function to e.g. format_instructions. >> It's not necessary to add the instructions to self.msg, that one is >> not user-friendly. >> Please wrap the long line in errors.py. > Updated the patch with new test case and fixes. Also split out trust.py > changes to a separate patch. > > Both attached. > > This works, however the test regexp doesn't do what it claims (doesn't check if each string is on a separate line). Checking the entire message would make the test more straightforward. Squash in the attached patch if you agree. I haven't tested the ipa-trust-add code as I don't have an AD machine, but it looks good. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: more-straightforward-test.patch Type: text/x-patch Size: 1367 bytes Desc: not available URL: From rcritten at redhat.com Fri Oct 12 13:30:16 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 12 Oct 2012 09:30:16 -0400 Subject: [Freeipa-devel] [PATCH] 0090 Pull translation files from Transifex In-Reply-To: <5077D0FC.9060300@redhat.com> References: <5077D0FC.9060300@redhat.com> Message-ID: <50781B68.4020500@redhat.com> Petr Viktorin wrote: > Hello, > There are lots of new translations, especially for French and Ukrainian. > Unfortunately we didn't have a string freeze, 35 messages are > new/changed since last POT push. > > Patch generated by: > cd install/po > make pull-po > make update-po > > Message stats: > ipa.pot has 1981 messages. There are 13 po translation files. > bn_IN: 12/1981 0.6% 1969 untranslated, 0 fuzzy > de: 32/1981 1.6% 1949 untranslated, 0 fuzzy > es: 889/1981 44.9% 1092 untranslated, 0 fuzzy > fr: 1803/1981 91.0% 178 untranslated, 0 fuzzy > id: 85/1981 4.3% 1896 untranslated, 0 fuzzy > ja: 140/1981 7.1% 1841 untranslated, 0 fuzzy > kn: 235/1981 11.9% 1746 untranslated, 0 fuzzy > nl: 1/1981 0.1% 1980 untranslated, 0 fuzzy > pl: 451/1981 22.8% 1530 untranslated, 0 fuzzy > ru: 366/1981 18.5% 1615 untranslated, 0 fuzzy > tg: 105/1981 5.3% 1876 untranslated, 0 fuzzy > uk: 1946/1981 98.2% 35 untranslated, 0 fuzzy > zh_CN: 130/1981 6.6% 1851 untranslated, 0 fuzzy pushed to master and ipa-3-0 rob From abokovoy at redhat.com Fri Oct 12 13:30:17 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 12 Oct 2012 16:30:17 +0300 Subject: [Freeipa-devel] [PATCH] 0082/0083 Handle NotFound exception when establishing trust In-Reply-To: <5077FF39.9040905@redhat.com> References: <20121005181452.GX17454@redhat.com> <5072C009.3080102@redhat.com> <20121008122228.GB17454@redhat.com> <50768E73.1080603@redhat.com> <20121011102709.GA17454@redhat.com> <5076A7F4.8000103@redhat.com> <20121011124404.GB17454@redhat.com> <5076C815.9020500@redhat.com> <20121012092009.GC17454@redhat.com> <5077FF39.9040905@redhat.com> Message-ID: <20121012133017.GD17454@redhat.com> On Fri, 12 Oct 2012, Petr Viktorin wrote: >>>>>Sure. Please share findings of your investigation, then. >>>>> >>>>>https://fedorahosted.org/freeipa/ticket/3167 >>>>> >>>>>Basically, I think you generalized too much. The result is much more >>>>>complex (=less understandable, maintainable, changeable) than a >>>>>'\n'.join() when creating the error. >>>>> >>>>>> >>>>>>With the following patch I have this behavior: >>>>>>>>>from ipalib import errors >>>>>>>>>raise errors.PublicError(lines=['foo','bar'], format="You've got a >>>>>>>>>message: %(lines)s") >>>>>>Traceback (most recent call last): >>>>>> File "", line 1, in >>>>>>PublicError: You've got a message: foo >>>>>>bar >>>>>>>>>raise errors.OverlapError(names=['foo','bar']) >>>>>>Traceback (most recent call last): >>>>>> File "", line 1, in >>>>>>OverlapError: overlapping arguments and options: ['foo', 'bar'] >>>>> >>>>>The new patch adds even more complexity. Adding the conversions only >>>>>to error classes that need them (if any), as opposed to PublicError >>>>>with an option to turn them off, would be much more straightforward. >>>>After discussing more with Petr on irc, I came up with the following >>>>patch: allow `instructions' additional parameter to PublicError() to >>>>add instructions to an error message. >>>> >>>>Trust's error message is converted to show its use. >>>> >>> >>>The rationale: >>>The need for multi-line error messages was prompted by requests that >>>IPA should either fix/prevent errors itself, or print out more >>>detailed instructions for the user. >>>Automatic joining of lists is problematic, because it repurposes a >>>standard datatype for the needs of a fairly specific use case. >>>Converting individual arguments that need it is better than a blanket >>>approach. >>>An extra argument for instructions allows us to separate the error >>>message and instructions in the future, if we need to e.g. add more >>>complex formatting than the \t. >>> >>> >>>Patch comments: >>>This needs some tests to verify it's right and prevent regressions. >>>Please rename the convert_keyword function to e.g. format_instructions. >>>It's not necessary to add the instructions to self.msg, that one is >>>not user-friendly. >>>Please wrap the long line in errors.py. >>Updated the patch with new test case and fixes. Also split out trust.py >>changes to a separate patch. >> >>Both attached. >> >> > >This works, however the test regexp doesn't do what it claims >(doesn't check if each string is on a separate line). >Checking the entire message would make the test more straightforward. >Squash in the attached patch if you agree. I purposedly went regexp way because of _("Additional instructions"). I know that our testsuite is not passing when running it localized so it may be a moot point but avoiding dependency on a localized content in the test was one specific reason for the approach. -- / Alexander Bokovoy From pviktori at redhat.com Fri Oct 12 13:48:44 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 12 Oct 2012 15:48:44 +0200 Subject: [Freeipa-devel] [PATCH] 0082/0083 Handle NotFound exception when establishing trust In-Reply-To: <20121012133017.GD17454@redhat.com> References: <20121005181452.GX17454@redhat.com> <5072C009.3080102@redhat.com> <20121008122228.GB17454@redhat.com> <50768E73.1080603@redhat.com> <20121011102709.GA17454@redhat.com> <5076A7F4.8000103@redhat.com> <20121011124404.GB17454@redhat.com> <5076C815.9020500@redhat.com> <20121012092009.GC17454@redhat.com> <5077FF39.9040905@redhat.com> <20121012133017.GD17454@redhat.com> Message-ID: <50781FBC.4000905@redhat.com> On 10/12/2012 03:30 PM, Alexander Bokovoy wrote: > On Fri, 12 Oct 2012, Petr Viktorin wrote: >>>>>> Sure. Please share findings of your investigation, then. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3167 >>>>>> >>>>>> Basically, I think you generalized too much. The result is much more >>>>>> complex (=less understandable, maintainable, changeable) than a >>>>>> '\n'.join() when creating the error. >>>>>> >>>>>>> >>>>>>> With the following patch I have this behavior: >>>>>>>>>> from ipalib import errors >>>>>>>>>> raise errors.PublicError(lines=['foo','bar'], format="You've >>>>>>>>>> got a >>>>>>>>>> message: %(lines)s") >>>>>>> Traceback (most recent call last): >>>>>>> File "", line 1, in >>>>>>> PublicError: You've got a message: foo >>>>>>> bar >>>>>>>>>> raise errors.OverlapError(names=['foo','bar']) >>>>>>> Traceback (most recent call last): >>>>>>> File "", line 1, in >>>>>>> OverlapError: overlapping arguments and options: ['foo', 'bar'] >>>>>> >>>>>> The new patch adds even more complexity. Adding the conversions only >>>>>> to error classes that need them (if any), as opposed to PublicError >>>>>> with an option to turn them off, would be much more straightforward. >>>>> After discussing more with Petr on irc, I came up with the following >>>>> patch: allow `instructions' additional parameter to PublicError() to >>>>> add instructions to an error message. >>>>> >>>>> Trust's error message is converted to show its use. >>>>> >>>> >>>> The rationale: >>>> The need for multi-line error messages was prompted by requests that >>>> IPA should either fix/prevent errors itself, or print out more >>>> detailed instructions for the user. >>>> Automatic joining of lists is problematic, because it repurposes a >>>> standard datatype for the needs of a fairly specific use case. >>>> Converting individual arguments that need it is better than a blanket >>>> approach. >>>> An extra argument for instructions allows us to separate the error >>>> message and instructions in the future, if we need to e.g. add more >>>> complex formatting than the \t. >>>> >>>> >>>> Patch comments: >>>> This needs some tests to verify it's right and prevent regressions. >>>> Please rename the convert_keyword function to e.g. format_instructions. >>>> It's not necessary to add the instructions to self.msg, that one is >>>> not user-friendly. >>>> Please wrap the long line in errors.py. >>> Updated the patch with new test case and fixes. Also split out trust.py >>> changes to a separate patch. >>> >>> Both attached. >>> >>> >> >> This works, however the test regexp doesn't do what it claims (doesn't >> check if each string is on a separate line). >> Checking the entire message would make the test more straightforward. >> Squash in the attached patch if you agree. > I purposedly went regexp way because of _("Additional instructions"). I > know that our testsuite is not passing when running it localized so it > may be a moot point but avoiding dependency on a localized content in > the test was one specific reason for the approach. > ACKed off-list, the test issue can be sorted out separately. I think this should wait for a larger-scale, more thought-out rework of the test suite. At first glance, your approach seemed too ad-hoc and complicated. The problem with complicated code in tests is that if code is complicated, you need to test it -- leading to a loop. (At second glance, the regexp actually turned out incorrect, but that's less of a point.) I'd be glad if we can come up with a good solution to testing i18n issues everywhere, but this level of complexity in individual tests is not it. -- Petr? From rcritten at redhat.com Fri Oct 12 13:51:35 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 12 Oct 2012 09:51:35 -0400 Subject: [Freeipa-devel] [PATCH] 0082/0083 Handle NotFound exception when establishing trust In-Reply-To: <20121012133017.GD17454@redhat.com> References: <20121005181452.GX17454@redhat.com> <5072C009.3080102@redhat.com> <20121008122228.GB17454@redhat.com> <50768E73.1080603@redhat.com> <20121011102709.GA17454@redhat.com> <5076A7F4.8000103@redhat.com> <20121011124404.GB17454@redhat.com> <5076C815.9020500@redhat.com> <20121012092009.GC17454@redhat.com> <5077FF39.9040905@redhat.com> <20121012133017.GD17454@redhat.com> Message-ID: <50782067.7040609@redhat.com> Alexander Bokovoy wrote: > On Fri, 12 Oct 2012, Petr Viktorin wrote: >>>>>> Sure. Please share findings of your investigation, then. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3167 >>>>>> >>>>>> Basically, I think you generalized too much. The result is much more >>>>>> complex (=less understandable, maintainable, changeable) than a >>>>>> '\n'.join() when creating the error. >>>>>> >>>>>>> >>>>>>> With the following patch I have this behavior: >>>>>>>>>> from ipalib import errors >>>>>>>>>> raise errors.PublicError(lines=['foo','bar'], format="You've >>>>>>>>>> got a >>>>>>>>>> message: %(lines)s") >>>>>>> Traceback (most recent call last): >>>>>>> File "", line 1, in >>>>>>> PublicError: You've got a message: foo >>>>>>> bar >>>>>>>>>> raise errors.OverlapError(names=['foo','bar']) >>>>>>> Traceback (most recent call last): >>>>>>> File "", line 1, in >>>>>>> OverlapError: overlapping arguments and options: ['foo', 'bar'] >>>>>> >>>>>> The new patch adds even more complexity. Adding the conversions only >>>>>> to error classes that need them (if any), as opposed to PublicError >>>>>> with an option to turn them off, would be much more straightforward. >>>>> After discussing more with Petr on irc, I came up with the following >>>>> patch: allow `instructions' additional parameter to PublicError() to >>>>> add instructions to an error message. >>>>> >>>>> Trust's error message is converted to show its use. >>>>> >>>> >>>> The rationale: >>>> The need for multi-line error messages was prompted by requests that >>>> IPA should either fix/prevent errors itself, or print out more >>>> detailed instructions for the user. >>>> Automatic joining of lists is problematic, because it repurposes a >>>> standard datatype for the needs of a fairly specific use case. >>>> Converting individual arguments that need it is better than a blanket >>>> approach. >>>> An extra argument for instructions allows us to separate the error >>>> message and instructions in the future, if we need to e.g. add more >>>> complex formatting than the \t. >>>> >>>> >>>> Patch comments: >>>> This needs some tests to verify it's right and prevent regressions. >>>> Please rename the convert_keyword function to e.g. format_instructions. >>>> It's not necessary to add the instructions to self.msg, that one is >>>> not user-friendly. >>>> Please wrap the long line in errors.py. >>> Updated the patch with new test case and fixes. Also split out trust.py >>> changes to a separate patch. >>> >>> Both attached. >>> >>> >> >> This works, however the test regexp doesn't do what it claims (doesn't >> check if each string is on a separate line). >> Checking the entire message would make the test more straightforward. >> Squash in the attached patch if you agree. > I purposedly went regexp way because of _("Additional instructions"). I > know that our testsuite is not passing when running it localized so it > may be a moot point but avoiding dependency on a localized content in > the test was one specific reason for the approach. > I pushed these both to master and ipa-3-0 since the only controversy is in the way we are testing this. I wanted to get this fix in upstream. rob From abokovoy at redhat.com Fri Oct 12 14:11:27 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 12 Oct 2012 17:11:27 +0300 Subject: [Freeipa-devel] [PATCH] 0082/0083 Handle NotFound exception when establishing trust In-Reply-To: <50781FBC.4000905@redhat.com> References: <20121008122228.GB17454@redhat.com> <50768E73.1080603@redhat.com> <20121011102709.GA17454@redhat.com> <5076A7F4.8000103@redhat.com> <20121011124404.GB17454@redhat.com> <5076C815.9020500@redhat.com> <20121012092009.GC17454@redhat.com> <5077FF39.9040905@redhat.com> <20121012133017.GD17454@redhat.com> <50781FBC.4000905@redhat.com> Message-ID: <20121012141127.GE17454@redhat.com> On Fri, 12 Oct 2012, Petr Viktorin wrote: >>I purposedly went regexp way because of _("Additional instructions"). I >>know that our testsuite is not passing when running it localized so it >>may be a moot point but avoiding dependency on a localized content in >>the test was one specific reason for the approach. >> > >ACKed off-list, the test issue can be sorted out separately. > > >I think this should wait for a larger-scale, more thought-out rework >of the test suite. >At first glance, your approach seemed too ad-hoc and complicated. The >problem with complicated code in tests is that if code is >complicated, you need to test it -- leading to a loop. >(At second glance, the regexp actually turned out incorrect, but >that's less of a point.) > >I'd be glad if we can come up with a good solution to testing i18n >issues everywhere, but this level of complexity in individual tests >is not it. Sure, let's think about better way to make testsuite resistant to environmental changes. Below, for the record, some of our ideas from off-list discussion: - force 'make-test' running with pre-set LC_ALL to something we expect working; - use special locale 'test.utf8' to force using 'test' translation. test.po file would contain fixed translations that we can rely on in the test suite; - this special test translation can also test cases we know about as being broken for lower/upper Unicode transformation (single-direction changes like dotless i to I to i and others) where regressions might appear. -- / Alexander Bokovoy From pviktori at redhat.com Fri Oct 12 15:04:57 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 12 Oct 2012 17:04:57 +0200 Subject: [Freeipa-devel] Proposal: Use argparse for option parsing Message-ID: <50783199.4050803@redhat.com> Hello, I read through https://fedorahosted.org/freeipa/ticket/3060 and noticed that the requirements are similar to what an existing library offers. The optparse module we currently use for CLI option parsing is deprecated[1]. The replacement is called argparse, which is part of the Python 2.7 standard library. Out of the box, it provides several features we either lack or had to handle manually, namely: * supporting sub-commands [2] * producing more informative usage messages [2] * handling both optional and positional arguments [3] * as well as including a number of other more minor improvements on the optparse API. [3] The package has also been backported to Python 2.6, the only catch there is that it's not in the standard library. Not much of our code calls optparse directly, so switching shouldn't be a major effort (within the scope of reorganizing the help system). In exchange we get better CLI help messages, forward compatibility, and reuse of proven code instead of our own solutions. [1] http://docs.python.org/library/optparse.html [2] http://code.google.com/p/argparse/ [3] yum info python-argparse (EPEL-6) -- Petr? From mkosek at redhat.com Fri Oct 12 15:20:22 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 12 Oct 2012 17:20:22 +0200 Subject: [Freeipa-devel] Unit tests failing on F18 Message-ID: <50783536.8020007@redhat.com> Hello, I was investigating global unit test failure on Fedora 18 for most of today, I would like to share results I found so far. Unit test and its related scripts on F18 now reports NSS BUSY exception, just like this one: # ./make-testcert Traceback (most recent call last): File "./make-testcert", line 134, in sys.exit(makecert(reqdir)) File "./make-testcert", line 111, in makecert add=True) File "./make-testcert", line 68, in run result = self.execute(method, *args, **options) File "/root/freeipa-master2/ipalib/backend.py", line 146, in execute raise error #pylint: disable=E0702 ipalib.errors.NetworkError: cannot connect to 'http://vm-042.idm.lab.bos.redhat.com/ipa/session/xml': [Errno -8053] (SEC_ERROR_BUSY) NSS could not shutdown. Objects are still in use. Something In F18 must have changed, this worked before... But leaked NSSConnection objects without proper close() now ends with the exception above. In case of make-testcert script, the exception is raised because the script does the following procedure: 1) connect, do one command 2) disconnect 3) connect, do second command However, during disconnect, NSSConnection is leaked which makes NSS very uncomfortable during second connection atempt (and nss_shutdown()). I managed to fix this issue with attached patch. ./make-testcert or "./make-test tests/test_xmlrpc/test_group_plugin.py" works fine now. But global "./make-test" still fails, I think there is some remaining NSSConnection leak, I suspect there is something wrong with how we use our context (threading.local object). It looses a connection or some other thread invoked in ldap2 module may be kicking in, here is my debug output: CONTEXT[xmlclient] = Test a simple LDAP bind using ldap2 ... SKIP: No directory manager password in /root/.ipa/.dmpw Test the `ipaserver.rpcserver.jsonserver.unmarshal` method. ... ok tests.test_ipaserver.test_rpcserver.test_session.test_mount ... CONTEXT 150714476: GET languages CONTEXT[xmlclient] = None The connection is in the context, but then something happens and it is gone. Then, unit tests try to connect again and NSS fails. I would be really glad if somebody with a knowledge of NSS or how threads in Python/IPA work could give me some advice... Thanks! Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: close-ssl-socket.patch Type: text/x-patch Size: 1242 bytes Desc: not available URL: From dpal at redhat.com Fri Oct 12 15:45:37 2012 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 12 Oct 2012 11:45:37 -0400 Subject: [Freeipa-devel] Proposal: Use argparse for option parsing In-Reply-To: <50783199.4050803@redhat.com> References: <50783199.4050803@redhat.com> Message-ID: <50783B21.5010802@redhat.com> On 10/12/2012 11:04 AM, Petr Viktorin wrote: > Hello, > I read through https://fedorahosted.org/freeipa/ticket/3060 and > noticed that the requirements are similar to what an existing library > offers. > > The optparse module we currently use for CLI option parsing is > deprecated[1]. The replacement is called argparse, which is part of > the Python 2.7 standard library. Out of the box, it provides several > features we either lack or had to handle manually, namely: > * supporting sub-commands [2] > * producing more informative usage messages [2] > * handling both optional and positional arguments [3] > * as well as including a number of other more minor improvements on > the optparse API. [3] > > The package has also been backported to Python 2.6, the only catch > there is that it's not in the standard library. > > > Not much of our code calls optparse directly, so switching shouldn't > be a major effort (within the scope of reorganizing the help system). > In exchange we get better CLI help messages, forward compatibility, > and reuse of proven code instead of our own solutions. > > > [1] http://docs.python.org/library/optparse.html > [2] http://code.google.com/p/argparse/ > [3] yum info python-argparse (EPEL-6) > The ticket is IMO nice to have. Does it provide any value for other main commands? If so can you reference other tickets that it would help with. I am not sure I want the switch for just help. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jdennis at redhat.com Fri Oct 12 16:16:45 2012 From: jdennis at redhat.com (John Dennis) Date: Fri, 12 Oct 2012 12:16:45 -0400 Subject: [Freeipa-devel] Unit tests failing on F18 In-Reply-To: <50783536.8020007@redhat.com> References: <50783536.8020007@redhat.com> Message-ID: <5078426D.40001@redhat.com> On 10/12/2012 11:20 AM, Martin Kosek wrote: > Hello, > > I was investigating global unit test failure on Fedora 18 for most of today, I > would like to share results I found so far. > > Unit test and its related scripts on F18 now reports NSS BUSY exception, just > like this one: > > # ./make-testcert > Traceback (most recent call last): > File "./make-testcert", line 134, in > sys.exit(makecert(reqdir)) > File "./make-testcert", line 111, in makecert > add=True) > File "./make-testcert", line 68, in run > result = self.execute(method, *args, **options) > File "/root/freeipa-master2/ipalib/backend.py", line 146, in execute > raise error #pylint: disable=E0702 > ipalib.errors.NetworkError: cannot connect to > 'http://vm-042.idm.lab.bos.redhat.com/ipa/session/xml': [Errno -8053] > (SEC_ERROR_BUSY) NSS could not shutdown. Objects are still in use. > > Something In F18 must have changed, this worked before... But leaked > NSSConnection objects without proper close() now ends with the exception above. > > In case of make-testcert script, the exception is raised because the script > does the following procedure: > > 1) connect, do one command > 2) disconnect > 3) connect, do second command > > However, during disconnect, NSSConnection is leaked which makes NSS very > uncomfortable during second connection atempt (and nss_shutdown()). I managed > to fix this issue with attached patch. ./make-testcert or "./make-test > tests/test_xmlrpc/test_group_plugin.py" works fine now. > > But global "./make-test" still fails, I think there is some remaining > NSSConnection leak, I suspect there is something wrong with how we use our > context (threading.local object). It looses a connection or some other thread > invoked in ldap2 module may be kicking in, here is my debug output: > > CONTEXT[xmlclient] = > > Test a simple LDAP bind using ldap2 ... SKIP: No directory manager password in > /root/.ipa/.dmpw > Test the `ipaserver.rpcserver.jsonserver.unmarshal` method. ... ok > tests.test_ipaserver.test_rpcserver.test_session.test_mount ... CONTEXT > 150714476: GET languages > > CONTEXT[xmlclient] = None > > The connection is in the context, but then something happens and it is gone. > Then, unit tests try to connect again and NSS fails. > > I would be really glad if somebody with a knowledge of NSS or how threads in > Python/IPA work could give me some advice... O.K. I'll take a look at it. I seem to recall Rob looked into something similar a couple of days ago. Rob, do you have any additional information to share? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Fri Oct 12 16:21:09 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 12 Oct 2012 12:21:09 -0400 Subject: [Freeipa-devel] Unit tests failing on F18 In-Reply-To: <5078426D.40001@redhat.com> References: <50783536.8020007@redhat.com> <5078426D.40001@redhat.com> Message-ID: <50784375.7080206@redhat.com> John Dennis wrote: > On 10/12/2012 11:20 AM, Martin Kosek wrote: >> Hello, >> >> I was investigating global unit test failure on Fedora 18 for most of >> today, I >> would like to share results I found so far. >> >> Unit test and its related scripts on F18 now reports NSS BUSY >> exception, just >> like this one: >> >> # ./make-testcert >> Traceback (most recent call last): >> File "./make-testcert", line 134, in >> sys.exit(makecert(reqdir)) >> File "./make-testcert", line 111, in makecert >> add=True) >> File "./make-testcert", line 68, in run >> result = self.execute(method, *args, **options) >> File "/root/freeipa-master2/ipalib/backend.py", line 146, in execute >> raise error #pylint: disable=E0702 >> ipalib.errors.NetworkError: cannot connect to >> 'http://vm-042.idm.lab.bos.redhat.com/ipa/session/xml': [Errno -8053] >> (SEC_ERROR_BUSY) NSS could not shutdown. Objects are still in use. >> >> Something In F18 must have changed, this worked before... But leaked >> NSSConnection objects without proper close() now ends with the >> exception above. >> >> In case of make-testcert script, the exception is raised because the >> script >> does the following procedure: >> >> 1) connect, do one command >> 2) disconnect >> 3) connect, do second command >> >> However, during disconnect, NSSConnection is leaked which makes NSS very >> uncomfortable during second connection atempt (and nss_shutdown()). I >> managed >> to fix this issue with attached patch. ./make-testcert or "./make-test >> tests/test_xmlrpc/test_group_plugin.py" works fine now. >> >> But global "./make-test" still fails, I think there is some remaining >> NSSConnection leak, I suspect there is something wrong with how we use >> our >> context (threading.local object). It looses a connection or some other >> thread >> invoked in ldap2 module may be kicking in, here is my debug output: >> >> CONTEXT[xmlclient] = >> >> Test a simple LDAP bind using ldap2 ... SKIP: No directory manager >> password in >> /root/.ipa/.dmpw >> Test the `ipaserver.rpcserver.jsonserver.unmarshal` method. ... ok >> tests.test_ipaserver.test_rpcserver.test_session.test_mount ... CONTEXT >> 150714476: GET languages >> >> CONTEXT[xmlclient] = None >> >> The connection is in the context, but then something happens and it is >> gone. >> Then, unit tests try to connect again and NSS fails. >> >> I would be really glad if somebody with a knowledge of NSS or how >> threads in >> Python/IPA work could give me some advice... > > O.K. I'll take a look at it. I seem to recall Rob looked into something > similar a couple of days ago. Rob, do you have any additional > information to share? > > Nothing to add. I looked at this briefly yesterday but nothing jumped out at me. I think this may be unrelated to the previous problem I investigated. It very well could be we are not closing a connection somewhere. rob From rcritten at redhat.com Fri Oct 12 18:06:54 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 12 Oct 2012 14:06:54 -0400 Subject: [Freeipa-devel] Announcing FreeIPA v3.0.0 Release Message-ID: <50785C3E.8070202@redhat.com> The FreeIPA team is proud to announce version FreeIPA v3.0.0. It can be downloaded from http://www.freeipa.org/Downloads. A build is on the way to updates-testing for Fedora 18. FreeIPA 3.0.0 works well in Fedora 17 but we will not be providing a build in the Fedora 17 following Fedora's policy of not moving forward with releases. There is a known issue installing a replica with a dogtag CA in Fedora 18. We are continuing to investigate. Non-CA replica installation is fine, and upgrading a replica with a CA is unaffected. FreeIPA will be participating in a Fedora 18 Test Day next Monday, October 15. For details see http://fedoraproject.org/wiki/Test_Day:2012-10-15_FreeIPA == Highlights in 3.0.0 == * Support for AD Trust * Per-domain DNS permissions * DNS persistent search enabled by default, new zones are seen immediately * New DNS resolver library * Migration improvements * The last administrator cannot be removed or disabled * Forms-based password reset * Redesigned action panels in UI * Sessions for command-line users * Tool to configure automount client, ipa-client-automount * NTLM password hash is generated for existing users on first use of IPA cross-realm environment based on their Kerberos keys without requiring a password change. * Secure identifiers compatible with Active Directory are generated automatically for existing users upon set up of IPA cross-realm environment. * Use certmonger to renew CA subsystem certificates * Support for DNS zone transfers to non-IPA slaves * Internal change to LDAP Distinguished Name handling to be more robust * Better support for Internet Explorer 9 in the UI * Allow multiple servers on client install command-line and configuring without DNS discovery. * Cooperate with new 389-ds-base winsync POSIX plugin so that AD POSIX attribute can be synced with IPA. * Improvements to schema upgrade process. * Exclude some attributes from replication. * Notify success on add, delete and update in UI. * Set the e-mail attribute on new users by default. * SSH public key format has been changed to OpenSSH-style public keys. * Support for the Dogtag CA version 10 * New ipa-client-install option to disable OpenSSH client configuration. * Expand Referential Integrity checks on hosts, SUDO and HBAC rule referential attributes * Run the CLEANALLRUV task when deleting a replication agreement to remove replication meta-data about removed master. See the ipa-replica-manage man page for the list of new commands related to CLEANALLRUV command. * Try to prevent orphaning other servers when deleting a master. * Add missing indices for automount and principal aliases which will improve performance. * Provide a new Firefox extension for configuring the browser. Firefox 15 deprecated the interface we used in the past to set the Kerberos negotiation directives. This new extension will be used on Firefox 15 and beyond, and the older interface for older browsers. * Man page improvements * A SID can be created as the last step of ipa-adtrust-install. * Create a default fallback group for AD trust users. * Support for 389-ds-base 1.3.0. * Move CRL publish directory to IPA owned directory * Add uniqueness plugin configuration for sudorule names. * The initial IPA server with a dogtag CA is configured to generate CRLs. Subsequent masters are configured to not generate CRLs. The CRL is available on a non-generating master at http://fqdn.example.com/ipa/crl/MasterCRL.bin. == Upgrading == An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. Please note, that 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-devel mailing list: http://www.redhat.com/mailman/listinfo/freeipa-devel == Detailed Changelog since 3.0.0 rc2 == Alexander Bokovoy (7): * support multi-line error messages in exceptions * Handle NotFound exception when establishing trust * Fix wrong RID for Domain Admins in the examples of trust commands * Add cifs principal to S4U2Proxy targets only when running ipa-adtrust-install * Make sure samba{,4}-winbind-krb5-locator package is not used with trusts * Add instructions support to PublicError * Use PublicError instructions support for trust-add case when domain is not found Jan Cholasta (1): * Do not show full SSH public keys in command output by default. Martin Kosek (3): * Minor fixes for default SMB group * Move CRL publish directory to IPA owned directory * Fix CA CRL migration crash in ipa-upgradeconfig Petr Viktorin (4): * ipa-upgradeconfig: Remove the upgrade_httpd_selinux function * replica-install: Don't copy Firefox config extension files if they're not in the replica file * Create Firefox extension on upgrade and replica-install * Pull translation files from Transifex Petr Vobornik (1): * Add mime type to httpd ipa.conf for xpi exetension Rob Crittenden (6): * Add uniqueness plugin configuration for sudorule cn * Set renewal time for the CA audit certificate to 720 days. * Fix CS replication management. * Configure the initial CA as the CRL generator. * Explicitly disable betxn plugins for the time being. * Become IPA 3.0.0 Simo Sorce (2): * Fix trust attributes for ipa trust-add * Use stricter requirement for krb5-server Sumit Bose (2): * ipa-adtrust-install: create fallback group with ldif file * ipadb: reload trust information if domain is not known Tomas Babej (1): * Notify user about necessary ports in ipa-client-install From rcritten at redhat.com Fri Oct 12 19:00:29 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 12 Oct 2012 15:00:29 -0400 Subject: [Freeipa-devel] [PATCH] 1062 fix dogtag replication Message-ID: <507868CD.5080109@redhat.com> This patch changes the replication protocol from SSL to TLS. This will fix installing a replica CA along with an updated version of dogtag that fixes other issues. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1062-dogtag.patch Type: text/x-diff Size: 1098 bytes Desc: not available URL: From mkosek at redhat.com Mon Oct 15 06:27:06 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 15 Oct 2012 08:27:06 +0200 Subject: [Freeipa-devel] Unit tests failing on F18 In-Reply-To: <5078426D.40001@redhat.com> References: <50783536.8020007@redhat.com> <5078426D.40001@redhat.com> Message-ID: <507BACBA.3090902@redhat.com> On 10/12/2012 06:16 PM, John Dennis wrote: > On 10/12/2012 11:20 AM, Martin Kosek wrote: >> Hello, >> >> I was investigating global unit test failure on Fedora 18 for most of today, I >> would like to share results I found so far. >> >> Unit test and its related scripts on F18 now reports NSS BUSY exception, just >> like this one: >> >> # ./make-testcert >> Traceback (most recent call last): >> File "./make-testcert", line 134, in >> sys.exit(makecert(reqdir)) >> File "./make-testcert", line 111, in makecert >> add=True) >> File "./make-testcert", line 68, in run >> result = self.execute(method, *args, **options) >> File "/root/freeipa-master2/ipalib/backend.py", line 146, in execute >> raise error #pylint: disable=E0702 >> ipalib.errors.NetworkError: cannot connect to >> 'http://vm-042.idm.lab.bos.redhat.com/ipa/session/xml': [Errno -8053] >> (SEC_ERROR_BUSY) NSS could not shutdown. Objects are still in use. >> >> Something In F18 must have changed, this worked before... But leaked >> NSSConnection objects without proper close() now ends with the exception above. >> >> In case of make-testcert script, the exception is raised because the script >> does the following procedure: >> >> 1) connect, do one command >> 2) disconnect >> 3) connect, do second command >> >> However, during disconnect, NSSConnection is leaked which makes NSS very >> uncomfortable during second connection atempt (and nss_shutdown()). I managed >> to fix this issue with attached patch. ./make-testcert or "./make-test >> tests/test_xmlrpc/test_group_plugin.py" works fine now. >> >> But global "./make-test" still fails, I think there is some remaining >> NSSConnection leak, I suspect there is something wrong with how we use our >> context (threading.local object). It looses a connection or some other thread >> invoked in ldap2 module may be kicking in, here is my debug output: >> >> CONTEXT[xmlclient] = >> >> Test a simple LDAP bind using ldap2 ... SKIP: No directory manager password in >> /root/.ipa/.dmpw >> Test the `ipaserver.rpcserver.jsonserver.unmarshal` method. ... ok >> tests.test_ipaserver.test_rpcserver.test_session.test_mount ... CONTEXT >> 150714476: GET languages >> >> CONTEXT[xmlclient] = None >> >> The connection is in the context, but then something happens and it is gone. >> Then, unit tests try to connect again and NSS fails. >> >> I would be really glad if somebody with a knowledge of NSS or how threads in >> Python/IPA work could give me some advice... > > O.K. I'll take a look at it. I seem to recall Rob looked into something similar > a couple of days ago. Rob, do you have any additional information to share? Great, with your NSS+Python knowledge this should be walk in the park :-) Any luck with investigation of this issue? Thanks, Martin From mkosek at redhat.com Mon Oct 15 06:37:17 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 15 Oct 2012 08:37:17 +0200 Subject: [Freeipa-devel] Unit tests failing on F18 In-Reply-To: <50784375.7080206@redhat.com> References: <50783536.8020007@redhat.com> <5078426D.40001@redhat.com> <50784375.7080206@redhat.com> Message-ID: <507BAF1D.2080203@redhat.com> On 10/12/2012 06:21 PM, Rob Crittenden wrote: > John Dennis wrote: >> On 10/12/2012 11:20 AM, Martin Kosek wrote: >>> Hello, >>> >>> I was investigating global unit test failure on Fedora 18 for most of >>> today, I >>> would like to share results I found so far. >>> >>> Unit test and its related scripts on F18 now reports NSS BUSY >>> exception, just >>> like this one: >>> >>> # ./make-testcert >>> Traceback (most recent call last): >>> File "./make-testcert", line 134, in >>> sys.exit(makecert(reqdir)) >>> File "./make-testcert", line 111, in makecert >>> add=True) >>> File "./make-testcert", line 68, in run >>> result = self.execute(method, *args, **options) >>> File "/root/freeipa-master2/ipalib/backend.py", line 146, in execute >>> raise error #pylint: disable=E0702 >>> ipalib.errors.NetworkError: cannot connect to >>> 'http://vm-042.idm.lab.bos.redhat.com/ipa/session/xml': [Errno -8053] >>> (SEC_ERROR_BUSY) NSS could not shutdown. Objects are still in use. >>> >>> Something In F18 must have changed, this worked before... But leaked >>> NSSConnection objects without proper close() now ends with the >>> exception above. >>> >>> In case of make-testcert script, the exception is raised because the >>> script >>> does the following procedure: >>> >>> 1) connect, do one command >>> 2) disconnect >>> 3) connect, do second command >>> >>> However, during disconnect, NSSConnection is leaked which makes NSS very >>> uncomfortable during second connection atempt (and nss_shutdown()). I >>> managed >>> to fix this issue with attached patch. ./make-testcert or "./make-test >>> tests/test_xmlrpc/test_group_plugin.py" works fine now. >>> >>> But global "./make-test" still fails, I think there is some remaining >>> NSSConnection leak, I suspect there is something wrong with how we use >>> our >>> context (threading.local object). It looses a connection or some other >>> thread >>> invoked in ldap2 module may be kicking in, here is my debug output: >>> >>> CONTEXT[xmlclient] = >>> >>> Test a simple LDAP bind using ldap2 ... SKIP: No directory manager >>> password in >>> /root/.ipa/.dmpw >>> Test the `ipaserver.rpcserver.jsonserver.unmarshal` method. ... ok >>> tests.test_ipaserver.test_rpcserver.test_session.test_mount ... CONTEXT >>> 150714476: GET languages >>> >>> CONTEXT[xmlclient] = None >>> >>> The connection is in the context, but then something happens and it is >>> gone. >>> Then, unit tests try to connect again and NSS fails. >>> >>> I would be really glad if somebody with a knowledge of NSS or how >>> threads in >>> Python/IPA work could give me some advice... >> >> O.K. I'll take a look at it. I seem to recall Rob looked into something >> similar a couple of days ago. Rob, do you have any additional >> information to share? >> >> > > Nothing to add. I looked at this briefly yesterday but nothing jumped out at > me. I think this may be unrelated to the previous problem I investigated. It > very well could be we are not closing a connection somewhere. > > rob Yes, we are not. I fixed it in one place (patch in my original e-mail). With the patch, one could run at least some parts of the unit test. I assume we are simply not treating initializing and shutting down of NSS correctly in some places (also with regards to threads), but I have not found a fix yet. Martin From mkosek at redhat.com Mon Oct 15 08:32:24 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 15 Oct 2012 10:32:24 +0200 Subject: [Freeipa-devel] [Freeipa-users] Announcing FreeIPA v3.0.0 Release In-Reply-To: <50785C3E.8070202@redhat.com> References: <50785C3E.8070202@redhat.com> Message-ID: <507BCA18.3000302@redhat.com> On 10/12/2012 08:06 PM, Rob Crittenden wrote: > The FreeIPA team is proud to announce version FreeIPA v3.0.0. > > It can be downloaded from http://www.freeipa.org/Downloads. Correction: FreeIPA 3.0.0 can be downloaded from http://www.freeipa.org/page/Downloads Martin From pspacek at redhat.com Mon Oct 15 08:38:41 2012 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 15 Oct 2012 10:38:41 +0200 Subject: [Freeipa-devel] [PATCH 0079] Update NEWS file for 2.0 release Message-ID: <507BCB91.1060702@redhat.com> Hello, Update NEWS file for 2.0 release -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0079-Update-NEWS-file-for-2.0-release.patch Type: text/x-patch Size: 1905 bytes Desc: not available URL: From mkosek at redhat.com Mon Oct 15 10:58:59 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 15 Oct 2012 12:58:59 +0200 Subject: [Freeipa-devel] [PATCH] 1062 fix dogtag replication In-Reply-To: <507868CD.5080109@redhat.com> References: <507868CD.5080109@redhat.com> Message-ID: <507BEC73.6050800@redhat.com> On 10/12/2012 09:00 PM, Rob Crittenden wrote: > This patch changes the replication protocol from SSL to TLS. This will fix > installing a replica CA along with an updated version of dogtag that fixes > other issues. > > rob > I tested 2.0 -> 3.0 and 3.0 -> 3.0 CA replicas and the recent dogtag + ipa with this patch worked fine. ACK. Pushed to master, ipa-3-0. Martin From pspacek at redhat.com Mon Oct 15 11:10:26 2012 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 15 Oct 2012 13:10:26 +0200 Subject: [Freeipa-devel] [PATCH 0078] Use automatic connection management in LDAP modification code to prevent potential deadlock In-Reply-To: <50742B7B.2070205@redhat.com> References: <5072E75E.1050305@redhat.com> <20121009112157.GF2593@redhat.com> <50742B7B.2070205@redhat.com> Message-ID: <507BEF22.8070708@redhat.com> On 10/09/2012 03:49 PM, Petr Spacek wrote: > On 10/09/2012 01:21 PM, Adam Tkac wrote: >> On Mon, Oct 08, 2012 at 04:46:54PM +0200, Petr Spacek wrote: >>> Hello, >>> >>> Use automatic connection management in LDAP modification code to >>> prevent potential deadlock. >>> >>> Without this patch the plugin will deadlock when modify_ldap_common() >>> is called with PTR synchronization enabled and only single >>> connection is available in the connection pool. >> >> Nack >> >> If I read the patch correctly, it leaves unused ldap_conn parameters in >> ldap_modify_do() and modify_soa_record() functions. >> >> Those params are always NULL so they can be safely removed. Please also remove >> the "autoconn" variable from ldap_modify_do() > > My intent was to keep the same connection management abilities as are in > ldap_query(): You can avoid repetitive ldap_pool_get/putconnection() calls by > passing connection via parameter. > > I can remove it if it isn't worth. (Actually *_modify_*() functions do not use > this capability now.) I forgot to send the patch after our discussion on IRC. Attached patch removes unused parameters. > Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0078-2-Use-automatic-connection-management-in-LDAP-modifica.patch Type: text/x-patch Size: 5563 bytes Desc: not available URL: From pviktori at redhat.com Mon Oct 15 12:45:13 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 15 Oct 2012 14:45:13 +0200 Subject: [Freeipa-devel] [PATCH] 0091 ipautil.run: Log the command line before running the command Message-ID: <507C0559.9010605@redhat.com> As I was debugging code that calls long-running or failing commands, I got tired of the invocation being logged after the command is done. This patch should improve the logging. https://fedorahosted.org/freeipa/ticket/3174 --- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0091-ipautil.run-Log-the-command-line-before-running-the-.patch Type: text/x-patch Size: 2223 bytes Desc: not available URL: From atkac at redhat.com Mon Oct 15 12:57:47 2012 From: atkac at redhat.com (Adam Tkac) Date: Mon, 15 Oct 2012 14:57:47 +0200 Subject: [Freeipa-devel] [PATCH 0079] Update NEWS file for 2.0 release In-Reply-To: <507BCB91.1060702@redhat.com> References: <507BCB91.1060702@redhat.com> Message-ID: <20121015125746.GA9925@redhat.com> On Mon, Oct 15, 2012 at 10:38:41AM +0200, Petr Spacek wrote: > Hello, > > Update NEWS file for 2.0 release Hi Peter, are you OK with this version of NEWS? (patch attached) A -- Adam Tkac, Red Hat, Inc. -------------- next part -------------- >From bcd017c75978e2f78976bb8a2b6d47af26df429a Mon Sep 17 00:00:00 2001 From: Petr Spacek Date: Mon, 15 Oct 2012 10:37:01 +0200 Subject: [PATCH] Update NEWS file for 2.0 release. Signed-off-by: Petr Spacek Signed-off-by: Adam Tkac --- NEWS | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/NEWS b/NEWS index 02e4845..4312741 100644 --- a/NEWS +++ b/NEWS @@ -1,3 +1,37 @@ +2.0 +====== +[1] SOA serial number can be incremented automatically after each change + in LDAP database. (Configuration option "serial_autoincrement".) + +[2] It was possible to DoS named service via quiery which contained + $ character. CVE-2012-3429 was fixed. + +[3] DNS Dynamic Update returns codes NOTAUTH and REFUSED properly. + +[4] BIND doesn't refuse to start if initial connection times out. + +[5] Object renaming (LDAP moddn) in persistent mode is handled properly. + +[6] Internal record cache is flushed properly after reconnection + to the LDAP server (in configurations with persistent search). + +[7] Simple time-based deadlock detection code was added. Error message + is printed after 10*(timeout) seconds. + Some deadlocks in various situations with low connection count were fixed. + +[8] Libdns interface version >= 90 is supported properly. + +[9] Zone transfers were fixed. Records with non-FQDNs are handled properly. + +[10] Logging was improved. + +[11] Memory leaks in dynamic update, persistent search, ldap_query + and configurations with multiple plugin instances were fixed. + +[12] Version numbering format changed to: [features].[bugfixes] + +[13] Many other bugfixes + 1.1.0rc1 ====== -- 1.7.11.7 From rcritten at redhat.com Mon Oct 15 12:59:10 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 15 Oct 2012 08:59:10 -0400 Subject: [Freeipa-devel] Unit tests failing on F18 In-Reply-To: <507BAF1D.2080203@redhat.com> References: <50783536.8020007@redhat.com> <5078426D.40001@redhat.com> <50784375.7080206@redhat.com> <507BAF1D.2080203@redhat.com> Message-ID: <507C089E.3050106@redhat.com> Martin Kosek wrote: > On 10/12/2012 06:21 PM, Rob Crittenden wrote: >> John Dennis wrote: >>> On 10/12/2012 11:20 AM, Martin Kosek wrote: >>>> Hello, >>>> >>>> I was investigating global unit test failure on Fedora 18 for most of >>>> today, I >>>> would like to share results I found so far. >>>> >>>> Unit test and its related scripts on F18 now reports NSS BUSY >>>> exception, just >>>> like this one: >>>> >>>> # ./make-testcert >>>> Traceback (most recent call last): >>>> File "./make-testcert", line 134, in >>>> sys.exit(makecert(reqdir)) >>>> File "./make-testcert", line 111, in makecert >>>> add=True) >>>> File "./make-testcert", line 68, in run >>>> result = self.execute(method, *args, **options) >>>> File "/root/freeipa-master2/ipalib/backend.py", line 146, in execute >>>> raise error #pylint: disable=E0702 >>>> ipalib.errors.NetworkError: cannot connect to >>>> 'http://vm-042.idm.lab.bos.redhat.com/ipa/session/xml': [Errno -8053] >>>> (SEC_ERROR_BUSY) NSS could not shutdown. Objects are still in use. >>>> >>>> Something In F18 must have changed, this worked before... But leaked >>>> NSSConnection objects without proper close() now ends with the >>>> exception above. >>>> >>>> In case of make-testcert script, the exception is raised because the >>>> script >>>> does the following procedure: >>>> >>>> 1) connect, do one command >>>> 2) disconnect >>>> 3) connect, do second command >>>> >>>> However, during disconnect, NSSConnection is leaked which makes NSS very >>>> uncomfortable during second connection atempt (and nss_shutdown()). I >>>> managed >>>> to fix this issue with attached patch. ./make-testcert or "./make-test >>>> tests/test_xmlrpc/test_group_plugin.py" works fine now. >>>> >>>> But global "./make-test" still fails, I think there is some remaining >>>> NSSConnection leak, I suspect there is something wrong with how we use >>>> our >>>> context (threading.local object). It looses a connection or some other >>>> thread >>>> invoked in ldap2 module may be kicking in, here is my debug output: >>>> >>>> CONTEXT[xmlclient] = >>>> >>>> Test a simple LDAP bind using ldap2 ... SKIP: No directory manager >>>> password in >>>> /root/.ipa/.dmpw >>>> Test the `ipaserver.rpcserver.jsonserver.unmarshal` method. ... ok >>>> tests.test_ipaserver.test_rpcserver.test_session.test_mount ... CONTEXT >>>> 150714476: GET languages >>>> >>>> CONTEXT[xmlclient] = None >>>> >>>> The connection is in the context, but then something happens and it is >>>> gone. >>>> Then, unit tests try to connect again and NSS fails. >>>> >>>> I would be really glad if somebody with a knowledge of NSS or how >>>> threads in >>>> Python/IPA work could give me some advice... >>> >>> O.K. I'll take a look at it. I seem to recall Rob looked into something >>> similar a couple of days ago. Rob, do you have any additional >>> information to share? >>> >>> >> >> Nothing to add. I looked at this briefly yesterday but nothing jumped out at >> me. I think this may be unrelated to the previous problem I investigated. It >> very well could be we are not closing a connection somewhere. >> >> rob > > Yes, we are not. I fixed it in one place (patch in my original e-mail). With > the patch, one could run at least some parts of the unit test. I assume we are > simply not treating initializing and shutting down of NSS correctly in some > places (also with regards to threads), but I have not found a fix yet. If you modify tests/test_xmlrpc/xmlrpc_test.py and remove request.destroy_context() from tearDown then the tests will pass. But this shouldn't be necessary, we really want to clean up the context between requests. I'm guessing that we're being affected by an external change. It could be in a number of places: httplib, xmlrpclib, NSS, etc. rob From jdennis at redhat.com Mon Oct 15 13:00:15 2012 From: jdennis at redhat.com (John Dennis) Date: Mon, 15 Oct 2012 09:00:15 -0400 Subject: [Freeipa-devel] Unit tests failing on F18 In-Reply-To: <507BACBA.3090902@redhat.com> References: <50783536.8020007@redhat.com> <5078426D.40001@redhat.com> <507BACBA.3090902@redhat.com> Message-ID: <507C08DF.2020405@redhat.com> On 10/15/2012 02:27 AM, Martin Kosek wrote: > On 10/12/2012 06:16 PM, John Dennis wrote: >> O.K. I'll take a look at it. I seem to recall Rob looked into something similar >> a couple of days ago. Rob, do you have any additional information to share? > > Great, with your NSS+Python knowledge this should be walk in the park :-) > Any luck with investigation of this issue? Not yet, it's next on my to-do list. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From pviktori at redhat.com Mon Oct 15 13:05:05 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 15 Oct 2012 15:05:05 +0200 Subject: [Freeipa-devel] Proposal: Use argparse for option parsing In-Reply-To: <50783B21.5010802@redhat.com> References: <50783199.4050803@redhat.com> <50783B21.5010802@redhat.com> Message-ID: <507C0A01.4050303@redhat.com> On 10/12/2012 05:45 PM, Dmitri Pal wrote: > On 10/12/2012 11:04 AM, Petr Viktorin wrote: >> Hello, >> I read through https://fedorahosted.org/freeipa/ticket/3060 and >> noticed that the requirements are similar to what an existing library >> offers. >> >> The optparse module we currently use for CLI option parsing is >> deprecated[1]. The replacement is called argparse, which is part of >> the Python 2.7 standard library. Out of the box, it provides several >> features we either lack or had to handle manually, namely: >> * supporting sub-commands [2] >> * producing more informative usage messages [2] >> * handling both optional and positional arguments [3] >> * as well as including a number of other more minor improvements on >> the optparse API. [3] >> >> The package has also been backported to Python 2.6, the only catch >> there is that it's not in the standard library. >> >> >> Not much of our code calls optparse directly, so switching shouldn't >> be a major effort (within the scope of reorganizing the help system). >> In exchange we get better CLI help messages, forward compatibility, >> and reuse of proven code instead of our own solutions. >> >> >> [1] http://docs.python.org/library/optparse.html >> [2] http://code.google.com/p/argparse/ >> [3] yum info python-argparse (EPEL-6) >> > The ticket is IMO nice to have. Does it provide any value for other main > commands? Yes, it is nice to have. I thought that only affects priority, not what technical solution is correct. I don't think there's value for other commands than help. > If so can you reference other tickets that it would help with. > I am not sure I want the switch for just help. The help improvement ticket describes describes "sane" behavior for a subcommand-based CLI, which is what argparse was written for. We have our own implementation of it, which is subtly wrong, so we can either continue maintaining it or switch to reusing existing, tested code. I think using the library is better in the long run. (And as a nice-to-have ticket, this is for the long run, right?) -- Petr? From pspacek at redhat.com Mon Oct 15 13:09:43 2012 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 15 Oct 2012 15:09:43 +0200 Subject: [Freeipa-devel] [PATCH 0079] Update NEWS file for 2.0 release In-Reply-To: <20121015125746.GA9925@redhat.com> References: <507BCB91.1060702@redhat.com> <20121015125746.GA9925@redhat.com> Message-ID: <507C0B17.9030709@redhat.com> On 10/15/2012 02:57 PM, Adam Tkac wrote: > On Mon, Oct 15, 2012 at 10:38:41AM +0200, Petr Spacek wrote: >> Hello, >> >> Update NEWS file for 2.0 release > > Hi Peter, > > are you OK with this version of NEWS? (patch attached) Sure, pushed to master: b0ceb4aaaba7452f92f91acb46a90eb9509ee72e Petr^2 Spacek From abokovoy at redhat.com Mon Oct 15 13:10:45 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 15 Oct 2012 16:10:45 +0300 Subject: [Freeipa-devel] [PATCH] 0092 Remove bogus check for smbpasswd Message-ID: <20121015131044.GI17454@redhat.com> Hi! We don't use smbpasswd in adtrustinstance anymore so the check is bogus. One-liner. -- / Alexander Bokovoy -------------- next part -------------- >From 687f448a4b7d12ddb356f8e2a35a93fe9611b7cb Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Mon, 15 Oct 2012 16:01:26 +0300 Subject: [PATCH] Remove bogus check for smbpasswd We don't use smbpasswd when configuring IPA for AD trusts anymore because we switched to use Kerberos authentication in IPA passdb backend based on CIFS service keytab. --- ipaserver/install/adtrustinstance.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py index b74f4b685b1cb56bdcdbae15ab6a8f38960bfc66..fcf2a73920567bde26c0df3b4797d727d241b36c 100644 --- a/ipaserver/install/adtrustinstance.py +++ b/ipaserver/install/adtrustinstance.py @@ -60,7 +60,7 @@ and re-run ipa-adtrust-instal again afterwards. """ def check_inst(): - for smbfile in ['/usr/sbin/smbd', '/usr/bin/net', '/usr/bin/smbpasswd']: + for smbfile in ['/usr/sbin/smbd', '/usr/bin/net']: if not os.path.exists(smbfile): print "%s was not found on this system" % file print "Please install the 'samba' packages and " \ -- 1.7.12 From dpal at redhat.com Mon Oct 15 14:05:42 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 15 Oct 2012 10:05:42 -0400 Subject: [Freeipa-devel] Proposal: Use argparse for option parsing In-Reply-To: <507C0A01.4050303@redhat.com> References: <50783199.4050803@redhat.com> <50783B21.5010802@redhat.com> <507C0A01.4050303@redhat.com> Message-ID: <507C1836.5060701@redhat.com> On 10/15/2012 09:05 AM, Petr Viktorin wrote: > On 10/12/2012 05:45 PM, Dmitri Pal wrote: >> On 10/12/2012 11:04 AM, Petr Viktorin wrote: >>> Hello, >>> I read through https://fedorahosted.org/freeipa/ticket/3060 and >>> noticed that the requirements are similar to what an existing library >>> offers. >>> >>> The optparse module we currently use for CLI option parsing is >>> deprecated[1]. The replacement is called argparse, which is part of >>> the Python 2.7 standard library. Out of the box, it provides several >>> features we either lack or had to handle manually, namely: >>> * supporting sub-commands [2] >>> * producing more informative usage messages [2] >>> * handling both optional and positional arguments [3] >>> * as well as including a number of other more minor improvements on >>> the optparse API. [3] >>> >>> The package has also been backported to Python 2.6, the only catch >>> there is that it's not in the standard library. >>> >>> >>> Not much of our code calls optparse directly, so switching shouldn't >>> be a major effort (within the scope of reorganizing the help system). >>> In exchange we get better CLI help messages, forward compatibility, >>> and reuse of proven code instead of our own solutions. >>> >>> >>> [1] http://docs.python.org/library/optparse.html >>> [2] http://code.google.com/p/argparse/ >>> [3] yum info python-argparse (EPEL-6) >>> >> The ticket is IMO nice to have. Does it provide any value for other main >> commands? > > Yes, it is nice to have. I thought that only affects priority, not > what technical solution is correct. > I don't think there's value for other commands than help. > >> If so can you reference other tickets that it would help with. >> I am not sure I want the switch for just help. > > The help improvement ticket describes describes "sane" behavior for a > subcommand-based CLI, which is what argparse was written for. We have > our own implementation of it, which is subtly wrong, so we can either > continue maintaining it or switch to reusing existing, tested code. > I think using the library is better in the long run. (And as a > nice-to-have ticket, this is for the long run, right?) > Since there is not value for other commands I do not see an urgency to switch now. The homegrown solution might be ugly but it works so replacing it would not be a high priority. 3.2 is already pretty full and I do not see this work getting in. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Mon Oct 15 14:21:08 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 15 Oct 2012 10:21:08 -0400 Subject: [Freeipa-devel] Test Day today Message-ID: <507C1BD4.1080604@redhat.com> We're participating in the Fedora Test Days, and today is our day! The list of tests can be found at: https://fedoraproject.org/wiki/Test_Day:2012-10-15_FreeIPA The latest Fedora 18 beta test compose is available via https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Please test with the current freeipa, pki-ca and 389-ds-base packages in Fedora 18. The versions are freeipa-server-3.0.0-2, pki-ca-10.0.0-0.44.b1 and 389-ds-base-1.3.0-0.1.a1. thanks rob From sbose at redhat.com Mon Oct 15 15:19:49 2012 From: sbose at redhat.com (Sumit Bose) Date: Mon, 15 Oct 2012 17:19:49 +0200 Subject: [Freeipa-devel] [PATCH] 0092 Remove bogus check for smbpasswd In-Reply-To: <20121015131044.GI17454@redhat.com> References: <20121015131044.GI17454@redhat.com> Message-ID: <20121015151949.GL23959@localhost.localdomain> On Mon, Oct 15, 2012 at 04:10:45PM +0300, Alexander Bokovoy wrote: > Hi! > > We don't use smbpasswd in adtrustinstance anymore so the check is > bogus. > > One-liner. > > -- > / Alexander Bokovoy ACK bye, Sumit > >From 687f448a4b7d12ddb356f8e2a35a93fe9611b7cb Mon Sep 17 00:00:00 2001 > From: Alexander Bokovoy > Date: Mon, 15 Oct 2012 16:01:26 +0300 > Subject: [PATCH] Remove bogus check for smbpasswd > > We don't use smbpasswd when configuring IPA for AD trusts anymore > because we switched to use Kerberos authentication in IPA passdb > backend based on CIFS service keytab. > --- > ipaserver/install/adtrustinstance.py | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py > index b74f4b685b1cb56bdcdbae15ab6a8f38960bfc66..fcf2a73920567bde26c0df3b4797d727d241b36c 100644 > --- a/ipaserver/install/adtrustinstance.py > +++ b/ipaserver/install/adtrustinstance.py > @@ -60,7 +60,7 @@ and re-run ipa-adtrust-instal again afterwards. > """ > > def check_inst(): > - for smbfile in ['/usr/sbin/smbd', '/usr/bin/net', '/usr/bin/smbpasswd']: > + for smbfile in ['/usr/sbin/smbd', '/usr/bin/net']: > if not os.path.exists(smbfile): > print "%s was not found on this system" % file > print "Please install the 'samba' packages and " \ > -- > 1.7.12 > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From rcritten at redhat.com Mon Oct 15 15:39:44 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 15 Oct 2012 11:39:44 -0400 Subject: [Freeipa-devel] [PATCH] 0092 Remove bogus check for smbpasswd In-Reply-To: <20121015151949.GL23959@localhost.localdomain> References: <20121015131044.GI17454@redhat.com> <20121015151949.GL23959@localhost.localdomain> Message-ID: <507C2E40.6030808@redhat.com> Sumit Bose wrote: > On Mon, Oct 15, 2012 at 04:10:45PM +0300, Alexander Bokovoy wrote: >> Hi! >> >> We don't use smbpasswd in adtrustinstance anymore so the check is >> bogus. >> >> One-liner. >> >> -- >> / Alexander Bokovoy > > ACK NACK. Please fix the error message too. It should be using the variable smbfile and not file. rob > > bye, > Sumit > >> >From 687f448a4b7d12ddb356f8e2a35a93fe9611b7cb Mon Sep 17 00:00:00 2001 >> From: Alexander Bokovoy >> Date: Mon, 15 Oct 2012 16:01:26 +0300 >> Subject: [PATCH] Remove bogus check for smbpasswd >> >> We don't use smbpasswd when configuring IPA for AD trusts anymore >> because we switched to use Kerberos authentication in IPA passdb >> backend based on CIFS service keytab. >> --- >> ipaserver/install/adtrustinstance.py | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py >> index b74f4b685b1cb56bdcdbae15ab6a8f38960bfc66..fcf2a73920567bde26c0df3b4797d727d241b36c 100644 >> --- a/ipaserver/install/adtrustinstance.py >> +++ b/ipaserver/install/adtrustinstance.py >> @@ -60,7 +60,7 @@ and re-run ipa-adtrust-instal again afterwards. >> """ >> >> def check_inst(): >> - for smbfile in ['/usr/sbin/smbd', '/usr/bin/net', '/usr/bin/smbpasswd']: >> + for smbfile in ['/usr/sbin/smbd', '/usr/bin/net']: >> if not os.path.exists(smbfile): >> print "%s was not found on this system" % file >> print "Please install the 'samba' packages and " \ >> -- >> 1.7.12 >> > >> _______________________________________________ >> 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 abokovoy at redhat.com Mon Oct 15 16:52:22 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 15 Oct 2012 19:52:22 +0300 Subject: [Freeipa-devel] [PATCH] 0092 Remove bogus check for smbpasswd In-Reply-To: <507C2E40.6030808@redhat.com> References: <20121015131044.GI17454@redhat.com> <20121015151949.GL23959@localhost.localdomain> <507C2E40.6030808@redhat.com> Message-ID: <20121015165222.GJ17454@redhat.com> On Mon, 15 Oct 2012, Rob Crittenden wrote: >Sumit Bose wrote: >>On Mon, Oct 15, 2012 at 04:10:45PM +0300, Alexander Bokovoy wrote: >>>Hi! >>> >>>We don't use smbpasswd in adtrustinstance anymore so the check is >>>bogus. >>> >>>One-liner. >>> >>>-- >>>/ Alexander Bokovoy >> >>ACK > >NACK. Please fix the error message too. It should be using the >variable smbfile and not file. Good catch, thanks! Attached. -- / Alexander Bokovoy -------------- next part -------------- >From 00dec00b414cd7d2f5e6d29a3aa59ce795b1c6ac Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Mon, 15 Oct 2012 16:01:26 +0300 Subject: [PATCH] Remove bogus check for smbpasswd We don't use smbpasswd when configuring IPA for AD trusts anymore because we switched to use Kerberos authentication in IPA passdb backend based on CIFS service keytab. --- ipaserver/install/adtrustinstance.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py index b74f4b685b1cb56bdcdbae15ab6a8f38960bfc66..b3602ddce7fa1c184bdf1283e67b50463e49c5fd 100644 --- a/ipaserver/install/adtrustinstance.py +++ b/ipaserver/install/adtrustinstance.py @@ -60,9 +60,9 @@ and re-run ipa-adtrust-instal again afterwards. """ def check_inst(): - for smbfile in ['/usr/sbin/smbd', '/usr/bin/net', '/usr/bin/smbpasswd']: + for smbfile in ['/usr/sbin/smbd', '/usr/bin/net']: if not os.path.exists(smbfile): - print "%s was not found on this system" % file + print "%s was not found on this system" % smbfile print "Please install the 'samba' packages and " \ "start the installation again" return False -- 1.7.12 From mkosek at redhat.com Tue Oct 16 07:08:53 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 16 Oct 2012 09:08:53 +0200 Subject: [Freeipa-devel] [PATCH] 0092 Remove bogus check for smbpasswd In-Reply-To: <20121015165222.GJ17454@redhat.com> References: <20121015131044.GI17454@redhat.com> <20121015151949.GL23959@localhost.localdomain> <507C2E40.6030808@redhat.com> <20121015165222.GJ17454@redhat.com> Message-ID: <507D0805.5090502@redhat.com> On 10/15/2012 06:52 PM, Alexander Bokovoy wrote: > On Mon, 15 Oct 2012, Rob Crittenden wrote: >> Sumit Bose wrote: >>> On Mon, Oct 15, 2012 at 04:10:45PM +0300, Alexander Bokovoy wrote: >>>> Hi! >>>> >>>> We don't use smbpasswd in adtrustinstance anymore so the check is >>>> bogus. >>>> >>>> One-liner. >>>> >>>> -- >>>> / Alexander Bokovoy >>> >>> ACK >> >> NACK. Please fix the error message too. It should be using the variable >> smbfile and not file. > Good catch, thanks! > > Attached. ACK. I just linked it to ticket 3181 (and related Bugzilla). Pushed to master, ipa-3-0. Martin From mkosek at redhat.com Tue Oct 16 07:13:15 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 16 Oct 2012 09:13:15 +0200 Subject: [Freeipa-devel] [PATCH by nkondras] Add uninstall command hints to ipa-*-install In-Reply-To: <5076DB4B.8000904@redhat.com> References: <5076DB4B.8000904@redhat.com> Message-ID: <507D090B.3040301@redhat.com> On 10/11/2012 04:44 PM, Petr Viktorin wrote: > The patch was submitted via Trac at > https://fedorahosted.org/freeipa/ticket/3065. Thanks, Nikolai! Please use this > list next time to speed things up. > > I took the liberty of adding one more message, re-formatting the code a bit, > and mentioning the ticket in the commit message. > ACK. Thanks both Petr and Nikolai! Pushed to master, ipa-3-0. Martin From abokovoy at redhat.com Tue Oct 16 08:46:17 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 16 Oct 2012 11:46:17 +0300 Subject: [Freeipa-devel] broken bind-dyndb-ldap in ipa-devel repo Message-ID: <20121016084617.GL17454@redhat.com> Hi, It looks like bind has moved its ABI in F17 updates-testing: $ rpm -ql bind-libs /usr/lib64/libbind9.so.90 /usr/lib64/libbind9.so.90.0.5 /usr/lib64/libdns.so.95 /usr/lib64/libdns.so.95.1.1 /usr/lib64/libisc.so.92 /usr/lib64/libisc.so.92.1.0 /usr/lib64/libisccc.so.90 /usr/lib64/libisccc.so.90.0.2 /usr/lib64/libisccfg.so.90 /usr/lib64/libisccfg.so.90.0.2 /usr/lib64/liblwres.so.90 /usr/lib64/liblwres.so.90.0.1 Note libdns.so.95 -- this does not play well with bind-dyndb-ldap in ipa-devel repository as that one is built against libdns.so.93. Yum then is unable to install the packages as the only repo where bind 9.9.2 is available is updates-testing. Petr, Adam, could any of you rebuild bind-dyndb-ldap in ipa-devel repo against bind in updates-testing for F17? Without this rebuild managed DNS is not possible to use in F17+ipa-devel. -- / Alexander Bokovoy From atkac at redhat.com Tue Oct 16 09:16:24 2012 From: atkac at redhat.com (Adam Tkac) Date: Tue, 16 Oct 2012 11:16:24 +0200 Subject: [Freeipa-devel] broken bind-dyndb-ldap in ipa-devel repo In-Reply-To: <20121016084617.GL17454@redhat.com> References: <20121016084617.GL17454@redhat.com> Message-ID: <20121016091622.GA1420@redhat.com> On Tue, Oct 16, 2012 at 11:46:17AM +0300, Alexander Bokovoy wrote: > Hi, > > It looks like bind has moved its ABI in F17 updates-testing: > $ rpm -ql bind-libs > /usr/lib64/libbind9.so.90 > /usr/lib64/libbind9.so.90.0.5 > /usr/lib64/libdns.so.95 > /usr/lib64/libdns.so.95.1.1 > /usr/lib64/libisc.so.92 > /usr/lib64/libisc.so.92.1.0 > /usr/lib64/libisccc.so.90 > /usr/lib64/libisccc.so.90.0.2 > /usr/lib64/libisccfg.so.90 > /usr/lib64/libisccfg.so.90.0.2 > /usr/lib64/liblwres.so.90 > /usr/lib64/liblwres.so.90.0.1 > > Note libdns.so.95 -- this does not play well with bind-dyndb-ldap in > ipa-devel repository as that one is built against libdns.so.93. Yum then > is unable to install the packages as the only repo where bind 9.9.2 is > available is updates-testing. > > Petr, Adam, could any of you rebuild bind-dyndb-ldap in ipa-devel repo > against bind in updates-testing for F17? > > Without this rebuild managed DNS is not possible to use in > F17+ipa-devel. Hi Alexander, I'm not sure if I have permissions to rebuild pkgs in ipa-devel repo, I've neved did it before. Is there some manual how to do it? Thanks in advance. Regards, Adam -- Adam Tkac, Red Hat, Inc. From abokovoy at redhat.com Tue Oct 16 09:40:07 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 16 Oct 2012 12:40:07 +0300 Subject: [Freeipa-devel] broken bind-dyndb-ldap in ipa-devel repo In-Reply-To: <20121016091622.GA1420@redhat.com> References: <20121016084617.GL17454@redhat.com> <20121016091622.GA1420@redhat.com> Message-ID: <20121016094007.GM17454@redhat.com> On Tue, 16 Oct 2012, Adam Tkac wrote: >I'm not sure if I have permissions to rebuild pkgs in ipa-devel repo, I've neved >did it before. Is there some manual how to do it? Thanks in advance. I believe Martin or Jakub could provide all needed info (off-list) for manual rebuilds, please contact them directly. At least for FreeIPA and SSSD there are builds triggered from commits to the git repo. -- / Alexander Bokovoy From pviktori at redhat.com Tue Oct 16 11:55:54 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 16 Oct 2012 13:55:54 +0200 Subject: [Freeipa-devel] [PATCH] 0092 Make sure the CA is running when starting services Message-ID: <507D4B4A.5090907@redhat.com> https://fedorahosted.org/freeipa/ticket/3084 See ticket & commit message. Please tell me of a better way to extend the Services. What's interesting is that usually the CA is "running" right after the ports are opened, but if not, it takes *exactly* one minute between the ports being open and the time I stop getting 503 "Service Temporarily Unavailable" from ca/admin/ca/getStatus. Is there a sleep somewhere in pki? or httpd? or IP?? -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0092-Make-sure-the-CA-is-running-when-starting-services.patch Type: text/x-patch Size: 13974 bytes Desc: not available URL: From simo at redhat.com Tue Oct 16 12:03:51 2012 From: simo at redhat.com (Simo Sorce) Date: Tue, 16 Oct 2012 08:03:51 -0400 Subject: [Freeipa-devel] [PATCH] 500 Fix shutdown issues with systemd Message-ID: <1350389031.10587.192.camel@willson.li.ssimo.org> Also improve shutdown reliability and restart behavior so we always kill all the processes we started even if the list of processes to handle changed in LDAP. Fixes: https://fedorahosted.org/freeipa/ticket/2302 -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-500-1-Get-list-of-service-from-LDAP-only-at-startup.patch Type: text/x-patch Size: 11147 bytes Desc: not available URL: From abokovoy at redhat.com Tue Oct 16 12:25:12 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 16 Oct 2012 15:25:12 +0300 Subject: [Freeipa-devel] [PATCH] 500 Fix shutdown issues with systemd In-Reply-To: <1350389031.10587.192.camel@willson.li.ssimo.org> References: <1350389031.10587.192.camel@willson.li.ssimo.org> Message-ID: <20121016122512.GN17454@redhat.com> On Tue, 16 Oct 2012, Simo Sorce wrote: >Also improve shutdown reliability and restart behavior so we always kill >all the processes we started even if the list of processes to handle >changed in LDAP. > >Fixes: https://fedorahosted.org/freeipa/ticket/2302 Works for me on freshly installed F18. Since I've got no signs of solution coming out of systemd maintainer, I'm inclined to ACK this patch. For uninitiated, the problem with systemd is that we attempt to start dirsrv services at the time when everything is going for shutdown. systemctl uses D-Bus for communication with systemd and at the time when we send start command for dirsrv services, there is no D-Bus daemon already so systemctl sits forever, waiting for any message on the bus. Avoiding restarting dirsrv services avoids coming into infinite loop territory, thus ACK. Security-wise, the dumped list of services is in the directory (0700, root, root) permissions so nobody can modify it but root. Root already has possibility to shutdown whatever services are there. I think we are OK here -- but whoever packages the change, would need to be careful and copy accompanying spec-file changes. -- / Alexander Bokovoy From tbabej at redhat.com Tue Oct 16 12:26:24 2012 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 16 Oct 2012 14:26:24 +0200 Subject: [Freeipa-devel] [PATCH 0019] Forbid overlapping primary and secondary rid ranges Message-ID: <507D5270.20904@redhat.com> Hi, commands ipa idrange-add / idrange-mod no longer allows the user to enter primary or secondary rid range such that has non-zero intersection with primary or secondary rid range of another existing id range, as this could cause collision. Unit tests added to test_range_plugin.py https://fedorahosted.org/freeipa/ticket/3086 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0019-Forbid-overlapping-primary-and-secondary-rid-ranges.patch Type: text/x-patch Size: 13603 bytes Desc: not available URL: From jcholast at redhat.com Tue Oct 16 14:02:25 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 16 Oct 2012 16:02:25 +0200 Subject: [Freeipa-devel] [PATCH] 0091 ipautil.run: Log the command line before running the command In-Reply-To: <507C0559.9010605@redhat.com> References: <507C0559.9010605@redhat.com> Message-ID: <507D68F1.80004@redhat.com> Hi, On 15.10.2012 14:45, Petr Viktorin wrote: > As I was debugging code that calls long-running or failing commands, I > got tired of the invocation being logged after the command is done. > This patch should improve the logging. > > https://fedorahosted.org/freeipa/ticket/3174 > --- > Petr? > + except: + root_logger.debug('Process failed') + raise Why do you use blank except here? Can you print the reason why the process has failed or the exit code here? Honza -- Jan Cholasta From pviktori at redhat.com Tue Oct 16 14:27:51 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 16 Oct 2012 16:27:51 +0200 Subject: [Freeipa-devel] [PATCH] 0091 ipautil.run: Log the command line before running the command In-Reply-To: <507D68F1.80004@redhat.com> References: <507C0559.9010605@redhat.com> <507D68F1.80004@redhat.com> Message-ID: <507D6EE7.8050702@redhat.com> On 10/16/2012 04:02 PM, Jan Cholasta wrote: > Hi, > > On 15.10.2012 14:45, Petr Viktorin wrote: >> As I was debugging code that calls long-running or failing commands, I >> got tired of the invocation being logged after the command is done. >> This patch should improve the logging. >> >> https://fedorahosted.org/freeipa/ticket/3174 >> --- >> Petr? >> > > + except: > + root_logger.debug('Process failed') > + raise > > Why do you use blank except here? Can you print the reason why the > process has failed or the exit code here? > > Honza > I re-raise command afterwards, so the error is not really handled or ignored. It's one of the few situations where a bare except is justified :) Since the error is re-raised, it should be handled by the caller. Printing additional info here should be redundant. The exception can happen before the Popen object is created, so the return code might not be available. Anyway bad return code is handled later, here we'd get errors like command not found, fork() failure etc. I see that the wording could be better, attaching new patch: s/Process failed/Process execution failed/ s/Process successful/Process finished/ -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0091-02-ipautil.run-Log-the-command-line-before-running-the-.patch Type: text/x-patch Size: 2231 bytes Desc: not available URL: From jcholast at redhat.com Tue Oct 16 14:53:31 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 16 Oct 2012 16:53:31 +0200 Subject: [Freeipa-devel] [PATCH] 0091 ipautil.run: Log the command line before running the command In-Reply-To: <507D6EE7.8050702@redhat.com> References: <507C0559.9010605@redhat.com> <507D68F1.80004@redhat.com> <507D6EE7.8050702@redhat.com> Message-ID: <507D74EB.4030602@redhat.com> On 16.10.2012 16:27, Petr Viktorin wrote: > On 10/16/2012 04:02 PM, Jan Cholasta wrote: >> Hi, >> >> On 15.10.2012 14:45, Petr Viktorin wrote: >>> As I was debugging code that calls long-running or failing commands, I >>> got tired of the invocation being logged after the command is done. >>> This patch should improve the logging. >>> >>> https://fedorahosted.org/freeipa/ticket/3174 >>> --- >>> Petr? >>> >> >> + except: >> + root_logger.debug('Process failed') >> + raise >> >> Why do you use blank except here? Can you print the reason why the >> process has failed or the exit code here? >> >> Honza >> > > I re-raise command afterwards, so the error is not really handled or > ignored. It's one of the few situations where a bare except is justified :) OK, makes sense. > Since the error is re-raised, it should be handled by the caller. > Printing additional info here should be redundant. > The exception can happen before the Popen object is created, so the > return code might not be available. Anyway bad return code is handled > later, here we'd get errors like command not found, fork() failure etc. Right. Anyway, I think logging the return code might come handy in some situations. Can you please add it? > > I see that the wording could be better, attaching new patch: > s/Process failed/Process execution failed/ > s/Process successful/Process finished/ > Honza -- Jan Cholasta From rcritten at redhat.com Tue Oct 16 15:21:14 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 16 Oct 2012 11:21:14 -0400 Subject: [Freeipa-devel] [PATCH] 1063 Allow no reverse domain Message-ID: <507D7B6A.20304@redhat.com> A reverse zone is always created unless --no-reverse is passed. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1063-reverse.patch Type: text/x-diff Size: 2110 bytes Desc: not available URL: From pviktori at redhat.com Tue Oct 16 15:26:39 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 16 Oct 2012 17:26:39 +0200 Subject: [Freeipa-devel] [PATCH] 0091 ipautil.run: Log the command line before running the command In-Reply-To: <507D74EB.4030602@redhat.com> References: <507C0559.9010605@redhat.com> <507D68F1.80004@redhat.com> <507D6EE7.8050702@redhat.com> <507D74EB.4030602@redhat.com> Message-ID: <507D7CAF.20605@redhat.com> On 10/16/2012 04:53 PM, Jan Cholasta wrote: > On 16.10.2012 16:27, Petr Viktorin wrote: >> On 10/16/2012 04:02 PM, Jan Cholasta wrote: >>> Hi, >>> >>> On 15.10.2012 14:45, Petr Viktorin wrote: >>>> As I was debugging code that calls long-running or failing commands, I >>>> got tired of the invocation being logged after the command is done. >>>> This patch should improve the logging. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3174 >>>> --- >>>> Petr? >>>> >>> >>> + except: >>> + root_logger.debug('Process failed') >>> + raise >>> >>> Why do you use blank except here? Can you print the reason why the >>> process has failed or the exit code here? >>> >>> Honza >>> >> >> I re-raise command afterwards, so the error is not really handled or >> ignored. It's one of the few situations where a bare except is >> justified :) > > OK, makes sense. > >> Since the error is re-raised, it should be handled by the caller. >> Printing additional info here should be redundant. >> The exception can happen before the Popen object is created, so the >> return code might not be available. Anyway bad return code is handled >> later, here we'd get errors like command not found, fork() failure etc. > > Right. Anyway, I think logging the return code might come handy in some > situations. Can you please add it? > You're right. Added. >> >> I see that the wording could be better, attaching new patch: >> s/Process failed/Process execution failed/ >> s/Process successful/Process finished/ >> > > Honza > -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0091-03-ipautil.run-Log-the-command-line-before-running-the-.patch Type: text/x-patch Size: 2261 bytes Desc: not available URL: From jcholast at redhat.com Tue Oct 16 15:29:57 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 16 Oct 2012 17:29:57 +0200 Subject: [Freeipa-devel] [PATCH] 0091 ipautil.run: Log the command line before running the command In-Reply-To: <507D7CAF.20605@redhat.com> References: <507C0559.9010605@redhat.com> <507D68F1.80004@redhat.com> <507D6EE7.8050702@redhat.com> <507D74EB.4030602@redhat.com> <507D7CAF.20605@redhat.com> Message-ID: <507D7D75.60904@redhat.com> On 16.10.2012 17:26, Petr Viktorin wrote: > On 10/16/2012 04:53 PM, Jan Cholasta wrote: >> On 16.10.2012 16:27, Petr Viktorin wrote: >>> On 10/16/2012 04:02 PM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 15.10.2012 14:45, Petr Viktorin wrote: >>>>> As I was debugging code that calls long-running or failing commands, I >>>>> got tired of the invocation being logged after the command is done. >>>>> This patch should improve the logging. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3174 >>>>> --- >>>>> Petr? >>>>> >>>> >>>> + except: >>>> + root_logger.debug('Process failed') >>>> + raise >>>> >>>> Why do you use blank except here? Can you print the reason why the >>>> process has failed or the exit code here? >>>> >>>> Honza >>>> >>> >>> I re-raise command afterwards, so the error is not really handled or >>> ignored. It's one of the few situations where a bare except is >>> justified :) >> >> OK, makes sense. >> >>> Since the error is re-raised, it should be handled by the caller. >>> Printing additional info here should be redundant. >>> The exception can happen before the Popen object is created, so the >>> return code might not be available. Anyway bad return code is handled >>> later, here we'd get errors like command not found, fork() failure etc. >> >> Right. Anyway, I think logging the return code might come handy in some >> situations. Can you please add it? >> > > You're right. Added. > >>> >>> I see that the wording could be better, attaching new patch: >>> s/Process failed/Process execution failed/ >>> s/Process successful/Process finished/ >>> >> >> Honza >> > > Thanks. ACK. Honza -- Jan Cholasta From mkosek at redhat.com Tue Oct 16 16:03:43 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 16 Oct 2012 18:03:43 +0200 Subject: [Freeipa-devel] [PATCH] 1063 Allow no reverse domain In-Reply-To: <507D7B6A.20304@redhat.com> References: <507D7B6A.20304@redhat.com> Message-ID: <507D855F.7080102@redhat.com> On 10/16/2012 05:21 PM, Rob Crittenden wrote: > A reverse zone is always created unless --no-reverse is passed. > > rob > Yeah, this is much better. I would just unify our summary printed before installation. Now when running ipa-server-install with --no-reverse: ... BIND DNS server will be configured to serve IPA domain with: Forwarders: IP_ADDRESS Reverse zone: No reverse zone <<<<< Continue to configure the system with these values? [no]: ... But if you answer "no" for THE question, then we have a bit different wording: BIND DNS server will be configured to serve IPA domain with: Forwarders: 10.16.255.2 Reverse zone: None <<<<<< Continue to configure the system with these values? [no]: y ... If you fix this (it is a one-liner), then ACK. Martin From edewata at redhat.com Tue Oct 16 16:10:32 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 16 Oct 2012 11:10:32 -0500 Subject: [Freeipa-devel] [PATCHES] backport of Firefox extension to FreeIPA 2.2 In-Reply-To: <5077F721.5060003@redhat.com> References: <5076C1D5.20403@redhat.com> <5077F721.5060003@redhat.com> Message-ID: <507D86F8.60706@redhat.com> On 10/12/2012 5:55 AM, Petr Viktorin wrote: > On 10/11/2012 02:55 PM, Petr Vobornik wrote: >> This bunch of patches is a backport of Firefox extension to FreeIPA 2.2. >> >> First apply pvoborni's patches then pviktori's. > > I tested several replication/upgrade scenarios. Upgrading from 2.2.0 and > to master works fine. ACK for the Python part. ACK for the JavaScript part. Just a minor issue, there's a typo in ipa_init.json and internal.py, I think it's supposed to use a curly bracket: http://${host]/ipa/config/unauthorized.html This problem exists on both pvoborni-219-1 and pvoborni-219-2-2 patches. -- Endi S. Dewata From rcritten at redhat.com Tue Oct 16 17:27:38 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 16 Oct 2012 13:27:38 -0400 Subject: [Freeipa-devel] [PATCH] 1063 Allow no reverse domain In-Reply-To: <507D855F.7080102@redhat.com> References: <507D7B6A.20304@redhat.com> <507D855F.7080102@redhat.com> Message-ID: <507D990A.9010002@redhat.com> Martin Kosek wrote: > On 10/16/2012 05:21 PM, Rob Crittenden wrote: >> A reverse zone is always created unless --no-reverse is passed. >> >> rob >> > > Yeah, this is much better. I would just unify our summary printed before > installation. Now when running ipa-server-install with --no-reverse: > > ... > BIND DNS server will be configured to serve IPA domain with: > Forwarders: IP_ADDRESS > Reverse zone: No reverse zone <<<<< > > Continue to configure the system with these values? [no]: > ... > > > But if you answer "no" for THE question, then we have a bit different wording: > > BIND DNS server will be configured to serve IPA domain with: > Forwarders: 10.16.255.2 > Reverse zone: None <<<<<< > > Continue to configure the system with these values? [no]: y > ... > > If you fix this (it is a one-liner), then ACK. > > Martin > Updated patch. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1063-2-reverse.patch Type: text/x-diff Size: 2597 bytes Desc: not available URL: From mkosek at redhat.com Wed Oct 17 07:04:45 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 17 Oct 2012 09:04:45 +0200 Subject: [Freeipa-devel] [PATCH] 1063 Allow no reverse domain In-Reply-To: <507D990A.9010002@redhat.com> References: <507D7B6A.20304@redhat.com> <507D855F.7080102@redhat.com> <507D990A.9010002@redhat.com> Message-ID: <507E588D.3060503@redhat.com> On 10/16/2012 07:27 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> On 10/16/2012 05:21 PM, Rob Crittenden wrote: >>> A reverse zone is always created unless --no-reverse is passed. >>> >>> rob >>> >> >> Yeah, this is much better. I would just unify our summary printed before >> installation. Now when running ipa-server-install with --no-reverse: >> >> ... >> BIND DNS server will be configured to serve IPA domain with: >> Forwarders: IP_ADDRESS >> Reverse zone: No reverse zone <<<<< >> >> Continue to configure the system with these values? [no]: >> ... >> >> >> But if you answer "no" for THE question, then we have a bit different wording: >> >> BIND DNS server will be configured to serve IPA domain with: >> Forwarders: 10.16.255.2 >> Reverse zone: None <<<<<< >> >> Continue to configure the system with these values? [no]: y >> ... >> >> If you fix this (it is a one-liner), then ACK. >> >> Martin >> > > Updated patch. > > rob ACK. Pushed to master, ipa-3-0. Martin From sbose at redhat.com Wed Oct 17 09:14:51 2012 From: sbose at redhat.com (Sumit Bose) Date: Wed, 17 Oct 2012 11:14:51 +0200 Subject: [Freeipa-devel] [PATCH 0019] Forbid overlapping primary and secondary rid ranges In-Reply-To: <507D5270.20904@redhat.com> References: <507D5270.20904@redhat.com> Message-ID: <20121017091451.GR23959@localhost.localdomain> On Tue, Oct 16, 2012 at 02:26:24PM +0200, Tomas Babej wrote: > Hi, > > commands ipa idrange-add / idrange-mod no longer allows the user > to enter primary or secondary rid range such that has non-zero > intersection with primary or secondary rid range of another > existing id range, as this could cause collision. > > Unit tests added to test_range_plugin.py > > https://fedorahosted.org/freeipa/ticket/3086 > > Tomas Thank you for the patch, comments are in-line. bye, Sumit > >From a46a8d0aa4e64e105a53a177b6a12cf28e56620e Mon Sep 17 00:00:00 2001 > From: Tomas Babej > Date: Mon, 15 Oct 2012 06:28:16 -0400 > Subject: [PATCH] Forbid overlapping primary and secondary rid ranges > > Commands ipa idrange-add / idrange-mod no longer allows the user > to enter primary or secondary rid range such that has non-zero > intersection with primary or secondary rid range of another > existing id range, as this could cause collision. > > Unit tests added to test_range_plugin.py > > https://fedorahosted.org/freeipa/ticket/3086 > --- > .../ipa-range-check/ipa_range_check.c | 93 +++++++++++++--- > tests/test_xmlrpc/test_range_plugin.py | 120 +++++++++++++++++++-- > 2 files changed, 191 insertions(+), 22 deletions(-) > > diff --git a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c > index 499e54a9c4a4c9134a231c0cd09e700390565a14..4f9f7437d11d2bc33238b14f5099a42b4c5463d2 100644 > --- a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c > +++ b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c > @@ -132,24 +132,67 @@ done: > return ret; > } > > -#define IN_RANGE(x,base,size) ( (x) >= (base) && ((x) - (base)) < (size) ) > -static bool ranges_overlap(struct range_info *r1, struct range_info *r2) > +#define IN_RANGE(x,base,size) ( (x) >= (base) && (x) < (size+base) ) Would you mind to use the original definition of IN_RANGE? x-base looks a bit odd, but I made it on purpose to avoid overruns. Since we already know that x>=base we can be sure that there will be no underrun. > +static bool intervals_overlap(uint32_t x, uint32_t base, uint32_t x_size, uint32_t base_size) > { > - if (r1->name != NULL && r2->name != NULL && > - strcasecmp(r1->name, r2->name) == 0) { > - return false; > - } > - > - if (IN_RANGE(r1->base_id, r2->base_id, r2->id_range_size) || > - IN_RANGE((r1->base_id + r1->id_range_size - 1), r2->base_id, r2->id_range_size) || > - IN_RANGE(r2->base_id, r1->base_id, r1->id_range_size) || > - IN_RANGE((r2->base_id + r2->id_range_size - 1), r1->base_id, r1->id_range_size)) { > + if (IN_RANGE(x, base, base_size) || > + IN_RANGE((x + x_size - 1), base, base_size) || > + IN_RANGE(base, x, x_size) || > + IN_RANGE((base + base_size - 1), x, x_size)) { > return true; > } > > return false; > } > > +//returns 0 if there is no overlap > +//connected ranges must not overlap: > +// existing range: base rid sec_rid > +// | | \ / | > +// | | \/ | > +// | | /\ | > +// | | / \ | > +// new range: base rid sec_rid I think we currently do not use C++ style comments in freeipa C code. Can you switch to /* */ comments? > +static int ranges_overlap(struct range_info *r1, struct range_info *r2) > +{ > + if (r1->name != NULL && r2->name != NULL && > + strcasecmp(r1->name, r2->name) == 0) { > + return 0; > + } > + > + //check if base range overlaps with existing base range > + if (intervals_overlap(r1->base_id, r2->base_id, > + r1->id_range_size, r2->id_range_size)){ > + return 1; > + } > + > + //if both base_rid and secondary_base_rid are 0, the rid range is not set > + //in that case we skip the primary/secondary rid range overlap test > + if((r1->base_rid!=0 || r1->secondary_base_rid!=0) && > + (r2->base_rid!=0 || r2->secondary_base_rid!=0)){ can you add spaces around '!=' ? > + > + //check if rid range overlaps with existing rid range > + if (intervals_overlap(r1->base_rid, r2->base_rid, > + r1->id_range_size, r2->id_range_size)) > + return 2; > + > + //check if secondary rid range overlaps with existing secondary rid range > + if (intervals_overlap(r1->secondary_base_rid, r2->secondary_base_rid, > + r1->id_range_size, r2->id_range_size)) > + return 3; > + > + //check if rid range overlaps with existing secondary rid range > + if (intervals_overlap(r1->base_rid, r2->secondary_base_rid, > + r1->id_range_size, r2->id_range_size)) > + return 4; > + > + //check if secondary rid range overlaps with existing rid range > + if (intervals_overlap(r1->secondary_base_rid, r2->base_rid, > + r1->id_range_size, r2->id_range_size)) > + return 5; > + } Return code is missing if one of the ranges does not have the rid ranges set. Can you add a test case for this condition as well? > +} > + > static int ipa_range_check_start(Slapi_PBlock *pb) > { > return 0; > @@ -176,7 +219,7 @@ static int ipa_range_check_pre_op(Slapi_PBlock *pb, int modtype) > int search_result; > Slapi_Entry **search_entries = NULL; > size_t c; > - bool overlap = true; > + int no_overlap = 0; > const char *check_attr; > char *errmsg = NULL; > > @@ -315,13 +358,31 @@ static int ipa_range_check_pre_op(Slapi_PBlock *pb, int modtype) > goto done; > } > > - overlap = ranges_overlap(old_range, new_range); > + no_overlap = ranges_overlap(new_range, old_range); > free(old_range); > old_range = NULL; > - if (overlap) { > - LOG_FATAL("New range overlaps with existing one.\n"); > + if (no_overlap != 0) { > ret = LDAP_CONSTRAINT_VIOLATION; > - errmsg = "New range overlaps with existing one."; > + if (no_overlap==1) { > + errmsg = "New base range overlaps with existing base range."; > + LOG_FATAL("New base range overlaps with existing base range.\n"); > + } > + if (no_overlap==2) { > + errmsg = "New primary rid range overlaps with existing primary rid range."; > + LOG_FATAL("New primary rid range overlaps with existing primary rid range.\n"); > + } > + if (no_overlap==3) { > + errmsg = "New secondary rid range overlaps with existing secondary rid range."; > + LOG_FATAL("New secondary rid range overlaps with existing secondary rid range.\n"); > + } > + if (no_overlap==4) { > + errmsg = "New primary rid range overlaps with existing secondary rid range."; > + LOG_FATAL("New primary rid range overlaps with existing secondary rid range.\n"); > + } > + if (no_overlap==5) { > + errmsg = "New secondary rid range overlaps with existing primary rid range."; > + LOG_FATAL("New secondary rid range overlaps with existing primary rid range.\n"); > + } Can you change this to a switch block? Please also add a default section. This was new return codes (for new checks) can be added and we still get a message even if it does not have a matching message here. LOG_FATAL can handle arguments, so I would suggest to add a LOG_FATAL("%s\n", errmsg); after the switch block. > goto done; > } > } From sbose at redhat.com Wed Oct 17 09:43:25 2012 From: sbose at redhat.com (Sumit Bose) Date: Wed, 17 Oct 2012 11:43:25 +0200 Subject: [Freeipa-devel] [PATCH] 0087 Warn about DNA plugin configuration when working with local ID ranges In-Reply-To: <20121010095953.GP17454@redhat.com> References: <20121010075111.GJ17454@redhat.com> <20121010094744.GC2134@localhost.localdomain> <20121010095953.GP17454@redhat.com> Message-ID: <20121017094325.GS23959@localhost.localdomain> On Wed, Oct 10, 2012 at 12:59:53PM +0300, Alexander Bokovoy wrote: > On Wed, 10 Oct 2012, Sumit Bose wrote: > >On Wed, Oct 10, 2012 at 10:51:11AM +0300, Alexander Bokovoy wrote: > >> > >>Warn about manual DNA plugin configuration when working with local ID ranges > >>since we currently do not support automatic pick up of the changed > >>settings for local ID ranges by the DNA plugin. > >>https://fedorahosted.org/freeipa/ticket/3116 > >> > >> > >>-- > >>/ Alexander Bokovoy > > > >> """) > > > >I wonder if we should add a sentence like "See section 'Managing Unique > >UID and GID Number Assignments' in the FreeIPA Documentation for > >details' to point the admin to the right directory? Or replace the last > >sentence with something more explicit like 'The dnaNextRange attribute > >of 'cn=Posix IDs,cn=Distributed Numeric Assignment > >Plugin,cn=plugins,cn=config' has to be modified to match the new range'? > Updated the patch, also adding the same warning to the 'idrange-add' > help. > > -- > / Alexander Bokovoy ACK. If there is an easy way to avoid the duplication it would be nice if you can modify the patch accordingly. bye, Sumit From pvoborni at redhat.com Wed Oct 17 10:02:38 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 17 Oct 2012 12:02:38 +0200 Subject: [Freeipa-devel] [PATCHES] backport of Firefox extension to FreeIPA 2.2 In-Reply-To: <507D86F8.60706@redhat.com> References: <5076C1D5.20403@redhat.com> <5077F721.5060003@redhat.com> <507D86F8.60706@redhat.com> Message-ID: <507E823E.4090703@redhat.com> On 10/16/2012 06:10 PM, Endi Sukma Dewata wrote: > On 10/12/2012 5:55 AM, Petr Viktorin wrote: >> On 10/11/2012 02:55 PM, Petr Vobornik wrote: >>> This bunch of patches is a backport of Firefox extension to FreeIPA 2.2. >>> >>> First apply pvoborni's patches then pviktori's. >> >> I tested several replication/upgrade scenarios. Upgrading from 2.2.0 and >> to master works fine. ACK for the Python part. > > ACK for the JavaScript part. Pushed to ipa-2-2 > > Just a minor issue, there's a typo in ipa_init.json and internal.py, I > think it's supposed to use a curly bracket: > > http://${host]/ipa/config/unauthorized.html > > This problem exists on both pvoborni-219-1 and pvoborni-219-2-2 patches. > Fixed, attaching updated and pushed patch for ipa-2-2. I will send patch for 3.0 separately. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0219-2-2-1-Configuration-pages-changed-to-use-new-FF-extension.patch Type: text/x-patch Size: 33011 bytes Desc: not available URL: From pvoborni at redhat.com Wed Oct 17 10:07:09 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 17 Oct 2012 12:07:09 +0200 Subject: [Freeipa-devel] [PATCH] 222 Fixed incorrect link to browser config after session expiration Message-ID: <507E834D.7060806@redhat.com> Fixed typo in message placeholder. https://fedorahosted.org/freeipa/ticket/3187 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0222-Fixed-incorrect-link-to-browser-config-after-session.patch Type: text/x-patch Size: 2649 bytes Desc: not available URL: From mkosek at redhat.com Wed Oct 17 10:09:24 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 17 Oct 2012 12:09:24 +0200 Subject: [Freeipa-devel] [PATCH] 0087 Warn about DNA plugin configuration when working with local ID ranges In-Reply-To: <20121017094325.GS23959@localhost.localdomain> References: <20121010075111.GJ17454@redhat.com> <20121010094744.GC2134@localhost.localdomain> <20121010095953.GP17454@redhat.com> <20121017094325.GS23959@localhost.localdomain> Message-ID: <507E83D4.1000306@redhat.com> On 10/17/2012 11:43 AM, Sumit Bose wrote: > On Wed, Oct 10, 2012 at 12:59:53PM +0300, Alexander Bokovoy wrote: >> On Wed, 10 Oct 2012, Sumit Bose wrote: >>> On Wed, Oct 10, 2012 at 10:51:11AM +0300, Alexander Bokovoy wrote: >>>> >>>> Warn about manual DNA plugin configuration when working with local ID ranges >>>> since we currently do not support automatic pick up of the changed >>>> settings for local ID ranges by the DNA plugin. >>>> https://fedorahosted.org/freeipa/ticket/3116 >>>> >>>> >>>> -- >>>> / Alexander Bokovoy >>> >>>> """) >>> >>> I wonder if we should add a sentence like "See section 'Managing Unique >>> UID and GID Number Assignments' in the FreeIPA Documentation for >>> details' to point the admin to the right directory? Or replace the last >>> sentence with something more explicit like 'The dnaNextRange attribute >>> of 'cn=Posix IDs,cn=Distributed Numeric Assignment >>> Plugin,cn=plugins,cn=config' has to be modified to match the new range'? >> Updated the patch, also adding the same warning to the 'idrange-add' >> help. >> >> -- >> / Alexander Bokovoy > > ACK. > > If there is an easy way to avoid the duplication it would be nice if you > can modify the patch accordingly. > > bye, > Sumit > Pushed to master, ipa-3-0. Martin From abokovoy at redhat.com Wed Oct 17 10:10:14 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 17 Oct 2012 13:10:14 +0300 Subject: [Freeipa-devel] [PATCH] 0087 Warn about DNA plugin configuration when working with local ID ranges In-Reply-To: <20121017094325.GS23959@localhost.localdomain> References: <20121010075111.GJ17454@redhat.com> <20121010094744.GC2134@localhost.localdomain> <20121010095953.GP17454@redhat.com> <20121017094325.GS23959@localhost.localdomain> Message-ID: <20121017101014.GQ17454@redhat.com> On Wed, 17 Oct 2012, Sumit Bose wrote: >On Wed, Oct 10, 2012 at 12:59:53PM +0300, Alexander Bokovoy wrote: >> On Wed, 10 Oct 2012, Sumit Bose wrote: >> >On Wed, Oct 10, 2012 at 10:51:11AM +0300, Alexander Bokovoy wrote: >> >> >> >>Warn about manual DNA plugin configuration when working with local ID ranges >> >>since we currently do not support automatic pick up of the changed >> >>settings for local ID ranges by the DNA plugin. >> >>https://fedorahosted.org/freeipa/ticket/3116 >> >> >> >> >> >>-- >> >>/ Alexander Bokovoy >> > >> >> """) >> > >> >I wonder if we should add a sentence like "See section 'Managing Unique >> >UID and GID Number Assignments' in the FreeIPA Documentation for >> >details' to point the admin to the right directory? Or replace the last >> >sentence with something more explicit like 'The dnaNextRange attribute >> >of 'cn=Posix IDs,cn=Distributed Numeric Assignment >> >Plugin,cn=plugins,cn=config' has to be modified to match the new range'? >> Updated the patch, also adding the same warning to the 'idrange-add' >> help. >> >> -- >> / Alexander Bokovoy > >ACK. > >If there is an easy way to avoid the duplication it would be nice if you >can modify the patch accordingly. Docstring is a string literal only: >>> s="""text ... first ... second""" >>> def f(): ... """another text ... first ... second"""+s ... return ... >>> print f.__doc__ None >>> def y(): ... """Doctstring for y()""" ... return ... >>> print y.__doc__ Doctstring for y() >>> Though we could play the game and do explicit f.__doc__ = s this would work but... Any preference from others?. -- / Alexander Bokovoy From pviktori at redhat.com Wed Oct 17 10:14:17 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 17 Oct 2012 12:14:17 +0200 Subject: [Freeipa-devel] [PATCH] 0087 Warn about DNA plugin configuration when working with local ID ranges In-Reply-To: <20121017101014.GQ17454@redhat.com> References: <20121010075111.GJ17454@redhat.com> <20121010094744.GC2134@localhost.localdomain> <20121010095953.GP17454@redhat.com> <20121017094325.GS23959@localhost.localdomain> <20121017101014.GQ17454@redhat.com> Message-ID: <507E84F9.5070400@redhat.com> On 10/17/2012 12:10 PM, Alexander Bokovoy wrote: > On Wed, 17 Oct 2012, Sumit Bose wrote: >> On Wed, Oct 10, 2012 at 12:59:53PM +0300, Alexander Bokovoy wrote: >>> On Wed, 10 Oct 2012, Sumit Bose wrote: >>> >On Wed, Oct 10, 2012 at 10:51:11AM +0300, Alexander Bokovoy wrote: >>> >> >>> >>Warn about manual DNA plugin configuration when working with local >>> ID ranges >>> >>since we currently do not support automatic pick up of the changed >>> >>settings for local ID ranges by the DNA plugin. >>> >>https://fedorahosted.org/freeipa/ticket/3116 >>> >> >>> >> >>> >>-- >>> >>/ Alexander Bokovoy >>> > >>> >> """) >>> > >>> >I wonder if we should add a sentence like "See section 'Managing Unique >>> >UID and GID Number Assignments' in the FreeIPA Documentation for >>> >details' to point the admin to the right directory? Or replace the last >>> >sentence with something more explicit like 'The dnaNextRange attribute >>> >of 'cn=Posix IDs,cn=Distributed Numeric Assignment >>> >Plugin,cn=plugins,cn=config' has to be modified to match the new >>> range'? >>> Updated the patch, also adding the same warning to the 'idrange-add' >>> help. >>> >>> -- >>> / Alexander Bokovoy >> >> ACK. >> >> If there is an easy way to avoid the duplication it would be nice if you >> can modify the patch accordingly. > Docstring is a string literal only: > >>> s="""text > ... first > ... second""" > >>> def f(): > ... """another text > ... first > ... second"""+s > ... return > ... >>> print f.__doc__ > None > >>> def y(): > ... """Doctstring for y()""" > ... return > ... > >>> print y.__doc__ > Doctstring for y() > >>> > > Though we could play the game and do explicit f.__doc__ = s > this would work but... > > Any preference from others?. In the code you changed, we already play that game. -- Petr? From mkosek at redhat.com Wed Oct 17 10:41:35 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 17 Oct 2012 12:41:35 +0200 Subject: [Freeipa-devel] [PATCH] 0087 Warn about DNA plugin configuration when working with local ID ranges In-Reply-To: <507E84F9.5070400@redhat.com> References: <20121010075111.GJ17454@redhat.com> <20121010094744.GC2134@localhost.localdomain> <20121010095953.GP17454@redhat.com> <20121017094325.GS23959@localhost.localdomain> <20121017101014.GQ17454@redhat.com> <507E84F9.5070400@redhat.com> Message-ID: <507E8B5F.6060406@redhat.com> On 10/17/2012 12:14 PM, Petr Viktorin wrote: > On 10/17/2012 12:10 PM, Alexander Bokovoy wrote: >> On Wed, 17 Oct 2012, Sumit Bose wrote: >>> On Wed, Oct 10, 2012 at 12:59:53PM +0300, Alexander Bokovoy wrote: >>>> On Wed, 10 Oct 2012, Sumit Bose wrote: >>>> >On Wed, Oct 10, 2012 at 10:51:11AM +0300, Alexander Bokovoy wrote: >>>> >> >>>> >>Warn about manual DNA plugin configuration when working with local >>>> ID ranges >>>> >>since we currently do not support automatic pick up of the changed >>>> >>settings for local ID ranges by the DNA plugin. >>>> >>https://fedorahosted.org/freeipa/ticket/3116 >>>> >> >>>> >> >>>> >>-- >>>> >>/ Alexander Bokovoy >>>> > >>>> >> """) >>>> > >>>> >I wonder if we should add a sentence like "See section 'Managing Unique >>>> >UID and GID Number Assignments' in the FreeIPA Documentation for >>>> >details' to point the admin to the right directory? Or replace the last >>>> >sentence with something more explicit like 'The dnaNextRange attribute >>>> >of 'cn=Posix IDs,cn=Distributed Numeric Assignment >>>> >Plugin,cn=plugins,cn=config' has to be modified to match the new >>>> range'? >>>> Updated the patch, also adding the same warning to the 'idrange-add' >>>> help. >>>> >>>> -- >>>> / Alexander Bokovoy >>> >>> ACK. >>> >>> If there is an easy way to avoid the duplication it would be nice if you >>> can modify the patch accordingly. >> Docstring is a string literal only: >> >>> s="""text >> ... first >> ... second""" >> >>> def f(): >> ... """another text >> ... first >> ... second"""+s >> ... return >> ... >>> print f.__doc__ >> None >> >>> def y(): >> ... """Doctstring for y()""" >> ... return >> ... >> >>> print y.__doc__ >> Doctstring for y() >> >>> >> >> Though we could play the game and do explicit f.__doc__ = s >> this would work but... >> >> Any preference from others?. > > In the code you changed, we already play that game. > Ok, it seems I pushed the patch way too early. If Alexander wants to, he can prepare a patch to fix the duplication and we I can push the change then. You may also need to fix indentation in idrange-add command help, it is now indented too much and it would make deduplication complicated. Martin From abokovoy at redhat.com Wed Oct 17 10:42:38 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 17 Oct 2012 13:42:38 +0300 Subject: [Freeipa-devel] [PATCH] 0087 Warn about DNA plugin configuration when working with local ID ranges In-Reply-To: <507E84F9.5070400@redhat.com> References: <20121010075111.GJ17454@redhat.com> <20121010094744.GC2134@localhost.localdomain> <20121010095953.GP17454@redhat.com> <20121017094325.GS23959@localhost.localdomain> <20121017101014.GQ17454@redhat.com> <507E84F9.5070400@redhat.com> Message-ID: <20121017104238.GR17454@redhat.com> On Wed, 17 Oct 2012, Petr Viktorin wrote: >On 10/17/2012 12:10 PM, Alexander Bokovoy wrote: >>On Wed, 17 Oct 2012, Sumit Bose wrote: >>>On Wed, Oct 10, 2012 at 12:59:53PM +0300, Alexander Bokovoy wrote: >>>>On Wed, 10 Oct 2012, Sumit Bose wrote: >>>>>On Wed, Oct 10, 2012 at 10:51:11AM +0300, Alexander Bokovoy wrote: >>>>>> >>>>>>Warn about manual DNA plugin configuration when working with local >>>>ID ranges >>>>>>since we currently do not support automatic pick up of the changed >>>>>>settings for local ID ranges by the DNA plugin. >>>>>>https://fedorahosted.org/freeipa/ticket/3116 >>>>>> >>>>>> >>>>>>-- >>>>>>/ Alexander Bokovoy >>>>> >>>>>> """) >>>>> >>>>>I wonder if we should add a sentence like "See section 'Managing Unique >>>>>UID and GID Number Assignments' in the FreeIPA Documentation for >>>>>details' to point the admin to the right directory? Or replace the last >>>>>sentence with something more explicit like 'The dnaNextRange attribute >>>>>of 'cn=Posix IDs,cn=Distributed Numeric Assignment >>>>>Plugin,cn=plugins,cn=config' has to be modified to match the new >>>>range'? >>>>Updated the patch, also adding the same warning to the 'idrange-add' >>>>help. >>>> >>>>-- >>>>/ Alexander Bokovoy >>> >>>ACK. >>> >>>If there is an easy way to avoid the duplication it would be nice if you >>>can modify the patch accordingly. >>Docstring is a string literal only: >> >>> s="""text >> ... first >> ... second""" >> >>> def f(): >> ... """another text >> ... first >> ... second"""+s >> ... return >> ... >>> print f.__doc__ >> None >> >>> def y(): >> ... """Doctstring for y()""" >> ... return >> ... >> >>> print y.__doc__ >> Doctstring for y() >> >>> >> >>Though we could play the game and do explicit f.__doc__ = s >>this would work but... >> >>Any preference from others?. > >In the code you changed, we already play that game. No, we don't. We do explicit string literals wrapped into Gettext() calls but it does not change the fact that they are still literals and xgettext does not support arbitrary expressions in Python code. I tried two different approaches: 1. a = _("""one text""") __doc__ = _("""another text""") + a 2. a = """one text""" __doc__ = _("""another text""" + a) Both don't work. First is because Gettext() class does not support concatenation. Second one is because xgettext does not work with such form and only takes """another text""". -- / Alexander Bokovoy From abokovoy at redhat.com Wed Oct 17 10:43:52 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 17 Oct 2012 13:43:52 +0300 Subject: [Freeipa-devel] [PATCH] 0087 Warn about DNA plugin configuration when working with local ID ranges In-Reply-To: <507E8B5F.6060406@redhat.com> References: <20121010075111.GJ17454@redhat.com> <20121010094744.GC2134@localhost.localdomain> <20121010095953.GP17454@redhat.com> <20121017094325.GS23959@localhost.localdomain> <20121017101014.GQ17454@redhat.com> <507E84F9.5070400@redhat.com> <507E8B5F.6060406@redhat.com> Message-ID: <20121017104352.GS17454@redhat.com> On Wed, 17 Oct 2012, Martin Kosek wrote: >On 10/17/2012 12:14 PM, Petr Viktorin wrote: >> On 10/17/2012 12:10 PM, Alexander Bokovoy wrote: >>> On Wed, 17 Oct 2012, Sumit Bose wrote: >>>> On Wed, Oct 10, 2012 at 12:59:53PM +0300, Alexander Bokovoy wrote: >>>>> On Wed, 10 Oct 2012, Sumit Bose wrote: >>>>> >On Wed, Oct 10, 2012 at 10:51:11AM +0300, Alexander Bokovoy wrote: >>>>> >> >>>>> >>Warn about manual DNA plugin configuration when working with local >>>>> ID ranges >>>>> >>since we currently do not support automatic pick up of the changed >>>>> >>settings for local ID ranges by the DNA plugin. >>>>> >>https://fedorahosted.org/freeipa/ticket/3116 >>>>> >> >>>>> >> >>>>> >>-- >>>>> >>/ Alexander Bokovoy >>>>> > >>>>> >> """) >>>>> > >>>>> >I wonder if we should add a sentence like "See section 'Managing Unique >>>>> >UID and GID Number Assignments' in the FreeIPA Documentation for >>>>> >details' to point the admin to the right directory? Or replace the last >>>>> >sentence with something more explicit like 'The dnaNextRange attribute >>>>> >of 'cn=Posix IDs,cn=Distributed Numeric Assignment >>>>> >Plugin,cn=plugins,cn=config' has to be modified to match the new >>>>> range'? >>>>> Updated the patch, also adding the same warning to the 'idrange-add' >>>>> help. >>>>> >>>>> -- >>>>> / Alexander Bokovoy >>>> >>>> ACK. >>>> >>>> If there is an easy way to avoid the duplication it would be nice if you >>>> can modify the patch accordingly. >>> Docstring is a string literal only: >>> >>> s="""text >>> ... first >>> ... second""" >>> >>> def f(): >>> ... """another text >>> ... first >>> ... second"""+s >>> ... return >>> ... >>> print f.__doc__ >>> None >>> >>> def y(): >>> ... """Doctstring for y()""" >>> ... return >>> ... >>> >>> print y.__doc__ >>> Doctstring for y() >>> >>> >>> >>> Though we could play the game and do explicit f.__doc__ = s >>> this would work but... >>> >>> Any preference from others?. >> >> In the code you changed, we already play that game. >> > >Ok, it seems I pushed the patch way too early. If Alexander wants to, he can >prepare a patch to fix the duplication and we I can push the change then. See my another email. We have more fundamental issues that prevent this kind of message reuse. You pushed the right patch, I believe. -- / Alexander Bokovoy From mkosek at redhat.com Wed Oct 17 10:48:24 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 17 Oct 2012 12:48:24 +0200 Subject: [Freeipa-devel] [PATCH] 0087 Warn about DNA plugin configuration when working with local ID ranges In-Reply-To: <20121017104238.GR17454@redhat.com> References: <20121010075111.GJ17454@redhat.com> <20121010094744.GC2134@localhost.localdomain> <20121010095953.GP17454@redhat.com> <20121017094325.GS23959@localhost.localdomain> <20121017101014.GQ17454@redhat.com> <507E84F9.5070400@redhat.com> <20121017104238.GR17454@redhat.com> Message-ID: <507E8CF8.9030901@redhat.com> On 10/17/2012 12:42 PM, Alexander Bokovoy wrote: > On Wed, 17 Oct 2012, Petr Viktorin wrote: >> On 10/17/2012 12:10 PM, Alexander Bokovoy wrote: >>> On Wed, 17 Oct 2012, Sumit Bose wrote: >>>> On Wed, Oct 10, 2012 at 12:59:53PM +0300, Alexander Bokovoy wrote: >>>>> On Wed, 10 Oct 2012, Sumit Bose wrote: >>>>>> On Wed, Oct 10, 2012 at 10:51:11AM +0300, Alexander Bokovoy wrote: >>>>>>> >>>>>>> Warn about manual DNA plugin configuration when working with local >>>>> ID ranges >>>>>>> since we currently do not support automatic pick up of the changed >>>>>>> settings for local ID ranges by the DNA plugin. >>>>>>> https://fedorahosted.org/freeipa/ticket/3116 >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> / Alexander Bokovoy >>>>>> >>>>>>> """) >>>>>> >>>>>> I wonder if we should add a sentence like "See section 'Managing Unique >>>>>> UID and GID Number Assignments' in the FreeIPA Documentation for >>>>>> details' to point the admin to the right directory? Or replace the last >>>>>> sentence with something more explicit like 'The dnaNextRange attribute >>>>>> of 'cn=Posix IDs,cn=Distributed Numeric Assignment >>>>>> Plugin,cn=plugins,cn=config' has to be modified to match the new >>>>> range'? >>>>> Updated the patch, also adding the same warning to the 'idrange-add' >>>>> help. >>>>> >>>>> -- >>>>> / Alexander Bokovoy >>>> >>>> ACK. >>>> >>>> If there is an easy way to avoid the duplication it would be nice if you >>>> can modify the patch accordingly. >>> Docstring is a string literal only: >>> >>> s="""text >>> ... first >>> ... second""" >>> >>> def f(): >>> ... """another text >>> ... first >>> ... second"""+s >>> ... return >>> ... >>> print f.__doc__ >>> None >>> >>> def y(): >>> ... """Doctstring for y()""" >>> ... return >>> ... >>> >>> print y.__doc__ >>> Doctstring for y() >>> >>> >>> >>> Though we could play the game and do explicit f.__doc__ = s >>> this would work but... >>> >>> Any preference from others?. >> >> In the code you changed, we already play that game. > No, we don't. We do explicit string literals wrapped into Gettext() > calls but it does not change the fact that they are still literals and > xgettext does not support arbitrary expressions in Python code. > > I tried two different approaches: > 1. a = _("""one text""") > __doc__ = _("""another text""") + a > > 2. a = """one text""" > __doc__ = _("""another text""" + a) > > Both don't work. First is because Gettext() class does not support > concatenation. Second one is because xgettext does not work with such > form and only takes """another text""". > I think I still do not get it, what's wrong with my example? # python >>> from ipalib import _ >>> a = """Bonus text""" >>> __doc__ = _("""Another Text""" + a) >>> __doc__ Gettext('Another TextBonus text', domain='ipa', localedir=None) >>> unicode(__doc__) u'Another TextBonus text' Am I missing something? Martin From sbose at redhat.com Wed Oct 17 10:52:11 2012 From: sbose at redhat.com (Sumit Bose) Date: Wed, 17 Oct 2012 12:52:11 +0200 Subject: [Freeipa-devel] [PATCH] 0089 Clarify trust-add help regarding multiple runs against the same domain In-Reply-To: <20121010150502.GY17454@redhat.com> References: <20121010150502.GY17454@redhat.com> Message-ID: <20121017105211.GT23959@localhost.localdomain> On Wed, Oct 10, 2012 at 06:05:02PM +0300, Alexander Bokovoy wrote: > Hi, > > this patch originated from off-list discussion regarding multiple runs > of ipa trust-add against the same domain. > > Since trust-add re-establishes the trust every time it is run and all > the other information fetched from the remote domain controller stays > the same, it can be run multiple times. The only change would occur is > update of trust relationship credentials -- they are supposed to be > updated periodically by underlying infrastructure anyway. > > So the patch adds some clarity to the help and changes summary message > when trust was re-established instead of created. > -- > / Alexander Bokovoy ACK Btw, another useful feature of allowing to run trust-add multiple times is to re-established the trust if it was deleted only on one side, AD or IPA. Having a separate command for this would make no sense because it would be basically be an alias to trust-add. bye, Sumit From pvoborni at redhat.com Wed Oct 17 10:55:39 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 17 Oct 2012 12:55:39 +0200 Subject: [Freeipa-devel] [PATCH] 223 Simpler instructions to generate certificate Message-ID: <507E8EAB.1050309@redhat.com> Instructions to generate certificate were simplified. New instructions: 1) Create a certificate database or use an existing one. To create a new database: # certutil -N -d 2) Create a CSR with subject CN=,O=, for example: # certutil -R -d -a -g -s 'CN=dev.example.com,O=DEV.EXAMPLE.COM' 3) Copy and paste the CSR (from -----BEGIN NEW CERTIFICATE REQUEST----- to -----END NEW CERTIFICATE REQUEST-----) into the text area below: https://fedorahosted.org/freeipa/ticket/3056 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0223-Simpler-instructions-to-generate-certificate.patch Type: text/x-patch Size: 4935 bytes Desc: not available URL: From abokovoy at redhat.com Wed Oct 17 10:57:33 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 17 Oct 2012 13:57:33 +0300 Subject: [Freeipa-devel] [PATCH] 0087 Warn about DNA plugin configuration when working with local ID ranges In-Reply-To: <507E8CF8.9030901@redhat.com> References: <20121010075111.GJ17454@redhat.com> <20121010094744.GC2134@localhost.localdomain> <20121010095953.GP17454@redhat.com> <20121017094325.GS23959@localhost.localdomain> <20121017101014.GQ17454@redhat.com> <507E84F9.5070400@redhat.com> <20121017104238.GR17454@redhat.com> <507E8CF8.9030901@redhat.com> Message-ID: <20121017105733.GT17454@redhat.com> On Wed, 17 Oct 2012, Martin Kosek wrote: >On 10/17/2012 12:42 PM, Alexander Bokovoy wrote: >> On Wed, 17 Oct 2012, Petr Viktorin wrote: >>> On 10/17/2012 12:10 PM, Alexander Bokovoy wrote: >>>> On Wed, 17 Oct 2012, Sumit Bose wrote: >>>>> On Wed, Oct 10, 2012 at 12:59:53PM +0300, Alexander Bokovoy wrote: >>>>>> On Wed, 10 Oct 2012, Sumit Bose wrote: >>>>>>> On Wed, Oct 10, 2012 at 10:51:11AM +0300, Alexander Bokovoy wrote: >>>>>>>> >>>>>>>> Warn about manual DNA plugin configuration when working with local >>>>>> ID ranges >>>>>>>> since we currently do not support automatic pick up of the changed >>>>>>>> settings for local ID ranges by the DNA plugin. >>>>>>>> https://fedorahosted.org/freeipa/ticket/3116 >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> / Alexander Bokovoy >>>>>>> >>>>>>>> """) >>>>>>> >>>>>>> I wonder if we should add a sentence like "See section 'Managing Unique >>>>>>> UID and GID Number Assignments' in the FreeIPA Documentation for >>>>>>> details' to point the admin to the right directory? Or replace the last >>>>>>> sentence with something more explicit like 'The dnaNextRange attribute >>>>>>> of 'cn=Posix IDs,cn=Distributed Numeric Assignment >>>>>>> Plugin,cn=plugins,cn=config' has to be modified to match the new >>>>>> range'? >>>>>> Updated the patch, also adding the same warning to the 'idrange-add' >>>>>> help. >>>>>> >>>>>> -- >>>>>> / Alexander Bokovoy >>>>> >>>>> ACK. >>>>> >>>>> If there is an easy way to avoid the duplication it would be nice if you >>>>> can modify the patch accordingly. >>>> Docstring is a string literal only: >>>> >>> s="""text >>>> ... first >>>> ... second""" >>>> >>> def f(): >>>> ... """another text >>>> ... first >>>> ... second"""+s >>>> ... return >>>> ... >>> print f.__doc__ >>>> None >>>> >>> def y(): >>>> ... """Doctstring for y()""" >>>> ... return >>>> ... >>>> >>> print y.__doc__ >>>> Doctstring for y() >>>> >>> >>>> >>>> Though we could play the game and do explicit f.__doc__ = s >>>> this would work but... >>>> >>>> Any preference from others?. >>> >>> In the code you changed, we already play that game. >> No, we don't. We do explicit string literals wrapped into Gettext() >> calls but it does not change the fact that they are still literals and >> xgettext does not support arbitrary expressions in Python code. >> >> I tried two different approaches: >> 1. a = _("""one text""") >> __doc__ = _("""another text""") + a >> >> 2. a = """one text""" >> __doc__ = _("""another text""" + a) >> >> Both don't work. First is because Gettext() class does not support >> concatenation. Second one is because xgettext does not work with such >> form and only takes """another text""". >> > >I think I still do not get it, what's wrong with my example? > ># python >>>> from ipalib import _ >>>> a = """Bonus text""" >>>> __doc__ = _("""Another Text""" + a) >>>> __doc__ >Gettext('Another TextBonus text', domain='ipa', localedir=None) >>>> unicode(__doc__) >u'Another TextBonus text' > >Am I missing something? Yes. You are missing xgettext utility. It does extract strings for translation. In your example it would extract """Another Text""" only, because it does not support evaluation of expressions. More to that, the actual code would ask then for translated string with msgid """Another TextBonus text""" which does not exist in the translation catalog at all. This means whatever was translated for """Another Text""" will never be shown. We need to make Gettext() class additive, so that when two Gettext() instances are added, they accumulate msgid(s) and then do concatenation of translated entries on __str__. -- / Alexander Bokovoy From mkosek at redhat.com Wed Oct 17 10:59:43 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 17 Oct 2012 12:59:43 +0200 Subject: [Freeipa-devel] [PATCH] 0089 Clarify trust-add help regarding multiple runs against the same domain In-Reply-To: <20121017105211.GT23959@localhost.localdomain> References: <20121010150502.GY17454@redhat.com> <20121017105211.GT23959@localhost.localdomain> Message-ID: <507E8F9F.4060606@redhat.com> On 10/17/2012 12:52 PM, Sumit Bose wrote: > On Wed, Oct 10, 2012 at 06:05:02PM +0300, Alexander Bokovoy wrote: >> Hi, >> >> this patch originated from off-list discussion regarding multiple runs >> of ipa trust-add against the same domain. >> >> Since trust-add re-establishes the trust every time it is run and all >> the other information fetched from the remote domain controller stays >> the same, it can be run multiple times. The only change would occur is >> update of trust relationship credentials -- they are supposed to be >> updated periodically by underlying infrastructure anyway. >> >> So the patch adds some clarity to the help and changes summary message >> when trust was re-established instead of created. >> -- >> / Alexander Bokovoy > > ACK > > Btw, another useful feature of allowing to run trust-add multiple times > is to re-established the trust if it was deleted only on one side, AD or > IPA. Having a separate command for this would make no sense because it > would be basically be an alias to trust-add. > > bye, > Sumit > I am still a bit worried about our consistency with IPA command help indentation. You have it indented with trust-add command: # ipa help trust-add Purpose: Add new trust to use. This command establishes trust relationship to another domain which becomes 'trusted'. As result, users of the trusted domain may access resources of this domain. ... But other commands don't, e.g.: # ipa help passwd Set a user's password If someone other than a user changes that user's password (e.g., Helpdesk resets it) then the p... # ipa help ping Ping the remote IPA server to ensure it is running. The ping command sends an echo request to an IPA server. The server ... Martin From tbabej at redhat.com Wed Oct 17 10:59:52 2012 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 17 Oct 2012 12:59:52 +0200 Subject: [Freeipa-devel] [PATCH 0019] Forbid overlapping primary and secondary rid ranges In-Reply-To: <20121017091451.GR23959@localhost.localdomain> References: <507D5270.20904@redhat.com> <20121017091451.GR23959@localhost.localdomain> Message-ID: <507E8FA8.3070501@redhat.com> On 10/17/2012 11:14 AM, Sumit Bose wrote: > On Tue, Oct 16, 2012 at 02:26:24PM +0200, Tomas Babej wrote: >> Hi, >> >> commands ipa idrange-add / idrange-mod no longer allows the user >> to enter primary or secondary rid range such that has non-zero >> intersection with primary or secondary rid range of another >> existing id range, as this could cause collision. >> >> Unit tests added to test_range_plugin.py >> >> https://fedorahosted.org/freeipa/ticket/3086 >> >> Tomas > Thank you for the patch, comments are in-line. > > bye, > Sumit > >> >From a46a8d0aa4e64e105a53a177b6a12cf28e56620e Mon Sep 17 00:00:00 2001 >> From: Tomas Babej >> Date: Mon, 15 Oct 2012 06:28:16 -0400 >> Subject: [PATCH] Forbid overlapping primary and secondary rid ranges >> >> Commands ipa idrange-add / idrange-mod no longer allows the user >> to enter primary or secondary rid range such that has non-zero >> intersection with primary or secondary rid range of another >> existing id range, as this could cause collision. >> >> Unit tests added to test_range_plugin.py >> >> https://fedorahosted.org/freeipa/ticket/3086 >> --- >> .../ipa-range-check/ipa_range_check.c | 93 +++++++++++++--- >> tests/test_xmlrpc/test_range_plugin.py | 120 +++++++++++++++++++-- >> 2 files changed, 191 insertions(+), 22 deletions(-) >> >> diff --git a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c >> index 499e54a9c4a4c9134a231c0cd09e700390565a14..4f9f7437d11d2bc33238b14f5099a42b4c5463d2 100644 >> --- a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c >> +++ b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c >> @@ -132,24 +132,67 @@ done: >> return ret; >> } >> >> -#define IN_RANGE(x,base,size) ( (x) >= (base) && ((x) - (base)) < (size) ) >> -static bool ranges_overlap(struct range_info *r1, struct range_info *r2) >> +#define IN_RANGE(x,base,size) ( (x) >= (base) && (x) < (size+base) ) > Would you mind to use the original definition of IN_RANGE? x-base looks > a bit odd, but I made it on purpose to avoid overruns. Since we already > know that x>=base we can be sure that there will be no underrun. > >> +static bool intervals_overlap(uint32_t x, uint32_t base, uint32_t x_size, uint32_t base_size) >> { >> - if (r1->name != NULL && r2->name != NULL && >> - strcasecmp(r1->name, r2->name) == 0) { >> - return false; >> - } >> - >> - if (IN_RANGE(r1->base_id, r2->base_id, r2->id_range_size) || >> - IN_RANGE((r1->base_id + r1->id_range_size - 1), r2->base_id, r2->id_range_size) || >> - IN_RANGE(r2->base_id, r1->base_id, r1->id_range_size) || >> - IN_RANGE((r2->base_id + r2->id_range_size - 1), r1->base_id, r1->id_range_size)) { >> + if (IN_RANGE(x, base, base_size) || >> + IN_RANGE((x + x_size - 1), base, base_size) || >> + IN_RANGE(base, x, x_size) || >> + IN_RANGE((base + base_size - 1), x, x_size)) { >> return true; >> } >> >> return false; >> } >> >> +//returns 0 if there is no overlap >> +//connected ranges must not overlap: >> +// existing range: base rid sec_rid >> +// | | \ / | >> +// | | \/ | >> +// | | /\ | >> +// | | / \ | >> +// new range: base rid sec_rid > I think we currently do not use C++ style comments in freeipa C code. > Can you switch to /* */ comments? > >> +static int ranges_overlap(struct range_info *r1, struct range_info *r2) >> +{ >> + if (r1->name != NULL && r2->name != NULL && >> + strcasecmp(r1->name, r2->name) == 0) { >> + return 0; >> + } >> + >> + //check if base range overlaps with existing base range >> + if (intervals_overlap(r1->base_id, r2->base_id, >> + r1->id_range_size, r2->id_range_size)){ >> + return 1; >> + } >> + >> + //if both base_rid and secondary_base_rid are 0, the rid range is not set >> + //in that case we skip the primary/secondary rid range overlap test >> + if((r1->base_rid!=0 || r1->secondary_base_rid!=0) && >> + (r2->base_rid!=0 || r2->secondary_base_rid!=0)){ > can you add spaces around '!=' ? > >> + >> + //check if rid range overlaps with existing rid range >> + if (intervals_overlap(r1->base_rid, r2->base_rid, >> + r1->id_range_size, r2->id_range_size)) >> + return 2; >> + >> + //check if secondary rid range overlaps with existing secondary rid range >> + if (intervals_overlap(r1->secondary_base_rid, r2->secondary_base_rid, >> + r1->id_range_size, r2->id_range_size)) >> + return 3; >> + >> + //check if rid range overlaps with existing secondary rid range >> + if (intervals_overlap(r1->base_rid, r2->secondary_base_rid, >> + r1->id_range_size, r2->id_range_size)) >> + return 4; >> + >> + //check if secondary rid range overlaps with existing rid range >> + if (intervals_overlap(r1->secondary_base_rid, r2->base_rid, >> + r1->id_range_size, r2->id_range_size)) >> + return 5; >> + } > Return code is missing if one of the ranges does not have the rid ranges > set. Can you add a test case for this condition as well? > >> +} >> + >> static int ipa_range_check_start(Slapi_PBlock *pb) >> { >> return 0; >> @@ -176,7 +219,7 @@ static int ipa_range_check_pre_op(Slapi_PBlock *pb, int modtype) >> int search_result; >> Slapi_Entry **search_entries = NULL; >> size_t c; >> - bool overlap = true; >> + int no_overlap = 0; >> const char *check_attr; >> char *errmsg = NULL; >> >> @@ -315,13 +358,31 @@ static int ipa_range_check_pre_op(Slapi_PBlock *pb, int modtype) >> goto done; >> } >> >> - overlap = ranges_overlap(old_range, new_range); >> + no_overlap = ranges_overlap(new_range, old_range); >> free(old_range); >> old_range = NULL; >> - if (overlap) { >> - LOG_FATAL("New range overlaps with existing one.\n"); >> + if (no_overlap != 0) { >> ret = LDAP_CONSTRAINT_VIOLATION; >> - errmsg = "New range overlaps with existing one."; >> + if (no_overlap==1) { >> + errmsg = "New base range overlaps with existing base range."; >> + LOG_FATAL("New base range overlaps with existing base range.\n"); >> + } >> + if (no_overlap==2) { >> + errmsg = "New primary rid range overlaps with existing primary rid range."; >> + LOG_FATAL("New primary rid range overlaps with existing primary rid range.\n"); >> + } >> + if (no_overlap==3) { >> + errmsg = "New secondary rid range overlaps with existing secondary rid range."; >> + LOG_FATAL("New secondary rid range overlaps with existing secondary rid range.\n"); >> + } >> + if (no_overlap==4) { >> + errmsg = "New primary rid range overlaps with existing secondary rid range."; >> + LOG_FATAL("New primary rid range overlaps with existing secondary rid range.\n"); >> + } >> + if (no_overlap==5) { >> + errmsg = "New secondary rid range overlaps with existing primary rid range."; >> + LOG_FATAL("New secondary rid range overlaps with existing primary rid range.\n"); >> + } > Can you change this to a switch block? Please also add a default > section. This was new return codes (for new checks) can be added and we > still get a message even if it does not have a matching message here. > > LOG_FATAL can handle arguments, so I would suggest to add a > > LOG_FATAL("%s\n", errmsg); > > after the switch block. > >> goto done; >> } >> } Thank you for your suggestions. New version of the patch attached. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0019-2-Forbid-overlapping-primary-and-secondary-rid-ranges.patch Type: text/x-patch Size: 13376 bytes Desc: not available URL: From atkac at redhat.com Wed Oct 17 11:04:16 2012 From: atkac at redhat.com (Adam Tkac) Date: Wed, 17 Oct 2012 13:04:16 +0200 Subject: [Freeipa-devel] Hide private symbols in the bind-dyndb-ldap Message-ID: <20121017110414.GA1944@redhat.com> Hello, attached patch hides all symbols except dynamic_driver_{init,destroy}. Feedback is appreciated. Regards, Adam -- Adam Tkac, Red Hat, Inc. -------------- next part -------------- >From 126929489baf4f69fe0444860776f7e76c1411f2 Mon Sep 17 00:00:00 2001 From: Adam Tkac Date: Wed, 17 Oct 2012 13:00:31 +0200 Subject: [PATCH] Hide all symbols except dynamic_driver_{init,destroy} Signed-off-by: Adam Tkac --- configure.ac | 15 +++++++++++++++ src/ldap_driver.c | 10 ++++++++-- 2 files changed, 23 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index cff5526..30a7374 100644 --- a/configure.ac +++ b/configure.ac @@ -30,6 +30,21 @@ AC_TYPE_SIZE_T # Checks for library functions. AC_CHECK_FUNCS([memset strcasecmp strncasecmp]) +# Check if build chain supports symbol visibility +AC_MSG_CHECKING([for -fvisibility=hidden compiler flag]) +SAVED_CFLAGS="$CFLAGS" +CFLAGS="$CFLAGS -fvisibility=hidden" +AC_TRY_COMPILE([ + extern __attribute__((__visibility__("hidden"))) int hidden; + extern __attribute__((__visibility__("default"))) int def; + extern __attribute__((__visibility__("hidden"))) int fhidden(void); + extern __attribute__((__visibility__("default"))) int fdef(void); +],[], +[AC_MSG_RESULT([yes]) + AC_DEFINE([HAVE_VISIBILITY], 1, [Define if compiler supports -fvisibility])], +[CFLAGS="$SAVED_CFLAGS" + AC_MSG_RESULT([no])]) + # Check version of libdns AC_MSG_CHECKING([libdns version]) AC_TRY_RUN([ diff --git a/src/ldap_driver.c b/src/ldap_driver.c index 3a80223..99a8421 100644 --- a/src/ldap_driver.c +++ b/src/ldap_driver.c @@ -52,6 +52,12 @@ #include "util.h" #include "zone_manager.h" +#ifdef HAVE_VISIBILITY +#define VISIBLE __attribute__((__visibility__("default"))) +#else +#define VISIBLE +#endif + #define LDAPDB_MAGIC ISC_MAGIC('L', 'D', 'P', 'D') #define VALID_LDAPDB(ldapdb) \ ((ldapdb) != NULL && (ldapdb)->common.impmagic == LDAPDB_MAGIC) @@ -1315,7 +1321,7 @@ static dns_dbimplementation_t *ldapdb_imp; const char *ldapdb_impname = "dynamic-ldap"; -isc_result_t +VISIBLE isc_result_t dynamic_driver_init(isc_mem_t *mctx, const char *name, const char * const *argv, dns_dyndb_arguments_t *dyndb_args) { @@ -1360,7 +1366,7 @@ dynamic_driver_init(isc_mem_t *mctx, const char *name, const char * const *argv, return result; } -void +VISIBLE void dynamic_driver_destroy(void) { /* Only unregister the implementation if it was registered by us. */ -- 1.7.11.7 From pviktori at redhat.com Wed Oct 17 11:09:12 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 17 Oct 2012 13:09:12 +0200 Subject: [Freeipa-devel] [PATCH] 0087 Warn about DNA plugin configuration when working with local ID ranges In-Reply-To: <20121017104238.GR17454@redhat.com> References: <20121010075111.GJ17454@redhat.com> <20121010094744.GC2134@localhost.localdomain> <20121010095953.GP17454@redhat.com> <20121017094325.GS23959@localhost.localdomain> <20121017101014.GQ17454@redhat.com> <507E84F9.5070400@redhat.com> <20121017104238.GR17454@redhat.com> Message-ID: <507E91D8.8040004@redhat.com> On 10/17/2012 12:42 PM, Alexander Bokovoy wrote: > On Wed, 17 Oct 2012, Petr Viktorin wrote: >> On 10/17/2012 12:10 PM, Alexander Bokovoy wrote: >>> On Wed, 17 Oct 2012, Sumit Bose wrote: >>>> On Wed, Oct 10, 2012 at 12:59:53PM +0300, Alexander Bokovoy wrote: >>>>> On Wed, 10 Oct 2012, Sumit Bose wrote: >>>>>> On Wed, Oct 10, 2012 at 10:51:11AM +0300, Alexander Bokovoy wrote: >>>>>>> >>>>>>> Warn about manual DNA plugin configuration when working with local >>>>> ID ranges >>>>>>> since we currently do not support automatic pick up of the changed >>>>>>> settings for local ID ranges by the DNA plugin. >>>>>>> https://fedorahosted.org/freeipa/ticket/3116 >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> / Alexander Bokovoy >>>>>> >>>>>>> """) >>>>>> >>>>>> I wonder if we should add a sentence like "See section 'Managing >>>>>> Unique >>>>>> UID and GID Number Assignments' in the FreeIPA Documentation for >>>>>> details' to point the admin to the right directory? Or replace the >>>>>> last >>>>>> sentence with something more explicit like 'The dnaNextRange >>>>>> attribute >>>>>> of 'cn=Posix IDs,cn=Distributed Numeric Assignment >>>>>> Plugin,cn=plugins,cn=config' has to be modified to match the new >>>>> range'? >>>>> Updated the patch, also adding the same warning to the 'idrange-add' >>>>> help. >>>>> >>>>> -- >>>>> / Alexander Bokovoy >>>> >>>> ACK. >>>> >>>> If there is an easy way to avoid the duplication it would be nice if >>>> you >>>> can modify the patch accordingly. >>> Docstring is a string literal only: >>> >>> s="""text >>> ... first >>> ... second""" >>> >>> def f(): >>> ... """another text >>> ... first >>> ... second"""+s >>> ... return >>> ... >>> print f.__doc__ >>> None >>> >>> def y(): >>> ... """Doctstring for y()""" >>> ... return >>> ... >>> >>> print y.__doc__ >>> Doctstring for y() >>> >>> >>> >>> Though we could play the game and do explicit f.__doc__ = s >>> this would work but... >>> >>> Any preference from others?. >> >> In the code you changed, we already play that game. > No, we don't. We do explicit string literals wrapped into Gettext() > calls but it does not change the fact that they are still literals and > xgettext does not support arbitrary expressions in Python code. > > I tried two different approaches: > 1. a = _("""one text""") > __doc__ = _("""another text""") + a > > 2. a = """one text""" > __doc__ = _("""another text""" + a) > > Both don't work. First is because Gettext() class does not support > concatenation. Second one is because xgettext does not work with such > form and only takes """another text""". > Ah, you're right. A similar complaint from another POV came from a translator not long ago. I've filed a ticket, https://fedorahosted.org/freeipa/ticket/3188 -- Petr? From mkosek at redhat.com Wed Oct 17 11:18:36 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 17 Oct 2012 13:18:36 +0200 Subject: [Freeipa-devel] [PATCH] 323 Report ipa-upgradeconfig errors during RPM upgrade Message-ID: <507E940C.1000002@redhat.com> Report errors just like with ipa-ldap-updater. These messages should warn user that some parts of the upgrades may have not been successful and he should follow up on them. Otherwise, user may not notice them at all. ipa-upgradeconfig logging has been made consistent with ipa-ldap-updater logging - only error level or higher severity log messages are printed to stderr, with the same console format. A new debug log that an upgrade script has started was added to make log investigation easier. https://fedorahosted.org/freeipa/ticket/3157 --- Reproducer is in Bugzilla attached to the ticket. With this patch, RPM update will report errors to user: # rpm -Uvh --force ~/freeipa-master/dist/rpms/freeipa-* Preparing... ########################################### [100%] 1:freeipa-python ########################################### [ 14%] 2:freeipa-client ########################################### [ 29%] 3:freeipa-admintools ########################################### [ 43%] 4:freeipa-server ########################################### [ 57%] ERROR: Cannot update connections in /etc/named.conf: [Errno 13] Permission denied: '/etc/named.conf' 5:freeipa-server-selinux ########################################### [ 71%] 6:freeipa-server-trust-ad########################################### [ 86%] 7:freeipa-debuginfo ########################################### [100%] Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-323-report-ipa-upgradeconfig-errors-during-rpm-upgrade.patch Type: text/x-patch Size: 2530 bytes Desc: not available URL: From sbose at redhat.com Wed Oct 17 11:29:44 2012 From: sbose at redhat.com (Sumit Bose) Date: Wed, 17 Oct 2012 13:29:44 +0200 Subject: [Freeipa-devel] [PATCH] support AES for cross-realm TGTs In-Reply-To: <1557234042.2399022.1348699000344.JavaMail.root@redhat.com> References: <26889845.2398987.1348698998522.JavaMail.root@redhat.com> <1557234042.2399022.1348699000344.JavaMail.root@redhat.com> Message-ID: <20121017112944.GU23959@localhost.localdomain> On Wed, Sep 26, 2012 at 06:36:40PM -0400, Simo Sorce wrote: > > This patch allows Windows to send us TGTs using AES. > > Simo. > > -- > Simo Sorce * Red Hat, Inc. * New York (sorry for the long delay) ACK, patch is working as expected with w2k8r2. bye, Sumit From mkosek at redhat.com Wed Oct 17 11:55:37 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 17 Oct 2012 13:55:37 +0200 Subject: [Freeipa-devel] [PATCH] support AES for cross-realm TGTs In-Reply-To: <20121017112944.GU23959@localhost.localdomain> References: <26889845.2398987.1348698998522.JavaMail.root@redhat.com> <1557234042.2399022.1348699000344.JavaMail.root@redhat.com> <20121017112944.GU23959@localhost.localdomain> Message-ID: <507E9CB9.8020902@redhat.com> On 10/17/2012 01:29 PM, Sumit Bose wrote: > On Wed, Sep 26, 2012 at 06:36:40PM -0400, Simo Sorce wrote: >> >> This patch allows Windows to send us TGTs using AES. >> >> Simo. >> >> -- >> Simo Sorce * Red Hat, Inc. * New York > > (sorry for the long delay) > > ACK, patch is working as expected with w2k8r2. > > bye, > Sumit Pushed to master, ipa-3-0. Martin From abokovoy at redhat.com Wed Oct 17 12:14:41 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 17 Oct 2012 15:14:41 +0300 Subject: [Freeipa-devel] [PATCH] Fix various issues found by Coverity In-Reply-To: <20121002092846.GS6816@localhost.localdomain> References: <20121002092846.GS6816@localhost.localdomain> Message-ID: <20121017121441.GU17454@redhat.com> On Tue, 02 Oct 2012, Sumit Bose wrote: >Hi, > >this patch fixes a couple of resource leaks and unchecked return and an >uninitialised value found by Coverity. ACK. -- / Alexander Bokovoy From abokovoy at redhat.com Wed Oct 17 12:15:32 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 17 Oct 2012 15:15:32 +0300 Subject: [Freeipa-devel] [PATCH] 87 extdom: handle INP_POSIX_UID and INP_POSIX_GID requests In-Reply-To: <20121011102620.GB23959@localhost.localdomain> References: <20121011102620.GB23959@localhost.localdomain> Message-ID: <20121017121532.GV17454@redhat.com> On Thu, 11 Oct 2012, Sumit Bose wrote: >Hi, > >I found this issue while working on a related sssd bug >https://fedorahosted.org/sssd/ticket/1561 . > >This patch allows the clients to send a request map a UID or GID for a >trusted user to the name of the user. To achieve this the Posix ID is >mapped to the corresponding SID and then the SID is looked up. > >FreeIPA ticket is https://fedorahosted.org/freeipa/ticket/3166 . ACK. -- / Alexander Bokovoy From mkosek at redhat.com Wed Oct 17 12:33:33 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 17 Oct 2012 14:33:33 +0200 Subject: [Freeipa-devel] [PATCH] Fix various issues found by Coverity In-Reply-To: <20121017121441.GU17454@redhat.com> References: <20121002092846.GS6816@localhost.localdomain> <20121017121441.GU17454@redhat.com> Message-ID: <507EA59D.5040800@redhat.com> On 10/17/2012 02:14 PM, Alexander Bokovoy wrote: > On Tue, 02 Oct 2012, Sumit Bose wrote: >> Hi, >> >> this patch fixes a couple of resource leaks and unchecked return and an >> uninitialised value found by Coverity. > ACK. > Pushed to master, ipa-3-0. Martin From sbose at redhat.com Wed Oct 17 12:34:45 2012 From: sbose at redhat.com (Sumit Bose) Date: Wed, 17 Oct 2012 14:34:45 +0200 Subject: [Freeipa-devel] [PATCH 0019] Forbid overlapping primary and secondary rid ranges In-Reply-To: <507E8FA8.3070501@redhat.com> References: <507D5270.20904@redhat.com> <20121017091451.GR23959@localhost.localdomain> <507E8FA8.3070501@redhat.com> Message-ID: <20121017123445.GW23959@localhost.localdomain> On Wed, Oct 17, 2012 at 12:59:52PM +0200, Tomas Babej wrote: > On 10/17/2012 11:14 AM, Sumit Bose wrote: > >On Tue, Oct 16, 2012 at 02:26:24PM +0200, Tomas Babej wrote: > >>Hi, > >> > >>commands ipa idrange-add / idrange-mod no longer allows the user > >>to enter primary or secondary rid range such that has non-zero > >>intersection with primary or secondary rid range of another > >>existing id range, as this could cause collision. > >> > >>Unit tests added to test_range_plugin.py > >> > >>https://fedorahosted.org/freeipa/ticket/3086 > >> > >>Tomas > >Thank you for the patch, comments are in-line. > > > >bye, > >Sumit > > .... > Thank you for your suggestions. New version of the patch attached. > > Tomas Thank you for addressing my comments. I just realized that the check is too strict. The ranges of the Posix IDs [base_id - base_id+id_range_size) may not overlap for any existing range because those IDs belong to the single Posix ID namespace of the IPA domain. I.e each user, local or from a trusted domain, must have a unique Posix ID. The RID ranges [base_rid, base_rid+id_range_size) and [secondary_base_rid, secondary_base_rid+id_range_size) may not overlap with RID ranges from the same domain. So the RID ranges for the local domain may not overlap and the RID ranges for any specific trusted domain may not overlap. It is allowed that there is a range form the local domain may have base_rid=1000 and a range from a trusted domain as well. This is ok because the RID is only part of the identifier, each domain has a unique domain SID which is used together with the RID to identify e.g. a user. I would suggest to look for the ipaNTTrustedDomainSID attribute in slapi_entry_to_range_info() too and add it to struct range_info. In ranges_overlap() you can then check the Posix ID range for all ranges but do the RID checks only when the domain identifiers are either both NULL (local IPA domain) or are the same strings. Sorry for not seeing this earlier. bye, Sumit From tbabej at redhat.com Wed Oct 17 13:29:11 2012 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 17 Oct 2012 15:29:11 +0200 Subject: [Freeipa-devel] [PATCH 0019] Forbid overlapping primary and secondary rid ranges In-Reply-To: <20121017123445.GW23959@localhost.localdomain> References: <507D5270.20904@redhat.com> <20121017091451.GR23959@localhost.localdomain> <507E8FA8.3070501@redhat.com> <20121017123445.GW23959@localhost.localdomain> Message-ID: <507EB2A7.40505@redhat.com> On 10/17/2012 02:34 PM, Sumit Bose wrote: > On Wed, Oct 17, 2012 at 12:59:52PM +0200, Tomas Babej wrote: >> On 10/17/2012 11:14 AM, Sumit Bose wrote: >>> On Tue, Oct 16, 2012 at 02:26:24PM +0200, Tomas Babej wrote: >>>> Hi, >>>> >>>> commands ipa idrange-add / idrange-mod no longer allows the user >>>> to enter primary or secondary rid range such that has non-zero >>>> intersection with primary or secondary rid range of another >>>> existing id range, as this could cause collision. >>>> >>>> Unit tests added to test_range_plugin.py >>>> >>>> https://fedorahosted.org/freeipa/ticket/3086 >>>> >>>> Tomas >>> Thank you for the patch, comments are in-line. >>> >>> bye, >>> Sumit >>> > .... >> Thank you for your suggestions. New version of the patch attached. >> >> Tomas > Thank you for addressing my comments. I just realized that the check is > too strict. > > The ranges of the Posix IDs [base_id - base_id+id_range_size) may not > overlap for any existing range because those IDs belong to the single > Posix ID namespace of the IPA domain. I.e each user, local or from a > trusted domain, must have a unique Posix ID. > > The RID ranges [base_rid, base_rid+id_range_size) and > [secondary_base_rid, secondary_base_rid+id_range_size) may not overlap > with RID ranges from the same domain. So the RID ranges for the local > domain may not overlap and the RID ranges for any specific trusted > domain may not overlap. It is allowed that there is a range form the > local domain may have base_rid=1000 and a range from a trusted domain as > well. This is ok because the RID is only part of the identifier, each > domain has a unique domain SID which is used together with the RID to > identify e.g. a user. > > I would suggest to look for the ipaNTTrustedDomainSID attribute in > slapi_entry_to_range_info() too and add it to struct range_info. In > ranges_overlap() you can then check the Posix ID range for all ranges > but do the RID checks only when the domain identifiers are either both > NULL (local IPA domain) or are the same strings. > > Sorry for not seeing this earlier. > > bye, > Sumit Thanks for catching this issue. It is solved in the newest revision of the patch. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0019-3-Forbid-overlapping-primary-and-secondary-rid-ranges.patch Type: text/x-patch Size: 14509 bytes Desc: not available URL: From pviktori at redhat.com Wed Oct 17 13:43:13 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 17 Oct 2012 15:43:13 +0200 Subject: [Freeipa-devel] [PATCH] convert the base platform modules into packages In-Reply-To: <505C804B.9010506@ubuntu.com> References: <505C804B.9010506@ubuntu.com> Message-ID: <507EB5F1.1040903@redhat.com> On 09/21/2012 04:57 PM, Timo Aaltonen wrote: > Ok, so this is the first step before we can start to rewrite bits from > ipaserver/install to make them support other distros. There are no real > functional changes yet. > > had some dependency issues installing the resulting rpm's, so didn't > test the install scripts but they should work :) > > Hello, I recommend giving the -M flag to git format-patch, so it's easier to see changes in the patch. Your split of the fedora16 code into two modules is unfortunate: each tries to import the other one, and one is the other's parent. This would need special care to get working correctly. The best option here would probably be to put restore_context & check_selinux_status into a separate submodule, so you don't need to import fedora16 from services. Furthermore, in fedora16/__init__.py, you have: from ipapython.platform.fedora16.service import * This imports everything from that module, including e.g. "redhat" or "os". Please avoid star imports. List all the imported names explicitly, or import the module and then use qualified names. Other than that, after a trivial rebase the patch seems to work fine on Fedora. Thanks! -- Petr? From simo at redhat.com Wed Oct 17 13:58:36 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 17 Oct 2012 09:58:36 -0400 Subject: [Freeipa-devel] Hide private symbols in the bind-dyndb-ldap In-Reply-To: <20121017110414.GA1944@redhat.com> References: <20121017110414.GA1944@redhat.com> Message-ID: <1350482316.30610.18.camel@willson.li.ssimo.org> On Wed, 2012-10-17 at 13:04 +0200, Adam Tkac wrote: > Hello, > > attached patch hides all symbols except dynamic_driver_{init,destroy}. Feedback > is appreciated. Any reason not to use a simple export file ? Anyway strong ACK, keeping private symbols private is good hygiene. Simo. -- Simo Sorce * Red Hat, Inc * New York From atkac at redhat.com Wed Oct 17 15:06:11 2012 From: atkac at redhat.com (Adam Tkac) Date: Wed, 17 Oct 2012 17:06:11 +0200 Subject: [Freeipa-devel] Hide private symbols in the bind-dyndb-ldap In-Reply-To: <1350482316.30610.18.camel@willson.li.ssimo.org> References: <20121017110414.GA1944@redhat.com> <1350482316.30610.18.camel@willson.li.ssimo.org> Message-ID: <20121017150607.GA4388@redhat.com> On Wed, Oct 17, 2012 at 09:58:36AM -0400, Simo Sorce wrote: > On Wed, 2012-10-17 at 13:04 +0200, Adam Tkac wrote: > > Hello, > > > > attached patch hides all symbols except dynamic_driver_{init,destroy}. Feedback > > is appreciated. > > Any reason not to use a simple export file ? This is also possible solution. However if I understand GNU build chain correctly, using export file only affects linker and doesn't allow compiler to perform more aggressive optimisations (i.e. inline hidden functions etc), does it? > Anyway strong ACK, keeping private symbols private is good hygiene. Thanks, pushed to master. Regards, Adam -- Adam Tkac, Red Hat, Inc. From tbabej at redhat.com Wed Oct 17 15:10:05 2012 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 17 Oct 2012 17:10:05 +0200 Subject: [Freeipa-devel] [PATCH 0020] Refactoring of default.conf man page Message-ID: <507ECA4D.60207@redhat.com> Hi, Description for the 'server' and 'wait_for_attr' option has been added. Option 'server' has been marked as deprecated, as it is not used anywhere in IPA code. All the options have been sorted lexicographically. Please provide feedback for added descriptions: +.TP +.B server +Specifies the IPA Server hostname. This option is deprecated. +.TP +.B wait_for_attr +Debug option. Waits for asynchronous execution of 389-ds postoperation plugins before returning data to the client, therefore data added by postoperation plugins is included in the result. Increases execution time. The rest of the patch is just sorting options lexicographically. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0020-Refactoring-of-default.conf-man-page.patch Type: text/x-patch Size: 8820 bytes Desc: not available URL: From simo at redhat.com Wed Oct 17 15:16:58 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 17 Oct 2012 11:16:58 -0400 Subject: [Freeipa-devel] Hide private symbols in the bind-dyndb-ldap In-Reply-To: <20121017150607.GA4388@redhat.com> References: <20121017110414.GA1944@redhat.com> <1350482316.30610.18.camel@willson.li.ssimo.org> <20121017150607.GA4388@redhat.com> Message-ID: <1350487018.30610.41.camel@willson.li.ssimo.org> On Wed, 2012-10-17 at 17:06 +0200, Adam Tkac wrote: > On Wed, Oct 17, 2012 at 09:58:36AM -0400, Simo Sorce wrote: > > On Wed, 2012-10-17 at 13:04 +0200, Adam Tkac wrote: > > > Hello, > > > > > > attached patch hides all symbols except dynamic_driver_{init,destroy}. Feedback > > > is appreciated. > > > > Any reason not to use a simple export file ? > > This is also possible solution. However if I understand GNU build chain > correctly, using export file only affects linker and doesn't allow compiler to > perform more aggressive optimisations (i.e. inline hidden functions etc), does > it? It's linker only indeed, good point, I'll keep that in mind. > > Anyway strong ACK, keeping private symbols private is good hygiene. > > Thanks, pushed to master. > > Regards, Adam > -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Wed Oct 17 15:22:10 2012 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 17 Oct 2012 17:22:10 +0200 Subject: [Freeipa-devel] Hide private symbols in the bind-dyndb-ldap In-Reply-To: <1350487018.30610.41.camel@willson.li.ssimo.org> References: <20121017110414.GA1944@redhat.com> <1350482316.30610.18.camel@willson.li.ssimo.org> <20121017150607.GA4388@redhat.com> <1350487018.30610.41.camel@willson.li.ssimo.org> Message-ID: <507ECD22.1070408@redhat.com> On 10/17/2012 05:16 PM, Simo Sorce wrote: > On Wed, 2012-10-17 at 17:06 +0200, Adam Tkac wrote: >> On Wed, Oct 17, 2012 at 09:58:36AM -0400, Simo Sorce wrote: >>> On Wed, 2012-10-17 at 13:04 +0200, Adam Tkac wrote: >>>> Hello, >>>> >>>> attached patch hides all symbols except dynamic_driver_{init,destroy}. Feedback >>>> is appreciated. I'm perfectly okay with that, but I haven't time for exploring it deeply today. Petr^2 Spacek >>> >>> Any reason not to use a simple export file ? >> >> This is also possible solution. However if I understand GNU build chain >> correctly, using export file only affects linker and doesn't allow compiler to >> perform more aggressive optimisations (i.e. inline hidden functions etc), does >> it? > > It's linker only indeed, good point, I'll keep that in mind. > >>> Anyway strong ACK, keeping private symbols private is good hygiene. >> >> Thanks, pushed to master. >> >> Regards, Adam From rcritten at redhat.com Wed Oct 17 15:56:26 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 17 Oct 2012 11:56:26 -0400 Subject: [Freeipa-devel] [PATCH] 1064 Improve error messages during ipa-replica-manage Message-ID: <507ED52A.5050206@redhat.com> Make some of the errors in ipa-replica-manage clearer. See ticket for more reproduction details. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1064-replica.patch Type: text/x-diff Size: 3831 bytes Desc: not available URL: From sbose at redhat.com Wed Oct 17 18:12:49 2012 From: sbose at redhat.com (Sumit Bose) Date: Wed, 17 Oct 2012 20:12:49 +0200 Subject: [Freeipa-devel] [PATCH 0019] Forbid overlapping primary and secondary rid ranges In-Reply-To: <507EB2A7.40505@redhat.com> References: <507D5270.20904@redhat.com> <20121017091451.GR23959@localhost.localdomain> <507E8FA8.3070501@redhat.com> <20121017123445.GW23959@localhost.localdomain> <507EB2A7.40505@redhat.com> Message-ID: <20121017181249.GB23959@localhost.localdomain> On Wed, Oct 17, 2012 at 03:29:11PM +0200, Tomas Babej wrote: > On 10/17/2012 02:34 PM, Sumit Bose wrote: > >On Wed, Oct 17, 2012 at 12:59:52PM +0200, Tomas Babej wrote: > >>On 10/17/2012 11:14 AM, Sumit Bose wrote: > >>>On Tue, Oct 16, 2012 at 02:26:24PM +0200, Tomas Babej wrote: > >>>>Hi, > >>>> > >>>>commands ipa idrange-add / idrange-mod no longer allows the user > >>>>to enter primary or secondary rid range such that has non-zero > >>>>intersection with primary or secondary rid range of another > >>>>existing id range, as this could cause collision. > >>>> > >>>>Unit tests added to test_range_plugin.py > >>>> > >>>>https://fedorahosted.org/freeipa/ticket/3086 > >>>> > >>>>Tomas > >>>Thank you for the patch, comments are in-line. > >>> > >>>bye, > >>>Sumit > >>> > >.... > >>Thank you for your suggestions. New version of the patch attached. > >> > >>Tomas > >Thank you for addressing my comments. I just realized that the check is > >too strict. > > > >The ranges of the Posix IDs [base_id - base_id+id_range_size) may not > >overlap for any existing range because those IDs belong to the single > >Posix ID namespace of the IPA domain. I.e each user, local or from a > >trusted domain, must have a unique Posix ID. > > > >The RID ranges [base_rid, base_rid+id_range_size) and > >[secondary_base_rid, secondary_base_rid+id_range_size) may not overlap > >with RID ranges from the same domain. So the RID ranges for the local > >domain may not overlap and the RID ranges for any specific trusted > >domain may not overlap. It is allowed that there is a range form the > >local domain may have base_rid=1000 and a range from a trusted domain as > >well. This is ok because the RID is only part of the identifier, each > >domain has a unique domain SID which is used together with the RID to > >identify e.g. a user. > > > >I would suggest to look for the ipaNTTrustedDomainSID attribute in > >slapi_entry_to_range_info() too and add it to struct range_info. In > >ranges_overlap() you can then check the Posix ID range for all ranges > >but do the RID checks only when the domain identifiers are either both > >NULL (local IPA domain) or are the same strings. > > > >Sorry for not seeing this earlier. > > > >bye, > >Sumit > > Thanks for catching this issue. It is solved in the newest revision > of the patch. > > Tomas sorry, found another one ... ... > +static int ranges_overlap(struct range_info *r1, struct range_info *r2) > +{ > + if (r1->name != NULL && r2->name != NULL && > + strcasecmp(r1->name, r2->name) == 0) { > + return 0; > + } > + > + /* check if base range overlaps with existing base range */ > + if (intervals_overlap(r1->base_id, r2->base_id, > + r1->id_range_size, r2->id_range_size)){ > + return 1; > + } > + > + /* if both base_rid and secondary_base_rid = 0, the rid range is not set */ > + bool rid_ranges_set = (r1->base_rid != 0 || r1->secondary_base_rid != 0) && > + (r2->base_rid != 0 || r2->secondary_base_rid != 0); > + > + bool ranges_from_same_domain = > + (r1->domain_id == NULL && r2->domain_id == NULL) || > + (strcasecmp(r1->domain_id, r2->domain_id) == 0); > + you have to check that both domain_id are not NULL before calling strcasecmp. bye, Sumit From jdennis at redhat.com Wed Oct 17 18:23:34 2012 From: jdennis at redhat.com (John Dennis) Date: Wed, 17 Oct 2012 14:23:34 -0400 Subject: [Freeipa-devel] [PATCH 75] log dogtag errors In-Reply-To: <5077D64C.1080701@redhat.com> References: <201204201807.q3KI7VuR019115@int-mx11.intmail.prod.int.phx2.redhat.com> <4F9A5C8D.9000004@redhat.com> <4F9BF5BF.5030302@redhat.com> <5076F98E.7020901@redhat.com> <5077D64C.1080701@redhat.com> Message-ID: <507EF7A6.6040604@redhat.com> On 10/12/2012 04:35 AM, Petr Viktorin wrote: > On 10/11/2012 06:53 PM, John Dennis wrote: >> On 04/28/2012 09:50 AM, John Dennis wrote: >>> On 04/27/2012 04:45 AM, Petr Viktorin wrote: >>>> On 04/20/2012 08:07 PM, John Dennis wrote: >>>>> Ticket #2622 >>>>> >>>>> If we get an error from dogtag we always did raise a >>>>> CertificateOperationError exception with a message describing the >>>>> problem. Unfortuanately that error message did not go into the log, >>>>> just sent back to the caller. The fix is to format the error message >>>>> and send the same message to both the log and use it to initialize the >>>>> CertificateOperationError exception. >>>>> >>>> >>>> The patch contains five hunks with almost exactly the same code, >>>> applying the same changes in each case. >>>> Wouldn't it make sense to move the _sslget call, parsing, and error >>>> handling to a common method? >>>> >>> >>> Yes it would and ordinarily I would have taken that approach. However on >>> IRC (or phone?) with Rob we decided not to perturb the code too much for >>> this particular issue because we intend to refactor the code later. This >>> was one of the last patches destined for 2.2 which is why we took the >>> more conservative approach. >>> >> >> I went back and looked at this. It's not practical to collapse >> everything into a common subroutine unless you paramaterize the heck out >> of a common subroutine. That's because all the patched locations have >> subtly different things going on, different parameters to sslget >> followed by different result parsing and handling. In retrospect I think >> it's clearer to keep things separate rather than one subroutine that >> needs a lot of parameters and/or convoluted logic to handle each unique >> case. > > I don't agree that it's clearer, but I guess that's debatable. > >> Part of the problem is the dogtag interface. Every command has the >> potential to behave differently making it difficult to work with. I >> wrote this code originally and got it reduced to as many common parts as >> I could. At some point soon we'll be switching to a new dogtag REST >> interface which hopefully will allow for greater commonality due to >> interface consistency. >> >> In summary: I still stand by the original patch. >> > > However, I see no reason to not use a method such as: > > def raise_certop_error(self, method_name, error=None, detail=None): > """Log and raise a CertificateOperationError > > :param method_name: Name of the method in which the error occured > :param error: Error string. If None, "Unable to communicate with > CMS" is used. > :param detail: Detailed or low-level information. Will be put in > parentheses. > """ > > to at least get rid of the repetition this patch is adding - almost the > same format+log+raise sequence is used twice in each of the five hunks. > Added a utility function as suggested. Revised patch attached. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jdennis-0075-1-log-dogtag-errors.patch Type: text/x-patch Size: 7717 bytes Desc: not available URL: From rcritten at redhat.com Wed Oct 17 22:04:34 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 17 Oct 2012 18:04:34 -0400 Subject: [Freeipa-devel] Unit tests failing on F18 In-Reply-To: <50783536.8020007@redhat.com> References: <50783536.8020007@redhat.com> Message-ID: <507F2B72.3050802@redhat.com> Martin Kosek wrote: > Hello, > > I was investigating global unit test failure on Fedora 18 for most of today, I > would like to share results I found so far. > > Unit test and its related scripts on F18 now reports NSS BUSY exception, just > like this one: > > # ./make-testcert > Traceback (most recent call last): > File "./make-testcert", line 134, in > sys.exit(makecert(reqdir)) > File "./make-testcert", line 111, in makecert > add=True) > File "./make-testcert", line 68, in run > result = self.execute(method, *args, **options) > File "/root/freeipa-master2/ipalib/backend.py", line 146, in execute > raise error #pylint: disable=E0702 > ipalib.errors.NetworkError: cannot connect to > 'http://vm-042.idm.lab.bos.redhat.com/ipa/session/xml': [Errno -8053] > (SEC_ERROR_BUSY) NSS could not shutdown. Objects are still in use. > > Something In F18 must have changed, this worked before... But leaked > NSSConnection objects without proper close() now ends with the exception above. > > In case of make-testcert script, the exception is raised because the script > does the following procedure: > > 1) connect, do one command > 2) disconnect > 3) connect, do second command > > However, during disconnect, NSSConnection is leaked which makes NSS very > uncomfortable during second connection atempt (and nss_shutdown()). I managed > to fix this issue with attached patch. ./make-testcert or "./make-test > tests/test_xmlrpc/test_group_plugin.py" works fine now. > > But global "./make-test" still fails, I think there is some remaining > NSSConnection leak, I suspect there is something wrong with how we use our > context (threading.local object). It looses a connection or some other thread > invoked in ldap2 module may be kicking in, here is my debug output: > > CONTEXT[xmlclient] = > > Test a simple LDAP bind using ldap2 ... SKIP: No directory manager password in > /root/.ipa/.dmpw > Test the `ipaserver.rpcserver.jsonserver.unmarshal` method. ... ok > tests.test_ipaserver.test_rpcserver.test_session.test_mount ... CONTEXT > 150714476: GET languages > > CONTEXT[xmlclient] = None > > The connection is in the context, but then something happens and it is gone. > Then, unit tests try to connect again and NSS fails. > > I would be really glad if somebody with a knowledge of NSS or how threads in > Python/IPA work could give me some advice... > > Thanks! > Martin I built upon your patch and have something that seems to work at least somewhat. I'm getting some unexpected test failures when running the entire suite but no NSS shutdown errors. I haven't had a chance to really investigate everything yet, sending this out as a work-in-progress in case you want to take a look. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: candidate.patch Type: text/x-diff Size: 3261 bytes Desc: not available URL: From rmeggins at redhat.com Wed Oct 17 23:39:17 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 17 Oct 2012 17:39:17 -0600 Subject: [Freeipa-devel] using 389-ds-base with betxn plugins enabled Message-ID: <507F41A5.5030508@redhat.com> I'm testing with f18, freeipa-server 3.0.0, 389-ds-base-1.3.0.a1, with betxn manually enabled in all plugins in 389. I did an ipa-server-install. I have ipa user-add --all --raw working - it returns the mep and memberof attributes immediately. I had to do something like this: diff --git a/ipalib/plugins/user.py b/ipalib/plugins/user.py index 5d667dc..5a490bb 100644 --- a/ipalib/plugins/user.py +++ b/ipalib/plugins/user.py @@ -568,6 +568,11 @@ class user_add(LDAPCreate): newentry = wait_for_value(ldap, dn, 'objectclass', 'mepOriginEntry') entry_from_entry(entry_attrs, newentry) + if not self.api.env.wait_for_attr: + # have to update memberof, mep data in entry to return + (newdn, newentry) = ldap.get_entry(dn, ['*']) + entry_attrs.update(newentry) + if options.get('random', False): try: entry_attrs['randompassword'] = unicode(getattr(context, 'randompassword')) That is, after user_add.post_callback adds the user to the group, it needs to get the updated memberof attribute from the user entry, as well as the mep data. I think there are several other places in the code where wait_for_attr and wait_for_attr_memberof are used, that will have to change in a similar manner. I don't know if this patch is the best way to solve the problem - I suppose it would be better to update only the memberof and objectclass and mepmanagedentry attributes in entry_attrs, but I'm not sure how to do that. From tbabej at redhat.com Thu Oct 18 06:31:50 2012 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 18 Oct 2012 08:31:50 +0200 Subject: [Freeipa-devel] [PATCH 0019] Forbid overlapping primary and secondary rid ranges In-Reply-To: <20121017181249.GB23959@localhost.localdomain> References: <507D5270.20904@redhat.com> <20121017091451.GR23959@localhost.localdomain> <507E8FA8.3070501@redhat.com> <20121017123445.GW23959@localhost.localdomain> <507EB2A7.40505@redhat.com> <20121017181249.GB23959@localhost.localdomain> Message-ID: <507FA256.9040105@redhat.com> On 10/17/2012 08:12 PM, Sumit Bose wrote: > On Wed, Oct 17, 2012 at 03:29:11PM +0200, Tomas Babej wrote: >> On 10/17/2012 02:34 PM, Sumit Bose wrote: >>> On Wed, Oct 17, 2012 at 12:59:52PM +0200, Tomas Babej wrote: >>>> On 10/17/2012 11:14 AM, Sumit Bose wrote: >>>>> On Tue, Oct 16, 2012 at 02:26:24PM +0200, Tomas Babej wrote: >>>>>> Hi, >>>>>> >>>>>> commands ipa idrange-add / idrange-mod no longer allows the user >>>>>> to enter primary or secondary rid range such that has non-zero >>>>>> intersection with primary or secondary rid range of another >>>>>> existing id range, as this could cause collision. >>>>>> >>>>>> Unit tests added to test_range_plugin.py >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3086 >>>>>> >>>>>> Tomas >>>>> Thank you for the patch, comments are in-line. >>>>> >>>>> bye, >>>>> Sumit >>>>> >>> .... >>>> Thank you for your suggestions. New version of the patch attached. >>>> >>>> Tomas >>> Thank you for addressing my comments. I just realized that the check is >>> too strict. >>> >>> The ranges of the Posix IDs [base_id - base_id+id_range_size) may not >>> overlap for any existing range because those IDs belong to the single >>> Posix ID namespace of the IPA domain. I.e each user, local or from a >>> trusted domain, must have a unique Posix ID. >>> >>> The RID ranges [base_rid, base_rid+id_range_size) and >>> [secondary_base_rid, secondary_base_rid+id_range_size) may not overlap >>> with RID ranges from the same domain. So the RID ranges for the local >>> domain may not overlap and the RID ranges for any specific trusted >>> domain may not overlap. It is allowed that there is a range form the >>> local domain may have base_rid=1000 and a range from a trusted domain as >>> well. This is ok because the RID is only part of the identifier, each >>> domain has a unique domain SID which is used together with the RID to >>> identify e.g. a user. >>> >>> I would suggest to look for the ipaNTTrustedDomainSID attribute in >>> slapi_entry_to_range_info() too and add it to struct range_info. In >>> ranges_overlap() you can then check the Posix ID range for all ranges >>> but do the RID checks only when the domain identifiers are either both >>> NULL (local IPA domain) or are the same strings. >>> >>> Sorry for not seeing this earlier. >>> >>> bye, >>> Sumit >> Thanks for catching this issue. It is solved in the newest revision >> of the patch. >> >> Tomas > sorry, found another one ... > > ... >> +static int ranges_overlap(struct range_info *r1, struct range_info *r2) >> +{ >> + if (r1->name != NULL && r2->name != NULL && >> + strcasecmp(r1->name, r2->name) == 0) { >> + return 0; >> + } >> + >> + /* check if base range overlaps with existing base range */ >> + if (intervals_overlap(r1->base_id, r2->base_id, >> + r1->id_range_size, r2->id_range_size)){ >> + return 1; >> + } >> + >> + /* if both base_rid and secondary_base_rid = 0, the rid range is not set */ >> + bool rid_ranges_set = (r1->base_rid != 0 || r1->secondary_base_rid != 0) && >> + (r2->base_rid != 0 || r2->secondary_base_rid != 0); >> + >> + bool ranges_from_same_domain = >> + (r1->domain_id == NULL && r2->domain_id == NULL) || >> + (strcasecmp(r1->domain_id, r2->domain_id) == 0); >> + > you have to check that both domain_id are not NULL before calling > strcasecmp. > > bye, > Sumit Null pointer check added. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0019-4-Forbid-overlapping-primary-and-secondary-rid-ranges.patch Type: text/x-patch Size: 14570 bytes Desc: not available URL: From mkosek at redhat.com Thu Oct 18 07:46:20 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 18 Oct 2012 09:46:20 +0200 Subject: [Freeipa-devel] Unit tests failing on F18 In-Reply-To: <507F2B72.3050802@redhat.com> References: <50783536.8020007@redhat.com> <507F2B72.3050802@redhat.com> Message-ID: <507FB3CC.5080303@redhat.com> On 10/18/2012 12:04 AM, Rob Crittenden wrote: > Martin Kosek wrote: >> Hello, >> >> I was investigating global unit test failure on Fedora 18 for most of today, I >> would like to share results I found so far. >> >> Unit test and its related scripts on F18 now reports NSS BUSY exception, just >> like this one: >> >> # ./make-testcert >> Traceback (most recent call last): >> File "./make-testcert", line 134, in >> sys.exit(makecert(reqdir)) >> File "./make-testcert", line 111, in makecert >> add=True) >> File "./make-testcert", line 68, in run >> result = self.execute(method, *args, **options) >> File "/root/freeipa-master2/ipalib/backend.py", line 146, in execute >> raise error #pylint: disable=E0702 >> ipalib.errors.NetworkError: cannot connect to >> 'http://vm-042.idm.lab.bos.redhat.com/ipa/session/xml': [Errno -8053] >> (SEC_ERROR_BUSY) NSS could not shutdown. Objects are still in use. >> >> Something In F18 must have changed, this worked before... But leaked >> NSSConnection objects without proper close() now ends with the exception above. >> >> In case of make-testcert script, the exception is raised because the script >> does the following procedure: >> >> 1) connect, do one command >> 2) disconnect >> 3) connect, do second command >> >> However, during disconnect, NSSConnection is leaked which makes NSS very >> uncomfortable during second connection atempt (and nss_shutdown()). I managed >> to fix this issue with attached patch. ./make-testcert or "./make-test >> tests/test_xmlrpc/test_group_plugin.py" works fine now. >> >> But global "./make-test" still fails, I think there is some remaining >> NSSConnection leak, I suspect there is something wrong with how we use our >> context (threading.local object). It looses a connection or some other thread >> invoked in ldap2 module may be kicking in, here is my debug output: >> >> CONTEXT[xmlclient] = >> >> Test a simple LDAP bind using ldap2 ... SKIP: No directory manager password in >> /root/.ipa/.dmpw >> Test the `ipaserver.rpcserver.jsonserver.unmarshal` method. ... ok >> tests.test_ipaserver.test_rpcserver.test_session.test_mount ... CONTEXT >> 150714476: GET languages >> >> CONTEXT[xmlclient] = None >> >> The connection is in the context, but then something happens and it is gone. >> Then, unit tests try to connect again and NSS fails. >> >> I would be really glad if somebody with a knowledge of NSS or how threads in >> Python/IPA work could give me some advice... >> >> Thanks! >> Martin > > I built upon your patch and have something that seems to work at least > somewhat. I'm getting some unexpected test failures when running the entire > suite but no NSS shutdown errors. I haven't had a chance to really investigate > everything yet, sending this out as a work-in-progress in case you want to take > a look. > > rob > Yeah, this is great! I tested a fresh build+install on Fedora 18 with your patch and all tests succeeded. So as for F18, I am inclined to ACK the patch as is. I am just not sure that this will work on platforms with Python version < 2.7, xmlrpclib is different there. Martin From mkosek at redhat.com Thu Oct 18 08:59:37 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 18 Oct 2012 10:59:37 +0200 Subject: [Freeipa-devel] [PATCH] 87 extdom: handle INP_POSIX_UID and INP_POSIX_GID requests In-Reply-To: <20121017121532.GV17454@redhat.com> References: <20121011102620.GB23959@localhost.localdomain> <20121017121532.GV17454@redhat.com> Message-ID: <507FC4F9.3040403@redhat.com> On 10/17/2012 02:15 PM, Alexander Bokovoy wrote: > On Thu, 11 Oct 2012, Sumit Bose wrote: >> Hi, >> >> I found this issue while working on a related sssd bug >> https://fedorahosted.org/sssd/ticket/1561 . >> >> This patch allows the clients to send a request map a UID or GID for a >> trusted user to the name of the user. To achieve this the Posix ID is >> mapped to the corresponding SID and then the SID is looked up. >> >> FreeIPA ticket is https://fedorahosted.org/freeipa/ticket/3166 . > ACK. Pushed to master, ipa-3-0. Martin From pviktori at redhat.com Thu Oct 18 09:06:01 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 18 Oct 2012 11:06:01 +0200 Subject: [Freeipa-devel] [PATCH 75] log dogtag errors In-Reply-To: <507EF7A6.6040604@redhat.com> References: <201204201807.q3KI7VuR019115@int-mx11.intmail.prod.int.phx2.redhat.com> <4F9A5C8D.9000004@redhat.com> <4F9BF5BF.5030302@redhat.com> <5076F98E.7020901@redhat.com> <5077D64C.1080701@redhat.com> <507EF7A6.6040604@redhat.com> Message-ID: <507FC679.1070203@redhat.com> On 10/17/2012 08:23 PM, John Dennis wrote: > On 10/12/2012 04:35 AM, Petr Viktorin wrote: >> On 10/11/2012 06:53 PM, John Dennis wrote: >>> On 04/28/2012 09:50 AM, John Dennis wrote: >>>> On 04/27/2012 04:45 AM, Petr Viktorin wrote: >>>>> On 04/20/2012 08:07 PM, John Dennis wrote: >>>>>> Ticket #2622 >>>>>> >>>>>> If we get an error from dogtag we always did raise a >>>>>> CertificateOperationError exception with a message describing the >>>>>> problem. Unfortuanately that error message did not go into the log, >>>>>> just sent back to the caller. The fix is to format the error message >>>>>> and send the same message to both the log and use it to initialize >>>>>> the >>>>>> CertificateOperationError exception. >>>>>> >>>>> >>>>> The patch contains five hunks with almost exactly the same code, >>>>> applying the same changes in each case. >>>>> Wouldn't it make sense to move the _sslget call, parsing, and error >>>>> handling to a common method? >>>>> >>>> >>>> Yes it would and ordinarily I would have taken that approach. >>>> However on >>>> IRC (or phone?) with Rob we decided not to perturb the code too much >>>> for >>>> this particular issue because we intend to refactor the code later. >>>> This >>>> was one of the last patches destined for 2.2 which is why we took the >>>> more conservative approach. >>>> >>> >>> I went back and looked at this. It's not practical to collapse >>> everything into a common subroutine unless you paramaterize the heck out >>> of a common subroutine. That's because all the patched locations have >>> subtly different things going on, different parameters to sslget >>> followed by different result parsing and handling. In retrospect I think >>> it's clearer to keep things separate rather than one subroutine that >>> needs a lot of parameters and/or convoluted logic to handle each unique >>> case. >> >> I don't agree that it's clearer, but I guess that's debatable. >> >>> Part of the problem is the dogtag interface. Every command has the >>> potential to behave differently making it difficult to work with. I >>> wrote this code originally and got it reduced to as many common parts as >>> I could. At some point soon we'll be switching to a new dogtag REST >>> interface which hopefully will allow for greater commonality due to >>> interface consistency. >>> >>> In summary: I still stand by the original patch. >>> >> >> However, I see no reason to not use a method such as: >> >> def raise_certop_error(self, method_name, error=None, detail=None): >> """Log and raise a CertificateOperationError >> >> :param method_name: Name of the method in which the error occured >> :param error: Error string. If None, "Unable to communicate with >> CMS" is used. >> :param detail: Detailed or low-level information. Will be put in >> parentheses. >> """ >> >> to at least get rid of the repetition this patch is adding - almost the >> same format+log+raise sequence is used twice in each of the five hunks. >> > > Added a utility function as suggested. Revised patch attached. This looks much better. I found one more issue, though. > diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py > index baa41ad..66fef57 100644 > --- a/ipaserver/plugins/dogtag.py > +++ b/ipaserver/plugins/dogtag.py > @@ -1233,6 +1233,27 @@ class ra(rabase.rabase): > self.password = '' > super(ra, self).__init__() > > + def raise_certificate_operation_error(self, func_name, err_msg=None, detail=None): > + """ > + :param func_name: function name where error occurred > + > + :param err_msg: diagnostic error message, if not supplied it will be > + 'Unable to communicate with CMS' > + :param detail: extra information that will be appended to err_msg > + inside a parenthesis > + > + Raise a CertificateOperationError and log the error message. > + """ > + > + if err_msg is None: > + err_msg = _('Unable to communicate with CMS') > + > + if detail is not None: > + err_msg += ' (%s)' % detail Here I get TypeError: unsupported operand type(s) for +=: 'Gettext' and 'unicode'. Until our Gettext class supports addition (part of #3188), please use `err_msg = u'%s (%s)' % (err_msg, detail)` instead. -- Petr? From mkosek at redhat.com Thu Oct 18 09:27:08 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 18 Oct 2012 11:27:08 +0200 Subject: [Freeipa-devel] [PATCH 0018] Make service naming in ipa-server-install consistent In-Reply-To: <5076E1B1.70205@redhat.com> References: <50769EC4.10001@redhat.com> <5076A027.4090009@redhat.com> <5076E1B1.70205@redhat.com> Message-ID: <507FCB6C.1000807@redhat.com> On 10/11/2012 05:11 PM, Tomas Babej wrote: > On 10/11/2012 12:32 PM, Martin Kosek wrote: >> On 10/11/2012 12:26 PM, Tomas Babej wrote: >>> Hi, >>> >>> This patch forces more consistency into ipa-server-install output. All >>> descriptions of services that are not instances of >>> SimpleServiceInstance are now in the following format: >>> >>> () >>> >>> Furthermore, start_creation method has been modified to support >>> custom start and end messages. >>> >>> Sample output produced by this patch attached. >>> >>> https://fedorahosted.org/freeipa/ticket/3059 >>> >>> Tomas >>> >> Just based on reading the patch, this does not look right: >> >> - self.start_creation("Configuring certificate server", 210) >> + self.start_creation("Configuring directory server for the CA", >> + end_message="Done configuring directory server for the CA", >> + show_service_name=True, runtime=210) >> >> Martin >> > Thanks, glitch fixed. > > Tomas Ok, I managed to get the patch a proper review. I like the result, in the console, but I still not entirely satisfied with the patch, looks over-engineered to me + there is a lot of duplication with "Configuring %(service)s" and "Done configuring %(service)s" messages. These messages could be easily generated only based on name of a service (self.service_name, we got that) and a new "friendly service name" or description. If we add description this way: class KrbInstance(service.Service): def __init__(self, fstore=None): service.Service.__init__(self, "krb5kdc", description="Kerberos KDC") ... the start_creation could be very simple: ... self.start_creation(runtime=30) ... All messages could be simply generated by the Service class just based on self.service_name and self.description with having the same output as you do now. Martin From mkosek at redhat.com Thu Oct 18 12:22:00 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 18 Oct 2012 14:22:00 +0200 Subject: [Freeipa-devel] [PATCH] 324 Add fallback for httpd restarts Message-ID: <507FF468.7000801@redhat.com> Attaching a script I used to reproduce the issue on machine with sysV (RHEL 6.4 in my case). With the patch applied, httpd restarts correctly fallback-ed. If you think that the wait is not enough, I can add a more complicated procedure, like this one: wait_time = 5 retries = 3 for x in xrange(retries): try: sleep(wait_time) http.stop() sleep(wait_time) http.start() except CalledProcessError: wait_time = wait_time * 2 continue break ---- httpd init script on sysV based platforms cannot guarantee that two consecutive httpd service restarts succeed when run in a small time distance. Add fallback procedure that adds additional waiting time after such failed restart attempt, and then try to stop and start the service again. https://fedorahosted.org/freeipa/ticket/2965 -- Martin Kosek Senior Software Engineer - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-324-add-fallback-for-httpd-restarts.patch Type: text/x-patch Size: 3619 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: http-restart-test.py Type: text/x-python Size: 579 bytes Desc: not available URL: From rcritten at redhat.com Thu Oct 18 12:47:25 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 18 Oct 2012 08:47:25 -0400 Subject: [Freeipa-devel] [PATCH] 324 Add fallback for httpd restarts In-Reply-To: <507FF468.7000801@redhat.com> References: <507FF468.7000801@redhat.com> Message-ID: <507FFA5D.6040002@redhat.com> Martin Kosek wrote: > Attaching a script I used to reproduce the issue on machine with sysV (RHEL 6.4 > in my case). With the patch applied, httpd restarts correctly fallback-ed. > > If you think that the wait is not enough, I can add a more complicated > procedure, like this one: > > wait_time = 5 > retries = 3 > > for x in xrange(retries): > try: > sleep(wait_time) > http.stop() > sleep(wait_time) > http.start() > except CalledProcessError: > wait_time = wait_time * 2 > continue > break > > > ---- > > httpd init script on sysV based platforms cannot guarantee that two > consecutive httpd service restarts succeed when run in a small > time distance. > > Add fallback procedure that adds additional waiting time after such > failed restart attempt, and then try to stop and start the service > again. > > https://fedorahosted.org/freeipa/ticket/2965 Should we attempt to retrieve a file to ensure that the service is up? The ipa.crt would be a candidate for this. rob From mkosek at redhat.com Thu Oct 18 13:12:00 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 18 Oct 2012 15:12:00 +0200 Subject: [Freeipa-devel] [PATCH] 324 Add fallback for httpd restarts In-Reply-To: <507FFA5D.6040002@redhat.com> References: <507FF468.7000801@redhat.com> <507FFA5D.6040002@redhat.com> Message-ID: <50800020.6020602@redhat.com> On 10/18/2012 02:47 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> Attaching a script I used to reproduce the issue on machine with sysV (RHEL 6.4 >> in my case). With the patch applied, httpd restarts correctly fallback-ed. >> >> If you think that the wait is not enough, I can add a more complicated >> procedure, like this one: >> >> wait_time = 5 >> retries = 3 >> >> for x in xrange(retries): >> try: >> sleep(wait_time) >> http.stop() >> sleep(wait_time) >> http.start() >> except CalledProcessError: >> wait_time = wait_time * 2 >> continue >> break >> >> >> ---- >> >> httpd init script on sysV based platforms cannot guarantee that two >> consecutive httpd service restarts succeed when run in a small >> time distance. >> >> Add fallback procedure that adds additional waiting time after such >> failed restart attempt, and then try to stop and start the service >> again. >> >> https://fedorahosted.org/freeipa/ticket/2965 > > > Should we attempt to retrieve a file to ensure that the service is up? The > ipa.crt would be a candidate for this. > > rob Hm, this looks over-engineered from my POV. We already check that ports are open, right? Martin From rcritten at redhat.com Thu Oct 18 14:36:01 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 18 Oct 2012 10:36:01 -0400 Subject: [Freeipa-devel] [PATCH] 324 Add fallback for httpd restarts In-Reply-To: <50800020.6020602@redhat.com> References: <507FF468.7000801@redhat.com> <507FFA5D.6040002@redhat.com> <50800020.6020602@redhat.com> Message-ID: <508013D1.7030001@redhat.com> Martin Kosek wrote: > On 10/18/2012 02:47 PM, Rob Crittenden wrote: >> Martin Kosek wrote: >>> Attaching a script I used to reproduce the issue on machine with sysV (RHEL 6.4 >>> in my case). With the patch applied, httpd restarts correctly fallback-ed. >>> >>> If you think that the wait is not enough, I can add a more complicated >>> procedure, like this one: >>> >>> wait_time = 5 >>> retries = 3 >>> >>> for x in xrange(retries): >>> try: >>> sleep(wait_time) >>> http.stop() >>> sleep(wait_time) >>> http.start() >>> except CalledProcessError: >>> wait_time = wait_time * 2 >>> continue >>> break >>> >>> >>> ---- >>> >>> httpd init script on sysV based platforms cannot guarantee that two >>> consecutive httpd service restarts succeed when run in a small >>> time distance. >>> >>> Add fallback procedure that adds additional waiting time after such >>> failed restart attempt, and then try to stop and start the service >>> again. >>> >>> https://fedorahosted.org/freeipa/ticket/2965 >> >> >> Should we attempt to retrieve a file to ensure that the service is up? The >> ipa.crt would be a candidate for this. >> >> rob > > Hm, this looks over-engineered from my POV. We already check that ports are > open, right? Well, this is assuming that sysV is going to return an error when httpd doesn't start. It should at least call service status to make sure the service is operational. rob From mkosek at redhat.com Thu Oct 18 14:53:34 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 18 Oct 2012 16:53:34 +0200 Subject: [Freeipa-devel] [PATCH] 324 Add fallback for httpd restarts In-Reply-To: <508013D1.7030001@redhat.com> References: <507FF468.7000801@redhat.com> <507FFA5D.6040002@redhat.com> <50800020.6020602@redhat.com> <508013D1.7030001@redhat.com> Message-ID: <508017EE.4070809@redhat.com> On 10/18/2012 04:36 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> On 10/18/2012 02:47 PM, Rob Crittenden wrote: >>> Martin Kosek wrote: >>>> Attaching a script I used to reproduce the issue on machine with sysV (RHEL >>>> 6.4 >>>> in my case). With the patch applied, httpd restarts correctly fallback-ed. >>>> >>>> If you think that the wait is not enough, I can add a more complicated >>>> procedure, like this one: >>>> >>>> wait_time = 5 >>>> retries = 3 >>>> >>>> for x in xrange(retries): >>>> try: >>>> sleep(wait_time) >>>> http.stop() >>>> sleep(wait_time) >>>> http.start() >>>> except CalledProcessError: >>>> wait_time = wait_time * 2 >>>> continue >>>> break >>>> >>>> >>>> ---- >>>> >>>> httpd init script on sysV based platforms cannot guarantee that two >>>> consecutive httpd service restarts succeed when run in a small >>>> time distance. >>>> >>>> Add fallback procedure that adds additional waiting time after such >>>> failed restart attempt, and then try to stop and start the service >>>> again. >>>> >>>> https://fedorahosted.org/freeipa/ticket/2965 >>> >>> >>> Should we attempt to retrieve a file to ensure that the service is up? The >>> ipa.crt would be a candidate for this. >>> >>> rob >> >> Hm, this looks over-engineered from my POV. We already check that ports are >> open, right? > > Well, this is assuming that sysV is going to return an error when httpd doesn't > start. It should at least call service status to make sure the service is > operational. > > rob > Actually, we generally already do that as a part of start() process, you will see it when running my test script: DEBUG: stderr= DEBUG: args=/sbin/service httpd restart DEBUG: stdout=Stopping httpd: [FAILED] Starting httpd: [FAILED] DEBUG: stderr=(98)Address already in use: make_sock: could not bind to address [::]:80 (98)Address already in use: make_sock: could not bind to address 0.0.0.0:80 no listening sockets available, shutting down Unable to open logs DEBUG: httpd restart failed, try to stop&start again DEBUG: args=/sbin/service httpd stop DEBUG: stdout=Stopping httpd: [ OK ] DEBUG: stderr= DEBUG: args=/sbin/service httpd start DEBUG: stdout=Starting httpd: [ OK ] DEBUG: stderr= DEBUG: args=/sbin/service httpd status <<<<<<<<<< DEBUG: stdout=httpd dead but subsys locked But I just realized, that my change in httpinstance.py is redundant, it uses platform service to do the restart which has the fallback already, i.e. modification there is enough. Updated patch attached. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-324-2-add-fallback-for-httpd-restarts.patch Type: text/x-patch Size: 2416 bytes Desc: not available URL: From rcritten at redhat.com Thu Oct 18 15:14:40 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 18 Oct 2012 11:14:40 -0400 Subject: [Freeipa-devel] [PATCH 0020] Refactoring of default.conf man page In-Reply-To: <507ECA4D.60207@redhat.com> References: <507ECA4D.60207@redhat.com> Message-ID: <50801CE0.9060100@redhat.com> Tomas Babej wrote: > Hi, > > Description for the 'server' and 'wait_for_attr' option has been > added. Option 'server' has been marked as deprecated, as it is not > used anywhere in IPA code. All the options have been sorted > lexicographically. > > Please provide feedback for added descriptions: > > +.TP > +.B server > +Specifies the IPA Server hostname. This option is deprecated. > > +.TP > +.B wait_for_attr > +Debug option. Waits for asynchronous execution of 389-ds > postoperation plugins before returning data to the client, > therefore data added by postoperation plugins is included > in the result. Increases execution time. > > The rest of the patch is just sorting options lexicographically. > > Tomas Can you add startup_timeout as well? This controls the amount of time we wait when starting a service. The default is 2 minutes. And dogtag_version? The changes you made look good. rob From rcritten at redhat.com Thu Oct 18 15:22:25 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 18 Oct 2012 11:22:25 -0400 Subject: [Freeipa-devel] [PATCH] 323 Report ipa-upgradeconfig errors during RPM upgrade In-Reply-To: <507E940C.1000002@redhat.com> References: <507E940C.1000002@redhat.com> Message-ID: <50801EB1.2090507@redhat.com> Martin Kosek wrote: > Report errors just like with ipa-ldap-updater. These messages should warn > user that some parts of the upgrades may have not been successful and > he should follow up on them. Otherwise, user may not notice them at all. > > ipa-upgradeconfig logging has been made consistent with ipa-ldap-updater > logging - only error level or higher severity log messages are printed > to stderr, with the same console format. A new debug log that an upgrade > script has started was added to make log investigation easier. > > https://fedorahosted.org/freeipa/ticket/3157 > > --- > > Reproducer is in Bugzilla attached to the ticket. With this patch, RPM update > will report errors to user: > > # rpm -Uvh --force ~/freeipa-master/dist/rpms/freeipa-* > Preparing... ########################################### [100%] > 1:freeipa-python ########################################### [ 14%] > 2:freeipa-client ########################################### [ 29%] > 3:freeipa-admintools ########################################### [ 43%] > 4:freeipa-server ########################################### [ 57%] > ERROR: Cannot update connections in /etc/named.conf: [Errno 13] Permission > denied: '/etc/named.conf' > 5:freeipa-server-selinux ########################################### [ 71%] > 6:freeipa-server-trust-ad########################################### [ 86%] > 7:freeipa-debuginfo ########################################### [100%] > > Martin Can you add an option to run in info mode (the equivalent of verbose=True)? Otherwise running from the cli returns nothing unless there is an error, I like some amount of output myself. rob From rcritten at redhat.com Thu Oct 18 15:24:23 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 18 Oct 2012 11:24:23 -0400 Subject: [Freeipa-devel] [PATCH] 223 Simpler instructions to generate certificate In-Reply-To: <507E8EAB.1050309@redhat.com> References: <507E8EAB.1050309@redhat.com> Message-ID: <50801F27.3070009@redhat.com> Petr Vobornik wrote: > Instructions to generate certificate were simplified. > > New instructions: > > 1) Create a certificate database or use an existing one. To create a > new database: > # certutil -N -d > 2) Create a CSR with subject CN=,O=, for example: > # certutil -R -d -a -g -s > 'CN=dev.example.com,O=DEV.EXAMPLE.COM' > 3) Copy and paste the CSR (from -----BEGIN NEW CERTIFICATE > REQUEST----- to -----END NEW CERTIFICATE REQUEST-----) into the text > area below: > > https://fedorahosted.org/freeipa/ticket/3056 > ACK, looks good to me. rob From mkosek at redhat.com Thu Oct 18 15:34:09 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 18 Oct 2012 17:34:09 +0200 Subject: [Freeipa-devel] [PATCH] 323 Report ipa-upgradeconfig errors during RPM upgrade In-Reply-To: <50801EB1.2090507@redhat.com> References: <507E940C.1000002@redhat.com> <50801EB1.2090507@redhat.com> Message-ID: <50802171.7030901@redhat.com> On 10/18/2012 05:22 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> Report errors just like with ipa-ldap-updater. These messages should warn >> user that some parts of the upgrades may have not been successful and >> he should follow up on them. Otherwise, user may not notice them at all. >> >> ipa-upgradeconfig logging has been made consistent with ipa-ldap-updater >> logging - only error level or higher severity log messages are printed >> to stderr, with the same console format. A new debug log that an upgrade >> script has started was added to make log investigation easier. >> >> https://fedorahosted.org/freeipa/ticket/3157 >> >> --- >> >> Reproducer is in Bugzilla attached to the ticket. With this patch, RPM update >> will report errors to user: >> >> # rpm -Uvh --force ~/freeipa-master/dist/rpms/freeipa-* >> Preparing... ########################################### [100%] >> 1:freeipa-python ########################################### [ 14%] >> 2:freeipa-client ########################################### [ 29%] >> 3:freeipa-admintools ########################################### [ 43%] >> 4:freeipa-server ########################################### [ 57%] >> ERROR: Cannot update connections in /etc/named.conf: [Errno 13] Permission >> denied: '/etc/named.conf' >> 5:freeipa-server-selinux ########################################### [ 71%] >> 6:freeipa-server-trust-ad########################################### [ 86%] >> 7:freeipa-debuginfo ########################################### [100%] >> >> Martin > > Can you add an option to run in info mode (the equivalent of verbose=True)? > Otherwise running from the cli returns nothing unless there is an error, I like > some amount of output myself. > > rob > ipa-upgradeconfig has a --debug option. I doubt that the output can be more verbose :-) Martin From rcritten at redhat.com Thu Oct 18 15:37:49 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 18 Oct 2012 11:37:49 -0400 Subject: [Freeipa-devel] [PATCH] 500 Fix shutdown issues with systemd In-Reply-To: <1350389031.10587.192.camel@willson.li.ssimo.org> References: <1350389031.10587.192.camel@willson.li.ssimo.org> Message-ID: <5080224D.5040600@redhat.com> Simo Sorce wrote: > Also improve shutdown reliability and restart behavior so we always kill > all the processes we started even if the list of processes to handle > changed in LDAP. > > Fixes: https://fedorahosted.org/freeipa/ticket/2302 Should this list be updated if we do a post-install of DNS or the CA? It isn't now which would leave some services running. rob From simo at redhat.com Thu Oct 18 15:45:52 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 18 Oct 2012 11:45:52 -0400 Subject: [Freeipa-devel] [PATCH] 500 Fix shutdown issues with systemd In-Reply-To: <5080224D.5040600@redhat.com> References: <1350389031.10587.192.camel@willson.li.ssimo.org> <5080224D.5040600@redhat.com> Message-ID: <1350575152.30610.100.camel@willson.li.ssimo.org> On Thu, 2012-10-18 at 11:37 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > Also improve shutdown reliability and restart behavior so we always kill > > all the processes we started even if the list of processes to handle > > changed in LDAP. > > > > Fixes: https://fedorahosted.org/freeipa/ticket/2302 > > Should this list be updated if we do a post-install of DNS or the CA? It > isn't now which would leave some services running. Yes we probably should, but I think it should be done as a separate ticket. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Oct 18 15:48:22 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 18 Oct 2012 11:48:22 -0400 Subject: [Freeipa-devel] [PATCH] 0091 ipautil.run: Log the command line before running the command In-Reply-To: <507D7D75.60904@redhat.com> References: <507C0559.9010605@redhat.com> <507D68F1.80004@redhat.com> <507D6EE7.8050702@redhat.com> <507D74EB.4030602@redhat.com> <507D7CAF.20605@redhat.com> <507D7D75.60904@redhat.com> Message-ID: <508024C6.60709@redhat.com> Jan Cholasta wrote: > On 16.10.2012 17:26, Petr Viktorin wrote: >> On 10/16/2012 04:53 PM, Jan Cholasta wrote: >>> On 16.10.2012 16:27, Petr Viktorin wrote: >>>> On 10/16/2012 04:02 PM, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> On 15.10.2012 14:45, Petr Viktorin wrote: >>>>>> As I was debugging code that calls long-running or failing >>>>>> commands, I >>>>>> got tired of the invocation being logged after the command is done. >>>>>> This patch should improve the logging. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3174 >>>>>> --- >>>>>> Petr? >>>>>> >>>>> >>>>> + except: >>>>> + root_logger.debug('Process failed') >>>>> + raise >>>>> >>>>> Why do you use blank except here? Can you print the reason why the >>>>> process has failed or the exit code here? >>>>> >>>>> Honza >>>>> >>>> >>>> I re-raise command afterwards, so the error is not really handled or >>>> ignored. It's one of the few situations where a bare except is >>>> justified :) >>> >>> OK, makes sense. >>> >>>> Since the error is re-raised, it should be handled by the caller. >>>> Printing additional info here should be redundant. >>>> The exception can happen before the Popen object is created, so the >>>> return code might not be available. Anyway bad return code is handled >>>> later, here we'd get errors like command not found, fork() failure etc. >>> >>> Right. Anyway, I think logging the return code might come handy in some >>> situations. Can you please add it? >>> >> >> You're right. Added. >> >>>> >>>> I see that the wording could be better, attaching new patch: >>>> s/Process failed/Process execution failed/ >>>> s/Process successful/Process finished/ >>>> >>> >>> Honza >>> >> >> > > Thanks. ACK. > > Honza > pushed to ipa-3-0 and master rob From rcritten at redhat.com Thu Oct 18 15:51:18 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 18 Oct 2012 11:51:18 -0400 Subject: [Freeipa-devel] [PATCH] 500 Fix shutdown issues with systemd In-Reply-To: <1350575152.30610.100.camel@willson.li.ssimo.org> References: <1350389031.10587.192.camel@willson.li.ssimo.org> <5080224D.5040600@redhat.com> <1350575152.30610.100.camel@willson.li.ssimo.org> Message-ID: <50802576.20706@redhat.com> Simo Sorce wrote: > On Thu, 2012-10-18 at 11:37 -0400, Rob Crittenden wrote: >> Simo Sorce wrote: >>> Also improve shutdown reliability and restart behavior so we always kill >>> all the processes we started even if the list of processes to handle >>> changed in LDAP. >>> >>> Fixes: https://fedorahosted.org/freeipa/ticket/2302 >> >> Should this list be updated if we do a post-install of DNS or the CA? It >> isn't now which would leave some services running. > > Yes we probably should, > but I think it should be done as a separate ticket. > > Simo. > What's the impact if we don't do this now? rob From rcritten at redhat.com Thu Oct 18 15:51:45 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 18 Oct 2012 11:51:45 -0400 Subject: [Freeipa-devel] [PATCH] 323 Report ipa-upgradeconfig errors during RPM upgrade In-Reply-To: <50802171.7030901@redhat.com> References: <507E940C.1000002@redhat.com> <50801EB1.2090507@redhat.com> <50802171.7030901@redhat.com> Message-ID: <50802591.3020501@redhat.com> Martin Kosek wrote: > On 10/18/2012 05:22 PM, Rob Crittenden wrote: >> Martin Kosek wrote: >>> Report errors just like with ipa-ldap-updater. These messages should warn >>> user that some parts of the upgrades may have not been successful and >>> he should follow up on them. Otherwise, user may not notice them at all. >>> >>> ipa-upgradeconfig logging has been made consistent with ipa-ldap-updater >>> logging - only error level or higher severity log messages are printed >>> to stderr, with the same console format. A new debug log that an upgrade >>> script has started was added to make log investigation easier. >>> >>> https://fedorahosted.org/freeipa/ticket/3157 >>> >>> --- >>> >>> Reproducer is in Bugzilla attached to the ticket. With this patch, RPM update >>> will report errors to user: >>> >>> # rpm -Uvh --force ~/freeipa-master/dist/rpms/freeipa-* >>> Preparing... ########################################### [100%] >>> 1:freeipa-python ########################################### [ 14%] >>> 2:freeipa-client ########################################### [ 29%] >>> 3:freeipa-admintools ########################################### [ 43%] >>> 4:freeipa-server ########################################### [ 57%] >>> ERROR: Cannot update connections in /etc/named.conf: [Errno 13] Permission >>> denied: '/etc/named.conf' >>> 5:freeipa-server-selinux ########################################### [ 71%] >>> 6:freeipa-server-trust-ad########################################### [ 86%] >>> 7:freeipa-debuginfo ########################################### [100%] >>> >>> Martin >> >> Can you add an option to run in info mode (the equivalent of verbose=True)? >> Otherwise running from the cli returns nothing unless there is an error, I like >> some amount of output myself. >> >> rob >> > > ipa-upgradeconfig has a --debug option. I doubt that the output can be more > verbose :-) > > Martin > Yeah, but there is no middle ground. You either get everything or nothing. rob From simo at redhat.com Thu Oct 18 15:57:40 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 18 Oct 2012 11:57:40 -0400 Subject: [Freeipa-devel] [PATCH] 500 Fix shutdown issues with systemd In-Reply-To: <50802576.20706@redhat.com> References: <1350389031.10587.192.camel@willson.li.ssimo.org> <5080224D.5040600@redhat.com> <1350575152.30610.100.camel@willson.li.ssimo.org> <50802576.20706@redhat.com> Message-ID: <1350575860.30610.103.camel@willson.li.ssimo.org> On Thu, 2012-10-18 at 11:51 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Thu, 2012-10-18 at 11:37 -0400, Rob Crittenden wrote: > >> Simo Sorce wrote: > >>> Also improve shutdown reliability and restart behavior so we always kill > >>> all the processes we started even if the list of processes to handle > >>> changed in LDAP. > >>> > >>> Fixes: https://fedorahosted.org/freeipa/ticket/2302 > >> > >> Should this list be updated if we do a post-install of DNS or the CA? It > >> isn't now which would leave some services running. > > > > Yes we probably should, > > but I think it should be done as a separate ticket. > > > > Simo. > > > > What's the impact if we don't do this now? some services will not be turned off by ipactl, however this shouldn't impact much at shutdown, as systemd will shutdown left over stuff as it keeps track of all processes. uhmm however if someone does a ipactl restart those services will not be restarted the first time it is run (we will tell systemd to start them but it will do likely nothing as they are already started), after that they will be handled as they fact they are enabled will be stored in the file. Simo. -- Simo Sorce * Red Hat, Inc * New York From jdennis at redhat.com Thu Oct 18 17:20:28 2012 From: jdennis at redhat.com (John Dennis) Date: Thu, 18 Oct 2012 13:20:28 -0400 Subject: [Freeipa-devel] [PATCH 75] log dogtag errors In-Reply-To: <507FC679.1070203@redhat.com> References: <201204201807.q3KI7VuR019115@int-mx11.intmail.prod.int.phx2.redhat.com> <4F9A5C8D.9000004@redhat.com> <4F9BF5BF.5030302@redhat.com> <5076F98E.7020901@redhat.com> <5077D64C.1080701@redhat.com> <507EF7A6.6040604@redhat.com> <507FC679.1070203@redhat.com> Message-ID: <50803A5C.60305@redhat.com> On 10/18/2012 05:06 AM, Petr Viktorin wrote: > This looks much better. I found one more issue, though. > >> + if detail is not None: >> + err_msg += ' (%s)' % detail > > Here I get TypeError: unsupported operand type(s) for +=: 'Gettext' and > 'unicode'. > Until our Gettext class supports addition (part of #3188), please use > `err_msg = u'%s (%s)' % (err_msg, detail)` instead. Good catch, fixed. New patch attached. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jdennis-0075-2-log-dogtag-errors.patch Type: text/x-patch Size: 7730 bytes Desc: not available URL: From rcritten at redhat.com Thu Oct 18 18:01:24 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 18 Oct 2012 14:01:24 -0400 Subject: [Freeipa-devel] [PATCH 0017] Improve error message in ipa-replica-manage In-Reply-To: <506EF5F0.6070806@redhat.com> References: <506AED1B.8010205@redhat.com> <506AF250.2010404@redhat.com> <506EF5F0.6070806@redhat.com> Message-ID: <508043F4.4050504@redhat.com> Tomas Babej wrote: > On 10/02/2012 03:55 PM, Rob Crittenden wrote: >> Tomas Babej wrote: >>> Hi, >>> >>> When executing ipa-replica-manage connect to an unknown or irrelevant >>> master, we now print a sensible error message informing the user >>> about this possiblity as well. >>> >>> https://fedorahosted.org/freeipa/ticket/3105 >>> >>> Tomas >> >> I put a whole bunch of code into a try/except and this may be catching >> errors in unexpected ways. >> >> I'm not entirely sure right now what we should do, but looking at the >> code in the try: >> >> repl1.conn.getEntry(master1_dn, ldap.SCOPE_BASE) >> repl1.conn.getEntry(master2_dn, ldap.SCOPE_BASE) >> >> We take in replica1 and replica1 as arguments (the default for >> replica1 is the current host). >> >> If either of these raise a NotFound it means there there is no master >> of that name. Does that mean that the master was deleted? Well, >> clearly not. >> >> A lot has changed since I did this, I may have been relying on a >> side-effect, or just hadn't tested well-enough. >> >> I wonder if we need that message at all. Is "foo" is not an IPA server >> good enough? It still might be confusing if someone didn't know that >> "foo" was deleted and it was still running. We could probably verify >> that it is at least an IPA server by doing similar checking in the >> client, it all depends on how far we want to take it. >> >> rob > > I modified the patch. Now if the NotFound error is encountered, we try > to investigate whether we're trying to connect to an IPA server at all. > Please see if you have any suggestions. > > Tomas Getting there, the errors are a lot better. Can you modify the 'Connection unsuccessful' message to include the server we failed to connect to? The logger isn't so nice either, I think I'd prefer it if we could exclude the severity: ipa: ERROR: LDAP Error: Connect error: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user. Connection unsuccessful. So drop the 'ipa: ERROR: ' part for consistency. TI don't believe we configure the root logger at all in this tool so it is using the defaults. I'd also replace the test for -4 with the constant ipadiscovery.NOT_IPA_SERVER rob From abokovoy at redhat.com Thu Oct 18 19:00:54 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 18 Oct 2012 22:00:54 +0300 Subject: [Freeipa-devel] Search global catalog for trusted domain SIDs Message-ID: <20121018190054.GB17454@redhat.com> Hi, this is work in progress, shared mostly to get comments. Simo, Sumit, this is an attempt to resolve external group members from trusted domains using their Global Catalog services. The code quickly became complex because it needs to do a lot of additional activity. A rough sequence is following: 1. Match external member against existing trusted domain 2. Find trusted domain's domain controller 3. Fetch trusted domain account auth info 4. Set up ccache in /tmp/krb5cc_TRUSTEDDOMAIN with principal ourdomain$@trusted.domain 5. Do LDAP SASL interactive bind using the ccache 6. Search for the member's SID 7. Decode SID 8. Replace an external member name by SID in the group-add-member command Right now I'm failing at SASL interactive bind as Global Catalog does not accept the credentials in DomainValidator.__resolve_against_gc(), perhaps because I'm using LDAP SASL interactive bind wrongly. It is late here so I might simply be blind already. [Thu Oct 18 21:42:08.924696 2012] [:error] [pid 7831] [client 192.168.111.206:0] INVALID_CREDENTIALS: {'info': '8009030B: LdapErr: DSID-0C0904DC, comment: AcceptSecurityContext error, data 0, v1db1', 'desc': 'Invalid credentials'} Note that ccache is successfully created and populated and is usable from command line via ldapsearch: # klist -c /tmp/systemd-private-eBLWxO/krb5cc_TRUSTEDDOMAIN Ticket cache: FILE:/tmp/systemd-private-eBLWxO/krb5cc_TRUSTEDDOMAIN Default principal: IPATEAM$@AD.LOCAL Valid starting Expires Service principal 10/18/12 21:42:06 10/19/12 07:42:06 krbtgt/AD.LOCAL at AD.LOCAL renew until 10/19/12 21:42:08 10/18/12 21:42:06 10/19/12 07:42:06 ldap/winda.ad.local at AD.LOCAL renew until 10/19/12 21:42:08 # KRB5CCNAME=/tmp/systemd-private-eBLWxO/krb5cc_TRUSTEDDOMAIN ldapsearch -Y GSSAPI -H ldap://winda.ad.local:3268 -b dc=ad,dc=local '(&(sAMAccountName=ipateam$)(objectClass=*))' SASL/GSSAPI authentication started SASL username: IPATEAM$@AD.LOCAL SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base with scope subtree # filter: (&(sAMAccountName=ipateam$)(objectClass=*)) # requesting: ALL # # IPATEAM$, Users, ad.local dn: CN=IPATEAM$,CN=Users,DC=ad,DC=local objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user cn: IPATEAM$ distinguishedName: CN=IPATEAM$,CN=Users,DC=ad,DC=local instanceType: 4 whenCreated: 20121018132513.0Z whenChanged: 20121018174020.0Z uSNCreated: 209080 uSNChanged: 209106 name: IPATEAM$ objectGUID:: 43oH5Pepm0CCvJ8VGxLEnA== userAccountControl: 2080 primaryGroupID: 513 objectSid:: AQUAAAAAAAUVAAAAze8BAQQy1QhmzheAyAUAAA== sAMAccountName: IPATEAM$ sAMAccountType: 805306370 objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=ad,DC=local dSCorePropagationData: 16010101000000.0Z lastLogonTimestamp: 129950556201332000 # search result search: 4 result: 0 Success # numResponses: 2 # numEntries: 1 -- / Alexander Bokovoy -------------- next part -------------- >From 960277985935169490ca1c550bb8e0e3cd382001 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 18 Oct 2012 21:46:35 +0300 Subject: [PATCH 4/4] WIP: Resolve external members from trusted domain via Global Catalog A sequence is following: 1. Match external member against existing trusted domain 2. Find trusted domain's domain controller 3. Fetch trusted domain account auth info 4. Set up ccache in /tmp/krb5cc_TRUSTEDDOMAIN with principal ourdomain$@trusted.domain 5. Do LDAP SASL interactive bind using the ccache 6. Search for the member's SID 7. Decode SID 8. Replace external member name by SID --- ipalib/plugins/group.py | 6 +- ipaserver/dcerpc.py | 162 +++++++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 164 insertions(+), 4 deletions(-) diff --git a/ipalib/plugins/group.py b/ipalib/plugins/group.py index a174ba62cc32a7fb83474f52e2621521553889af..c4ecd6299d6111a389565e53f3a3e09a5c3f2f89 100644 --- a/ipalib/plugins/group.py +++ b/ipalib/plugins/group.py @@ -382,7 +382,11 @@ class group_add_member(LDAPAddMember): if domain_validator.is_trusted_sid_valid(sid): sids.append(sid) else: - failed_sids.append((sid, 'Not a trusted domain SID')) + actual_sid = domain_validator.get_sid_trusted_domain_object(sid) + if actual_sid: + sids.append(actual_sid) + else: + failed_sids.append((sid, 'Not a trusted domain SID')) if len(sids) == 0: raise errors.ValidationError(name=_('external member'), error=_('values are not recognized as valid SIDs from trusted domain')) diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index 80e6b7c87511e1d206df4d1de28574cc7b8410f7..1b5b77661aec20366f37f3a3d1f5e6e48de0cbff 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -29,6 +29,7 @@ from ipalib import Command from ipalib import errors from ipapython import ipautil from ipapython.ipa_log_manager import * +from ipapython.dn import DN from ipaserver.install import installutils import os, string, struct, copy @@ -46,6 +47,7 @@ try: except ImportError: from ldap.controls import LDAPControl as LDAPControl #pylint: disable=F0401 import ldap as _ldap +from ipaserver.ipaldap import IPAdmin __doc__ = _(""" Classes to manage trust joins using DCE-RPC calls @@ -102,6 +104,8 @@ class DomainValidator(object): ATTR_FLATNAME = 'ipantflatname' ATTR_SID = 'ipantsecurityidentifier' ATTR_TRUSTED_SID = 'ipanttrusteddomainsid' + ATTR_TRUST_PARTNER = 'ipanttrustpartner' + ATTR_TRUST_AUTHOUT = 'ipanttrustauthoutgoing' def __init__(self, api): self.api = api @@ -111,6 +115,9 @@ class DomainValidator(object): self.dn = None self.sid = None self._domains = None + self._info = dict() + self._creds = None + self._parm = None def is_configured(self): cn_trust_local = DN(('cn', self.api.env.domain), self.api.env.container_cifsdomains, self.api.env.basedn) @@ -124,15 +131,36 @@ class DomainValidator(object): return False return True + def __get_trust_creds(self): + cn_trust_local = DN(('cn', self.api.env.domain), self.api.env.container_cifsdomains, self.api.env.basedn) + try: + (dn, entry_attrs) = self.ldap.get_entry(cn_trust_local, [self.ATTR_FLATNAME, self.ATTR_SID]) + self.flatname = entry_attrs[self.ATTR_FLATNAME][0] + self.sid = entry_attrs[self.ATTR_SID][0] + self.dn = dn + self.domain = self.api.env.domain + except errors.NotFound, e: + return False + return True + + def get_trusted_domains(self): + """Returns dict of trusted domain tuples (flatname, sid, trust_auth_outgoing), keyed by domain name""" cn_trust = DN(('cn', 'ad'), self.api.env.container_trusts, self.api.env.basedn) try: search_kw = {'objectClass': 'ipaNTTrustedDomain'} filter = self.ldap.make_filter(search_kw, rules=self.ldap.MATCH_ALL) (entries, truncated) = self.ldap.find_entries(filter=filter, base_dn=cn_trust, - attrs_list=[self.ATTR_TRUSTED_SID, 'dn']) + attrs_list=[self.ATTR_TRUSTED_SID, + self.ATTR_FLATNAME, + self.ATTR_TRUST_PARTNER, + self.ATTR_TRUST_AUTHOUT]) - result = map (lambda entry: security.dom_sid(entry[1][self.ATTR_TRUSTED_SID][0]), entries) + result = dict() + for entry in entries: + result[entry[1][self.ATTR_TRUST_PARTNER][0]] = (entry[1][self.ATTR_FLATNAME][0].lower(), + security.dom_sid(entry[1][self.ATTR_TRUSTED_SID][0]), + entry[1][self.ATTR_TRUST_AUTHOUT][0]) return result except errors.NotFound, e: return [] @@ -158,13 +186,141 @@ class DomainValidator(object): # We have non-zero list of trusted domains and have to go through them # one by one and check their sids as prefixes test_sid_subauths = test_sid.sub_auths - for domsid in self._domains: + for domain in self._domains: + domsid = self._domains[domain][1] sub_auths = domsid.sub_auths num_auths = min(test_sid.num_auths, domsid.num_auths) if test_sid_subauths[:num_auths] == sub_auths[:num_auths]: return True return False + def normalize_name(self, name): + result = dict() + components = name.split('@') + if len(components) == 2: + result['domain'] = unicode(components[1]).lower() + result['name'] = unicode(components[0]).lower() + else: + components = name.split('\\') + if len(components) == 2: + result['flatname'] = unicode(components[0]).lower() + result['name'] = unicode(components[1]).lower() + else: + result['name'] = unicode(name).lower() + return result + + def get_sid_trusted_domain_object(self, object_name): + """Returns SID for the trusted domain object (user or group only)""" + if not self.domain: + # our domain is not configured or self.is_configured() never run + return None + if not self._domains: + self._domains = self.get_trusted_domains() + if len(self._domains) == 0: + # Our domain is configured but no trusted domains are configured + return None + components = self.normalize_name(object_name) + if not ('domain' in components or 'flatname' in components): + # No domain or realm specified, ambiguous search + return False + + entry = None + if 'domain' in components and components['domain'] in self._domains: + # Now we have a name to check against our list of trusted domains + info = self.__retrieve_trusted_domain_dc(components['domain']) + if 'dc' in info: + entry = self.__resolve_against_gc(info, components['name']) + elif 'flatname' in components: + # Flatname was specified, traverse through the list of trusted + # domains first to find the proper one + for domain in self._domains: + if self._domains[domain][0] == components['flatname']: + info = self.__retrieve_trusted_domain_dc(domain) + if info and 'dc' in info: + entry = self.__resolve_against_gc(info, components['name']) + if entry: + sid = entry.getValue('objectSid') + try: + test_sid = security.dom_sid(sid) + return str(test_sid) + except TypeError, e: + return False + return False + + def __extract_trusted_auth(self, info): + clear = None + auth = drsblobs.trustAuthInOutBlob() + auth.__ndr_unpack__(info['auth']) + self.api.log.error(auth.__ndr_print__()) + auth_array = auth.current.array[0] + if auth_array.AuthType == lsa.TRUST_AUTH_TYPE_CLEAR: + clear = ''.join(map(chr, auth_array.AuthInfo.password)).decode('utf-16-le') + return clear + + def __kinit_as_trusted_account(self, info, password): + ccache_name = "/tmp/krb5cc_TRUSTEDDOMAIN" + principal = '%s$@%s' % (self.flatname, info['dns_domain'].upper()) + (stdout, stderr, returncode) = ipautil.run(['/usr/bin/kinit', principal], + env={'KRB5CCNAME':ccache_name}, + stdin=password, raiseonerr=False) + if returncode == 0: + return (ccache_name, principal) + + def __resolve_against_gc(self, info, name): + conn = IPAdmin(host=info['dc'], port=3268) + auth = self.__extract_trusted_auth(info) + if auth: + (ccache_name, principal) = self.__kinit_as_trusted_account(info, auth) + if ccache_name: + cb_info = dict() + (CB_USER, CB_GETREALM) = (0x4001, 0x4008) + cb_info[CB_USER] = principal + cb_info[CB_GETREALM] = info['dns_domain'].upper() + sasl_auth = _ldap.sasl.sasl(cb_info,'GSSAPI') + old_ccache = os.environ.get('KRB5CCNAME') + os.environ["KRB5CCNAME"] = ccache_name + conn.sasl_interactive_bind_s(None, sasl_auth) + os.environ["KRB5CCNAME"] = old_ccache + base = DN(*map(lambda p: ('dc', p), info['dns_domain'].split('.'))) + entry = conn.getEntry(base, _ldap.SCOPE_BASE, + '(&(sAMAccountName=%(name)s)(|(objectClass=user)(objectClass=group)))' % dict(name=name), + ['sAMAccountName', 'sAMAccountType', 'objectSid', 'groupType', 'description']) + return entry + + def __retrieve_trusted_domain_dc(self, domain): + if domain in self._info: + return self._info[domain] + + if not self._creds: + self._parm = param.LoadParm() + self._parm.load(os.path.join(ipautil.SHARE_DIR,"smb.conf.empty")) + self._parm.set('netbios name', self.flatname) + self._creds = credentials.Credentials() + self._creds.set_kerberos_state(credentials.MUST_USE_KERBEROS) + self._creds.guess(self._parm) + self._creds.set_workstation(self.flatname) + + netrc = net.Net(creds=self._creds, lp=self._parm) + try: + result = netrc.finddc(domain=domain, flags=nbt.NBT_SERVER_LDAP | nbt.NBT_SERVER_DS) + except RuntimeError, e: + raise assess_dcerpc_exception(message=str(e)) + + if not result: + return None + + info = dict() + info['name'] = unicode(result.domain_name) + info['dns_domain'] = unicode(result.dns_domain) + info['dns_forest'] = unicode(result.forest) + info['guid'] = unicode(result.domain_uuid) + info['dc'] = unicode(result.pdc_dns_name) + info['auth'] = self._domains[domain][2] + + self._info[domain] = info + return info + + class TrustDomainInstance(object): def __init__(self, hostname, creds=None): -- 1.7.12 From abokovoy at redhat.com Thu Oct 18 19:06:22 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 18 Oct 2012 22:06:22 +0300 Subject: [Freeipa-devel] [PATCH] 500 Fix shutdown issues with systemd In-Reply-To: <5080224D.5040600@redhat.com> References: <1350389031.10587.192.camel@willson.li.ssimo.org> <5080224D.5040600@redhat.com> Message-ID: <20121018190622.GC17454@redhat.com> On Thu, 18 Oct 2012, Rob Crittenden wrote: >Simo Sorce wrote: >>Also improve shutdown reliability and restart behavior so we always kill >>all the processes we started even if the list of processes to handle >>changed in LDAP. >> >>Fixes: https://fedorahosted.org/freeipa/ticket/2302 > >Should this list be updated if we do a post-install of DNS or the CA? >It isn't now which would leave some services running. Same for ipa-adtrust-install. -- / Alexander Bokovoy From simo at redhat.com Thu Oct 18 19:15:43 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 18 Oct 2012 15:15:43 -0400 Subject: [Freeipa-devel] Search global catalog for trusted domain SIDs In-Reply-To: <20121018190054.GB17454@redhat.com> References: <20121018190054.GB17454@redhat.com> Message-ID: <1350587743.30610.104.camel@willson.li.ssimo.org> On Thu, 2012-10-18 at 22:00 +0300, Alexander Bokovoy wrote: > Hi, > > this is work in progress, shared mostly to get comments. > > Simo, Sumit, this is an attempt to resolve external group members from > trusted domains using their Global Catalog services. > > The code quickly became complex because it needs to do a lot of > additional activity. A rough sequence is following: > 1. Match external member against existing trusted domain > 2. Find trusted domain's domain controller > 3. Fetch trusted domain account auth info > 4. Set up ccache in /tmp/krb5cc_TRUSTEDDOMAIN with principal > ourdomain$@trusted.domain > 5. Do LDAP SASL interactive bind using the ccache > 6. Search for the member's SID > 7. Decode SID > 8. Replace an external member name by SID in the group-add-member > command > > Right now I'm failing at SASL interactive bind as Global Catalog does > not accept the credentials in DomainValidator.__resolve_against_gc(), > perhaps because I'm using LDAP SASL interactive bind wrongly. It is late > here so I might simply be blind already. > > [Thu Oct 18 21:42:08.924696 2012] [:error] [pid 7831] [client > 192.168.111.206:0] INVALID_CREDENTIALS: {'info': '8009030B: LdapErr: > DSID-0C0904DC, comment: AcceptSecurityContext error, data 0, v1db1', > 'desc': 'Invalid credentials'} I do not see anything clearly wrong in the patch, I guess wireshark may help to understand if there is a difference between your code and ldapsearch ? Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Oct 18 19:41:08 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 18 Oct 2012 15:41:08 -0400 Subject: [Freeipa-devel] Unit tests failing on F18 In-Reply-To: <507FB3CC.5080303@redhat.com> References: <50783536.8020007@redhat.com> <507F2B72.3050802@redhat.com> <507FB3CC.5080303@redhat.com> Message-ID: <50805B54.1070100@redhat.com> Martin Kosek wrote: > On 10/18/2012 12:04 AM, Rob Crittenden wrote: >> Martin Kosek wrote: >>> Hello, >>> >>> I was investigating global unit test failure on Fedora 18 for most of today, I >>> would like to share results I found so far. >>> >>> Unit test and its related scripts on F18 now reports NSS BUSY exception, just >>> like this one: >>> >>> # ./make-testcert >>> Traceback (most recent call last): >>> File "./make-testcert", line 134, in >>> sys.exit(makecert(reqdir)) >>> File "./make-testcert", line 111, in makecert >>> add=True) >>> File "./make-testcert", line 68, in run >>> result = self.execute(method, *args, **options) >>> File "/root/freeipa-master2/ipalib/backend.py", line 146, in execute >>> raise error #pylint: disable=E0702 >>> ipalib.errors.NetworkError: cannot connect to >>> 'http://vm-042.idm.lab.bos.redhat.com/ipa/session/xml': [Errno -8053] >>> (SEC_ERROR_BUSY) NSS could not shutdown. Objects are still in use. >>> >>> Something In F18 must have changed, this worked before... But leaked >>> NSSConnection objects without proper close() now ends with the exception above. >>> >>> In case of make-testcert script, the exception is raised because the script >>> does the following procedure: >>> >>> 1) connect, do one command >>> 2) disconnect >>> 3) connect, do second command >>> >>> However, during disconnect, NSSConnection is leaked which makes NSS very >>> uncomfortable during second connection atempt (and nss_shutdown()). I managed >>> to fix this issue with attached patch. ./make-testcert or "./make-test >>> tests/test_xmlrpc/test_group_plugin.py" works fine now. >>> >>> But global "./make-test" still fails, I think there is some remaining >>> NSSConnection leak, I suspect there is something wrong with how we use our >>> context (threading.local object). It looses a connection or some other thread >>> invoked in ldap2 module may be kicking in, here is my debug output: >>> >>> CONTEXT[xmlclient] = >>> >>> Test a simple LDAP bind using ldap2 ... SKIP: No directory manager password in >>> /root/.ipa/.dmpw >>> Test the `ipaserver.rpcserver.jsonserver.unmarshal` method. ... ok >>> tests.test_ipaserver.test_rpcserver.test_session.test_mount ... CONTEXT >>> 150714476: GET languages >>> >>> CONTEXT[xmlclient] = None >>> >>> The connection is in the context, but then something happens and it is gone. >>> Then, unit tests try to connect again and NSS fails. >>> >>> I would be really glad if somebody with a knowledge of NSS or how threads in >>> Python/IPA work could give me some advice... >>> >>> Thanks! >>> Martin >> >> I built upon your patch and have something that seems to work at least >> somewhat. I'm getting some unexpected test failures when running the entire >> suite but no NSS shutdown errors. I haven't had a chance to really investigate >> everything yet, sending this out as a work-in-progress in case you want to take >> a look. >> >> rob >> > > Yeah, this is great! I tested a fresh build+install on Fedora 18 with your > patch and all tests succeeded. So as for F18, I am inclined to ACK the patch as is. > > I am just not sure that this will work on platforms with Python version < 2.7, > xmlrpclib is different there. > > Martin > Here is my first crack at fixing that too. It requires a bunch of run time juggling though. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1065-tests.patch Type: text/x-diff Size: 3822 bytes Desc: not available URL: From rcritten at redhat.com Thu Oct 18 19:42:09 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 18 Oct 2012 15:42:09 -0400 Subject: [Freeipa-devel] [PATCH] 1066 requesting certs with subject alt name Message-ID: <50805B91.5050407@redhat.com> We were seeing a unicode failure when trying to request a certificate with subject alt names. This one-liner should fix it. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1066-altname.patch Type: text/x-diff Size: 969 bytes Desc: not available URL: From sbose at redhat.com Thu Oct 18 19:56:07 2012 From: sbose at redhat.com (Sumit Bose) Date: Thu, 18 Oct 2012 21:56:07 +0200 Subject: [Freeipa-devel] Search global catalog for trusted domain SIDs In-Reply-To: <20121018190054.GB17454@redhat.com> References: <20121018190054.GB17454@redhat.com> Message-ID: <20121018195607.GF23959@localhost.localdomain> On Thu, Oct 18, 2012 at 10:00:54PM +0300, Alexander Bokovoy wrote: > Hi, > > this is work in progress, shared mostly to get comments. > > Simo, Sumit, this is an attempt to resolve external group members from > trusted domains using their Global Catalog services. > > The code quickly became complex because it needs to do a lot of > additional activity. A rough sequence is following: > 1. Match external member against existing trusted domain > 2. Find trusted domain's domain controller > 3. Fetch trusted domain account auth info > 4. Set up ccache in /tmp/krb5cc_TRUSTEDDOMAIN with principal > ourdomain$@trusted.domain > 5. Do LDAP SASL interactive bind using the ccache > 6. Search for the member's SID > 7. Decode SID > 8. Replace an external member name by SID in the group-add-member > command > > Right now I'm failing at SASL interactive bind as Global Catalog does > not accept the credentials in DomainValidator.__resolve_against_gc(), > perhaps because I'm using LDAP SASL interactive bind wrongly. It is late > here so I might simply be blind already. > > [Thu Oct 18 21:42:08.924696 2012] [:error] [pid 7831] [client > 192.168.111.206:0] INVALID_CREDENTIALS: {'info': '8009030B: LdapErr: > DSID-0C0904DC, comment: AcceptSecurityContext error, data 0, v1db1', > 'desc': 'Invalid credentials'} > > Note that ccache is successfully created and populated and > is usable from command line via ldapsearch: > ... > + > + def __resolve_against_gc(self, info, name): > + conn = IPAdmin(host=info['dc'], port=3268) > + auth = self.__extract_trusted_auth(info) > + if auth: > + (ccache_name, principal) = self.__kinit_as_trusted_account(info, auth) > + if ccache_name: > + cb_info = dict() > + (CB_USER, CB_GETREALM) = (0x4001, 0x4008) > + cb_info[CB_USER] = principal > + cb_info[CB_GETREALM] = info['dns_domain'].upper() > + sasl_auth = _ldap.sasl.sasl(cb_info,'GSSAPI') > + old_ccache = os.environ.get('KRB5CCNAME') > + os.environ["KRB5CCNAME"] = ccache_name > + conn.sasl_interactive_bind_s(None, sasl_auth) > + os.environ["KRB5CCNAME"] = old_ccache Are you sure the bind is already finished here? I haven't looked at the implementation, but if it does a lazy bind, i.e. only bind when the first request is made, it will see the wrong ccache. Can you try to set KRB5CCNAME to the old value after calling conn.getEntry()? bye, Sumit > + base = DN(*map(lambda p: ('dc', p), info['dns_domain'].split('.'))) > + entry = conn.getEntry(base, _ldap.SCOPE_BASE, > + '(&(sAMAccountName=%(name)s)(|(objectClass=user)(objectClass=group)))' % dict(name=name), > + ['sAMAccountName', 'sAMAccountType', 'objectSid', 'groupType', 'description']) > + return entry From sbose at redhat.com Thu Oct 18 20:00:19 2012 From: sbose at redhat.com (Sumit Bose) Date: Thu, 18 Oct 2012 22:00:19 +0200 Subject: [Freeipa-devel] [PATCH 0019] Forbid overlapping primary and secondary rid ranges In-Reply-To: <507FA256.9040105@redhat.com> References: <507D5270.20904@redhat.com> <20121017091451.GR23959@localhost.localdomain> <507E8FA8.3070501@redhat.com> <20121017123445.GW23959@localhost.localdomain> <507EB2A7.40505@redhat.com> <20121017181249.GB23959@localhost.localdomain> <507FA256.9040105@redhat.com> Message-ID: <20121018200018.GG23959@localhost.localdomain> On Thu, Oct 18, 2012 at 08:31:50AM +0200, Tomas Babej wrote: > On 10/17/2012 08:12 PM, Sumit Bose wrote: > >On Wed, Oct 17, 2012 at 03:29:11PM +0200, Tomas Babej wrote: > >>On 10/17/2012 02:34 PM, Sumit Bose wrote: > >>>On Wed, Oct 17, 2012 at 12:59:52PM +0200, Tomas Babej wrote: > >>>>On 10/17/2012 11:14 AM, Sumit Bose wrote: > >>>>>On Tue, Oct 16, 2012 at 02:26:24PM +0200, Tomas Babej wrote: > >>>>>>Hi, > >>>>>> > >>>>>>commands ipa idrange-add / idrange-mod no longer allows the user > >>>>>>to enter primary or secondary rid range such that has non-zero > >>>>>>intersection with primary or secondary rid range of another > >>>>>>existing id range, as this could cause collision. > >>>>>> > >>>>>>Unit tests added to test_range_plugin.py > >>>>>> > >>>>>>https://fedorahosted.org/freeipa/ticket/3086 > >>>>>> > >>>>>>Tomas > >>>>>Thank you for the patch, comments are in-line. > >>>>> > >>>>>bye, > >>>>>Sumit > >>>>> > >>>.... > >>>>Thank you for your suggestions. New version of the patch attached. > >>>> > >>>>Tomas > >>>Thank you for addressing my comments. I just realized that the check is > >>>too strict. > >>> > >>>The ranges of the Posix IDs [base_id - base_id+id_range_size) may not > >>>overlap for any existing range because those IDs belong to the single > >>>Posix ID namespace of the IPA domain. I.e each user, local or from a > >>>trusted domain, must have a unique Posix ID. > >>> > >>>The RID ranges [base_rid, base_rid+id_range_size) and > >>>[secondary_base_rid, secondary_base_rid+id_range_size) may not overlap > >>>with RID ranges from the same domain. So the RID ranges for the local > >>>domain may not overlap and the RID ranges for any specific trusted > >>>domain may not overlap. It is allowed that there is a range form the > >>>local domain may have base_rid=1000 and a range from a trusted domain as > >>>well. This is ok because the RID is only part of the identifier, each > >>>domain has a unique domain SID which is used together with the RID to > >>>identify e.g. a user. > >>> > >>>I would suggest to look for the ipaNTTrustedDomainSID attribute in > >>>slapi_entry_to_range_info() too and add it to struct range_info. In > >>>ranges_overlap() you can then check the Posix ID range for all ranges > >>>but do the RID checks only when the domain identifiers are either both > >>>NULL (local IPA domain) or are the same strings. > >>> > >>>Sorry for not seeing this earlier. > >>> > >>>bye, > >>>Sumit > >>Thanks for catching this issue. It is solved in the newest revision > >>of the patch. > >> > >>Tomas > >sorry, found another one ... > > > >... > >>+static int ranges_overlap(struct range_info *r1, struct range_info *r2) > >>+{ > >>+ if (r1->name != NULL && r2->name != NULL && > >>+ strcasecmp(r1->name, r2->name) == 0) { > >>+ return 0; > >>+ } > >>+ > >>+ /* check if base range overlaps with existing base range */ > >>+ if (intervals_overlap(r1->base_id, r2->base_id, > >>+ r1->id_range_size, r2->id_range_size)){ > >>+ return 1; > >>+ } > >>+ > >>+ /* if both base_rid and secondary_base_rid = 0, the rid range is not set */ > >>+ bool rid_ranges_set = (r1->base_rid != 0 || r1->secondary_base_rid != 0) && > >>+ (r2->base_rid != 0 || r2->secondary_base_rid != 0); > >>+ > >>+ bool ranges_from_same_domain = > >>+ (r1->domain_id == NULL && r2->domain_id == NULL) || > >>+ (strcasecmp(r1->domain_id, r2->domain_id) == 0); > >>+ > >you have to check that both domain_id are not NULL before calling > >strcasecmp. > > > >bye, > >Sumit > Null pointer check added. > Thank you. ACK bye, Sumit > Tomas From abokovoy at redhat.com Thu Oct 18 20:42:34 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 18 Oct 2012 23:42:34 +0300 Subject: [Freeipa-devel] Search global catalog for trusted domain SIDs In-Reply-To: <20121018195607.GF23959@localhost.localdomain> References: <20121018190054.GB17454@redhat.com> <20121018195607.GF23959@localhost.localdomain> Message-ID: <20121018204234.GD17454@redhat.com> On Thu, 18 Oct 2012, Sumit Bose wrote: >On Thu, Oct 18, 2012 at 10:00:54PM +0300, Alexander Bokovoy wrote: >> Hi, >> >> this is work in progress, shared mostly to get comments. >> >> Simo, Sumit, this is an attempt to resolve external group members from >> trusted domains using their Global Catalog services. >> >> The code quickly became complex because it needs to do a lot of >> additional activity. A rough sequence is following: >> 1. Match external member against existing trusted domain >> 2. Find trusted domain's domain controller >> 3. Fetch trusted domain account auth info >> 4. Set up ccache in /tmp/krb5cc_TRUSTEDDOMAIN with principal >> ourdomain$@trusted.domain >> 5. Do LDAP SASL interactive bind using the ccache >> 6. Search for the member's SID >> 7. Decode SID >> 8. Replace an external member name by SID in the group-add-member >> command >> >> Right now I'm failing at SASL interactive bind as Global Catalog does >> not accept the credentials in DomainValidator.__resolve_against_gc(), >> perhaps because I'm using LDAP SASL interactive bind wrongly. It is late >> here so I might simply be blind already. >> >> [Thu Oct 18 21:42:08.924696 2012] [:error] [pid 7831] [client >> 192.168.111.206:0] INVALID_CREDENTIALS: {'info': '8009030B: LdapErr: >> DSID-0C0904DC, comment: AcceptSecurityContext error, data 0, v1db1', >> 'desc': 'Invalid credentials'} >> >> Note that ccache is successfully created and populated and >> is usable from command line via ldapsearch: >> >... >> + >> + def __resolve_against_gc(self, info, name): >> + conn = IPAdmin(host=info['dc'], port=3268) >> + auth = self.__extract_trusted_auth(info) >> + if auth: >> + (ccache_name, principal) = self.__kinit_as_trusted_account(info, auth) >> + if ccache_name: >> + cb_info = dict() >> + (CB_USER, CB_GETREALM) = (0x4001, 0x4008) >> + cb_info[CB_USER] = principal >> + cb_info[CB_GETREALM] = info['dns_domain'].upper() >> + sasl_auth = _ldap.sasl.sasl(cb_info,'GSSAPI') >> + old_ccache = os.environ.get('KRB5CCNAME') >> + os.environ["KRB5CCNAME"] = ccache_name >> + conn.sasl_interactive_bind_s(None, sasl_auth) >> + os.environ["KRB5CCNAME"] = old_ccache > >Are you sure the bind is already finished here? I haven't looked at the >implementation, but if it does a lazy bind, i.e. only bind when the >first request is made, it will see the wrong ccache. Can you try to >set KRB5CCNAME to the old value after calling conn.getEntry()? Yes, I'm sure because it raises exception from within sasl_interactive_bind_s() call, it never ever gets to the next line. [Thu Oct 18 23:28:12.421356 2012] [:error] [pid 8183] [client 192.168.111.206:0] conn.sasl_interactive_bind_s(None, sasl_auth) [Thu Oct 18 23:28:12.421412 2012] [:error] [pid 8183] [client 192.168.111.206:0] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py", line 556, in sasl_interactive_bind_s [Thu Oct 18 23:28:12.421832 2012] [:error] [pid 8183] [client 192.168.111.206:0] return self.conn.sasl_interactive_bind_s(who, auth, serverctrls, clientctrls, sasl_flags) [Thu Oct 18 23:28:12.421854 2012] [:error] [pid 8183] [client 192.168.111.206:0] File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 229, in sasl_interactive_bind_s [Thu Oct 18 23:28:12.422086 2012] [:error] [pid 8183] [client 192.168.111.206:0] return self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls),sasl_flags) [Thu Oct 18 23:28:12.422108 2012] [:error] [pid 8183] [client 192.168.111.206:0] File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 99, in _ldap_call [Thu Oct 18 23:28:12.422134 2012] [:error] [pid 8183] [client 192.168.111.206:0] result = func(*args,**kwargs) [Thu Oct 18 23:28:12.422196 2012] [:error] [pid 8183] [client 192.168.111.206:0] INVALID_CREDENTIALS: {'info': '8009030B: LdapErr: DSID-0C0904DC, comment: AcceptSecurityContext error, data 0, v1db1', 'desc': 'Invalid credentials'} -- / Alexander Bokovoy From sbose at redhat.com Thu Oct 18 21:15:25 2012 From: sbose at redhat.com (Sumit Bose) Date: Thu, 18 Oct 2012 23:15:25 +0200 Subject: [Freeipa-devel] Search global catalog for trusted domain SIDs In-Reply-To: <20121018204234.GD17454@redhat.com> References: <20121018190054.GB17454@redhat.com> <20121018195607.GF23959@localhost.localdomain> <20121018204234.GD17454@redhat.com> Message-ID: <20121018211525.GI23959@localhost.localdomain> On Thu, Oct 18, 2012 at 11:42:34PM +0300, Alexander Bokovoy wrote: > On Thu, 18 Oct 2012, Sumit Bose wrote: > >On Thu, Oct 18, 2012 at 10:00:54PM +0300, Alexander Bokovoy wrote: > >>Hi, > >> > >>this is work in progress, shared mostly to get comments. > >> > >>Simo, Sumit, this is an attempt to resolve external group members from > >>trusted domains using their Global Catalog services. > >> > >>The code quickly became complex because it needs to do a lot of > >>additional activity. A rough sequence is following: > >>1. Match external member against existing trusted domain > >>2. Find trusted domain's domain controller > >>3. Fetch trusted domain account auth info > >>4. Set up ccache in /tmp/krb5cc_TRUSTEDDOMAIN with principal > >> ourdomain$@trusted.domain > >>5. Do LDAP SASL interactive bind using the ccache > >>6. Search for the member's SID > >>7. Decode SID > >>8. Replace an external member name by SID in the group-add-member > >> command > >> > >>Right now I'm failing at SASL interactive bind as Global Catalog does > >>not accept the credentials in DomainValidator.__resolve_against_gc(), > >>perhaps because I'm using LDAP SASL interactive bind wrongly. It is late > >>here so I might simply be blind already. > >> > >>[Thu Oct 18 21:42:08.924696 2012] [:error] [pid 7831] [client > >>192.168.111.206:0] INVALID_CREDENTIALS: {'info': '8009030B: LdapErr: > >>DSID-0C0904DC, comment: AcceptSecurityContext error, data 0, v1db1', > >>'desc': 'Invalid credentials'} > >> > >>Note that ccache is successfully created and populated and > >>is usable from command line via ldapsearch: > >> > >... > >>+ > >>+ def __resolve_against_gc(self, info, name): > >>+ conn = IPAdmin(host=info['dc'], port=3268) > >>+ auth = self.__extract_trusted_auth(info) > >>+ if auth: > >>+ (ccache_name, principal) = self.__kinit_as_trusted_account(info, auth) > >>+ if ccache_name: > >>+ cb_info = dict() > >>+ (CB_USER, CB_GETREALM) = (0x4001, 0x4008) > >>+ cb_info[CB_USER] = principal > >>+ cb_info[CB_GETREALM] = info['dns_domain'].upper() > >>+ sasl_auth = _ldap.sasl.sasl(cb_info,'GSSAPI') > >>+ old_ccache = os.environ.get('KRB5CCNAME') > >>+ os.environ["KRB5CCNAME"] = ccache_name > >>+ conn.sasl_interactive_bind_s(None, sasl_auth) > >>+ os.environ["KRB5CCNAME"] = old_ccache > > > >Are you sure the bind is already finished here? I haven't looked at the > >implementation, but if it does a lazy bind, i.e. only bind when the > >first request is made, it will see the wrong ccache. Can you try to > >set KRB5CCNAME to the old value after calling conn.getEntry()? > Yes, I'm sure because it raises exception from within > sasl_interactive_bind_s() call, it never ever gets to the next line. > > [Thu Oct 18 23:28:12.421356 2012] [:error] [pid 8183] [client 192.168.111.206:0] conn.sasl_interactive_bind_s(None, sasl_auth) > [Thu Oct 18 23:28:12.421412 2012] [:error] [pid 8183] [client 192.168.111.206:0] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py", line 556, in sasl_interactive_bind_s > [Thu Oct 18 23:28:12.421832 2012] [:error] [pid 8183] [client 192.168.111.206:0] return self.conn.sasl_interactive_bind_s(who, auth, serverctrls, clientctrls, sasl_flags) > [Thu Oct 18 23:28:12.421854 2012] [:error] [pid 8183] [client 192.168.111.206:0] File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 229, in > sasl_interactive_bind_s > [Thu Oct 18 23:28:12.422086 2012] [:error] [pid 8183] [client 192.168.111.206:0] return self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls),sasl_flags) > [Thu Oct 18 23:28:12.422108 2012] [:error] [pid 8183] [client 192.168.111.206:0] File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 99, in _ldap_call > [Thu Oct 18 23:28:12.422134 2012] [:error] [pid 8183] [client 192.168.111.206:0] result = func(*args,**kwargs) > [Thu Oct 18 23:28:12.422196 2012] [:error] [pid 8183] [client 192.168.111.206:0] INVALID_CREDENTIALS: {'info': '8009030B: LdapErr: DSID-0C0904DC, comment: AcceptSecurityContext error, data 0, v1db1', 'desc': 'Invalid credentials'} > ok another guess. In the python docs it is said the "Such changes to the environment affect subprocesses started with os.system(), popen() or fork() and execv()." So I guess os.environ["KRB5CCNAME"]=something does not change the environment of the running process, but only python data. If I try to set a new env var in the python interpreter and look at /proc/PID/environ from a different shell, I see no changes. bye, Sumit > -- > / Alexander Bokovoy From abokovoy at redhat.com Thu Oct 18 21:22:16 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 19 Oct 2012 00:22:16 +0300 Subject: [Freeipa-devel] Search global catalog for trusted domain SIDs In-Reply-To: <20121018211525.GI23959@localhost.localdomain> References: <20121018190054.GB17454@redhat.com> <20121018195607.GF23959@localhost.localdomain> <20121018204234.GD17454@redhat.com> <20121018211525.GI23959@localhost.localdomain> Message-ID: <20121018212216.GE17454@redhat.com> On Thu, 18 Oct 2012, Sumit Bose wrote: >On Thu, Oct 18, 2012 at 11:42:34PM +0300, Alexander Bokovoy wrote: >> On Thu, 18 Oct 2012, Sumit Bose wrote: >> >On Thu, Oct 18, 2012 at 10:00:54PM +0300, Alexander Bokovoy wrote: >> >>Hi, >> >> >> >>this is work in progress, shared mostly to get comments. >> >> >> >>Simo, Sumit, this is an attempt to resolve external group members from >> >>trusted domains using their Global Catalog services. >> >> >> >>The code quickly became complex because it needs to do a lot of >> >>additional activity. A rough sequence is following: >> >>1. Match external member against existing trusted domain >> >>2. Find trusted domain's domain controller >> >>3. Fetch trusted domain account auth info >> >>4. Set up ccache in /tmp/krb5cc_TRUSTEDDOMAIN with principal >> >> ourdomain$@trusted.domain >> >>5. Do LDAP SASL interactive bind using the ccache >> >>6. Search for the member's SID >> >>7. Decode SID >> >>8. Replace an external member name by SID in the group-add-member >> >> command >> >> >> >>Right now I'm failing at SASL interactive bind as Global Catalog does >> >>not accept the credentials in DomainValidator.__resolve_against_gc(), >> >>perhaps because I'm using LDAP SASL interactive bind wrongly. It is late >> >>here so I might simply be blind already. >> >> >> >>[Thu Oct 18 21:42:08.924696 2012] [:error] [pid 7831] [client >> >>192.168.111.206:0] INVALID_CREDENTIALS: {'info': '8009030B: LdapErr: >> >>DSID-0C0904DC, comment: AcceptSecurityContext error, data 0, v1db1', >> >>'desc': 'Invalid credentials'} >> >> >> >>Note that ccache is successfully created and populated and >> >>is usable from command line via ldapsearch: >> >> >> >... >> >>+ >> >>+ def __resolve_against_gc(self, info, name): >> >>+ conn = IPAdmin(host=info['dc'], port=3268) >> >>+ auth = self.__extract_trusted_auth(info) >> >>+ if auth: >> >>+ (ccache_name, principal) = self.__kinit_as_trusted_account(info, auth) >> >>+ if ccache_name: >> >>+ cb_info = dict() >> >>+ (CB_USER, CB_GETREALM) = (0x4001, 0x4008) >> >>+ cb_info[CB_USER] = principal >> >>+ cb_info[CB_GETREALM] = info['dns_domain'].upper() >> >>+ sasl_auth = _ldap.sasl.sasl(cb_info,'GSSAPI') >> >>+ old_ccache = os.environ.get('KRB5CCNAME') >> >>+ os.environ["KRB5CCNAME"] = ccache_name >> >>+ conn.sasl_interactive_bind_s(None, sasl_auth) >> >>+ os.environ["KRB5CCNAME"] = old_ccache >> > >> >Are you sure the bind is already finished here? I haven't looked at the >> >implementation, but if it does a lazy bind, i.e. only bind when the >> >first request is made, it will see the wrong ccache. Can you try to >> >set KRB5CCNAME to the old value after calling conn.getEntry()? >> Yes, I'm sure because it raises exception from within >> sasl_interactive_bind_s() call, it never ever gets to the next line. >> >> [Thu Oct 18 23:28:12.421356 2012] [:error] [pid 8183] [client 192.168.111.206:0] conn.sasl_interactive_bind_s(None, sasl_auth) >> [Thu Oct 18 23:28:12.421412 2012] [:error] [pid 8183] [client 192.168.111.206:0] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py", line 556, in sasl_interactive_bind_s >> [Thu Oct 18 23:28:12.421832 2012] [:error] [pid 8183] [client 192.168.111.206:0] return self.conn.sasl_interactive_bind_s(who, auth, serverctrls, clientctrls, sasl_flags) >> [Thu Oct 18 23:28:12.421854 2012] [:error] [pid 8183] [client 192.168.111.206:0] File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 229, in >> sasl_interactive_bind_s >> [Thu Oct 18 23:28:12.422086 2012] [:error] [pid 8183] [client 192.168.111.206:0] return self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls),sasl_flags) >> [Thu Oct 18 23:28:12.422108 2012] [:error] [pid 8183] [client 192.168.111.206:0] File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 99, in _ldap_call >> [Thu Oct 18 23:28:12.422134 2012] [:error] [pid 8183] [client 192.168.111.206:0] result = func(*args,**kwargs) >> [Thu Oct 18 23:28:12.422196 2012] [:error] [pid 8183] [client 192.168.111.206:0] INVALID_CREDENTIALS: {'info': '8009030B: LdapErr: DSID-0C0904DC, comment: AcceptSecurityContext error, data 0, v1db1', 'desc': 'Invalid credentials'} >> > >ok another guess. In the python docs it is said the "Such changes to the >environment affect subprocesses started with os.system(), popen() or >fork() and execv()." So I guess os.environ["KRB5CCNAME"]=something does >not change the environment of the running process, but only python data. >If I try to set a new env var in the python interpreter and look at >/proc/PID/environ from a different shell, I see no changes. No, this does not matter. I'm reproducing the same error with a standalone app that does not modify environment: http://cpaste.org/1370/raw/ We do modify environment in the framework code (ipaserver/rpcserver.py) already and it works just fine. -- / Alexander Bokovoy From mkosek at redhat.com Fri Oct 19 06:15:49 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 19 Oct 2012 08:15:49 +0200 Subject: [Freeipa-devel] [PATCH] 323 Report ipa-upgradeconfig errors during RPM upgrade In-Reply-To: <50802591.3020501@redhat.com> References: <507E940C.1000002@redhat.com> <50801EB1.2090507@redhat.com> <50802171.7030901@redhat.com> <50802591.3020501@redhat.com> Message-ID: <5080F015.5030004@redhat.com> On 10/18/2012 05:51 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> On 10/18/2012 05:22 PM, Rob Crittenden wrote: >>> Martin Kosek wrote: >>>> Report errors just like with ipa-ldap-updater. These messages should warn >>>> user that some parts of the upgrades may have not been successful and >>>> he should follow up on them. Otherwise, user may not notice them at all. >>>> >>>> ipa-upgradeconfig logging has been made consistent with ipa-ldap-updater >>>> logging - only error level or higher severity log messages are printed >>>> to stderr, with the same console format. A new debug log that an upgrade >>>> script has started was added to make log investigation easier. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3157 >>>> >>>> --- >>>> >>>> Reproducer is in Bugzilla attached to the ticket. With this patch, RPM update >>>> will report errors to user: >>>> >>>> # rpm -Uvh --force ~/freeipa-master/dist/rpms/freeipa-* >>>> Preparing... ########################################### [100%] >>>> 1:freeipa-python ########################################### [ >>>> 14%] >>>> 2:freeipa-client ########################################### [ >>>> 29%] >>>> 3:freeipa-admintools ########################################### [ >>>> 43%] >>>> 4:freeipa-server ########################################### [ >>>> 57%] >>>> ERROR: Cannot update connections in /etc/named.conf: [Errno 13] Permission >>>> denied: '/etc/named.conf' >>>> 5:freeipa-server-selinux ########################################### [ >>>> 71%] >>>> 6:freeipa-server-trust-ad########################################### [ >>>> 86%] >>>> 7:freeipa-debuginfo ########################################### >>>> [100%] >>>> >>>> Martin >>> >>> Can you add an option to run in info mode (the equivalent of verbose=True)? >>> Otherwise running from the cli returns nothing unless there is an error, I like >>> some amount of output myself. >>> >>> rob >>> >> >> ipa-upgradeconfig has a --debug option. I doubt that the output can be more >> verbose :-) >> >> Martin >> > > Yeah, but there is no middle ground. You either get everything or nothing. > > rob Well, I can add it if you want it really hard. But from my perspective, having both "--debug" and "--verbose" is strange and it will also make it inconsistent with our other CLI tools where we have just --debug option (ipa-ldap-updater, ipa-replica-prepare, ipa-*-install). Martin From mkosek at redhat.com Fri Oct 19 07:04:14 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 19 Oct 2012 09:04:14 +0200 Subject: [Freeipa-devel] [PATCH 0019] Forbid overlapping primary and secondary rid ranges In-Reply-To: <20121018200018.GG23959@localhost.localdomain> References: <507D5270.20904@redhat.com> <20121017091451.GR23959@localhost.localdomain> <507E8FA8.3070501@redhat.com> <20121017123445.GW23959@localhost.localdomain> <507EB2A7.40505@redhat.com> <20121017181249.GB23959@localhost.localdomain> <507FA256.9040105@redhat.com> <20121018200018.GG23959@localhost.localdomain> Message-ID: <5080FB6E.3050200@redhat.com> On 10/18/2012 10:00 PM, Sumit Bose wrote: > On Thu, Oct 18, 2012 at 08:31:50AM +0200, Tomas Babej wrote: >> On 10/17/2012 08:12 PM, Sumit Bose wrote: >>> On Wed, Oct 17, 2012 at 03:29:11PM +0200, Tomas Babej wrote: >>>> On 10/17/2012 02:34 PM, Sumit Bose wrote: >>>>> On Wed, Oct 17, 2012 at 12:59:52PM +0200, Tomas Babej wrote: >>>>>> On 10/17/2012 11:14 AM, Sumit Bose wrote: >>>>>>> On Tue, Oct 16, 2012 at 02:26:24PM +0200, Tomas Babej wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> commands ipa idrange-add / idrange-mod no longer allows the user >>>>>>>> to enter primary or secondary rid range such that has non-zero >>>>>>>> intersection with primary or secondary rid range of another >>>>>>>> existing id range, as this could cause collision. >>>>>>>> >>>>>>>> Unit tests added to test_range_plugin.py >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/3086 >>>>>>>> >>>>>>>> Tomas >>>>>>> Thank you for the patch, comments are in-line. >>>>>>> >>>>>>> bye, >>>>>>> Sumit >>>>>>> >>>>> .... >>>>>> Thank you for your suggestions. New version of the patch attached. >>>>>> >>>>>> Tomas >>>>> Thank you for addressing my comments. I just realized that the check is >>>>> too strict. >>>>> >>>>> The ranges of the Posix IDs [base_id - base_id+id_range_size) may not >>>>> overlap for any existing range because those IDs belong to the single >>>>> Posix ID namespace of the IPA domain. I.e each user, local or from a >>>>> trusted domain, must have a unique Posix ID. >>>>> >>>>> The RID ranges [base_rid, base_rid+id_range_size) and >>>>> [secondary_base_rid, secondary_base_rid+id_range_size) may not overlap >>>>> with RID ranges from the same domain. So the RID ranges for the local >>>>> domain may not overlap and the RID ranges for any specific trusted >>>>> domain may not overlap. It is allowed that there is a range form the >>>>> local domain may have base_rid=1000 and a range from a trusted domain as >>>>> well. This is ok because the RID is only part of the identifier, each >>>>> domain has a unique domain SID which is used together with the RID to >>>>> identify e.g. a user. >>>>> >>>>> I would suggest to look for the ipaNTTrustedDomainSID attribute in >>>>> slapi_entry_to_range_info() too and add it to struct range_info. In >>>>> ranges_overlap() you can then check the Posix ID range for all ranges >>>>> but do the RID checks only when the domain identifiers are either both >>>>> NULL (local IPA domain) or are the same strings. >>>>> >>>>> Sorry for not seeing this earlier. >>>>> >>>>> bye, >>>>> Sumit >>>> Thanks for catching this issue. It is solved in the newest revision >>>> of the patch. >>>> >>>> Tomas >>> sorry, found another one ... >>> >>> ... >>>> +static int ranges_overlap(struct range_info *r1, struct range_info *r2) >>>> +{ >>>> + if (r1->name != NULL && r2->name != NULL && >>>> + strcasecmp(r1->name, r2->name) == 0) { >>>> + return 0; >>>> + } >>>> + >>>> + /* check if base range overlaps with existing base range */ >>>> + if (intervals_overlap(r1->base_id, r2->base_id, >>>> + r1->id_range_size, r2->id_range_size)){ >>>> + return 1; >>>> + } >>>> + >>>> + /* if both base_rid and secondary_base_rid = 0, the rid range is not set */ >>>> + bool rid_ranges_set = (r1->base_rid != 0 || r1->secondary_base_rid != 0) && >>>> + (r2->base_rid != 0 || r2->secondary_base_rid != 0); >>>> + >>>> + bool ranges_from_same_domain = >>>> + (r1->domain_id == NULL && r2->domain_id == NULL) || >>>> + (strcasecmp(r1->domain_id, r2->domain_id) == 0); >>>> + >>> you have to check that both domain_id are not NULL before calling >>> strcasecmp. >>> >>> bye, >>> Sumit >> Null pointer check added. >> > > Thank you. > > ACK > > bye, > Sumit >> Tomas Thanks guys. Pushed to master, ipa-3-0. Martin From pviktori at redhat.com Fri Oct 19 07:45:19 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 19 Oct 2012 09:45:19 +0200 Subject: [Freeipa-devel] [PATCH 75] log dogtag errors In-Reply-To: <50803A5C.60305@redhat.com> References: <201204201807.q3KI7VuR019115@int-mx11.intmail.prod.int.phx2.redhat.com> <4F9A5C8D.9000004@redhat.com> <4F9BF5BF.5030302@redhat.com> <5076F98E.7020901@redhat.com> <5077D64C.1080701@redhat.com> <507EF7A6.6040604@redhat.com> <507FC679.1070203@redhat.com> <50803A5C.60305@redhat.com> Message-ID: <5081050F.1030803@redhat.com> On 10/18/2012 07:20 PM, John Dennis wrote: > On 10/18/2012 05:06 AM, Petr Viktorin wrote: >> This looks much better. I found one more issue, though. >> >>> + if detail is not None: >>> + err_msg += ' (%s)' % detail >> >> Here I get TypeError: unsupported operand type(s) for +=: 'Gettext' and >> 'unicode'. >> Until our Gettext class supports addition (part of #3188), please use >> `err_msg = u'%s (%s)' % (err_msg, detail)` instead. > > Good catch, fixed. New patch attached. > It works fine now, thanks. ACK -- Petr? From pviktori at redhat.com Fri Oct 19 07:55:36 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 19 Oct 2012 09:55:36 +0200 Subject: [Freeipa-devel] [PATCH 0017] Improve error message in ipa-replica-manage In-Reply-To: <508043F4.4050504@redhat.com> References: <506AED1B.8010205@redhat.com> <506AF250.2010404@redhat.com> <506EF5F0.6070806@redhat.com> <508043F4.4050504@redhat.com> Message-ID: <50810778.5020202@redhat.com> On 10/18/2012 08:01 PM, Rob Crittenden wrote: > Tomas Babej wrote: >> On 10/02/2012 03:55 PM, Rob Crittenden wrote: >>> Tomas Babej wrote: >>>> Hi, >>>> >>>> When executing ipa-replica-manage connect to an unknown or irrelevant >>>> master, we now print a sensible error message informing the user >>>> about this possiblity as well. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3105 >>>> >>>> Tomas >>> >>> I put a whole bunch of code into a try/except and this may be catching >>> errors in unexpected ways. >>> >>> I'm not entirely sure right now what we should do, but looking at the >>> code in the try: >>> >>> repl1.conn.getEntry(master1_dn, ldap.SCOPE_BASE) >>> repl1.conn.getEntry(master2_dn, ldap.SCOPE_BASE) >>> >>> We take in replica1 and replica1 as arguments (the default for >>> replica1 is the current host). >>> >>> If either of these raise a NotFound it means there there is no master >>> of that name. Does that mean that the master was deleted? Well, >>> clearly not. >>> >>> A lot has changed since I did this, I may have been relying on a >>> side-effect, or just hadn't tested well-enough. >>> >>> I wonder if we need that message at all. Is "foo" is not an IPA server >>> good enough? It still might be confusing if someone didn't know that >>> "foo" was deleted and it was still running. We could probably verify >>> that it is at least an IPA server by doing similar checking in the >>> client, it all depends on how far we want to take it. >>> >>> rob >> >> I modified the patch. Now if the NotFound error is encountered, we try >> to investigate whether we're trying to connect to an IPA server at all. >> Please see if you have any suggestions. >> >> Tomas > > Getting there, the errors are a lot better. > > Can you modify the 'Connection unsuccessful' message to include the > server we failed to connect to? > > The logger isn't so nice either, I think I'd prefer it if we could > exclude the severity: > > ipa: ERROR: LDAP Error: Connect error: TLS error -8172:Peer's > certificate issuer has been marked as not trusted by the user. > Connection unsuccessful. > > So drop the 'ipa: ERROR: ' part for consistency. TI don't believe we > configure the root logger at all in this tool so it is using the defaults. It's not very easy to find the right call to configure the logger to drop the "ipa: ERROR:" part: standard_logging_setup(console_format='%(message)s') The function is in ipapython.ipa_log_manager. Hopefully that helps. > I'd also replace the test for -4 with the constant > ipadiscovery.NOT_IPA_SERVER > > rob > -- Petr? From pviktori at redhat.com Fri Oct 19 08:00:37 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 19 Oct 2012 10:00:37 +0200 Subject: [Freeipa-devel] [PATCH] 323 Report ipa-upgradeconfig errors during RPM upgrade In-Reply-To: <5080F015.5030004@redhat.com> References: <507E940C.1000002@redhat.com> <50801EB1.2090507@redhat.com> <50802171.7030901@redhat.com> <50802591.3020501@redhat.com> <5080F015.5030004@redhat.com> Message-ID: <508108A5.6080505@redhat.com> On 10/19/2012 08:15 AM, Martin Kosek wrote: > On 10/18/2012 05:51 PM, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On 10/18/2012 05:22 PM, Rob Crittenden wrote: >>>> Martin Kosek wrote: >>>>> Report errors just like with ipa-ldap-updater. These messages should warn >>>>> user that some parts of the upgrades may have not been successful and >>>>> he should follow up on them. Otherwise, user may not notice them at all. >>>>> >>>>> ipa-upgradeconfig logging has been made consistent with ipa-ldap-updater >>>>> logging - only error level or higher severity log messages are printed >>>>> to stderr, with the same console format. A new debug log that an upgrade >>>>> script has started was added to make log investigation easier. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3157 >>>>> >>>>> --- >>>>> >>>>> Reproducer is in Bugzilla attached to the ticket. With this patch, RPM update >>>>> will report errors to user: >>>>> >>>>> # rpm -Uvh --force ~/freeipa-master/dist/rpms/freeipa-* >>>>> Preparing... ########################################### [100%] >>>>> 1:freeipa-python ########################################### [ >>>>> 14%] >>>>> 2:freeipa-client ########################################### [ >>>>> 29%] >>>>> 3:freeipa-admintools ########################################### [ >>>>> 43%] >>>>> 4:freeipa-server ########################################### [ >>>>> 57%] >>>>> ERROR: Cannot update connections in /etc/named.conf: [Errno 13] Permission >>>>> denied: '/etc/named.conf' >>>>> 5:freeipa-server-selinux ########################################### [ >>>>> 71%] >>>>> 6:freeipa-server-trust-ad########################################### [ >>>>> 86%] >>>>> 7:freeipa-debuginfo ########################################### >>>>> [100%] >>>>> >>>>> Martin >>>> >>>> Can you add an option to run in info mode (the equivalent of verbose=True)? >>>> Otherwise running from the cli returns nothing unless there is an error, I like >>>> some amount of output myself. >>>> >>>> rob >>>> >>> >>> ipa-upgradeconfig has a --debug option. I doubt that the output can be more >>> verbose :-) >>> >>> Martin >>> >> >> Yeah, but there is no middle ground. You either get everything or nothing. >> >> rob > > Well, I can add it if you want it really hard. But from my perspective, having > both "--debug" and "--verbose" is strange and it will also make it inconsistent > with our other CLI tools where we have just --debug option (ipa-ldap-updater, > ipa-replica-prepare, ipa-*-install). > I like ipa-replica-conncheck's approach: --debug (output everything) and --quiet (only output errors). -- Petr? From mkosek at redhat.com Fri Oct 19 08:10:22 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 19 Oct 2012 10:10:22 +0200 Subject: [Freeipa-devel] [PATCH] 1066 requesting certs with subject alt name In-Reply-To: <50805B91.5050407@redhat.com> References: <50805B91.5050407@redhat.com> Message-ID: <50810AEE.8080308@redhat.com> On 10/18/2012 09:42 PM, Rob Crittenden wrote: > We were seeing a unicode failure when trying to request a certificate with > subject alt names. This one-liner should fix it. > > rob > Yup, this fixes it, works fine on --selfsign IPA CA too. Just when testing your patch, I found out we don't treat some non-DNS subject alternative name well, e.g. email extension, an we try to match it with our hosts: Certificate Request: ... Attributes: Requested Extensions: X509v3 Subject Alternative Name: email:foo at testcert.example.com, DNS:web.example.com ... cert-request result: ipa: ERROR: no host record for subject alt name foo at testcert.example.com in certificate request Do you want to fix it in current patch or should I create a ticket? Martin From mkosek at redhat.com Fri Oct 19 08:14:00 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 19 Oct 2012 10:14:00 +0200 Subject: [Freeipa-devel] [PATCH 75] log dogtag errors In-Reply-To: <5081050F.1030803@redhat.com> References: <201204201807.q3KI7VuR019115@int-mx11.intmail.prod.int.phx2.redhat.com> <4F9A5C8D.9000004@redhat.com> <4F9BF5BF.5030302@redhat.com> <5076F98E.7020901@redhat.com> <5077D64C.1080701@redhat.com> <507EF7A6.6040604@redhat.com> <507FC679.1070203@redhat.com> <50803A5C.60305@redhat.com> <5081050F.1030803@redhat.com> Message-ID: <50810BC8.9060704@redhat.com> On 10/19/2012 09:45 AM, Petr Viktorin wrote: > On 10/18/2012 07:20 PM, John Dennis wrote: >> On 10/18/2012 05:06 AM, Petr Viktorin wrote: >>> This looks much better. I found one more issue, though. >>> >>>> + if detail is not None: >>>> + err_msg += ' (%s)' % detail >>> >>> Here I get TypeError: unsupported operand type(s) for +=: 'Gettext' and >>> 'unicode'. >>> Until our Gettext class supports addition (part of #3188), please use >>> `err_msg = u'%s (%s)' % (err_msg, detail)` instead. >> >> Good catch, fixed. New patch attached. >> > > It works fine now, thanks. ACK > Pushed to master, ipa-3-0. Martin From pspacek at redhat.com Fri Oct 19 10:36:29 2012 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 19 Oct 2012 12:36:29 +0200 Subject: [Freeipa-devel] [PATCH] 1066 requesting certs with subject alt name In-Reply-To: <50810AEE.8080308@redhat.com> References: <50805B91.5050407@redhat.com> <50810AEE.8080308@redhat.com> Message-ID: <50812D2D.90207@redhat.com> On 10/19/2012 10:10 AM, Martin Kosek wrote: > On 10/18/2012 09:42 PM, Rob Crittenden wrote: >> We were seeing a unicode failure when trying to request a certificate with >> subject alt names. This one-liner should fix it. >> >> rob >> > > Yup, this fixes it, works fine on --selfsign IPA CA too. > > Just when testing your patch, I found out we don't treat some non-DNS subject > alternative name well, e.g. email extension, an we try to match it with our hosts: > > Certificate Request: > ... > Attributes: > Requested Extensions: > X509v3 Subject Alternative Name: > email:foo at testcert.example.com, DNS:web.example.com > ... > > cert-request result: > > ipa: ERROR: no host record for subject alt name foo at testcert.example.com in > certificate request IMHO there should be a --force option. SAN can contain a lot of different things. Also, we can't assume that we manage the whole world ... (now :-)) > > Do you want to fix it in current patch or should I create a ticket? > > Martin From tbabej at redhat.com Fri Oct 19 11:26:26 2012 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 19 Oct 2012 13:26:26 +0200 Subject: [Freeipa-devel] [PATCH 0018] Make service naming in ipa-server-install consistent In-Reply-To: <507FCB6C.1000807@redhat.com> References: <50769EC4.10001@redhat.com> <5076A027.4090009@redhat.com> <5076E1B1.70205@redhat.com> <507FCB6C.1000807@redhat.com> Message-ID: <508138E2.8050203@redhat.com> On 10/18/2012 11:27 AM, Martin Kosek wrote: > On 10/11/2012 05:11 PM, Tomas Babej wrote: >> On 10/11/2012 12:32 PM, Martin Kosek wrote: >>> On 10/11/2012 12:26 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> This patch forces more consistency into ipa-server-install output. All >>>> descriptions of services that are not instances of >>>> SimpleServiceInstance are now in the following format: >>>> >>>> () >>>> >>>> Furthermore, start_creation method has been modified to support >>>> custom start and end messages. >>>> >>>> Sample output produced by this patch attached. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3059 >>>> >>>> Tomas >>>> >>> Just based on reading the patch, this does not look right: >>> >>> - self.start_creation("Configuring certificate server", 210) >>> + self.start_creation("Configuring directory server for the CA", >>> + end_message="Done configuring directory server for the CA", >>> + show_service_name=True, runtime=210) >>> >>> Martin >>> >> Thanks, glitch fixed. >> >> Tomas > Ok, I managed to get the patch a proper review. I like the result, in the > console, but I still not entirely satisfied with the patch, looks > over-engineered to me + there is a lot of duplication with "Configuring > %(service)s" and "Done configuring %(service)s" messages. > > These messages could be easily generated only based on name of a service > (self.service_name, we got that) and a new "friendly service name" or description. > > If we add description this way: > > class KrbInstance(service.Service): > def __init__(self, fstore=None): > service.Service.__init__(self, "krb5kdc", description="Kerberos KDC") > ... > > the start_creation could be very simple: > ... > self.start_creation(runtime=30) > ... > > All messages could be simply generated by the Service class just based on > self.service_name and self.description with having the same output as you do now. > > Martin I simplified the approach as you suggested. However, I kept optional start_message and end_message parameters in case we would want to specify the messages instead of using the pre-generated ones. This is used in baseupdate.py and upgradeinstance.py More info in the documentation of start_creation() function. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0018-3-Make-service-naming-in-ipa-server-install-consistent.patch Type: text/x-patch Size: 15522 bytes Desc: not available URL: From mkosek at redhat.com Fri Oct 19 11:44:09 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 19 Oct 2012 13:44:09 +0200 Subject: [Freeipa-devel] [PATCH 0018] Make service naming in ipa-server-install consistent In-Reply-To: <508138E2.8050203@redhat.com> References: <50769EC4.10001@redhat.com> <5076A027.4090009@redhat.com> <5076E1B1.70205@redhat.com> <507FCB6C.1000807@redhat.com> <508138E2.8050203@redhat.com> Message-ID: <50813D09.6010908@redhat.com> On 10/19/2012 01:26 PM, Tomas Babej wrote: > On 10/18/2012 11:27 AM, Martin Kosek wrote: >> On 10/11/2012 05:11 PM, Tomas Babej wrote: >>> On 10/11/2012 12:32 PM, Martin Kosek wrote: >>>> On 10/11/2012 12:26 PM, Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> This patch forces more consistency into ipa-server-install output. All >>>>> descriptions of services that are not instances of >>>>> SimpleServiceInstance are now in the following format: >>>>> >>>>> () >>>>> >>>>> Furthermore, start_creation method has been modified to support >>>>> custom start and end messages. >>>>> >>>>> Sample output produced by this patch attached. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3059 >>>>> >>>>> Tomas >>>>> >>>> Just based on reading the patch, this does not look right: >>>> >>>> - self.start_creation("Configuring certificate server", 210) >>>> + self.start_creation("Configuring directory server for the CA", >>>> + end_message="Done configuring directory server for the CA", >>>> + show_service_name=True, runtime=210) >>>> >>>> Martin >>>> >>> Thanks, glitch fixed. >>> >>> Tomas >> Ok, I managed to get the patch a proper review. I like the result, in the >> console, but I still not entirely satisfied with the patch, looks >> over-engineered to me + there is a lot of duplication with "Configuring >> %(service)s" and "Done configuring %(service)s" messages. >> >> These messages could be easily generated only based on name of a service >> (self.service_name, we got that) and a new "friendly service name" or >> description. >> >> If we add description this way: >> >> class KrbInstance(service.Service): >> def __init__(self, fstore=None): >> service.Service.__init__(self, "krb5kdc", description="Kerberos KDC") >> ... >> >> the start_creation could be very simple: >> ... >> self.start_creation(runtime=30) >> ... >> >> All messages could be simply generated by the Service class just based on >> self.service_name and self.description with having the same output as you do >> now. >> >> Martin > I simplified the approach as you suggested. However, I kept optional > start_message and end_message parameters in case we would want > to specify the messages instead of using the pre-generated ones. > This is used in baseupdate.py and upgradeinstance.py > > More info in the documentation of start_creation() function. > > Tomas NACK. Tried running ./make-lint with your patch, got thousands of errors... But the approach looks OK, I am just thinking that default value for show_service_name of start_creation() should be True as it is the most widely used value - you would not have to specify it everytime you call start_creation() in *instance.py files. Martin From pvoborni at redhat.com Fri Oct 19 12:44:16 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 19 Oct 2012 14:44:16 +0200 Subject: [Freeipa-devel] [PATCH] 223 Simpler instructions to generate certificate In-Reply-To: <50801F27.3070009@redhat.com> References: <507E8EAB.1050309@redhat.com> <50801F27.3070009@redhat.com> Message-ID: <50814B20.7090000@redhat.com> On 10/18/2012 05:24 PM, Rob Crittenden wrote: > Petr Vobornik wrote: >> Instructions to generate certificate were simplified. >> >> New instructions: >> >> 1) Create a certificate database or use an existing one. To create a >> new database: >> # certutil -N -d >> 2) Create a CSR with subject CN=,O=, for example: >> # certutil -R -d -a -g -s >> 'CN=dev.example.com,O=DEV.EXAMPLE.COM' >> 3) Copy and paste the CSR (from -----BEGIN NEW CERTIFICATE >> REQUEST----- to -----END NEW CERTIFICATE REQUEST-----) into the text >> area below: >> >> https://fedorahosted.org/freeipa/ticket/3056 >> > > ACK, looks good to me. > > rob > Pushed to ipa-3-0, master. -- Petr Vobornik From tbabej at redhat.com Fri Oct 19 12:49:03 2012 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 19 Oct 2012 14:49:03 +0200 Subject: [Freeipa-devel] [PATCH 0018] Make service naming in ipa-server-install consistent In-Reply-To: <50813D09.6010908@redhat.com> References: <50769EC4.10001@redhat.com> <5076A027.4090009@redhat.com> <5076E1B1.70205@redhat.com> <507FCB6C.1000807@redhat.com> <508138E2.8050203@redhat.com> <50813D09.6010908@redhat.com> Message-ID: <50814C3F.2060005@redhat.com> On 10/19/2012 01:44 PM, Martin Kosek wrote: > On 10/19/2012 01:26 PM, Tomas Babej wrote: >> On 10/18/2012 11:27 AM, Martin Kosek wrote: >>> On 10/11/2012 05:11 PM, Tomas Babej wrote: >>>> On 10/11/2012 12:32 PM, Martin Kosek wrote: >>>>> On 10/11/2012 12:26 PM, Tomas Babej wrote: >>>>>> Hi, >>>>>> >>>>>> This patch forces more consistency into ipa-server-install output. All >>>>>> descriptions of services that are not instances of >>>>>> SimpleServiceInstance are now in the following format: >>>>>> >>>>>> () >>>>>> >>>>>> Furthermore, start_creation method has been modified to support >>>>>> custom start and end messages. >>>>>> >>>>>> Sample output produced by this patch attached. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3059 >>>>>> >>>>>> Tomas >>>>>> >>>>> Just based on reading the patch, this does not look right: >>>>> >>>>> - self.start_creation("Configuring certificate server", 210) >>>>> + self.start_creation("Configuring directory server for the CA", >>>>> + end_message="Done configuring directory server for the CA", >>>>> + show_service_name=True, runtime=210) >>>>> >>>>> Martin >>>>> >>>> Thanks, glitch fixed. >>>> >>>> Tomas >>> Ok, I managed to get the patch a proper review. I like the result, in the >>> console, but I still not entirely satisfied with the patch, looks >>> over-engineered to me + there is a lot of duplication with "Configuring >>> %(service)s" and "Done configuring %(service)s" messages. >>> >>> These messages could be easily generated only based on name of a service >>> (self.service_name, we got that) and a new "friendly service name" or >>> description. >>> >>> If we add description this way: >>> >>> class KrbInstance(service.Service): >>> def __init__(self, fstore=None): >>> service.Service.__init__(self, "krb5kdc", description="Kerberos KDC") >>> ... >>> >>> the start_creation could be very simple: >>> ... >>> self.start_creation(runtime=30) >>> ... >>> >>> All messages could be simply generated by the Service class just based on >>> self.service_name and self.description with having the same output as you do >>> now. >>> >>> Martin >> I simplified the approach as you suggested. However, I kept optional >> start_message and end_message parameters in case we would want >> to specify the messages instead of using the pre-generated ones. >> This is used in baseupdate.py and upgradeinstance.py >> >> More info in the documentation of start_creation() function. >> >> Tomas > NACK. Tried running ./make-lint with your patch, got thousands of errors... More like one error thousand times :) I somehow botched up rebasing the patch, I swear that I corrected that indentation issue beforehand. Nevermind, thanks for checking. ./make-lint runs clean now :) > > But the approach looks OK, I am just thinking that default value for > show_service_name of start_creation() should be True as it is the most widely > used value - you would not have to specify it everytime you call > start_creation() in *instance.py files. > > Martin Default values switched. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0018-4-Make-service-naming-in-ipa-server-install-consistent.patch Type: text/x-patch Size: 15554 bytes Desc: not available URL: From rcritten at redhat.com Fri Oct 19 13:10:14 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 19 Oct 2012 09:10:14 -0400 Subject: [Freeipa-devel] [PATCH] 1066 requesting certs with subject alt name In-Reply-To: <50812D2D.90207@redhat.com> References: <50805B91.5050407@redhat.com> <50810AEE.8080308@redhat.com> <50812D2D.90207@redhat.com> Message-ID: <50815136.1030709@redhat.com> Petr Spacek wrote: > On 10/19/2012 10:10 AM, Martin Kosek wrote: >> On 10/18/2012 09:42 PM, Rob Crittenden wrote: >>> We were seeing a unicode failure when trying to request a certificate >>> with >>> subject alt names. This one-liner should fix it. >>> >>> rob >>> >> >> Yup, this fixes it, works fine on --selfsign IPA CA too. >> >> Just when testing your patch, I found out we don't treat some non-DNS >> subject >> alternative name well, e.g. email extension, an we try to match it >> with our hosts: >> >> Certificate Request: >> ... >> Attributes: >> Requested Extensions: >> X509v3 Subject Alternative Name: >> email:foo at testcert.example.com, DNS:web.example.com >> ... >> >> cert-request result: >> >> ipa: ERROR: no host record for subject alt name >> foo at testcert.example.com in >> certificate request > > IMHO there should be a --force option. SAN can contain a lot of > different things. Also, we can't assume that we manage the whole world > ... (now :-)) > The intention was just to provide support for DNS alt names. I don't think requiring a host entry exist for any alt hosts is asking too much. I think a new ticket should be opened to support non-DNS alt names. rob From mkosek at redhat.com Fri Oct 19 13:16:41 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 19 Oct 2012 15:16:41 +0200 Subject: [Freeipa-devel] [PATCH 0018] Make service naming in ipa-server-install consistent In-Reply-To: <50814C3F.2060005@redhat.com> References: <50769EC4.10001@redhat.com> <5076A027.4090009@redhat.com> <5076E1B1.70205@redhat.com> <507FCB6C.1000807@redhat.com> <508138E2.8050203@redhat.com> <50813D09.6010908@redhat.com> <50814C3F.2060005@redhat.com> Message-ID: <508152B9.6020200@redhat.com> On 10/19/2012 02:49 PM, Tomas Babej wrote: > On 10/19/2012 01:44 PM, Martin Kosek wrote: >> On 10/19/2012 01:26 PM, Tomas Babej wrote: >>> On 10/18/2012 11:27 AM, Martin Kosek wrote: >>>> On 10/11/2012 05:11 PM, Tomas Babej wrote: >>>>> On 10/11/2012 12:32 PM, Martin Kosek wrote: >>>>>> On 10/11/2012 12:26 PM, Tomas Babej wrote: >>>>>>> Hi, >>>>>>> >>>>>>> This patch forces more consistency into ipa-server-install output. All >>>>>>> descriptions of services that are not instances of >>>>>>> SimpleServiceInstance are now in the following format: >>>>>>> >>>>>>> () >>>>>>> >>>>>>> Furthermore, start_creation method has been modified to support >>>>>>> custom start and end messages. >>>>>>> >>>>>>> Sample output produced by this patch attached. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/3059 >>>>>>> >>>>>>> Tomas >>>>>>> >>>>>> Just based on reading the patch, this does not look right: >>>>>> >>>>>> - self.start_creation("Configuring certificate server", 210) >>>>>> + self.start_creation("Configuring directory server for the CA", >>>>>> + end_message="Done configuring directory server for the CA", >>>>>> + show_service_name=True, runtime=210) >>>>>> >>>>>> Martin >>>>>> >>>>> Thanks, glitch fixed. >>>>> >>>>> Tomas >>>> Ok, I managed to get the patch a proper review. I like the result, in the >>>> console, but I still not entirely satisfied with the patch, looks >>>> over-engineered to me + there is a lot of duplication with "Configuring >>>> %(service)s" and "Done configuring %(service)s" messages. >>>> >>>> These messages could be easily generated only based on name of a service >>>> (self.service_name, we got that) and a new "friendly service name" or >>>> description. >>>> >>>> If we add description this way: >>>> >>>> class KrbInstance(service.Service): >>>> def __init__(self, fstore=None): >>>> service.Service.__init__(self, "krb5kdc", description="Kerberos >>>> KDC") >>>> ... >>>> >>>> the start_creation could be very simple: >>>> ... >>>> self.start_creation(runtime=30) >>>> ... >>>> >>>> All messages could be simply generated by the Service class just based on >>>> self.service_name and self.description with having the same output as you do >>>> now. >>>> >>>> Martin >>> I simplified the approach as you suggested. However, I kept optional >>> start_message and end_message parameters in case we would want >>> to specify the messages instead of using the pre-generated ones. >>> This is used in baseupdate.py and upgradeinstance.py >>> >>> More info in the documentation of start_creation() function. >>> >>> Tomas >> NACK. Tried running ./make-lint with your patch, got thousands of errors... > More like one error thousand times :) I somehow botched up rebasing > the patch, I swear that I corrected that indentation issue beforehand. > Nevermind, thanks for checking. ./make-lint runs clean now :) >> >> But the approach looks OK, I am just thinking that default value for >> show_service_name of start_creation() should be True as it is the most widely >> used value - you would not have to specify it everytime you call >> start_creation() in *instance.py files. >> >> Martin > Default values switched. > > Tomas NACK. Server installation crashed with the first step: # ipa-server-install Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd Unexpected error - see /var/log/ipaserver-install.log for details: TypeError: expected a character buffer object ipaserver-install.log: 2012-10-19T12:59:37Z INFO File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 614, in run_script return_value = main_function() File "/sbin/ipa-server-install", line 904, in main ntp.create_instance() File "/usr/lib/python2.7/site-packages/ipaserver/install/ntpinstance.py", line 158, in create_instance self.start_creation() File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 358, in start_creation self.print_msg(end_message) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 295, in print_msg print_msg(message, self.output_fd) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 60, in print_msg output_fd.write(message) 2012-10-19T12:59:37Z INFO The ipa-server-install command failed, exception: TypeError: expected a character buffer object Martin From rcritten at redhat.com Fri Oct 19 13:23:01 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 19 Oct 2012 09:23:01 -0400 Subject: [Freeipa-devel] [PATCH] 323 Report ipa-upgradeconfig errors during RPM upgrade In-Reply-To: <508108A5.6080505@redhat.com> References: <507E940C.1000002@redhat.com> <50801EB1.2090507@redhat.com> <50802171.7030901@redhat.com> <50802591.3020501@redhat.com> <5080F015.5030004@redhat.com> <508108A5.6080505@redhat.com> Message-ID: <50815435.1030301@redhat.com> Petr Viktorin wrote: > On 10/19/2012 08:15 AM, Martin Kosek wrote: >> On 10/18/2012 05:51 PM, Rob Crittenden wrote: >>> Martin Kosek wrote: >>>> On 10/18/2012 05:22 PM, Rob Crittenden wrote: >>>>> Martin Kosek wrote: >>>>>> Report errors just like with ipa-ldap-updater. These messages >>>>>> should warn >>>>>> user that some parts of the upgrades may have not been successful and >>>>>> he should follow up on them. Otherwise, user may not notice them >>>>>> at all. >>>>>> >>>>>> ipa-upgradeconfig logging has been made consistent with >>>>>> ipa-ldap-updater >>>>>> logging - only error level or higher severity log messages are >>>>>> printed >>>>>> to stderr, with the same console format. A new debug log that an >>>>>> upgrade >>>>>> script has started was added to make log investigation easier. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3157 >>>>>> >>>>>> --- >>>>>> >>>>>> Reproducer is in Bugzilla attached to the ticket. With this patch, >>>>>> RPM update >>>>>> will report errors to user: >>>>>> >>>>>> # rpm -Uvh --force ~/freeipa-master/dist/rpms/freeipa-* >>>>>> Preparing... >>>>>> ########################################### [100%] >>>>>> 1:freeipa-python >>>>>> ########################################### [ >>>>>> 14%] >>>>>> 2:freeipa-client >>>>>> ########################################### [ >>>>>> 29%] >>>>>> 3:freeipa-admintools >>>>>> ########################################### [ >>>>>> 43%] >>>>>> 4:freeipa-server >>>>>> ########################################### [ >>>>>> 57%] >>>>>> ERROR: Cannot update connections in /etc/named.conf: [Errno 13] >>>>>> Permission >>>>>> denied: '/etc/named.conf' >>>>>> 5:freeipa-server-selinux >>>>>> ########################################### [ >>>>>> 71%] >>>>>> >>>>>> 6:freeipa-server-trust-ad########################################### >>>>>> [ >>>>>> 86%] >>>>>> 7:freeipa-debuginfo >>>>>> ########################################### >>>>>> [100%] >>>>>> >>>>>> Martin >>>>> >>>>> Can you add an option to run in info mode (the equivalent of >>>>> verbose=True)? >>>>> Otherwise running from the cli returns nothing unless there is an >>>>> error, I like >>>>> some amount of output myself. >>>>> >>>>> rob >>>>> >>>> >>>> ipa-upgradeconfig has a --debug option. I doubt that the output can >>>> be more >>>> verbose :-) >>>> >>>> Martin >>>> >>> >>> Yeah, but there is no middle ground. You either get everything or >>> nothing. >>> >>> rob >> >> Well, I can add it if you want it really hard. But from my >> perspective, having >> both "--debug" and "--verbose" is strange and it will also make it >> inconsistent >> with our other CLI tools where we have just --debug option >> (ipa-ldap-updater, >> ipa-replica-prepare, ipa-*-install). >> > > I like ipa-replica-conncheck's approach: --debug (output everything) and > --quiet (only output errors). > I guess I'm sad because we spent a fair bit of time adding pretty output to the script in non-debug mode which we are not suppressing. ACK on quiet mode. rob From mkosek at redhat.com Fri Oct 19 13:37:58 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 19 Oct 2012 15:37:58 +0200 Subject: [Freeipa-devel] [PATCH] 325 Create reverse zone in unattended mode Message-ID: <508157B6.3070305@redhat.com> Previous fix for ticket #3161 caused ipa-{server,dns}-install to skip creation of reverse zone when running in unattended mode. Make sure that reverse zone is created also in unattended mode (unless --no-reverse is specified). https://fedorahosted.org/freeipa/ticket/3161 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-325-create-reverse-zone-in-unattended-mode.patch Type: text/x-patch Size: 2224 bytes Desc: not available URL: From rcritten at redhat.com Fri Oct 19 13:40:39 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 19 Oct 2012 09:40:39 -0400 Subject: [Freeipa-devel] [PATCH] 325 Create reverse zone in unattended mode In-Reply-To: <508157B6.3070305@redhat.com> References: <508157B6.3070305@redhat.com> Message-ID: <50815857.6030906@redhat.com> Martin Kosek wrote: > Previous fix for ticket #3161 caused ipa-{server,dns}-install to > skip creation of reverse zone when running in unattended mode. Make > sure that reverse zone is created also in unattended mode (unless > --no-reverse is specified). > > https://fedorahosted.org/freeipa/ticket/3161 ACK From pspacek at redhat.com Fri Oct 19 13:41:34 2012 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 19 Oct 2012 15:41:34 +0200 Subject: [Freeipa-devel] [PATCH] 1066 requesting certs with subject alt name In-Reply-To: <50815136.1030709@redhat.com> References: <50805B91.5050407@redhat.com> <50810AEE.8080308@redhat.com> <50812D2D.90207@redhat.com> <50815136.1030709@redhat.com> Message-ID: <5081588E.7070801@redhat.com> On 10/19/2012 03:10 PM, Rob Crittenden wrote: > Petr Spacek wrote: >> On 10/19/2012 10:10 AM, Martin Kosek wrote: >>> On 10/18/2012 09:42 PM, Rob Crittenden wrote: >>>> We were seeing a unicode failure when trying to request a certificate >>>> with >>>> subject alt names. This one-liner should fix it. >>>> >>>> rob >>>> >>> >>> Yup, this fixes it, works fine on --selfsign IPA CA too. >>> >>> Just when testing your patch, I found out we don't treat some non-DNS >>> subject >>> alternative name well, e.g. email extension, an we try to match it >>> with our hosts: >>> >>> Certificate Request: >>> ... >>> Attributes: >>> Requested Extensions: >>> X509v3 Subject Alternative Name: >>> email:foo at testcert.example.com, DNS:web.example.com >>> ... >>> >>> cert-request result: >>> >>> ipa: ERROR: no host record for subject alt name >>> foo at testcert.example.com in >>> certificate request >> >> IMHO there should be a --force option. SAN can contain a lot of >> different things. Also, we can't assume that we manage the whole world >> ... (now :-)) >> > > The intention was just to provide support for DNS alt names. I don't think > requiring a host entry exist for any alt hosts is asking too much. > > I think a new ticket should be opened to support non-DNS alt names. IMHO SAN names usually contain a lot of "virtual" names like www.shop1.com, ftp.shop1.com, etc. These names are usually CNAMEs to "real" name like srv1.shop1.com. In that case host object doesn't make sense. (But SAN is required for proper certificate validation.) Petr^2 Spacek From rcritten at redhat.com Fri Oct 19 13:46:47 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 19 Oct 2012 09:46:47 -0400 Subject: [Freeipa-devel] [PATCH] 1066 requesting certs with subject alt name In-Reply-To: <5081588E.7070801@redhat.com> References: <50805B91.5050407@redhat.com> <50810AEE.8080308@redhat.com> <50812D2D.90207@redhat.com> <50815136.1030709@redhat.com> <5081588E.7070801@redhat.com> Message-ID: <508159C7.10507@redhat.com> Petr Spacek wrote: > On 10/19/2012 03:10 PM, Rob Crittenden wrote: >> Petr Spacek wrote: >>> On 10/19/2012 10:10 AM, Martin Kosek wrote: >>>> On 10/18/2012 09:42 PM, Rob Crittenden wrote: >>>>> We were seeing a unicode failure when trying to request a certificate >>>>> with >>>>> subject alt names. This one-liner should fix it. >>>>> >>>>> rob >>>>> >>>> >>>> Yup, this fixes it, works fine on --selfsign IPA CA too. >>>> >>>> Just when testing your patch, I found out we don't treat some non-DNS >>>> subject >>>> alternative name well, e.g. email extension, an we try to match it >>>> with our hosts: >>>> >>>> Certificate Request: >>>> ... >>>> Attributes: >>>> Requested Extensions: >>>> X509v3 Subject Alternative Name: >>>> email:foo at testcert.example.com, DNS:web.example.com >>>> ... >>>> >>>> cert-request result: >>>> >>>> ipa: ERROR: no host record for subject alt name >>>> foo at testcert.example.com in >>>> certificate request >>> >>> IMHO there should be a --force option. SAN can contain a lot of >>> different things. Also, we can't assume that we manage the whole world >>> ... (now :-)) >>> >> >> The intention was just to provide support for DNS alt names. I don't >> think >> requiring a host entry exist for any alt hosts is asking too much. >> >> I think a new ticket should be opened to support non-DNS alt names. > > IMHO SAN names usually contain a lot of "virtual" names like > www.shop1.com, ftp.shop1.com, etc. > > These names are usually CNAMEs to "real" name like srv1.shop1.com. In > that case host object doesn't make sense. (But SAN is required for > proper certificate validation.) The purpose is so we more tightly control was certificates are issued by our CA because we automatically issue them. rob From mkosek at redhat.com Fri Oct 19 14:06:47 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 19 Oct 2012 16:06:47 +0200 Subject: [Freeipa-devel] [PATCH] 323 Report ipa-upgradeconfig errors during RPM upgrade In-Reply-To: <50815435.1030301@redhat.com> References: <507E940C.1000002@redhat.com> <50801EB1.2090507@redhat.com> <50802171.7030901@redhat.com> <50802591.3020501@redhat.com> <5080F015.5030004@redhat.com> <508108A5.6080505@redhat.com> <50815435.1030301@redhat.com> Message-ID: <50815E77.1030201@redhat.com> On 10/19/2012 03:23 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 10/19/2012 08:15 AM, Martin Kosek wrote: >>> On 10/18/2012 05:51 PM, Rob Crittenden wrote: >>>> Martin Kosek wrote: >>>>> On 10/18/2012 05:22 PM, Rob Crittenden wrote: >>>>>> Martin Kosek wrote: >>>>>>> Report errors just like with ipa-ldap-updater. These messages >>>>>>> should warn >>>>>>> user that some parts of the upgrades may have not been successful and >>>>>>> he should follow up on them. Otherwise, user may not notice them >>>>>>> at all. >>>>>>> >>>>>>> ipa-upgradeconfig logging has been made consistent with >>>>>>> ipa-ldap-updater >>>>>>> logging - only error level or higher severity log messages are >>>>>>> printed >>>>>>> to stderr, with the same console format. A new debug log that an >>>>>>> upgrade >>>>>>> script has started was added to make log investigation easier. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/3157 >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Reproducer is in Bugzilla attached to the ticket. With this patch, >>>>>>> RPM update >>>>>>> will report errors to user: >>>>>>> >>>>>>> # rpm -Uvh --force ~/freeipa-master/dist/rpms/freeipa-* >>>>>>> Preparing... >>>>>>> ########################################### [100%] >>>>>>> 1:freeipa-python >>>>>>> ########################################### [ >>>>>>> 14%] >>>>>>> 2:freeipa-client >>>>>>> ########################################### [ >>>>>>> 29%] >>>>>>> 3:freeipa-admintools >>>>>>> ########################################### [ >>>>>>> 43%] >>>>>>> 4:freeipa-server >>>>>>> ########################################### [ >>>>>>> 57%] >>>>>>> ERROR: Cannot update connections in /etc/named.conf: [Errno 13] >>>>>>> Permission >>>>>>> denied: '/etc/named.conf' >>>>>>> 5:freeipa-server-selinux >>>>>>> ########################################### [ >>>>>>> 71%] >>>>>>> >>>>>>> 6:freeipa-server-trust-ad########################################### >>>>>>> [ >>>>>>> 86%] >>>>>>> 7:freeipa-debuginfo >>>>>>> ########################################### >>>>>>> [100%] >>>>>>> >>>>>>> Martin >>>>>> >>>>>> Can you add an option to run in info mode (the equivalent of >>>>>> verbose=True)? >>>>>> Otherwise running from the cli returns nothing unless there is an >>>>>> error, I like >>>>>> some amount of output myself. >>>>>> >>>>>> rob >>>>>> >>>>> >>>>> ipa-upgradeconfig has a --debug option. I doubt that the output can >>>>> be more >>>>> verbose :-) >>>>> >>>>> Martin >>>>> >>>> >>>> Yeah, but there is no middle ground. You either get everything or >>>> nothing. >>>> >>>> rob >>> >>> Well, I can add it if you want it really hard. But from my >>> perspective, having >>> both "--debug" and "--verbose" is strange and it will also make it >>> inconsistent >>> with our other CLI tools where we have just --debug option >>> (ipa-ldap-updater, >>> ipa-replica-prepare, ipa-*-install). >>> >> >> I like ipa-replica-conncheck's approach: --debug (output everything) and >> --quiet (only output errors). >> > > I guess I'm sad because we spent a fair bit of time adding pretty output to the > script in non-debug mode which we are not suppressing. > > ACK on quiet mode. > > rob Ok, you won, this actually makes sense - added a --quiet mode. I also played a bit with console level formatting and print the level only in --debug mode. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-323-2-report-ipa-upgradeconfig-errors-during-rpm-upgrade.patch Type: text/x-patch Size: 4012 bytes Desc: not available URL: From mkosek at redhat.com Fri Oct 19 14:18:36 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 19 Oct 2012 16:18:36 +0200 Subject: [Freeipa-devel] [PATCH] 1066 requesting certs with subject alt name In-Reply-To: <508159C7.10507@redhat.com> References: <50805B91.5050407@redhat.com> <50810AEE.8080308@redhat.com> <50812D2D.90207@redhat.com> <50815136.1030709@redhat.com> <5081588E.7070801@redhat.com> <508159C7.10507@redhat.com> Message-ID: <5081613C.9090005@redhat.com> On 10/19/2012 03:46 PM, Rob Crittenden wrote: > Petr Spacek wrote: >> On 10/19/2012 03:10 PM, Rob Crittenden wrote: >>> Petr Spacek wrote: >>>> On 10/19/2012 10:10 AM, Martin Kosek wrote: >>>>> On 10/18/2012 09:42 PM, Rob Crittenden wrote: >>>>>> We were seeing a unicode failure when trying to request a certificate >>>>>> with >>>>>> subject alt names. This one-liner should fix it. >>>>>> >>>>>> rob >>>>>> >>>>> >>>>> Yup, this fixes it, works fine on --selfsign IPA CA too. >>>>> >>>>> Just when testing your patch, I found out we don't treat some non-DNS >>>>> subject >>>>> alternative name well, e.g. email extension, an we try to match it >>>>> with our hosts: >>>>> >>>>> Certificate Request: >>>>> ... >>>>> Attributes: >>>>> Requested Extensions: >>>>> X509v3 Subject Alternative Name: >>>>> email:foo at testcert.example.com, DNS:web.example.com >>>>> ... >>>>> >>>>> cert-request result: >>>>> >>>>> ipa: ERROR: no host record for subject alt name >>>>> foo at testcert.example.com in >>>>> certificate request >>>> >>>> IMHO there should be a --force option. SAN can contain a lot of >>>> different things. Also, we can't assume that we manage the whole world >>>> ... (now :-)) >>>> >>> >>> The intention was just to provide support for DNS alt names. I don't >>> think >>> requiring a host entry exist for any alt hosts is asking too much. >>> >>> I think a new ticket should be opened to support non-DNS alt names. >> >> IMHO SAN names usually contain a lot of "virtual" names like >> www.shop1.com, ftp.shop1.com, etc. >> >> These names are usually CNAMEs to "real" name like srv1.shop1.com. In >> that case host object doesn't make sense. (But SAN is required for >> proper certificate validation.) > > The purpose is so we more tightly control was certificates are issued by our CA > because we automatically issue them. > > rob I opened a ticket for better Subject Alternative Name check: https://fedorahosted.org/freeipa/ticket/3196 ACK for patch 1066. Pushed to master, ipa-3-0. Martin From mkosek at redhat.com Fri Oct 19 14:21:39 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 19 Oct 2012 16:21:39 +0200 Subject: [Freeipa-devel] [PATCH] 325 Create reverse zone in unattended mode In-Reply-To: <50815857.6030906@redhat.com> References: <508157B6.3070305@redhat.com> <50815857.6030906@redhat.com> Message-ID: <508161F3.2030900@redhat.com> On 10/19/2012 03:40 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> Previous fix for ticket #3161 caused ipa-{server,dns}-install to >> skip creation of reverse zone when running in unattended mode. Make >> sure that reverse zone is created also in unattended mode (unless >> --no-reverse is specified). >> >> https://fedorahosted.org/freeipa/ticket/3161 > > ACK > Pushed to master, ipa-3-0. Martin From pviktori at redhat.com Fri Oct 19 14:53:49 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 19 Oct 2012 16:53:49 +0200 Subject: [Freeipa-devel] [PATCH] 323 Report ipa-upgradeconfig errors during RPM upgrade In-Reply-To: <50815E77.1030201@redhat.com> References: <507E940C.1000002@redhat.com> <50801EB1.2090507@redhat.com> <50802171.7030901@redhat.com> <50802591.3020501@redhat.com> <5080F015.5030004@redhat.com> <508108A5.6080505@redhat.com> <50815435.1030301@redhat.com> <50815E77.1030201@redhat.com> Message-ID: <5081697D.3080503@redhat.com> On 10/19/2012 04:06 PM, Martin Kosek wrote: > On 10/19/2012 03:23 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 10/19/2012 08:15 AM, Martin Kosek wrote: >>>> On 10/18/2012 05:51 PM, Rob Crittenden wrote: >>>>> Martin Kosek wrote: >>>>>> On 10/18/2012 05:22 PM, Rob Crittenden wrote: >>>>>>> Martin Kosek wrote: >>>>>>>> Report errors just like with ipa-ldap-updater. These messages >>>>>>>> should warn >>>>>>>> user that some parts of the upgrades may have not been successful and >>>>>>>> he should follow up on them. Otherwise, user may not notice them >>>>>>>> at all. >>>>>>>> >>>>>>>> ipa-upgradeconfig logging has been made consistent with >>>>>>>> ipa-ldap-updater >>>>>>>> logging - only error level or higher severity log messages are >>>>>>>> printed >>>>>>>> to stderr, with the same console format. A new debug log that an >>>>>>>> upgrade >>>>>>>> script has started was added to make log investigation easier. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/3157 >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Reproducer is in Bugzilla attached to the ticket. With this patch, >>>>>>>> RPM update >>>>>>>> will report errors to user: >>>>>>>> >>>>>>>> # rpm -Uvh --force ~/freeipa-master/dist/rpms/freeipa-* >>>>>>>> Preparing... >>>>>>>> ########################################### [100%] >>>>>>>> 1:freeipa-python >>>>>>>> ########################################### [ >>>>>>>> 14%] >>>>>>>> 2:freeipa-client >>>>>>>> ########################################### [ >>>>>>>> 29%] >>>>>>>> 3:freeipa-admintools >>>>>>>> ########################################### [ >>>>>>>> 43%] >>>>>>>> 4:freeipa-server >>>>>>>> ########################################### [ >>>>>>>> 57%] >>>>>>>> ERROR: Cannot update connections in /etc/named.conf: [Errno 13] >>>>>>>> Permission >>>>>>>> denied: '/etc/named.conf' >>>>>>>> 5:freeipa-server-selinux >>>>>>>> ########################################### [ >>>>>>>> 71%] >>>>>>>> >>>>>>>> 6:freeipa-server-trust-ad########################################### >>>>>>>> [ >>>>>>>> 86%] >>>>>>>> 7:freeipa-debuginfo >>>>>>>> ########################################### >>>>>>>> [100%] >>>>>>>> >>>>>>>> Martin >>>>>>> >>>>>>> Can you add an option to run in info mode (the equivalent of >>>>>>> verbose=True)? >>>>>>> Otherwise running from the cli returns nothing unless there is an >>>>>>> error, I like >>>>>>> some amount of output myself. >>>>>>> >>>>>>> rob >>>>>>> >>>>>> >>>>>> ipa-upgradeconfig has a --debug option. I doubt that the output can >>>>>> be more >>>>>> verbose :-) >>>>>> >>>>>> Martin >>>>>> >>>>> >>>>> Yeah, but there is no middle ground. You either get everything or >>>>> nothing. >>>>> >>>>> rob >>>> >>>> Well, I can add it if you want it really hard. But from my >>>> perspective, having >>>> both "--debug" and "--verbose" is strange and it will also make it >>>> inconsistent >>>> with our other CLI tools where we have just --debug option >>>> (ipa-ldap-updater, >>>> ipa-replica-prepare, ipa-*-install). >>>> >>> >>> I like ipa-replica-conncheck's approach: --debug (output everything) and >>> --quiet (only output errors). >>> >> >> I guess I'm sad because we spent a fair bit of time adding pretty output to the >> script in non-debug mode which we are not suppressing. >> >> ACK on quiet mode. >> >> rob > > Ok, you won, this actually makes sense - added a --quiet mode. I also played a > bit with console level formatting and print the level only in --debug mode. > Nice idea. I think it would be useful if standard_logging_setup did this by default (though this patch is probably not the place for standard_logging_setup changes). -- Petr? From rcritten at redhat.com Fri Oct 19 15:42:59 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 19 Oct 2012 11:42:59 -0400 Subject: [Freeipa-devel] [PATCH] 0092 Make sure the CA is running when starting services In-Reply-To: <507D4B4A.5090907@redhat.com> References: <507D4B4A.5090907@redhat.com> Message-ID: <50817503.8090906@redhat.com> Petr Viktorin wrote: > https://fedorahosted.org/freeipa/ticket/3084 > See ticket & commit message. > > > Please tell me of a better way to extend the Services. > > > What's interesting is that usually the CA is "running" right after the > ports are opened, but if not, it takes *exactly* one minute between the > ports being open and the time I stop getting 503 "Service Temporarily > Unavailable" from ca/admin/ca/getStatus. Is there a sleep somewhere in > pki? or httpd? or IP?? No sleep that I know of, and I'm not seeing that behavior. In my testing I got 503 exactly once. Most of the time once the port(s) were open and the request went through the status was that dogtag was up and ready. Just a few minor requests. Can you add a block comment to ca_status? I think particularly explaining why port 443 and not a CA port directly (I assume so we test the proxy). I'm a little confused by the wait variable. It is a boolean in some cases and a string in others (no-proxy)? Why not just pass in False? The patch itself looks good. I'm having a replica install problem which I'm guessing is unrelated. The configure proxy step is failing to restart httpd. It is failing because the default mod_nss port is 8443 which is also being used by dogtag, so httpd fails to restart and the installation blows up. rob From pviktori at redhat.com Fri Oct 19 16:46:04 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 19 Oct 2012 18:46:04 +0200 Subject: [Freeipa-devel] [PATCH] 0093 ipa-replica-install: Use configured IPA DNS servers in forward/reverse resolution check Message-ID: <508183CC.8000908@redhat.com> Fix a regression in one of my earlier patches. https://fedorahosted.org/freeipa/ticket/3194 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0093-ipa-replica-install-Use-configured-IPA-DNS-servers-i.patch Type: text/x-patch Size: 3126 bytes Desc: not available URL: From rcritten at redhat.com Fri Oct 19 17:47:04 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 19 Oct 2012 13:47:04 -0400 Subject: [Freeipa-devel] [PATCH] 500 Fix shutdown issues with systemd In-Reply-To: <1350575860.30610.103.camel@willson.li.ssimo.org> References: <1350389031.10587.192.camel@willson.li.ssimo.org> <5080224D.5040600@redhat.com> <1350575152.30610.100.camel@willson.li.ssimo.org> <50802576.20706@redhat.com> <1350575860.30610.103.camel@willson.li.ssimo.org> Message-ID: <50819218.4010202@redhat.com> Simo Sorce wrote: > On Thu, 2012-10-18 at 11:51 -0400, Rob Crittenden wrote: >> Simo Sorce wrote: >>> On Thu, 2012-10-18 at 11:37 -0400, Rob Crittenden wrote: >>>> Simo Sorce wrote: >>>>> Also improve shutdown reliability and restart behavior so we always kill >>>>> all the processes we started even if the list of processes to handle >>>>> changed in LDAP. >>>>> >>>>> Fixes: https://fedorahosted.org/freeipa/ticket/2302 >>>> >>>> Should this list be updated if we do a post-install of DNS or the CA? It >>>> isn't now which would leave some services running. >>> >>> Yes we probably should, >>> but I think it should be done as a separate ticket. >>> >>> Simo. >>> >> >> What's the impact if we don't do this now? > > some services will not be turned off by ipactl, however this shouldn't > impact much at shutdown, as systemd will shutdown left over stuff as it > keeps track of all processes. > > uhmm however if someone does a ipactl restart those services will not be > restarted the first time it is run (we will tell systemd to start them > but it will do likely nothing as they are already started), after that > they will be handled as they fact they are enabled will be stored in the > file. Well, what is the downside of a call to refresh the list of running services that should be run at the end of setting up new services? Otherwise we could find outselves with a bunch of unreproducible cases where things weren't start/stopped properly. rob From simo at redhat.com Fri Oct 19 18:04:51 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 19 Oct 2012 14:04:51 -0400 Subject: [Freeipa-devel] [PATCH] 500 Fix shutdown issues with systemd In-Reply-To: <50819218.4010202@redhat.com> References: <1350389031.10587.192.camel@willson.li.ssimo.org> <5080224D.5040600@redhat.com> <1350575152.30610.100.camel@willson.li.ssimo.org> <50802576.20706@redhat.com> <1350575860.30610.103.camel@willson.li.ssimo.org> <50819218.4010202@redhat.com> Message-ID: <1350669891.30610.136.camel@willson.li.ssimo.org> On Fri, 2012-10-19 at 13:47 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Thu, 2012-10-18 at 11:51 -0400, Rob Crittenden wrote: > >> Simo Sorce wrote: > >>> On Thu, 2012-10-18 at 11:37 -0400, Rob Crittenden wrote: > >>>> Simo Sorce wrote: > >>>>> Also improve shutdown reliability and restart behavior so we always kill > >>>>> all the processes we started even if the list of processes to handle > >>>>> changed in LDAP. > >>>>> > >>>>> Fixes: https://fedorahosted.org/freeipa/ticket/2302 > >>>> > >>>> Should this list be updated if we do a post-install of DNS or the CA? It > >>>> isn't now which would leave some services running. > >>> > >>> Yes we probably should, > >>> but I think it should be done as a separate ticket. > >>> > >>> Simo. > >>> > >> > >> What's the impact if we don't do this now? > > > > some services will not be turned off by ipactl, however this shouldn't > > impact much at shutdown, as systemd will shutdown left over stuff as it > > keeps track of all processes. > > > > uhmm however if someone does a ipactl restart those services will not be > > restarted the first time it is run (we will tell systemd to start them > > but it will do likely nothing as they are already started), after that > > they will be handled as they fact they are enabled will be stored in the > > file. > > Well, what is the downside of a call to refresh the list of running > services that should be run at the end of setting up new services? > > Otherwise we could find outselves with a bunch of unreproducible cases > where things weren't start/stopped properly. Yeah I have been thinking about that. I am thinking of changing the patch so that it's the service class itself that saves this data. That way saving is always performed no matter 'what' starts the service. Do you agree ? Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Fri Oct 19 18:11:03 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 19 Oct 2012 14:11:03 -0400 Subject: [Freeipa-devel] [PATCH] 324 Add fallback for httpd restarts In-Reply-To: <508017EE.4070809@redhat.com> References: <507FF468.7000801@redhat.com> <507FFA5D.6040002@redhat.com> <50800020.6020602@redhat.com> <508013D1.7030001@redhat.com> <508017EE.4070809@redhat.com> Message-ID: <508197B7.7070507@redhat.com> Martin Kosek wrote: > On 10/18/2012 04:36 PM, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On 10/18/2012 02:47 PM, Rob Crittenden wrote: >>>> Martin Kosek wrote: >>>>> Attaching a script I used to reproduce the issue on machine with sysV (RHEL >>>>> 6.4 >>>>> in my case). With the patch applied, httpd restarts correctly fallback-ed. >>>>> >>>>> If you think that the wait is not enough, I can add a more complicated >>>>> procedure, like this one: >>>>> >>>>> wait_time = 5 >>>>> retries = 3 >>>>> >>>>> for x in xrange(retries): >>>>> try: >>>>> sleep(wait_time) >>>>> http.stop() >>>>> sleep(wait_time) >>>>> http.start() >>>>> except CalledProcessError: >>>>> wait_time = wait_time * 2 >>>>> continue >>>>> break >>>>> >>>>> >>>>> ---- >>>>> >>>>> httpd init script on sysV based platforms cannot guarantee that two >>>>> consecutive httpd service restarts succeed when run in a small >>>>> time distance. >>>>> >>>>> Add fallback procedure that adds additional waiting time after such >>>>> failed restart attempt, and then try to stop and start the service >>>>> again. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/2965 >>>> >>>> >>>> Should we attempt to retrieve a file to ensure that the service is up? The >>>> ipa.crt would be a candidate for this. >>>> >>>> rob >>> >>> Hm, this looks over-engineered from my POV. We already check that ports are >>> open, right? >> >> Well, this is assuming that sysV is going to return an error when httpd doesn't >> start. It should at least call service status to make sure the service is >> operational. >> >> rob >> > > Actually, we generally already do that as a part of start() process, you will > see it when running my test script: > > DEBUG: stderr= > DEBUG: args=/sbin/service httpd restart > DEBUG: stdout=Stopping httpd: [FAILED] > Starting httpd: [FAILED] > > DEBUG: stderr=(98)Address already in use: make_sock: could not bind to address > [::]:80 > (98)Address already in use: make_sock: could not bind to address 0.0.0.0:80 > no listening sockets available, shutting down > Unable to open logs > > DEBUG: httpd restart failed, try to stop&start again > DEBUG: args=/sbin/service httpd stop > DEBUG: stdout=Stopping httpd: [ OK ] > > DEBUG: stderr= > DEBUG: args=/sbin/service httpd start > DEBUG: stdout=Starting httpd: [ OK ] > > DEBUG: stderr= > DEBUG: args=/sbin/service httpd status <<<<<<<<<< > DEBUG: stdout=httpd dead but subsys locked > > But I just realized, that my change in httpinstance.py is redundant, it uses > platform service to do the restart which has the fallback already, i.e. > modification there is enough. Updated patch attached. > > Martin > ack, pushed to master and ipa-3-0 From rcritten at redhat.com Fri Oct 19 18:15:53 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 19 Oct 2012 14:15:53 -0400 Subject: [Freeipa-devel] [PATCH] 500 Fix shutdown issues with systemd In-Reply-To: <1350669891.30610.136.camel@willson.li.ssimo.org> References: <1350389031.10587.192.camel@willson.li.ssimo.org> <5080224D.5040600@redhat.com> <1350575152.30610.100.camel@willson.li.ssimo.org> <50802576.20706@redhat.com> <1350575860.30610.103.camel@willson.li.ssimo.org> <50819218.4010202@redhat.com> <1350669891.30610.136.camel@willson.li.ssimo.org> Message-ID: <508198D9.7020005@redhat.com> Simo Sorce wrote: > On Fri, 2012-10-19 at 13:47 -0400, Rob Crittenden wrote: >> Simo Sorce wrote: >>> On Thu, 2012-10-18 at 11:51 -0400, Rob Crittenden wrote: >>>> Simo Sorce wrote: >>>>> On Thu, 2012-10-18 at 11:37 -0400, Rob Crittenden wrote: >>>>>> Simo Sorce wrote: >>>>>>> Also improve shutdown reliability and restart behavior so we always kill >>>>>>> all the processes we started even if the list of processes to handle >>>>>>> changed in LDAP. >>>>>>> >>>>>>> Fixes: https://fedorahosted.org/freeipa/ticket/2302 >>>>>> >>>>>> Should this list be updated if we do a post-install of DNS or the CA? It >>>>>> isn't now which would leave some services running. >>>>> >>>>> Yes we probably should, >>>>> but I think it should be done as a separate ticket. >>>>> >>>>> Simo. >>>>> >>>> >>>> What's the impact if we don't do this now? >>> >>> some services will not be turned off by ipactl, however this shouldn't >>> impact much at shutdown, as systemd will shutdown left over stuff as it >>> keeps track of all processes. >>> >>> uhmm however if someone does a ipactl restart those services will not be >>> restarted the first time it is run (we will tell systemd to start them >>> but it will do likely nothing as they are already started), after that >>> they will be handled as they fact they are enabled will be stored in the >>> file. >> >> Well, what is the downside of a call to refresh the list of running >> services that should be run at the end of setting up new services? >> >> Otherwise we could find outselves with a bunch of unreproducible cases >> where things weren't start/stopped properly. > > Yeah I have been thinking about that. > I am thinking of changing the patch so that it's the service class > itself that saves this data. > > That way saving is always performed no matter 'what' starts the service. > Do you agree ? > Yes, that sounds like it'll be very robust. rob From rcritten at redhat.com Fri Oct 19 18:54:59 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 19 Oct 2012 14:54:59 -0400 Subject: [Freeipa-devel] [PATCH] 323 Report ipa-upgradeconfig errors during RPM upgrade In-Reply-To: <50815E77.1030201@redhat.com> References: <507E940C.1000002@redhat.com> <50801EB1.2090507@redhat.com> <50802171.7030901@redhat.com> <50802591.3020501@redhat.com> <5080F015.5030004@redhat.com> <508108A5.6080505@redhat.com> <50815435.1030301@redhat.com> <50815E77.1030201@redhat.com> Message-ID: <5081A203.6000205@redhat.com> Martin Kosek wrote: > On 10/19/2012 03:23 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 10/19/2012 08:15 AM, Martin Kosek wrote: >>>> On 10/18/2012 05:51 PM, Rob Crittenden wrote: >>>>> Martin Kosek wrote: >>>>>> On 10/18/2012 05:22 PM, Rob Crittenden wrote: >>>>>>> Martin Kosek wrote: >>>>>>>> Report errors just like with ipa-ldap-updater. These messages >>>>>>>> should warn >>>>>>>> user that some parts of the upgrades may have not been successful and >>>>>>>> he should follow up on them. Otherwise, user may not notice them >>>>>>>> at all. >>>>>>>> >>>>>>>> ipa-upgradeconfig logging has been made consistent with >>>>>>>> ipa-ldap-updater >>>>>>>> logging - only error level or higher severity log messages are >>>>>>>> printed >>>>>>>> to stderr, with the same console format. A new debug log that an >>>>>>>> upgrade >>>>>>>> script has started was added to make log investigation easier. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/3157 >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Reproducer is in Bugzilla attached to the ticket. With this patch, >>>>>>>> RPM update >>>>>>>> will report errors to user: >>>>>>>> >>>>>>>> # rpm -Uvh --force ~/freeipa-master/dist/rpms/freeipa-* >>>>>>>> Preparing... >>>>>>>> ########################################### [100%] >>>>>>>> 1:freeipa-python >>>>>>>> ########################################### [ >>>>>>>> 14%] >>>>>>>> 2:freeipa-client >>>>>>>> ########################################### [ >>>>>>>> 29%] >>>>>>>> 3:freeipa-admintools >>>>>>>> ########################################### [ >>>>>>>> 43%] >>>>>>>> 4:freeipa-server >>>>>>>> ########################################### [ >>>>>>>> 57%] >>>>>>>> ERROR: Cannot update connections in /etc/named.conf: [Errno 13] >>>>>>>> Permission >>>>>>>> denied: '/etc/named.conf' >>>>>>>> 5:freeipa-server-selinux >>>>>>>> ########################################### [ >>>>>>>> 71%] >>>>>>>> >>>>>>>> 6:freeipa-server-trust-ad########################################### >>>>>>>> [ >>>>>>>> 86%] >>>>>>>> 7:freeipa-debuginfo >>>>>>>> ########################################### >>>>>>>> [100%] >>>>>>>> >>>>>>>> Martin >>>>>>> >>>>>>> Can you add an option to run in info mode (the equivalent of >>>>>>> verbose=True)? >>>>>>> Otherwise running from the cli returns nothing unless there is an >>>>>>> error, I like >>>>>>> some amount of output myself. >>>>>>> >>>>>>> rob >>>>>>> >>>>>> >>>>>> ipa-upgradeconfig has a --debug option. I doubt that the output can >>>>>> be more >>>>>> verbose :-) >>>>>> >>>>>> Martin >>>>>> >>>>> >>>>> Yeah, but there is no middle ground. You either get everything or >>>>> nothing. >>>>> >>>>> rob >>>> >>>> Well, I can add it if you want it really hard. But from my >>>> perspective, having >>>> both "--debug" and "--verbose" is strange and it will also make it >>>> inconsistent >>>> with our other CLI tools where we have just --debug option >>>> (ipa-ldap-updater, >>>> ipa-replica-prepare, ipa-*-install). >>>> >>> >>> I like ipa-replica-conncheck's approach: --debug (output everything) and >>> --quiet (only output errors). >>> >> >> I guess I'm sad because we spent a fair bit of time adding pretty output to the >> script in non-debug mode which we are not suppressing. >> >> ACK on quiet mode. >> >> rob > > Ok, you won, this actually makes sense - added a --quiet mode. I also played a > bit with console level formatting and print the level only in --debug mode. > > Martin > ACK, pushed to master and ipa-3-0 From tbabej at redhat.com Mon Oct 22 08:11:12 2012 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 22 Oct 2012 10:11:12 +0200 Subject: [Freeipa-devel] [PATCH 0020] Refactoring of default.conf man page In-Reply-To: <50801CE0.9060100@redhat.com> References: <507ECA4D.60207@redhat.com> <50801CE0.9060100@redhat.com> Message-ID: <5084FFA0.3010807@redhat.com> On 10/18/2012 05:14 PM, Rob Crittenden wrote: > Tomas Babej wrote: >> Hi, >> >> Description for the 'server' and 'wait_for_attr' option has been >> added. Option 'server' has been marked as deprecated, as it is not >> used anywhere in IPA code. All the options have been sorted >> lexicographically. >> >> Please provide feedback for added descriptions: >> >> +.TP >> +.B server >> +Specifies the IPA Server hostname. This option is deprecated. >> >> +.TP >> +.B wait_for_attr >> +Debug option. Waits for asynchronous execution of 389-ds >> postoperation plugins before returning data to the client, >> therefore data added by postoperation plugins is included >> in the result. Increases execution time. >> >> The rest of the patch is just sorting options lexicographically. >> >> Tomas > > Can you add startup_timeout as well? This controls the amount of time > we wait when starting a service. The default is 2 minutes. > > And dogtag_version? > > The changes you made look good. > > rob > > The descriptions for the requested options have been added: +.B dogtag_version +Stores the version of Dogtag. Value 9 is assumed if not specified otherwise. +.B startup_timeout