From dpal at redhat.com Sun Jun 2 02:00:21 2013 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 01 Jun 2013 22:00:21 -0400 Subject: [Freeipa-devel] IPAv3.1 and Redhat 6.4 In-Reply-To: References: <51A9126F.5090005@redhat.com> Message-ID: <51AAA735.1070902@redhat.com> On 05/31/2013 07:27 PM, Stephen Ingram wrote: > On Fri, May 31, 2013 at 2:13 PM, Dmitri Pal > wrote: > > On 05/31/2013 04:47 PM, Nicholas MacKenzie wrote: >> Will IPAv3.1 ever come to 6.4 or perhaps 6.5? Are there any >> rumors surrounding release dates? >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > 6.4 has SSSD 1.9 and IPA 3.0 > There are no plans to port 3.1+ server versions to RHEL6.x. > There are considerations to backport SSSD and ipa-client to 6.x. > Version is yet TBD but for 6.5 we are focusing on porting selcted > fixes for SSSD 1.9 and IPA 3.0. > > > With this being the case, will there be an upgrade path to RHEL 7.x > and IPA 3.2.x? Since upgrade from RHEL 6.x to 7.x will probably not > work, would replication to a higher version work or maybe the backup > that Rob was working on? > > Steve The plan is to support mixed 6.x and 7.x replicas in one deployment for a period of migration. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From diane at ghic.org Sun Jun 2 04:48:07 2013 From: diane at ghic.org (Diane Trout) Date: Sat, 01 Jun 2013 21:48:07 -0700 Subject: [Freeipa-devel] Minor error: format not a string literal and no format arguments [-Werror=format-security] In-Reply-To: <2421658.MiZkXgAtf3@myrada> References: <2421658.MiZkXgAtf3@myrada> Message-ID: <4426203.q59XKFUOqa@myrada> I wasn't subscribed to the list before, so here's the git formatted patch you were asking for. Diane -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-log-format-not-a-string-literal.patch Type: text/x-patch Size: 1117 bytes Desc: not available URL: From pvoborni at redhat.com Mon Jun 3 07:26:26 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 03 Jun 2013 09:26:26 +0200 Subject: [Freeipa-devel] [PATCH] 417 Regression fix: missing control buttons in nested search facets In-Reply-To: <51A5E9FE.3040305@redhat.com> References: <51A5BE91.3030306@redhat.com> <51A5E9FE.3040305@redhat.com> Message-ID: <51AC4522.5050809@redhat.com> On 05/29/2013 01:43 PM, Ana Krivokapic wrote: > On 05/29/2013 10:38 AM, Petr Vobornik wrote: >> Automount maps, keys and dnsrecord search facet are missing control >> buttons (add, delete, refresh). >> >> Regression introduced by 6e90920233cc9a7c9feb040dea22cda837715c39 - >> 'Move spec modifications from facet factories to pre_ops'. >> >> https://fedorahosted.org/freeipa/ticket/3605 >> > This fixes the issue, ACK. Pushed to master, ipa-3-2. -- Petr Vobornik From mkosek at redhat.com Mon Jun 3 07:59:16 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 03 Jun 2013 09:59:16 +0200 Subject: [Freeipa-devel] Minor error: format not a string literal and no format arguments [-Werror=format-security] In-Reply-To: <4426203.q59XKFUOqa@myrada> References: <2421658.MiZkXgAtf3@myrada> <4426203.q59XKFUOqa@myrada> Message-ID: <51AC4CD4.9050403@redhat.com> On 06/02/2013 06:48 AM, Diane Trout wrote: > I wasn't subscribed to the list before, so here's the git formatted patch you > were asking for. > > Diane Sumit already ACKed the patch, I pushed it to master and ipa-3-2 branches. Thanks for the patch. We appreciate efforts in making FreeIPA available in other platforms, patches welcome. Martin From pspacek at redhat.com Mon Jun 3 08:51:37 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 03 Jun 2013 10:51:37 +0200 Subject: [Freeipa-devel] [PATCH 0160] Fix crash triggered by missing sasl_user parameter In-Reply-To: <1388581366.5830954.1370002047640.JavaMail.root@redhat.com> References: <51A5FB33.7000802@redhat.com> <1388581366.5830954.1370002047640.JavaMail.root@redhat.com> Message-ID: <51AC5919.5010001@redhat.com> On 31.5.2013 14:07, Tomas Hozza wrote: > ACK Pushed to master: 65de3f4d5718edf27899cf90389cb7cb15f5d725 > > Works as expected. > > Regards, > > Tomas Hozza > > ----- Original Message ----- >> Hello, >> >> Fix crash triggered by missing sasl_user parameter. >> >> -- >> Petr^2 Spacek >> -- Petr^2 Spacek From pspacek at redhat.com Mon Jun 3 08:51:38 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 03 Jun 2013 10:51:38 +0200 Subject: [Freeipa-devel] [PATCH 0161] Validate authentication settings strictly In-Reply-To: <1617278605.5857933.1370006509585.JavaMail.root@redhat.com> References: <51A5FE13.9080200@redhat.com> <1617278605.5857933.1370006509585.JavaMail.root@redhat.com> Message-ID: <51AC591A.20200@redhat.com> On 31.5.2013 15:21, Tomas Hozza wrote: > ACK. Pushed to master: d6d8e23e2a7a6e2d2b9d34e957d32f620edf96d0 > > Works OK. > > Regards, > > Tomas Hozza > > ----- Original Message ----- >> Hello, >> >> Validate authentication settings strictly. >> >> - auth_method 'SASL' do not accept bind_dn and password options >> - auth_method 'simple' do not accept sasl_* and krb5_* options >> - auth_method 'none' do not accept any of options above >> >> -- >> Petr^2 Spacek >> -- Petr^2 Spacek From pspacek at redhat.com Mon Jun 3 08:51:44 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 03 Jun 2013 10:51:44 +0200 Subject: [Freeipa-devel] [PATCH 0159] Deprecate configuration without persistent search In-Reply-To: <1638001085.5875003.1370008887189.JavaMail.root@redhat.com> References: <51A4B764.7040301@redhat.com> <51A61BB6.4080406@redhat.com> <1638001085.5875003.1370008887189.JavaMail.root@redhat.com> Message-ID: <51AC5920.8010000@redhat.com> On 31.5.2013 16:01, Tomas Hozza wrote: > ACK. Pushed to master: 7b685ff7077d10c1917c5a9a97b50d77587b8f04 > > Looks good. > > Regards, > > Tomas Hozza > > ----- Original Message ----- >> On 28.5.2013 15:55, Petr Spacek wrote: >>> Hello, >>> >>> Deprecate configuration without persistent search. >>> >>> https://fedorahosted.org/bind-dyndb-ldap/ticket/120 >> >> This version of the patch adds notice to the README. >> >> -- >> Petr^2 Spacek >> -- Petr^2 Spacek From mkosek at redhat.com Mon Jun 3 11:05:45 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 03 Jun 2013 13:05:45 +0200 Subject: [Freeipa-devel] Announcing FreeIPA 3.1.5 Message-ID: <51AC7889.7010901@redhat.com> The FreeIPA team is proud to announce version FreeIPA v3.1.5. It can be downloaded from http://www.freeipa.org/page/Downloads. The new version has also been built for Fedora 18 and is on its way to updates-testing: https://admin.fedoraproject.org/updates/freeipa-3.1.5-1.fc18 == Highlights in 3.1.5 == === Bug fixes === * Directory Server CLDAP responder now returns a result in all cases to avoid timeouts or freezes with Windows DC or other tools probing this interface. == 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-users mailing list: http://www.redhat.com/mailman/listinfo/freeipa-users == Detailed Changelog since 3.1.4 == Alexander Bokovoy (1) * Fix cldap parser to work with a single equality filter (NtVer=...) Martin Kosek (1): * Become IPA 3.1.5 Petr Viktorin (1): * Remove leading zero from IPA_NUM_VERSION Simo Sorce (2): * CLDAP: Fix domain handling in netlogon requests * CLDAP: Return empty reply on non-fatal errors From tbabej at redhat.com Mon Jun 3 11:10:10 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 03 Jun 2013 13:10:10 +0200 Subject: [Freeipa-devel] [PATCH 0064] Do not check userPassword with 7-bit plugin Message-ID: <51AC7992.1010806@redhat.com> Hi, Default list of attributes that are checked with 7-bit plugin for being 7-bit clean includes userPassword. Consecutively, one is unable to set passwords that contain non-ascii characters. https://fedorahosted.org/freeipa/ticket/3640 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0064-Do-not-check-userPassword-with-7-bit-plugin.patch Type: text/x-patch Size: 1562 bytes Desc: not available URL: From jcholast at redhat.com Mon Jun 3 11:32:23 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 03 Jun 2013 13:32:23 +0200 Subject: [Freeipa-devel] [PATCH 0064] Do not check userPassword with 7-bit plugin In-Reply-To: <51AC7992.1010806@redhat.com> References: <51AC7992.1010806@redhat.com> Message-ID: <51AC7EC7.70704@redhat.com> Hi, On 3.6.2013 13:10, Tomas Babej wrote: > Hi, > > Default list of attributes that are checked with 7-bit plugin > for being 7-bit clean includes userPassword. Consecutively, one > is unable to set passwords that contain non-ascii characters. > > https://fedorahosted.org/freeipa/ticket/3640 > > Tomas > what is the idea behind this: +replace:nsslapd-pluginarg2:userpassword::mail why not use remove instead of replace? Also please add the missing newline at the end of the update file. Honza -- Jan Cholasta From pviktori at redhat.com Mon Jun 3 12:05:09 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 03 Jun 2013 14:05:09 +0200 Subject: [Freeipa-devel] [RFE] Integration testing Message-ID: <51AC8675.6050600@redhat.com> Hello, A design document for integration testing is available at http://www.freeipa.org/page/V3/Integration_testing. I've copied it below for easier quoting. __NOTOC__ = Overview = Make it possible to write and run multi-host integration tests (such as: install master & replica, add user on replica, verify it's added on master). These tests will be run from continuous integration. Any developer can also run them manually. = Use Cases = == Continuous integration == The developer team at Red Hat will run a Jenkins continuous integration server that will run the tests automatically (after each commit if resources are available). The CI results will be posted publicly. == Developer testing == Anyone is be able to run integration tests without advanced infrastructure, only a number of virtual machines to run the tests on is needed. == Beaker integration == The tests will run seamlessly inside [http://beaker-project.org/ Beaker]/[https://fedoraproject.org/wiki/QA/RHTS RHTS]. A special option enables reporting via BeakerLib. = Non-goals = A complete testing/continuous integration setup needs some steps that will not be included in IPA's test suite: * Building the code * VM provisioning * Configuring the basic system, installing the packages = Design= The Python package with the IPA test suite is renamed to ipatests, and packaged for RPM-based systems as freeipa-tests. Eventually the package will be included in Fedora. Integration tests will be controlled from a single machine, and executed on a number of "remote" machines that act as servers, replicas, clients, etc. The controlling machine communicates with the others via the SSH protocol. (The controlling machine may be the same as one of the "remote" ones.) Integration tests are included in the main IPA set suite, and configured using environment variables. If the variables are missing, all integration tests are skipped. If an insufficient number of hosts is configured for a test, the individiual test will be skipped. A tool is provided to run installed tests. The remote machines used for integration testing are required to have relevant IPA packages installed, firewall opened up, any needed workarounds applied (RPM downgrades, SELinux mode,...), and sshd set up to allow root login. The test runner will connect to these machines, install IPA, perform the tests, and then uninstall IPA & return the systems to their previous state. A plugin for integration with BeakerLib is provided. = Test configuration = Tests are configured using these environment variables. == Host configuration == ; $MASTER : FQDN of the first IPA server ; $REPLICA : FQDNs of other IPA servers (space-separated) ; $CLIENT : FQDNs of IPA clients (space-separated) ; $MASTER_env2, $REPLICA_env2, $CLIENT_env2, $MASTER_env3, ... : can be used for additional domains when needed DNS needs to be set up so that IP addresses can be obtained for these hosts. == Basic configuration == ; $IPATEST_DIR : Directory for test data on the remote hosts : Default: /root/ipatests ; $DNSFORWARD : IP of a DNS forwarder : Default: 8.8.8.8 == Test customization == ; $DOMAIN : IPA domain name : Default: taken from $MASTER ; $NISDOMAIN : NIS domain name : Default: ipatest ; $NTPSERVER : NIS domain name : Default: ipatest ; $IPv6SETUP : Set to TRUE for IPv6-only connectivity ; $IPADEBUG : Set to enable test debugging ; $ADMINID : Admin username : Default: admin ; $ADMINPW : Admin user password : Default: Secret123 ; $ROOTDN : Directory manager DN : Default: cn=Directory Manager ; $ROOTDNPWD : Directory manager password : Default: Secret123 = Supporting tools = == ipa-test-config == This tool reads the configuration variables above and outputs a Bash script that sets a much more complete set of variables for easy shell-based testing or test set-up. Without arguments, ipa-test-config outputs information specific to the host it is run on. When given a hostname, it prints config for that host. With the --global flag, it outputs configuration common to all hosts. == ipa-run-tests == This tool is a wrapper arount nosetests and accepts the same arguments as Nose. It loads any additional plugins and runs tests from the system-installed IPA test suite. == Other == TBD: Additional command-line tools may be provided for tasks such as installing IPA in a given topology. = Implementation = Test cases are implemented as Nose test classes, with installation/uninstallation as class setup/teardown. A BeakerLib plugin is provided that starts/ends Beaker phases for Nose test contexts and cases, issues a Beaker assertion (rlPass/rlFail) for each test case, and collects and submits relevant logs. A separate plugin will be provided to collect logs outside of a Beaker environment. = Example instructions = To run the test called test_integration/test_simple_replication.py, which needs to run with two masters, follow these instructions. Install the IPA server packages on two machines, and do any preparations necessary to install IPA (e.g. configure/disable the firewall). Then, install the freeipa-tests package on the machine that will run the tests (this may be one of the machines above, or preferably a different one). Set MASTER and REPLICA environment variables to the fully qualified hostnames of the two machines prepared earlier. Also set any other relevant variables listed in [[#Test configuration|Test configuration]]. You may run ipa-test-config --global to verify how the test configuration will be handled. The next steps depend on whether the test will run within a BeakerLib session or not. == With BeakerLib == Set up a BeakerLib test (e.g. rlJournalStart), and run: ipa-run-tests --with-beakerlib --no-skip test_integration/test_simple_replication.py The output is somewhat messy as BeakerLib logs are printed to standard error. Not that output from external hosts is buffered, so installation may appear hung. Archive any relevant data (e.g. with rlJournalPrintText), and end the BeakerLib session (rlJournalEnd). == Without BeakerLib == Run: ipa-run-tests test_integration/test_simple_replication.py As with other Nose tests, no output is shown for test setup (installation) if nothing goes wrong, so there may be a long time without output. A summary is printed at the end of the test run. = Feature Managment = === UI === N/A === CLI === See above = Major configuration options and enablement = See instructions above. = Replication = N/A = Updates and Upgrades = N/A (Note: The tests can theoretically be used to drive hosts with other versions of IPA packages to test backward/forward compatibility.) = Dependencies = The freeipa-test package will depend on some libraries that are already used for unit tests and other test-related tasks: * python-nose * python-paste * python-coverage * python-polib Integration testing brings in a dependency on a library for the SSH protocol: * python-paramiko Naturally, the new dependencies are not needed in a production environment. = External Impact = Cooperation with QE is underway. = Design author = [[User:pviktorin|Petr Viktorin]] -- Petr? From tbabej at redhat.com Mon Jun 3 12:43:39 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 03 Jun 2013 14:43:39 +0200 Subject: [Freeipa-devel] [PATCH 0065] Use private ccache in ipa-server-install Message-ID: <51AC8F7B.4090408@redhat.com> Hi, this patch fixes the installation problems on master on F19 with krb5 packages >= 1.11.2-6 https://fedorahosted.org/freeipa/ticket/3666 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0065-Use-private-ccache-in-ipa-server-install.patch Type: text/x-patch Size: 1572 bytes Desc: not available URL: From mkosek at redhat.com Mon Jun 3 12:55:06 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 03 Jun 2013 14:55:06 +0200 Subject: [Freeipa-devel] [PATCH 0064] Do not check userPassword with 7-bit plugin In-Reply-To: <51AC7EC7.70704@redhat.com> References: <51AC7992.1010806@redhat.com> <51AC7EC7.70704@redhat.com> Message-ID: <51AC922A.2080604@redhat.com> On 06/03/2013 01:32 PM, Jan Cholasta wrote: > Hi, > > On 3.6.2013 13:10, Tomas Babej wrote: >> Hi, >> >> Default list of attributes that are checked with 7-bit plugin >> for being 7-bit clean includes userPassword. Consecutively, one >> is unable to set passwords that contain non-ascii characters. >> >> https://fedorahosted.org/freeipa/ticket/3640 >> >> Tomas >> > > what is the idea behind this: > > +replace:nsslapd-pluginarg2:userpassword::mail > > why not use remove instead of replace? Because of https://fedorahosted.org/389/ticket/47370, I found - DS would crash. In this update, I would like to operate only with this one attribute to avoid shifting the whole nsslapd-pluginargX array if we chose to remove nsslapd-pluginarg2. I thought that the safest approach would be to simply replace nsslapd-pluginarg2 with an already checked value, thus creating a safe NOOP. But I am open to other values leading to not checking userPassword attribute + changing nsslapd-pluginarg2 only. Martin From jcholast at redhat.com Mon Jun 3 12:59:52 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 03 Jun 2013 14:59:52 +0200 Subject: [Freeipa-devel] [PATCH 0064] Do not check userPassword with 7-bit plugin In-Reply-To: <51AC922A.2080604@redhat.com> References: <51AC7992.1010806@redhat.com> <51AC7EC7.70704@redhat.com> <51AC922A.2080604@redhat.com> Message-ID: <51AC9348.6000002@redhat.com> On 3.6.2013 14:55, Martin Kosek wrote: > On 06/03/2013 01:32 PM, Jan Cholasta wrote: >> Hi, >> >> On 3.6.2013 13:10, Tomas Babej wrote: >>> Hi, >>> >>> Default list of attributes that are checked with 7-bit plugin >>> for being 7-bit clean includes userPassword. Consecutively, one >>> is unable to set passwords that contain non-ascii characters. >>> >>> https://fedorahosted.org/freeipa/ticket/3640 >>> >>> Tomas >>> >> >> what is the idea behind this: >> >> +replace:nsslapd-pluginarg2:userpassword::mail >> >> why not use remove instead of replace? > > Because of https://fedorahosted.org/389/ticket/47370, I found - DS would crash. > > In this update, I would like to operate only with this one attribute to avoid > shifting the whole nsslapd-pluginargX array if we chose to remove > nsslapd-pluginarg2. > > I thought that the safest approach would be to simply replace > nsslapd-pluginarg2 with an already checked value, thus creating a safe NOOP. > But I am open to other values leading to not checking userPassword attribute + > changing nsslapd-pluginarg2 only. > > Martin > I see. Anyway, I think there should be a comment in the update file explaining why replace is necessary. -- Jan Cholasta From mkosek at redhat.com Mon Jun 3 12:58:56 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 03 Jun 2013 14:58:56 +0200 Subject: [Freeipa-devel] [PATCH 0065] Use private ccache in ipa-server-install In-Reply-To: <51AC8F7B.4090408@redhat.com> References: <51AC8F7B.4090408@redhat.com> Message-ID: <51AC9310.2090900@redhat.com> On 06/03/2013 02:43 PM, Tomas Babej wrote: > Hi, > > this patch fixes the installation problems on master on F19 with krb5 packages >>= 1.11.2-6 > > https://fedorahosted.org/freeipa/ticket/3666 > > Tomas 1) Leaving cache_desc open: + (cache_desc, cache_path) = tempfile.mkstemp(prefix='krbcc') + os.environ['KRB5CCNAME'] = cache_path Why do we keep the descriptor open and close it at the and of the installation? Can we close it right after tempfile.mkstemp? I think we do it this way in other places in installation. 2) What about other installers where we handle Kerberos auth, like ipa-{replica,dns,ca}-install? A common function, other shared means, of handling KRB5CCNAME may be appropriate to avoid duplicating code too much. Martin From tbabej at redhat.com Mon Jun 3 13:07:56 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 03 Jun 2013 15:07:56 +0200 Subject: [Freeipa-devel] [PATCH 0064] Do not check userPassword with 7-bit plugin In-Reply-To: <51AC7992.1010806@redhat.com> References: <51AC7992.1010806@redhat.com> Message-ID: <51AC952C.5060607@redhat.com> On 06/03/2013 01:10 PM, Tomas Babej wrote: > Hi, > > Default list of attributes that are checked with 7-bit plugin > for being 7-bit clean includes userPassword. Consecutively, one > is unable to set passwords that contain non-ascii characters. > > https://fedorahosted.org/freeipa/ticket/3640 > > Tomas Proper explanation and missing newline added. Updated patch attached. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0064-2-Do-not-check-userPassword-with-7-bit-plugin.patch Type: text/x-patch Size: 1754 bytes Desc: not available URL: From sbose at redhat.com Mon Jun 3 13:32:05 2013 From: sbose at redhat.com (Sumit Bose) Date: Mon, 3 Jun 2013 15:32:05 +0200 Subject: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts In-Reply-To: <20130528115059.GS26689@redhat.com> References: <20130528115059.GS26689@redhat.com> Message-ID: <20130603133205.GE3487@localhost.localdomain> On Tue, May 28, 2013 at 02:50:59PM +0300, Alexander Bokovoy wrote: > Hi, > > > http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts > > > === CLI === > > The feature is not directly exposed in CLI. > > IPA idrange management is expanded to specify idrange type (IPA local, > AD trust, AD with winsync, IPA trust, ..) to affect the way how AD users > SIDs are mapped to POSIX IDs. > Hi, currently with algorithmic mapping we use user-private groups for all trusted user. This is in agreement with the defaults for IPA users and also matches with AD's RID handling because a single namespace for UIDs and GIDs is forced this way. When adding support for UIDs and GIDs stored in AD we cannot do this anymore because AD (correctly) treats POSIX UIDs and GIDs as separate name spaces. As a consequence SSSD has to treat algorithmic mapping and IDs-in-AD mapping differently with respect to user private groups. My question is, shall SSSD implicitly do the right thing based on the type of the idrange, or shall there be an extra attribute in the idrange object which explicitly says if the range has user private groups or not? I think it is not needed because for both current mappings there is only one choice but maybe someone can think of a reason for such an attribute. bye, Sumit From sbose at redhat.com Mon Jun 3 13:39:09 2013 From: sbose at redhat.com (Sumit Bose) Date: Mon, 3 Jun 2013 15:39:09 +0200 Subject: [Freeipa-devel] [PATCH] Fix format string typo Message-ID: <20130603133909.GF3487@localhost.localdomain> Hi, this patch just fixes a typo. bye, Sumit -------------- next part -------------- From b4bf2704175de6ddf961e7447c57c5ced8cc0c5a Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Mon, 3 Jun 2013 14:05:03 +0200 Subject: [PATCH] Fix format string typo --- daemons/ipa-slapi-plugins/ipa-sidgen/ipa_sidgen_common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/daemons/ipa-slapi-plugins/ipa-sidgen/ipa_sidgen_common.c b/daemons/ipa-slapi-plugins/ipa-sidgen/ipa_sidgen_common.c index d7e6ac39a57ce26cf6ac7196a1797c44e5a65f77..fafc55a497620024e45186b48ed84029e273f5ef 100644 --- a/daemons/ipa-slapi-plugins/ipa-sidgen/ipa_sidgen_common.c +++ b/daemons/ipa-slapi-plugins/ipa-sidgen/ipa_sidgen_common.c @@ -518,7 +518,7 @@ int find_sid_for_ldap_entry(struct slapi_entry *entry, ret = find_sid_for_id(id, plugin_id, base_dn, dom_sid, ranges, &sid); if (ret != 0) { - LOG_FATAL("Cannot convert Posix ID [%ul] into an unused SID.\n", id); + LOG_FATAL("Cannot convert Posix ID [%lu] into an unused SID.\n", id); goto done; } -- 1.8.1.4 From mkosek at redhat.com Mon Jun 3 13:41:46 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 03 Jun 2013 15:41:46 +0200 Subject: [Freeipa-devel] [PATCH] Fix format string typo In-Reply-To: <20130603133909.GF3487@localhost.localdomain> References: <20130603133909.GF3487@localhost.localdomain> Message-ID: <51AC9D1A.4070906@redhat.com> On 06/03/2013 03:39 PM, Sumit Bose wrote: > Hi, > > this patch just fixes a typo. > > bye, > Sumit > Obvious ACK. Pushed to master, ipa-3-2. Martin From abokovoy at redhat.com Mon Jun 3 13:57:13 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 3 Jun 2013 16:57:13 +0300 Subject: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts In-Reply-To: <1370014932.2769.200.camel@willson.li.ssimo.org> References: <51A6084A.7050500@redhat.com> <20130530090102.GC1945@localhost.localdomain> <20130530114020.GP26689@redhat.com> <51A7E429.7090704@redhat.com> <20130531075453.GS26689@redhat.com> <1370006962.2769.196.camel@willson.li.ssimo.org> <20130531133508.GT26689@redhat.com> <1370009874.2769.199.camel@willson.li.ssimo.org> <51A8B524.5070303@redhat.com> <1370014932.2769.200.camel@willson.li.ssimo.org> Message-ID: <20130603135713.GX26689@redhat.com> On Fri, 31 May 2013, Simo Sorce wrote: >On Fri, 2013-05-31 at 10:35 -0400, Rob Crittenden wrote: >> Simo Sorce wrote: >> > On Fri, 2013-05-31 at 16:35 +0300, Alexander Bokovoy wrote: >> >> On Fri, 31 May 2013, Simo Sorce wrote: >> >>> On Fri, 2013-05-31 at 10:54 +0300, Alexander Bokovoy wrote: >> >>>> On Thu, 30 May 2013, Dmitri Pal wrote: >> >>>>> [...] >> >>>>>>>> >> >>>>>>>> For Lunix and older SSSD version we in fact have a problem. >> >>>>>>>> What I want to avoid is to have to define procedures and patches for >> >>>>>>>> all >> >>>>>>> ^^^^^^ ? >> >>>>>>>> the clients. However if you use ipa-client-install it would configure >> >>>>>>>> sssd the old way. >> >>>>>>>> How to make it configured the new way? Manually? This is error prone >> >>>>>>>> and >> >>>>>>>> people will be reluctant to reconfigure SSSD. Automatically? Means >> >>>>>>>> patches to all the versions of the clients. >> >>>>>>>> How we are going to deal with the huge test matrix? >> >>>>>>> >> >>>>>>> I think rolling out patches to old sssd versions is not a good idea and >> >>>>>>> I think we won't have the time to prepare all the needed patches in a >> >>>>>>> reasonable time-frame. >> >>>>>>> >> >>>>>>> For SSSD versions which do not allow multiple search bases (1.5 and 1.6) >> >>>>>>> I would suggest to add a new domain section for the AD user with LDAP >> >>>>>>> and Kerberos provider. This would allow IPA users to works as before and >> >>>>>>> add the AD users to the client. Maybe this would also be a better >> >>>>>>> solution for the other SSSD versions instead of multiple search bases, >> >>>>>>> at least it's a solution for all versions. >> >>>>>>> >> >>>>>>> Since we have the python config API for SSSD the needed changes to the >> >>>>>>> sssd.conf might be scriptable with a reasonable effort. Maybe this can >> >>>>>>> be added to ipa-client-install with a new option like >> >>>>>>> --enable-legacy-trust-support which can add the news section to existing >> >>>>>>> configuration or include it for new installations? >> >>>>>> Bigger question is what is simpler: write configuration instructions or >> >>>>>> modify/provide additional script for old SSSD? >> >>>>>> >> >>>>>> Remeber that trusts with AD are most likely established when IPA clients >> >>>>>> are already rolled out. Changing ipa-client-install is not helpful for >> >>>>>> this case since the clients are already there. >> >>>>>> >> >>>>>> Perhaps a better approach would be documentation for non-SSSD case and a >> >>>>>> simple snippet that can be run alone or in use with puppet/etc to deploy >> >>>>>> massively. The snippet would use SSSDConfig Python API to add needed >> >>>>>> modifications to the clients' SSSD configuration. >> >>>>>> >> >>>>>> We can even extend IPA server tools to allow generating such snippets >> >>>>>> based on the trusts configuration. After all, we do have control over >> >>>>>> IPA server in such cases. >> >>>>>> >> >>>>>> >> >>>>>> I have updated wiki page with discussed ideas. >> >>>>> >> >>>>> Sorry but this is not enough. >> >>>>> I do not see a discussion the design about the client side solutuon >> >>>>> procedure. >> >>>>> >> >>>>> I am looking for a session that would contain a table (or like): >> >>>>> >> >>>>> -------------------------------------------------------------------------- >> >>>>> | Type/Version of the client | Action | >> >>>>> -------------------------------------------------------------------------- >> >>>>> | Solaris/HP-UX/AIX (non sssd) | Configure manually to recognize AD as | >> >>>>> | | a domain following following steps ...| >> >>>>> -------------------------------------------------------------------------- >> >>>>> | Clients that have SSSD | If the client is already installed | >> >>>>> | before 1.9 | and configured do X | >> >>>>> | | If it is a fresh install of the | >> >>>>> | | client do Y | >> >>>>> -------------------------------------------------------------------------- >> >>>>> | SSSD 1.9 and later | Use the following ipa-client-install | >> >>>>> | | flags XYZ and/or authconfig command | >> >>>>> | | ABC | >> >>>>> -------------------------------------------------------------------------- >> >>>>> >> >>>>> Can something like this be added to wiki and corresponding tickets to provide a testable >> >>>>> replacements for XYZ above be filed in trac? >> >>>> I've added more, including three tickets to cover specific >> >>>> configurations. >> >>>> >> >>>> Unfortunately, we have limits in multiple search bases approach by >> >>>> the commercial UNIX vendors since their LDAP modules do not support >> >>>> multiple search bases. For all of those platforms there is PADL pam_ldap >> >>>> available which can be used for the same purpose. >> >>>> >> >>>> If we still want to support native pam_ldap on Solaris (which don't work >> >>>> with multiple search bases), we'd have to merge LDAP trees. >> >>> >> >>> Alexander, in my initial proposal I said that trusted users should be >> >>> put in the same tree as compat users, it was exactly to address this >> >>> problem. >> >>> >> >>> We do not need to cause more problems by using multiple search trees >> >>> IMO. >> >> Ok, since I wanted to re-use slapi-nis anyway, this only means adding >> >> one more config attribute to slapi-nis configuration that will ask it to >> >> look into NSS in addition to the main query. >> >> >> >> In which order these queries should be performed? first to LDAP then NSS >> >> or first to NSS then to LDAP? I guess the answer depends on specific >> >> setup -- if all your users in AD, you'd like to look at them first. >> > >> > If we cache stuff in memory I am not sure it matters much. >> >> Note that AFAIK there is no option in slapi-nis to look at nss. It is >> probably safe to assume that the sssd loop protection will suffice. >> >> This may be quite a change too, as slapi-nis won't be able to rely on >> watching for MOD to update itself and instead will need to be a >> general-purpose cache, or ALWAYS look up the entry (or entries) in nss >> and rely on the local sssd cache to prevent performance issues. > >My initial proposal was to always lookup via NSS and rely on sssd fast >cache to avoid costly operations, at least for individual lookups. >for enumerations it will be sorta expensive, but that is fine IMO. Ok. My current approach (I'm still reading through slapi-nis code) is to have another backend (in terms of slapi-nis) that is used by another plugin. We will configure it to expose the data to the same tree. It will probably require few changes in schema compatibility plugin to allow working over the same tree without returning 'not found' but other than that it should be pretty straight-forward. I've also updated wiki for the fact that we'll be using a single tree. -- / Alexander Bokovoy From tbabej at redhat.com Mon Jun 3 15:00:43 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 03 Jun 2013 17:00:43 +0200 Subject: [Freeipa-devel] [PATCHES 0061-0063] Extend ID range types Message-ID: <51ACAF9B.7040300@redhat.com> Hi, Sending rebased versions on top of current master. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0061-2-Add-ipaRangeType-attribute-to-LDAP-Schema.patch Type: text/x-patch Size: 5854 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0062-2-Add-update-plugin-to-fill-in-ipaRangeType-attribute.patch Type: text/x-patch Size: 6542 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0063-2-Extend-idrange-commands-to-support-new-range-origin-.patch Type: text/x-patch Size: 5899 bytes Desc: not available URL: From pspacek at redhat.com Mon Jun 3 15:08:30 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 03 Jun 2013 17:08:30 +0200 Subject: [Freeipa-devel] [PATCH 0162] Mark function arguments with __attribute__((nonnull)) when appropriate Message-ID: <51ACB16E.5090009@redhat.com> Hello, Mark function arguments with __attribute__((nonnull)) when appropriate. This patch prevents bugs like https://git.fedorahosted.org/cgit/bind-dyndb-ldap.git/commit/?id=65de3f4d5718edf27899cf90389cb7cb15f5d725 The patch seems big, but it is really trivial. I'm open to suggestions for better macro names etc. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0162-Mark-function-arguments-with-__attribute__-nonnull-w.patch Type: text/x-patch Size: 45267 bytes Desc: not available URL: From akrivoka at redhat.com Mon Jun 3 16:18:39 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 03 Jun 2013 18:18:39 +0200 Subject: [Freeipa-devel] [PATCH] 418 Make ssbrowser.html work in IE 10 In-Reply-To: <51A5E351.3000301@redhat.com> References: <51A5E351.3000301@redhat.com> Message-ID: <51ACC1DF.9040007@redhat.com> On 05/29/2013 01:15 PM, Petr Vobornik wrote: > Manual configuration page for other browsers (ssbrowser.html) doesn't > work in IE 10 - error page is displayed. > > This patch is conditioning creation of Firefox configuration object so > that configure.jar is requested only in Firefox. IE doesn't request it > and so it does not fail. > > https://fedorahosted.org/freeipa/ticket/3645 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Mon Jun 3 16:22:56 2013 From: sbose at redhat.com (Sumit Bose) Date: Mon, 3 Jun 2013 18:22:56 +0200 Subject: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts In-Reply-To: <20130603133205.GE3487@localhost.localdomain> References: <20130528115059.GS26689@redhat.com> <20130603133205.GE3487@localhost.localdomain> Message-ID: <20130603162256.GG3487@localhost.localdomain> On Mon, Jun 03, 2013 at 03:32:05PM +0200, Sumit Bose wrote: > On Tue, May 28, 2013 at 02:50:59PM +0300, Alexander Bokovoy wrote: > > Hi, > > > > > > http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts > > > > > > === CLI === > > > > The feature is not directly exposed in CLI. > > > > IPA idrange management is expanded to specify idrange type (IPA local, > > AD trust, AD with winsync, IPA trust, ..) to affect the way how AD users > > SIDs are mapped to POSIX IDs. > > > > Hi, > > currently with algorithmic mapping we use user-private groups for all > trusted user. This is in agreement with the defaults for IPA users and > also matches with AD's RID handling because a single namespace for UIDs > and GIDs is forced this way. > > When adding support for UIDs and GIDs stored in AD we cannot do this > anymore because AD (correctly) treats POSIX UIDs and GIDs as separate > name spaces. As a consequence SSSD has to treat algorithmic mapping and > IDs-in-AD mapping differently with respect to user private groups. > > My question is, shall SSSD implicitly do the right thing based on the > type of the idrange, or shall there be an extra attribute in the idrange > object which explicitly says if the range has user private groups or > not? > > I think it is not needed because for both current mappings there is only > one choice but maybe someone can think of a reason for such an > attribute. We discussed this a bit and came to the following agreement: - no extra attribute is needed - for all idranges type where IPA is assigning the ID user-private groups will be used (local IPA users, algorithmic mappings) - for all idranges where the IDs are managed by external sources we use what we get bye, Sumit > > bye, > Sumit > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From pviktori at redhat.com Tue Jun 4 08:49:45 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 04 Jun 2013 10:49:45 +0200 Subject: [Freeipa-devel] [PATCH] Fix format string typo In-Reply-To: <51AC9D1A.4070906@redhat.com> References: <20130603133909.GF3487@localhost.localdomain> <51AC9D1A.4070906@redhat.com> Message-ID: <51ADAA29.8040707@redhat.com> On 06/03/2013 03:41 PM, Martin Kosek wrote: > On 06/03/2013 03:39 PM, Sumit Bose wrote: >> Hi, >> >> this patch just fixes a typo. >> >> bye, >> Sumit >> > > Obvious ACK. Pushed to master, ipa-3-2. > > Martin Is the patch really right? It caused a new compiler warning: format '%lu' expects argument of type 'long unsigned int', but argument 6 has type 'uint32_t' [-Wformat=] -- Petr? From sbose at redhat.com Tue Jun 4 08:56:59 2013 From: sbose at redhat.com (Sumit Bose) Date: Tue, 4 Jun 2013 10:56:59 +0200 Subject: [Freeipa-devel] [PATCH] Fix format string typo In-Reply-To: <51ADAA29.8040707@redhat.com> References: <20130603133909.GF3487@localhost.localdomain> <51AC9D1A.4070906@redhat.com> <51ADAA29.8040707@redhat.com> Message-ID: <20130604085659.GK3487@localhost.localdomain> On Tue, Jun 04, 2013 at 10:49:45AM +0200, Petr Viktorin wrote: > On 06/03/2013 03:41 PM, Martin Kosek wrote: > >On 06/03/2013 03:39 PM, Sumit Bose wrote: > >>Hi, > >> > >>this patch just fixes a typo. > >> > >>bye, > >>Sumit > >> > > > >Obvious ACK. Pushed to master, ipa-3-2. > > > >Martin > > Is the patch really right? It caused a new compiler warning: > > format '%lu' expects argument of type 'long unsigned int', but > argument 6 has type 'uint32_t' [-Wformat=] ah, sorry, I didn't check the compiler output carefully enough, I'll send a fix. bye, Sumit > > -- > Petr? From pvoborni at redhat.com Tue Jun 4 10:26:46 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 04 Jun 2013 12:26:46 +0200 Subject: [Freeipa-devel] [PATCH] 418 Make ssbrowser.html work in IE 10 In-Reply-To: <51ACC1DF.9040007@redhat.com> References: <51A5E351.3000301@redhat.com> <51ACC1DF.9040007@redhat.com> Message-ID: <51ADC0E6.3010803@redhat.com> On 06/03/2013 06:18 PM, Ana Krivokapic wrote: > On 05/29/2013 01:15 PM, Petr Vobornik wrote: >> Manual configuration page for other browsers (ssbrowser.html) doesn't >> work in IE 10 - error page is displayed. >> >> This patch is conditioning creation of Firefox configuration object so >> that configure.jar is requested only in Firefox. IE doesn't request it >> and so it does not fail. >> >> https://fedorahosted.org/freeipa/ticket/3645>> > > ACK > > -- > Regards, > > Ana Krivokapic Pushed to master, ipa-3-2 -- Petr Vobornik From tbabej at redhat.com Tue Jun 4 11:29:14 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 04 Jun 2013 13:29:14 +0200 Subject: [Freeipa-devel] [PATCH 0065] Use private ccache in ipa-server-install In-Reply-To: <51AC9310.2090900@redhat.com> References: <51AC8F7B.4090408@redhat.com> <51AC9310.2090900@redhat.com> Message-ID: <51ADCF8A.1040506@redhat.com> On 06/03/2013 02:58 PM, Martin Kosek wrote: > On 06/03/2013 02:43 PM, Tomas Babej wrote: >> Hi, >> >> this patch fixes the installation problems on master on F19 with krb5 packages >>> = 1.11.2-6 >> https://fedorahosted.org/freeipa/ticket/3666 >> >> Tomas > 1) Leaving cache_desc open: > > + (cache_desc, cache_path) = tempfile.mkstemp(prefix='krbcc') > + os.environ['KRB5CCNAME'] = cache_path > > Why do we keep the descriptor open and close it at the and of the installation? > Can we close it right after tempfile.mkstemp? I think we do it this way in > other places in installation. > > 2) What about other installers where we handle Kerberos auth, like > ipa-{replica,dns,ca}-install? > > A common function, other shared means, of handling KRB5CCNAME may be > appropriate to avoid duplicating code too much. > > Martin I moved the code responsible to PrivateCCache class, both for readability and conciseness. Private ccache now used in replica,dns and ca the installers. I managed to reproduce the error only with dns-install though(fails on adding the service principal), but having a private ccache for the installer should not hurt. Ipa-adtrust-install requires the admin ticket, so there shouldn't be an issue. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0065-2-Use-private-ccache-in-ipa-server-install.patch Type: text/x-patch Size: 6302 bytes Desc: not available URL: From pviktori at redhat.com Tue Jun 4 11:48:23 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 04 Jun 2013 13:48:23 +0200 Subject: [Freeipa-devel] [PATCH] 0235 tests: Use ipa-getkeytab from /usr/sbin instead of the in-tree one Message-ID: <51ADD407.6020100@redhat.com> Hardcoding the in-tree location for ipa-getkeytab makes testing outside the source tree impossible. This patch makes the tests use the installed location. In other places the test suite assumes IPA is installed system-wide, even if running from the source tree. I know I frequently forget to run `make` before testing, which makes the ipa-getkeytab tests fail. So this patch would work well for me (and probably other Python devs), but I guess others might be used to `make test` checking what `make` built. C developers, are you OK with e.g. adding `cp ipa-client/ipa-getkeytab /usr/sbin/ipa-getkeytab` to your testing workflow? Or should this be made configurable (or auto-detected)? -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0235-tests-Use-ipa-getkeytab-from-usr-sbin-instead-of-the.patch Type: text/x-patch Size: 1154 bytes Desc: not available URL: From pviktori at redhat.com Tue Jun 4 11:51:15 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 04 Jun 2013 13:51:15 +0200 Subject: [Freeipa-devel] [PATCH] 0235 tests: Use ipa-getkeytab from /usr/sbin instead of the in-tree one In-Reply-To: <51ADD407.6020100@redhat.com> References: <51ADD407.6020100@redhat.com> Message-ID: <51ADD4B3.1060003@redhat.com> On 06/04/2013 01:48 PM, Petr Viktorin wrote: > Hardcoding the in-tree location for ipa-getkeytab makes testing outside > the source tree impossible. This patch makes the tests use the installed > location. > > In other places the test suite assumes IPA is installed system-wide, > even if running from the source tree. > I know I frequently forget to run `make` before testing, which makes the > ipa-getkeytab tests fail. So this patch would work well for me (and > probably other Python devs), but I guess others might be used to `make > test` checking what `make` built. > > C developers, are you OK with e.g. adding `cp ipa-client/ipa-getkeytab > /usr/sbin/ipa-getkeytab` to your testing workflow? Or should this be > made configurable (or auto-detected)? > I forgot to say: Apply this on top of my patches 0227-0229. -- Petr? From jpazdziora at redhat.com Tue Jun 4 12:09:33 2013 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Tue, 4 Jun 2013 14:09:33 +0200 Subject: [Freeipa-devel] [PATCH] 0235 tests: Use ipa-getkeytab from /usr/sbin instead of the in-tree one In-Reply-To: <51ADD407.6020100@redhat.com> References: <51ADD407.6020100@redhat.com> Message-ID: <20130604120933.GW31859@redhat.com> On Tue, Jun 04, 2013 at 01:48:23PM +0200, Petr Viktorin wrote: > Hardcoding the in-tree location for ipa-getkeytab makes testing > outside the source tree impossible. This patch makes the tests use > the installed location. > > In other places the test suite assumes IPA is installed system-wide, > even if running from the source tree. > I know I frequently forget to run `make` before testing, which makes > the ipa-getkeytab tests fail. So this patch would work well for me > (and probably other Python devs), but I guess others might be used > to `make test` checking what `make` built. > > C developers, are you OK with e.g. adding `cp > ipa-client/ipa-getkeytab /usr/sbin/ipa-getkeytab` to your testing > workflow? Or should this be made configurable (or auto-detected)? Will the environment running the test have access rights to do that copy operation? Can't you just use PATH value (let PATH do its work)? -- Jan Pazdziora | adelton at #ipa*, #brno Principal Software Engineer, Identity Management Engineering, Red Hat From pviktori at redhat.com Tue Jun 4 12:22:42 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 04 Jun 2013 14:22:42 +0200 Subject: [Freeipa-devel] [PATCH] 0235 tests: Use ipa-getkeytab from /usr/sbin instead of the in-tree one In-Reply-To: <20130604120933.GW31859@redhat.com> References: <51ADD407.6020100@redhat.com> <20130604120933.GW31859@redhat.com> Message-ID: <51ADDC12.6030208@redhat.com> On 06/04/2013 02:09 PM, Jan Pazdziora wrote: > On Tue, Jun 04, 2013 at 01:48:23PM +0200, Petr Viktorin wrote: >> Hardcoding the in-tree location for ipa-getkeytab makes testing >> outside the source tree impossible. This patch makes the tests use >> the installed location. >> >> In other places the test suite assumes IPA is installed system-wide, >> even if running from the source tree. >> I know I frequently forget to run `make` before testing, which makes >> the ipa-getkeytab tests fail. So this patch would work well for me >> (and probably other Python devs), but I guess others might be used >> to `make test` checking what `make` built. >> >> C developers, are you OK with e.g. adding `cp >> ipa-client/ipa-getkeytab /usr/sbin/ipa-getkeytab` to your testing >> workflow? Or should this be made configurable (or auto-detected)? > > Will the environment running the test have access rights to do that > copy operation? Yes. To set up any meaningful testing of IPA, you need root. > Can't you just use PATH value (let PATH do its work)? That's probably the easiest way to make it configurable. But ipa-client/ipa-getkeytab (the old value) is not normally in PATH so some workflow change would be necessary in this case, too. -- Petr? From simo at redhat.com Tue Jun 4 12:53:23 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 04 Jun 2013 08:53:23 -0400 Subject: [Freeipa-devel] [PATCH] 0235 tests: Use ipa-getkeytab from /usr/sbin instead of the in-tree one In-Reply-To: <51ADD407.6020100@redhat.com> References: <51ADD407.6020100@redhat.com> Message-ID: <1370350403.2744.15.camel@willson.li.ssimo.org> On Tue, 2013-06-04 at 13:48 +0200, Petr Viktorin wrote: > Hardcoding the in-tree location for ipa-getkeytab makes testing outside > the source tree impossible. This patch makes the tests use the installed > location. > > In other places the test suite assumes IPA is installed system-wide, > even if running from the source tree. > I know I frequently forget to run `make` before testing, which makes the > ipa-getkeytab tests fail. So this patch would work well for me (and > probably other Python devs), but I guess others might be used to `make > test` checking what `make` built. > > C developers, are you OK with e.g. adding `cp ipa-client/ipa-getkeytab > /usr/sbin/ipa-getkeytab` to your testing workflow? Absolutely not. > Or should this be made configurable (or auto-detected)? You must not break a machine just to do make test. I often do make test, then make rpms and install rpms, I *never* directly install on my development machine or VMs, I always go through RPM in order to keep the system clean, and tests repeatable. ipa-getkeytab specifically do not need root to be tested so I really do not see that copying over a system path would ever be a good idea. Simo. -- Simo Sorce * Red Hat, Inc * New York From thozza at redhat.com Tue Jun 4 14:26:09 2013 From: thozza at redhat.com (Tomas Hozza) Date: Tue, 4 Jun 2013 10:26:09 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0162] Mark function arguments with __attribute__((nonnull)) when appropriate In-Reply-To: <51ACB16E.5090009@redhat.com> References: <51ACB16E.5090009@redhat.com> Message-ID: <1829912745.6635598.1370355969346.JavaMail.root@redhat.com> ACK. The change looks reasonable and I'm not able to come up with a better macro name... :) Regards, Tomas Hozza ----- Original Message ----- > Hello, > > Mark function arguments with __attribute__((nonnull)) when appropriate. > > This patch prevents bugs like > https://git.fedorahosted.org/cgit/bind-dyndb-ldap.git/commit/?id=65de3f4d5718edf27899cf90389cb7cb15f5d725 > > The patch seems big, but it is really trivial. > > > I'm open to suggestions for better macro names etc. > > -- > Petr^2 Spacek > From rcritten at redhat.com Tue Jun 4 14:30:16 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 04 Jun 2013 10:30:16 -0400 Subject: [Freeipa-devel] [PATCH] 0235 tests: Use ipa-getkeytab from /usr/sbin instead of the in-tree one In-Reply-To: <51ADDC12.6030208@redhat.com> References: <51ADD407.6020100@redhat.com> <20130604120933.GW31859@redhat.com> <51ADDC12.6030208@redhat.com> Message-ID: <51ADF9F8.9060204@redhat.com> Petr Viktorin wrote: > On 06/04/2013 02:09 PM, Jan Pazdziora wrote: >> On Tue, Jun 04, 2013 at 01:48:23PM +0200, Petr Viktorin wrote: >>> Hardcoding the in-tree location for ipa-getkeytab makes testing >>> outside the source tree impossible. This patch makes the tests use >>> the installed location. >>> >>> In other places the test suite assumes IPA is installed system-wide, >>> even if running from the source tree. >>> I know I frequently forget to run `make` before testing, which makes >>> the ipa-getkeytab tests fail. So this patch would work well for me >>> (and probably other Python devs), but I guess others might be used >>> to `make test` checking what `make` built. >>> >>> C developers, are you OK with e.g. adding `cp >>> ipa-client/ipa-getkeytab /usr/sbin/ipa-getkeytab` to your testing >>> workflow? Or should this be made configurable (or auto-detected)? >> >> Will the environment running the test have access rights to do that >> copy operation? > > Yes. To set up any meaningful testing of IPA, you need root. > >> Can't you just use PATH value (let PATH do its work)? > > That's probably the easiest way to make it configurable. > But ipa-client/ipa-getkeytab (the old value) is not normally in PATH so > some workflow change would be necessary in this case, too. > Testing has bit in a bit split-brain since the beginning. We initially did all testing using the lite-server. That seems to have fallen by the way-side recently. The traditional route was to install IPA, mostly to get Kerberos and 389-ds running, then to test changes/code in the local tree before committing/submitting upstream. This is the reason that the local ipa-getkeytab is used, for example, to make it easier to test changes without having to reinstall. rob From pviktori at redhat.com Tue Jun 4 14:58:04 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 04 Jun 2013 16:58:04 +0200 Subject: [Freeipa-devel] [PATCH] 0235 tests: Use ipa-getkeytab from /usr/sbin instead of the in-tree one In-Reply-To: <51ADF9F8.9060204@redhat.com> References: <51ADD407.6020100@redhat.com> <20130604120933.GW31859@redhat.com> <51ADDC12.6030208@redhat.com> <51ADF9F8.9060204@redhat.com> Message-ID: <51AE007C.1090608@redhat.com> On 06/04/2013 04:30 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 06/04/2013 02:09 PM, Jan Pazdziora wrote: >>> On Tue, Jun 04, 2013 at 01:48:23PM +0200, Petr Viktorin wrote: >>>> Hardcoding the in-tree location for ipa-getkeytab makes testing >>>> outside the source tree impossible. This patch makes the tests use >>>> the installed location. >>>> >>>> In other places the test suite assumes IPA is installed system-wide, >>>> even if running from the source tree. >>>> I know I frequently forget to run `make` before testing, which makes >>>> the ipa-getkeytab tests fail. So this patch would work well for me >>>> (and probably other Python devs), but I guess others might be used >>>> to `make test` checking what `make` built. >>>> >>>> C developers, are you OK with e.g. adding `cp >>>> ipa-client/ipa-getkeytab /usr/sbin/ipa-getkeytab` to your testing >>>> workflow? Or should this be made configurable (or auto-detected)? >>> >>> Will the environment running the test have access rights to do that >>> copy operation? >> >> Yes. To set up any meaningful testing of IPA, you need root. >> >>> Can't you just use PATH value (let PATH do its work)? >> >> That's probably the easiest way to make it configurable. >> But ipa-client/ipa-getkeytab (the old value) is not normally in PATH so >> some workflow change would be necessary in this case, too. >> > > Testing has bit in a bit split-brain since the beginning. We initially > did all testing using the lite-server. That seems to have fallen by the > way-side recently. I still use the lite-server for testing. I'm not brave enough to try extracting coverage info from mod_wsgi. > The traditional route was to install IPA, mostly to get Kerberos and > 389-ds running, then to test changes/code in the local tree before > committing/submitting upstream. This is the reason that the local > ipa-getkeytab is used, for example, to make it easier to test changes > without having to reinstall. It's my impression that everyone runs the tests differently. Well, at least more bugs should be found that way. I'll send a patch that uses $PATH as soon as I test it. -- Petr? From pspacek at redhat.com Tue Jun 4 15:05:55 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 04 Jun 2013 17:05:55 +0200 Subject: [Freeipa-devel] [PATCH 0162] Mark function arguments with __attribute__((nonnull)) when appropriate In-Reply-To: <1829912745.6635598.1370355969346.JavaMail.root@redhat.com> References: <51ACB16E.5090009@redhat.com> <1829912745.6635598.1370355969346.JavaMail.root@redhat.com> Message-ID: <51AE0253.5010001@redhat.com> On 4.6.2013 16:26, Tomas Hozza wrote: > ACK. Pushed to master: ab6c6a889eedaceb5a23be82f0a0df574365f0be > > The change looks reasonable and I'm not able to come up with > a better macro name... :) > > Regards, > > Tomas Hozza > > ----- Original Message ----- >> Hello, >> >> Mark function arguments with __attribute__((nonnull)) when appropriate. >> >> This patch prevents bugs like >> https://git.fedorahosted.org/cgit/bind-dyndb-ldap.git/commit/?id=65de3f4d5718edf27899cf90389cb7cb15f5d725 >> >> The patch seems big, but it is really trivial. >> >> >> I'm open to suggestions for better macro names etc. >> >> -- >> Petr^2 Spacek >> -- Petr^2 Spacek From pspacek at redhat.com Tue Jun 4 15:07:40 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 04 Jun 2013 17:07:40 +0200 Subject: [Freeipa-devel] [PATCH 0164] Bump NVR to 3.3 Message-ID: <51AE02BC.60600@redhat.com> Hello, Bump NVR to 3.3. Pushed to master: c7bf64b99cb85d814a7d919a0684fd20d749d019 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0164-Bump-NVR-to-3.3.patch Type: text/x-patch Size: 1196 bytes Desc: not available URL: From pspacek at redhat.com Tue Jun 4 15:07:49 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 04 Jun 2013 17:07:49 +0200 Subject: [Freeipa-devel] [PATCH 0163] Update NEWS file for upcoming 3.3 release Message-ID: <51AE02C5.2010608@redhat.com> Hello, Update NEWS file for upcoming 3.3 release. Pushed to master: 55b3e679a6d1f0f0800577f6996d96b1b63cc7b6 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0163-Update-NEWS-file-for-upcoming-3.3-release.patch Type: text/x-patch Size: 1333 bytes Desc: not available URL: From pviktori at redhat.com Tue Jun 4 15:24:21 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 04 Jun 2013 17:24:21 +0200 Subject: [Freeipa-devel] [PATCH] 0235 tests: Use ipa-getkeytab from /usr/sbin instead of the in-tree one In-Reply-To: <1370350403.2744.15.camel@willson.li.ssimo.org> References: <51ADD407.6020100@redhat.com> <1370350403.2744.15.camel@willson.li.ssimo.org> Message-ID: <51AE06A5.4030301@redhat.com> On 06/04/2013 02:53 PM, Simo Sorce wrote: > On Tue, 2013-06-04 at 13:48 +0200, Petr Viktorin wrote: >> Hardcoding the in-tree location for ipa-getkeytab makes testing outside >> the source tree impossible. This patch makes the tests use the installed >> location. >> >> In other places the test suite assumes IPA is installed system-wide, >> even if running from the source tree. >> I know I frequently forget to run `make` before testing, which makes the >> ipa-getkeytab tests fail. So this patch would work well for me (and >> probably other Python devs), but I guess others might be used to `make >> test` checking what `make` built. >> >> C developers, are you OK with e.g. adding `cp ipa-client/ipa-getkeytab >> /usr/sbin/ipa-getkeytab` to your testing workflow? > > Absolutely not. > >> Or should this be made configurable (or auto-detected)? > > You must not break a machine just to do make test. > > I often do make test, then make rpms and install rpms, I *never* > directly install on my development machine or VMs, I always go through > RPM in order to keep the system clean, and tests repeatable. I do the same except I never run make test on the development machine -- without IPA installed the tests don't work. > ipa-getkeytab specifically do not need root to be tested so I really do > not see that copying over a system path would ever be a good idea. > > Simo. With this version of the patch, the tests use ipa-getkeytab from $PATH, and the in-tree directory is added to PATH in make-test. Out-of-tree tests don't use make-test so they will use the system PATH. Is that OK? -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0235.2-Do-not-hardcode-path-to-ipa-getkeytab-in-tests.patch Type: text/x-patch Size: 3287 bytes Desc: not available URL: From simo at redhat.com Tue Jun 4 15:48:22 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 04 Jun 2013 11:48:22 -0400 Subject: [Freeipa-devel] [PATCH] 0235 tests: Use ipa-getkeytab from /usr/sbin instead of the in-tree one In-Reply-To: <51AE06A5.4030301@redhat.com> References: <51ADD407.6020100@redhat.com> <1370350403.2744.15.camel@willson.li.ssimo.org> <51AE06A5.4030301@redhat.com> Message-ID: <1370360902.2744.40.camel@willson.li.ssimo.org> On Tue, 2013-06-04 at 17:24 +0200, Petr Viktorin wrote: > On 06/04/2013 02:53 PM, Simo Sorce wrote: > > On Tue, 2013-06-04 at 13:48 +0200, Petr Viktorin wrote: > >> Hardcoding the in-tree location for ipa-getkeytab makes testing outside > >> the source tree impossible. This patch makes the tests use the installed > >> location. > >> > >> In other places the test suite assumes IPA is installed system-wide, > >> even if running from the source tree. > >> I know I frequently forget to run `make` before testing, which makes the > >> ipa-getkeytab tests fail. So this patch would work well for me (and > >> probably other Python devs), but I guess others might be used to `make > >> test` checking what `make` built. > >> > >> C developers, are you OK with e.g. adding `cp ipa-client/ipa-getkeytab > >> /usr/sbin/ipa-getkeytab` to your testing workflow? > > > > Absolutely not. > > > >> Or should this be made configurable (or auto-detected)? > > > > You must not break a machine just to do make test. > > > > I often do make test, then make rpms and install rpms, I *never* > > directly install on my development machine or VMs, I always go through > > RPM in order to keep the system clean, and tests repeatable. > > I do the same except I never run make test on the development machine -- > without IPA installed the tests don't work. > > > ipa-getkeytab specifically do not need root to be tested so I really do > > not see that copying over a system path would ever be a good idea. > > > > Simo. > > > With this version of the patch, the tests use ipa-getkeytab from $PATH, > and the in-tree directory is added to PATH in make-test. Out-of-tree > tests don't use make-test so they will use the system PATH. > Is that OK? > Sounds good to me. Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Tue Jun 4 16:09:45 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 04 Jun 2013 18:09:45 +0200 Subject: [Freeipa-devel] [PATCH 0065] Use private ccache in ipa-server-install In-Reply-To: <51ADCF8A.1040506@redhat.com> References: <51AC8F7B.4090408@redhat.com> <51AC9310.2090900@redhat.com> <51ADCF8A.1040506@redhat.com> Message-ID: <51AE1149.6010201@redhat.com> On 06/04/2013 01:29 PM, Tomas Babej wrote: > On 06/03/2013 02:58 PM, Martin Kosek wrote: >> On 06/03/2013 02:43 PM, Tomas Babej wrote: >>> Hi, >>> >>> this patch fixes the installation problems on master on F19 with krb5 >>> packages >>>> = 1.11.2-6 >>> https://fedorahosted.org/freeipa/ticket/3666 >>> >>> Tomas >> 1) Leaving cache_desc open: >> >> + (cache_desc, cache_path) = tempfile.mkstemp(prefix='krbcc') >> + os.environ['KRB5CCNAME'] = cache_path >> >> Why do we keep the descriptor open and close it at the and of the >> installation? >> Can we close it right after tempfile.mkstemp? I think we do it this >> way in >> other places in installation. >> >> 2) What about other installers where we handle Kerberos auth, like >> ipa-{replica,dns,ca}-install? >> >> A common function, other shared means, of handling KRB5CCNAME may be >> appropriate to avoid duplicating code too much. >> >> Martin > I moved the code responsible to PrivateCCache class, both for > readability and conciseness. > > Private ccache now used in replica,dns and ca the installers. I managed > to reproduce the error only with > dns-install though(fails on adding the service principal), but having a > private ccache for the installer should not hurt. > > Ipa-adtrust-install requires the admin ticket, so there shouldn't be an > issue. > > Tomas Shouldn't the context manager restore os.environ['KRB5CCNAME'] on exit? Two nitpicks: ipaserver/install/installutils.py: new blank line at EOF For most context managers I prefer @contextlib.contextmanager rather than writing out the class, it makes them shorter and easier to read. -- Petr? From pvoborni at redhat.com Tue Jun 4 16:15:36 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 04 Jun 2013 18:15:36 +0200 Subject: [Freeipa-devel] [RFE] Integration testing In-Reply-To: <51AC8675.6050600@redhat.com> References: <51AC8675.6050600@redhat.com> Message-ID: <51AE12A8.5000607@redhat.com> Hello, Some Qs: 1) does the configuration only mean: "We have this topology, run all test which fits into it"? IDK how should Web UI or XML-RPC tests fit into it. The difference is that configuration for Web UI tests should mean: "This is how FreeIPA and related stuff is installed. Tests all available functionality and don't test the missing." IE. if I install freeipa server without CA, the UI tests needs to get that info (ie. by no_ca flag) and then skip certificate tests or parts of other tests which touches this feature (like navigation tests). The same for no-dns and has-trust... Complete UI testing would be something like following: a) set configuration A b) install server with configuration A c) run all UI tests (some may be skipped) i) in Firefox ii) in IE iii) in Chrome d) uninstall server e) set configuration B f) install server with configuration B g) run all UI tests (some may be skipped) i) in Firefox ii) in IE iii) in Chrome h) uninstall server i) repeat for config C ... Note:: browser change is also done by change of configuration. Is it possible? Can the configuration change or should there be other level of configuration which can change? Do we have time to do it? It may take almost a day (sequentially, with full coverage). Does python nose support some master tests or can it be somehow configured in Jenkins so we can automate installation of IPA with different configurations (IE by the 'To-be-done command-line tools'). 2) There is no configuration options for trusts. IMO we would like to test that. 3) Test runner needs to connect to remote machine as root. Should a config option for root password be added or can we safely assume that there will always be other authentication method available? Thanks On 06/03/2013 02:05 PM, Petr Viktorin wrote: > Hello, > A design document for integration testing is available at > http://www.freeipa.org/page/V3/Integration_testing. I've copied it below > for easier quoting. > > > __NOTOC__ > > = Overview = > > Make it possible to write and run multi-host integration tests (such as: > install master & replica, add user on replica, verify it's added on > master). > > These tests will be run from continuous integration. > Any developer can also run them manually. > > = Use Cases = > > == Continuous integration == > > The developer team at Red Hat will run a Jenkins continuous integration > server > that will run the tests automatically (after each commit if resources are > available). > > The CI results will be posted publicly. > > == Developer testing == > > Anyone is be able to run integration tests without advanced infrastructure, > only a number of virtual machines to run the tests on is needed. > > == Beaker integration == > > The tests will run seamlessly inside [http://beaker-project.org/ > Beaker]/[https://fedoraproject.org/wiki/QA/RHTS RHTS]. > A special option enables reporting via BeakerLib. > > = Non-goals = > > A complete testing/continuous integration setup needs some steps that > will not > be included in IPA's test suite: > > * Building the code > * VM provisioning > > * Configuring the basic system, installing the packages > > > = Design= > > The Python package with the IPA test suite is renamed to > ipatests, and > packaged for RPM-based systems as freeipa-tests. > Eventually the package will be included in Fedora. > > Integration tests will be controlled from a single machine, and executed > on a number of "remote" machines that act as servers, replicas, clients, > etc. > The controlling machine communicates with the others via the SSH protocol. > (The controlling machine may be the same as one of the "remote" ones.) > > Integration tests are included in the main IPA set suite, and configured > using > environment variables. If the variables are missing, all integration > tests are > skipped. > If an insufficient number of hosts is configured for a test, the > individiual > test will be skipped. > > A tool is provided to run installed tests. > > The remote machines used for integration testing are required to have > relevant > IPA packages installed, firewall opened up, any needed workarounds > applied (RPM > downgrades, SELinux mode,...), and sshd set up to allow root login. > The test runner will connect to these machines, install IPA, perform the > tests, > and then uninstall IPA & return the systems to their previous state. > > A plugin for integration with BeakerLib is provided. > > = Test configuration = > > Tests are configured using these environment variables. > > == Host configuration == > > ; $MASTER > : FQDN of the first IPA server > ; $REPLICA > : FQDNs of other IPA servers (space-separated) > ; $CLIENT > : FQDNs of IPA clients (space-separated) > ; $MASTER_env2, $REPLICA_env2, $CLIENT_env2, $MASTER_env3, ... > : can be used for additional domains when needed > > DNS needs to be set up so that IP addresses can be obtained for these > hosts. > > == Basic configuration == > > ; $IPATEST_DIR > : Directory for test data on the remote hosts > : Default: /root/ipatests > ; $DNSFORWARD > : IP of a DNS forwarder > : Default: 8.8.8.8 > > == Test customization == > > ; $DOMAIN > : IPA domain name > : Default: taken from $MASTER > ; $NISDOMAIN > : NIS domain name > : Default: ipatest > ; $NTPSERVER > : NIS domain name > : Default: ipatest > ; $IPv6SETUP > : Set to TRUE for IPv6-only connectivity > ; $IPADEBUG > : Set to enable test debugging > > ; $ADMINID > : Admin username > : Default: admin > ; $ADMINPW > : Admin user password > : Default: Secret123 > ; $ROOTDN > : Directory manager DN > : Default: cn=Directory Manager > ; $ROOTDNPWD > : Directory manager password > : Default: Secret123 > > = Supporting tools = > > == ipa-test-config == > > This tool reads the configuration variables above and outputs a Bash script > that sets a much more complete set of variables for easy shell-based > testing > or test set-up. > > Without arguments, ipa-test-config outputs information specific > to the host it is run on. When given a hostname, it prints config for that > host. > With the --global flag, it outputs configuration common to all > hosts. > > == ipa-run-tests == > > This tool is a wrapper arount nosetests and accepts the same > arguments > as Nose. > It loads any additional plugins and runs tests from the system-installed > IPA > test suite. > > == Other == > > TBD: Additional command-line tools may be provided for tasks such as > installing > IPA in a given topology. > > = Implementation = > > Test cases are implemented as Nose test classes, with > installation/uninstallation as class setup/teardown. > > A BeakerLib plugin is provided that starts/ends Beaker phases for Nose test > contexts and cases, issues a Beaker assertion (rlPass/rlFail) for each test > case, and collects and submits relevant logs. > > A separate plugin will be provided to collect logs outside of a Beaker > environment. > > = Example instructions = > To run the test called > test_integration/test_simple_replication.py, > which needs to run with two masters, follow these instructions. > > Install the IPA server packages on two machines, and do any preparations > necessary to install IPA (e.g. configure/disable the firewall). > > Then, install the freeipa-tests package on the machine that > will run > the tests (this may be one of the machines above, or preferably a different > one). > Set MASTER and REPLICA environment variables to the fully qualified > hostnames > of the two machines prepared earlier. > Also set any other relevant variables listed in > [[#Test configuration|Test configuration]]. > You may run ipa-test-config --global to verify how the test > configuration will be handled. > > The next steps depend on whether the test will run within a BeakerLib > session > or not. > > == With BeakerLib == > > Set up a BeakerLib test (e.g. rlJournalStart), and run: > > ipa-run-tests --with-beakerlib --no-skip > test_integration/test_simple_replication.py > > The output is somewhat messy as BeakerLib logs are printed to standard > error. > Not that output from external hosts is buffered, so installation may appear > hung. > > Archive any relevant data (e.g. with rlJournalPrintText), > and end the BeakerLib session (rlJournalEnd). > > == Without BeakerLib == > > Run: > > ipa-run-tests test_integration/test_simple_replication.py > > As with other Nose tests, no output is shown for test setup (installation) > if nothing goes wrong, so there may be a long time without output. > A summary is printed at the end of the test run. > > > = Feature Managment = > > === UI === > > N/A > > === CLI === > > See above > > = Major configuration options and enablement = > > See instructions above. > > = Replication = > > N/A > > = Updates and Upgrades = > > N/A > > (Note: The tests can theoretically be used to drive hosts with other > versions > of IPA packages to test backward/forward compatibility.) > > = Dependencies = > > The freeipa-test package will depend on some libraries that are already > used > for unit tests and other test-related tasks: > > * python-nose > * python-paste > * python-coverage > * python-polib > > Integration testing brings in a dependency on a library for the SSH > protocol: > > * python-paramiko > > Naturally, the new dependencies are not needed in a production environment. > > = External Impact = > > Cooperation with QE is underway. > > = Design author = > > [[User:pviktorin|Petr Viktorin]] > -- Petr Vobornik From pviktori at redhat.com Tue Jun 4 17:19:02 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 04 Jun 2013 19:19:02 +0200 Subject: [Freeipa-devel] [RFE] Integration testing In-Reply-To: <51AE12A8.5000607@redhat.com> References: <51AC8675.6050600@redhat.com> <51AE12A8.5000607@redhat.com> Message-ID: <51AE2186.1090805@redhat.com> On 06/04/2013 06:15 PM, Petr Vobornik wrote: > Hello, > > Some Qs: > > 1) does the configuration only mean: "We have this topology, run all > test which fits into it"? Not quite, it means "We have these machines, run tests whose topology can fit on them". > IDK how should Web UI or XML-RPC tests fit > into it. The existing test suite, including the RPC tests, stays as it is. The single-machine tests generally expect IPA to be set up on the local machine. > The difference is that configuration for Web UI tests should > mean: "This is how FreeIPA and related stuff is installed. Tests all > available functionality and don't test the missing." IE. if I install > freeipa server without CA, the UI tests needs to get that info (ie. by > no_ca flag) and then skip certificate tests or parts of other tests > which touches this feature (like navigation tests). The same for no-dns > and has-trust... > > Complete UI testing would be something like following: > a) set configuration A > b) install server with configuration A > c) run all UI tests (some may be skipped) > i) in Firefox > ii) in IE > iii) in Chrome > d) uninstall server > e) set configuration B > f) install server with configuration B > g) run all UI tests (some may be skipped) > i) in Firefox > ii) in IE > iii) in Chrome > h) uninstall server > i) repeat for config C > ... > > Note:: browser change is also done by change of configuration. > > Is it possible? Can the configuration change or should there be other > level of configuration which can change? Do we have time to do it? It > may take almost a day (sequentially, with full coverage). This would be configured in Jenkins as several jobs: 1) Run UI tests with configuration A + Firefox 2) Run UI tests with configuration A + IE 3) Run UI tests with configuration A + Chrome 4) Run UI tests with configuration B + Firefox 5) Run UI tests with configuration B + IE 6) Run UI tests with configuration B + Chrome If we wanted exhaustive tests it could be done as a "matrix job" ([A, B]?[FF, IE, Chrome]), but as you say we don't have resources for that, so we'll have to use some sane subset. (Note: Jenkins can aggregate results from multiple jobs, so we'd get a single report from all these) > Does python nose support some master tests or can it be somehow > configured in Jenkins so we can automate installation of IPA with > different configurations (IE by the 'To-be-done command-line tools'). I'm not sure what you mean by master tests. Jenkins can be configured to run different tests using different configurations. But the way I see it, the different topologies would be in different tests, and run different checks. remember that we want a CI, not exhaustive testing of all the possible cases. The command-line tools would be for external shell-based tests; I've heard some people might want to write those :) > 2) There is no configuration options for trusts. IMO we would like to > test that. Options for that can be added when the trust tests are written. > 3) Test runner needs to connect to remote machine as root. Should a > config option for root password be added or can we safely assume that > there will always be other authentication method available? My bad, I forgot to add $IPA_ROOT_SSH_PASSWORD to the wiki page. Fixed. Other authentication methods can be added if needed. -- Petr? From jhrozek at redhat.com Tue Jun 4 19:48:10 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 4 Jun 2013 21:48:10 +0200 Subject: [Freeipa-devel] [RFE] Integration testing In-Reply-To: <51AC8675.6050600@redhat.com> References: <51AC8675.6050600@redhat.com> Message-ID: <20130604194810.GB10811@hendrix.redhat.com> On Mon, Jun 03, 2013 at 02:05:09PM +0200, Petr Viktorin wrote: > Hello, > A design document for integration testing is available at > http://www.freeipa.org/page/V3/Integration_testing. I've copied it below for > easier quoting. > > > __NOTOC__ > > = Overview = > > Make it possible to write and run multi-host integration tests (such as: > install master & replica, add user on replica, verify it's added on master). > > These tests will be run from continuous integration. > Any developer can also run them manually. > > = Use Cases = > > == Continuous integration == > > The developer team at Red Hat will run a Jenkins continuous integration > server > that will run the tests automatically (after each commit if resources are > available). > > The CI results will be posted publicly. > > == Developer testing == > > Anyone is be able to run integration tests without advanced infrastructure, > only a number of virtual machines to run the tests on is needed. > > == Beaker integration == > > The tests will run seamlessly inside [http://beaker-project.org/ > Beaker]/[https://fedoraproject.org/wiki/QA/RHTS RHTS]. > A special option enables reporting via BeakerLib. > > = Non-goals = > > A complete testing/continuous integration setup needs some steps that will > not > be included in IPA's test suite: > > * Building the code > * VM provisioning > > * Configuring the basic system, installing the packages > > > = Design= > > The Python package with the IPA test suite is renamed to ipatests, > and > packaged for RPM-based systems as freeipa-tests. > Eventually the package will be included in Fedora. > > Integration tests will be controlled from a single machine, and executed > on a number of "remote" machines that act as servers, replicas, clients, > etc. > The controlling machine communicates with the others via the SSH protocol. > (The controlling machine may be the same as one of the "remote" ones.) > > Integration tests are included in the main IPA set suite, and configured > using > environment variables. If the variables are missing, all integration tests > are > skipped. > If an insufficient number of hosts is configured for a test, the individiual > test will be skipped. > > A tool is provided to run installed tests. > > The remote machines used for integration testing are required to have > relevant > IPA packages installed, firewall opened up, any needed workarounds applied > (RPM > downgrades, SELinux mode,...), and sshd set up to allow root login. > The test runner will connect to these machines, install IPA, perform the > tests, > and then uninstall IPA & return the systems to their previous state. > > A plugin for integration with BeakerLib is provided. > > = Test configuration = > > Tests are configured using these environment variables. > > == Host configuration == > > ; $MASTER > : FQDN of the first IPA server > ; $REPLICA > : FQDNs of other IPA servers (space-separated) > ; $CLIENT > : FQDNs of IPA clients (space-separated) > ; $MASTER_env2, $REPLICA_env2, $CLIENT_env2, $MASTER_env3, ... > : can be used for additional domains when needed > > DNS needs to be set up so that IP addresses can be obtained for these hosts. > > == Basic configuration == > > ; $IPATEST_DIR > : Directory for test data on the remote hosts > : Default: /root/ipatests > ; $DNSFORWARD > : IP of a DNS forwarder > : Default: 8.8.8.8 > > == Test customization == > > ; $DOMAIN > : IPA domain name > : Default: taken from $MASTER > ; $NISDOMAIN > : NIS domain name > : Default: ipatest > ; $NTPSERVER > : NIS domain name > : Default: ipatest > ; $IPv6SETUP > : Set to TRUE for IPv6-only connectivity > ; $IPADEBUG > : Set to enable test debugging > > ; $ADMINID > : Admin username > : Default: admin > ; $ADMINPW > : Admin user password > : Default: Secret123 > ; $ROOTDN > : Directory manager DN > : Default: cn=Directory Manager > ; $ROOTDNPWD > : Directory manager password > : Default: Secret123 > > = Supporting tools = > > == ipa-test-config == > > This tool reads the configuration variables above and outputs a Bash script > that sets a much more complete set of variables for easy shell-based testing > or test set-up. > > Without arguments, ipa-test-config outputs information specific > to the host it is run on. When given a hostname, it prints config for that > host. > With the --global flag, it outputs configuration common to all > hosts. > > == ipa-run-tests == > > This tool is a wrapper arount nosetests and accepts the same > arguments > as Nose. > It loads any additional plugins and runs tests from the system-installed IPA > test suite. > > == Other == > > TBD: Additional command-line tools may be provided for tasks such as > installing > IPA in a given topology. > > = Implementation = > > Test cases are implemented as Nose test classes, with > installation/uninstallation as class setup/teardown. > > A BeakerLib plugin is provided that starts/ends Beaker phases for Nose test > contexts and cases, issues a Beaker assertion (rlPass/rlFail) for each test > case, and collects and submits relevant logs. > > A separate plugin will be provided to collect logs outside of a Beaker > environment. > > = Example instructions = > To run the test called test_integration/test_simple_replication.py, > which needs to run with two masters, follow these instructions. > > Install the IPA server packages on two machines, and do any preparations > necessary to install IPA (e.g. configure/disable the firewall). > > Then, install the freeipa-tests package on the machine that will > run > the tests (this may be one of the machines above, or preferably a different > one). > Set MASTER and REPLICA environment variables to the fully qualified > hostnames > of the two machines prepared earlier. > Also set any other relevant variables listed in > [[#Test configuration|Test configuration]]. > You may run ipa-test-config --global to verify how the test > configuration will be handled. > > The next steps depend on whether the test will run within a BeakerLib > session > or not. How much is the test library tied to IPA? I'd like to reuse it for SSSD tests, obviously those tests that would be able to run against an IPA server could be easy, but what about tests that require some other custom LDAP server? Would the library allow rolling out a more generic server or would we need to set up a "stable" machine which the tests would connect to? From tbabej at redhat.com Wed Jun 5 07:20:16 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 05 Jun 2013 09:20:16 +0200 Subject: [Freeipa-devel] [PATCH 0065] Use private ccache in ipa-server-install In-Reply-To: <51AE1149.6010201@redhat.com> References: <51AC8F7B.4090408@redhat.com> <51AC9310.2090900@redhat.com> <51ADCF8A.1040506@redhat.com> <51AE1149.6010201@redhat.com> Message-ID: <51AEE6B0.8040604@redhat.com> On 06/04/2013 06:09 PM, Petr Viktorin wrote: > On 06/04/2013 01:29 PM, Tomas Babej wrote: >> On 06/03/2013 02:58 PM, Martin Kosek wrote: >>> On 06/03/2013 02:43 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> this patch fixes the installation problems on master on F19 with krb5 >>>> packages >>>>> = 1.11.2-6 >>>> https://fedorahosted.org/freeipa/ticket/3666 >>>> >>>> Tomas >>> 1) Leaving cache_desc open: >>> >>> + (cache_desc, cache_path) = tempfile.mkstemp(prefix='krbcc') >>> + os.environ['KRB5CCNAME'] = cache_path >>> >>> Why do we keep the descriptor open and close it at the and of the >>> installation? >>> Can we close it right after tempfile.mkstemp? I think we do it this >>> way in >>> other places in installation. >>> >>> 2) What about other installers where we handle Kerberos auth, like >>> ipa-{replica,dns,ca}-install? >>> >>> A common function, other shared means, of handling KRB5CCNAME may be >>> appropriate to avoid duplicating code too much. >>> >>> Martin >> I moved the code responsible to PrivateCCache class, both for >> readability and conciseness. >> >> Private ccache now used in replica,dns and ca the installers. I managed >> to reproduce the error only with >> dns-install though(fails on adding the service principal), but having a >> private ccache for the installer should not hurt. >> >> Ipa-adtrust-install requires the admin ticket, so there shouldn't be an >> issue. >> >> Tomas > > Shouldn't the context manager restore os.environ['KRB5CCNAME'] on exit? There's no need to, since the value of the environment variable is inherited only into child processes (pkispawn, etc.). Hence the KRB5CCNAME environment variable is not available outside the install script. [root at vm-002 labtool]# ipa-server-install [snip] 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 [root at vm-002 labtool]# echo $KRB5CCNAME [root at vm-002 labtool]# > > > Two nitpicks: > > ipaserver/install/installutils.py: new blank line at EOF > > For most context managers I prefer @contextlib.contextmanager rather > than writing out the class, it makes them shorter and easier to read Addressed in the updated patch. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0065-3-Use-private-ccache-in-ipa-server-install.patch Type: text/x-patch Size: 6390 bytes Desc: not available URL: From tbabej at redhat.com Wed Jun 5 08:01:32 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 05 Jun 2013 10:01:32 +0200 Subject: [Freeipa-devel] [PATCHES 0053-0055] Prompt for RID base if trusted domain SID / name is specified and vice versa In-Reply-To: <51A8D498.3090901@redhat.com> References: <518D06B1.1060904@redhat.com> <519109CC.5090300@redhat.com> <51A7436F.7060302@redhat.com> <51A87A96.6080404@redhat.com> <51A8A729.9030108@redhat.com> <51A8D498.3090901@redhat.com> Message-ID: <51AEF05C.30208@redhat.com> On 05/31/2013 06:49 PM, Ana Krivokapic wrote: > On 05/31/2013 03:35 PM, Ana Krivokapic wrote: >> On 05/31/2013 12:25 PM, Tomas Babej wrote: >>> On 05/30/2013 02:17 PM, Ana Krivokapic wrote: >>>> On 05/13/2013 05:42 PM, Tomas Babej wrote: >>>>> On 05/10/2013 04:39 PM, Tomas Babej wrote: >>>>>> Hi, >>>>>> >>>>>> this patcheset deals with >>>>>> https://fedorahosted.org/freeipa/ticket/3602 >>>>>> >>>>>> See commit messages for details. >>>>>> >>>>>> Tomas >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-devel mailing list >>>>>> Freeipa-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> >>>>> I noticed during further development that logic in >>>>> interactive_prompt_callback did not follow the pre_callback logic >>>>> precisely. >>>>> >>>>> Fixed patches attached. >>>>> >>>>> Tomas >>>> Hi, >>>> >>>> Patches work fine. >>>> >>>> I would suggest incorporating a fix for ticket >>>> https://fedorahosted.org/freeipa/ticket/3634 into this patchset. >>>> The issue from ticket #3634 is closely connected to this one, and >>>> with the introduction of prompt_param() functionality, including a >>>> fix for it would require minimal effort. You can look at my patch >>>> (https://www.redhat.com/archives/freeipa-devel/2013-May/msg00297.html) >>>> and if you think the approach is right, adjust accordingly and >>>> incorporate it in your patchset. >>>> >>>> Other (minor) comments: >>>> >>>> * The last change in ipalib/plugins/idrange.py seems like you >>>> wanted to fix the fact that the lines weren't properly indented >>>> (they weren't multiples of 4). However, you also need to fix the >>>> previous line (raise ...). >>>> * There are a lot of unused imports in ipalib/frontend.py. Since >>>> you are already touching imports in your patch, could you clean up >>>> the unused imports as well. >>>> >>>> -- >>>> Regards, >>>> >>>> Ana Krivokapic >>>> Associate Software Engineer >>>> FreeIPA team >>>> Red Hat Inc. >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >>> I addressed the minor issues. Updated patches are attached. >>> >>> Regarding your patch, I agree. I sent a reply to its thread. >>> >>> Tomas >> ACK >> > After a second look, you seem to have removed to many imports from > ipalib/frontend.py and now the doctests are failing. The import of > `Password` from `parameters` should be put back in. > -- > Regards, > > Ana Krivokapic > Associate Software Engineer > FreeIPA team > Red Hat Inc. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Fixed. That actually was an unused import - when considering the code :) Thanks for catching that. Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0055-4-Incorporate-interactive-prompts-in-idrange-add.patch Type: text/x-patch Size: 3364 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0054-4-Add-prompt_param-method-to-avoid-code-duplication.patch Type: text/x-patch Size: 9394 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0053-4-Remove-redundant-check-for-env.interactive.patch Type: text/x-patch Size: 872 bytes Desc: not available URL: From pviktori at redhat.com Wed Jun 5 08:07:44 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 05 Jun 2013 10:07:44 +0200 Subject: [Freeipa-devel] [PATCH 0065] Use private ccache in ipa-server-install In-Reply-To: <51AEE6B0.8040604@redhat.com> References: <51AC8F7B.4090408@redhat.com> <51AC9310.2090900@redhat.com> <51ADCF8A.1040506@redhat.com> <51AE1149.6010201@redhat.com> <51AEE6B0.8040604@redhat.com> Message-ID: <51AEF1D0.3010107@redhat.com> On 06/05/2013 09:20 AM, Tomas Babej wrote: > On 06/04/2013 06:09 PM, Petr Viktorin wrote: >> On 06/04/2013 01:29 PM, Tomas Babej wrote: >>> On 06/03/2013 02:58 PM, Martin Kosek wrote: >>>> On 06/03/2013 02:43 PM, Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> this patch fixes the installation problems on master on F19 with krb5 >>>>> packages >>>>>> = 1.11.2-6 >>>>> https://fedorahosted.org/freeipa/ticket/3666 >>>>> >>>>> Tomas >>>> 1) Leaving cache_desc open: >>>> >>>> + (cache_desc, cache_path) = tempfile.mkstemp(prefix='krbcc') >>>> + os.environ['KRB5CCNAME'] = cache_path >>>> >>>> Why do we keep the descriptor open and close it at the and of the >>>> installation? >>>> Can we close it right after tempfile.mkstemp? I think we do it this >>>> way in >>>> other places in installation. >>>> >>>> 2) What about other installers where we handle Kerberos auth, like >>>> ipa-{replica,dns,ca}-install? >>>> >>>> A common function, other shared means, of handling KRB5CCNAME may be >>>> appropriate to avoid duplicating code too much. >>>> >>>> Martin >>> I moved the code responsible to PrivateCCache class, both for >>> readability and conciseness. >>> >>> Private ccache now used in replica,dns and ca the installers. I managed >>> to reproduce the error only with >>> dns-install though(fails on adding the service principal), but having a >>> private ccache for the installer should not hurt. >>> >>> Ipa-adtrust-install requires the admin ticket, so there shouldn't be an >>> issue. >>> >>> Tomas >> >> Shouldn't the context manager restore os.environ['KRB5CCNAME'] on exit? > > There's no need to, since the value of the environment variable is > inherited only into child processes (pkispawn, etc.). Hence the KRB5CCNAME > environment variable is not available outside the install script. Yes, but what if you call a child process after the context manager exits? I know that currently there is no code after the context manager exits, but that's no reason to surprise people who will want to reuse it later. Context managers are expected to clean up after themselves. If there's no way to do this then you should at least document that this one is special. But in this case it shouldn't be that hard to clean up. > [root at vm-002 labtool]# ipa-server-install > [snip] > 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 > > [root at vm-002 labtool]# echo $KRB5CCNAME > > [root at vm-002 labtool]# >> >> >> Two nitpicks: >> >> ipaserver/install/installutils.py: new blank line at EOF >> >> For most context managers I prefer @contextlib.contextmanager rather >> than writing out the class, it makes them shorter and easier to read > > Addressed in the updated patch. > > Tomas -- Petr? From pviktori at redhat.com Wed Jun 5 08:42:30 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 05 Jun 2013 10:42:30 +0200 Subject: [Freeipa-devel] [RFE] Integration testing In-Reply-To: <20130604194810.GB10811@hendrix.redhat.com> References: <51AC8675.6050600@redhat.com> <20130604194810.GB10811@hendrix.redhat.com> Message-ID: <51AEF9F6.2000500@redhat.com> On 06/04/2013 09:48 PM, Jakub Hrozek wrote: > On Mon, Jun 03, 2013 at 02:05:09PM +0200, Petr Viktorin wrote: >> Hello, >> A design document for integration testing is available at >> http://www.freeipa.org/page/V3/Integration_testing. I've copied it below for >> easier quoting. >> >> >> __NOTOC__ >> >> = Overview = >> >> Make it possible to write and run multi-host integration tests (such as: >> install master & replica, add user on replica, verify it's added on master). >> >> These tests will be run from continuous integration. >> Any developer can also run them manually. >> >> = Use Cases = >> >> == Continuous integration == >> >> The developer team at Red Hat will run a Jenkins continuous integration >> server >> that will run the tests automatically (after each commit if resources are >> available). >> >> The CI results will be posted publicly. >> >> == Developer testing == >> >> Anyone is be able to run integration tests without advanced infrastructure, >> only a number of virtual machines to run the tests on is needed. >> >> == Beaker integration == >> >> The tests will run seamlessly inside [http://beaker-project.org/ >> Beaker]/[https://fedoraproject.org/wiki/QA/RHTS RHTS]. >> A special option enables reporting via BeakerLib. >> >> = Non-goals = >> >> A complete testing/continuous integration setup needs some steps that will >> not >> be included in IPA's test suite: >> >> * Building the code >> * VM provisioning >> >> * Configuring the basic system, installing the packages >> >> >> = Design= >> >> The Python package with the IPA test suite is renamed to ipatests, >> and >> packaged for RPM-based systems as freeipa-tests. >> Eventually the package will be included in Fedora. >> >> Integration tests will be controlled from a single machine, and executed >> on a number of "remote" machines that act as servers, replicas, clients, >> etc. >> The controlling machine communicates with the others via the SSH protocol. >> (The controlling machine may be the same as one of the "remote" ones.) >> >> Integration tests are included in the main IPA set suite, and configured >> using >> environment variables. If the variables are missing, all integration tests >> are >> skipped. >> If an insufficient number of hosts is configured for a test, the individiual >> test will be skipped. >> >> A tool is provided to run installed tests. >> >> The remote machines used for integration testing are required to have >> relevant >> IPA packages installed, firewall opened up, any needed workarounds applied >> (RPM >> downgrades, SELinux mode,...), and sshd set up to allow root login. >> The test runner will connect to these machines, install IPA, perform the >> tests, >> and then uninstall IPA & return the systems to their previous state. >> >> A plugin for integration with BeakerLib is provided. >> >> = Test configuration = >> >> Tests are configured using these environment variables. >> >> == Host configuration == >> >> ; $MASTER >> : FQDN of the first IPA server >> ; $REPLICA >> : FQDNs of other IPA servers (space-separated) >> ; $CLIENT >> : FQDNs of IPA clients (space-separated) >> ; $MASTER_env2, $REPLICA_env2, $CLIENT_env2, $MASTER_env3, ... >> : can be used for additional domains when needed >> >> DNS needs to be set up so that IP addresses can be obtained for these hosts. >> >> == Basic configuration == >> >> ; $IPATEST_DIR >> : Directory for test data on the remote hosts >> : Default: /root/ipatests >> ; $DNSFORWARD >> : IP of a DNS forwarder >> : Default: 8.8.8.8 >> >> == Test customization == >> >> ; $DOMAIN >> : IPA domain name >> : Default: taken from $MASTER >> ; $NISDOMAIN >> : NIS domain name >> : Default: ipatest >> ; $NTPSERVER >> : NIS domain name >> : Default: ipatest >> ; $IPv6SETUP >> : Set to TRUE for IPv6-only connectivity >> ; $IPADEBUG >> : Set to enable test debugging >> >> ; $ADMINID >> : Admin username >> : Default: admin >> ; $ADMINPW >> : Admin user password >> : Default: Secret123 >> ; $ROOTDN >> : Directory manager DN >> : Default: cn=Directory Manager >> ; $ROOTDNPWD >> : Directory manager password >> : Default: Secret123 >> >> = Supporting tools = >> >> == ipa-test-config == >> >> This tool reads the configuration variables above and outputs a Bash script >> that sets a much more complete set of variables for easy shell-based testing >> or test set-up. >> >> Without arguments, ipa-test-config outputs information specific >> to the host it is run on. When given a hostname, it prints config for that >> host. >> With the --global flag, it outputs configuration common to all >> hosts. >> >> == ipa-run-tests == >> >> This tool is a wrapper arount nosetests and accepts the same >> arguments >> as Nose. >> It loads any additional plugins and runs tests from the system-installed IPA >> test suite. >> >> == Other == >> >> TBD: Additional command-line tools may be provided for tasks such as >> installing >> IPA in a given topology. >> >> = Implementation = >> >> Test cases are implemented as Nose test classes, with >> installation/uninstallation as class setup/teardown. >> >> A BeakerLib plugin is provided that starts/ends Beaker phases for Nose test >> contexts and cases, issues a Beaker assertion (rlPass/rlFail) for each test >> case, and collects and submits relevant logs. >> >> A separate plugin will be provided to collect logs outside of a Beaker >> environment. >> >> = Example instructions = >> To run the test called test_integration/test_simple_replication.py, >> which needs to run with two masters, follow these instructions. >> >> Install the IPA server packages on two machines, and do any preparations >> necessary to install IPA (e.g. configure/disable the firewall). >> >> Then, install the freeipa-tests package on the machine that will >> run >> the tests (this may be one of the machines above, or preferably a different >> one). >> Set MASTER and REPLICA environment variables to the fully qualified >> hostnames >> of the two machines prepared earlier. >> Also set any other relevant variables listed in >> [[#Test configuration|Test configuration]]. >> You may run ipa-test-config --global to verify how the test >> configuration will be handled. >> >> The next steps depend on whether the test will run within a BeakerLib >> session >> or not. > > How much is the test library tied to IPA? I'd like to reuse it for SSSD > tests, obviously those tests that would be able to run against an IPA > server could be easy, but what about tests that require some other > custom LDAP server? Would the library allow rolling out a more generic > server or would we need to set up a "stable" machine which the tests > would connect to? The test library is tied to ipapython. In particular the logging infrastructure wouldn't be easy to replace. So you'll need some IPA packages installed on the controlling machine, but no server needs to be running. On the remote machines, all you need is an SSH-2 server. The library doesn't "roll out" servers. Everyone's setup can be different (static servers, Beaker, cloud, local VM provisioning, ...). Unfortunately, the only sane way to support everything is to have the user write a script for it. So the tests assume servers are already prepared, up to RPM installation, and they just run ipa-server-install & co. I'll set up a Jenkins instance to run the tests and release much of the configuration, but this will only be an example of how to do it in one particular case. For AD, the tests will expect an AD server fully set up, since you can't really install Windows automatically. You can either do the same for a custom LDAP server, or you can have the tests install/uninstall it. -- Petr? From tbabej at redhat.com Wed Jun 5 08:47:02 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 05 Jun 2013 10:47:02 +0200 Subject: [Freeipa-devel] [PATCH 0065] Use private ccache in ipa-server-install In-Reply-To: <51AEF1D0.3010107@redhat.com> References: <51AC8F7B.4090408@redhat.com> <51AC9310.2090900@redhat.com> <51ADCF8A.1040506@redhat.com> <51AE1149.6010201@redhat.com> <51AEE6B0.8040604@redhat.com> <51AEF1D0.3010107@redhat.com> Message-ID: <51AEFB06.8010407@redhat.com> On 06/05/2013 10:07 AM, Petr Viktorin wrote: > On 06/05/2013 09:20 AM, Tomas Babej wrote: >> On 06/04/2013 06:09 PM, Petr Viktorin wrote: >>> On 06/04/2013 01:29 PM, Tomas Babej wrote: >>>> On 06/03/2013 02:58 PM, Martin Kosek wrote: >>>>> On 06/03/2013 02:43 PM, Tomas Babej wrote: >>>>>> Hi, >>>>>> >>>>>> this patch fixes the installation problems on master on F19 with >>>>>> krb5 >>>>>> packages >>>>>>> = 1.11.2-6 >>>>>> https://fedorahosted.org/freeipa/ticket/3666 >>>>>> >>>>>> Tomas >>>>> 1) Leaving cache_desc open: >>>>> >>>>> + (cache_desc, cache_path) = tempfile.mkstemp(prefix='krbcc') >>>>> + os.environ['KRB5CCNAME'] = cache_path >>>>> >>>>> Why do we keep the descriptor open and close it at the and of the >>>>> installation? >>>>> Can we close it right after tempfile.mkstemp? I think we do it this >>>>> way in >>>>> other places in installation. >>>>> >>>>> 2) What about other installers where we handle Kerberos auth, like >>>>> ipa-{replica,dns,ca}-install? >>>>> >>>>> A common function, other shared means, of handling KRB5CCNAME may be >>>>> appropriate to avoid duplicating code too much. >>>>> >>>>> Martin >>>> I moved the code responsible to PrivateCCache class, both for >>>> readability and conciseness. >>>> >>>> Private ccache now used in replica,dns and ca the installers. I >>>> managed >>>> to reproduce the error only with >>>> dns-install though(fails on adding the service principal), but >>>> having a >>>> private ccache for the installer should not hurt. >>>> >>>> Ipa-adtrust-install requires the admin ticket, so there shouldn't >>>> be an >>>> issue. >>>> >>>> Tomas >>> >>> Shouldn't the context manager restore os.environ['KRB5CCNAME'] on exit? >> >> There's no need to, since the value of the environment variable is >> inherited only into child processes (pkispawn, etc.). Hence the >> KRB5CCNAME >> environment variable is not available outside the install script. > > Yes, but what if you call a child process after the context manager > exits? > I know that currently there is no code after the context manager > exits, but that's no reason to surprise people who will want to reuse > it later. > > Context managers are expected to clean up after themselves. If there's > no way to do this then you should at least document that this one is > special. But in this case it shouldn't be that hard to clean up. > Not at all, I actually had the code there at some point, but removed it. Updated patch attached. Tomas >> [root at vm-002 labtool]# ipa-server-install >> [snip] >> 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 >> >> [root at vm-002 labtool]# echo $KRB5CCNAME >> >> [root at vm-002 labtool]# >>> >>> >>> Two nitpicks: >>> >>> ipaserver/install/installutils.py: new blank line at EOF >>> >>> For most context managers I prefer @contextlib.contextmanager rather >>> than writing out the class, it makes them shorter and easier to read >> >> Addressed in the updated patch. >> >> Tomas > > -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0065-4-Use-private-ccache-in-ipa-server-install.patch Type: text/x-patch Size: 6604 bytes Desc: not available URL: From akrivoka at redhat.com Wed Jun 5 09:30:27 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 05 Jun 2013 11:30:27 +0200 Subject: [Freeipa-devel] [PATCHES 0053-0055] Prompt for RID base if trusted domain SID / name is specified and vice versa In-Reply-To: <51AEF05C.30208@redhat.com> References: <518D06B1.1060904@redhat.com> <519109CC.5090300@redhat.com> <51A7436F.7060302@redhat.com> <51A87A96.6080404@redhat.com> <51A8A729.9030108@redhat.com> <51A8D498.3090901@redhat.com> <51AEF05C.30208@redhat.com> Message-ID: <51AF0533.3060408@redhat.com> On 06/05/2013 10:01 AM, Tomas Babej wrote: > On 05/31/2013 06:49 PM, Ana Krivokapic wrote: >> On 05/31/2013 03:35 PM, Ana Krivokapic wrote: >>> On 05/31/2013 12:25 PM, Tomas Babej wrote: >>>> On 05/30/2013 02:17 PM, Ana Krivokapic wrote: >>>>> On 05/13/2013 05:42 PM, Tomas Babej wrote: >>>>>> On 05/10/2013 04:39 PM, Tomas Babej wrote: >>>>>>> Hi, >>>>>>> >>>>>>> this patcheset deals with >>>>>>> https://fedorahosted.org/freeipa/ticket/3602 >>>>>>> >>>>>>> See commit messages for details. >>>>>>> >>>>>>> Tomas >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Freeipa-devel mailing list >>>>>>> Freeipa-devel at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>> >>>>>> I noticed during further development that logic in >>>>>> interactive_prompt_callback did not follow the pre_callback logic >>>>>> precisely. >>>>>> >>>>>> Fixed patches attached. >>>>>> >>>>>> Tomas >>>>> Hi, >>>>> >>>>> Patches work fine. >>>>> >>>>> I would suggest incorporating a fix for ticket >>>>> https://fedorahosted.org/freeipa/ticket/3634 into this patchset. >>>>> The issue from ticket #3634 is closely connected to this one, and >>>>> with the introduction of prompt_param() functionality, including a >>>>> fix for it would require minimal effort. You can look at my patch >>>>> (https://www.redhat.com/archives/freeipa-devel/2013-May/msg00297.html) >>>>> and if you think the approach is right, adjust accordingly and >>>>> incorporate it in your patchset. >>>>> >>>>> Other (minor) comments: >>>>> >>>>> * The last change in ipalib/plugins/idrange.py seems like you >>>>> wanted to fix the fact that the lines weren't properly indented >>>>> (they weren't multiples of 4). However, you also need to fix the >>>>> previous line (raise ...). >>>>> * There are a lot of unused imports in ipalib/frontend.py. Since >>>>> you are already touching imports in your patch, could you clean up >>>>> the unused imports as well. >>>>> >>>>> -- >>>>> Regards, >>>>> >>>>> Ana Krivokapic >>>>> Associate Software Engineer >>>>> FreeIPA team >>>>> Red Hat Inc. >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>>> I addressed the minor issues. Updated patches are attached. >>>> >>>> Regarding your patch, I agree. I sent a reply to its thread. >>>> >>>> Tomas >>> ACK >>> >> After a second look, you seem to have removed to many imports from >> ipalib/frontend.py and now the doctests are failing. The import of >> `Password` from `parameters` should be put back in. >> -- >> Regards, >> >> Ana Krivokapic >> Associate Software Engineer >> FreeIPA team >> Red Hat Inc. >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > Fixed. That actually was an unused import - when considering the code :) > > Thanks for catching that. > > Tomas ACK for all 3 patches. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Wed Jun 5 09:39:23 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 5 Jun 2013 11:39:23 +0200 Subject: [Freeipa-devel] [RFE] Integration testing In-Reply-To: <51AEF9F6.2000500@redhat.com> References: <51AC8675.6050600@redhat.com> <20130604194810.GB10811@hendrix.redhat.com> <51AEF9F6.2000500@redhat.com> Message-ID: <20130605093923.GG10811@hendrix.redhat.com> On Wed, Jun 05, 2013 at 10:42:30AM +0200, Petr Viktorin wrote: > On 06/04/2013 09:48 PM, Jakub Hrozek wrote: > >On Mon, Jun 03, 2013 at 02:05:09PM +0200, Petr Viktorin wrote: > >>Hello, > >>A design document for integration testing is available at > >>http://www.freeipa.org/page/V3/Integration_testing. I've copied it below for > >>easier quoting. > >> > >> > >>__NOTOC__ > >> > >>= Overview = > >> > >>Make it possible to write and run multi-host integration tests (such as: > >>install master & replica, add user on replica, verify it's added on master). > >> > >>These tests will be run from continuous integration. > >>Any developer can also run them manually. > >> > >>= Use Cases = > >> > >>== Continuous integration == > >> > >>The developer team at Red Hat will run a Jenkins continuous integration > >>server > >>that will run the tests automatically (after each commit if resources are > >>available). > >> > >>The CI results will be posted publicly. > >> > >>== Developer testing == > >> > >>Anyone is be able to run integration tests without advanced infrastructure, > >>only a number of virtual machines to run the tests on is needed. > >> > >>== Beaker integration == > >> > >>The tests will run seamlessly inside [http://beaker-project.org/ > >>Beaker]/[https://fedoraproject.org/wiki/QA/RHTS RHTS]. > >>A special option enables reporting via BeakerLib. > >> > >>= Non-goals = > >> > >>A complete testing/continuous integration setup needs some steps that will > >>not > >>be included in IPA's test suite: > >> > >>* Building the code > >>* VM provisioning > >> > >>* Configuring the basic system, installing the packages > >> > >> > >>= Design= > >> > >>The Python package with the IPA test suite is renamed to ipatests, > >>and > >>packaged for RPM-based systems as freeipa-tests. > >>Eventually the package will be included in Fedora. > >> > >>Integration tests will be controlled from a single machine, and executed > >>on a number of "remote" machines that act as servers, replicas, clients, > >>etc. > >>The controlling machine communicates with the others via the SSH protocol. > >>(The controlling machine may be the same as one of the "remote" ones.) > >> > >>Integration tests are included in the main IPA set suite, and configured > >>using > >>environment variables. If the variables are missing, all integration tests > >>are > >>skipped. > >>If an insufficient number of hosts is configured for a test, the individiual > >>test will be skipped. > >> > >>A tool is provided to run installed tests. > >> > >>The remote machines used for integration testing are required to have > >>relevant > >>IPA packages installed, firewall opened up, any needed workarounds applied > >>(RPM > >>downgrades, SELinux mode,...), and sshd set up to allow root login. > >>The test runner will connect to these machines, install IPA, perform the > >>tests, > >>and then uninstall IPA & return the systems to their previous state. > >> > >>A plugin for integration with BeakerLib is provided. > >> > >>= Test configuration = > >> > >>Tests are configured using these environment variables. > >> > >>== Host configuration == > >> > >>; $MASTER > >>: FQDN of the first IPA server > >>; $REPLICA > >>: FQDNs of other IPA servers (space-separated) > >>; $CLIENT > >>: FQDNs of IPA clients (space-separated) > >>; $MASTER_env2, $REPLICA_env2, $CLIENT_env2, $MASTER_env3, ... > >>: can be used for additional domains when needed > >> > >>DNS needs to be set up so that IP addresses can be obtained for these hosts. > >> > >>== Basic configuration == > >> > >>; $IPATEST_DIR > >>: Directory for test data on the remote hosts > >>: Default: /root/ipatests > >>; $DNSFORWARD > >>: IP of a DNS forwarder > >>: Default: 8.8.8.8 > >> > >>== Test customization == > >> > >>; $DOMAIN > >>: IPA domain name > >>: Default: taken from $MASTER > >>; $NISDOMAIN > >>: NIS domain name > >>: Default: ipatest > >>; $NTPSERVER > >>: NIS domain name > >>: Default: ipatest > >>; $IPv6SETUP > >>: Set to TRUE for IPv6-only connectivity > >>; $IPADEBUG > >>: Set to enable test debugging > >> > >>; $ADMINID > >>: Admin username > >>: Default: admin > >>; $ADMINPW > >>: Admin user password > >>: Default: Secret123 > >>; $ROOTDN > >>: Directory manager DN > >>: Default: cn=Directory Manager > >>; $ROOTDNPWD > >>: Directory manager password > >>: Default: Secret123 > >> > >>= Supporting tools = > >> > >>== ipa-test-config == > >> > >>This tool reads the configuration variables above and outputs a Bash script > >>that sets a much more complete set of variables for easy shell-based testing > >>or test set-up. > >> > >>Without arguments, ipa-test-config outputs information specific > >>to the host it is run on. When given a hostname, it prints config for that > >>host. > >>With the --global flag, it outputs configuration common to all > >>hosts. > >> > >>== ipa-run-tests == > >> > >>This tool is a wrapper arount nosetests and accepts the same > >>arguments > >>as Nose. > >>It loads any additional plugins and runs tests from the system-installed IPA > >>test suite. > >> > >>== Other == > >> > >>TBD: Additional command-line tools may be provided for tasks such as > >>installing > >>IPA in a given topology. > >> > >>= Implementation = > >> > >>Test cases are implemented as Nose test classes, with > >>installation/uninstallation as class setup/teardown. > >> > >>A BeakerLib plugin is provided that starts/ends Beaker phases for Nose test > >>contexts and cases, issues a Beaker assertion (rlPass/rlFail) for each test > >>case, and collects and submits relevant logs. > >> > >>A separate plugin will be provided to collect logs outside of a Beaker > >>environment. > >> > >>= Example instructions = > >>To run the test called test_integration/test_simple_replication.py, > >>which needs to run with two masters, follow these instructions. > >> > >>Install the IPA server packages on two machines, and do any preparations > >>necessary to install IPA (e.g. configure/disable the firewall). > >> > >>Then, install the freeipa-tests package on the machine that will > >>run > >>the tests (this may be one of the machines above, or preferably a different > >>one). > >>Set MASTER and REPLICA environment variables to the fully qualified > >>hostnames > >>of the two machines prepared earlier. > >>Also set any other relevant variables listed in > >>[[#Test configuration|Test configuration]]. > >>You may run ipa-test-config --global to verify how the test > >>configuration will be handled. > >> > >>The next steps depend on whether the test will run within a BeakerLib > >>session > >>or not. > > > >How much is the test library tied to IPA? I'd like to reuse it for SSSD > >tests, obviously those tests that would be able to run against an IPA > >server could be easy, but what about tests that require some other > >custom LDAP server? Would the library allow rolling out a more generic > >server or would we need to set up a "stable" machine which the tests > >would connect to? > > The test library is tied to ipapython. In particular the logging > infrastructure wouldn't be easy to replace. So you'll need some IPA packages > installed on the controlling machine, but no server needs to be running. > On the remote machines, all you need is an SSH-2 server. > That's fine. > The library doesn't "roll out" servers. Everyone's setup can be different > (static servers, Beaker, cloud, local VM provisioning, ...). > Unfortunately, the only sane way to support everything is to have the user > write a script for it. So the tests assume servers are already prepared, up > to RPM installation, and they just run ipa-server-install & co. > I'll set up a Jenkins instance to run the tests and release much of the > configuration, but this will only be an example of how to do it in one > particular case. > For AD, the tests will expect an AD server fully set up, since you can't > really install Windows automatically. You can either do the same for a > custom LDAP server, or you can have the tests install/uninstall it. Sounds good, thanks. From pviktori at redhat.com Wed Jun 5 10:31:59 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 05 Jun 2013 12:31:59 +0200 Subject: [Freeipa-devel] [PATCH 0065] Use private ccache in ipa-server-install In-Reply-To: <51AEFB06.8010407@redhat.com> References: <51AC8F7B.4090408@redhat.com> <51AC9310.2090900@redhat.com> <51ADCF8A.1040506@redhat.com> <51AE1149.6010201@redhat.com> <51AEE6B0.8040604@redhat.com> <51AEF1D0.3010107@redhat.com> <51AEFB06.8010407@redhat.com> Message-ID: <51AF139F.8060801@redhat.com> On 06/05/2013 10:47 AM, Tomas Babej wrote: > On 06/05/2013 10:07 AM, Petr Viktorin wrote: >> On 06/05/2013 09:20 AM, Tomas Babej wrote: >>> On 06/04/2013 06:09 PM, Petr Viktorin wrote: >>>> On 06/04/2013 01:29 PM, Tomas Babej wrote: >>>>> On 06/03/2013 02:58 PM, Martin Kosek wrote: >>>>>> On 06/03/2013 02:43 PM, Tomas Babej wrote: >>>>>>> Hi, >>>>>>> >>>>>>> this patch fixes the installation problems on master on F19 with >>>>>>> krb5 >>>>>>> packages >>>>>>>> = 1.11.2-6 >>>>>>> https://fedorahosted.org/freeipa/ticket/3666 >>>>>>> >>>>>>> Tomas >>>>>> 1) Leaving cache_desc open: >>>>>> >>>>>> + (cache_desc, cache_path) = tempfile.mkstemp(prefix='krbcc') >>>>>> + os.environ['KRB5CCNAME'] = cache_path >>>>>> >>>>>> Why do we keep the descriptor open and close it at the and of the >>>>>> installation? >>>>>> Can we close it right after tempfile.mkstemp? I think we do it this >>>>>> way in >>>>>> other places in installation. >>>>>> >>>>>> 2) What about other installers where we handle Kerberos auth, like >>>>>> ipa-{replica,dns,ca}-install? >>>>>> >>>>>> A common function, other shared means, of handling KRB5CCNAME may be >>>>>> appropriate to avoid duplicating code too much. >>>>>> >>>>>> Martin >>>>> I moved the code responsible to PrivateCCache class, both for >>>>> readability and conciseness. >>>>> >>>>> Private ccache now used in replica,dns and ca the installers. I >>>>> managed >>>>> to reproduce the error only with >>>>> dns-install though(fails on adding the service principal), but >>>>> having a >>>>> private ccache for the installer should not hurt. >>>>> >>>>> Ipa-adtrust-install requires the admin ticket, so there shouldn't >>>>> be an >>>>> issue. >>>>> >>>>> Tomas >>>> >>>> Shouldn't the context manager restore os.environ['KRB5CCNAME'] on exit? >>> >>> There's no need to, since the value of the environment variable is >>> inherited only into child processes (pkispawn, etc.). Hence the >>> KRB5CCNAME >>> environment variable is not available outside the install script. >> >> Yes, but what if you call a child process after the context manager >> exits? >> I know that currently there is no code after the context manager >> exits, but that's no reason to surprise people who will want to reuse >> it later. >> >> Context managers are expected to clean up after themselves. If there's >> no way to do this then you should at least document that this one is >> special. But in this case it shouldn't be that hard to clean up. >> > Not at all, I actually had the code there at some point, but removed it. > > Updated patch attached. > > Tomas Thanks. ACK, pushed to master, ipa-3-2. master: 6f51f92138ff12eff732bf028751dcfa8ef9b442 ipa-3-2: 4ec1de1a65f1fabe7f5b26b4c4487deec5cea0cf -- Petr? From pvoborni at redhat.com Wed Jun 5 10:49:49 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 05 Jun 2013 12:49:49 +0200 Subject: [Freeipa-devel] [RFE] Integration testing In-Reply-To: <51AE2186.1090805@redhat.com> References: <51AC8675.6050600@redhat.com> <51AE12A8.5000607@redhat.com> <51AE2186.1090805@redhat.com> Message-ID: <51AF17CD.5000909@redhat.com> On 06/04/2013 07:19 PM, Petr Viktorin wrote: > On 06/04/2013 06:15 PM, Petr Vobornik wrote: >> Hello, >> >> Some Qs: >> >> 1) does the configuration only mean: "We have this topology, run all >> test which fits into it"? > > Not quite, it means "We have these machines, run tests whose topology > can fit on them". > >> IDK how should Web UI or XML-RPC tests fit >> into it. > > The existing test suite, including the RPC tests, stays as it is. > The > single-machine tests generally expect IPA to be set up on the local > machine. > I wouldn't make that assumption. We should allow to have test runner and FreeIPA server on different machines. >> The difference is that configuration for Web UI tests should >> mean: "This is how FreeIPA and related stuff is installed. Tests all >> available functionality and don't test the missing." IE. if I install >> freeipa server without CA, the UI tests needs to get that info (ie. by >> no_ca flag) and then skip certificate tests or parts of other tests >> which touches this feature (like navigation tests). The same for no-dns >> and has-trust... >> >> Complete UI testing would be something like following: >> a) set configuration A >> b) install server with configuration A >> c) run all UI tests (some may be skipped) >> i) in Firefox >> ii) in IE >> iii) in Chrome >> d) uninstall server >> e) set configuration B >> f) install server with configuration B >> g) run all UI tests (some may be skipped) >> i) in Firefox >> ii) in IE >> iii) in Chrome >> h) uninstall server >> i) repeat for config C >> ... >> >> Note:: browser change is also done by change of configuration. >> >> Is it possible? Can the configuration change or should there be other >> level of configuration which can change? Do we have time to do it? It >> may take almost a day (sequentially, with full coverage). > > This would be configured in Jenkins as several jobs: > > 1) Run UI tests with configuration A + Firefox > 2) Run UI tests with configuration A + IE > 3) Run UI tests with configuration A + Chrome > 4) Run UI tests with configuration B + Firefox > 5) Run UI tests with configuration B + IE > 6) Run UI tests with configuration B + Chrome > > If we wanted exhaustive tests it could be done as a "matrix job" ([A, > B]?[FF, IE, Chrome]), but as you say we don't have resources for that, > so we'll have to use some sane subset. > > (Note: Jenkins can aggregate results from multiple jobs, so we'd get a > single report from all these) > >> Does python nose support some master tests or can it be somehow >> configured in Jenkins so we can automate installation of IPA with >> different configurations (IE by the 'To-be-done command-line tools'). > > I'm not sure what you mean by master tests. > Jenkins can be configured to run different tests using different > configurations. > But the way I see it, the different topologies would be in different > tests, and run different checks. remember that we want a CI, not > exhaustive testing of all the possible cases. Thanks for the info. So it would be safe to have only one job for Web UI in CI, the one with most complete feature set and most supported browser(FF). All tests for various config/browser combinations can be executed manually when needed. > > The command-line tools would be for external shell-based tests; I've > heard some people might want to write those :) > >> 2) There is no configuration options for trusts. IMO we would like to >> test that. > > Options for that can be added when the trust tests are written. > >> 3) Test runner needs to connect to remote machine as root. Should a >> config option for root password be added or can we safely assume that >> there will always be other authentication method available? > > My bad, I forgot to add $IPA_ROOT_SSH_PASSWORD to the wiki page. Fixed. > > Other authentication methods can be added if needed. > -- Petr Vobornik From pspacek at redhat.com Wed Jun 5 10:53:00 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 05 Jun 2013 12:53:00 +0200 Subject: [Freeipa-devel] Announcing bind-dyndb-ldap version 3.3 Message-ID: <51AF188C.5030707@redhat.com> The FreeIPA team is proud to announce bind-dyndb-ldap version 3.2. It can be downloaded from https://fedorahosted.org/released/bind-dyndb-ldap/. The new version has also been built for Fedora 19 and now it in updates-testing: https://admin.fedoraproject.org/updates/FEDORA-2013-10003 This release includes several fixes. == Changes in 3.3 == [1] Crash triggered by missing sasl_user parameter was fixed. [2] IPv6 handling in PTR record synchronization was fixed. https://fedorahosted.org/bind-dyndb-ldap/ticket/118 [3] Authentication settings are validated more strictly. Conflicting options are reported and prevent named from starting. [4] Automatic empty zones defined in RFC 6303 are automatically unloaded if conflicting master or forward zone is defined in LDAP. https://fedorahosted.org/bind-dyndb-ldap/ticket/119 [5] Configuration without persistent search is now deprecated and informational message is logged. Support for zone_refresh will be removed in 4.x release. https://fedorahosted.org/bind-dyndb-ldap/ticket/120 == Upgrading == An server can be upgraded simply by installing updated rpms. BIND has to be restarted manually after the RPM installation. You will need to clean up configuration file /etc/named.conf if your configuration contains typos or other unsupported options. Downgrading back to any 2.x version is supported under following conditions: - new object class idnsForwardZone is not utilized - record types not supported by 2.x versions are not utilized - configured connection count is >= 3 (to prevent deadlocks in 2.x releases) == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list: http://www.redhat.com/mailman/listinfo/freeipa-users -- Petr Spacek Software engineer Red Hat From mkosek at redhat.com Wed Jun 5 10:53:54 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 05 Jun 2013 12:53:54 +0200 Subject: [Freeipa-devel] [PATCHES 0053-0055] Prompt for RID base if trusted domain SID / name is specified and vice versa In-Reply-To: <51AF0533.3060408@redhat.com> References: <518D06B1.1060904@redhat.com> <519109CC.5090300@redhat.com> <51A7436F.7060302@redhat.com> <51A87A96.6080404@redhat.com> <51A8A729.9030108@redhat.com> <51A8D498.3090901@redhat.com> <51AEF05C.30208@redhat.com> <51AF0533.3060408@redhat.com> Message-ID: <51AF18C2.70703@redhat.com> On 06/05/2013 11:30 AM, Ana Krivokapic wrote: > On 06/05/2013 10:01 AM, Tomas Babej wrote: >> On 05/31/2013 06:49 PM, Ana Krivokapic wrote: >>> On 05/31/2013 03:35 PM, Ana Krivokapic wrote: >>>> On 05/31/2013 12:25 PM, Tomas Babej wrote: >>>>> On 05/30/2013 02:17 PM, Ana Krivokapic wrote: >>>>>> On 05/13/2013 05:42 PM, Tomas Babej wrote: >>>>>>> On 05/10/2013 04:39 PM, Tomas Babej wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> this patcheset deals with https://fedorahosted.org/freeipa/ticket/3602 >>>>>>>> >>>>>>>> See commit messages for details. >>>>>>>> >>>>>>>> Tomas >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Freeipa-devel mailing list >>>>>>>> Freeipa-devel at redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>>> >>>>>>> I noticed during further development that logic in >>>>>>> interactive_prompt_callback did not follow the pre_callback logic precisely. >>>>>>> >>>>>>> Fixed patches attached. >>>>>>> >>>>>>> Tomas >>>>>> Hi, >>>>>> >>>>>> Patches work fine. >>>>>> >>>>>> I would suggest incorporating a fix for ticket >>>>>> https://fedorahosted.org/freeipa/ticket/3634 into this patchset. The >>>>>> issue from ticket #3634 is closely connected to this one, and with the >>>>>> introduction of prompt_param() functionality, including a fix for it >>>>>> would require minimal effort. You can look at my patch >>>>>> (https://www.redhat.com/archives/freeipa-devel/2013-May/msg00297.html) >>>>>> and if you think the approach is right, adjust accordingly and >>>>>> incorporate it in your patchset. >>>>>> >>>>>> Other (minor) comments: >>>>>> >>>>>> * The last change in ipalib/plugins/idrange.py seems like you wanted to >>>>>> fix the fact that the lines weren't properly indented (they weren't >>>>>> multiples of 4). However, you also need to fix the previous line (raise ...). >>>>>> * There are a lot of unused imports in ipalib/frontend.py. Since you are >>>>>> already touching imports in your patch, could you clean up the unused >>>>>> imports as well. >>>>>> >>>>>> -- >>>>>> Regards, >>>>>> >>>>>> Ana Krivokapic >>>>>> Associate Software Engineer >>>>>> FreeIPA team >>>>>> Red Hat Inc. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-devel mailing list >>>>>> Freeipa-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> >>>>> I addressed the minor issues. Updated patches are attached. >>>>> >>>>> Regarding your patch, I agree. I sent a reply to its thread. >>>>> >>>>> Tomas >>>> ACK >>>> >>> After a second look, you seem to have removed to many imports from >>> ipalib/frontend.py and now the doctests are failing. The import of >>> `Password` from `parameters` should be put back in. >>> -- >>> Regards, >>> >>> Ana Krivokapic >>> Associate Software Engineer >>> FreeIPA team >>> Red Hat Inc. >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Fixed. That actually was an unused import - when considering the code :) >> >> Thanks for catching that. >> >> Tomas > ACK for all 3 patches. Pushed to master, ipa-3-2. Martin From pviktori at redhat.com Wed Jun 5 11:04:38 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 05 Jun 2013 13:04:38 +0200 Subject: [Freeipa-devel] [RFE] Integration testing In-Reply-To: <51AF17CD.5000909@redhat.com> References: <51AC8675.6050600@redhat.com> <51AE12A8.5000607@redhat.com> <51AE2186.1090805@redhat.com> <51AF17CD.5000909@redhat.com> Message-ID: <51AF1B46.7000403@redhat.com> On 06/05/2013 12:49 PM, Petr Vobornik wrote: > On 06/04/2013 07:19 PM, Petr Viktorin wrote: >> On 06/04/2013 06:15 PM, Petr Vobornik wrote: >>> Hello, >>> >>> Some Qs: >>> >>> 1) does the configuration only mean: "We have this topology, run all >>> test which fits into it"? >> >> Not quite, it means "We have these machines, run tests whose topology >> can fit on them". >> >>> IDK how should Web UI or XML-RPC tests fit >>> into it. >> >> The existing test suite, including the RPC tests, stays as it is. > >> The >> single-machine tests generally expect IPA to be set up on the local >> machine. >> > > I wouldn't make that assumption. We should allow to have test runner and > FreeIPA server on different machines. That would mean changing our entire existing test suite. For a single machine, the test runner would basically just SSH into the server and run a command or script there. You (or Jenkins) can do that easily. >>> The difference is that configuration for Web UI tests should >>> mean: "This is how FreeIPA and related stuff is installed. Tests all >>> available functionality and don't test the missing." IE. if I install >>> freeipa server without CA, the UI tests needs to get that info (ie. by >>> no_ca flag) and then skip certificate tests or parts of other tests >>> which touches this feature (like navigation tests). The same for no-dns >>> and has-trust... >>> >>> Complete UI testing would be something like following: >>> a) set configuration A >>> b) install server with configuration A >>> c) run all UI tests (some may be skipped) >>> i) in Firefox >>> ii) in IE >>> iii) in Chrome >>> d) uninstall server >>> e) set configuration B >>> f) install server with configuration B >>> g) run all UI tests (some may be skipped) >>> i) in Firefox >>> ii) in IE >>> iii) in Chrome >>> h) uninstall server >>> i) repeat for config C >>> ... >>> >>> Note:: browser change is also done by change of configuration. >>> >>> Is it possible? Can the configuration change or should there be other >>> level of configuration which can change? Do we have time to do it? It >>> may take almost a day (sequentially, with full coverage). >> >> This would be configured in Jenkins as several jobs: >> >> 1) Run UI tests with configuration A + Firefox >> 2) Run UI tests with configuration A + IE >> 3) Run UI tests with configuration A + Chrome >> 4) Run UI tests with configuration B + Firefox >> 5) Run UI tests with configuration B + IE >> 6) Run UI tests with configuration B + Chrome >> >> If we wanted exhaustive tests it could be done as a "matrix job" ([A, >> B]?[FF, IE, Chrome]), but as you say we don't have resources for that, >> so we'll have to use some sane subset. >> >> (Note: Jenkins can aggregate results from multiple jobs, so we'd get a >> single report from all these) >> >>> Does python nose support some master tests or can it be somehow >>> configured in Jenkins so we can automate installation of IPA with >>> different configurations (IE by the 'To-be-done command-line tools'). >> >> I'm not sure what you mean by master tests. >> Jenkins can be configured to run different tests using different >> configurations. >> But the way I see it, the different topologies would be in different >> tests, and run different checks. remember that we want a CI, not >> exhaustive testing of all the possible cases. > > Thanks for the info. So it would be safe to have only one job for Web UI > in CI, the one with most complete feature set and most supported > browser(FF). All tests for various config/browser combinations can be > executed manually when needed. Yes. Additionally, if there is some subset of tests that we want to always run on another browser, we can mark them with Nose's attrib plugin, and run them in a separate job. -- Petr? From pvoborni at redhat.com Wed Jun 5 11:07:31 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 05 Jun 2013 13:07:31 +0200 Subject: [Freeipa-devel] [PATCH] 419 Fix regression: missing facet tab group labels Message-ID: <51AF1BF3.5020009@redhat.com> Currently there is only empty space between facet tabs and facet title. It's a regression caused by recent refactoring. https://fedorahosted.org/freeipa/ticket/3688 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0419-Fix-regression-missing-facet-tab-group-labels.patch Type: text/x-patch Size: 2491 bytes Desc: not available URL: From tbabej at redhat.com Wed Jun 5 11:23:16 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 05 Jun 2013 13:23:16 +0200 Subject: [Freeipa-devel] [PATCH 0065] Use private ccache in ipa-server-install In-Reply-To: <51ADCF8A.1040506@redhat.com> References: <51AC8F7B.4090408@redhat.com> <51AC9310.2090900@redhat.com> <51ADCF8A.1040506@redhat.com> Message-ID: <51AF1FA4.2090406@redhat.com> On 06/04/2013 01:29 PM, Tomas Babej wrote: > On 06/03/2013 02:58 PM, Martin Kosek wrote: >> On 06/03/2013 02:43 PM, Tomas Babej wrote: >>> Hi, >>> >>> this patch fixes the installation problems on master on F19 with >>> krb5 packages >>>> = 1.11.2-6 >>> https://fedorahosted.org/freeipa/ticket/3666 >>> >>> Tomas >> 1) Leaving cache_desc open: >> >> + (cache_desc, cache_path) = tempfile.mkstemp(prefix='krbcc') >> + os.environ['KRB5CCNAME'] = cache_path >> >> Why do we keep the descriptor open and close it at the and of the >> installation? >> Can we close it right after tempfile.mkstemp? I think we do it this >> way in >> other places in installation. >> >> 2) What about other installers where we handle Kerberos auth, like >> ipa-{replica,dns,ca}-install? >> >> A common function, other shared means, of handling KRB5CCNAME may be >> appropriate to avoid duplicating code too much. >> >> Martin > I moved the code responsible to PrivateCCache class, both for > readability and conciseness. > > Private ccache now used in replica,dns and ca the installers. I > managed to reproduce the error only with > dns-install though(fails on adding the service principal), but having > a private ccache for the installer should not hurt. > > Ipa-adtrust-install requires the admin ticket, so there shouldn't be > an issue. My reasoning was flawed here, ipa-adtrust-install attempts to re-kinit admin ticket, so it needs the private ccache as well. Sending one-liner fix. Tomas > > Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0066-Use-private-ccache-in-ipa-adtrust-install.patch Type: text/x-patch Size: 1124 bytes Desc: not available URL: From akrivoka at redhat.com Wed Jun 5 12:45:31 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 05 Jun 2013 14:45:31 +0200 Subject: [Freeipa-devel] [PATCH] 419 Fix regression: missing facet tab group labels In-Reply-To: <51AF1BF3.5020009@redhat.com> References: <51AF1BF3.5020009@redhat.com> Message-ID: <51AF32EB.40501@redhat.com> On 06/05/2013 01:07 PM, Petr Vobornik wrote: > Currently there is only empty space between facet tabs and facet title. > > It's a regression caused by recent refactoring. > > https://fedorahosted.org/freeipa/ticket/3688 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Wed Jun 5 12:44:25 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 05 Jun 2013 14:44:25 +0200 Subject: [Freeipa-devel] [PATCH 0065] Use private ccache in ipa-server-install In-Reply-To: <51AF1FA4.2090406@redhat.com> References: <51AC8F7B.4090408@redhat.com> <51AC9310.2090900@redhat.com> <51ADCF8A.1040506@redhat.com> <51AF1FA4.2090406@redhat.com> Message-ID: <51AF32A9.4030402@redhat.com> On 06/05/2013 01:23 PM, Tomas Babej wrote: > On 06/04/2013 01:29 PM, Tomas Babej wrote: >> On 06/03/2013 02:58 PM, Martin Kosek wrote: >>> On 06/03/2013 02:43 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> this patch fixes the installation problems on master on F19 with krb5 packages >>>>> = 1.11.2-6 >>>> https://fedorahosted.org/freeipa/ticket/3666 >>>> >>>> Tomas >>> 1) Leaving cache_desc open: >>> >>> + (cache_desc, cache_path) = tempfile.mkstemp(prefix='krbcc') >>> + os.environ['KRB5CCNAME'] = cache_path >>> >>> Why do we keep the descriptor open and close it at the and of the installation? >>> Can we close it right after tempfile.mkstemp? I think we do it this way in >>> other places in installation. >>> >>> 2) What about other installers where we handle Kerberos auth, like >>> ipa-{replica,dns,ca}-install? >>> >>> A common function, other shared means, of handling KRB5CCNAME may be >>> appropriate to avoid duplicating code too much. >>> >>> Martin >> I moved the code responsible to PrivateCCache class, both for readability and >> conciseness. >> >> Private ccache now used in replica,dns and ca the installers. I managed to >> reproduce the error only with >> dns-install though(fails on adding the service principal), but having a >> private ccache for the installer should not hurt. >> >> Ipa-adtrust-install requires the admin ticket, so there shouldn't be an issue. > > My reasoning was flawed here, ipa-adtrust-install attempts to re-kinit admin > ticket, so it needs the private ccache as well. > > Sending one-liner fix. > > Tomas As also discussed with Alexander on IRC, we do not want to have private ccache for ipa-adtrust-install as we deliberately re-kinit admin user to add new MS-PAC information to the ticket so that subsequent trust commands work. In other install scripts, we want to have private ccache so that we don't mess with user's default ccache. This entire problem should go away when krb5 is fixed, see https://bugzilla.redhat.com/show_bug.cgi?id=961235 Thus, your current fix for private ccaches is correct. Thanks, Martin From pvoborni at redhat.com Wed Jun 5 12:58:35 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 05 Jun 2013 14:58:35 +0200 Subject: [Freeipa-devel] [PATCH] 419 Fix regression: missing facet tab group labels In-Reply-To: <51AF32EB.40501@redhat.com> References: <51AF1BF3.5020009@redhat.com> <51AF32EB.40501@redhat.com> Message-ID: <51AF35FB.9040002@redhat.com> On 06/05/2013 02:45 PM, Ana Krivokapic wrote: > On 06/05/2013 01:07 PM, Petr Vobornik wrote: >> Currently there is only empty space between facet tabs and facet title. >> >> It's a regression caused by recent refactoring. >> >> https://fedorahosted.org/freeipa/ticket/3688 >> > ACK Pushed to master, ipa-3-2. > > -- > Regards, > > Ana Krivokapic > Associate Software Engineer > FreeIPA team > Red Hat Inc. -- Petr Vobornik From tbabej at redhat.com Wed Jun 5 12:53:57 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 05 Jun 2013 14:53:57 +0200 Subject: [Freeipa-devel] [PATCHES 0061-0063] Extend ID range types In-Reply-To: <51ACAF9B.7040300@redhat.com> References: <51ACAF9B.7040300@redhat.com> Message-ID: <51AF34E5.6080504@redhat.com> On 06/03/2013 05:00 PM, Tomas Babej wrote: > Hi, > > Sending rebased versions on top of current master. > > Tomas Hi, A rebase was needed again. I also fixed a bug in the update plugin, since it used case-sensitive comparison of objectclasses. Updated patcheset attached. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0062-3-Add-update-plugin-to-fill-in-ipaRangeType-attribute.patch Type: text/x-patch Size: 6609 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0061-3-Add-ipaRangeType-attribute-to-LDAP-Schema.patch Type: text/x-patch Size: 5854 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0063-3-Extend-idrange-commands-to-support-new-range-origin-.patch Type: text/x-patch Size: 5905 bytes Desc: not available URL: From akrivoka at redhat.com Wed Jun 5 14:14:36 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 05 Jun 2013 16:14:36 +0200 Subject: [Freeipa-devel] [PATCH] 0034 Improve handling of options in ipa-client-install Message-ID: <51AF47CC.5020709@redhat.com> Hello, The attached patch should improve handling of client re-enrollment related options of ipa-client-install. https://fedorahosted.org/freeipa/ticket/3686 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0034-Improve-handling-of-options-in-ipa-client-install.patch Type: text/x-patch Size: 1565 bytes Desc: not available URL: From mkosek at redhat.com Thu Jun 6 06:37:53 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 06 Jun 2013 08:37:53 +0200 Subject: [Freeipa-devel] [PATCH] 409 Remove redundant u'' character Message-ID: <51B02E41.4090608@redhat.com> One Python's unicode marking character was being printed by RPC plugin which then appeared in ipa-client-install output. This patch removes it. ---- Pushed as a one(two)liner to master, ipa-3-2. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-409-remove-redundant-u-character.patch Type: text/x-patch Size: 1723 bytes Desc: not available URL: From tbabej at redhat.com Thu Jun 6 09:08:30 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 06 Jun 2013 11:08:30 +0200 Subject: [Freeipa-devel] [PATCHES 0061-0063] Extend ID range types In-Reply-To: <51AF34E5.6080504@redhat.com> References: <51ACAF9B.7040300@redhat.com> <51AF34E5.6080504@redhat.com> Message-ID: <51B0518E.8050700@redhat.com> On 06/05/2013 02:53 PM, Tomas Babej wrote: > On 06/03/2013 05:00 PM, Tomas Babej wrote: >> Hi, >> >> Sending rebased versions on top of current master. >> >> Tomas > Hi, > > A rebase was needed again. > > I also fixed a bug in the update plugin, since it used case-sensitive > comparison of objectclasses. > > Updated patcheset attached. > > Tomas > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Patcheset updated with the changes required for the patch 67. Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0063-4-Extend-idrange-commands-to-support-new-range-origin-.patch Type: text/x-patch Size: 11639 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0062-4-Add-update-plugin-to-fill-in-ipaRangeType-attribute.patch Type: text/x-patch Size: 6609 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0061-4-Add-ipaRangeType-attribute-to-LDAP-Schema.patch Type: text/x-patch Size: 5854 bytes Desc: not available URL: From tbabej at redhat.com Thu Jun 6 09:10:31 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 06 Jun 2013 11:10:31 +0200 Subject: [Freeipa-devel] [PATCH 0067] Add --use-posix option that forces trusted range type Message-ID: <51B05207.4010100@redhat.com> Hi, Adds --use-posix option to ipa trust-add command. It takes two allowed values: 'yes' : the 'ipa-ad-trust-posix' range type is enforced 'no' : the 'ipa-ad-trust' range type is enforced When --use-posix option is not specified, the range type should be determined by ID range discovery. https://fedorahosted.org/freeipa/ticket/3650 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0067-Add-use-posix-option-that-forces-trusted-range-type.patch Type: text/x-patch Size: 5339 bytes Desc: not available URL: From tbabej at redhat.com Thu Jun 6 09:40:18 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 06 Jun 2013 11:40:18 +0200 Subject: [Freeipa-devel] [PATCH] 0034 Improve handling of options in ipa-client-install In-Reply-To: <51AF47CC.5020709@redhat.com> References: <51AF47CC.5020709@redhat.com> Message-ID: <51B05902.8080902@redhat.com> On 06/05/2013 04:14 PM, Ana Krivokapic wrote: > Hello, > > The attached patch should improve handling of client re-enrollment > related options of ipa-client-install. > > https://fedorahosted.org/freeipa/ticket/3686 > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Thu Jun 6 10:00:02 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 6 Jun 2013 13:00:02 +0300 Subject: [Freeipa-devel] [PATCHES 0061-0063] Extend ID range types In-Reply-To: <51B0518E.8050700@redhat.com> References: <51ACAF9B.7040300@redhat.com> <51AF34E5.6080504@redhat.com> <51B0518E.8050700@redhat.com> Message-ID: <20130606100002.GB26689@redhat.com> On Thu, 06 Jun 2013, Tomas Babej wrote: >From 0580d3c03319c72d731d0598b19e633fc536b866 Mon Sep 17 00:00:00 2001 >From: Tomas Babej >Date: Thu, 30 May 2013 14:07:09 +0200 >Subject: [PATCH 62/63] Add update plugin to fill in ipaRangeType attribute > >Previously, we deduced the range type from the range objectclass >and filled in virtual attribute in post_callback phase. > >Having a ipaRangeType attributeType in schema, we need to fill >the attribute values to ranges created in previous IPA versions. > >The plugin follows the same approach, setting ipa-local or >ipa-ad-trust value to the ipaRangeType attribute according >to the objectclass of the range. > >Part of https://fedorahosted.org/freeipa/ticket/3647 You need also to fix bootstrap template as ipaRangeType now is mandatory attribute for the range class: ----------------------------------------------------- add objectClass: top ipaIDrange ipaDomainIDRange add cn: VDA.LI_id_range add ipaBaseID: 1393400000 add ipaIDRangeSize: 200000 adding new entry "cn=VDA.LI_id_range,cn=ranges,cn=etc,dc=vda,dc=li" 2013-06-06T09:56:07Z DEBUG stderr=ldap_initialize( ldap://red.espoo.vda.li:389/??base ) ldap_add: Object class violation (65) additional info: missing attribute "ipaRangeType" required by object class "ipaIDrange" 2013-06-06T09:56:07Z CRITICAL Failed to load bootstrap-template.ldif: Command '/usr/bin/ldapmodify -v -f /tmp/tmpkOLzK2 -H ldap://red.espoo.vda.li:389 -x -D cn=Directory Manager -y /tmp/tmpHb7d4F' returned non-zero exit status 65 2013-06-06T09:56:07Z DEBUG duration: 3 seconds ------------------------------------------------------ -- / Alexander Bokovoy From tbabej at redhat.com Thu Jun 6 10:51:41 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 06 Jun 2013 12:51:41 +0200 Subject: [Freeipa-devel] [PATCH 0069] Manage ipa-otpd.socket by IPA Message-ID: <51B069BD.2070507@redhat.com> Hi, Adds a new simple service called OtpdInstance, that manages ipa-otpd.socket service. Added to server/replica installer and ipa-upgradeconfig script. https://fedorahosted.org/freeipa/ticket/3680 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0069-Manage-ipa-otpd.socket-by-IPA.patch Type: text/x-patch Size: 8628 bytes Desc: not available URL: From akrivoka at redhat.com Thu Jun 6 10:58:59 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 06 Jun 2013 12:58:59 +0200 Subject: [Freeipa-devel] [PATCH] 0035 Prevent error when running IPA commands with su/sudo Message-ID: <51B06B73.2040404@redhat.com> Hello, This patch fixes https://fedorahosted.org/freeipa/ticket/3685. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0035-Prevent-error-when-running-IPA-commands-with-su-sudo.patch Type: text/x-patch Size: 1766 bytes Desc: not available URL: From tbabej at redhat.com Thu Jun 6 11:31:24 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 06 Jun 2013 13:31:24 +0200 Subject: [Freeipa-devel] [PATCH] 0035 Prevent error when running IPA commands with su/sudo In-Reply-To: <51B06B73.2040404@redhat.com> References: <51B06B73.2040404@redhat.com> Message-ID: <51B0730C.1030900@redhat.com> On 06/06/2013 12:58 PM, Ana Krivokapic wrote: > Hello, > > This patch fixes https://fedorahosted.org/freeipa/ticket/3685. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpazdziora at redhat.com Thu Jun 6 13:45:09 2013 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Thu, 6 Jun 2013 15:45:09 +0200 Subject: [Freeipa-devel] [PATCH] 0034 Improve handling of options in ipa-client-install In-Reply-To: <51AF47CC.5020709@redhat.com> References: <51AF47CC.5020709@redhat.com> Message-ID: <20130606134509.GH30324@redhat.com> On Wed, Jun 05, 2013 at 04:14:36PM +0200, Ana Krivokapic wrote: > Hello, > > The attached patch should improve handling of client re-enrollment > related options of ipa-client-install. > > https://fedorahosted.org/freeipa/ticket/3686 [...] > > + if options.keytab and options.principal: > + root_logger.error("Options 'principal' and 'keytab' cannot be used " > + "together.") > + return CLIENT_INSTALL_ERROR > + I know that this check only explains what happens later in the code but isn't using custom principal _plus_ a keytab for that principal a valid combination? Right now, it's either principal + password, or keytab and from that keytab a specific host/* principal. Can't it be ptincipal + keytab? -- Jan Pazdziora | adelton at #ipa*, #brno Principal Software Engineer, Identity Management Engineering, Red Hat From rcritten at redhat.com Thu Jun 6 13:49:50 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 06 Jun 2013 09:49:50 -0400 Subject: [Freeipa-devel] [PATCH] 0034 Improve handling of options in ipa-client-install In-Reply-To: <20130606134509.GH30324@redhat.com> References: <51AF47CC.5020709@redhat.com> <20130606134509.GH30324@redhat.com> Message-ID: <51B0937E.30606@redhat.com> Jan Pazdziora wrote: > On Wed, Jun 05, 2013 at 04:14:36PM +0200, Ana Krivokapic wrote: >> Hello, >> >> The attached patch should improve handling of client re-enrollment >> related options of ipa-client-install. >> >> https://fedorahosted.org/freeipa/ticket/3686 > > [...] > >> >> + if options.keytab and options.principal: >> + root_logger.error("Options 'principal' and 'keytab' cannot be used " >> + "together.") >> + return CLIENT_INSTALL_ERROR >> + > > I know that this check only explains what happens later in the code > but isn't using custom principal _plus_ a keytab for that principal > a valid combination? Right now, it's either principal + password, or > keytab and from that keytab a specific host/* principal. Can't it be > ptincipal + keytab? > You do raise an interesting point. I think the assumption is that there is only one principal in the keytab. rob From tbabej at redhat.com Thu Jun 6 13:52:16 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 06 Jun 2013 15:52:16 +0200 Subject: [Freeipa-devel] [PATCH] 0034 Improve handling of options in ipa-client-install In-Reply-To: <20130606134509.GH30324@redhat.com> References: <51AF47CC.5020709@redhat.com> <20130606134509.GH30324@redhat.com> Message-ID: <51B09410.3030504@redhat.com> On 06/06/2013 03:45 PM, Jan Pazdziora wrote: > On Wed, Jun 05, 2013 at 04:14:36PM +0200, Ana Krivokapic wrote: >> Hello, >> >> The attached patch should improve handling of client re-enrollment >> related options of ipa-client-install. >> >> https://fedorahosted.org/freeipa/ticket/3686 > [...] > >> >> + if options.keytab and options.principal: >> + root_logger.error("Options 'principal' and 'keytab' cannot be used " >> + "together.") >> + return CLIENT_INSTALL_ERROR >> + > I know that this check only explains what happens later in the code > but isn't using custom principal _plus_ a keytab for that principal > a valid combination? Right now, it's either principal + password, or > keytab and from that keytab a specific host/* principal. Can't it be > ptincipal + keytab? > Currently only the host keytab is supported. This is described in the man pages / or shows up with --help option, so there should be no confusion. See http://www.freeipa.org/page/V3/Forced_client_re-enrollment The use case was to have a way how to automatically re-enroll a host that would not need sticking admin's password in the script. Tomas From tbabej at redhat.com Thu Jun 6 14:04:51 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 06 Jun 2013 16:04:51 +0200 Subject: [Freeipa-devel] [PATCH 0030] Require rid-base and secondary-rid-base options in idrange-add when trust exists In-Reply-To: <51A8DF79.9070700@redhat.com> References: <51A4C406.5000206@redhat.com> <51A8DF79.9070700@redhat.com> Message-ID: <51B09703.9080801@redhat.com> On 05/31/2013 07:35 PM, Ana Krivokapic wrote: > On 05/28/2013 04:49 PM, Ana Krivokapic wrote: >> Hello, >> >> This patch addresseshttps://fedorahosted.org/freeipa/ticket/3634 >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > This updated patch applies on top of tbabej's patches 0053-0055. > > As suggested by Tom?s( > (https://www.redhat.com/archives/freeipa-devel/2013-May/msg00352.html), I > refactored support of "mock" LDAP objects to tests/util, and modified > test_range_plugin and test_cli to use it. > -- > Regards, > > Ana Krivokapic > Associate Software Engineer > FreeIPA team > Red Hat Inc. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel I looked thoroughly at the issue here.. The ticket is a little bit confusing about that, but you need to require primary/secondary rid base for the range after ipa-adtrust-install has been run. Currently, the way your patch works, the bases are required only if at least one trust exists. [root at vm-002 labtool]# ipa-adtrust-install The log file for this installation can be found in /var/log/ipaserver-install.log [snip] Setup complete [snip] [root at vm-002 labtool]# ipa idrange-add local First Posix ID of the range: 10 Number of IDs in the range: 20 ---------------------- Added ID range "local" ---------------------- Range name: local First Posix ID of the range: 10 Number of IDs in the range: 20 Range type: local domain range After adding the trust, everything works ok: [root at vm-002 labtool]# ipa trust-find --------------- 1 trust matched --------------- Realm name: test Domain NetBIOS name: TEST Domain Security Identifier: S-1-5-21-259319770-2312917334-591429603 Trust type: Active Directory domain [root at vm-002 labtool]# ipa idrange-add local First Posix ID of the range: 10 Number of IDs in the range: 10 First RID of the corresponding RID range: 10 First RID of the secondary RID range: 20 ---------------------- Added ID range "local" ---------------------- Range name: local First Posix ID of the range: 10 Number of IDs in the range: 10 First RID of the corresponding RID range: 10 First RID of the secondary RID range: 20 Range type: local domain range We should require for primary/secondary rid base after ipa-adtrust-install has been run even if no trust is established. Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu Jun 6 16:14:29 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 06 Jun 2013 18:14:29 +0200 Subject: [Freeipa-devel] [PATCH 0064] Do not check userPassword with 7-bit plugin In-Reply-To: <51AC952C.5060607@redhat.com> References: <51AC7992.1010806@redhat.com> <51AC952C.5060607@redhat.com> Message-ID: <51B0B565.6010702@redhat.com> On 06/03/2013 03:07 PM, Tomas Babej wrote: > On 06/03/2013 01:10 PM, Tomas Babej wrote: >> Hi, >> >> Default list of attributes that are checked with 7-bit plugin >> for being 7-bit clean includes userPassword. Consecutively, one >> is unable to set passwords that contain non-ascii characters. >> >> https://fedorahosted.org/freeipa/ticket/3640 >> >> Tomas > > Proper explanation and missing newline added. > > Updated patch attached. > > Tomas > Works for me. ACK, pushed to master, ipa-3-2. Martin From mkosek at redhat.com Thu Jun 6 16:18:18 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 06 Jun 2013 18:18:18 +0200 Subject: [Freeipa-devel] [PATCH 0069] Manage ipa-otpd.socket by IPA In-Reply-To: <51B069BD.2070507@redhat.com> References: <51B069BD.2070507@redhat.com> Message-ID: <51B0B64A.1080303@redhat.com> On 06/06/2013 12:51 PM, Tomas Babej wrote: > Hi, > > Adds a new simple service called OtpdInstance, that manages > ipa-otpd.socket service. Added to server/replica installer > and ipa-upgradeconfig script. > > https://fedorahosted.org/freeipa/ticket/3680 > > Tomas > Tested with server/replica install and upgrades. Both worked fine. ACK. Pushed to master, ipa-3-2. Thanks, Martin From tbabej at redhat.com Fri Jun 7 08:23:36 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 07 Jun 2013 10:23:36 +0200 Subject: [Freeipa-devel] [PATCH] 0029 Make sure replication works after DM password is changed In-Reply-To: <51937353.3090501@redhat.com> References: <519357F3.3080408@redhat.com> <51935D92.8080407@redhat.com> <51936395.20409@redhat.com> <51937353.3090501@redhat.com> Message-ID: <51B19888.2050803@redhat.com> On 05/15/2013 01:36 PM, Ana Krivokapic wrote: > On 05/15/2013 12:29 PM, Petr Viktorin wrote: >> On 05/15/2013 12:04 PM, Tomas Babej wrote: >>> On 05/15/2013 11:40 AM, Ana Krivokapic wrote: >>>> Hello, >>>> >>>> See the commit message for details. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3594 >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> + def regenerate_ca_file(self, ca_file): >>> + dm_pwd_fd, dm_pwd_fname = tempfile.mkstemp() >>> + keydb_pwd_fd, keydb_pwd_fname = tempfile.mkstemp() >>> + >>> + os.write(dm_pwd_fd, self.dirman_password) >>> + os.close(dm_pwd_fd) >>> + >>> + keydb_pwd = '' >>> + with open('/etc/pki/pki-tomcat/password.conf') as f: >>> + for line in f.readlines(): >>> + key, value = line.strip().split('=') >>> + if key == 'internal': >>> + keydb_pwd = value >>> + break >>> + >>> + os.write(keydb_pwd_fd, keydb_pwd) >>> + os.close(keydb_pwd_fd) >>> + >>> + ipautil.run([ >>> + '/usr/bin/PKCS12Export', >>> + '-d', '/etc/pki/pki-tomcat/alias/', >>> + '-p', keydb_pwd_fname, >>> + '-w', dm_pwd_fname, >>> + '-o', ca_file >>> + ]) >>> + >>> >>> If the PKCS12Export call fails (returns non-zero code), we raise >>> exception here, and the temporary files are never removed. >>> >>> + os.remove(dm_pwd_fname) >>> + os.remove(keydb_pwd_fname) >>> >>> This might not be a big issue since mkstemp() call creates temporary >>> file readable and writable only be given user ID, >>> however, we should not leave files with passwords in plaintext on the >>> disk if it is not necessary. >>> >>> This can be easily prevented by wrapping the call up with >>> try-chatch-finally block, or using raiseonerr=False options of run >>> method. >> Or by using ipautil.write_tmp_file() -- the file it creates is always >> removed after it's closed/garbage collected, and it has a name attribute. >> > Updated patch uses `ipautil.write_tmp_file()`. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel I'm testing on a fairly updated F19 VM: I'm getting the following error when preparing the replica info file: [root at vm-002 ~]# ipa-replica-prepare vm-003.ipa.com --ip-address 192.168.122.213 Directory Manager (existing master) password: Preparing replica for vm-003.ipa.com from vm-002.ipa.com Command '/usr/bin/PKCS12Export -d /etc/pki/pki-tomcat/alias/ -p /tmp/tmp15Je9R -w /tmp/tmpCGD5Sr -o /root/cacert.p12' returned non When trying that manually: [root at vm-002 ~]# /usr/bin/PKCS12Export -d /etc/pki/pki-tomcat/alias/ -p /tmp/tmp15Je9R -w /tmp/tmpCGD5Sr -o /root/cacert.p12 Exception in thread "main" java.lang.NoClassDefFoundError: org/mozilla/jss/util/PasswordCallback at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2451) at java.lang.Class.getMethod0(Class.java:2694) at java.lang.Class.getMethod(Class.java:1622) at sun.launcher.LauncherHelper.getMainMethod(LauncherHelper.java:494) at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:486) Caused by: java.lang.ClassNotFoundException: org.mozilla.jss.util.PasswordCallback at java.net.URLClassLoader$1.run(URLClassLoader.java:366) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:423) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) ... 6 more We might need to investigate what causes this, and if the issue is not on our side, file appropriate bugs. Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Fri Jun 7 10:15:59 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 07 Jun 2013 12:15:59 +0200 Subject: [Freeipa-devel] [PATCH] 0033 Fail when adding a trust with a different range In-Reply-To: <51A87688.2070107@redhat.com> References: <51A87688.2070107@redhat.com> Message-ID: <51B1B2DF.3050101@redhat.com> On 05/31/2013 12:08 PM, Ana Krivokapic wrote: > Hello, > > This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3635. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Hi, the patch itself works as it should, I have only some refactoring comments: 1.) There already is a add_range method that is called from within trust_add's execute() and handles some range validation (currently only whether domain's SID of new and existing range are equal, my patch 67 add some more). Your patch introduces a new method validate_range() that is called from execute(), which leads to some duplication of the logic, mainly two same calls to the API (getting the info about the old range via idrange_show) I'd rather we keep all the validation in one place, preferably inside the add_range method or refactored out of it in the new method that is called only from add_range(). 2.) That being said, other parts of refactoring are nice and make code more clear, +1. Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Jun 7 11:11:30 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 07 Jun 2013 13:11:30 +0200 Subject: [Freeipa-devel] [PATCH] 0035 Prevent error when running IPA commands with su/sudo In-Reply-To: <51B0730C.1030900@redhat.com> References: <51B06B73.2040404@redhat.com> <51B0730C.1030900@redhat.com> Message-ID: <51B1BFE2.4070300@redhat.com> On 06/06/2013 01:31 PM, Tomas Babej wrote: > On 06/06/2013 12:58 PM, Ana Krivokapic wrote: >> Hello, >> >> This patch fixes https://fedorahosted.org/freeipa/ticket/3685. >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > ACK > > Tomas > Pushed to master, ipa-3-2. Martin From dpal at redhat.com Fri Jun 7 12:04:17 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 07 Jun 2013 08:04:17 -0400 Subject: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used In-Reply-To: <053.e8f59eb95b19dcdbcf715e1166fb104a@fedorahosted.org> References: <038.85636923ffc7d7f47d64dd7308c2c527@fedorahosted.org> <053.e8f59eb95b19dcdbcf715e1166fb104a@fedorahosted.org> Message-ID: <51B1CC41.30401@redhat.com> On 06/07/2013 03:47 AM, freeipa wrote: > #3668: CA-less install fails when intermediate CA is used > -------------------------------------+------------------------------------- > Reporter: jcholast | Owner: jcholast > Type: defect | Status: assigned > Priority: major | Milestone: 2013 Month 06 - > Component: | June (3.2.x bug fixing) > Installation | Version: > Resolution: | Keywords: > Blocked By: | Blocking: > Tests Updated: 0 | Affects DOC: 0 > Patch posted for review: 0 | Red Hat Bugzilla: > Source: | Effort Type: > Targeted feature: | Design link: > Design review: 0 | Fedora test page: > Chosen: | Needs UI design: > -------------------------------------+------------------------------------- > Release Notes: > > > -------------------------------------+------------------------------------- > Changes (by mkosek): > > * rhbz: 0 => > > > Comment: > > We not support intermediate CAs for external CA install or CA-less > install. Thus, this ticket cannot be easily solved extensive changes to > the installer. Related to #3274 (Pilsner milestone). > > Moving back to triage to decide what to do about this ticket. > So you are saying that CA we chain to or get the certs from should always be a root CA? Why does it matter for our code whether the CA we deal with a Root CA or not? If we are trying to say that we do not follow the chains of trust I can understand that. So the limitation is that we should always be given the certs from the same CA we chain to and not its sub CA's, right? That makes sense. Can someone describe a use case where in real life the certs would come from one CA in the chain but we would be told to chain or use a sub CA of that CA. That seems strange. What am I missing? -- 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 Fri Jun 7 12:26:20 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 07 Jun 2013 14:26:20 +0200 Subject: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used In-Reply-To: <51B1CC41.30401@redhat.com> References: <038.85636923ffc7d7f47d64dd7308c2c527@fedorahosted.org> <053.e8f59eb95b19dcdbcf715e1166fb104a@fedorahosted.org> <51B1CC41.30401@redhat.com> Message-ID: <51B1D16C.2010201@redhat.com> On 06/07/2013 02:04 PM, Dmitri Pal wrote: > On 06/07/2013 03:47 AM, freeipa wrote: >> #3668: CA-less install fails when intermediate CA is used >> -------------------------------------+------------------------------------- >> Reporter: jcholast | Owner: jcholast >> Type: defect | Status: assigned >> Priority: major | Milestone: 2013 Month 06 - >> Component: | June (3.2.x bug fixing) >> Installation | Version: >> Resolution: | Keywords: >> Blocked By: | Blocking: >> Tests Updated: 0 | Affects DOC: 0 >> Patch posted for review: 0 | Red Hat Bugzilla: >> Source: | Effort Type: >> Targeted feature: | Design link: >> Design review: 0 | Fedora test page: >> Chosen: | Needs UI design: >> -------------------------------------+------------------------------------- >> Release Notes: >> >> >> -------------------------------------+------------------------------------- >> Changes (by mkosek): >> >> * rhbz: 0 => >> >> >> Comment: >> >> We not support intermediate CAs for external CA install or CA-less >> install. Thus, this ticket cannot be easily solved extensive changes to >> the installer. Related to #3274 (Pilsner milestone). >> >> Moving back to triage to decide what to do about this ticket. >> > So you are saying that CA we chain to or get the certs from should > always be a root CA? > Why does it matter for our code whether the CA we deal with a Root CA or > not? No, this is a case when a CA you pass for FreeIPA is not a direct "parent" of HTTP/DIRSRV certificates, i.e. there is an intermediate CA between the CA passed to IPA and the actual certs. It should not mean that the root CA you pass to IPA must be necessarily a root CA of the entire chain. Jan, is this correct? Can you elaborate? > If we are trying to say that we do not follow the chains of trust I can > understand that. So the limitation is that we should always be given the > certs from the same CA we chain to and not its sub CA's, right? That > makes sense. > > Can someone describe a use case where in real life the certs would come > from one CA in the chain but we would be told to chain or use a sub CA > of that CA. That seems strange. What am I missing? From dpal at redhat.com Fri Jun 7 12:54:56 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 07 Jun 2013 08:54:56 -0400 Subject: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used In-Reply-To: <51B1D16C.2010201@redhat.com> References: <038.85636923ffc7d7f47d64dd7308c2c527@fedorahosted.org> <053.e8f59eb95b19dcdbcf715e1166fb104a@fedorahosted.org> <51B1CC41.30401@redhat.com> <51B1D16C.2010201@redhat.com> Message-ID: <51B1D820.3090304@redhat.com> On 06/07/2013 08:26 AM, Martin Kosek wrote: > On 06/07/2013 02:04 PM, Dmitri Pal wrote: >> On 06/07/2013 03:47 AM, freeipa wrote: >>> #3668: CA-less install fails when intermediate CA is used >>> -------------------------------------+------------------------------------- >>> Reporter: jcholast | Owner: jcholast >>> Type: defect | Status: assigned >>> Priority: major | Milestone: 2013 Month 06 - >>> Component: | June (3.2.x bug fixing) >>> Installation | Version: >>> Resolution: | Keywords: >>> Blocked By: | Blocking: >>> Tests Updated: 0 | Affects DOC: 0 >>> Patch posted for review: 0 | Red Hat Bugzilla: >>> Source: | Effort Type: >>> Targeted feature: | Design link: >>> Design review: 0 | Fedora test page: >>> Chosen: | Needs UI design: >>> -------------------------------------+------------------------------------- >>> Release Notes: >>> >>> >>> -------------------------------------+------------------------------------- >>> Changes (by mkosek): >>> >>> * rhbz: 0 => >>> >>> >>> Comment: >>> >>> We not support intermediate CAs for external CA install or CA-less >>> install. Thus, this ticket cannot be easily solved extensive changes to >>> the installer. Related to #3274 (Pilsner milestone). >>> >>> Moving back to triage to decide what to do about this ticket. >>> >> So you are saying that CA we chain to or get the certs from should >> always be a root CA? >> Why does it matter for our code whether the CA we deal with a Root CA or >> not? > No, this is a case when a CA you pass for FreeIPA is not a direct "parent" of > HTTP/DIRSRV certificates, i.e. there is an intermediate CA between the CA > passed to IPA and the actual certs. My question is what prevents you to give IPA the certs from the direct parent. What is the use case or real world scenario where the parent certs are not available? Just trying to wrap my head. I have CA 1 and CA 2. CA 2 is a sub CA of 1. I have certs from CA 1 If I pass them to IPA but point to CA2 it would not work. OK The example can be that CA1 is a public CA and CA2 is my CA. But what prevents me from giving IPA the certs from CA2? Why would I try to give IPA certs from CA1? Do I understand the scenario correctly? > > It should not mean that the root CA you pass to IPA must be necessarily a root > CA of the entire chain. Jan, is this correct? Can you elaborate? > >> If we are trying to say that we do not follow the chains of trust I can >> understand that. So the limitation is that we should always be given the >> certs from the same CA we chain to and not its sub CA's, right? That >> makes sense. >> >> Can someone describe a use case where in real life the certs would come >> from one CA in the chain but we would be told to chain or use a sub CA >> of that CA. That seems strange. What am I missing? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jcholast at redhat.com Fri Jun 7 12:57:55 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 07 Jun 2013 14:57:55 +0200 Subject: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used In-Reply-To: <51B1D16C.2010201@redhat.com> References: <038.85636923ffc7d7f47d64dd7308c2c527@fedorahosted.org> <053.e8f59eb95b19dcdbcf715e1166fb104a@fedorahosted.org> <51B1CC41.30401@redhat.com> <51B1D16C.2010201@redhat.com> Message-ID: <51B1D8D3.6070502@redhat.com> On 7.6.2013 14:26, Martin Kosek wrote: > On 06/07/2013 02:04 PM, Dmitri Pal wrote: >> On 06/07/2013 03:47 AM, freeipa wrote: >>> #3668: CA-less install fails when intermediate CA is used >>> -------------------------------------+------------------------------------- >>> Reporter: jcholast | Owner: jcholast >>> Type: defect | Status: assigned >>> Priority: major | Milestone: 2013 Month 06 - >>> Component: | June (3.2.x bug fixing) >>> Installation | Version: >>> Resolution: | Keywords: >>> Blocked By: | Blocking: >>> Tests Updated: 0 | Affects DOC: 0 >>> Patch posted for review: 0 | Red Hat Bugzilla: >>> Source: | Effort Type: >>> Targeted feature: | Design link: >>> Design review: 0 | Fedora test page: >>> Chosen: | Needs UI design: >>> -------------------------------------+------------------------------------- >>> Release Notes: >>> >>> >>> -------------------------------------+------------------------------------- >>> Changes (by mkosek): >>> >>> * rhbz: 0 => >>> >>> >>> Comment: >>> >>> We not support intermediate CAs for external CA install or CA-less >>> install. Thus, this ticket cannot be easily solved extensive changes to >>> the installer. Related to #3274 (Pilsner milestone). >>> >>> Moving back to triage to decide what to do about this ticket. >>> >> So you are saying that CA we chain to or get the certs from should >> always be a root CA? >> Why does it matter for our code whether the CA we deal with a Root CA or >> not? > > No, this is a case when a CA you pass for FreeIPA is not a direct "parent" of > HTTP/DIRSRV certificates, i.e. there is an intermediate CA between the CA > passed to IPA and the actual certs. > > It should not mean that the root CA you pass to IPA must be necessarily a root > CA of the entire chain. Jan, is this correct? Can you elaborate? Yes, this is correct. The DS certificate must be directly signed by the CA trusted by IPA (specified by --root-ca-cert in ipa-server-install), there may be no intermediate CAs, because ldapsearch and friends and python-ldap don't like them. Honza -- Jan Cholasta From mkosek at redhat.com Fri Jun 7 12:58:43 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 07 Jun 2013 14:58:43 +0200 Subject: [Freeipa-devel] Configuring FreeIPA with JBoss EAP Message-ID: <51B1D903.8060303@redhat.com> Hello Jan a Peter, freeipa-devel users, There was recently a project of integrating FreeIPA server with Jboss EAP. One of the results of this project should be a script able to conveniently configure JBoss EAP on a machine to use FreeIPA as an identity&authentication backend. What I would like to find out is what would be the best place to store&maintain such script. AFAIK, JBoss EAP did not want to keep the configuration script with their project - can you Peter please share the reasons for it? I was thinking it would be then easier to maintain the script according to JBoss EAP releases. Second option would be to deploy the script with FreeIPA project. Then, they would also conform to FreeIPA release schedule and not JBoss ones. So I was pondering where should we put scripts like this one, it is quite a specific script, so I do not want to keeping it with freeipa-client package. In this case I would propose creating a new optional subpackage "freeipa-client-jboss" which would include all scripts/docs for the JBoss EAP integration (may extend in future). In future, there may also come more thematic FreeIPA integration scripts when they cannot be stored in relevant upstream projects. Any ideas? Is the correct approach to keep configuration scripts for other upstream projects? Thanks, Martin From jcholast at redhat.com Fri Jun 7 13:08:48 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 07 Jun 2013 15:08:48 +0200 Subject: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used In-Reply-To: <51B1D820.3090304@redhat.com> References: <038.85636923ffc7d7f47d64dd7308c2c527@fedorahosted.org> <053.e8f59eb95b19dcdbcf715e1166fb104a@fedorahosted.org> <51B1CC41.30401@redhat.com> <51B1D16C.2010201@redhat.com> <51B1D820.3090304@redhat.com> Message-ID: <51B1DB60.2010705@redhat.com> On 7.6.2013 14:54, Dmitri Pal wrote: > On 06/07/2013 08:26 AM, Martin Kosek wrote: >> On 06/07/2013 02:04 PM, Dmitri Pal wrote: >>> On 06/07/2013 03:47 AM, freeipa wrote: >>>> #3668: CA-less install fails when intermediate CA is used >>>> -------------------------------------+------------------------------------- >>>> Reporter: jcholast | Owner: jcholast >>>> Type: defect | Status: assigned >>>> Priority: major | Milestone: 2013 Month 06 - >>>> Component: | June (3.2.x bug fixing) >>>> Installation | Version: >>>> Resolution: | Keywords: >>>> Blocked By: | Blocking: >>>> Tests Updated: 0 | Affects DOC: 0 >>>> Patch posted for review: 0 | Red Hat Bugzilla: >>>> Source: | Effort Type: >>>> Targeted feature: | Design link: >>>> Design review: 0 | Fedora test page: >>>> Chosen: | Needs UI design: >>>> -------------------------------------+------------------------------------- >>>> Release Notes: >>>> >>>> >>>> -------------------------------------+------------------------------------- >>>> Changes (by mkosek): >>>> >>>> * rhbz: 0 => >>>> >>>> >>>> Comment: >>>> >>>> We not support intermediate CAs for external CA install or CA-less >>>> install. Thus, this ticket cannot be easily solved extensive changes to >>>> the installer. Related to #3274 (Pilsner milestone). >>>> >>>> Moving back to triage to decide what to do about this ticket. >>>> >>> So you are saying that CA we chain to or get the certs from should >>> always be a root CA? >>> Why does it matter for our code whether the CA we deal with a Root CA or >>> not? >> No, this is a case when a CA you pass for FreeIPA is not a direct "parent" of >> HTTP/DIRSRV certificates, i.e. there is an intermediate CA between the CA >> passed to IPA and the actual certs. > > My question is what prevents you to give IPA the certs from the direct > parent. What is the use case or real world scenario where the parent > certs are not available? > Just trying to wrap my head. > > I have CA 1 and CA 2. CA 2 is a sub CA of 1. > I have certs from CA 1 > If I pass them to IPA but point to CA2 it would not work. OK > The example can be that CA1 is a public CA and CA2 is my CA. But what > prevents me from giving IPA the certs from CA2? Why would I try to give > IPA certs from CA1? > > Do I understand the scenario correctly? > Nothing is preventing you to give IPA certs from CA2, this works fine. The problem is that if you pass IPA certificates issued by CA2 and point it to CA1 at the same time, it does not work (despite having the complete trust chain). Honza -- Jan Cholasta From jdennis at redhat.com Fri Jun 7 13:17:57 2013 From: jdennis at redhat.com (John Dennis) Date: Fri, 07 Jun 2013 09:17:57 -0400 Subject: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used In-Reply-To: <51B1D8D3.6070502@redhat.com> References: <038.85636923ffc7d7f47d64dd7308c2c527@fedorahosted.org> <053.e8f59eb95b19dcdbcf715e1166fb104a@fedorahosted.org> <51B1CC41.30401@redhat.com> <51B1D16C.2010201@redhat.com> <51B1D8D3.6070502@redhat.com> Message-ID: <51B1DD85.9010001@redhat.com> On 06/07/2013 08:57 AM, Jan Cholasta wrote: > Yes, this is correct. The DS certificate must be directly signed by the > CA trusted by IPA (specified by --root-ca-cert in ipa-server-install), > there may be no intermediate CAs, because ldapsearch and friends and > python-ldap don't like them. That doesn't sound right. Do we understand why a chain length > 1 is failing? John From dpal at redhat.com Fri Jun 7 13:21:28 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 07 Jun 2013 09:21:28 -0400 Subject: [Freeipa-devel] Configuring FreeIPA with JBoss EAP In-Reply-To: <51B1D903.8060303@redhat.com> References: <51B1D903.8060303@redhat.com> Message-ID: <51B1DE58.5060903@redhat.com> On 06/07/2013 08:58 AM, Martin Kosek wrote: > Hello Jan a Peter, freeipa-devel users, > > There was recently a project of integrating FreeIPA server with Jboss EAP. One > of the results of this project should be a script able to conveniently > configure JBoss EAP on a machine to use FreeIPA as an identity&authentication > backend. > > What I would like to find out is what would be the best place to store&maintain > such script. AFAIK, JBoss EAP did not want to keep the configuration script > with their project - can you Peter please share the reasons for it? I was > thinking it would be then easier to maintain the script according to JBoss EAP > releases. > > Second option would be to deploy the script with FreeIPA project. Then, they > would also conform to FreeIPA release schedule and not JBoss ones. So I was > pondering where should we put scripts like this one, it is quite a specific > script, so I do not want to keeping it with freeipa-client package. > > In this case I would propose creating a new optional subpackage > "freeipa-client-jboss" which would include all scripts/docs for the JBoss EAP > integration (may extend in future). In future, there may also come more > thematic FreeIPA integration scripts when they cannot be stored in relevant > upstream projects. > > Any ideas? Is the correct approach to keep configuration scripts for other > upstream projects? There are two parts of the question: 1) Code aspect 2) RPM/SRPM aspect IMO the code can live in IPA git repo in a separate directory or be a completely separate source code project. We can start with IPA repo and spin it off like we did with the ding-libs if we see a need. As for packaging IMO it should be a separate SRPM (or a part of IPA for now) and produce a separate rpm that should be conditionally installed if IPA client and EAP are installed on the same system. I wonder if rpm can do that? Sounds like a conditional require (if something like this is possible). 2c. > > Thanks, > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Fri Jun 7 13:23:48 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 07 Jun 2013 09:23:48 -0400 Subject: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used In-Reply-To: <51B1DB60.2010705@redhat.com> References: <038.85636923ffc7d7f47d64dd7308c2c527@fedorahosted.org> <053.e8f59eb95b19dcdbcf715e1166fb104a@fedorahosted.org> <51B1CC41.30401@redhat.com> <51B1D16C.2010201@redhat.com> <51B1D820.3090304@redhat.com> <51B1DB60.2010705@redhat.com> Message-ID: <51B1DEE4.6090300@redhat.com> On 06/07/2013 09:08 AM, Jan Cholasta wrote: > On 7.6.2013 14:54, Dmitri Pal wrote: >> On 06/07/2013 08:26 AM, Martin Kosek wrote: >>> On 06/07/2013 02:04 PM, Dmitri Pal wrote: >>>> On 06/07/2013 03:47 AM, freeipa wrote: >>>>> #3668: CA-less install fails when intermediate CA is used >>>>> -------------------------------------+------------------------------------- >>>>> >>>>> Reporter: jcholast | Owner: jcholast >>>>> Type: defect | Status: assigned >>>>> Priority: major | Milestone: 2013 >>>>> Month 06 - >>>>> Component: | June (3.2.x bug fixing) >>>>> Installation | Version: >>>>> Resolution: | Keywords: >>>>> Blocked By: | Blocking: >>>>> Tests Updated: 0 | Affects DOC: 0 >>>>> Patch posted for review: 0 | Red Hat Bugzilla: >>>>> Source: | Effort Type: >>>>> Targeted feature: | Design link: >>>>> Design review: 0 | Fedora test page: >>>>> Chosen: | Needs UI design: >>>>> -------------------------------------+------------------------------------- >>>>> >>>>> Release Notes: >>>>> >>>>> >>>>> -------------------------------------+------------------------------------- >>>>> >>>>> Changes (by mkosek): >>>>> >>>>> * rhbz: 0 => >>>>> >>>>> >>>>> Comment: >>>>> >>>>> We not support intermediate CAs for external CA install or CA-less >>>>> install. Thus, this ticket cannot be easily solved extensive >>>>> changes to >>>>> the installer. Related to #3274 (Pilsner milestone). >>>>> >>>>> Moving back to triage to decide what to do about this ticket. >>>>> >>>> So you are saying that CA we chain to or get the certs from should >>>> always be a root CA? >>>> Why does it matter for our code whether the CA we deal with a Root >>>> CA or >>>> not? >>> No, this is a case when a CA you pass for FreeIPA is not a direct >>> "parent" of >>> HTTP/DIRSRV certificates, i.e. there is an intermediate CA between >>> the CA >>> passed to IPA and the actual certs. >> >> My question is what prevents you to give IPA the certs from the direct >> parent. What is the use case or real world scenario where the parent >> certs are not available? >> Just trying to wrap my head. >> >> I have CA 1 and CA 2. CA 2 is a sub CA of 1. >> I have certs from CA 1 >> If I pass them to IPA but point to CA2 it would not work. OK >> The example can be that CA1 is a public CA and CA2 is my CA. But what >> prevents me from giving IPA the certs from CA2? Why would I try to give >> IPA certs from CA1? >> >> Do I understand the scenario correctly? >> > > Nothing is preventing you to give IPA certs from CA2, this works fine. > > The problem is that if you pass IPA certificates issued by CA2 and > point it to CA1 at the same time, it does not work (despite having the > complete trust chain). > > Honza > But why would you do so? What would be the reason and business case? Why not to point to CA2? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jcholast at redhat.com Fri Jun 7 13:26:36 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 07 Jun 2013 15:26:36 +0200 Subject: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used In-Reply-To: <51B1DD85.9010001@redhat.com> References: <038.85636923ffc7d7f47d64dd7308c2c527@fedorahosted.org> <053.e8f59eb95b19dcdbcf715e1166fb104a@fedorahosted.org> <51B1CC41.30401@redhat.com> <51B1D16C.2010201@redhat.com> <51B1D8D3.6070502@redhat.com> <51B1DD85.9010001@redhat.com> Message-ID: <51B1DF8C.2020108@redhat.com> On 7.6.2013 15:17, John Dennis wrote: > On 06/07/2013 08:57 AM, Jan Cholasta wrote: >> Yes, this is correct. The DS certificate must be directly signed by the >> CA trusted by IPA (specified by --root-ca-cert in ipa-server-install), >> there may be no intermediate CAs, because ldapsearch and friends and >> python-ldap don't like them. > > That doesn't sound right. Do we understand why a chain length > 1 is > failing? > LDAP utilities and python-ldap only trust certificates directly issued by CAs you point them to (at least on Fedora 18). Honza -- Jan Cholasta From tbabej at redhat.com Fri Jun 7 13:31:36 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 07 Jun 2013 15:31:36 +0200 Subject: [Freeipa-devel] [PATCHES 0061-0063] Extend ID range types In-Reply-To: <20130606100002.GB26689@redhat.com> References: <51ACAF9B.7040300@redhat.com> <51AF34E5.6080504@redhat.com> <51B0518E.8050700@redhat.com> <20130606100002.GB26689@redhat.com> Message-ID: <51B1E0B8.7030806@redhat.com> On 06/06/2013 12:00 PM, Alexander Bokovoy wrote: > On Thu, 06 Jun 2013, Tomas Babej wrote: >> From 0580d3c03319c72d731d0598b19e633fc536b866 Mon Sep 17 00:00:00 2001 >> From: Tomas Babej >> Date: Thu, 30 May 2013 14:07:09 +0200 >> Subject: [PATCH 62/63] Add update plugin to fill in ipaRangeType >> attribute >> >> Previously, we deduced the range type from the range objectclass >> and filled in virtual attribute in post_callback phase. >> >> Having a ipaRangeType attributeType in schema, we need to fill >> the attribute values to ranges created in previous IPA versions. >> >> The plugin follows the same approach, setting ipa-local or >> ipa-ad-trust value to the ipaRangeType attribute according >> to the objectclass of the range. >> >> Part of https://fedorahosted.org/freeipa/ticket/3647 > You need also to fix bootstrap template as ipaRangeType now is mandatory > attribute for the range class: > Updated patches attached. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0063-5-Extend-idrange-commands-to-support-new-range-origin-.patch Type: text/x-patch Size: 11678 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0062-5-Add-update-plugin-to-fill-in-ipaRangeType-attribute.patch Type: text/x-patch Size: 6609 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0061-5-Add-ipaRangeType-attribute-to-LDAP-Schema.patch Type: text/x-patch Size: 6334 bytes Desc: not available URL: From mkosek at redhat.com Fri Jun 7 13:31:41 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 07 Jun 2013 15:31:41 +0200 Subject: [Freeipa-devel] Configuring FreeIPA with JBoss EAP In-Reply-To: <51B1DE58.5060903@redhat.com> References: <51B1D903.8060303@redhat.com> <51B1DE58.5060903@redhat.com> Message-ID: <51B1E0BD.1010604@redhat.com> On 06/07/2013 03:21 PM, Dmitri Pal wrote: > On 06/07/2013 08:58 AM, Martin Kosek wrote: >> Hello Jan a Peter, freeipa-devel users, >> >> There was recently a project of integrating FreeIPA server with Jboss EAP. One >> of the results of this project should be a script able to conveniently >> configure JBoss EAP on a machine to use FreeIPA as an identity&authentication >> backend. >> >> What I would like to find out is what would be the best place to store&maintain >> such script. AFAIK, JBoss EAP did not want to keep the configuration script >> with their project - can you Peter please share the reasons for it? I was >> thinking it would be then easier to maintain the script according to JBoss EAP >> releases. >> >> Second option would be to deploy the script with FreeIPA project. Then, they >> would also conform to FreeIPA release schedule and not JBoss ones. So I was >> pondering where should we put scripts like this one, it is quite a specific >> script, so I do not want to keeping it with freeipa-client package. >> >> In this case I would propose creating a new optional subpackage >> "freeipa-client-jboss" which would include all scripts/docs for the JBoss EAP >> integration (may extend in future). In future, there may also come more >> thematic FreeIPA integration scripts when they cannot be stored in relevant >> upstream projects. >> >> Any ideas? Is the correct approach to keep configuration scripts for other >> upstream projects? > > There are two parts of the question: > 1) Code aspect > 2) RPM/SRPM aspect > > IMO the code can live in IPA git repo in a separate directory or be a > completely separate source code project. > We can start with IPA repo and spin it off like we did with the > ding-libs if we see a need. Yes, we can start small and see how it goes further. > > As for packaging IMO it should be a separate SRPM (or a part of IPA for > now) and produce a separate rpm that should be conditionally installed > if IPA client and EAP are installed on the same system. I wonder if rpm > can do that? Sounds like a conditional require (if something like this > is possible). > > 2c. What is the advantage of separate SRPM? I planned to produce a separate rpm, i.e. freeipa-client-jboss--.rpm which would require freeipa-client package (or in JBoss's case maybe also on freeipa-server package). I am not sure if we can make it require also JBoss EAP - AFAIK, they ship the project only via ZIP files, so no rpm tricks :-( Martin From abokovoy at redhat.com Fri Jun 7 13:31:46 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 7 Jun 2013 16:31:46 +0300 Subject: [Freeipa-devel] Configuring FreeIPA with JBoss EAP In-Reply-To: <51B1DE58.5060903@redhat.com> References: <51B1D903.8060303@redhat.com> <51B1DE58.5060903@redhat.com> Message-ID: <20130607133146.GG26689@redhat.com> On Fri, 07 Jun 2013, Dmitri Pal wrote: >On 06/07/2013 08:58 AM, Martin Kosek wrote: >> Hello Jan a Peter, freeipa-devel users, >> >> There was recently a project of integrating FreeIPA server with Jboss EAP. One >> of the results of this project should be a script able to conveniently >> configure JBoss EAP on a machine to use FreeIPA as an identity&authentication >> backend. >> >> What I would like to find out is what would be the best place to store&maintain >> such script. AFAIK, JBoss EAP did not want to keep the configuration script >> with their project - can you Peter please share the reasons for it? I was >> thinking it would be then easier to maintain the script according to JBoss EAP >> releases. >> >> Second option would be to deploy the script with FreeIPA project. Then, they >> would also conform to FreeIPA release schedule and not JBoss ones. So I was >> pondering where should we put scripts like this one, it is quite a specific >> script, so I do not want to keeping it with freeipa-client package. >> >> In this case I would propose creating a new optional subpackage >> "freeipa-client-jboss" which would include all scripts/docs for the JBoss EAP >> integration (may extend in future). In future, there may also come more >> thematic FreeIPA integration scripts when they cannot be stored in relevant >> upstream projects. >> >> Any ideas? Is the correct approach to keep configuration scripts for other >> upstream projects? > >There are two parts of the question: >1) Code aspect >2) RPM/SRPM aspect > >IMO the code can live in IPA git repo in a separate directory or be a >completely separate source code project. >We can start with IPA repo and spin it off like we did with the >ding-libs if we see a need. > >As for packaging IMO it should be a separate SRPM (or a part of IPA for >now) and produce a separate rpm that should be conditionally installed >if IPA client and EAP are installed on the same system. I wonder if rpm >can do that? Sounds like a conditional require (if something like this >is possible). Not possible in rpm. What we do with trusts is equally applicable here -- a separate subpackage that holds all needed requires. In this case it would be Requires: to JBoss EAP provides. Then this separate rpm can be installed alone, pulling JBoss EAP. Also Anaconda allows to choose a collection to install. Adding 'FreeIPA Identity Management for JBoss EAP' would be relatively easy -- it is just a list of packages to pull. -- / Alexander Bokovoy From jdennis at redhat.com Fri Jun 7 13:36:16 2013 From: jdennis at redhat.com (John Dennis) Date: Fri, 07 Jun 2013 09:36:16 -0400 Subject: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used In-Reply-To: <51B1DF8C.2020108@redhat.com> References: <038.85636923ffc7d7f47d64dd7308c2c527@fedorahosted.org> <053.e8f59eb95b19dcdbcf715e1166fb104a@fedorahosted.org> <51B1CC41.30401@redhat.com> <51B1D16C.2010201@redhat.com> <51B1D8D3.6070502@redhat.com> <51B1DD85.9010001@redhat.com> <51B1DF8C.2020108@redhat.com> Message-ID: <51B1E1D0.8020800@redhat.com> On 06/07/2013 09:26 AM, Jan Cholasta wrote: > On 7.6.2013 15:17, John Dennis wrote: >> On 06/07/2013 08:57 AM, Jan Cholasta wrote: >>> Yes, this is correct. The DS certificate must be directly signed by the >>> CA trusted by IPA (specified by --root-ca-cert in ipa-server-install), >>> there may be no intermediate CAs, because ldapsearch and friends and >>> python-ldap don't like them. >> >> That doesn't sound right. Do we understand why a chain length > 1 is >> failing? >> > > LDAP utilities and python-ldap only trust certificates directly issued > by CAs you point them to (at least on Fedora 18). This sounds like a bug in MozLDAP (i.e. the NSS LDAP crypto provider). Have we filed a bug? Let's file the bug here in the Red Hat bugzilla, not upstream, we're the maintainers of MozLDAP and upstream is already frustrated with it. From jcholast at redhat.com Fri Jun 7 13:39:41 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 07 Jun 2013 15:39:41 +0200 Subject: [Freeipa-devel] [PATCHES] 134-139 CA-less fixes Message-ID: <51B1E29D.30901@redhat.com> Hi, the attached patches fix some of the issues I have found while working on test plan for CA-less install (see for more information on that). https://fedorahosted.org/freeipa/ticket/3665 https://fedorahosted.org/freeipa/ticket/3667 https://fedorahosted.org/freeipa/ticket/3673 https://fedorahosted.org/freeipa/ticket/3674 https://fedorahosted.org/freeipa/ticket/3675 Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-134-Use-the-correct-PKCS-12-file-for-HTTP-server.patch Type: text/x-patch Size: 930 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-135-Remove-stray-error-condition-in-ipa-server-install.patch Type: text/x-patch Size: 969 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-136-Handle-exceptions-gracefully-when-verifying-PKCS-12-.patch Type: text/x-patch Size: 2284 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-137-Skip-empty-lines-when-parsing-pk12util-output.patch Type: text/x-patch Size: 813 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-138-Do-not-allow-installing-CA-replicas-in-CA-less-setup.patch Type: text/x-patch Size: 1605 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-139-Do-not-track-DS-certificate-in-CA-less-setup.patch Type: text/x-patch Size: 1061 bytes Desc: not available URL: From abokovoy at redhat.com Fri Jun 7 13:41:10 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 7 Jun 2013 16:41:10 +0300 Subject: [Freeipa-devel] [PATCHES 0061-0063] Extend ID range types In-Reply-To: <51B1E0B8.7030806@redhat.com> References: <51ACAF9B.7040300@redhat.com> <51AF34E5.6080504@redhat.com> <51B0518E.8050700@redhat.com> <20130606100002.GB26689@redhat.com> <51B1E0B8.7030806@redhat.com> Message-ID: <20130607134110.GH26689@redhat.com> Hi, in patch 0061: On Fri, 07 Jun 2013, Tomas Babej wrote: >+ range_types = { >+ u'ipa-local': unicode(_(u'local domain range')), >+ u'ipa-ad-winsync': unicode(_('Active Directory winsync range')), >+ u'ipa-ad-trust': unicode(_('Active Directory domain range')), >+ u'ipa-ad-trust-posix': unicode(_('Active Directory trust range with ' >+ 'POSIX attributes')), >+ u'ipa-ipa-trust': unicode(_('IPA trust range')), >+ } Why there is _(u'local domain range') and then others without Unicode strings? Either way is fine but there should be consistency. The rest of this patch would be much shorter if there wouldn't additional whitespace. Could you please git rid of that? -- / Alexander Bokovoy From abokovoy at redhat.com Fri Jun 7 13:52:51 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 7 Jun 2013 16:52:51 +0300 Subject: [Freeipa-devel] [PATCHES 0061-0063] Extend ID range types In-Reply-To: <51B1E0B8.7030806@redhat.com> References: <51ACAF9B.7040300@redhat.com> <51AF34E5.6080504@redhat.com> <51B0518E.8050700@redhat.com> <20130606100002.GB26689@redhat.com> <51B1E0B8.7030806@redhat.com> Message-ID: <20130607135251.GI26689@redhat.com> On Fri, 07 Jun 2013, Tomas Babej wrote: >From e3b073011518f37497f08b0b4f4e34881b671a0a Mon Sep 17 00:00:00 2001 >From: Tomas Babej >Date: Thu, 30 May 2013 14:07:09 +0200 >Subject: [PATCH 62/63] Add update plugin to fill in ipaRangeType attribute > >Previously, we deduced the range type from the range objectclass >and filled in virtual attribute in post_callback phase. > >Having a ipaRangeType attributeType in schema, we need to fill >the attribute values to ranges created in previous IPA versions. > >The plugin follows the same approach, setting ipa-local or >ipa-ad-trust value to the ipaRangeType attribute according >to the objectclass of the range. > >Part of https://fedorahosted.org/freeipa/ticket/3647 ACK. -- / Alexander Bokovoy From abokovoy at redhat.com Fri Jun 7 13:54:03 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 7 Jun 2013 16:54:03 +0300 Subject: [Freeipa-devel] [PATCHES 0061-0063] Extend ID range types In-Reply-To: <51B1E0B8.7030806@redhat.com> References: <51ACAF9B.7040300@redhat.com> <51AF34E5.6080504@redhat.com> <51B0518E.8050700@redhat.com> <20130606100002.GB26689@redhat.com> <51B1E0B8.7030806@redhat.com> Message-ID: <20130607135403.GJ26689@redhat.com> On Fri, 07 Jun 2013, Tomas Babej wrote: >From 85ec5eca8a4dac379902b535b17995c0bfacb428 Mon Sep 17 00:00:00 2001 >From: Tomas Babej >Date: Thu, 30 May 2013 14:02:44 +0200 >Subject: [PATCH 61/63] Add ipaRangeType attribute to LDAP Schema > >This adds a new LDAP attribute ipaRangeType with >OID 2.16.840.1.113730.3.8.11.41 to the LDAP Schema. > >ObjectClass ipaIDrange has been altered to require >ipaRangeType attribute. > >Part of https://fedorahosted.org/freeipa/ticket/3647 ACK. -- / Alexander Bokovoy From dpal at redhat.com Fri Jun 7 14:04:24 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 07 Jun 2013 10:04:24 -0400 Subject: [Freeipa-devel] Configuring FreeIPA with JBoss EAP In-Reply-To: <20130607133146.GG26689@redhat.com> References: <51B1D903.8060303@redhat.com> <51B1DE58.5060903@redhat.com> <20130607133146.GG26689@redhat.com> Message-ID: <51B1E868.8000302@redhat.com> On 06/07/2013 09:31 AM, Alexander Bokovoy wrote: > On Fri, 07 Jun 2013, Dmitri Pal wrote: >> On 06/07/2013 08:58 AM, Martin Kosek wrote: >>> Hello Jan a Peter, freeipa-devel users, >>> >>> There was recently a project of integrating FreeIPA server with >>> Jboss EAP. One >>> of the results of this project should be a script able to conveniently >>> configure JBoss EAP on a machine to use FreeIPA as an >>> identity&authentication >>> backend. >>> >>> What I would like to find out is what would be the best place to >>> store&maintain >>> such script. AFAIK, JBoss EAP did not want to keep the configuration >>> script >>> with their project - can you Peter please share the reasons for it? >>> I was >>> thinking it would be then easier to maintain the script according to >>> JBoss EAP >>> releases. >>> >>> Second option would be to deploy the script with FreeIPA project. >>> Then, they >>> would also conform to FreeIPA release schedule and not JBoss ones. >>> So I was >>> pondering where should we put scripts like this one, it is quite a >>> specific >>> script, so I do not want to keeping it with freeipa-client package. >>> >>> In this case I would propose creating a new optional subpackage >>> "freeipa-client-jboss" which would include all scripts/docs for the >>> JBoss EAP >>> integration (may extend in future). In future, there may also come more >>> thematic FreeIPA integration scripts when they cannot be stored in >>> relevant >>> upstream projects. >>> >>> Any ideas? Is the correct approach to keep configuration scripts for >>> other >>> upstream projects? >> >> There are two parts of the question: >> 1) Code aspect >> 2) RPM/SRPM aspect >> >> IMO the code can live in IPA git repo in a separate directory or be a >> completely separate source code project. >> We can start with IPA repo and spin it off like we did with the >> ding-libs if we see a need. >> >> As for packaging IMO it should be a separate SRPM (or a part of IPA for >> now) and produce a separate rpm that should be conditionally installed >> if IPA client and EAP are installed on the same system. I wonder if rpm >> can do that? Sounds like a conditional require (if something like this >> is possible). > Not possible in rpm. > > What we do with trusts is equally applicable here -- a separate > subpackage that holds all needed requires. In this case it would be > Requires: to JBoss EAP provides. > > Then this separate rpm can be installed alone, pulling JBoss EAP. > Also Anaconda allows to choose a collection to install. Adding 'FreeIPA > Identity Management for JBoss EAP' would be relatively easy -- it is > just a list of packages to pull. > Makes sense. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From tbabej at redhat.com Fri Jun 7 14:18:19 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 07 Jun 2013 16:18:19 +0200 Subject: [Freeipa-devel] [PATCHES 0061-0063] Extend ID range types In-Reply-To: <20130607134110.GH26689@redhat.com> References: <51ACAF9B.7040300@redhat.com> <51AF34E5.6080504@redhat.com> <51B0518E.8050700@redhat.com> <20130606100002.GB26689@redhat.com> <51B1E0B8.7030806@redhat.com> <20130607134110.GH26689@redhat.com> Message-ID: <51B1EBAB.6010001@redhat.com> On 06/07/2013 03:41 PM, Alexander Bokovoy wrote: > Hi, > > in patch 0061: > > On Fri, 07 Jun 2013, Tomas Babej wrote: >> + range_types = { >> + u'ipa-local': unicode(_(u'local domain range')), >> + u'ipa-ad-winsync': unicode(_('Active Directory winsync >> range')), >> + u'ipa-ad-trust': unicode(_('Active Directory domain range')), >> + u'ipa-ad-trust-posix': unicode(_('Active Directory trust >> range with ' >> + 'POSIX attributes')), >> + u'ipa-ipa-trust': unicode(_('IPA trust range')), >> + } > Why there is _(u'local domain range') and then others without Unicode > strings? Either way is fine but there should be consistency. > Sure, fixed. > The rest of this patch would be much shorter if there wouldn't > additional whitespace. Could you please git rid of that? > Whitespaces are intentional, these are fixes for PEP8 E302 errors. Sending the whole patchset updated. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0063-6-Extend-idrange-commands-to-support-new-range-origin-.patch Type: text/x-patch Size: 11677 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0062-6-Add-update-plugin-to-fill-in-ipaRangeType-attribute.patch Type: text/x-patch Size: 6609 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0061-6-Add-ipaRangeType-attribute-to-LDAP-Schema.patch Type: text/x-patch Size: 6334 bytes Desc: not available URL: From mkosek at redhat.com Fri Jun 7 14:25:37 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 07 Jun 2013 16:25:37 +0200 Subject: [Freeipa-devel] Announcing FreeIPA 3.2.1 Message-ID: <51B1ED61.7050805@redhat.com> The FreeIPA team is proud to announce FreeIPA v3.2.1. It can be downloaded from http://www.freeipa.org/page/Downloads. The new version has also been built for Fedora 19 and is on its way to updates-testing. == Highlights in 3.2.1 == === New features for 3.2.1 === * dnszone-add command now interactively prompts user when it needs IP address of a name server instead of failing in the server phase * Improved debugging level of DNS dynamic update in ipa-client-install (see ipaclient-install.log) * Support multiple local domain ID ranges with RID base set === Bug fixes === * Directory Server CLDAP responder now returns a result in all cases to avoid timeouts or freezes with Windows DC or other tools probing this interface. * User passwords may contain non-ASCII characters again * Missing Web UI HBAC Test tab is returned back in the UI menu * Manual Web UI configuration page for other browsers (e.g. Internet Explorer 10) is fixed * Removal of ID range of an active trust is no longer allowed * ... and many others stabilization fixes, see Detailed changelog for full details == Upgrading == An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. Due to changes related to OCSP/CRL URI fix [1], ipa-ca.DOMAIN DNS name is automatically converted from a set of CNAMEs to a set of A/AAAA records pointing to FreeIPA servers with CA configured. FreeIPA servers installed with the --selfsign option will be converted to CA-less. See the section above titled "Dropped --selfsign option". Please note, that the referential integrity extension requires an extended set of indexes to be configured. RPM update for an IPA server with a excessive number of hosts, SUDO or HBAC entries may require several minutes to finish. If you have multiple servers you may upgrade them one at a time. It is expected that all servers will be upgraded in a relatively short period (days or weeks not months). They should be able to co-exist peacefully but new features will not be available on old servers and enrolling a new client against an old server will result in the SSH keys not being uploaded. Downgrading a server once upgraded is not supported. Upgrading from 2.2.0 and later versions is supported. Upgrading from previous versions is not supported and has not been tested. An enrolled client does not need the new packages installed unless you want to re-enroll it. SSH keys for already installed clients are not uploaded, you will have to re-enroll the client or manually upload the keys. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == References == [1] http://freeipa.org/page/V3/Single_OCSP_and_CRL_in_certs == Detailed Changelog since 3.2.0 == === Alexander Bokovoy (1): === * Fix cldap parser to work with a single equality filter (NtVer=...) === Ana Krivokapic (3): === * Prompt for nameserver IP address in dnszone-add * Do not display success message on failure in web UI * Prevent error when running IPA commands with su/sudo === Diane Trout (1): === * Fix log format not a string literal. === Martin Kosek (4): === * Set KRB5CCNAME so that dirsrv can work with newer krb5-server * Avoid exporting KRB5_KTNAME in dirsrv env * Remove redundant u'' character * Become 3.2.1 === Nathaniel McCallum (6): === * Add ipaUserAuthType and ipaUserAuthTypeClass * Add IPA OTP schema and ACLs * ipa-kdb: Add OTP support * Add the krb5/FreeIPA RADIUS companion daemon * Remove unnecessary prefixes from ipa-pwd-extop files * Add OTP support to ipa-pwd-extop === Petr Spacek (1): === * ipa-client-install: Add 'debug' and 'show' statements to nsupdate commands === Petr Viktorin (1): === * Remove leading zero from IPA_NUM_VERSION === Petr Vobornik (7): === * Fix: HBAC Test tab is missing * Move spec modifications from facet factories to pre_ops * Unite and move facet pre_ops to related modules * Web UI: move ./_base/metadata_provider.js to ./metadata.js * Regression fix: missing control buttons in nested search facets * Make ssbrowser.html work in IE 10 * Fix regression: missing facet tab group labels === Simo Sorce (2): === * CLDAP: Fix domain handling in netlogon requests * CLDAP: Return empty reply on non-fatal errors === Sumit Bose (1): === * Fix format string typo === Tomas Babej (9): === * Remove redundancy from hbactest help text * Support multiple local domain ranges with RID base set * Do not allow removal of ID range of an active trust * Use private ccache in ipa install tools * Remove redundant check for env.interactive * Add prompt_param method to avoid code duplication * Incorporate interactive prompts in idrange-add * Do not check userPassword with 7-bit plugin * Manage ipa-otpd.socket by IPA From abokovoy at redhat.com Fri Jun 7 15:44:18 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 7 Jun 2013 18:44:18 +0300 Subject: [Freeipa-devel] [PATCHES 0061-0063] Extend ID range types In-Reply-To: <51B1EBAB.6010001@redhat.com> References: <51ACAF9B.7040300@redhat.com> <51AF34E5.6080504@redhat.com> <51B0518E.8050700@redhat.com> <20130606100002.GB26689@redhat.com> <51B1E0B8.7030806@redhat.com> <20130607134110.GH26689@redhat.com> <51B1EBAB.6010001@redhat.com> Message-ID: <20130607154418.GK26689@redhat.com> On Fri, 07 Jun 2013, Tomas Babej wrote: > On 06/07/2013 03:41 PM, Alexander Bokovoy wrote: >> Hi, >> >> in patch 0061: >> >> On Fri, 07 Jun 2013, Tomas Babej wrote: >>> + range_types = { >>> + u'ipa-local': unicode(_(u'local domain range')), >>> + u'ipa-ad-winsync': unicode(_('Active Directory winsync >>> range')), >>> + u'ipa-ad-trust': unicode(_('Active Directory domain range')), >>> + u'ipa-ad-trust-posix': unicode(_('Active Directory >>> trust range with ' >>> + 'POSIX attributes')), >>> + u'ipa-ipa-trust': unicode(_('IPA trust range')), >>> + } >> Why there is _(u'local domain range') and then others without Unicode >> strings? Either way is fine but there should be consistency. >> > Sure, fixed. > >> The rest of this patch would be much shorter if there wouldn't >> additional whitespace. Could you please git rid of that? >> > Whitespaces are intentional, these are fixes for PEP8 E302 errors. If they are intentional, please send them as separate patch. > Sending the whole patchset updated. Please split the whitespace fixes from the functional ones. -- / Alexander Bokovoy From akrivoka at redhat.com Fri Jun 7 15:49:27 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 07 Jun 2013 17:49:27 +0200 Subject: [Freeipa-devel] [PATCH] 0033 Fail when adding a trust with a different range In-Reply-To: <51B1B2DF.3050101@redhat.com> References: <51A87688.2070107@redhat.com> <51B1B2DF.3050101@redhat.com> Message-ID: <51B20107.4050405@redhat.com> On 06/07/2013 12:15 PM, Tomas Babej wrote: > On 05/31/2013 12:08 PM, Ana Krivokapic wrote: >> Hello, >> >> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3635. >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Hi, the patch itself works as it should, I have only some refactoring comments: > > 1.) There already is a add_range method that is called from within trust_add's > execute() > and handles some range validation (currently only whether domain's SID of new and > existing range are equal, my patch 67 add some more). > > Your patch introduces a new method validate_range() that is called from execute(), > which leads to some duplication of the logic, mainly two same calls to the API > (getting > the info about the old range via idrange_show) > > I'd rather we keep all the validation in one place, preferably inside the > add_range method > or refactored out of it in the new method that is called only from add_range(). > > 2.) That being said, other parts of refactoring are nice and make code more > clear, +1. > > Tomas My first instinct was to place this validation in the add_range() method. However, add_range() is called after the trust itself is added, and validation introduced by this patch needs to happen before the trust is added (we need to prevent the addition of trust in case the validation fails). As for the code duplication, you are right about that. I tried to minimize duplication - resulting updated patch attached. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0033-02-Fail-when-adding-a-trust-with-a-different-range.patch Type: text/x-patch Size: 4641 bytes Desc: not available URL: From pskopek at redhat.com Fri Jun 7 15:52:48 2013 From: pskopek at redhat.com (Peter Skopek) Date: Fri, 07 Jun 2013 17:52:48 +0200 Subject: [Freeipa-devel] Configuring FreeIPA with JBoss EAP In-Reply-To: <51B1D903.8060303@redhat.com> References: <51B1D903.8060303@redhat.com> Message-ID: <51B201D0.5060505@redhat.com> Hi Martin, the main reason why I suggested to not include the script in EAP is that we removed all similar scripts (for example data-source definition files) from its directories to keep is as simple and clean as possible. JBoss EAP 6 configuration changes needed to integrate with FreeIPA are quite stable and as EAP has it as API/CLI it is not going to change in the near future (all JBoss EAP 6 [6.0.0, 6.0.1, 6.1.0] releases will work with configuration proposed in config. document). I can understand, that similar reasons exist in FreeIPA side. So, the best way would be your proposal to create the "freeipa-client-jboss" subpackage. Regards, Peter On 06/07/2013 02:58 PM, Martin Kosek wrote: > Hello Jan a Peter, freeipa-devel users, > > There was recently a project of integrating FreeIPA server with Jboss EAP. One > of the results of this project should be a script able to conveniently > configure JBoss EAP on a machine to use FreeIPA as an identity&authentication > backend. > > What I would like to find out is what would be the best place to store&maintain > such script. AFAIK, JBoss EAP did not want to keep the configuration script > with their project - can you Peter please share the reasons for it? I was > thinking it would be then easier to maintain the script according to JBoss EAP > releases. > > Second option would be to deploy the script with FreeIPA project. Then, they > would also conform to FreeIPA release schedule and not JBoss ones. So I was > pondering where should we put scripts like this one, it is quite a specific > script, so I do not want to keeping it with freeipa-client package. > > In this case I would propose creating a new optional subpackage > "freeipa-client-jboss" which would include all scripts/docs for the JBoss EAP > integration (may extend in future). In future, there may also come more > thematic FreeIPA integration scripts when they cannot be stored in relevant > upstream projects. > > Any ideas? Is the correct approach to keep configuration scripts for other > upstream projects? > > Thanks, > Martin > From alee at redhat.com Fri Jun 7 16:05:27 2013 From: alee at redhat.com (Ade Lee) Date: Fri, 07 Jun 2013 12:05:27 -0400 Subject: [Freeipa-devel] Announcing the release of Dogtag 10.0.3 Message-ID: <1370621127.5909.1.camel@aleeredhat.laptop> The Dogtag team is proud to announce the third errata build for Dogtag v10.0.0. Builds are available for Fedora 18 and Fedora 19 in the updates-testing repositories. Please try them out and provide karma to move them to the F18 and F19 stable repositories. == Build Versions == pki-core-10.0.3-1 pki-ra-10.0.3-1 pki-tps-10.0.3-1 dogtag-pki-10.0.3-1 dogtag-pki-theme-10.0.3-1 pki-console-10.0.3-1 == Highlights since Dogtag v. 10.0.2 == * Fixes for security flaws in the TPS as described in CVE-2013-1885 and CVE-2013-1886 * Added checking for sane lengths of the fields in subject DNs in the TPS, to prevent a TPS crash. * Previously the server certificate name was partially hard-coded. Now in Tomcat-based subsystems, it can be fully configured using pki_ssl_server_nickname parameter. * Corrections and additions to man pages and other documentation. == Detailed Changes since Dogtag v. 10.0.2 == akoneru (1): #599 Improve pkispawn "Installation Summary" block alee (1): #486 Document migration steps for dogtag 9 -> dogtag 10 instances awnuk (4): #607 Port plug-in randomizing validity #571 Port patch allowing to include in CRLs NextUpdate calculated base on ThisUpdate BZ 951501 - correcting JavaScript inability to handle big numbers BZ 966189 - fix various TPS flaws cfu (1): BZ 952500 - small patch to remove eclipse warning in fix to BZ 952500 edewata (1) #631 Hard-coded server certificate nickname. jmagne (1): BZ 963073 - rhcs81 tps crash for CN over than 64 bytes mharmsen (3): #606 add restart/start at boot info to pkispawn man page #610 Document limitation in using GUI install #629 Package ownership of '/usr/share/pki/etc/' directory From sbose at redhat.com Fri Jun 7 16:20:57 2013 From: sbose at redhat.com (Sumit Bose) Date: Fri, 7 Jun 2013 18:20:57 +0200 Subject: [Freeipa-devel] [PATCH] Fix format string typo In-Reply-To: <20130604085659.GK3487@localhost.localdomain> References: <20130603133909.GF3487@localhost.localdomain> <51AC9D1A.4070906@redhat.com> <51ADAA29.8040707@redhat.com> <20130604085659.GK3487@localhost.localdomain> Message-ID: <20130607162056.GB6550@localhost.localdomain> On Tue, Jun 04, 2013 at 10:56:59AM +0200, Sumit Bose wrote: > On Tue, Jun 04, 2013 at 10:49:45AM +0200, Petr Viktorin wrote: > > On 06/03/2013 03:41 PM, Martin Kosek wrote: > > >On 06/03/2013 03:39 PM, Sumit Bose wrote: > > >>Hi, > > >> > > >>this patch just fixes a typo. > > >> > > >>bye, > > >>Sumit > > >> > > > > > >Obvious ACK. Pushed to master, ipa-3-2. > > > > > >Martin > > > > Is the patch really right? It caused a new compiler warning: > > > > format '%lu' expects argument of type 'long unsigned int', but > > argument 6 has type 'uint32_t' [-Wformat=] > > ah, sorry, I didn't check the compiler output carefully enough, I'll > send a fix. sorry, for the delay, fix attached. bye, Sumit > > bye, > Sumit > > > > -- > > Petr? > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- From 1bbf2626a0ef5c127b35e700e7eb2e2feec6659e Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Fri, 7 Jun 2013 18:17:55 +0200 Subject: [PATCH] Fix type of printf argument --- daemons/ipa-slapi-plugins/ipa-sidgen/ipa_sidgen_common.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/daemons/ipa-slapi-plugins/ipa-sidgen/ipa_sidgen_common.c b/daemons/ipa-slapi-plugins/ipa-sidgen/ipa_sidgen_common.c index fafc55a497620024e45186b48ed84029e273f5ef..6f784804cd39acdf88ceceb0e21b272a04fa13fc 100644 --- a/daemons/ipa-slapi-plugins/ipa-sidgen/ipa_sidgen_common.c +++ b/daemons/ipa-slapi-plugins/ipa-sidgen/ipa_sidgen_common.c @@ -518,7 +518,8 @@ int find_sid_for_ldap_entry(struct slapi_entry *entry, ret = find_sid_for_id(id, plugin_id, base_dn, dom_sid, ranges, &sid); if (ret != 0) { - LOG_FATAL("Cannot convert Posix ID [%lu] into an unused SID.\n", id); + LOG_FATAL("Cannot convert Posix ID [%lu] into an unused SID.\n", + (unsigned long) id); goto done; } -- 1.8.1.4 From tbabej at redhat.com Mon Jun 10 08:52:17 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 10 Jun 2013 10:52:17 +0200 Subject: [Freeipa-devel] [PATCHES 0061-0063] Extend ID range types In-Reply-To: <20130607154418.GK26689@redhat.com> References: <51ACAF9B.7040300@redhat.com> <51AF34E5.6080504@redhat.com> <51B0518E.8050700@redhat.com> <20130606100002.GB26689@redhat.com> <51B1E0B8.7030806@redhat.com> <20130607134110.GH26689@redhat.com> <51B1EBAB.6010001@redhat.com> <20130607154418.GK26689@redhat.com> Message-ID: <51B593C1.2000204@redhat.com> On 06/07/2013 05:44 PM, Alexander Bokovoy wrote: > On Fri, 07 Jun 2013, Tomas Babej wrote: >> On 06/07/2013 03:41 PM, Alexander Bokovoy wrote: >>> Hi, >>> >>> in patch 0061: >>> >>> On Fri, 07 Jun 2013, Tomas Babej wrote: >>>> + range_types = { >>>> + u'ipa-local': unicode(_(u'local domain range')), >>>> + u'ipa-ad-winsync': unicode(_('Active Directory winsync >>>> range')), >>>> + u'ipa-ad-trust': unicode(_('Active Directory domain range')), >>>> + u'ipa-ad-trust-posix': unicode(_('Active Directory trust >>>> range with ' >>>> + 'POSIX attributes')), >>>> + u'ipa-ipa-trust': unicode(_('IPA trust range')), >>>> + } >>> Why there is _(u'local domain range') and then others without Unicode >>> strings? Either way is fine but there should be consistency. >>> >> Sure, fixed. >> >>> The rest of this patch would be much shorter if there wouldn't >>> additional whitespace. Could you please git rid of that? >>> >> Whitespaces are intentional, these are fixes for PEP8 E302 errors. > If they are intentional, please send them as separate patch. > >> Sending the whole patchset updated. > Please split the whitespace fixes from the functional ones. > No problem, patches split. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0068-7-PEP8-fixes-in-idrange.py.patch Type: text/x-patch Size: 4608 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0063-7-Extend-idrange-commands-to-support-new-range-origin-.patch Type: text/x-patch Size: 10366 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0062-7-Add-update-plugin-to-fill-in-ipaRangeType-attribute.patch Type: text/x-patch Size: 6609 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0061-7-Add-ipaRangeType-attribute-to-LDAP-Schema.patch Type: text/x-patch Size: 6334 bytes Desc: not available URL: From mkosek at redhat.com Mon Jun 10 08:57:56 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 10 Jun 2013 10:57:56 +0200 Subject: [Freeipa-devel] [PATCH] Fix format string typo In-Reply-To: <20130607162056.GB6550@localhost.localdomain> References: <20130603133909.GF3487@localhost.localdomain> <51AC9D1A.4070906@redhat.com> <51ADAA29.8040707@redhat.com> <20130604085659.GK3487@localhost.localdomain> <20130607162056.GB6550@localhost.localdomain> Message-ID: <51B59514.2090408@redhat.com> On 06/07/2013 06:20 PM, Sumit Bose wrote: > On Tue, Jun 04, 2013 at 10:56:59AM +0200, Sumit Bose wrote: >> On Tue, Jun 04, 2013 at 10:49:45AM +0200, Petr Viktorin wrote: >>> On 06/03/2013 03:41 PM, Martin Kosek wrote: >>>> On 06/03/2013 03:39 PM, Sumit Bose wrote: >>>>> Hi, >>>>> >>>>> this patch just fixes a typo. >>>>> >>>>> bye, >>>>> Sumit >>>>> >>>> >>>> Obvious ACK. Pushed to master, ipa-3-2. >>>> >>>> Martin >>> >>> Is the patch really right? It caused a new compiler warning: >>> >>> format '%lu' expects argument of type 'long unsigned int', but >>> argument 6 has type 'uint32_t' [-Wformat=] >> >> ah, sorry, I didn't check the compiler output carefully enough, I'll >> send a fix. > > sorry, for the delay, fix attached. > > bye, > Sumit Thanks! I tested it and it fixed the FreeIPA build warning. ACK. Pushed to master, ipa-3-2. Martin From tbabej at redhat.com Mon Jun 10 09:11:48 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 10 Jun 2013 11:11:48 +0200 Subject: [Freeipa-devel] [PATCH] 0033 Fail when adding a trust with a different range In-Reply-To: <51B20107.4050405@redhat.com> References: <51A87688.2070107@redhat.com> <51B1B2DF.3050101@redhat.com> <51B20107.4050405@redhat.com> Message-ID: <51B59854.1030404@redhat.com> On 06/07/2013 05:49 PM, Ana Krivokapic wrote: > On 06/07/2013 12:15 PM, Tomas Babej wrote: >> On 05/31/2013 12:08 PM, Ana Krivokapic wrote: >>> Hello, >>> >>> This patch addresses tickethttps://fedorahosted.org/freeipa/ticket/3635. >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> Hi, the patch itself works as it should, I have only some refactoring >> comments: >> >> 1.) There already is a add_range method that is called from within >> trust_add's execute() >> and handles some range validation (currently only whether domain's >> SID of new and >> existing range are equal, my patch 67 add some more). >> >> Your patch introduces a new method validate_range() that is called >> from execute(), >> which leads to some duplication of the logic, mainly two same calls >> to the API (getting >> the info about the old range via idrange_show) >> >> I'd rather we keep all the validation in one place, preferably inside >> the add_range method >> or refactored out of it in the new method that is called only from >> add_range(). >> >> 2.) That being said, other parts of refactoring are nice and make >> code more clear, +1. >> >> Tomas > > My first instinct was to place this validation in the add_range() > method. However, add_range() is called after the trust itself is > added, and validation introduced by this patch needs to happen before > the trust is added (we need to prevent the addition of trust in case > the validation fails). > > As for the code duplication, you are right about that. I tried to > minimize duplication - resulting updated patch attached. > -- > Regards, > > Ana Krivokapic > Associate Software Engineer > FreeIPA team > Red Hat Inc. While this is a nice improvement from the code repetition point of view, the patch still has one flaw as I see it - the range validation happens at two separate places: Once here(already in the code): if old_range: old_dom_sid = old_range['result']['ipanttrusteddomainsid'][0]; if old_dom_sid == dom_sid: return raise errors.ValidationError(name=_('range exists'), error=_('ID range with the same name but different ' \ 'domain SID already exists. The ID range for ' \ 'the new trusted domain must be created manually.')) And once here(added by your patch): + if not self.validate_range(*keys, **options): + raise errors.ValidationError( + name=_('id range'), + error=_( + 'An id range already exists for this trust. ' + 'You should either delete the old range, or ' + 'exclude --base-id/--range-size options from the command.' I'd suggest we have one common place, say validate_range() function as we have now, that contains all the checks (more coming in the future for sure). That would mean that the whole trust-add command will fail in the case that "ID range with the same name but different domain SID already exists", since we now call validate_range() within execute() method. I checked with Alexander and we agreed that this is more desired behaviour. This would also result to reducement of the number of API calls, which is a nice benefit. Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Mon Jun 10 09:29:01 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 10 Jun 2013 11:29:01 +0200 Subject: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used In-Reply-To: <51B1DEE4.6090300@redhat.com> References: <038.85636923ffc7d7f47d64dd7308c2c527@fedorahosted.org> <053.e8f59eb95b19dcdbcf715e1166fb104a@fedorahosted.org> <51B1CC41.30401@redhat.com> <51B1D16C.2010201@redhat.com> <51B1D820.3090304@redhat.com> <51B1DB60.2010705@redhat.com> <51B1DEE4.6090300@redhat.com> Message-ID: <51B59C5D.5070205@redhat.com> On 7.6.2013 15:23, Dmitri Pal wrote: > On 06/07/2013 09:08 AM, Jan Cholasta wrote: >> On 7.6.2013 14:54, Dmitri Pal wrote: >>> On 06/07/2013 08:26 AM, Martin Kosek wrote: >>>> On 06/07/2013 02:04 PM, Dmitri Pal wrote: >>>>> On 06/07/2013 03:47 AM, freeipa wrote: >>>>>> #3668: CA-less install fails when intermediate CA is used >>>>>> -------------------------------------+------------------------------------- >>>>>> >>>>>> Reporter: jcholast | Owner: jcholast >>>>>> Type: defect | Status: assigned >>>>>> Priority: major | Milestone: 2013 >>>>>> Month 06 - >>>>>> Component: | June (3.2.x bug fixing) >>>>>> Installation | Version: >>>>>> Resolution: | Keywords: >>>>>> Blocked By: | Blocking: >>>>>> Tests Updated: 0 | Affects DOC: 0 >>>>>> Patch posted for review: 0 | Red Hat Bugzilla: >>>>>> Source: | Effort Type: >>>>>> Targeted feature: | Design link: >>>>>> Design review: 0 | Fedora test page: >>>>>> Chosen: | Needs UI design: >>>>>> -------------------------------------+------------------------------------- >>>>>> >>>>>> Release Notes: >>>>>> >>>>>> >>>>>> -------------------------------------+------------------------------------- >>>>>> >>>>>> Changes (by mkosek): >>>>>> >>>>>> * rhbz: 0 => >>>>>> >>>>>> >>>>>> Comment: >>>>>> >>>>>> We not support intermediate CAs for external CA install or CA-less >>>>>> install. Thus, this ticket cannot be easily solved extensive >>>>>> changes to >>>>>> the installer. Related to #3274 (Pilsner milestone). >>>>>> >>>>>> Moving back to triage to decide what to do about this ticket. >>>>>> >>>>> So you are saying that CA we chain to or get the certs from should >>>>> always be a root CA? >>>>> Why does it matter for our code whether the CA we deal with a Root >>>>> CA or >>>>> not? >>>> No, this is a case when a CA you pass for FreeIPA is not a direct >>>> "parent" of >>>> HTTP/DIRSRV certificates, i.e. there is an intermediate CA between >>>> the CA >>>> passed to IPA and the actual certs. >>> >>> My question is what prevents you to give IPA the certs from the direct >>> parent. What is the use case or real world scenario where the parent >>> certs are not available? >>> Just trying to wrap my head. >>> >>> I have CA 1 and CA 2. CA 2 is a sub CA of 1. >>> I have certs from CA 1 >>> If I pass them to IPA but point to CA2 it would not work. OK >>> The example can be that CA1 is a public CA and CA2 is my CA. But what >>> prevents me from giving IPA the certs from CA2? Why would I try to give >>> IPA certs from CA1? >>> >>> Do I understand the scenario correctly? >>> >> >> Nothing is preventing you to give IPA certs from CA2, this works fine. >> >> The problem is that if you pass IPA certificates issued by CA2 and >> point it to CA1 at the same time, it does not work (despite having the >> complete trust chain). >> >> Honza >> > > But why would you do so? What would be the reason and business case? Why > not to point to CA2? > I'm not sure, but this is apparently why --root-ca-cert was added to ipa-server-install. If the CA that issued the server certificates should always be used as root CA in IPA, then --root-ca-cert is redundant. Honza -- Jan Cholasta From jcholast at redhat.com Mon Jun 10 09:54:00 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 10 Jun 2013 11:54:00 +0200 Subject: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used In-Reply-To: <51B1E1D0.8020800@redhat.com> References: <038.85636923ffc7d7f47d64dd7308c2c527@fedorahosted.org> <053.e8f59eb95b19dcdbcf715e1166fb104a@fedorahosted.org> <51B1CC41.30401@redhat.com> <51B1D16C.2010201@redhat.com> <51B1D8D3.6070502@redhat.com> <51B1DD85.9010001@redhat.com> <51B1DF8C.2020108@redhat.com> <51B1E1D0.8020800@redhat.com> Message-ID: <51B5A238.5050105@redhat.com> On 7.6.2013 15:36, John Dennis wrote: > On 06/07/2013 09:26 AM, Jan Cholasta wrote: >> On 7.6.2013 15:17, John Dennis wrote: >>> On 06/07/2013 08:57 AM, Jan Cholasta wrote: >>>> Yes, this is correct. The DS certificate must be directly signed by the >>>> CA trusted by IPA (specified by --root-ca-cert in ipa-server-install), >>>> there may be no intermediate CAs, because ldapsearch and friends and >>>> python-ldap don't like them. >>> >>> That doesn't sound right. Do we understand why a chain length > 1 is >>> failing? >>> >> >> LDAP utilities and python-ldap only trust certificates directly issued >> by CAs you point them to (at least on Fedora 18). > > This sounds like a bug in MozLDAP (i.e. the NSS LDAP crypto provider). > Have we filed a bug? Let's file the bug here in the Red Hat bugzilla, > not upstream, we're the maintainers of MozLDAP and upstream is already > frustrated with it. > I have just tested with libldap compiled with OpenSSL on my Arch Linux box, it does not work as well: $ LDAPTLS_CACERT=$PWD/ca.crt ldapsearch -H ldap://vm-131.idm.lab.bos.redhat.com -ZZ -D 'cn=Directory Manager' -W -b '' -s base ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (invalid CA certificate) For the record, this is what happens with NSS on Fedora: $ LDAPTLS_CACERT=$PWD/ca.crt ldapsearch -H ldap://vm-131.idm.lab.bos.redhat.com -ZZ -D 'cn=Directory Manager' -W -b '' -s base ldap_start_tls: Connect error (-11) additional info: TLS error -8179:Peer's Certificate issuer is not recognized. Honza -- Jan Cholasta From tbabej at redhat.com Mon Jun 10 11:13:33 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 10 Jun 2013 13:13:33 +0200 Subject: [Freeipa-devel] [PATCH 0070] Remove hardcoded values from idrange plugin tests Message-ID: <51B5B4DD.4090201@redhat.com> Hi, Hardcoded values for range parameters such as base RID or range size could be the reason the tests produced incorrect results, as the ranges could get in conflict with already existing ranges on the server. Patch dynamically chooses ID and RID range space at the end of all ranges already present on the server. https://fedorahosted.org/freeipa/ticket/3662 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0070-Remove-hardcoded-values-from-idrange-plugin-tests.patch Type: text/x-patch Size: 5682 bytes Desc: not available URL: From abokovoy at redhat.com Mon Jun 10 12:06:08 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 10 Jun 2013 15:06:08 +0300 Subject: [Freeipa-devel] [PATCHES 0061-0063] Extend ID range types In-Reply-To: <51B593C1.2000204@redhat.com> References: <51ACAF9B.7040300@redhat.com> <51AF34E5.6080504@redhat.com> <51B0518E.8050700@redhat.com> <20130606100002.GB26689@redhat.com> <51B1E0B8.7030806@redhat.com> <20130607134110.GH26689@redhat.com> <51B1EBAB.6010001@redhat.com> <20130607154418.GK26689@redhat.com> <51B593C1.2000204@redhat.com> Message-ID: <20130610120608.GM26689@redhat.com> On Mon, 10 Jun 2013, Tomas Babej wrote: > On 06/07/2013 05:44 PM, Alexander Bokovoy wrote: >> On Fri, 07 Jun 2013, Tomas Babej wrote: >>> On 06/07/2013 03:41 PM, Alexander Bokovoy wrote: >>>> Hi, >>>> >>>> in patch 0061: >>>> >>>> On Fri, 07 Jun 2013, Tomas Babej wrote: >>>>> + range_types = { >>>>> + u'ipa-local': unicode(_(u'local domain range')), >>>>> + u'ipa-ad-winsync': unicode(_('Active Directory >>>>> winsync range')), >>>>> + u'ipa-ad-trust': unicode(_('Active Directory domain range')), >>>>> + u'ipa-ad-trust-posix': unicode(_('Active Directory >>>>> trust range with ' >>>>> + 'POSIX attributes')), >>>>> + u'ipa-ipa-trust': unicode(_('IPA trust range')), >>>>> + } >>>> Why there is _(u'local domain range') and then others without Unicode >>>> strings? Either way is fine but there should be consistency. >>>> >>> Sure, fixed. >>> >>>> The rest of this patch would be much shorter if there wouldn't >>>> additional whitespace. Could you please git rid of that? >>>> >>> Whitespaces are intentional, these are fixes for PEP8 E302 errors. >> If they are intentional, please send them as separate patch. >> >>> Sending the whole patchset updated. >> Please split the whitespace fixes from the functional ones. >> > No problem, patches split. Thanks. ACK, pushed to master. -- / Alexander Bokovoy From dpal at redhat.com Mon Jun 10 12:35:04 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 10 Jun 2013 08:35:04 -0400 Subject: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used In-Reply-To: <51B5A238.5050105@redhat.com> References: <038.85636923ffc7d7f47d64dd7308c2c527@fedorahosted.org> <053.e8f59eb95b19dcdbcf715e1166fb104a@fedorahosted.org> <51B1CC41.30401@redhat.com> <51B1D16C.2010201@redhat.com> <51B1D8D3.6070502@redhat.com> <51B1DD85.9010001@redhat.com> <51B1DF8C.2020108@redhat.com> <51B1E1D0.8020800@redhat.com> <51B5A238.5050105@redhat.com> Message-ID: <51B5C7F8.5090906@redhat.com> On 06/10/2013 05:54 AM, Jan Cholasta wrote: > On 7.6.2013 15:36, John Dennis wrote: >> On 06/07/2013 09:26 AM, Jan Cholasta wrote: >>> On 7.6.2013 15:17, John Dennis wrote: >>>> On 06/07/2013 08:57 AM, Jan Cholasta wrote: >>>>> Yes, this is correct. The DS certificate must be directly signed >>>>> by the >>>>> CA trusted by IPA (specified by --root-ca-cert in >>>>> ipa-server-install), >>>>> there may be no intermediate CAs, because ldapsearch and friends and >>>>> python-ldap don't like them. >>>> >>>> That doesn't sound right. Do we understand why a chain length > 1 is >>>> failing? >>>> >>> >>> LDAP utilities and python-ldap only trust certificates directly issued >>> by CAs you point them to (at least on Fedora 18). >> >> This sounds like a bug in MozLDAP (i.e. the NSS LDAP crypto provider). >> Have we filed a bug? Let's file the bug here in the Red Hat bugzilla, >> not upstream, we're the maintainers of MozLDAP and upstream is already >> frustrated with it. >> > > I have just tested with libldap compiled with OpenSSL on my Arch Linux > box, it does not work as well: > > $ LDAPTLS_CACERT=$PWD/ca.crt ldapsearch -H > ldap://vm-131.idm.lab.bos.redhat.com -ZZ -D 'cn=Directory Manager' -W > -b '' -s base > ldap_start_tls: Connect error (-11) > additional info: error:14090086:SSL > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed > (invalid CA certificate) > > For the record, this is what happens with NSS on Fedora: > > $ LDAPTLS_CACERT=$PWD/ca.crt ldapsearch -H > ldap://vm-131.idm.lab.bos.redhat.com -ZZ -D 'cn=Directory Manager' -W > -b '' -s base > ldap_start_tls: Connect error (-11) > additional info: TLS error -8179:Peer's Certificate issuer is not > recognized. > > Honza > If the options does not work we should hide it for now and clearly state in the docs and man pages that the case when certs come from different CA is not supported for the time being. -- 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 Jun 10 13:35:57 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 10 Jun 2013 09:35:57 -0400 Subject: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used In-Reply-To: <51B5C7F8.5090906@redhat.com> References: <038.85636923ffc7d7f47d64dd7308c2c527@fedorahosted.org> <053.e8f59eb95b19dcdbcf715e1166fb104a@fedorahosted.org> <51B1CC41.30401@redhat.com> <51B1D16C.2010201@redhat.com> <51B1D8D3.6070502@redhat.com> <51B1DD85.9010001@redhat.com> <51B1DF8C.2020108@redhat.com> <51B1E1D0.8020800@redhat.com> <51B5A238.5050105@redhat.com> <51B5C7F8.5090906@redhat.com> Message-ID: <51B5D63D.3080309@redhat.com> Dmitri Pal wrote: > On 06/10/2013 05:54 AM, Jan Cholasta wrote: >> On 7.6.2013 15:36, John Dennis wrote: >>> On 06/07/2013 09:26 AM, Jan Cholasta wrote: >>>> On 7.6.2013 15:17, John Dennis wrote: >>>>> On 06/07/2013 08:57 AM, Jan Cholasta wrote: >>>>>> Yes, this is correct. The DS certificate must be directly signed >>>>>> by the >>>>>> CA trusted by IPA (specified by --root-ca-cert in >>>>>> ipa-server-install), >>>>>> there may be no intermediate CAs, because ldapsearch and friends and >>>>>> python-ldap don't like them. >>>>> >>>>> That doesn't sound right. Do we understand why a chain length > 1 is >>>>> failing? >>>>> >>>> >>>> LDAP utilities and python-ldap only trust certificates directly issued >>>> by CAs you point them to (at least on Fedora 18). >>> >>> This sounds like a bug in MozLDAP (i.e. the NSS LDAP crypto provider). >>> Have we filed a bug? Let's file the bug here in the Red Hat bugzilla, >>> not upstream, we're the maintainers of MozLDAP and upstream is already >>> frustrated with it. >>> >> >> I have just tested with libldap compiled with OpenSSL on my Arch Linux >> box, it does not work as well: >> >> $ LDAPTLS_CACERT=$PWD/ca.crt ldapsearch -H >> ldap://vm-131.idm.lab.bos.redhat.com -ZZ -D 'cn=Directory Manager' -W >> -b '' -s base >> ldap_start_tls: Connect error (-11) >> additional info: error:14090086:SSL >> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed >> (invalid CA certificate) >> >> For the record, this is what happens with NSS on Fedora: >> >> $ LDAPTLS_CACERT=$PWD/ca.crt ldapsearch -H >> ldap://vm-131.idm.lab.bos.redhat.com -ZZ -D 'cn=Directory Manager' -W >> -b '' -s base >> ldap_start_tls: Connect error (-11) >> additional info: TLS error -8179:Peer's Certificate issuer is not >> recognized. >> >> Honza >> > If the options does not work we should hide it for now and clearly state > in the docs and man pages that the case when certs come from different > CA is not supported for the time being. > IIRC it was added for two reasons: 1. Because the CA is not required to be included in the PKCS#12 file. 2. Because previous attempts to figure out the nickname of the signing CA was problematic. rob From pviktori at redhat.com Mon Jun 10 13:56:12 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 10 Jun 2013 15:56:12 +0200 Subject: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used In-Reply-To: <51B5D63D.3080309@redhat.com> References: <038.85636923ffc7d7f47d64dd7308c2c527@fedorahosted.org> <053.e8f59eb95b19dcdbcf715e1166fb104a@fedorahosted.org> <51B1CC41.30401@redhat.com> <51B1D16C.2010201@redhat.com> <51B1D8D3.6070502@redhat.com> <51B1DD85.9010001@redhat.com> <51B1DF8C.2020108@redhat.com> <51B1E1D0.8020800@redhat.com> <51B5A238.5050105@redhat.com> <51B5C7F8.5090906@redhat.com> <51B5D63D.3080309@redhat.com> Message-ID: <51B5DAFC.7040307@redhat.com> On 06/10/2013 03:35 PM, Rob Crittenden wrote: > Dmitri Pal wrote: >> On 06/10/2013 05:54 AM, Jan Cholasta wrote: >>> On 7.6.2013 15:36, John Dennis wrote: >>>> On 06/07/2013 09:26 AM, Jan Cholasta wrote: >>>>> On 7.6.2013 15:17, John Dennis wrote: >>>>>> On 06/07/2013 08:57 AM, Jan Cholasta wrote: >>>>>>> Yes, this is correct. The DS certificate must be directly signed >>>>>>> by the >>>>>>> CA trusted by IPA (specified by --root-ca-cert in >>>>>>> ipa-server-install), >>>>>>> there may be no intermediate CAs, because ldapsearch and friends and >>>>>>> python-ldap don't like them. >>>>>> >>>>>> That doesn't sound right. Do we understand why a chain length > 1 is >>>>>> failing? >>>>>> >>>>> >>>>> LDAP utilities and python-ldap only trust certificates directly issued >>>>> by CAs you point them to (at least on Fedora 18). >>>> >>>> This sounds like a bug in MozLDAP (i.e. the NSS LDAP crypto provider). >>>> Have we filed a bug? Let's file the bug here in the Red Hat bugzilla, >>>> not upstream, we're the maintainers of MozLDAP and upstream is already >>>> frustrated with it. >>>> >>> >>> I have just tested with libldap compiled with OpenSSL on my Arch Linux >>> box, it does not work as well: >>> >>> $ LDAPTLS_CACERT=$PWD/ca.crt ldapsearch -H >>> ldap://vm-131.idm.lab.bos.redhat.com -ZZ -D 'cn=Directory Manager' -W >>> -b '' -s base >>> ldap_start_tls: Connect error (-11) >>> additional info: error:14090086:SSL >>> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed >>> (invalid CA certificate) >>> >>> For the record, this is what happens with NSS on Fedora: >>> >>> $ LDAPTLS_CACERT=$PWD/ca.crt ldapsearch -H >>> ldap://vm-131.idm.lab.bos.redhat.com -ZZ -D 'cn=Directory Manager' -W >>> -b '' -s base >>> ldap_start_tls: Connect error (-11) >>> additional info: TLS error -8179:Peer's Certificate issuer is not >>> recognized. >>> >>> Honza >>> >> If the options does not work we should hide it for now and clearly state >> in the docs and man pages that the case when certs come from different >> CA is not supported for the time being. >> > > IIRC it was added for two reasons: > > 1. Because the CA is not required to be included in the PKCS#12 file. Well, that's not a necessary requirement. A tester did have a bit of trouble creating a PKCS#12 file with both the server cert and the CA cert, but the trouble is comparable to having to create a PEM file. > 2. Because previous attempts to figure out the nickname of the signing > CA was problematic. This is the main reason. It could be done, but I believe we should avoid any guessing to determine the root of trust. -- Petr? From pviktori at redhat.com Mon Jun 10 14:01:12 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 10 Jun 2013 16:01:12 +0200 Subject: [Freeipa-devel] [PATCH] 0236 Flush stream after writing service messages Message-ID: <51B5DC28.9000801@redhat.com> Hello, This is related to testing but can be pushed independently. It will make testing master much more pleasant. sys.stdout is buffered by default if redirected to a file. This may cause automated installation to appear hung. Flush the stream so that messages are written immediately. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0236-Flush-stream-after-writing-service-messages.patch Type: text/x-patch Size: 915 bytes Desc: not available URL: From akrivoka at redhat.com Mon Jun 10 14:35:43 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 10 Jun 2013 16:35:43 +0200 Subject: [Freeipa-devel] [PATCH] 0029 Make sure replication works after DM password is changed In-Reply-To: <51B19888.2050803@redhat.com> References: <519357F3.3080408@redhat.com> <51935D92.8080407@redhat.com> <51936395.20409@redhat.com> <51937353.3090501@redhat.com> <51B19888.2050803@redhat.com> Message-ID: <51B5E43F.809@redhat.com> On 06/07/2013 10:23 AM, Tomas Babej wrote: > On 05/15/2013 01:36 PM, Ana Krivokapic wrote: >> On 05/15/2013 12:29 PM, Petr Viktorin wrote: >>> On 05/15/2013 12:04 PM, Tomas Babej wrote: >>>> On 05/15/2013 11:40 AM, Ana Krivokapic wrote: >>>>> Hello, >>>>> >>>>> See the commit message for details. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3594 >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> + def regenerate_ca_file(self, ca_file): >>>> + dm_pwd_fd, dm_pwd_fname = tempfile.mkstemp() >>>> + keydb_pwd_fd, keydb_pwd_fname = tempfile.mkstemp() >>>> + >>>> + os.write(dm_pwd_fd, self.dirman_password) >>>> + os.close(dm_pwd_fd) >>>> + >>>> + keydb_pwd = '' >>>> + with open('/etc/pki/pki-tomcat/password.conf') as f: >>>> + for line in f.readlines(): >>>> + key, value = line.strip().split('=') >>>> + if key == 'internal': >>>> + keydb_pwd = value >>>> + break >>>> + >>>> + os.write(keydb_pwd_fd, keydb_pwd) >>>> + os.close(keydb_pwd_fd) >>>> + >>>> + ipautil.run([ >>>> + '/usr/bin/PKCS12Export', >>>> + '-d', '/etc/pki/pki-tomcat/alias/', >>>> + '-p', keydb_pwd_fname, >>>> + '-w', dm_pwd_fname, >>>> + '-o', ca_file >>>> + ]) >>>> + >>>> >>>> If the PKCS12Export call fails (returns non-zero code), we raise >>>> exception here, and the temporary files are never removed. >>>> >>>> + os.remove(dm_pwd_fname) >>>> + os.remove(keydb_pwd_fname) >>>> >>>> This might not be a big issue since mkstemp() call creates temporary >>>> file readable and writable only be given user ID, >>>> however, we should not leave files with passwords in plaintext on the >>>> disk if it is not necessary. >>>> >>>> This can be easily prevented by wrapping the call up with >>>> try-chatch-finally block, or using raiseonerr=False options of run >>>> method. >>> Or by using ipautil.write_tmp_file() -- the file it creates is always >>> removed after it's closed/garbage collected, and it has a name attribute. >>> >> Updated patch uses `ipautil.write_tmp_file()`. >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > I'm testing on a fairly updated F19 VM: > > I'm getting the following error when preparing the replica info file: > > [root at vm-002 ~]# ipa-replica-prepare vm-003.ipa.com --ip-address > 192.168.122.213 > Directory Manager (existing master) password: > > Preparing replica for vm-003.ipa.com from vm-002.ipa.com > Command '/usr/bin/PKCS12Export -d /etc/pki/pki-tomcat/alias/ -p > /tmp/tmp15Je9R -w /tmp/tmpCGD5Sr -o /root/cacert.p12' returned non > > When trying that manually: > > [root at vm-002 ~]# /usr/bin/PKCS12Export -d /etc/pki/pki-tomcat/alias/ > -p /tmp/tmp15Je9R -w /tmp/tmpCGD5Sr -o /root/cacert.p12 > Exception in thread "main" java.lang.NoClassDefFoundError: > org/mozilla/jss/util/PasswordCallback > at java.lang.Class.getDeclaredMethods0(Native Method) > at java.lang.Class.privateGetDeclaredMethods(Class.java:2451) > at java.lang.Class.getMethod0(Class.java:2694) > at java.lang.Class.getMethod(Class.java:1622) > at sun.launcher.LauncherHelper.getMainMethod(LauncherHelper.java:494) > at > sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:486) > Caused by: java.lang.ClassNotFoundException: > org.mozilla.jss.util.PasswordCallback > at java.net.URLClassLoader$1.run(URLClassLoader.java:366) > at java.net.URLClassLoader$1.run(URLClassLoader.java:355) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:354) > at java.lang.ClassLoader.loadClass(ClassLoader.java:423) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) > at java.lang.ClassLoader.loadClass(ClassLoader.java:356) > ... 6 more > > We might need to investigate what causes this, and if the issue is not > on our side, file appropriate bugs. > > Tomas This is an bug in the PKCS12Export utility. I opened a Bugzilla for it: https://bugzilla.redhat.com/show_bug.cgi?id=972753. Below is a workaround, as suggested by Ade: as for a workaround, you could simply edit the file that starts PKCS12Export edit /usr/bin/PKCS12Export after line 134, simply add the line : CP=/usr/lib/java/jss4.jar but thats just a temp fix for f19 only not the real fix, you'll need the real fix checked in to pass the patch -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Mon Jun 10 14:48:14 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 10 Jun 2013 16:48:14 +0200 Subject: [Freeipa-devel] [PATCHES] 0230-0239 Integtration testing framework In-Reply-To: <51A88DA9.806@redhat.com> References: <51A88DA9.806@redhat.com> Message-ID: <51B5E72E.80000@redhat.com> On 05/31/2013 01:46 PM, Petr Viktorin wrote: > Apply on top of my patches 0227-0234. > > These patches add an initial integration testing framework. > > Patch 0230 adds a plugin for ordered test classes. > Nose orders methods within a test suite alphabetically, but we generally > want to run them in the order defined. This adds the @ordered decorator > that causes Nose to do just that, provided the plugin is loaded and > enabled, and that the methods are defined in the same file. The > ipa-run-tests wrapper is changed to enable the plugin. > In the future we may want to use this for unit tests as well. It might > also make sense to separate it from the FreeIPA project altogether. > > Patch 0231 adds configuration for tests. This reads environment > variables like: > - MASTER (FQDN of initial server) > - REPLICA (space-separated FQDNs of replicas) > - CLIENT (space-separated FQDNs of clients), > - IPATEST_DIR (directory the tests use on the remote machines) > etc., and loads them into an easy-to use Python object. > A tool called ipa-test-config is provided that generates a full set of > environment variables for shell-based tests from these, either global or > specific for a given host. > If environment variables don't work for us, alternate configuration > methods can be added in the future. > > Patch 0232 adds an integration test framework. > This extends Host object available from the configuration with methods > to run commands and copy files on the remote host, and adds a base class > for integration tests which can currently install and uninstall IPA in a > "star" topology. (In the future, the install/uninstall code should also > be made available as a shell command.) > A simple test for user replication between two masters is provided. > Log files from the remote hosts can be marked for collection, but the > actual collection is left to a Nose plugin. > The base class uses the @ordered decorator mentioned above. > > Patch 0233 improves on how commands are run on remote hosts. > In the previous patch, the process's stdin and stdout were combined as a > quick hack to avoid the problem that if we first read stdout and then > stderr, then stderr's buffer can fill up and we'd deadlock (and the > other way around). With this patch the streams are read in parallel. > In the future this can be extended to calling whole commands in parallel > (e.g. uninstalling IPA on all the hosts at once). > > Patch 0234 adds log collection to the BeakerLib integration plugin. > This tars up the marked logs, downloads then, and calls rlFileSubmit on > them. > > --- Attaching additional patches: Patch 0237 configures logging in ipa-run-tests to forward messages from the IPA logging machinery to a normal Python logger. This way the logs are captured The logs are also printed to stderr so that there's some activity on the terminal after you run the utility. Patch 0238 makes it possible to use RSA private SSH keys to log in to the remote machines. The key is given in $IPA_ROOT_SSH_KEY, and used if $IPA_ROOT_SSH_PASSWORD is empty. I've added this to the design page. Patch 0239 makes test setup change the hostname, /etc/hosts, and /etc/resolv.conf to match the configured values. These should be equivalent to the fixes in https://github.com/freeipa/tests/blob/master/ipa-tests/beaker/ipa-server/shared/ipa-install.sh#L733 In test teardown, the changes are undone. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0237-Show-logs-in-failed-tests.patch Type: text/x-patch Size: 3124 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0238-tests-Allow-public-keys-for-authentication-to-the-re.patch Type: text/x-patch Size: 4173 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0239-tests-Configure-unconfigure-remote-hosts.patch Type: text/x-patch Size: 9883 bytes Desc: not available URL: From akrivoka at redhat.com Mon Jun 10 15:31:03 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 10 Jun 2013 17:31:03 +0200 Subject: [Freeipa-devel] [PATCH] 0033 Fail when adding a trust with a different range In-Reply-To: <51B59854.1030404@redhat.com> References: <51A87688.2070107@redhat.com> <51B1B2DF.3050101@redhat.com> <51B20107.4050405@redhat.com> <51B59854.1030404@redhat.com> Message-ID: <51B5F137.5060803@redhat.com> On 06/10/2013 11:11 AM, Tomas Babej wrote: > On 06/07/2013 05:49 PM, Ana Krivokapic wrote: >> On 06/07/2013 12:15 PM, Tomas Babej wrote: >>> On 05/31/2013 12:08 PM, Ana Krivokapic wrote: >>>> Hello, >>>> >>>> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3635. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >>> Hi, the patch itself works as it should, I have only some >>> refactoring comments: >>> >>> 1.) There already is a add_range method that is called from within >>> trust_add's execute() >>> and handles some range validation (currently only whether domain's >>> SID of new and >>> existing range are equal, my patch 67 add some more). >>> >>> Your patch introduces a new method validate_range() that is called >>> from execute(), >>> which leads to some duplication of the logic, mainly two same calls >>> to the API (getting >>> the info about the old range via idrange_show) >>> >>> I'd rather we keep all the validation in one place, preferably >>> inside the add_range method >>> or refactored out of it in the new method that is called only from >>> add_range(). >>> >>> 2.) That being said, other parts of refactoring are nice and make >>> code more clear, +1. >>> >>> Tomas >> >> My first instinct was to place this validation in the add_range() >> method. However, add_range() is called after the trust itself is >> added, and validation introduced by this patch needs to happen before >> the trust is added (we need to prevent the addition of trust in case >> the validation fails). >> >> As for the code duplication, you are right about that. I tried to >> minimize duplication - resulting updated patch attached. >> -- >> Regards, >> >> Ana Krivokapic >> Associate Software Engineer >> FreeIPA team >> Red Hat Inc. > > While this is a nice improvement from the code repetition point of view, > the patch still has one flaw as I see it - the range validation > happens at two separate places: > > Once here(already in the code): > > if old_range: > > old_dom_sid = old_range['result']['ipanttrusteddomainsid'][0]; > > > if old_dom_sid == dom_sid: > > return > > > raise errors.ValidationError(name=_('range exists'), > > error=_('ID range with the same name but different ' \ > > 'domain SID already exists. The ID range for ' \ > > 'the new trusted domain must be created manually.')) > > > And once here(added by your patch): > > + if not self.validate_range(*keys, **options): > + raise errors.ValidationError( > + name=_('id range'), > + error=_( > + 'An id range already exists for this trust. ' > + 'You should either delete the old range, or ' > + 'exclude --base-id/--range-size options from the > command.' > > I'd suggest we have one common place, say validate_range() function as > we have now, > that contains all the checks (more coming in the future for sure). > > That would mean that the whole trust-add command will fail in the case > that "ID range > with the same name but different domain SID already exists", since we > now call validate_range() > within execute() method. I checked with Alexander and we agreed that > this is more desired behaviour. > > This would also result to reducement of the number of API calls, which > is a nice benefit. > > Tomas This updated patch completely separates validation logic and object creation logic of the trust_add command. I added two new methods: * validate_range(), which ensures that the options and environment related to idrange is valid, and * validate_options, which takes care of other general validation One change introduced in this patch is making the __populate_remote_domain() method of TrustDomainJoins class public, and calling it from trust_add. This was necessary in order to enable discovering details of the trusted domain in validation phase. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0033-03-Fail-when-adding-a-trust-with-a-different-range.patch Type: text/x-patch Size: 14806 bytes Desc: not available URL: From dpal at redhat.com Mon Jun 10 15:34:53 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 10 Jun 2013 11:34:53 -0400 Subject: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used In-Reply-To: <51B5DAFC.7040307@redhat.com> References: <038.85636923ffc7d7f47d64dd7308c2c527@fedorahosted.org> <053.e8f59eb95b19dcdbcf715e1166fb104a@fedorahosted.org> <51B1CC41.30401@redhat.com> <51B1D16C.2010201@redhat.com> <51B1D8D3.6070502@redhat.com> <51B1DD85.9010001@redhat.com> <51B1DF8C.2020108@redhat.com> <51B1E1D0.8020800@redhat.com> <51B5A238.5050105@redhat.com> <51B5C7F8.5090906@redhat.com> <51B5D63D.3080309@redhat.com> <51B5DAFC.7040307@redhat.com> Message-ID: <51B5F21D.7040302@redhat.com> On 06/10/2013 09:56 AM, Petr Viktorin wrote: > On 06/10/2013 03:35 PM, Rob Crittenden wrote: >> Dmitri Pal wrote: >>> On 06/10/2013 05:54 AM, Jan Cholasta wrote: >>>> On 7.6.2013 15:36, John Dennis wrote: >>>>> On 06/07/2013 09:26 AM, Jan Cholasta wrote: >>>>>> On 7.6.2013 15:17, John Dennis wrote: >>>>>>> On 06/07/2013 08:57 AM, Jan Cholasta wrote: >>>>>>>> Yes, this is correct. The DS certificate must be directly signed >>>>>>>> by the >>>>>>>> CA trusted by IPA (specified by --root-ca-cert in >>>>>>>> ipa-server-install), >>>>>>>> there may be no intermediate CAs, because ldapsearch and >>>>>>>> friends and >>>>>>>> python-ldap don't like them. >>>>>>> >>>>>>> That doesn't sound right. Do we understand why a chain length > >>>>>>> 1 is >>>>>>> failing? >>>>>>> >>>>>> >>>>>> LDAP utilities and python-ldap only trust certificates directly >>>>>> issued >>>>>> by CAs you point them to (at least on Fedora 18). >>>>> >>>>> This sounds like a bug in MozLDAP (i.e. the NSS LDAP crypto >>>>> provider). >>>>> Have we filed a bug? Let's file the bug here in the Red Hat bugzilla, >>>>> not upstream, we're the maintainers of MozLDAP and upstream is >>>>> already >>>>> frustrated with it. >>>>> >>>> >>>> I have just tested with libldap compiled with OpenSSL on my Arch Linux >>>> box, it does not work as well: >>>> >>>> $ LDAPTLS_CACERT=$PWD/ca.crt ldapsearch -H >>>> ldap://vm-131.idm.lab.bos.redhat.com -ZZ -D 'cn=Directory Manager' -W >>>> -b '' -s base >>>> ldap_start_tls: Connect error (-11) >>>> additional info: error:14090086:SSL >>>> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed >>>> (invalid CA certificate) >>>> >>>> For the record, this is what happens with NSS on Fedora: >>>> >>>> $ LDAPTLS_CACERT=$PWD/ca.crt ldapsearch -H >>>> ldap://vm-131.idm.lab.bos.redhat.com -ZZ -D 'cn=Directory Manager' -W >>>> -b '' -s base >>>> ldap_start_tls: Connect error (-11) >>>> additional info: TLS error -8179:Peer's Certificate issuer is not >>>> recognized. >>>> >>>> Honza >>>> >>> If the options does not work we should hide it for now and clearly >>> state >>> in the docs and man pages that the case when certs come from different >>> CA is not supported for the time being. >>> >> >> IIRC it was added for two reasons: >> >> 1. Because the CA is not required to be included in the PKCS#12 file. > > Well, that's not a necessary requirement. A tester did have a bit of > trouble creating a PKCS#12 file with both the server cert and the CA > cert, but the trouble is comparable to having to create a PEM file. > >> 2. Because previous attempts to figure out the nickname of the signing >> CA was problematic. > > This is the main reason. It could be done, but I believe we should > avoid any guessing to determine the root of trust. > I am not sure I get it. So we inspect the certificate PKCS#12 file and there can be ambiguity about the root of trust. How? This part is not clear to me. Sorry for being slow here. Can someone explain it in more details? Regardless... If something can't be reliably determined then we should probably do following: If we have any issues with determining the root of trust we should fail and request the caller to run the command again with additional command line option that would explicitly provide the the name of the root CA. Will that 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 pviktori at redhat.com Mon Jun 10 16:13:14 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 10 Jun 2013 18:13:14 +0200 Subject: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used In-Reply-To: <51B5F21D.7040302@redhat.com> References: <038.85636923ffc7d7f47d64dd7308c2c527@fedorahosted.org> <053.e8f59eb95b19dcdbcf715e1166fb104a@fedorahosted.org> <51B1CC41.30401@redhat.com> <51B1D16C.2010201@redhat.com> <51B1D8D3.6070502@redhat.com> <51B1DD85.9010001@redhat.com> <51B1DF8C.2020108@redhat.com> <51B1E1D0.8020800@redhat.com> <51B5A238.5050105@redhat.com> <51B5C7F8.5090906@redhat.com> <51B5D63D.3080309@redhat.com> <51B5DAFC.7040307@redhat.com> <51B5F21D.7040302@redhat.com> Message-ID: <51B5FB1A.1050004@redhat.com> On 06/10/2013 05:34 PM, Dmitri Pal wrote: > On 06/10/2013 09:56 AM, Petr Viktorin wrote: >> On 06/10/2013 03:35 PM, Rob Crittenden wrote: >>> Dmitri Pal wrote: >>>> On 06/10/2013 05:54 AM, Jan Cholasta wrote: >>>>> On 7.6.2013 15:36, John Dennis wrote: >>>>>> On 06/07/2013 09:26 AM, Jan Cholasta wrote: >>>>>>> On 7.6.2013 15:17, John Dennis wrote: >>>>>>>> On 06/07/2013 08:57 AM, Jan Cholasta wrote: >>>>>>>>> Yes, this is correct. The DS certificate must be directly signed >>>>>>>>> by the >>>>>>>>> CA trusted by IPA (specified by --root-ca-cert in >>>>>>>>> ipa-server-install), >>>>>>>>> there may be no intermediate CAs, because ldapsearch and >>>>>>>>> friends and >>>>>>>>> python-ldap don't like them. >>>>>>>> >>>>>>>> That doesn't sound right. Do we understand why a chain length > >>>>>>>> 1 is >>>>>>>> failing? >>>>>>>> >>>>>>> >>>>>>> LDAP utilities and python-ldap only trust certificates directly >>>>>>> issued >>>>>>> by CAs you point them to (at least on Fedora 18). >>>>>> >>>>>> This sounds like a bug in MozLDAP (i.e. the NSS LDAP crypto >>>>>> provider). >>>>>> Have we filed a bug? Let's file the bug here in the Red Hat bugzilla, >>>>>> not upstream, we're the maintainers of MozLDAP and upstream is >>>>>> already >>>>>> frustrated with it. >>>>>> >>>>> >>>>> I have just tested with libldap compiled with OpenSSL on my Arch Linux >>>>> box, it does not work as well: >>>>> >>>>> $ LDAPTLS_CACERT=$PWD/ca.crt ldapsearch -H >>>>> ldap://vm-131.idm.lab.bos.redhat.com -ZZ -D 'cn=Directory Manager' -W >>>>> -b '' -s base >>>>> ldap_start_tls: Connect error (-11) >>>>> additional info: error:14090086:SSL >>>>> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed >>>>> (invalid CA certificate) >>>>> >>>>> For the record, this is what happens with NSS on Fedora: >>>>> >>>>> $ LDAPTLS_CACERT=$PWD/ca.crt ldapsearch -H >>>>> ldap://vm-131.idm.lab.bos.redhat.com -ZZ -D 'cn=Directory Manager' -W >>>>> -b '' -s base >>>>> ldap_start_tls: Connect error (-11) >>>>> additional info: TLS error -8179:Peer's Certificate issuer is not >>>>> recognized. >>>>> >>>>> Honza >>>>> >>>> If the options does not work we should hide it for now and clearly >>>> state >>>> in the docs and man pages that the case when certs come from different >>>> CA is not supported for the time being. >>>> >>> >>> IIRC it was added for two reasons: >>> >>> 1. Because the CA is not required to be included in the PKCS#12 file. >> >> Well, that's not a necessary requirement. A tester did have a bit of >> trouble creating a PKCS#12 file with both the server cert and the CA >> cert, but the trouble is comparable to having to create a PEM file. >> >>> 2. Because previous attempts to figure out the nickname of the signing >>> CA was problematic. >> >> This is the main reason. It could be done, but I believe we should >> avoid any guessing to determine the root of trust. >> > > I am not sure I get it. > So we inspect the certificate PKCS#12 file and there can be ambiguity > about the root of trust. How? This part is not clear to me. > Sorry for being slow here. Can someone explain it in more details? A PKCS#12 file can contain any number of arbitrary certificates (or other objects). There is already some ambiguity in determining which cert to use for the server. Here we error out if we don't find exactly one cert with appropriate usage flags. The root CA cert can be the one that signed the server cert (the only scenario that works now), or it can be any one along the chain. If you have an intermediate CA signed by a well-known authority, you would probably not want to trust *everything* signed by that authority; you'd want to trust "your" root CA which can be anywhere along the chain. If we exclude scenarios with Intermediate CAs (which don't currently work), the situation is much simpler, but we don't want to limit the CLI to that. Note that users can't usually carefully control what's inside the PKCS#12 file: the tools will typically allow generating a file with either only one cert, or with the entire chain. > Regardless... > If something can't be reliably determined then we should probably do > following: > If we have any issues with determining the root of trust we should fail > and request the caller to run the command again with additional command > line option that would explicitly provide the the name of the root CA. > > Will that help? That would be any time there's more than one CA in the trust chain. Is it worth special-casing this? Are there real-world deployments that only use one CA? Note that in this case you can just use a single-cert PKCS#12 plus a PEM file for the CA, which is simple enough IMO. -- Petr? From pviktori at redhat.com Mon Jun 10 16:27:27 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 10 Jun 2013 18:27:27 +0200 Subject: [Freeipa-devel] [PATCHES 0061-0063] Extend ID range types In-Reply-To: <51B593C1.2000204@redhat.com> References: <51ACAF9B.7040300@redhat.com> <51AF34E5.6080504@redhat.com> <51B0518E.8050700@redhat.com> <20130606100002.GB26689@redhat.com> <51B1E0B8.7030806@redhat.com> <20130607134110.GH26689@redhat.com> <51B1EBAB.6010001@redhat.com> <20130607154418.GK26689@redhat.com> <51B593C1.2000204@redhat.com> Message-ID: <51B5FE6F.9060808@redhat.com> On 06/10/2013 10:52 AM, Tomas Babej wrote: > On 06/07/2013 05:44 PM, Alexander Bokovoy wrote: >> On Fri, 07 Jun 2013, Tomas Babej wrote: >>> On 06/07/2013 03:41 PM, Alexander Bokovoy wrote: >>>> Hi, >>>> >>>> in patch 0061: >>>> >>>> On Fri, 07 Jun 2013, Tomas Babej wrote: >>>>> + range_types = { >>>>> + u'ipa-local': unicode(_(u'local domain range')), >>>>> + u'ipa-ad-winsync': unicode(_('Active Directory winsync >>>>> range')), >>>>> + u'ipa-ad-trust': unicode(_('Active Directory domain range')), >>>>> + u'ipa-ad-trust-posix': unicode(_('Active Directory trust >>>>> range with ' >>>>> + 'POSIX attributes')), >>>>> + u'ipa-ipa-trust': unicode(_('IPA trust range')), >>>>> + } >>>> Why there is _(u'local domain range') and then others without Unicode >>>> strings? Either way is fine but there should be consistency. >>>> >>> Sure, fixed. >>> >>>> The rest of this patch would be much shorter if there wouldn't >>>> additional whitespace. Could you please git rid of that? >>>> >>> Whitespaces are intentional, these are fixes for PEP8 E302 errors. >> If they are intentional, please send them as separate patch. >> >>> Sending the whole patchset updated. >> Please split the whitespace fixes from the functional ones. >> > No problem, patches split. > > Tomas Hello, I got a test failure, most likely caused by this patch. In test_range_plugin.py, there are some manually added ranges without the new required attribute. Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/suite.py", line 208, in run self.setUp() File "/usr/lib/python2.7/site-packages/nose/suite.py", line 291, in setUp self.setupContext(ancestor) File "/usr/lib/python2.7/site-packages/nose/suite.py", line 314, in setupContext try_run(context, names) File "/usr/lib/python2.7/site-packages/nose/util.py", line 469, in try_run return func() File "/var/lib/jenkins/workspace/install-and-make-test/tests/test_xmlrpc/test_range_plugin.py", line 159, in setUpClass self.add_entry(testrange9_dn, testrange9_add) File "/var/lib/jenkins/workspace/install-and-make-test/tests/test_xmlrpc/test_range_plugin.py", line 148, in add_entry self.connection.add_s(dn, ldif) File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 195, in add_s return self.result(msgid,all=1,timeout=self.timeout) File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 458, in result resp_type, resp_data, resp_msgid = self.result2(msgid,all,timeout) File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 462, in result2 resp_type, resp_data, resp_msgid, resp_ctrls = self.result3(msgid,all,timeout) File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 469, in result3 resp_ctrl_classes=resp_ctrl_classes File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 476, in result4 ldap_result = self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop) File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 99, in _ldap_call result = func(*args,**kwargs) OBJECT_CLASS_VIOLATION: {'info': 'missing attribute "ipaRangeType" required by object class "ipaIDrange"\n', 'desc': 'Object class violation'} -- Petr? From abokovoy at redhat.com Mon Jun 10 16:31:02 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 10 Jun 2013 19:31:02 +0300 Subject: [Freeipa-devel] [PATCHES 0061-0063] Extend ID range types In-Reply-To: <51B5FE6F.9060808@redhat.com> References: <51ACAF9B.7040300@redhat.com> <51AF34E5.6080504@redhat.com> <51B0518E.8050700@redhat.com> <20130606100002.GB26689@redhat.com> <51B1E0B8.7030806@redhat.com> <20130607134110.GH26689@redhat.com> <51B1EBAB.6010001@redhat.com> <20130607154418.GK26689@redhat.com> <51B593C1.2000204@redhat.com> <51B5FE6F.9060808@redhat.com> Message-ID: <20130610163102.GO26689@redhat.com> On Mon, 10 Jun 2013, Petr Viktorin wrote: >On 06/10/2013 10:52 AM, Tomas Babej wrote: >>On 06/07/2013 05:44 PM, Alexander Bokovoy wrote: >>>On Fri, 07 Jun 2013, Tomas Babej wrote: >>>>On 06/07/2013 03:41 PM, Alexander Bokovoy wrote: >>>>>Hi, >>>>> >>>>>in patch 0061: >>>>> >>>>>On Fri, 07 Jun 2013, Tomas Babej wrote: >>>>>>+ range_types = { >>>>>>+ u'ipa-local': unicode(_(u'local domain range')), >>>>>>+ u'ipa-ad-winsync': unicode(_('Active Directory winsync >>>>>>range')), >>>>>>+ u'ipa-ad-trust': unicode(_('Active Directory domain range')), >>>>>>+ u'ipa-ad-trust-posix': unicode(_('Active Directory trust >>>>>>range with ' >>>>>>+ 'POSIX attributes')), >>>>>>+ u'ipa-ipa-trust': unicode(_('IPA trust range')), >>>>>>+ } >>>>>Why there is _(u'local domain range') and then others without Unicode >>>>>strings? Either way is fine but there should be consistency. >>>>> >>>>Sure, fixed. >>>> >>>>>The rest of this patch would be much shorter if there wouldn't >>>>>additional whitespace. Could you please git rid of that? >>>>> >>>>Whitespaces are intentional, these are fixes for PEP8 E302 errors. >>>If they are intentional, please send them as separate patch. >>> >>>>Sending the whole patchset updated. >>>Please split the whitespace fixes from the functional ones. >>> >>No problem, patches split. >> >>Tomas > >Hello, >I got a test failure, most likely caused by this patch. In >test_range_plugin.py, there are some manually added ranges without >the new required attribute. Good catch, thanks! I'd suggest to fix this as part of patch 0070 that Tomas sent in today because it touches the same code. -- / Alexander Bokovoy From dpal at redhat.com Mon Jun 10 17:03:33 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 10 Jun 2013 13:03:33 -0400 Subject: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used In-Reply-To: <51B5FB1A.1050004@redhat.com> References: <038.85636923ffc7d7f47d64dd7308c2c527@fedorahosted.org> <053.e8f59eb95b19dcdbcf715e1166fb104a@fedorahosted.org> <51B1CC41.30401@redhat.com> <51B1D16C.2010201@redhat.com> <51B1D8D3.6070502@redhat.com> <51B1DD85.9010001@redhat.com> <51B1DF8C.2020108@redhat.com> <51B1E1D0.8020800@redhat.com> <51B5A238.5050105@redhat.com> <51B5C7F8.5090906@redhat.com> <51B5D63D.3080309@redhat.com> <51B5DAFC.7040307@redhat.com> <51B5F21D.7040302@redhat.com> <51B5FB1A.1050004@redhat.com> Message-ID: <51B606E5.6010600@redhat.com> On 06/10/2013 12:13 PM, Petr Viktorin wrote: > On 06/10/2013 05:34 PM, Dmitri Pal wrote: >> On 06/10/2013 09:56 AM, Petr Viktorin wrote: >>> On 06/10/2013 03:35 PM, Rob Crittenden wrote: >>>> Dmitri Pal wrote: >>>>> On 06/10/2013 05:54 AM, Jan Cholasta wrote: >>>>>> On 7.6.2013 15:36, John Dennis wrote: >>>>>>> On 06/07/2013 09:26 AM, Jan Cholasta wrote: >>>>>>>> On 7.6.2013 15:17, John Dennis wrote: >>>>>>>>> On 06/07/2013 08:57 AM, Jan Cholasta wrote: >>>>>>>>>> Yes, this is correct. The DS certificate must be directly signed >>>>>>>>>> by the >>>>>>>>>> CA trusted by IPA (specified by --root-ca-cert in >>>>>>>>>> ipa-server-install), >>>>>>>>>> there may be no intermediate CAs, because ldapsearch and >>>>>>>>>> friends and >>>>>>>>>> python-ldap don't like them. >>>>>>>>> >>>>>>>>> That doesn't sound right. Do we understand why a chain length > >>>>>>>>> 1 is >>>>>>>>> failing? >>>>>>>>> >>>>>>>> >>>>>>>> LDAP utilities and python-ldap only trust certificates directly >>>>>>>> issued >>>>>>>> by CAs you point them to (at least on Fedora 18). >>>>>>> >>>>>>> This sounds like a bug in MozLDAP (i.e. the NSS LDAP crypto >>>>>>> provider). >>>>>>> Have we filed a bug? Let's file the bug here in the Red Hat >>>>>>> bugzilla, >>>>>>> not upstream, we're the maintainers of MozLDAP and upstream is >>>>>>> already >>>>>>> frustrated with it. >>>>>>> >>>>>> >>>>>> I have just tested with libldap compiled with OpenSSL on my Arch >>>>>> Linux >>>>>> box, it does not work as well: >>>>>> >>>>>> $ LDAPTLS_CACERT=$PWD/ca.crt ldapsearch -H >>>>>> ldap://vm-131.idm.lab.bos.redhat.com -ZZ -D 'cn=Directory >>>>>> Manager' -W >>>>>> -b '' -s base >>>>>> ldap_start_tls: Connect error (-11) >>>>>> additional info: error:14090086:SSL >>>>>> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed >>>>>> (invalid CA certificate) >>>>>> >>>>>> For the record, this is what happens with NSS on Fedora: >>>>>> >>>>>> $ LDAPTLS_CACERT=$PWD/ca.crt ldapsearch -H >>>>>> ldap://vm-131.idm.lab.bos.redhat.com -ZZ -D 'cn=Directory >>>>>> Manager' -W >>>>>> -b '' -s base >>>>>> ldap_start_tls: Connect error (-11) >>>>>> additional info: TLS error -8179:Peer's Certificate issuer >>>>>> is not >>>>>> recognized. >>>>>> >>>>>> Honza >>>>>> >>>>> If the options does not work we should hide it for now and clearly >>>>> state >>>>> in the docs and man pages that the case when certs come from >>>>> different >>>>> CA is not supported for the time being. >>>>> >>>> >>>> IIRC it was added for two reasons: >>>> >>>> 1. Because the CA is not required to be included in the PKCS#12 file. >>> >>> Well, that's not a necessary requirement. A tester did have a bit of >>> trouble creating a PKCS#12 file with both the server cert and the CA >>> cert, but the trouble is comparable to having to create a PEM file. >>> >>>> 2. Because previous attempts to figure out the nickname of the signing >>>> CA was problematic. >>> >>> This is the main reason. It could be done, but I believe we should >>> avoid any guessing to determine the root of trust. >>> >> >> I am not sure I get it. >> So we inspect the certificate PKCS#12 file and there can be ambiguity >> about the root of trust. How? This part is not clear to me. >> Sorry for being slow here. Can someone explain it in more details? > > A PKCS#12 file can contain any number of arbitrary certificates (or > other objects). > There is already some ambiguity in determining which cert to use for > the server. Here we error out if we don't find exactly one cert with > appropriate usage flags. > The root CA cert can be the one that signed the server cert (the only > scenario that works now), or it can be any one along the chain. > If you have an intermediate CA signed by a well-known authority, you > would probably not want to trust *everything* signed by that > authority; you'd want to trust "your" root CA which can be anywhere > along the chain. > > If we exclude scenarios with Intermediate CAs (which don't currently > work), the situation is much simpler, but we don't want to limit the > CLI to that. > > Note that users can't usually carefully control what's inside the > PKCS#12 file: the tools will typically allow generating a file with > either only one cert, or with the entire chain. > >> Regardless... >> If something can't be reliably determined then we should probably do >> following: >> If we have any issues with determining the root of trust we should fail >> and request the caller to run the command again with additional command >> line option that would explicitly provide the the name of the root CA. >> >> Will that help? > > That would be any time there's more than one CA in the trust chain. > Is it worth special-casing this? Are there real-world deployments that > only use one CA? Note that in this case you can just use a single-cert > PKCS#12 plus a PEM file for the CA, which is simple enough IMO. > So my point is that why we can't say that we support only a single-cert PKCS#12 file plus a PEM file case and have a clear set of instructions on how to produce these files? -- 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 Jun 10 17:12:57 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 10 Jun 2013 13:12:57 -0400 Subject: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used In-Reply-To: <51B606E5.6010600@redhat.com> References: <038.85636923ffc7d7f47d64dd7308c2c527@fedorahosted.org> <053.e8f59eb95b19dcdbcf715e1166fb104a@fedorahosted.org> <51B1CC41.30401@redhat.com> <51B1D16C.2010201@redhat.com> <51B1D8D3.6070502@redhat.com> <51B1DD85.9010001@redhat.com> <51B1DF8C.2020108@redhat.com> <51B1E1D0.8020800@redhat.com> <51B5A238.5050105@redhat.com> <51B5C7F8.5090906@redhat.com> <51B5D63D.3080309@redhat.com> <51B5DAFC.7040307@redhat.com> <51B5F21D.7040302@redhat.com> <51B5FB1A.1050004@redhat.com> <51B606E5.6010600@redhat.com> Message-ID: <51B60919.1030309@redhat.com> Dmitri Pal wrote: > On 06/10/2013 12:13 PM, Petr Viktorin wrote: >> On 06/10/2013 05:34 PM, Dmitri Pal wrote: >>> On 06/10/2013 09:56 AM, Petr Viktorin wrote: >>>> On 06/10/2013 03:35 PM, Rob Crittenden wrote: >>>>> Dmitri Pal wrote: >>>>>> On 06/10/2013 05:54 AM, Jan Cholasta wrote: >>>>>>> On 7.6.2013 15:36, John Dennis wrote: >>>>>>>> On 06/07/2013 09:26 AM, Jan Cholasta wrote: >>>>>>>>> On 7.6.2013 15:17, John Dennis wrote: >>>>>>>>>> On 06/07/2013 08:57 AM, Jan Cholasta wrote: >>>>>>>>>>> Yes, this is correct. The DS certificate must be directly signed >>>>>>>>>>> by the >>>>>>>>>>> CA trusted by IPA (specified by --root-ca-cert in >>>>>>>>>>> ipa-server-install), >>>>>>>>>>> there may be no intermediate CAs, because ldapsearch and >>>>>>>>>>> friends and >>>>>>>>>>> python-ldap don't like them. >>>>>>>>>> >>>>>>>>>> That doesn't sound right. Do we understand why a chain length > >>>>>>>>>> 1 is >>>>>>>>>> failing? >>>>>>>>>> >>>>>>>>> >>>>>>>>> LDAP utilities and python-ldap only trust certificates directly >>>>>>>>> issued >>>>>>>>> by CAs you point them to (at least on Fedora 18). >>>>>>>> >>>>>>>> This sounds like a bug in MozLDAP (i.e. the NSS LDAP crypto >>>>>>>> provider). >>>>>>>> Have we filed a bug? Let's file the bug here in the Red Hat >>>>>>>> bugzilla, >>>>>>>> not upstream, we're the maintainers of MozLDAP and upstream is >>>>>>>> already >>>>>>>> frustrated with it. >>>>>>>> >>>>>>> >>>>>>> I have just tested with libldap compiled with OpenSSL on my Arch >>>>>>> Linux >>>>>>> box, it does not work as well: >>>>>>> >>>>>>> $ LDAPTLS_CACERT=$PWD/ca.crt ldapsearch -H >>>>>>> ldap://vm-131.idm.lab.bos.redhat.com -ZZ -D 'cn=Directory >>>>>>> Manager' -W >>>>>>> -b '' -s base >>>>>>> ldap_start_tls: Connect error (-11) >>>>>>> additional info: error:14090086:SSL >>>>>>> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed >>>>>>> (invalid CA certificate) >>>>>>> >>>>>>> For the record, this is what happens with NSS on Fedora: >>>>>>> >>>>>>> $ LDAPTLS_CACERT=$PWD/ca.crt ldapsearch -H >>>>>>> ldap://vm-131.idm.lab.bos.redhat.com -ZZ -D 'cn=Directory >>>>>>> Manager' -W >>>>>>> -b '' -s base >>>>>>> ldap_start_tls: Connect error (-11) >>>>>>> additional info: TLS error -8179:Peer's Certificate issuer >>>>>>> is not >>>>>>> recognized. >>>>>>> >>>>>>> Honza >>>>>>> >>>>>> If the options does not work we should hide it for now and clearly >>>>>> state >>>>>> in the docs and man pages that the case when certs come from >>>>>> different >>>>>> CA is not supported for the time being. >>>>>> >>>>> >>>>> IIRC it was added for two reasons: >>>>> >>>>> 1. Because the CA is not required to be included in the PKCS#12 file. >>>> >>>> Well, that's not a necessary requirement. A tester did have a bit of >>>> trouble creating a PKCS#12 file with both the server cert and the CA >>>> cert, but the trouble is comparable to having to create a PEM file. >>>> >>>>> 2. Because previous attempts to figure out the nickname of the signing >>>>> CA was problematic. >>>> >>>> This is the main reason. It could be done, but I believe we should >>>> avoid any guessing to determine the root of trust. >>>> >>> >>> I am not sure I get it. >>> So we inspect the certificate PKCS#12 file and there can be ambiguity >>> about the root of trust. How? This part is not clear to me. >>> Sorry for being slow here. Can someone explain it in more details? >> >> A PKCS#12 file can contain any number of arbitrary certificates (or >> other objects). >> There is already some ambiguity in determining which cert to use for >> the server. Here we error out if we don't find exactly one cert with >> appropriate usage flags. >> The root CA cert can be the one that signed the server cert (the only >> scenario that works now), or it can be any one along the chain. >> If you have an intermediate CA signed by a well-known authority, you >> would probably not want to trust *everything* signed by that >> authority; you'd want to trust "your" root CA which can be anywhere >> along the chain. >> >> If we exclude scenarios with Intermediate CAs (which don't currently >> work), the situation is much simpler, but we don't want to limit the >> CLI to that. >> >> Note that users can't usually carefully control what's inside the >> PKCS#12 file: the tools will typically allow generating a file with >> either only one cert, or with the entire chain. >> >>> Regardless... >>> If something can't be reliably determined then we should probably do >>> following: >>> If we have any issues with determining the root of trust we should fail >>> and request the caller to run the command again with additional command >>> line option that would explicitly provide the the name of the root CA. >>> >>> Will that help? >> >> That would be any time there's more than one CA in the trust chain. >> Is it worth special-casing this? Are there real-world deployments that >> only use one CA? Note that in this case you can just use a single-cert >> PKCS#12 plus a PEM file for the CA, which is simple enough IMO. >> > So my point is that why we can't say that we support only a single-cert > PKCS#12 file plus a PEM file case and have a clear set of instructions > on how to produce these files? The problem is that the user has very little control over what gets pulled in and doing so would probably require a whole lot of additional steps that may just make them throw up their hands altogether. Take the NSS case. It will automatically pull in any needed CA certificates that are also in the database. So you'd have to go about deleting those certs prior to creating the PKCS#12 file or you'd have to create the PKCS#12 file, import it into a temporary NSS database, delete the unwanted certs, then re-create the PKCS#12 file. In short, rather a dreadful process. rob From tbabej at redhat.com Tue Jun 11 08:31:49 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 11 Jun 2013 10:31:49 +0200 Subject: [Freeipa-devel] [PATCH 0070] Remove hardcoded values from idrange plugin tests In-Reply-To: <51B5B4DD.4090201@redhat.com> References: <51B5B4DD.4090201@redhat.com> Message-ID: <51B6E075.8040102@redhat.com> On 06/10/2013 01:13 PM, Tomas Babej wrote: > Hi, > > Hardcoded values for range parameters such as base RID or range > size could be the reason the tests produced incorrect results, > as the ranges could get in conflict with already existing ranges > on the server. > > Patch dynamically chooses ID and RID range space at the end of > all ranges already present on the server. > > https://fedorahosted.org/freeipa/ticket/3662 > > Tomas Patch altered to incorporate minor fixes for recent idrange objectclass changes. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0070-2-Remove-hardcoded-values-from-idrange-plugin-tests.patch Type: text/x-patch Size: 7077 bytes Desc: not available URL: From abokovoy at redhat.com Tue Jun 11 10:59:18 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 11 Jun 2013 13:59:18 +0300 Subject: [Freeipa-devel] [PATCH 0070] Remove hardcoded values from idrange plugin tests In-Reply-To: <51B6E075.8040102@redhat.com> References: <51B5B4DD.4090201@redhat.com> <51B6E075.8040102@redhat.com> Message-ID: <20130611105917.GP26689@redhat.com> On Tue, 11 Jun 2013, Tomas Babej wrote: >On 06/10/2013 01:13 PM, Tomas Babej wrote: >>Hi, >> >>Hardcoded values for range parameters such as base RID or range >>size could be the reason the tests produced incorrect results, >>as the ranges could get in conflict with already existing ranges >>on the server. >> >>Patch dynamically chooses ID and RID range space at the end of >>all ranges already present on the server. >> >>https://fedorahosted.org/freeipa/ticket/3662 >> >>Tomas > >Patch altered to incorporate minor fixes for recent idrange >objectclass changes. > >Tomas >From b35b10f1356c9714776f16aadec7ffbe95e2f41e Mon Sep 17 00:00:00 2001 >From: Tomas Babej >Date: Mon, 10 Jun 2013 13:08:50 +0200 >Subject: [PATCH] Remove hardcoded values from idrange plugin tests > >Hardcoded values for range parameters such as base RID or range >size could be the reason the tests produced incorrect results, >as the ranges could get in conflict with already existing ranges >on the server. > >Patch dynamically chooses ID and RID range space at the end of >all ranges already present on the server. > >https://fedorahosted.org/freeipa/ticket/3662 >--- > ipalib/plugins/idrange.py | 2 +- > tests/test_xmlrpc/test_range_plugin.py | 90 ++++++++++++++++++++++------------ > 2 files changed, 60 insertions(+), 32 deletions(-) > >diff --git a/ipalib/plugins/idrange.py b/ipalib/plugins/idrange.py >index abca492978d04c71b78a89df8e5c2d1d51c06398..54b835e244fb60ee212a9c00223d4294ff8f4363 100644 >--- a/ipalib/plugins/idrange.py >+++ b/ipalib/plugins/idrange.py >@@ -224,7 +224,7 @@ class idrange(LDAPObject): > if not any((options.get('pkey_only', False), > options.get('raw', False))): > range_type = entry_attrs['iparangetype'][0] >- entry_attrs['iparangetype'] = self.range_types.get(range_type, None) >+ entry_attrs['iparangetype'] = [self.range_types.get(range_type, None)] > > # Remove the objectclass > if not keep_objectclass: Could you please extract this change into an independent patch? I'm thinking purely from possible backporting perspective. Otherwise looks good. -- / Alexander Bokovoy From tbabej at redhat.com Tue Jun 11 11:15:51 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 11 Jun 2013 13:15:51 +0200 Subject: [Freeipa-devel] [PATCH 0070] Remove hardcoded values from idrange plugin tests In-Reply-To: <20130611105917.GP26689@redhat.com> References: <51B5B4DD.4090201@redhat.com> <51B6E075.8040102@redhat.com> <20130611105917.GP26689@redhat.com> Message-ID: <51B706E7.3040607@redhat.com> On 06/11/2013 12:59 PM, Alexander Bokovoy wrote: > On Tue, 11 Jun 2013, Tomas Babej wrote: >> On 06/10/2013 01:13 PM, Tomas Babej wrote: >>> Hi, >>> >>> Hardcoded values for range parameters such as base RID or range >>> size could be the reason the tests produced incorrect results, >>> as the ranges could get in conflict with already existing ranges >>> on the server. >>> >>> Patch dynamically chooses ID and RID range space at the end of >>> all ranges already present on the server. >>> >>> https://fedorahosted.org/freeipa/ticket/3662 >>> >>> Tomas >> >> Patch altered to incorporate minor fixes for recent idrange >> objectclass changes. >> >> Tomas > >> From b35b10f1356c9714776f16aadec7ffbe95e2f41e Mon Sep 17 00:00:00 2001 >> From: Tomas Babej >> Date: Mon, 10 Jun 2013 13:08:50 +0200 >> Subject: [PATCH] Remove hardcoded values from idrange plugin tests >> >> Hardcoded values for range parameters such as base RID or range >> size could be the reason the tests produced incorrect results, >> as the ranges could get in conflict with already existing ranges >> on the server. >> >> Patch dynamically chooses ID and RID range space at the end of >> all ranges already present on the server. >> >> https://fedorahosted.org/freeipa/ticket/3662 >> --- >> ipalib/plugins/idrange.py | 2 +- >> tests/test_xmlrpc/test_range_plugin.py | 90 >> ++++++++++++++++++++++------------ >> 2 files changed, 60 insertions(+), 32 deletions(-) >> >> diff --git a/ipalib/plugins/idrange.py b/ipalib/plugins/idrange.py >> index >> abca492978d04c71b78a89df8e5c2d1d51c06398..54b835e244fb60ee212a9c00223d4294ff8f4363 >> 100644 >> --- a/ipalib/plugins/idrange.py >> +++ b/ipalib/plugins/idrange.py >> @@ -224,7 +224,7 @@ class idrange(LDAPObject): >> if not any((options.get('pkey_only', False), >> options.get('raw', False))): >> range_type = entry_attrs['iparangetype'][0] >> - entry_attrs['iparangetype'] = >> self.range_types.get(range_type, None) >> + entry_attrs['iparangetype'] = >> [self.range_types.get(range_type, None)] >> >> # Remove the objectclass >> if not keep_objectclass: > Could you please extract this change into an independent patch? I'm > thinking purely from possible backporting perspective. > > Otherwise looks good. Sure. Patches 0070 and 0071 attached. I'll link 0071 to the ticket for extending ID range types once it's pushed, for record's sake. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0071-Return-ipaRangeType-as-a-list-in-idrange-commands.patch Type: text/x-patch Size: 1161 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0070-3-Remove-hardcoded-values-from-idrange-plugin-tests.patch Type: text/x-patch Size: 6363 bytes Desc: not available URL: From abokovoy at redhat.com Tue Jun 11 12:04:04 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 11 Jun 2013 15:04:04 +0300 Subject: [Freeipa-devel] [PATCH] 0236 Flush stream after writing service messages In-Reply-To: <51B5DC28.9000801@redhat.com> References: <51B5DC28.9000801@redhat.com> Message-ID: <20130611120404.GQ26689@redhat.com> On Mon, 10 Jun 2013, Petr Viktorin wrote: >Hello, >This is related to testing but can be pushed independently. It will >make testing master much more pleasant. > > >sys.stdout is buffered by default if redirected to a file. >This may cause automated installation to appear hung. >Flush the stream so that messages are written immediately. Despite the fact that we have abstracted out output_fd in service class, in existing code it is only used against sys.stdout. Just in case it would be used against different output_fd, could you please make flush() conditional under output_fd.isatty() condition? -- / Alexander Bokovoy From abokovoy at redhat.com Tue Jun 11 12:32:19 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 11 Jun 2013 15:32:19 +0300 Subject: [Freeipa-devel] [PATCH] 0236 Flush stream after writing service messages In-Reply-To: <20130611120404.GQ26689@redhat.com> References: <51B5DC28.9000801@redhat.com> <20130611120404.GQ26689@redhat.com> Message-ID: <20130611123219.GR26689@redhat.com> On Tue, 11 Jun 2013, Alexander Bokovoy wrote: >On Mon, 10 Jun 2013, Petr Viktorin wrote: >>Hello, >>This is related to testing but can be pushed independently. It will >>make testing master much more pleasant. >> >> >>sys.stdout is buffered by default if redirected to a file. >>This may cause automated installation to appear hung. >>Flush the stream so that messages are written immediately. >Despite the fact that we have abstracted out output_fd in service class, >in existing code it is only used against sys.stdout. > >Just in case it would be used against different output_fd, could you please >make flush() conditional under output_fd.isatty() condition? On further thinking this conditioning is not really needed. So scratch it. ACK for the original patch. -- / Alexander Bokovoy From pviktori at redhat.com Tue Jun 11 12:43:56 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 11 Jun 2013 14:43:56 +0200 Subject: [Freeipa-devel] [PATCH] 0236 Flush stream after writing service messages In-Reply-To: <20130611123219.GR26689@redhat.com> References: <51B5DC28.9000801@redhat.com> <20130611120404.GQ26689@redhat.com> <20130611123219.GR26689@redhat.com> Message-ID: <51B71B8C.2010807@redhat.com> On 06/11/2013 02:32 PM, Alexander Bokovoy wrote: > On Tue, 11 Jun 2013, Alexander Bokovoy wrote: >> On Mon, 10 Jun 2013, Petr Viktorin wrote: >>> Hello, >>> This is related to testing but can be pushed independently. It will >>> make testing master much more pleasant. >>> >>> >>> sys.stdout is buffered by default if redirected to a file. >>> This may cause automated installation to appear hung. >>> Flush the stream so that messages are written immediately. >> Despite the fact that we have abstracted out output_fd in service class, >> in existing code it is only used against sys.stdout. >> >> Just in case it would be used against different output_fd, could you >> please >> make flush() conditional under output_fd.isatty() condition? > On further thinking this conditioning is not really needed. So scratch > it. > ACK for the original patch. > To elaborate why conditioning it's not needed: On a TTY, stdout is already unbuffered, so flush() is a no-op. In tests the stdout can be connected to Jenkins' console watcher or through a SSH channel to a controlling machine in integration tests. In these cases there's no TTY but we want the output flushed in case someone is tailing the output (or attaching timestamps to the lines). Also the messages are infrequent enough that performance isn't a concern. Pushed to master (as e8e88ed2084faeba7858f54c310e333b60513ed5) -- Petr? From akrivoka at redhat.com Tue Jun 11 14:09:04 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 11 Jun 2013 16:09:04 +0200 Subject: [Freeipa-devel] [PATCH 0030] Require rid-base and secondary-rid-base options in idrange-add when trust exists In-Reply-To: <51B09703.9080801@redhat.com> References: <51A4C406.5000206@redhat.com> <51A8DF79.9070700@redhat.com> <51B09703.9080801@redhat.com> Message-ID: <51B72F80.4000902@redhat.com> On 06/06/2013 04:04 PM, Tomas Babej wrote: > On 05/31/2013 07:35 PM, Ana Krivokapic wrote: >> On 05/28/2013 04:49 PM, Ana Krivokapic wrote: >>> Hello, >>> >>> This patch addresses https://fedorahosted.org/freeipa/ticket/3634 >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> This updated patch applies on top of tbabej's patches 0053-0055. >> >> As suggested by Tom?s( >> (https://www.redhat.com/archives/freeipa-devel/2013-May/msg00352.html), I >> refactored support of "mock" LDAP objects to tests/util, and modified >> test_range_plugin and test_cli to use it. >> -- >> Regards, >> >> Ana Krivokapic >> Associate Software Engineer >> FreeIPA team >> Red Hat Inc. >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > I looked thoroughly at the issue here.. > > The ticket is a little bit confusing about that, but you need to require > primary/secondary rid base for the range after ipa-adtrust-install has been run. > > Currently, the way your patch works, the bases are required only if at least > one trust exists. > > [root at vm-002 labtool]# ipa-adtrust-install > > The log file for this installation can be found in /var/log/ipaserver-install.log > [snip] > Setup complete > [snip] > > [root at vm-002 labtool]# ipa idrange-add local > First Posix ID of the range: 10 > Number of IDs in the range: 20 > ---------------------- > Added ID range "local" > ---------------------- > Range name: local > First Posix ID of the range: 10 > Number of IDs in the range: 20 > Range type: local domain range > > After adding the trust, everything works ok: > > [root at vm-002 labtool]# ipa trust-find > --------------- > 1 trust matched > --------------- > Realm name: test > Domain NetBIOS name: TEST > Domain Security Identifier: S-1-5-21-259319770-2312917334-591429603 > Trust type: Active Directory domain > > [root at vm-002 labtool]# ipa idrange-add local > First Posix ID of the range: 10 > Number of IDs in the range: 10 > First RID of the corresponding RID range: 10 > First RID of the secondary RID range: 20 > ---------------------- > Added ID range "local" > ---------------------- > Range name: local > First Posix ID of the range: 10 > Number of IDs in the range: 10 > First RID of the corresponding RID range: 10 > First RID of the secondary RID range: 20 > Range type: local domain range > > We should require for primary/secondary rid base after ipa-adtrust-install has > been run even if no trust is established. > > Tomas This patch introduces a new command which can be used to determine if ipa-adtrust-install has been run on the system. Tests have been amended accordingly. This patch applies on top of tbabej's patches 70 & 71. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0030-03-Require-rid-base-and-secondary-rid-base-in-idrange-a.patch Type: text/x-patch Size: 16841 bytes Desc: not available URL: From alee at redhat.com Tue Jun 11 14:42:25 2013 From: alee at redhat.com (Ade Lee) Date: Tue, 11 Jun 2013 10:42:25 -0400 Subject: [Freeipa-devel] [PATCH] 0029 Make sure replication works after DM password is changed In-Reply-To: <51B5E43F.809@redhat.com> References: <519357F3.3080408@redhat.com> <51935D92.8080407@redhat.com> <51936395.20409@redhat.com> <51937353.3090501@redhat.com> <51B19888.2050803@redhat.com> <51B5E43F.809@redhat.com> Message-ID: <1370961745.2400.96.camel@aleeredhat.laptop> On Mon, 2013-06-10 at 16:35 +0200, Ana Krivokapic wrote: > On 06/07/2013 10:23 AM, Tomas Babej wrote: > > > On 05/15/2013 01:36 PM, Ana Krivokapic wrote: > > > > > On 05/15/2013 12:29 PM, Petr Viktorin wrote: > > > > On 05/15/2013 12:04 PM, Tomas Babej wrote: > > > > > On 05/15/2013 11:40 AM, Ana Krivokapic wrote: > > > > > > Hello, > > > > > > > > > > > > See the commit message for details. > > > > > > > > > > > > https://fedorahosted.org/freeipa/ticket/3594 > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Freeipa-devel mailing list > > > > > > Freeipa-devel at redhat.com > > > > > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > > > > + def regenerate_ca_file(self, ca_file): > > > > > + dm_pwd_fd, dm_pwd_fname = tempfile.mkstemp() > > > > > + keydb_pwd_fd, keydb_pwd_fname = tempfile.mkstemp() > > > > > + > > > > > + os.write(dm_pwd_fd, self.dirman_password) > > > > > + os.close(dm_pwd_fd) > > > > > + > > > > > + keydb_pwd = '' > > > > > + with open('/etc/pki/pki-tomcat/password.conf') as f: > > > > > + for line in f.readlines(): > > > > > + key, value = line.strip().split('=') > > > > > + if key == 'internal': > > > > > + keydb_pwd = value > > > > > + break > > > > > + > > > > > + os.write(keydb_pwd_fd, keydb_pwd) > > > > > + os.close(keydb_pwd_fd) > > > > > + > > > > > + ipautil.run([ > > > > > + '/usr/bin/PKCS12Export', > > > > > + '-d', '/etc/pki/pki-tomcat/alias/', > > > > > + '-p', keydb_pwd_fname, > > > > > + '-w', dm_pwd_fname, > > > > > + '-o', ca_file > > > > > + ]) > > > > > + > > > > > > > > > > If the PKCS12Export call fails (returns non-zero code), we raise > > > > > exception here, and the temporary files are never removed. > > > > > > > > > > + os.remove(dm_pwd_fname) > > > > > + os.remove(keydb_pwd_fname) > > > > > > > > > > This might not be a big issue since mkstemp() call creates temporary > > > > > file readable and writable only be given user ID, > > > > > however, we should not leave files with passwords in plaintext on the > > > > > disk if it is not necessary. > > > > > > > > > > This can be easily prevented by wrapping the call up with > > > > > try-chatch-finally block, or using raiseonerr=False options of run > > > > > method. > > > > Or by using ipautil.write_tmp_file() ? the file it creates is always > > > > removed after it's closed/garbage collected, and it has a name attribute. > > > > > > > Updated patch uses `ipautil.write_tmp_file()`. > > > > > > > > > > > > _______________________________________________ > > > Freeipa-devel mailing list > > > Freeipa-devel at redhat.com > > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > I'm testing on a fairly updated F19 VM: > > > > I'm getting the following error when preparing the replica info > > file: > > > > [root at vm-002 ~]# ipa-replica-prepare vm-003.ipa.com --ip-address > > 192.168.122.213 > > Directory Manager (existing master) password: > > > > Preparing replica for vm-003.ipa.com from vm-002.ipa.com > > Command '/usr/bin/PKCS12Export -d /etc/pki/pki-tomcat/alias/ > > -p /tmp/tmp15Je9R -w /tmp/tmpCGD5Sr -o /root/cacert.p12' returned > > non > > > > When trying that manually: > > > > [root at vm-002 ~]# /usr/bin/PKCS12Export -d /etc/pki/pki-tomcat/alias/ > > -p /tmp/tmp15Je9R -w /tmp/tmpCGD5Sr -o /root/cacert.p12 > > Exception in thread "main" java.lang.NoClassDefFoundError: > > org/mozilla/jss/util/PasswordCallback > > at java.lang.Class.getDeclaredMethods0(Native Method) > > at java.lang.Class.privateGetDeclaredMethods(Class.java:2451) > > at java.lang.Class.getMethod0(Class.java:2694) > > at java.lang.Class.getMethod(Class.java:1622) > > at > > sun.launcher.LauncherHelper.getMainMethod(LauncherHelper.java:494) > > at > > sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:486) > > Caused by: java.lang.ClassNotFoundException: > > org.mozilla.jss.util.PasswordCallback > > at java.net.URLClassLoader$1.run(URLClassLoader.java:366) > > at java.net.URLClassLoader$1.run(URLClassLoader.java:355) > > at java.security.AccessController.doPrivileged(Native Method) > > at java.net.URLClassLoader.findClass(URLClassLoader.java:354) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:423) > > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:356) > > ... 6 more > > > > We might need to investigate what causes this, and if the issue is > > not on our side, file appropriate bugs. > > > > Tomas > > This is an bug in the PKCS12Export utility. I opened a Bugzilla for > it: https://bugzilla.redhat.com/show_bug.cgi?id=972753. > > Below is a workaround, as suggested by Ade: > as for a workaround, you could simply edit the file that starts > PKCS12Export > edit /usr/bin/PKCS12Export > after line 134, simply add the line : > CP=/usr/lib/java/jss4.jar > but thats just a temp fix for f19 only > not the real fix, > you'll need the real fix checked in to pass the patch > Just FYI, we plan to do a new release of pki-core today (pki-core-10.0.3-2) to address this issue. > -- > Regards, > > Ana Krivokapic > Associate Software Engineer > FreeIPA team > Red Hat Inc. From mkosek at redhat.com Tue Jun 11 16:03:38 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 11 Jun 2013 18:03:38 +0200 Subject: [Freeipa-devel] [PATCH 0030] Require rid-base and secondary-rid-base options in idrange-add when trust exists In-Reply-To: <51B72F80.4000902@redhat.com> References: <51A4C406.5000206@redhat.com> <51A8DF79.9070700@redhat.com> <51B09703.9080801@redhat.com> <51B72F80.4000902@redhat.com> Message-ID: <51B74A5A.2050903@redhat.com> On 06/11/2013 04:09 PM, Ana Krivokapic wrote: > On 06/06/2013 04:04 PM, Tomas Babej wrote: >> On 05/31/2013 07:35 PM, Ana Krivokapic wrote: >>> On 05/28/2013 04:49 PM, Ana Krivokapic wrote: >>>> Hello, >>>> >>>> This patch addresses https://fedorahosted.org/freeipa/ticket/3634 >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >>> This updated patch applies on top of tbabej's patches 0053-0055. >>> >>> As suggested by Tom?? >>> (https://www.redhat.com/archives/freeipa-devel/2013-May/msg00352.html), I >>> refactored support of "mock" LDAP objects to tests/util, and modified >>> test_range_plugin and test_cli to use it. >>> -- >>> Regards, >>> >>> Ana Krivokapic >>> Associate Software Engineer >>> FreeIPA team >>> Red Hat Inc. >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> I looked thoroughly at the issue here.. >> >> The ticket is a little bit confusing about that, but you need to require >> primary/secondary rid base for the range after ipa-adtrust-install has been run. >> >> Currently, the way your patch works, the bases are required only if at least >> one trust exists. >> >> [root at vm-002 labtool]# ipa-adtrust-install >> >> The log file for this installation can be found in /var/log/ipaserver-install.log >> [snip] >> Setup complete >> [snip] >> >> [root at vm-002 labtool]# ipa idrange-add local >> First Posix ID of the range: 10 >> Number of IDs in the range: 20 >> ---------------------- >> Added ID range "local" >> ---------------------- >> Range name: local >> First Posix ID of the range: 10 >> Number of IDs in the range: 20 >> Range type: local domain range >> >> After adding the trust, everything works ok: >> >> [root at vm-002 labtool]# ipa trust-find >> --------------- >> 1 trust matched >> --------------- >> Realm name: test >> Domain NetBIOS name: TEST >> Domain Security Identifier: S-1-5-21-259319770-2312917334-591429603 >> Trust type: Active Directory domain >> >> [root at vm-002 labtool]# ipa idrange-add local >> First Posix ID of the range: 10 >> Number of IDs in the range: 10 >> First RID of the corresponding RID range: 10 >> First RID of the secondary RID range: 20 >> ---------------------- >> Added ID range "local" >> ---------------------- >> Range name: local >> First Posix ID of the range: 10 >> Number of IDs in the range: 10 >> First RID of the corresponding RID range: 10 >> First RID of the secondary RID range: 20 >> Range type: local domain range >> >> We should require for primary/secondary rid base after ipa-adtrust-install >> has been run even if no trust is established. >> >> Tomas > > This patch introduces a new command which can be used to determine if > ipa-adtrust-install has been run on the system. > > Tests have been amended accordingly. > > This patch applies on top of tbabej's patches 70 & 71. Just 2 quick notes: 1) I would like the commands to be consistent with other similar commands like "dns_is_enabled". This would lead to "adtrust_is_enabled". 2) Is the used ldapsearch really the best way to find out if Trust is configured on a given master? Isn't a search in cn=masters,cn=ipa,... better? Alexander? Martin From mkosek at redhat.com Tue Jun 11 16:11:24 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 11 Jun 2013 18:11:24 +0200 Subject: [Freeipa-devel] Configuring FreeIPA with JBoss EAP In-Reply-To: <51B201D0.5060505@redhat.com> References: <51B1D903.8060303@redhat.com> <51B201D0.5060505@redhat.com> Message-ID: <51B74C2C.7000500@redhat.com> Ok, thanks for information. I filed an upstream ticket to capture the decision: https://fedorahosted.org/freeipa/ticket/3710 Please comment in the ticket if I forget anything. Thanks, Martin On 06/07/2013 05:52 PM, Peter Skopek wrote: > Hi Martin, > > the main reason why I suggested to not include the script in EAP is that we > removed all similar scripts (for example data-source definition files) from its > directories to keep is as simple and clean as possible. > JBoss EAP 6 configuration changes needed to integrate with FreeIPA are quite > stable and as EAP has it as API/CLI it is not going to change in the near > future (all JBoss EAP 6 [6.0.0, 6.0.1, 6.1.0] releases will work with > configuration proposed in config. document). > > I can understand, that similar reasons exist in FreeIPA side. So, the best way > would be your proposal to create the "freeipa-client-jboss" subpackage. > > Regards, > Peter > > On 06/07/2013 02:58 PM, Martin Kosek wrote: >> Hello Jan a Peter, freeipa-devel users, >> >> There was recently a project of integrating FreeIPA server with Jboss EAP. One >> of the results of this project should be a script able to conveniently >> configure JBoss EAP on a machine to use FreeIPA as an identity&authentication >> backend. >> >> What I would like to find out is what would be the best place to store&maintain >> such script. AFAIK, JBoss EAP did not want to keep the configuration script >> with their project - can you Peter please share the reasons for it? I was >> thinking it would be then easier to maintain the script according to JBoss EAP >> releases. >> >> Second option would be to deploy the script with FreeIPA project. Then, they >> would also conform to FreeIPA release schedule and not JBoss ones. So I was >> pondering where should we put scripts like this one, it is quite a specific >> script, so I do not want to keeping it with freeipa-client package. >> >> In this case I would propose creating a new optional subpackage >> "freeipa-client-jboss" which would include all scripts/docs for the JBoss EAP >> integration (may extend in future). In future, there may also come more >> thematic FreeIPA integration scripts when they cannot be stored in relevant >> upstream projects. >> >> Any ideas? Is the correct approach to keep configuration scripts for other >> upstream projects? >> >> Thanks, >> Martin >> From abokovoy at redhat.com Tue Jun 11 16:24:38 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 11 Jun 2013 19:24:38 +0300 Subject: [Freeipa-devel] [PATCH 0030] Require rid-base and secondary-rid-base options in idrange-add when trust exists In-Reply-To: <51B74A5A.2050903@redhat.com> References: <51A4C406.5000206@redhat.com> <51A8DF79.9070700@redhat.com> <51B09703.9080801@redhat.com> <51B72F80.4000902@redhat.com> <51B74A5A.2050903@redhat.com> Message-ID: <20130611162438.GS26689@redhat.com> On Tue, 11 Jun 2013, Martin Kosek wrote: >> This patch introduces a new command which can be used to determine if >> ipa-adtrust-install has been run on the system. >> >> Tests have been amended accordingly. >> >> This patch applies on top of tbabej's patches 70 & 71. > >Just 2 quick notes: > >1) I would like the commands to be consistent with other similar commands like >"dns_is_enabled". This would lead to "adtrust_is_enabled". I agree. Ideally we could have defined is-enabled command that would have accepted a name and then checked if conditions were met to 'enable' that one, but we already have dns_is_enabled. >2) Is the used ldapsearch really the best way to find out if Trust is >configured on a given master? Isn't a search in cn=masters,cn=ipa,... better? >Alexander? What would the search in cn=masters,cn=ipa,.. give? We can have multiple CIFS services per realm. However, only those in 'adtrust agents' group are the ones which are real DCs. And since membership in the group is not handled via framework or UI, it is clear indication that ipa-adtrust-install was run. -- / Alexander Bokovoy From mkosek at redhat.com Tue Jun 11 16:34:40 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 11 Jun 2013 18:34:40 +0200 Subject: [Freeipa-devel] [PATCH 0030] Require rid-base and secondary-rid-base options in idrange-add when trust exists In-Reply-To: <20130611162438.GS26689@redhat.com> References: <51A4C406.5000206@redhat.com> <51A8DF79.9070700@redhat.com> <51B09703.9080801@redhat.com> <51B72F80.4000902@redhat.com> <51B74A5A.2050903@redhat.com> <20130611162438.GS26689@redhat.com> Message-ID: <51B751A0.2070705@redhat.com> On 06/11/2013 06:24 PM, Alexander Bokovoy wrote: > On Tue, 11 Jun 2013, Martin Kosek wrote: >>> This patch introduces a new command which can be used to determine if >>> ipa-adtrust-install has been run on the system. >>> >>> Tests have been amended accordingly. >>> >>> This patch applies on top of tbabej's patches 70 & 71. >> >> Just 2 quick notes: >> >> 1) I would like the commands to be consistent with other similar commands like >> "dns_is_enabled". This would lead to "adtrust_is_enabled". > I agree. Ideally we could have defined is-enabled command that would > have accepted a name and then checked if conditions were met to 'enable' > that one, but we already have dns_is_enabled. Right. > > >> 2) Is the used ldapsearch really the best way to find out if Trust is >> configured on a given master? Isn't a search in cn=masters,cn=ipa,... better? >> Alexander? > What would the search in cn=masters,cn=ipa,.. give? > > We can have multiple CIFS services per realm. However, only those in > 'adtrust agents' group are the ones which are real DCs. And since > membership in the group is not handled via framework or UI, it is clear > indication that ipa-adtrust-install was run. It would say if there as an appropriate service configured by ipa-adtrust-install. In this case, "cn=ADTRUST,cn=FQDN,cn=masters,cn=ipa,cn=etc,SUFFIX. I am asking because this is a standard way in FreeIPA to ask for configured services. If that does not work for Trust, then your alternative way should be OK too. Martin From abokovoy at redhat.com Tue Jun 11 16:44:57 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 11 Jun 2013 19:44:57 +0300 Subject: [Freeipa-devel] [PATCH 0030] Require rid-base and secondary-rid-base options in idrange-add when trust exists In-Reply-To: <51B751A0.2070705@redhat.com> References: <51A4C406.5000206@redhat.com> <51A8DF79.9070700@redhat.com> <51B09703.9080801@redhat.com> <51B72F80.4000902@redhat.com> <51B74A5A.2050903@redhat.com> <20130611162438.GS26689@redhat.com> <51B751A0.2070705@redhat.com> Message-ID: <20130611164457.GT26689@redhat.com> On Tue, 11 Jun 2013, Martin Kosek wrote: >>> 2) Is the used ldapsearch really the best way to find out if Trust is >>> configured on a given master? Isn't a search in cn=masters,cn=ipa,... better? >>> Alexander? >> What would the search in cn=masters,cn=ipa,.. give? >> >> We can have multiple CIFS services per realm. However, only those in >> 'adtrust agents' group are the ones which are real DCs. And since >> membership in the group is not handled via framework or UI, it is clear >> indication that ipa-adtrust-install was run. > >It would say if there as an appropriate service configured by >ipa-adtrust-install. In this case, >"cn=ADTRUST,cn=FQDN,cn=masters,cn=ipa,cn=etc,SUFFIX. I am asking because this >is a standard way in FreeIPA to ask for configured services. > >If that does not work for Trust, then your alternative way should be OK too. This would work for making sure that ipa-adtrust-install was run on a specific server. It will not work for making sure trusts are enabled but in this case we only need to know that we have configured the host to be a DC so your approach is fine. I'm fine to use this approach, somehow it slipped out of my view when we discussed it with Ana.. -- / Alexander Bokovoy From jpazdziora at redhat.com Wed Jun 12 08:06:20 2013 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Wed, 12 Jun 2013 10:06:20 +0200 Subject: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used In-Reply-To: <51B1DEE4.6090300@redhat.com> References: <038.85636923ffc7d7f47d64dd7308c2c527@fedorahosted.org> <053.e8f59eb95b19dcdbcf715e1166fb104a@fedorahosted.org> <51B1CC41.30401@redhat.com> <51B1D16C.2010201@redhat.com> <51B1D820.3090304@redhat.com> <51B1DB60.2010705@redhat.com> <51B1DEE4.6090300@redhat.com> Message-ID: <20130612080620.GA12641@redhat.com> On Fri, Jun 07, 2013 at 09:23:48AM -0400, Dmitri Pal wrote: > > > > The problem is that if you pass IPA certificates issued by CA2 and > > point it to CA1 at the same time, it does not work (despite having the > > complete trust chain). > > But why would you do so? What would be the reason and business case? Why > not to point to CA2? Could the business case be an IPA server in DMZ which does not have access to CA2 but it can get to (public) CA1? -- Jan Pazdziora | adelton at #ipa*, #brno Principal Software Engineer, Identity Management Engineering, Red Hat From abokovoy at redhat.com Wed Jun 12 08:23:16 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 12 Jun 2013 11:23:16 +0300 Subject: [Freeipa-devel] [PATCH] 0033 Fail when adding a trust with a different range In-Reply-To: <51B5F137.5060803@redhat.com> References: <51A87688.2070107@redhat.com> <51B1B2DF.3050101@redhat.com> <51B20107.4050405@redhat.com> <51B59854.1030404@redhat.com> <51B5F137.5060803@redhat.com> Message-ID: <20130612082316.GU26689@redhat.com> On Mon, 10 Jun 2013, Ana Krivokapic wrote: >> And once here(added by your patch): >> >> + if not self.validate_range(*keys, **options): >> + raise errors.ValidationError( >> + name=_('id range'), >> + error=_( >> + 'An id range already exists for this trust. ' >> + 'You should either delete the old range, or ' >> + 'exclude --base-id/--range-size options from the >> command.' >> >> I'd suggest we have one common place, say validate_range() function as >> we have now, >> that contains all the checks (more coming in the future for sure). >> >> That would mean that the whole trust-add command will fail in the case >> that "ID range >> with the same name but different domain SID already exists", since we >> now call validate_range() >> within execute() method. I checked with Alexander and we agreed that >> this is more desired behaviour. >> >> This would also result to reducement of the number of API calls, which >> is a nice benefit. >> >> Tomas > >This updated patch completely separates validation logic and object >creation logic of the trust_add command. I added two new methods: > >* validate_range(), which ensures that the options and environment >related to idrange is valid, and >* validate_options, which takes care of other general validation > >One change introduced in this patch is making the >__populate_remote_domain() method of TrustDomainJoins class public, and >calling it from trust_add. This was necessary in order to enable >discovering details of the trusted domain in validation phase. Looks good overall but I'd suggest to wrap populate_remote_domain() calls in join_ad_* methods instead of removing them. If remote domain is not initialized (i.e. not(isinstance(self.remote_domain,TrustedDomainInstance)), then call populate_remote_domain() as it was before. -- / Alexander Bokovoy From tbabej at redhat.com Wed Jun 12 09:40:22 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 12 Jun 2013 11:40:22 +0200 Subject: [Freeipa-devel] [PATCH] 0033 Fail when adding a trust with a different range In-Reply-To: <20130612082316.GU26689@redhat.com> References: <51A87688.2070107@redhat.com> <51B1B2DF.3050101@redhat.com> <51B20107.4050405@redhat.com> <51B59854.1030404@redhat.com> <51B5F137.5060803@redhat.com> <20130612082316.GU26689@redhat.com> Message-ID: <51B84206.30601@redhat.com> On 06/12/2013 10:23 AM, Alexander Bokovoy wrote: > On Mon, 10 Jun 2013, Ana Krivokapic wrote: >>> And once here(added by your patch): >>> >>> + if not self.validate_range(*keys, **options): >>> + raise errors.ValidationError( >>> + name=_('id range'), >>> + error=_( >>> + 'An id range already exists for this trust. ' >>> + 'You should either delete the old range, or ' >>> + 'exclude --base-id/--range-size options from the >>> command.' >>> >>> I'd suggest we have one common place, say validate_range() function as >>> we have now, >>> that contains all the checks (more coming in the future for sure). >>> >>> That would mean that the whole trust-add command will fail in the case >>> that "ID range >>> with the same name but different domain SID already exists", since we >>> now call validate_range() >>> within execute() method. I checked with Alexander and we agreed that >>> this is more desired behaviour. >>> >>> This would also result to reducement of the number of API calls, which >>> is a nice benefit. >>> >>> Tomas >> >> This updated patch completely separates validation logic and object >> creation logic of the trust_add command. I added two new methods: >> >> * validate_range(), which ensures that the options and environment >> related to idrange is valid, and >> * validate_options, which takes care of other general validation >> >> One change introduced in this patch is making the >> __populate_remote_domain() method of TrustDomainJoins class public, and >> calling it from trust_add. This was necessary in order to enable >> discovering details of the trusted domain in validation phase. > Looks good overall but I'd suggest to wrap populate_remote_domain() > calls in join_ad_* methods instead of removing them. If remote domain is > not initialized (i.e. > not(isinstance(self.remote_domain,TrustedDomainInstance)), > then call populate_remote_domain() as it was before. > I tested the patch and it works fine. There's a lot of refactoring done, but the changes preserve equal state. Aside from Alexander's comment up here, I have but one nitpick. There are few constructs of the form: try: value = dictionary['keyword'] except KeyError: value = None or if 'keyword' in dictionary: value = dictionary['keyword'] else: value = None Can you please substitute these with "value = dictionary.get(keyword, None)"? Not everywhere, but there are places where it can improve readability of the code. All from me for now, Tomas From mkosek at redhat.com Wed Jun 12 10:14:47 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 12 Jun 2013 12:14:47 +0200 Subject: [Freeipa-devel] [PATCH] 0033 Fail when adding a trust with a different range In-Reply-To: <51B84206.30601@redhat.com> References: <51A87688.2070107@redhat.com> <51B1B2DF.3050101@redhat.com> <51B20107.4050405@redhat.com> <51B59854.1030404@redhat.com> <51B5F137.5060803@redhat.com> <20130612082316.GU26689@redhat.com> <51B84206.30601@redhat.com> Message-ID: <51B84A17.5000207@redhat.com> On 06/12/2013 11:40 AM, Tomas Babej wrote: > On 06/12/2013 10:23 AM, Alexander Bokovoy wrote: >> On Mon, 10 Jun 2013, Ana Krivokapic wrote: >>>> And once here(added by your patch): >>>> >>>> + if not self.validate_range(*keys, **options): >>>> + raise errors.ValidationError( >>>> + name=_('id range'), >>>> + error=_( >>>> + 'An id range already exists for this trust. ' >>>> + 'You should either delete the old range, or ' >>>> + 'exclude --base-id/--range-size options from the >>>> command.' >>>> >>>> I'd suggest we have one common place, say validate_range() function as >>>> we have now, >>>> that contains all the checks (more coming in the future for sure). >>>> >>>> That would mean that the whole trust-add command will fail in the case >>>> that "ID range >>>> with the same name but different domain SID already exists", since we >>>> now call validate_range() >>>> within execute() method. I checked with Alexander and we agreed that >>>> this is more desired behaviour. >>>> >>>> This would also result to reducement of the number of API calls, which >>>> is a nice benefit. >>>> >>>> Tomas >>> >>> This updated patch completely separates validation logic and object >>> creation logic of the trust_add command. I added two new methods: >>> >>> * validate_range(), which ensures that the options and environment >>> related to idrange is valid, and >>> * validate_options, which takes care of other general validation >>> >>> One change introduced in this patch is making the >>> __populate_remote_domain() method of TrustDomainJoins class public, and >>> calling it from trust_add. This was necessary in order to enable >>> discovering details of the trusted domain in validation phase. >> Looks good overall but I'd suggest to wrap populate_remote_domain() >> calls in join_ad_* methods instead of removing them. If remote domain is >> not initialized (i.e. not(isinstance(self.remote_domain,TrustedDomainInstance)), >> then call populate_remote_domain() as it was before. >> > I tested the patch and it works fine. > > There's a lot of refactoring done, but the changes preserve equal state. Aside > from > Alexander's comment up here, I have but one nitpick. > > There are few constructs of the form: > > try: > value = dictionary['keyword'] > except KeyError: > value = None > > or > > if 'keyword' in dictionary: > value = dictionary['keyword'] > else: > value = None > > Can you please substitute these with "value = dictionary.get(keyword, None)"? > Not everywhere, but there are places where it can improve readability of the code. You can even use just "value = dictionary.get(keyword)" as None is the default return value: >>> print {}.get("foo") None Martin From pviktori at redhat.com Wed Jun 12 11:40:25 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 12 Jun 2013 13:40:25 +0200 Subject: [Freeipa-devel] [PATCHES] 134-139 CA-less fixes In-Reply-To: <51B1E29D.30901@redhat.com> References: <51B1E29D.30901@redhat.com> Message-ID: <51B85E29.5030300@redhat.com> On 06/07/2013 03:39 PM, Jan Cholasta wrote: > Hi, > > the attached patches fix some of the issues I have found while working > on test plan for CA-less install (see > for more > information on that). > > https://fedorahosted.org/freeipa/ticket/3665 > https://fedorahosted.org/freeipa/ticket/3667 > https://fedorahosted.org/freeipa/ticket/3673 > https://fedorahosted.org/freeipa/ticket/3674 > https://fedorahosted.org/freeipa/ticket/3675 > > Honza > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > ACK, pushed to master & ipa-3-2. -- Petr? From tbabej at redhat.com Wed Jun 12 12:28:05 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 12 Jun 2013 14:28:05 +0200 Subject: [Freeipa-devel] [PATCH 0073] Remove support for IPA deployments with no persistent search Message-ID: <51B86955.6040905@redhat.com> Hi, Drops the code from ipa-server-install, ipa-dns-install and the BindInstance itself. Also changed ipa-upgradeconfig script so that it does not set zone_refresh to 0 on upgrades, as the option is deprecated, but rather removes it altogether. https://fedorahosted.org/freeipa/ticket/3632 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0073-Remove-support-for-IPA-deployments-with-no-persisten.patch Type: text/x-patch Size: 10891 bytes Desc: not available URL: From akrivoka at redhat.com Wed Jun 12 17:06:50 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 12 Jun 2013 19:06:50 +0200 Subject: [Freeipa-devel] [PATCH 0030] Require rid-base and secondary-rid-base options in idrange-add when trust exists In-Reply-To: <20130611164457.GT26689@redhat.com> References: <51A4C406.5000206@redhat.com> <51A8DF79.9070700@redhat.com> <51B09703.9080801@redhat.com> <51B72F80.4000902@redhat.com> <51B74A5A.2050903@redhat.com> <20130611162438.GS26689@redhat.com> <51B751A0.2070705@redhat.com> <20130611164457.GT26689@redhat.com> Message-ID: <51B8AAAA.2000701@redhat.com> On 06/11/2013 06:44 PM, Alexander Bokovoy wrote: > On Tue, 11 Jun 2013, Martin Kosek wrote: >>>> 2) Is the used ldapsearch really the best way to find out if Trust is >>>> configured on a given master? Isn't a search in cn=masters,cn=ipa,... better? >>>> Alexander? >>> What would the search in cn=masters,cn=ipa,.. give? >>> >>> We can have multiple CIFS services per realm. However, only those in >>> 'adtrust agents' group are the ones which are real DCs. And since >>> membership in the group is not handled via framework or UI, it is clear >>> indication that ipa-adtrust-install was run. >> >> It would say if there as an appropriate service configured by >> ipa-adtrust-install. In this case, >> "cn=ADTRUST,cn=FQDN,cn=masters,cn=ipa,cn=etc,SUFFIX. I am asking because this >> is a standard way in FreeIPA to ask for configured services. >> >> If that does not work for Trust, then your alternative way should be OK too. > This would work for making sure that ipa-adtrust-install was run on a > specific server. It will not work for making sure trusts are enabled > but in this case we only need to know that we have configured the host > to be a DC so your approach is fine. > > I'm fine to use this approach, somehow it slipped out of my view when we > discussed it with Ana.. > > I amended the name of the new command to 'adtrust_is_enabled'. I also simplified the LDAP search used in the command, as suggested by Martin and Alexander. Updated patch is attached. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0030-04-Require-rid-base-and-secondary-rid-base-in-idrange-a.patch Type: text/x-patch Size: 16149 bytes Desc: not available URL: From rcritten at redhat.com Thu Jun 13 02:34:54 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 12 Jun 2013 22:34:54 -0400 Subject: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used In-Reply-To: <20130612080620.GA12641@redhat.com> References: <038.85636923ffc7d7f47d64dd7308c2c527@fedorahosted.org> <053.e8f59eb95b19dcdbcf715e1166fb104a@fedorahosted.org> <51B1CC41.30401@redhat.com> <51B1D16C.2010201@redhat.com> <51B1D820.3090304@redhat.com> <51B1DB60.2010705@redhat.com> <51B1DEE4.6090300@redhat.com> <20130612080620.GA12641@redhat.com> Message-ID: <51B92FCE.6040406@redhat.com> Jan Pazdziora wrote: > On Fri, Jun 07, 2013 at 09:23:48AM -0400, Dmitri Pal wrote: >>> >>> The problem is that if you pass IPA certificates issued by CA2 and >>> point it to CA1 at the same time, it does not work (despite having the >>> complete trust chain). >> >> But why would you do so? What would be the reason and business case? Why >> not to point to CA2? > > Could the business case be an IPA server in DMZ which does not have > access to CA2 but it can get to (public) CA1? > A client does need to be able to contact a CA in order to trust it. rob From akrivoka at redhat.com Thu Jun 13 10:17:17 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 13 Jun 2013 12:17:17 +0200 Subject: [Freeipa-devel] [PATCH] 0033 Fail when adding a trust with a different range In-Reply-To: <51B84A17.5000207@redhat.com> References: <51A87688.2070107@redhat.com> <51B1B2DF.3050101@redhat.com> <51B20107.4050405@redhat.com> <51B59854.1030404@redhat.com> <51B5F137.5060803@redhat.com> <20130612082316.GU26689@redhat.com> <51B84206.30601@redhat.com> <51B84A17.5000207@redhat.com> Message-ID: <51B99C2D.7010301@redhat.com> On 06/12/2013 12:14 PM, Martin Kosek wrote: > On 06/12/2013 11:40 AM, Tomas Babej wrote: >> On 06/12/2013 10:23 AM, Alexander Bokovoy wrote: >>> On Mon, 10 Jun 2013, Ana Krivokapic wrote: >>>>> And once here(added by your patch): >>>>> >>>>> + if not self.validate_range(*keys, **options): >>>>> + raise errors.ValidationError( >>>>> + name=_('id range'), >>>>> + error=_( >>>>> + 'An id range already exists for this trust. ' >>>>> + 'You should either delete the old range, or ' >>>>> + 'exclude --base-id/--range-size options from the >>>>> command.' >>>>> >>>>> I'd suggest we have one common place, say validate_range() function as >>>>> we have now, >>>>> that contains all the checks (more coming in the future for sure). >>>>> >>>>> That would mean that the whole trust-add command will fail in the case >>>>> that "ID range >>>>> with the same name but different domain SID already exists", since we >>>>> now call validate_range() >>>>> within execute() method. I checked with Alexander and we agreed that >>>>> this is more desired behaviour. >>>>> >>>>> This would also result to reducement of the number of API calls, which >>>>> is a nice benefit. >>>>> >>>>> Tomas >>>> This updated patch completely separates validation logic and object >>>> creation logic of the trust_add command. I added two new methods: >>>> >>>> * validate_range(), which ensures that the options and environment >>>> related to idrange is valid, and >>>> * validate_options, which takes care of other general validation >>>> >>>> One change introduced in this patch is making the >>>> __populate_remote_domain() method of TrustDomainJoins class public, and >>>> calling it from trust_add. This was necessary in order to enable >>>> discovering details of the trusted domain in validation phase. >>> Looks good overall but I'd suggest to wrap populate_remote_domain() >>> calls in join_ad_* methods instead of removing them. If remote domain is >>> not initialized (i.e. not(isinstance(self.remote_domain,TrustedDomainInstance)), >>> then call populate_remote_domain() as it was before. Fixed. >> I tested the patch and it works fine. >> >> There's a lot of refactoring done, but the changes preserve equal state. Aside >> from >> Alexander's comment up here, I have but one nitpick. >> >> There are few constructs of the form: >> >> try: >> value = dictionary['keyword'] >> except KeyError: >> value = None >> >> or >> >> if 'keyword' in dictionary: >> value = dictionary['keyword'] >> else: >> value = None >> >> Can you please substitute these with "value = dictionary.get(keyword, None)"? >> Not everywhere, but there are places where it can improve readability of the code. > You can even use just "value = dictionary.get(keyword)" as None is the default > return value: > >>>> print {}.get("foo") Fixed. > None > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Updated patch attached. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0033-04-Fail-when-adding-a-trust-with-a-different-range.patch Type: text/x-patch Size: 14989 bytes Desc: not available URL: From pvoborni at redhat.com Thu Jun 13 10:30:47 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 13 Jun 2013 12:30:47 +0200 Subject: [Freeipa-devel] [PATCH] 420 Regression fix: rule table with ext. member support doesn't offer any items Message-ID: <51B99F57.5060708@redhat.com> Rule tables with external member has more than one column and therefore exclude parameter for adder dialog is not array of strings but array of objects. normalize_values function can't work with it and causes JS error. This patch creates proper exclude array before passing it to adder dialog. https://fedorahosted.org/freeipa/ticket/3711 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0420-Regression-fix-rule-table-with-ext.-member-support-d.patch Type: text/x-patch Size: 1805 bytes Desc: not available URL: From pviktori at redhat.com Thu Jun 13 12:16:36 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 13 Jun 2013 14:16:36 +0200 Subject: [Freeipa-devel] [PATCHES] 0230-0240 Integration testing framework In-Reply-To: <51B5E72E.80000@redhat.com> References: <51A88DA9.806@redhat.com> <51B5E72E.80000@redhat.com> Message-ID: <51B9B824.7030301@redhat.com> On 06/10/2013 04:48 PM, Petr Viktorin wrote: > On 05/31/2013 01:46 PM, Petr Viktorin wrote: >> Apply on top of my patches 0227-0234. >> >> These patches add an initial integration testing framework. >> >> Patch 0230 adds a plugin for ordered test classes. >> Nose orders methods within a test suite alphabetically, but we generally >> want to run them in the order defined. This adds the @ordered decorator >> that causes Nose to do just that, provided the plugin is loaded and >> enabled, and that the methods are defined in the same file. The >> ipa-run-tests wrapper is changed to enable the plugin. >> In the future we may want to use this for unit tests as well. It might >> also make sense to separate it from the FreeIPA project altogether. >> >> Patch 0231 adds configuration for tests. This reads environment >> variables like: >> - MASTER (FQDN of initial server) >> - REPLICA (space-separated FQDNs of replicas) >> - CLIENT (space-separated FQDNs of clients), >> - IPATEST_DIR (directory the tests use on the remote machines) >> etc., and loads them into an easy-to use Python object. >> A tool called ipa-test-config is provided that generates a full set of >> environment variables for shell-based tests from these, either global or >> specific for a given host. >> If environment variables don't work for us, alternate configuration >> methods can be added in the future. >> >> Patch 0232 adds an integration test framework. >> This extends Host object available from the configuration with methods >> to run commands and copy files on the remote host, and adds a base class >> for integration tests which can currently install and uninstall IPA in a >> "star" topology. (In the future, the install/uninstall code should also >> be made available as a shell command.) >> A simple test for user replication between two masters is provided. >> Log files from the remote hosts can be marked for collection, but the >> actual collection is left to a Nose plugin. >> The base class uses the @ordered decorator mentioned above. >> >> Patch 0233 improves on how commands are run on remote hosts. >> In the previous patch, the process's stdin and stdout were combined as a >> quick hack to avoid the problem that if we first read stdout and then >> stderr, then stderr's buffer can fill up and we'd deadlock (and the >> other way around). With this patch the streams are read in parallel. >> In the future this can be extended to calling whole commands in parallel >> (e.g. uninstalling IPA on all the hosts at once). >> >> Patch 0234 adds log collection to the BeakerLib integration plugin. >> This tars up the marked logs, downloads then, and calls rlFileSubmit on >> them. >> >> --- > > Attaching additional patches: > > Patch 0237 configures logging in ipa-run-tests to forward messages from > the IPA logging machinery to a normal Python logger. This way the logs > are captured > The logs are also printed to stderr so that there's some activity on the > terminal after you run the utility. > > Patch 0238 makes it possible to use RSA private SSH keys to log in to > the remote machines. The key is given in $IPA_ROOT_SSH_KEY, and used if > $IPA_ROOT_SSH_PASSWORD is empty. > I've added this to the design page. > > Patch 0239 makes test setup change the hostname, /etc/hosts, and > /etc/resolv.conf to match the configured values. These should be > equivalent to the fixes in > https://github.com/freeipa/tests/blob/master/ipa-tests/beaker/ipa-server/shared/ipa-install.sh#L733 > > In test teardown, the changes are undone. I've rebased the patrchset and added small fixes for patches 0232 and 0239. New patch 0240 contains a few fixes/improvements to the Host class that were not trivial to rebase into previous patches. The WIP patch adds a sketch of some of the tests for CA-less (http://www.freeipa.org/page/V3/CA-less_install#Test_Plan). Please comment if you can see where things can be improved for test authors! For your convenience, there is a Git repo with the changes available at git://github.com/encukou/freeipa.git, branch integration-testing. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0230.2-Add-a-plugin-for-test-ordering.patch Type: text/x-patch Size: 4190 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0231.2-Add-a-framework-for-integration-test-configuration.patch Type: text/x-patch Size: 21290 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0232.2-Add-a-framework-for-integration-testing.patch Type: text/x-patch Size: 22712 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0233.2-Introduce-a-class-for-remote-commands.patch Type: text/x-patch Size: 10810 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0234.2-Collect-logs-from-tests.patch Type: text/x-patch Size: 7020 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0237.2-Show-logs-in-failed-tests.patch Type: text/x-patch Size: 3124 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0238.2-tests-Allow-public-keys-for-authentication-to-the-re.patch Type: text/x-patch Size: 4173 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0239.2-tests-Configure-unconfigure-remote-hosts.patch Type: text/x-patch Size: 9826 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0240.2-Host-class-improvements.patch Type: text/x-patch Size: 6259 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: WIP-Add-initial-CA-less-installation-tests.patch Type: text/x-patch Size: 21357 bytes Desc: not available URL: From akrivoka at redhat.com Thu Jun 13 12:46:26 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 13 Jun 2013 14:46:26 +0200 Subject: [Freeipa-devel] [PATCH] 420 Regression fix: rule table with ext. member support doesn't offer any items In-Reply-To: <51B99F57.5060708@redhat.com> References: <51B99F57.5060708@redhat.com> Message-ID: <51B9BF22.30006@redhat.com> On 06/13/2013 12:30 PM, Petr Vobornik wrote: > Rule tables with external member has more than one column and therefore > exclude parameter for adder dialog is not array of strings but array of > objects. normalize_values function can't work with it and causes JS error. > > This patch creates proper exclude array before passing it to adder dialog. > > https://fedorahosted.org/freeipa/ticket/3711 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Thu Jun 13 13:24:47 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 13 Jun 2013 15:24:47 +0200 Subject: [Freeipa-devel] [PATCH] 420 Regression fix: rule table with ext. member support doesn't offer any items In-Reply-To: <51B9BF22.30006@redhat.com> References: <51B99F57.5060708@redhat.com> <51B9BF22.30006@redhat.com> Message-ID: <51B9C81F.8030508@redhat.com> On 06/13/2013 02:46 PM, Ana Krivokapic wrote: > On 06/13/2013 12:30 PM, Petr Vobornik wrote: >> Rule tables with external member has more than one column and >> therefore exclude parameter for adder dialog is not array of strings >> but array of objects. normalize_values function can't work with it and >> causes JS error. >> >> This patch creates proper exclude array before passing it to adder >> dialog. >> >> https://fedorahosted.org/freeipa/ticket/3711 > ACK > > I've noticed that there is a leftover from a different approach: pkey: pkey, + param: that.name, other_entity: that.other_entity, The line is removed, updated patch attached. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0420-1-Regression-fix-rule-table-with-ext.-member-support-d.patch Type: text/x-patch Size: 1798 bytes Desc: not available URL: From mkosek at redhat.com Thu Jun 13 13:29:46 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 13 Jun 2013 15:29:46 +0200 Subject: [Freeipa-devel] [PATCH] 410-411 Drop selinux subpackage Message-ID: <51B9C94A.4020507@redhat.com> All SELinux policy needed by FreeIPA server is now part of the global system SELinux policy which makes the subpackage redundant and slowing down the installation. This patch drops it. Second patch removes /var/cache/ipa/sessions which was redundant. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-410-drop-selinux-subpackage.patch Type: text/x-patch Size: 17639 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-411-drop-redundant-directory-var-cache-ipa-sessions.patch Type: text/x-patch Size: 2414 bytes Desc: not available URL: From akrivoka at redhat.com Thu Jun 13 14:16:50 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 13 Jun 2013 16:16:50 +0200 Subject: [Freeipa-devel] [PATCH] 0036 Fix displaying of success message Message-ID: <51B9D452.6080305@redhat.com> Hello, Make sure that the success message in web UI is properly populated with actual number of items that were successfully added/removed. https://fedorahosted.org/freeipa/ticket/3708 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0036-Fix-displaying-of-success-message.patch Type: text/x-patch Size: 5253 bytes Desc: not available URL: From akrivoka at redhat.com Thu Jun 13 15:13:50 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 13 Jun 2013 17:13:50 +0200 Subject: [Freeipa-devel] [PATCH] 420 Regression fix: rule table with ext. member support doesn't offer any items In-Reply-To: <51B9C81F.8030508@redhat.com> References: <51B99F57.5060708@redhat.com> <51B9BF22.30006@redhat.com> <51B9C81F.8030508@redhat.com> Message-ID: <51B9E1AE.5000305@redhat.com> On 06/13/2013 03:24 PM, Petr Vobornik wrote: > On 06/13/2013 02:46 PM, Ana Krivokapic wrote: >> On 06/13/2013 12:30 PM, Petr Vobornik wrote: >>> Rule tables with external member has more than one column and >>> therefore exclude parameter for adder dialog is not array of strings >>> but array of objects. normalize_values function can't work with it and >>> causes JS error. >>> >>> This patch creates proper exclude array before passing it to adder >>> dialog. >>> >>> https://fedorahosted.org/freeipa/ticket/3711 > >> ACK >> >> > > I've noticed that there is a leftover from a different approach: > > pkey: pkey, > + param: that.name, > other_entity: that.other_entity, > > The line is removed, updated patch attached. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel I missed it too in the first patch. ACK for updated patch. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Thu Jun 13 15:18:46 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 13 Jun 2013 17:18:46 +0200 Subject: [Freeipa-devel] [PATCH] 0036 Fix displaying of success message In-Reply-To: <51B9D452.6080305@redhat.com> References: <51B9D452.6080305@redhat.com> Message-ID: <51B9E2D6.6070607@redhat.com> On 06/13/2013 04:16 PM, Ana Krivokapic wrote: > Hello, > > Make sure that the success message in web UI is properly populated with actual > number of items that were successfully added/removed. > > https://fedorahosted.org/freeipa/ticket/3708 > The changes look good. But I've found an existing issue in the code which was moved to get_succeeded: When no operation succeeds following code behaves incorrectly: + var succeeded = data.result.completed; + + if (!succeeded) { The condition is evaluated as true when data.result.completed === 0. It's not desired because the subsequent commands in the if block will raise JS error (data.result doesn't have results obj). So we should check for: if (typeof succeeded !== 'number') -- Petr Vobornik From akrivoka at redhat.com Thu Jun 13 15:33:01 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 13 Jun 2013 17:33:01 +0200 Subject: [Freeipa-devel] [PATCH] 0036 Fix displaying of success message In-Reply-To: <51B9E2D6.6070607@redhat.com> References: <51B9D452.6080305@redhat.com> <51B9E2D6.6070607@redhat.com> Message-ID: <51B9E62D.2080905@redhat.com> On 06/13/2013 05:18 PM, Petr Vobornik wrote: > On 06/13/2013 04:16 PM, Ana Krivokapic wrote: >> Hello, >> >> Make sure that the success message in web UI is properly populated with actual >> number of items that were successfully added/removed. >> >> https://fedorahosted.org/freeipa/ticket/3708 >> > > The changes look good. But I've found an existing issue in the code which was > moved to get_succeeded: > > When no operation succeeds following code behaves incorrectly: > > + var succeeded = data.result.completed; > + > + if (!succeeded) { > > The condition is evaluated as true when data.result.completed === 0. It's not > desired because the subsequent commands in the if block will raise JS error > (data.result doesn't have results obj). > > So we should check for: > if (typeof succeeded !== 'number') > > Nice catch, thanks. Updated patch attached. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0036-02-Fix-displaying-of-success-message.patch Type: text/x-patch Size: 5272 bytes Desc: not available URL: From pvoborni at redhat.com Thu Jun 13 15:49:55 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 13 Jun 2013 17:49:55 +0200 Subject: [Freeipa-devel] [PATCH] 0036 Fix displaying of success message In-Reply-To: <51B9E62D.2080905@redhat.com> References: <51B9D452.6080305@redhat.com> <51B9E2D6.6070607@redhat.com> <51B9E62D.2080905@redhat.com> Message-ID: <51B9EA23.7030904@redhat.com> On 06/13/2013 05:33 PM, Ana Krivokapic wrote: > On 06/13/2013 05:18 PM, Petr Vobornik wrote: >> On 06/13/2013 04:16 PM, Ana Krivokapic wrote: >>> Hello, >>> >>> Make sure that the success message in web UI is properly populated with actual >>> number of items that were successfully added/removed. >>> >>> https://fedorahosted.org/freeipa/ticket/3708 >>> >> >> The changes look good. But I've found an existing issue in the code which was >> moved to get_succeeded: >> >> When no operation succeeds following code behaves incorrectly: >> >> + var succeeded = data.result.completed; >> + >> + if (!succeeded) { >> >> The condition is evaluated as true when data.result.completed === 0. It's not >> desired because the subsequent commands in the if block will raise JS error >> (data.result doesn't have results obj). >> >> So we should check for: >> if (typeof succeeded !== 'number') >> >> > > Nice catch, thanks. Updated patch attached. > ACK, pushed to master, ipa-3-2. -- Petr Vobornik From pvoborni at redhat.com Thu Jun 13 15:50:44 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 13 Jun 2013 17:50:44 +0200 Subject: [Freeipa-devel] [PATCH] 420 Regression fix: rule table with ext. member support doesn't offer any items In-Reply-To: <51B9E1AE.5000305@redhat.com> References: <51B99F57.5060708@redhat.com> <51B9BF22.30006@redhat.com> <51B9C81F.8030508@redhat.com> <51B9E1AE.5000305@redhat.com> Message-ID: <51B9EA54.9050500@redhat.com> On 06/13/2013 05:13 PM, Ana Krivokapic wrote: > On 06/13/2013 03:24 PM, Petr Vobornik wrote: >> On 06/13/2013 02:46 PM, Ana Krivokapic wrote: >>> On 06/13/2013 12:30 PM, Petr Vobornik wrote: >>>> Rule tables with external member has more than one column and >>>> therefore exclude parameter for adder dialog is not array of strings >>>> but array of objects. normalize_values function can't work with it and >>>> causes JS error. >>>> >>>> This patch creates proper exclude array before passing it to adder >>>> dialog. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3711 >> >>> ACK >>> >> >> I've noticed that there is a leftover from a different approach: >> >> pkey: pkey, >> + param: that.name, >> other_entity: that.other_entity, >> >> The line is removed, updated patch attached. >> > > I missed it too in the first patch. ACK for updated patch. pushed to master, ipa-3-2. > > -- > Regards, > > Ana Krivokapic > Associate Software Engineer > FreeIPA team > Red Hat Inc. -- Petr Vobornik From pviktori at redhat.com Fri Jun 14 11:25:03 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 14 Jun 2013 13:25:03 +0200 Subject: [Freeipa-devel] [PATCH] 410-411 Drop selinux subpackage In-Reply-To: <51B9C94A.4020507@redhat.com> References: <51B9C94A.4020507@redhat.com> Message-ID: <51BAFD8F.5050800@redhat.com> On 06/13/2013 03:29 PM, Martin Kosek wrote: > All SELinux policy needed by FreeIPA server is now part of the global > system SELinux policy which makes the subpackage redundant and slowing > down the installation. This patch drops it. > > Second patch removes /var/cache/ipa/sessions which was redundant. > > Martin Works for me, cautious ACK -- Petr? From jcholast at redhat.com Fri Jun 14 13:20:36 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 14 Jun 2013 15:20:36 +0200 Subject: [Freeipa-devel] [PATCHES] 0227-0229 freeipa-tests package & Beaker integration plugin In-Reply-To: <51A4D370.6030307@redhat.com> References: <51A4D370.6030307@redhat.com> Message-ID: <51BB18A4.2070607@redhat.com> Hi, On 28.5.2013 17:55, Petr Viktorin wrote: > Hello, > > Patch 0227 creates the freeipa-tests package. > As a system package, it needs a more unique name than "tests", so I > renamed it to "ipatests". I also changed imports and references to it. > Sorry to everyone developing tests right now ?? there will be conflicts, > but hopefully they'll be straightforward. > Note that the test suite does not yet pass when run outside the Git > tree. Work on that is ongoing but not a priority right now (it's more > important to get some integration tests running). Help would be > appreciated :) Typo in commit message: "Tename the 'tests' directory ..." The patch needs rebasing. > > Patch 0228 adds a wrapper based on make-test which runs the > system-installed test suite. freeipa-tests installs it as > /usr/bin/ipa-run-tests. > As I said above the tests currently fail when run this way. > > Patch 0229 adds a Nose plugin for integration with BeakerLib[1]. When > the plugin is loaded (ipa-run-tests does that) and enabled (using the > --with-beakerlib option), it hooks into Nose and runs rlPhase*, rlPass, > rlFail and rlLog* Bash functions at appropriate events. > I still need to actually run the code, I will do that with your patches 230-240 included. Honza -- Jan Cholasta From pviktori at redhat.com Fri Jun 14 14:01:59 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 14 Jun 2013 16:01:59 +0200 Subject: [Freeipa-devel] [PATCHES] 0227-0229 freeipa-tests package & Beaker integration plugin In-Reply-To: <51BB18A4.2070607@redhat.com> References: <51A4D370.6030307@redhat.com> <51BB18A4.2070607@redhat.com> Message-ID: <51BB2257.40504@redhat.com> On 06/14/2013 03:20 PM, Jan Cholasta wrote: > Hi, > > On 28.5.2013 17:55, Petr Viktorin wrote: >> Hello, >> >> Patch 0227 creates the freeipa-tests package. >> As a system package, it needs a more unique name than "tests", so I >> renamed it to "ipatests". I also changed imports and references to it. >> Sorry to everyone developing tests right now ?? there will be conflicts, >> but hopefully they'll be straightforward. >> Note that the test suite does not yet pass when run outside the Git >> tree. Work on that is ongoing but not a priority right now (it's more >> important to get some integration tests running). Help would be >> appreciated :) > > Typo in commit message: "Tename the 'tests' directory ..." Thanks for the catch! > The patch needs rebasing. Attaching rebased versions. >> Patch 0228 adds a wrapper based on make-test which runs the >> system-installed test suite. freeipa-tests installs it as >> /usr/bin/ipa-run-tests. >> As I said above the tests currently fail when run this way. >> >> Patch 0229 adds a Nose plugin for integration with BeakerLib[1]. When >> the plugin is loaded (ipa-run-tests does that) and enabled (using the >> --with-beakerlib option), it hooks into Nose and runs rlPhase*, rlPass, >> rlFail and rlLog* Bash functions at appropriate events. >> > > I still need to actually run the code, I will do that with your patches > 230-240 included. If I may suggest, please test this set by itself. The tests?ipatests rename blocks or conflicts with other patches so it would be good to get it in soon, without waiting on the integration testing review. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0227.2-Make-an-ipa-tests-package.patch Type: text/x-patch Size: 71201 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0228.2-Add-ipa-run-tests-command.patch Type: text/x-patch Size: 2517 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0229.2-Add-Nose-plugin-for-BeakerLib-integration.patch Type: text/x-patch Size: 11056 bytes Desc: not available URL: From jcholast at redhat.com Fri Jun 14 14:19:32 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 14 Jun 2013 16:19:32 +0200 Subject: [Freeipa-devel] [PATCHES] 0230-0240 Integration testing framework In-Reply-To: <51B9B824.7030301@redhat.com> References: <51A88DA9.806@redhat.com> <51B5E72E.80000@redhat.com> <51B9B824.7030301@redhat.com> Message-ID: <51BB2674.602@redhat.com> Hi, On 13.6.2013 14:16, Petr Viktorin wrote: > On 06/10/2013 04:48 PM, Petr Viktorin wrote: >> On 05/31/2013 01:46 PM, Petr Viktorin wrote: >>> Apply on top of my patches 0227-0234. >>> >>> These patches add an initial integration testing framework. >>> >>> Patch 0230 adds a plugin for ordered test classes. >>> Nose orders methods within a test suite alphabetically, but we generally >>> want to run them in the order defined. This adds the @ordered decorator >>> that causes Nose to do just that, provided the plugin is loaded and >>> enabled, and that the methods are defined in the same file. The >>> ipa-run-tests wrapper is changed to enable the plugin. >>> In the future we may want to use this for unit tests as well. It might >>> also make sense to separate it from the FreeIPA project altogether. >>> >>> Patch 0231 adds configuration for tests. This reads environment >>> variables like: >>> - MASTER (FQDN of initial server) >>> - REPLICA (space-separated FQDNs of replicas) >>> - CLIENT (space-separated FQDNs of clients), >>> - IPATEST_DIR (directory the tests use on the remote machines) >>> etc., and loads them into an easy-to use Python object. >>> A tool called ipa-test-config is provided that generates a full set of >>> environment variables for shell-based tests from these, either global or >>> specific for a given host. >>> If environment variables don't work for us, alternate configuration >>> methods can be added in the future. I think you forgot to add "%dir %{python_sitelib}/ipatests/test_integration" to the spec file. Is the "self = cls()" line at the beginning of Config.from_env() intentional? + self = cls() + env_normalize(env) + + self = cls(test_dir=env.get('IPATEST_DIR') or '/root/ipatests', >>> >>> Patch 0232 adds an integration test framework. >>> This extends Host object available from the configuration with methods >>> to run commands and copy files on the remote host, and adds a base class >>> for integration tests which can currently install and uninstall IPA in a >>> "star" topology. (In the future, the install/uninstall code should also >>> be made available as a shell command.) >>> A simple test for user replication between two masters is provided. >>> Log files from the remote hosts can be marked for collection, but the >>> actual collection is left to a Nose plugin. >>> The base class uses the @ordered decorator mentioned above. >>> >>> Patch 0233 improves on how commands are run on remote hosts. >>> In the previous patch, the process's stdin and stdout were combined as a >>> quick hack to avoid the problem that if we first read stdout and then >>> stderr, then stderr's buffer can fill up and we'd deadlock (and the >>> other way around). With this patch the streams are read in parallel. >>> In the future this can be extended to calling whole commands in parallel >>> (e.g. uninstalling IPA on all the hosts at once). >>> >>> Patch 0234 adds log collection to the BeakerLib integration plugin. >>> This tars up the marked logs, downloads then, and calls rlFileSubmit on >>> them. >>> >>> --- >> >> Attaching additional patches: >> >> Patch 0237 configures logging in ipa-run-tests to forward messages from >> the IPA logging machinery to a normal Python logger. This way the logs >> are captured >> The logs are also printed to stderr so that there's some activity on the >> terminal after you run the utility. >> >> Patch 0238 makes it possible to use RSA private SSH keys to log in to >> the remote machines. The key is given in $IPA_ROOT_SSH_KEY, and used if >> $IPA_ROOT_SSH_PASSWORD is empty. >> I've added this to the design page. It seems that the code prefers password authentication over public key authentication if both are configured. IMO it would be better if it did the opposite. >> >> Patch 0239 makes test setup change the hostname, /etc/hosts, and >> /etc/resolv.conf to match the configured values. These should be >> equivalent to the fixes in >> https://github.com/freeipa/tests/blob/master/ipa-tests/beaker/ipa-server/shared/ipa-install.sh#L733 >> >> >> In test teardown, the changes are undone. > > I've rebased the patrchset and added small fixes for patches 0232 and 0239. > > New patch 0240 contains a few fixes/improvements to the Host class that > were not trivial to rebase into previous patches. > > The WIP patch adds a sketch of some of the tests for CA-less > (http://www.freeipa.org/page/V3/CA-less_install#Test_Plan). Please > comment if you can see where things can be improved for test authors! Just a word of warning, there are still a few test cases I need to add to the CA-less test plan. Honza -- Jan Cholasta From jcholast at redhat.com Fri Jun 14 14:41:16 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 14 Jun 2013 16:41:16 +0200 Subject: [Freeipa-devel] [PATCHES] 0230-0240 Integration testing framework In-Reply-To: <51BB2674.602@redhat.com> References: <51A88DA9.806@redhat.com> <51B5E72E.80000@redhat.com> <51B9B824.7030301@redhat.com> <51BB2674.602@redhat.com> Message-ID: <51BB2B8C.9020403@redhat.com> On 14.6.2013 16:19, Jan Cholasta wrote: > Hi, > > On 13.6.2013 14:16, Petr Viktorin wrote: >> On 06/10/2013 04:48 PM, Petr Viktorin wrote: >>> On 05/31/2013 01:46 PM, Petr Viktorin wrote: >>>> Apply on top of my patches 0227-0234. >>>> >>>> These patches add an initial integration testing framework. >>>> >>>> Patch 0230 adds a plugin for ordered test classes. >>>> Nose orders methods within a test suite alphabetically, but we >>>> generally >>>> want to run them in the order defined. This adds the @ordered decorator >>>> that causes Nose to do just that, provided the plugin is loaded and >>>> enabled, and that the methods are defined in the same file. The >>>> ipa-run-tests wrapper is changed to enable the plugin. >>>> In the future we may want to use this for unit tests as well. It might >>>> also make sense to separate it from the FreeIPA project altogether. >>>> >>>> Patch 0231 adds configuration for tests. This reads environment >>>> variables like: >>>> - MASTER (FQDN of initial server) >>>> - REPLICA (space-separated FQDNs of replicas) >>>> - CLIENT (space-separated FQDNs of clients), >>>> - IPATEST_DIR (directory the tests use on the remote machines) >>>> etc., and loads them into an easy-to use Python object. >>>> A tool called ipa-test-config is provided that generates a full set of >>>> environment variables for shell-based tests from these, either >>>> global or >>>> specific for a given host. >>>> If environment variables don't work for us, alternate configuration >>>> methods can be added in the future. > > I think you forgot to add "%dir > %{python_sitelib}/ipatests/test_integration" to the spec file. > > Is the "self = cls()" line at the beginning of Config.from_env() > intentional? > > + self = cls() > + env_normalize(env) > + > + self = cls(test_dir=env.get('IPATEST_DIR') or '/root/ipatests', > Also typo in commit message: "Integration tests are be configured ..." >>>> >>>> Patch 0232 adds an integration test framework. >>>> This extends Host object available from the configuration with methods >>>> to run commands and copy files on the remote host, and adds a base >>>> class >>>> for integration tests which can currently install and uninstall IPA >>>> in a >>>> "star" topology. (In the future, the install/uninstall code should also >>>> be made available as a shell command.) >>>> A simple test for user replication between two masters is provided. >>>> Log files from the remote hosts can be marked for collection, but the >>>> actual collection is left to a Nose plugin. >>>> The base class uses the @ordered decorator mentioned above. >>>> >>>> Patch 0233 improves on how commands are run on remote hosts. >>>> In the previous patch, the process's stdin and stdout were combined >>>> as a >>>> quick hack to avoid the problem that if we first read stdout and then >>>> stderr, then stderr's buffer can fill up and we'd deadlock (and the >>>> other way around). With this patch the streams are read in parallel. >>>> In the future this can be extended to calling whole commands in >>>> parallel >>>> (e.g. uninstalling IPA on all the hosts at once). >>>> >>>> Patch 0234 adds log collection to the BeakerLib integration plugin. >>>> This tars up the marked logs, downloads then, and calls rlFileSubmit on >>>> them. Missing space in commit message: "... log files fromthe remote ..." >>>> >>>> --- >>> >>> Attaching additional patches: >>> >>> Patch 0237 configures logging in ipa-run-tests to forward messages from >>> the IPA logging machinery to a normal Python logger. This way the logs >>> are captured >>> The logs are also printed to stderr so that there's some activity on the >>> terminal after you run the utility. >>> >>> Patch 0238 makes it possible to use RSA private SSH keys to log in to >>> the remote machines. The key is given in $IPA_ROOT_SSH_KEY, and used if >>> $IPA_ROOT_SSH_PASSWORD is empty. >>> I've added this to the design page. > > It seems that the code prefers password authentication over public key > authentication if both are configured. IMO it would be better if it did > the opposite. > >>> >>> Patch 0239 makes test setup change the hostname, /etc/hosts, and >>> /etc/resolv.conf to match the configured values. These should be >>> equivalent to the fixes in >>> https://github.com/freeipa/tests/blob/master/ipa-tests/beaker/ipa-server/shared/ipa-install.sh#L733 >>> >>> >>> >>> In test teardown, the changes are undone. >> >> I've rebased the patrchset and added small fixes for patches 0232 and >> 0239. >> >> New patch 0240 contains a few fixes/improvements to the Host class that >> were not trivial to rebase into previous patches. >> >> The WIP patch adds a sketch of some of the tests for CA-less >> (http://www.freeipa.org/page/V3/CA-less_install#Test_Plan). Please >> comment if you can see where things can be improved for test authors! > > Just a word of warning, there are still a few test cases I need to add > to the CA-less test plan. > > Honza > -- Jan Cholasta From pviktori at redhat.com Fri Jun 14 15:44:35 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 14 Jun 2013 17:44:35 +0200 Subject: [Freeipa-devel] [PATCHES] 0230-0240 Integration testing framework In-Reply-To: <51BB2B8C.9020403@redhat.com> References: <51A88DA9.806@redhat.com> <51B5E72E.80000@redhat.com> <51B9B824.7030301@redhat.com> <51BB2674.602@redhat.com> <51BB2B8C.9020403@redhat.com> Message-ID: <51BB3A63.3090002@redhat.com> On 06/14/2013 04:41 PM, Jan Cholasta wrote: > On 14.6.2013 16:19, Jan Cholasta wrote: >> Hi, >> >> On 13.6.2013 14:16, Petr Viktorin wrote: >>> On 06/10/2013 04:48 PM, Petr Viktorin wrote: >>>> On 05/31/2013 01:46 PM, Petr Viktorin wrote: >>>>> Apply on top of my patches 0227-0234. >>>>> >>>>> These patches add an initial integration testing framework. >>>>> >>>>> Patch 0230 adds a plugin for ordered test classes. >>>>> Nose orders methods within a test suite alphabetically, but we >>>>> generally >>>>> want to run them in the order defined. This adds the @ordered >>>>> decorator >>>>> that causes Nose to do just that, provided the plugin is loaded and >>>>> enabled, and that the methods are defined in the same file. The >>>>> ipa-run-tests wrapper is changed to enable the plugin. >>>>> In the future we may want to use this for unit tests as well. It might >>>>> also make sense to separate it from the FreeIPA project altogether. >>>>> >>>>> Patch 0231 adds configuration for tests. This reads environment >>>>> variables like: >>>>> - MASTER (FQDN of initial server) >>>>> - REPLICA (space-separated FQDNs of replicas) >>>>> - CLIENT (space-separated FQDNs of clients), >>>>> - IPATEST_DIR (directory the tests use on the remote machines) >>>>> etc., and loads them into an easy-to use Python object. >>>>> A tool called ipa-test-config is provided that generates a full set of >>>>> environment variables for shell-based tests from these, either >>>>> global or >>>>> specific for a given host. >>>>> If environment variables don't work for us, alternate configuration >>>>> methods can be added in the future. >> >> I think you forgot to add "%dir >> %{python_sitelib}/ipatests/test_integration" to the spec file. >> >> Is the "self = cls()" line at the beginning of Config.from_env() >> intentional? >> >> + self = cls() >> + env_normalize(env) >> + >> + self = cls(test_dir=env.get('IPATEST_DIR') or '/root/ipatests', No. I removed it, thanks for thee catch. > Also typo in commit message: "Integration tests are be configured ..." Thanks, fixed. >>>>> >>>>> Patch 0232 adds an integration test framework. >>>>> This extends Host object available from the configuration with methods >>>>> to run commands and copy files on the remote host, and adds a base >>>>> class >>>>> for integration tests which can currently install and uninstall IPA >>>>> in a >>>>> "star" topology. (In the future, the install/uninstall code should >>>>> also >>>>> be made available as a shell command.) >>>>> A simple test for user replication between two masters is provided. >>>>> Log files from the remote hosts can be marked for collection, but the >>>>> actual collection is left to a Nose plugin. >>>>> The base class uses the @ordered decorator mentioned above. >>>>> >>>>> Patch 0233 improves on how commands are run on remote hosts. >>>>> In the previous patch, the process's stdin and stdout were combined >>>>> as a >>>>> quick hack to avoid the problem that if we first read stdout and then >>>>> stderr, then stderr's buffer can fill up and we'd deadlock (and the >>>>> other way around). With this patch the streams are read in parallel. >>>>> In the future this can be extended to calling whole commands in >>>>> parallel >>>>> (e.g. uninstalling IPA on all the hosts at once). >>>>> >>>>> Patch 0234 adds log collection to the BeakerLib integration plugin. >>>>> This tars up the marked logs, downloads then, and calls >>>>> rlFileSubmit on >>>>> them. > > Missing space in commit message: "... log files fromthe remote ..." Thanks, fixed. >>>>> >>>>> --- >>>> >>>> Attaching additional patches: >>>> >>>> Patch 0237 configures logging in ipa-run-tests to forward messages from >>>> the IPA logging machinery to a normal Python logger. This way the logs >>>> are captured >>>> The logs are also printed to stderr so that there's some activity on >>>> the >>>> terminal after you run the utility. >>>> >>>> Patch 0238 makes it possible to use RSA private SSH keys to log in to >>>> the remote machines. The key is given in $IPA_ROOT_SSH_KEY, and used if >>>> $IPA_ROOT_SSH_PASSWORD is empty. >>>> I've added this to the design page. >> >> It seems that the code prefers password authentication over public key >> authentication if both are configured. IMO it would be better if it did >> the opposite. Good point, fixed, design page updated. >>>> Patch 0239 makes test setup change the hostname, /etc/hosts, and >>>> /etc/resolv.conf to match the configured values. These should be >>>> equivalent to the fixes in >>>> https://github.com/freeipa/tests/blob/master/ipa-tests/beaker/ipa-server/shared/ipa-install.sh#L733 >>>> >>>> >>>> >>>> >>>> In test teardown, the changes are undone. >>> >>> I've rebased the patrchset and added small fixes for patches 0232 and >>> 0239. >>> >>> New patch 0240 contains a few fixes/improvements to the Host class that >>> were not trivial to rebase into previous patches. >>> >>> The WIP patch adds a sketch of some of the tests for CA-less >>> (http://www.freeipa.org/page/V3/CA-less_install#Test_Plan). Please >>> comment if you can see where things can be improved for test authors! >> >> Just a word of warning, there are still a few test cases I need to add >> to the CA-less test plan. Sure. I did this mainly to see how things look from the test author's point of view. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0227.3-Make-an-ipa-tests-package.patch Type: text/x-patch Size: 71201 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0228.3-Add-ipa-run-tests-command.patch Type: text/x-patch Size: 2517 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0229.3-Add-Nose-plugin-for-BeakerLib-integration.patch Type: text/x-patch Size: 11056 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0230.3-Add-a-plugin-for-test-ordering.patch Type: text/x-patch Size: 4190 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0231.3-Add-a-framework-for-integration-test-configuration.patch Type: text/x-patch Size: 21265 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0232.3-Add-a-framework-for-integration-testing.patch Type: text/x-patch Size: 22712 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0233.3-Introduce-a-class-for-remote-commands.patch Type: text/x-patch Size: 10810 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0234.3-Collect-logs-from-tests.patch Type: text/x-patch Size: 7021 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0235.3-Do-not-hardcode-path-to-ipa-getkeytab-in-tests.patch Type: text/x-patch Size: 3287 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0237.3-Show-logs-in-failed-tests.patch Type: text/x-patch Size: 3124 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0238.3-tests-Allow-public-keys-for-authentication-to-the-re.patch Type: text/x-patch Size: 4538 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0239.3-tests-Configure-unconfigure-remote-hosts.patch Type: text/x-patch Size: 9826 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0240.3-Host-class-improvements.patch Type: text/x-patch Size: 6270 bytes Desc: not available URL: From rcritten at redhat.com Fri Jun 14 19:43:26 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 14 Jun 2013 15:43:26 -0400 Subject: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used In-Reply-To: <51B92FCE.6040406@redhat.com> References: <038.85636923ffc7d7f47d64dd7308c2c527@fedorahosted.org> <053.e8f59eb95b19dcdbcf715e1166fb104a@fedorahosted.org> <51B1CC41.30401@redhat.com> <51B1D16C.2010201@redhat.com> <51B1D820.3090304@redhat.com> <51B1DB60.2010705@redhat.com> <51B1DEE4.6090300@redhat.com> <20130612080620.GA12641@redhat.com> <51B92FCE.6040406@redhat.com> Message-ID: <51BB725E.5050108@redhat.com> Rob Crittenden wrote: > Jan Pazdziora wrote: >> On Fri, Jun 07, 2013 at 09:23:48AM -0400, Dmitri Pal wrote: >>>> >>>> The problem is that if you pass IPA certificates issued by CA2 and >>>> point it to CA1 at the same time, it does not work (despite having the >>>> complete trust chain). >>> >>> But why would you do so? What would be the reason and business case? Why >>> not to point to CA2? >> >> Could the business case be an IPA server in DMZ which does not have >> access to CA2 but it can get to (public) CA1? >> > > A client does need to be able to contact a CA in order to trust it. Of course I meant that a client does NOT need to contact a CA. It just needs the CA cert. rob From jcholast at redhat.com Mon Jun 17 12:39:50 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 17 Jun 2013 14:39:50 +0200 Subject: [Freeipa-devel] [PATCHES] 0227-0229 freeipa-tests package & Beaker integration plugin In-Reply-To: <51BB2257.40504@redhat.com> References: <51A4D370.6030307@redhat.com> <51BB18A4.2070607@redhat.com> <51BB2257.40504@redhat.com> Message-ID: <51BF0396.2030806@redhat.com> On 14.6.2013 16:01, Petr Viktorin wrote: > On 06/14/2013 03:20 PM, Jan Cholasta wrote: >> Hi, >> >> On 28.5.2013 17:55, Petr Viktorin wrote: >>> Hello, >>> >>> Patch 0227 creates the freeipa-tests package. >>> As a system package, it needs a more unique name than "tests", so I >>> renamed it to "ipatests". I also changed imports and references to it. >>> Sorry to everyone developing tests right now ?? there will be conflicts, >>> but hopefully they'll be straightforward. >>> Note that the test suite does not yet pass when run outside the Git >>> tree. Work on that is ongoing but not a priority right now (it's more >>> important to get some integration tests running). Help would be >>> appreciated :) >> >> Typo in commit message: "Tename the 'tests' directory ..." > > Thanks for the catch! > >> The patch needs rebasing. > > Attaching rebased versions. > >>> Patch 0228 adds a wrapper based on make-test which runs the >>> system-installed test suite. freeipa-tests installs it as >>> /usr/bin/ipa-run-tests. >>> As I said above the tests currently fail when run this way. >>> >>> Patch 0229 adds a Nose plugin for integration with BeakerLib[1]. When >>> the plugin is loaded (ipa-run-tests does that) and enabled (using the >>> --with-beakerlib option), it hooks into Nose and runs rlPhase*, rlPass, >>> rlFail and rlLog* Bash functions at appropriate events. >>> >> >> I still need to actually run the code, I will do that with your patches >> 230-240 included. > > If I may suggest, please test this set by itself. The tests?ipatests > rename blocks or conflicts with other patches so it would be good to get > it in soon, without waiting on the integration testing review. > > When I run "make test" I get the following error: Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/loader.py", line 413, in loadTestsFromName addr.filename, addr.module) File "/usr/lib/python2.7/site-packages/nose/importer.py", line 47, in importFromPath return self.importFromDir(dir_path, fqname) File "/usr/lib/python2.7/site-packages/nose/importer.py", line 94, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File "/home/jcholast/freeipa/ipatests/test_xmlrpc/test_host_plugin.py", line 59, in fd = open('tests/test_xmlrpc/service.crt', 'r') IOError: [Errno 2] No such file or directory: 'tests/test_xmlrpc/service.crt' I believe the certificate path should begin with "ipatests" instead of "tests". When I run "ipa-run-tests", I get an additional similar error in test_service_plugin.py: Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/loader.py", line 413, in loadTestsFromName addr.filename, addr.module) File "/usr/lib/python2.7/site-packages/nose/importer.py", line 47, in importFromPath return self.importFromDir(dir_path, fqname) File "/usr/lib/python2.7/site-packages/nose/importer.py", line 94, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/test_service_plugin.py", line 42, in fd = open('ipatests/test_xmlrpc/service.crt', 'r') IOError: [Errno 2] No such file or directory: 'ipatests/test_xmlrpc/service.crt' Also with "ipa-run-tests", many of the cmdline tests are failing with: Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 381, in setUp try_run(self.inst, ('setup', 'setUp')) File "/usr/lib/python2.7/site-packages/nose/util.py", line 469, in try_run return func() File "/usr/lib/python2.7/site-packages/ipatests/test_cmdline/cmdline.py", line 58, in setUp 'Command %r not available' % self.command AssertionError: Command 'ipa-client/ipa-getkeytab' not available Honza -- Jan Cholasta From akrivoka at redhat.com Mon Jun 17 13:11:18 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 17 Jun 2013 15:11:18 +0200 Subject: [Freeipa-devel] [PATCH] 0037 Do not display traceback to user Message-ID: <51BF0AF6.1050309@redhat.com> Hello, Logging tracebacks at the INFO level caused them to be displayed to user on the command line. Change the log level to DEBUG, so that tracebacks are not visible to user. https://fedorahosted.org/freeipa/ticket/3704 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0037-Do-not-display-traceback-to-user.patch Type: text/x-patch Size: 1903 bytes Desc: not available URL: From jcholast at redhat.com Mon Jun 17 13:09:51 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 17 Jun 2013 15:09:51 +0200 Subject: [Freeipa-devel] [PATCHES] 0227-0229 freeipa-tests package & Beaker integration plugin In-Reply-To: <51BF0396.2030806@redhat.com> References: <51A4D370.6030307@redhat.com> <51BB18A4.2070607@redhat.com> <51BB2257.40504@redhat.com> <51BF0396.2030806@redhat.com> Message-ID: <51BF0A9F.2030600@redhat.com> On 17.6.2013 14:39, Jan Cholasta wrote: > On 14.6.2013 16:01, Petr Viktorin wrote: >> On 06/14/2013 03:20 PM, Jan Cholasta wrote: >>> Hi, >>> >>> On 28.5.2013 17:55, Petr Viktorin wrote: >>>> Hello, >>>> >>>> Patch 0227 creates the freeipa-tests package. >>>> As a system package, it needs a more unique name than "tests", so I >>>> renamed it to "ipatests". I also changed imports and references to it. >>>> Sorry to everyone developing tests right now ?? there will be >>>> conflicts, >>>> but hopefully they'll be straightforward. >>>> Note that the test suite does not yet pass when run outside the Git >>>> tree. Work on that is ongoing but not a priority right now (it's more >>>> important to get some integration tests running). Help would be >>>> appreciated :) >>> >>> Typo in commit message: "Tename the 'tests' directory ..." >> >> Thanks for the catch! >> >>> The patch needs rebasing. >> >> Attaching rebased versions. >> >>>> Patch 0228 adds a wrapper based on make-test which runs the >>>> system-installed test suite. freeipa-tests installs it as >>>> /usr/bin/ipa-run-tests. >>>> As I said above the tests currently fail when run this way. >>>> >>>> Patch 0229 adds a Nose plugin for integration with BeakerLib[1]. When >>>> the plugin is loaded (ipa-run-tests does that) and enabled (using the >>>> --with-beakerlib option), it hooks into Nose and runs rlPhase*, rlPass, >>>> rlFail and rlLog* Bash functions at appropriate events. >>>> >>> >>> I still need to actually run the code, I will do that with your patches >>> 230-240 included. >> >> If I may suggest, please test this set by itself. The tests?ipatests >> rename blocks or conflicts with other patches so it would be good to get >> it in soon, without waiting on the integration testing review. >> >> > > When I run "make test" I get the following error: > > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/nose/loader.py", line 413, in > loadTestsFromName > addr.filename, addr.module) > File "/usr/lib/python2.7/site-packages/nose/importer.py", line 47, in > importFromPath > return self.importFromDir(dir_path, fqname) > File "/usr/lib/python2.7/site-packages/nose/importer.py", line 94, in > importFromDir > mod = load_module(part_fqname, fh, filename, desc) > File > "/home/jcholast/freeipa/ipatests/test_xmlrpc/test_host_plugin.py", line > 59, in > fd = open('tests/test_xmlrpc/service.crt', 'r') > IOError: [Errno 2] No such file or directory: > 'tests/test_xmlrpc/service.crt' > > I believe the certificate path should begin with "ipatests" instead of > "tests". > > > When I run "ipa-run-tests", I get an additional similar error in > test_service_plugin.py: > > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/nose/loader.py", line 413, in > loadTestsFromName > addr.filename, addr.module) > File "/usr/lib/python2.7/site-packages/nose/importer.py", line 47, in > importFromPath > return self.importFromDir(dir_path, fqname) > File "/usr/lib/python2.7/site-packages/nose/importer.py", line 94, in > importFromDir > mod = load_module(part_fqname, fh, filename, desc) > File > "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/test_service_plugin.py", > line 42, in > fd = open('ipatests/test_xmlrpc/service.crt', 'r') > IOError: [Errno 2] No such file or directory: > 'ipatests/test_xmlrpc/service.crt' > > > Also with "ipa-run-tests", many of the cmdline tests are failing with: > > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/nose/case.py", line 381, in setUp > try_run(self.inst, ('setup', 'setUp')) > File "/usr/lib/python2.7/site-packages/nose/util.py", line 469, in > try_run > return func() > File > "/usr/lib/python2.7/site-packages/ipatests/test_cmdline/cmdline.py", > line 58, in setUp > 'Command %r not available' % self.command > AssertionError: Command 'ipa-client/ipa-getkeytab' not available > > > Honza > ipa-run-tests --with-beakerlib is horribly slow for me, is that expected? Honza -- Jan Cholasta From akrivoka at redhat.com Mon Jun 17 12:34:15 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 17 Jun 2013 14:34:15 +0200 Subject: [Freeipa-devel] [PATCH 0067] Add --use-posix option that forces trusted range type In-Reply-To: <51B05207.4010100@redhat.com> References: <51B05207.4010100@redhat.com> Message-ID: <51BF0247.4040604@redhat.com> On 06/06/2013 11:10 AM, Tomas Babej wrote: > Hi, > > Adds --use-posix option to ipa trust-add command. It takes two > allowed values: > 'yes' : the 'ipa-ad-trust-posix' range type is enforced > 'no' : the 'ipa-ad-trust' range type is enforced > > When --use-posix option is not specified, the range type should be > determined by ID range discovery. > > https://fedorahosted.org/freeipa/ticket/3650 > > Tomas > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel The patch works nicely, but I have a few comments: 1) You added a new option to the API, but you forgot to bump the IPA_API_VERSION_MINOR in the VERSION file. 2) Typo in commit message: "shold" instead of "should". 3) This construct: + if range_type is not None: + if range_type != old_range_type: can be replaced with a more readable variant which also avoids nested ifs: + if range_type and range_type != old_range_type: 4) Some unit tests to cover the behavior of the newly added option would be nice. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Mon Jun 17 14:44:45 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 17 Jun 2013 16:44:45 +0200 Subject: [Freeipa-devel] [PATCHES] 0227-0229 freeipa-tests package & Beaker integration plugin In-Reply-To: <51BF0A9F.2030600@redhat.com> References: <51A4D370.6030307@redhat.com> <51BB18A4.2070607@redhat.com> <51BB2257.40504@redhat.com> <51BF0396.2030806@redhat.com> <51BF0A9F.2030600@redhat.com> Message-ID: <51BF20DD.9070803@redhat.com> On 17.6.2013 15:09, Jan Cholasta wrote: > On 17.6.2013 14:39, Jan Cholasta wrote: >> On 14.6.2013 16:01, Petr Viktorin wrote: >>> On 06/14/2013 03:20 PM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 28.5.2013 17:55, Petr Viktorin wrote: >>>>> Hello, >>>>> >>>>> Patch 0227 creates the freeipa-tests package. >>>>> As a system package, it needs a more unique name than "tests", so I >>>>> renamed it to "ipatests". I also changed imports and references to it. >>>>> Sorry to everyone developing tests right now ?? there will be >>>>> conflicts, >>>>> but hopefully they'll be straightforward. >>>>> Note that the test suite does not yet pass when run outside the Git >>>>> tree. Work on that is ongoing but not a priority right now (it's more >>>>> important to get some integration tests running). Help would be >>>>> appreciated :) >>>> >>>> Typo in commit message: "Tename the 'tests' directory ..." >>> >>> Thanks for the catch! >>> >>>> The patch needs rebasing. >>> >>> Attaching rebased versions. >>> >>>>> Patch 0228 adds a wrapper based on make-test which runs the >>>>> system-installed test suite. freeipa-tests installs it as >>>>> /usr/bin/ipa-run-tests. >>>>> As I said above the tests currently fail when run this way. >>>>> >>>>> Patch 0229 adds a Nose plugin for integration with BeakerLib[1]. When >>>>> the plugin is loaded (ipa-run-tests does that) and enabled (using the >>>>> --with-beakerlib option), it hooks into Nose and runs rlPhase*, >>>>> rlPass, >>>>> rlFail and rlLog* Bash functions at appropriate events. >>>>> >>>> >>>> I still need to actually run the code, I will do that with your patches >>>> 230-240 included. >>> >>> If I may suggest, please test this set by itself. The tests?ipatests >>> rename blocks or conflicts with other patches so it would be good to get >>> it in soon, without waiting on the integration testing review. >>> >>> >> >> When I run "make test" I get the following error: >> >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/nose/loader.py", line 413, in >> loadTestsFromName >> addr.filename, addr.module) >> File "/usr/lib/python2.7/site-packages/nose/importer.py", line 47, in >> importFromPath >> return self.importFromDir(dir_path, fqname) >> File "/usr/lib/python2.7/site-packages/nose/importer.py", line 94, in >> importFromDir >> mod = load_module(part_fqname, fh, filename, desc) >> File >> "/home/jcholast/freeipa/ipatests/test_xmlrpc/test_host_plugin.py", line >> 59, in >> fd = open('tests/test_xmlrpc/service.crt', 'r') >> IOError: [Errno 2] No such file or directory: >> 'tests/test_xmlrpc/service.crt' >> >> I believe the certificate path should begin with "ipatests" instead of >> "tests". >> >> >> When I run "ipa-run-tests", I get an additional similar error in >> test_service_plugin.py: >> >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/nose/loader.py", line 413, in >> loadTestsFromName >> addr.filename, addr.module) >> File "/usr/lib/python2.7/site-packages/nose/importer.py", line 47, in >> importFromPath >> return self.importFromDir(dir_path, fqname) >> File "/usr/lib/python2.7/site-packages/nose/importer.py", line 94, in >> importFromDir >> mod = load_module(part_fqname, fh, filename, desc) >> File >> "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/test_service_plugin.py", >> >> line 42, in >> fd = open('ipatests/test_xmlrpc/service.crt', 'r') >> IOError: [Errno 2] No such file or directory: >> 'ipatests/test_xmlrpc/service.crt' >> >> >> Also with "ipa-run-tests", many of the cmdline tests are failing with: >> >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/nose/case.py", line 381, in >> setUp >> try_run(self.inst, ('setup', 'setUp')) >> File "/usr/lib/python2.7/site-packages/nose/util.py", line 469, in >> try_run >> return func() >> File >> "/usr/lib/python2.7/site-packages/ipatests/test_cmdline/cmdline.py", >> line 58, in setUp >> 'Command %r not available' % self.command >> AssertionError: Command 'ipa-client/ipa-getkeytab' not available >> >> >> Honza >> > > ipa-run-tests --with-beakerlib is horribly slow for me, is that expected? > > Honza > Also I get the following failures with --with-beaker (in addition to the previously reported ones): :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: Nose test: test_help.test_ipa_help :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ ERROR ] :: [ipa.ipalib.cli.cli] non-public: AttributeError: 'API' object has no attribute 'parser' :: [ ERROR ] :: Traceback (most recent call last): :: [ ERROR ] :: File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 129, in execute :: [ ERROR ] :: result = self.Command[_name](*args, **options) :: [ ERROR ] :: File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 435, in __call__ :: [ ERROR ] :: ret = self.run(*args, **options) :: [ ERROR ] :: File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 765, in run :: [ ERROR ] :: self.api.parser.print_help(outfile) :: [ ERROR ] :: AttributeError: 'API' object has no attribute 'parser' :: [ ERROR ] :: Traceback (most recent call last): :: [ ERROR ] :: File "/usr/lib64/python2.7/unittest/case.py", line 369, in run :: [ ERROR ] :: testMethod() :: [ ERROR ] :: File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest :: [ ERROR ] :: self.test(*self.arg) :: [ ERROR ] :: File "/usr/lib/python2.7/site-packages/ipatests/test_cmdline/test_help.py", line 63, in test_ipa_help :: [ ERROR ] :: return_value = api.Backend.cli.run(['help']) :: [ ERROR ] :: File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 1067, in run :: [ ERROR ] :: result = self.execute(name, **kw) :: [ ERROR ] :: File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 146, in execute :: [ ERROR ] :: raise error #pylint: disable=E0702 :: [ ERROR ] :: InternalError: an internal error has occurred :: [ FAIL ] :: Test failed: unhandled exception :: [ LOG ] :: Duration: 1s :: [ LOG ] :: Assertions: 0 good, 1 bad :: [ FAIL ] :: RESULT: Nose test: test_help.test_ipa_help :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: Nose test: test_help.test_ipa_without_arguments :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ ERROR ] :: Traceback (most recent call last): :: [ ERROR ] :: File "/usr/lib64/python2.7/unittest/case.py", line 369, in run :: [ ERROR ] :: testMethod() :: [ ERROR ] :: File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest :: [ ERROR ] :: self.test(*self.arg) :: [ ERROR ] :: File "/usr/lib/python2.7/site-packages/ipatests/test_cmdline/test_help.py", line 71, in test_ipa_without_arguments :: [ ERROR ] :: api.Backend.cli.run([]) :: [ ERROR ] :: File "/usr/lib/python2.7/site-packages/ipatests/test_cmdline/test_help.py", line 55, in __exit__ :: [ ERROR ] :: assert isinstance(exc_value, self.exception), exc_value :: [ ERROR ] :: AssertionError: 'API' object has no attribute 'parser' :: [ FAIL ] :: Test failed :: [ LOG ] :: Duration: 0s :: [ LOG ] :: Assertions: 0 good, 1 bad :: [ FAIL ] :: RESULT: Nose test: test_help.test_ipa_without_arguments Honza -- Jan Cholasta From pviktori at redhat.com Mon Jun 17 15:08:56 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 17 Jun 2013 17:08:56 +0200 Subject: [Freeipa-devel] [PATCHES] 0227-0229 freeipa-tests package & Beaker integration plugin In-Reply-To: <51BF20DD.9070803@redhat.com> References: <51A4D370.6030307@redhat.com> <51BB18A4.2070607@redhat.com> <51BB2257.40504@redhat.com> <51BF0396.2030806@redhat.com> <51BF0A9F.2030600@redhat.com> <51BF20DD.9070803@redhat.com> Message-ID: <51BF2688.6080307@redhat.com> On 06/17/2013 04:44 PM, Jan Cholasta wrote: > On 17.6.2013 15:09, Jan Cholasta wrote: >> On 17.6.2013 14:39, Jan Cholasta wrote: >>> On 14.6.2013 16:01, Petr Viktorin wrote: >>>> On 06/14/2013 03:20 PM, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> On 28.5.2013 17:55, Petr Viktorin wrote: >>>>>> Hello, >>>>>> >>>>>> Patch 0227 creates the freeipa-tests package. >>>>>> As a system package, it needs a more unique name than "tests", so I >>>>>> renamed it to "ipatests". I also changed imports and references to >>>>>> it. >>>>>> Sorry to everyone developing tests right now ?? there will be >>>>>> conflicts, >>>>>> but hopefully they'll be straightforward. >>>>>> Note that the test suite does not yet pass when run outside the Git >>>>>> tree. Work on that is ongoing but not a priority right now (it's more >>>>>> important to get some integration tests running). Help would be >>>>>> appreciated :) >>>>> >>>>> Typo in commit message: "Tename the 'tests' directory ..." >>>> >>>> Thanks for the catch! >>>> >>>>> The patch needs rebasing. >>>> >>>> Attaching rebased versions. >>>> >>>>>> Patch 0228 adds a wrapper based on make-test which runs the >>>>>> system-installed test suite. freeipa-tests installs it as >>>>>> /usr/bin/ipa-run-tests. >>>>>> As I said above the tests currently fail when run this way. >>>>>> >>>>>> Patch 0229 adds a Nose plugin for integration with BeakerLib[1]. When >>>>>> the plugin is loaded (ipa-run-tests does that) and enabled (using the >>>>>> --with-beakerlib option), it hooks into Nose and runs rlPhase*, >>>>>> rlPass, >>>>>> rlFail and rlLog* Bash functions at appropriate events. >>>>>> >>>>> >>>>> I still need to actually run the code, I will do that with your >>>>> patches >>>>> 230-240 included. >>>> >>>> If I may suggest, please test this set by itself. The tests?ipatests >>>> rename blocks or conflicts with other patches so it would be good to >>>> get >>>> it in soon, without waiting on the integration testing review. >>>> >>>> >>> >>> When I run "make test" I get the following error: >>> >>> Traceback (most recent call last): >>> File "/usr/lib/python2.7/site-packages/nose/loader.py", line 413, in >>> loadTestsFromName >>> addr.filename, addr.module) >>> File "/usr/lib/python2.7/site-packages/nose/importer.py", line 47, in >>> importFromPath >>> return self.importFromDir(dir_path, fqname) >>> File "/usr/lib/python2.7/site-packages/nose/importer.py", line 94, in >>> importFromDir >>> mod = load_module(part_fqname, fh, filename, desc) >>> File >>> "/home/jcholast/freeipa/ipatests/test_xmlrpc/test_host_plugin.py", line >>> 59, in >>> fd = open('tests/test_xmlrpc/service.crt', 'r') >>> IOError: [Errno 2] No such file or directory: >>> 'tests/test_xmlrpc/service.crt' >>> >>> I believe the certificate path should begin with "ipatests" instead of >>> "tests". Fixed, thanks. >>> When I run "ipa-run-tests", I get an additional similar error in >>> test_service_plugin.py: >>> >>> Traceback (most recent call last): >>> File "/usr/lib/python2.7/site-packages/nose/loader.py", line 413, in >>> loadTestsFromName >>> addr.filename, addr.module) >>> File "/usr/lib/python2.7/site-packages/nose/importer.py", line 47, in >>> importFromPath >>> return self.importFromDir(dir_path, fqname) >>> File "/usr/lib/python2.7/site-packages/nose/importer.py", line 94, in >>> importFromDir >>> mod = load_module(part_fqname, fh, filename, desc) >>> File >>> "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/test_service_plugin.py", >>> >>> >>> line 42, in >>> fd = open('ipatests/test_xmlrpc/service.crt', 'r') >>> IOError: [Errno 2] No such file or directory: >>> 'ipatests/test_xmlrpc/service.crt' >>> >>> >>> Also with "ipa-run-tests", many of the cmdline tests are failing with: >>> >>> Traceback (most recent call last): >>> File "/usr/lib/python2.7/site-packages/nose/case.py", line 381, in >>> setUp >>> try_run(self.inst, ('setup', 'setUp')) >>> File "/usr/lib/python2.7/site-packages/nose/util.py", line 469, in >>> try_run >>> return func() >>> File >>> "/usr/lib/python2.7/site-packages/ipatests/test_cmdline/cmdline.py", >>> line 58, in setUp >>> 'Command %r not available' % self.command >>> AssertionError: Command 'ipa-client/ipa-getkeytab' not available Yes, some tests don't work out-of-tree yet. This will be addressed in future patches. The important thing to check is if the beakerlib plugin handles failures well. >> ipa-run-tests --with-beakerlib is horribly slow for me, is that expected? Yes. For every logged line, BeakerLib's default logging backend starts up Python, parses a XML file, appends the line, and writes the XML out again. So especially with longer runs it's really slow. > Also I get the following failures with --with-beaker (in addition to the > previously reported ones): > > :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > > :: [ LOG ] :: Nose test: test_help.test_ipa_help > :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > > > :: [ ERROR ] :: [ipa.ipalib.cli.cli] non-public: AttributeError: > 'API' object has no attribute 'parser' > :: [ ERROR ] :: Traceback (most recent call last): > :: [ ERROR ] :: File > "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 129, in execute > :: [ ERROR ] :: result = self.Command[_name](*args, **options) > :: [ ERROR ] :: File > "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 435, in > __call__ > :: [ ERROR ] :: ret = self.run(*args, **options) > :: [ ERROR ] :: File > "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 765, in run > :: [ ERROR ] :: self.api.parser.print_help(outfile) > :: [ ERROR ] :: AttributeError: 'API' object has no attribute 'parser' > :: [ ERROR ] :: Traceback (most recent call last): > :: [ ERROR ] :: File "/usr/lib64/python2.7/unittest/case.py", line > 369, in run > :: [ ERROR ] :: testMethod() > :: [ ERROR ] :: File > "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest > :: [ ERROR ] :: self.test(*self.arg) > :: [ ERROR ] :: File > "/usr/lib/python2.7/site-packages/ipatests/test_cmdline/test_help.py", > line 63, in test_ipa_help > :: [ ERROR ] :: return_value = api.Backend.cli.run(['help']) > :: [ ERROR ] :: File > "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 1067, in run > :: [ ERROR ] :: result = self.execute(name, **kw) > :: [ ERROR ] :: File > "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 146, in execute > :: [ ERROR ] :: raise error #pylint: disable=E0702 > :: [ ERROR ] :: InternalError: an internal error has occurred > :: [ FAIL ] :: Test failed: unhandled exception > :: [ LOG ] :: Duration: 1s > :: [ LOG ] :: Assertions: 0 good, 1 bad > :: [ FAIL ] :: RESULT: Nose test: test_help.test_ipa_help > > :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > > :: [ LOG ] :: Nose test: test_help.test_ipa_without_arguments > :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > > > :: [ ERROR ] :: Traceback (most recent call last): > :: [ ERROR ] :: File "/usr/lib64/python2.7/unittest/case.py", line > 369, in run > :: [ ERROR ] :: testMethod() > :: [ ERROR ] :: File > "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest > :: [ ERROR ] :: self.test(*self.arg) > :: [ ERROR ] :: File > "/usr/lib/python2.7/site-packages/ipatests/test_cmdline/test_help.py", > line 71, in test_ipa_without_arguments > :: [ ERROR ] :: api.Backend.cli.run([]) > :: [ ERROR ] :: File > "/usr/lib/python2.7/site-packages/ipatests/test_cmdline/test_help.py", > line 55, in __exit__ > :: [ ERROR ] :: assert isinstance(exc_value, self.exception), > exc_value > :: [ ERROR ] :: AssertionError: 'API' object has no attribute 'parser' > :: [ FAIL ] :: Test failed > :: [ LOG ] :: Duration: 0s > :: [ LOG ] :: Assertions: 0 good, 1 bad > :: [ FAIL ] :: RESULT: Nose test: test_help.test_ipa_without_arguments We can fix individual out-of-tree failures later, the priority now is that in-tree tests are not broken, and that the beakerlib plugin works. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0227.3-Make-an-ipa-tests-package.patch Type: text/x-patch Size: 71543 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0228.3-Add-ipa-run-tests-command.patch Type: text/x-patch Size: 2517 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0229.3-Add-Nose-plugin-for-BeakerLib-integration.patch Type: text/x-patch Size: 11056 bytes Desc: not available URL: From mkosek at redhat.com Mon Jun 17 15:38:46 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 17 Jun 2013 17:38:46 +0200 Subject: [Freeipa-devel] [PATCH] 410-411 Drop selinux subpackage In-Reply-To: <51BAFD8F.5050800@redhat.com> References: <51B9C94A.4020507@redhat.com> <51BAFD8F.5050800@redhat.com> Message-ID: <51BF2D86.2010700@redhat.com> On 06/14/2013 01:25 PM, Petr Viktorin wrote: > On 06/13/2013 03:29 PM, Martin Kosek wrote: >> All SELinux policy needed by FreeIPA server is now part of the global >> system SELinux policy which makes the subpackage redundant and slowing >> down the installation. This patch drops it. >> >> Second patch removes /var/cache/ipa/sessions which was redundant. >> >> Martin > > Works for me, cautious ACK The change got also agreed by Rob and Alexander. Let's do it then. Pushed to master. Martin From jcholast at redhat.com Mon Jun 17 16:59:22 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 17 Jun 2013 18:59:22 +0200 Subject: [Freeipa-devel] [PATCHES] 0227-0229 freeipa-tests package & Beaker integration plugin In-Reply-To: <51BF2688.6080307@redhat.com> References: <51A4D370.6030307@redhat.com> <51BB18A4.2070607@redhat.com> <51BB2257.40504@redhat.com> <51BF0396.2030806@redhat.com> <51BF0A9F.2030600@redhat.com> <51BF20DD.9070803@redhat.com> <51BF2688.6080307@redhat.com> Message-ID: <51BF406A.9060808@redhat.com> On 17.6.2013 17:08, Petr Viktorin wrote: > We can fix individual out-of-tree failures later, the priority now is > that in-tree tests are not broken, and that the beakerlib plugin works. > Well, works just fine for me, so ACK. Honza -- Jan Cholasta From mkosek at redhat.com Mon Jun 17 17:27:33 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 17 Jun 2013 19:27:33 +0200 Subject: [Freeipa-devel] [PATCHES] 0227-0229 freeipa-tests package & Beaker integration plugin In-Reply-To: <51BF406A.9060808@redhat.com> References: <51A4D370.6030307@redhat.com> <51BB18A4.2070607@redhat.com> <51BB2257.40504@redhat.com> <51BF0396.2030806@redhat.com> <51BF0A9F.2030600@redhat.com> <51BF20DD.9070803@redhat.com> <51BF2688.6080307@redhat.com> <51BF406A.9060808@redhat.com> Message-ID: <51BF4705.1080500@redhat.com> On 06/17/2013 06:59 PM, Jan Cholasta wrote: > On 17.6.2013 17:08, Petr Viktorin wrote: >> We can fix individual out-of-tree failures later, the priority now is >> that in-tree tests are not broken, and that the beakerlib plugin works. >> > > Well, works just fine for me, so ACK. > > Honza > Thanks for review! I just had to merge freeipa.spec.in and update the changelog date to avoid making the strict RPM date checker angry. Pushed all 3 to master. Martin From dpal at redhat.com Mon Jun 17 19:10:05 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 17 Jun 2013 15:10:05 -0400 Subject: [Freeipa-devel] [PATCHES] 0227-0229 freeipa-tests package & Beaker integration plugin In-Reply-To: <51BF2688.6080307@redhat.com> References: <51A4D370.6030307@redhat.com> <51BB18A4.2070607@redhat.com> <51BB2257.40504@redhat.com> <51BF0396.2030806@redhat.com> <51BF0A9F.2030600@redhat.com> <51BF20DD.9070803@redhat.com> <51BF2688.6080307@redhat.com> Message-ID: <51BF5F0D.4060605@redhat.com> On 06/17/2013 11:08 AM, Petr Viktorin wrote: >>> ipa-run-tests --with-beakerlib is horribly slow for me, is that >>> expected? > > Yes. For every logged line, BeakerLib's default logging backend starts > up Python, parses a XML file, appends the line, and writes the XML out > again. So especially with longer runs it's really slow. Is there any way to solve this problem? For example send the output over the DBUS to a special service that would have the python already loaded and would do the appending to the files and writing the output. Also there can be an optimization that it would not save the file up until the change affects a different file. The logic would be: loop: If do not have an open output file open one and keep it in memory Read a request for update until receive a special message for termination or a signal, then break out of the loop If the request for update for the same file update the file Else save currently open file and start a new one, add data to the newly started file end close currently open file If we need this cross systems we can do AMQP. I bet this would be powers of magnitude faster. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jcholast at redhat.com Tue Jun 18 12:10:31 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 18 Jun 2013 14:10:31 +0200 Subject: [Freeipa-devel] [PATCH] 140 Check trust chain length in CA-less install Message-ID: <51C04E37.7060206@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-140-Check-trust-chain-length-in-CA-less-install.patch Type: text/x-patch Size: 1585 bytes Desc: not available URL: From akrivoka at redhat.com Tue Jun 18 14:07:32 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 18 Jun 2013 16:07:32 +0200 Subject: [Freeipa-devel] [PATCHES] 0227-0229 freeipa-tests package & Beaker integration plugin In-Reply-To: <51BF4705.1080500@redhat.com> References: <51A4D370.6030307@redhat.com> <51BB18A4.2070607@redhat.com> <51BB2257.40504@redhat.com> <51BF0396.2030806@redhat.com> <51BF0A9F.2030600@redhat.com> <51BF20DD.9070803@redhat.com> <51BF2688.6080307@redhat.com> <51BF406A.9060808@redhat.com> <51BF4705.1080500@redhat.com> Message-ID: <51C069A4.2050608@redhat.com> On 06/17/2013 07:27 PM, Martin Kosek wrote: > On 06/17/2013 06:59 PM, Jan Cholasta wrote: >> On 17.6.2013 17:08, Petr Viktorin wrote: >>> We can fix individual out-of-tree failures later, the priority now is >>> that in-tree tests are not broken, and that the beakerlib plugin works. >>> >> >> Well, works just fine for me, so ACK. >> >> Honza >> > > Thanks for review! I just had to merge freeipa.spec.in and update the > changelog date to avoid making the strict RPM date checker angry. > > Pushed all 3 to master. > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel There is one line in .gitignore which refers to the old location of the service.crt file. The attached patch fixes that. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0038-Fix-location-of-service.crt-in-.gitignore.patch Type: text/x-patch Size: 688 bytes Desc: not available URL: From purpleidea at gmail.com Tue Jun 18 14:38:07 2013 From: purpleidea at gmail.com (James) Date: Tue, 18 Jun 2013 10:38:07 -0400 Subject: [Freeipa-devel] A puppet module for freeipa Message-ID: <1371566287.28250.32.camel@freed.purpleidea.com> Hi freeipa-devel, I just joined today, I'd like to introduce myself, I'm James. Hi. I am currently working on (among other things) a puppet module for freeipa. I've just published an initial release: https://github.com/purpleidea/puppet-ipa It only has a few resource types at the moment, but I plan to add support for services and other things shortly. I'd really like to thank the ipa devel team for actually returning useful (and accurate) return codes! I've written modules for other projects that don't, and it's a lot harder. Thanks! I've been hanging out in #freeipa as 'purpleidea', and asking questions to make sure I get the design right. Thanks in advance for your help! I'm fairly new to freeipa, but so far I like it quite a lot. It's been on my TODO list for a number of years. I'll probably write about this and other technical things over at my blog. https://ttboj.wordpress.com/ I hope that the code is useful to you, and comments are welcome. If you'd rather not hear about any of this on freeipa-devel, that's okay too, just let me know. Cheers, James -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From purpleidea at gmail.com Tue Jun 18 14:35:07 2013 From: purpleidea at gmail.com (James) Date: Tue, 18 Jun 2013 10:35:07 -0400 Subject: [Freeipa-devel] A puppet module for freeipa Message-ID: <1371566107.28250.31.camel@freed.purpleidea.com> Hi freeipa-devel, I just joined today, I'd like to introduce myself, I'm James. Hi. I am currently working on (among other things) a puppet module for freeipa. I've just published an initial release: https://github.com/purpleidea/puppet-ipa It only has a few resource types at the moment, but I plan to add support for services and other things shortly. I'd really like to thank the ipa devel team for actually returning useful (and accurate) return codes! I've written modules for other projects that don't, and it's a lot harder. Thanks! I've been hanging out in #freeipa as 'purpleidea', and asking questions to make sure I get the design right. Thanks in advance for your help! I'm fairly new to freeipa, but so far I like it quite a lot. It's been on my TODO list for a number of years. I'll probably write about this and other technical things over at my blog. https://ttboj.wordpress.com/ I hope that the code is useful to you, and comments are welcome. If you'd rather not hear about any of this on freeipa-devel, that's okay too, just let me know. Cheers, James -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From mkosek at redhat.com Tue Jun 18 14:55:38 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 18 Jun 2013 16:55:38 +0200 Subject: [Freeipa-devel] [PATCHES] 0227-0229 freeipa-tests package & Beaker integration plugin In-Reply-To: <51C069A4.2050608@redhat.com> References: <51A4D370.6030307@redhat.com> <51BB18A4.2070607@redhat.com> <51BB2257.40504@redhat.com> <51BF0396.2030806@redhat.com> <51BF0A9F.2030600@redhat.com> <51BF20DD.9070803@redhat.com> <51BF2688.6080307@redhat.com> <51BF406A.9060808@redhat.com> <51BF4705.1080500@redhat.com> <51C069A4.2050608@redhat.com> Message-ID: <51C074EA.4010003@redhat.com> On 06/18/2013 04:07 PM, Ana Krivokapic wrote: > On 06/17/2013 07:27 PM, Martin Kosek wrote: >> On 06/17/2013 06:59 PM, Jan Cholasta wrote: >>> On 17.6.2013 17:08, Petr Viktorin wrote: >>>> We can fix individual out-of-tree failures later, the priority now is >>>> that in-tree tests are not broken, and that the beakerlib plugin works. >>>> >>> >>> Well, works just fine for me, so ACK. >>> >>> Honza >>> >> >> Thanks for review! I just had to merge freeipa.spec.in and update the >> changelog date to avoid making the strict RPM date checker angry. >> >> Pushed all 3 to master. >> >> Martin >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > There is one line in .gitignore which refers to the old location of the > service.crt file. The attached patch fixes that. > Good point. ACK, pushed to master. Martin From simo at redhat.com Tue Jun 18 15:16:29 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 18 Jun 2013 11:16:29 -0400 Subject: [Freeipa-devel] A puppet module for freeipa In-Reply-To: <1371566287.28250.32.camel@freed.purpleidea.com> References: <1371566287.28250.32.camel@freed.purpleidea.com> Message-ID: <1371568589.2759.28.camel@willson.li.ssimo.org> On Tue, 2013-06-18 at 10:38 -0400, James wrote: > Hi freeipa-devel, > > I just joined today, I'd like to introduce myself, I'm James. Hi. > > I am currently working on (among other things) a puppet module for > freeipa. I've just published an initial release: > > https://github.com/purpleidea/puppet-ipa > > It only has a few resource types at the moment, but I plan to add > support for services and other things shortly. > > I'd really like to thank the ipa devel team for actually returning > useful (and accurate) return codes! I've written modules for other > projects that don't, and it's a lot harder. Thanks! > > I've been hanging out in #freeipa as 'purpleidea', and asking questions > to make sure I get the design right. Thanks in advance for your help! > I'm fairly new to freeipa, but so far I like it quite a lot. It's been > on my TODO list for a number of years. > > I'll probably write about this and other technical things over at my > blog. https://ttboj.wordpress.com/ > > I hope that the code is useful to you, and comments are welcome. If > you'd rather not hear about any of this on freeipa-devel, that's okay > too, just let me know. James, great start! Feel free to use this list for development oriented questions related to any aspect of FreeIPA. Simo. -- Simo Sorce * Red Hat, Inc * New York From purpleidea at gmail.com Tue Jun 18 15:21:15 2013 From: purpleidea at gmail.com (James) Date: Tue, 18 Jun 2013 11:21:15 -0400 Subject: [Freeipa-devel] A puppet module for freeipa In-Reply-To: <1371568589.2759.28.camel@willson.li.ssimo.org> References: <1371566287.28250.32.camel@freed.purpleidea.com> <1371568589.2759.28.camel@willson.li.ssimo.org> Message-ID: <1371568875.28250.35.camel@freed.purpleidea.com> On Tue, 2013-06-18 at 11:16 -0400, Simo Sorce wrote: > On Tue, 2013-06-18 at 10:38 -0400, James wrote: > > Hi freeipa-devel, > > > > I just joined today, I'd like to introduce myself, I'm James. Hi. > > > > I am currently working on (among other things) a puppet module for > > freeipa. I've just published an initial release: > > > > https://github.com/purpleidea/puppet-ipa > > > > It only has a few resource types at the moment, but I plan to add > > support for services and other things shortly. > > > > I'd really like to thank the ipa devel team for actually returning > > useful (and accurate) return codes! I've written modules for other > > projects that don't, and it's a lot harder. Thanks! > > > > I've been hanging out in #freeipa as 'purpleidea', and asking questions > > to make sure I get the design right. Thanks in advance for your help! > > I'm fairly new to freeipa, but so far I like it quite a lot. It's been > > on my TODO list for a number of years. > > > > I'll probably write about this and other technical things over at my > > blog. https://ttboj.wordpress.com/ > > > > I hope that the code is useful to you, and comments are welcome. If > > you'd rather not hear about any of this on freeipa-devel, that's okay > > too, just let me know. > > > James, > great start! > > Feel free to use this list for development oriented questions related to > any aspect of FreeIPA. > > Simo. Thanks Simo! So far #freeipa and #kerberos have been particularly helpful. I'll probably post back here if I get stuck on something particularly tricky. Feel free to call me out if anyone finds me abusing the ipa api incorrectly in my code. Cheers, James > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From pvoborni at redhat.com Tue Jun 18 17:28:55 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 18 Jun 2013 19:28:55 +0200 Subject: [Freeipa-devel] [PATCH] 421 Fix default value selection in radio widget Message-ID: <51C098D7.4030105@redhat.com> Fix default value selection in radio widget https://fedorahosted.org/freeipa/ticket/3718 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0421-Fix-default-value-selection-in-radio-widget.patch Type: text/x-patch Size: 1867 bytes Desc: not available URL: From npmccallum at redhat.com Tue Jun 18 18:27:30 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 18 Jun 2013 14:27:30 -0400 Subject: [Freeipa-devel] [PATCH] Permit reads to ipatokenRadiusProxyUser objects Message-ID: <1371580050.23980.20.camel@localhost.localdomain> Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Permit-reads-to-ipatokenRadiusProxyUser-objects.patch Type: text/x-patch Size: 3563 bytes Desc: not available URL: From tbabej at redhat.com Wed Jun 19 07:48:56 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 19 Jun 2013 09:48:56 +0200 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool Message-ID: <51C16268.9040001@redhat.com> Hi, Provides a pluggable framework for generating configuration scriptlets and instructions for various machine setups. Creates a new ipa-client-advise command, available to root user on the IPA server. Also provides an example configuration plugin. https://fedorahosted.org/freeipa/ticket/3670 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0072-Provide-ipa-client-advise-tool.patch Type: text/x-patch Size: 17718 bytes Desc: not available URL: From tbabej at redhat.com Wed Jun 19 08:07:51 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 19 Jun 2013 10:07:51 +0200 Subject: [Freeipa-devel] [PATCH] 0033 Fail when adding a trust with a different range In-Reply-To: <51B99C2D.7010301@redhat.com> References: <51A87688.2070107@redhat.com> <51B1B2DF.3050101@redhat.com> <51B20107.4050405@redhat.com> <51B59854.1030404@redhat.com> <51B5F137.5060803@redhat.com> <20130612082316.GU26689@redhat.com> <51B84206.30601@redhat.com> <51B84A17.5000207@redhat.com> <51B99C2D.7010301@redhat.com> Message-ID: <51C166D7.8040203@redhat.com> On 06/13/2013 12:17 PM, Ana Krivokapic wrote: > On 06/12/2013 12:14 PM, Martin Kosek wrote: >> On 06/12/2013 11:40 AM, Tomas Babej wrote: >>> On 06/12/2013 10:23 AM, Alexander Bokovoy wrote: >>>> On Mon, 10 Jun 2013, Ana Krivokapic wrote: >>>>>> And once here(added by your patch): >>>>>> >>>>>> + if not self.validate_range(*keys, **options): >>>>>> + raise errors.ValidationError( >>>>>> + name=_('id range'), >>>>>> + error=_( >>>>>> + 'An id range already exists for this trust. ' >>>>>> + 'You should either delete the old range, or ' >>>>>> + 'exclude --base-id/--range-size options from the >>>>>> command.' >>>>>> >>>>>> I'd suggest we have one common place, say validate_range() function as >>>>>> we have now, >>>>>> that contains all the checks (more coming in the future for sure). >>>>>> >>>>>> That would mean that the whole trust-add command will fail in the case >>>>>> that "ID range >>>>>> with the same name but different domain SID already exists", since we >>>>>> now call validate_range() >>>>>> within execute() method. I checked with Alexander and we agreed that >>>>>> this is more desired behaviour. >>>>>> >>>>>> This would also result to reducement of the number of API calls, which >>>>>> is a nice benefit. >>>>>> >>>>>> Tomas >>>>> This updated patch completely separates validation logic and object >>>>> creation logic of the trust_add command. I added two new methods: >>>>> >>>>> * validate_range(), which ensures that the options and environment >>>>> related to idrange is valid, and >>>>> * validate_options, which takes care of other general validation >>>>> >>>>> One change introduced in this patch is making the >>>>> __populate_remote_domain() method of TrustDomainJoins class public, and >>>>> calling it from trust_add. This was necessary in order to enable >>>>> discovering details of the trusted domain in validation phase. >>>> Looks good overall but I'd suggest to wrap populate_remote_domain() >>>> calls in join_ad_* methods instead of removing them. If remote domain is >>>> not initialized (i.e. not(isinstance(self.remote_domain,TrustedDomainInstance)), >>>> then call populate_remote_domain() as it was before. > Fixed. > >>> I tested the patch and it works fine. >>> >>> There's a lot of refactoring done, but the changes preserve equal state. Aside >>> from >>> Alexander's comment up here, I have but one nitpick. >>> >>> There are few constructs of the form: >>> >>> try: >>> value = dictionary['keyword'] >>> except KeyError: >>> value = None >>> >>> or >>> >>> if 'keyword' in dictionary: >>> value = dictionary['keyword'] >>> else: >>> value = None >>> >>> Can you please substitute these with "value = dictionary.get(keyword, None)"? >>> Not everywhere, but there are places where it can improve readability of the code. >> You can even use just "value = dictionary.get(keyword)" as None is the default >> return value: >> >>>>> print {}.get("foo") > Fixed. > >> None >> >> Martin >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > Updated patch attached. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Wed Jun 19 08:13:47 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 19 Jun 2013 10:13:47 +0200 Subject: [Freeipa-devel] [PATCH] 412 Remove entitlement support Message-ID: <51C1683B.60308@redhat.com> Entitlements code was not tested nor supported upstream since version 3.0. Remove the associated code. https://fedorahosted.org/freeipa/ticket/3739 ---- As agreed on Triage meeting, I plan to push this patch to ipa-3-2 and master branches. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-412-remove-entitlement-support.patch Type: text/x-patch Size: 147013 bytes Desc: not available URL: From abokovoy at redhat.com Wed Jun 19 08:17:16 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 19 Jun 2013 11:17:16 +0300 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <51C16268.9040001@redhat.com> References: <51C16268.9040001@redhat.com> Message-ID: <20130619081716.GG24492@redhat.com> On Wed, 19 Jun 2013, Tomas Babej wrote: > Hi, > > Provides a pluggable framework for generating configuration > scriptlets and instructions for various machine setups. > > Creates a new ipa-client-advise command, available to root user > on the IPA server. > > Also provides an example configuration plugin. > > https://fedorahosted.org/freeipa/ticket/3670 In general looks fine. Manual page is copied from ipa-restore and has its content irrelevant to ipa-client-advise. -- / Alexander Bokovoy From tbabej at redhat.com Wed Jun 19 08:00:16 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 19 Jun 2013 10:00:16 +0200 Subject: [Freeipa-devel] [PATCH 0070] Remove hardcoded values from idrange plugin tests In-Reply-To: <51B706E7.3040607@redhat.com> References: <51B5B4DD.4090201@redhat.com> <51B6E075.8040102@redhat.com> <20130611105917.GP26689@redhat.com> <51B706E7.3040607@redhat.com> Message-ID: <51C16510.4060404@redhat.com> On 06/11/2013 01:15 PM, Tomas Babej wrote: > On 06/11/2013 12:59 PM, Alexander Bokovoy wrote: >> On Tue, 11 Jun 2013, Tomas Babej wrote: >>> On 06/10/2013 01:13 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> Hardcoded values for range parameters such as base RID or range >>>> size could be the reason the tests produced incorrect results, >>>> as the ranges could get in conflict with already existing ranges >>>> on the server. >>>> >>>> Patch dynamically chooses ID and RID range space at the end of >>>> all ranges already present on the server. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3662 >>>> >>>> Tomas >>> >>> Patch altered to incorporate minor fixes for recent idrange >>> objectclass changes. >>> >>> Tomas >> >>> From b35b10f1356c9714776f16aadec7ffbe95e2f41e Mon Sep 17 00:00:00 2001 >>> From: Tomas Babej >>> Date: Mon, 10 Jun 2013 13:08:50 +0200 >>> Subject: [PATCH] Remove hardcoded values from idrange plugin tests >>> >>> Hardcoded values for range parameters such as base RID or range >>> size could be the reason the tests produced incorrect results, >>> as the ranges could get in conflict with already existing ranges >>> on the server. >>> >>> Patch dynamically chooses ID and RID range space at the end of >>> all ranges already present on the server. >>> >>> https://fedorahosted.org/freeipa/ticket/3662 >>> --- >>> ipalib/plugins/idrange.py | 2 +- >>> tests/test_xmlrpc/test_range_plugin.py | 90 >>> ++++++++++++++++++++++------------ >>> 2 files changed, 60 insertions(+), 32 deletions(-) >>> >>> diff --git a/ipalib/plugins/idrange.py b/ipalib/plugins/idrange.py >>> index >>> abca492978d04c71b78a89df8e5c2d1d51c06398..54b835e244fb60ee212a9c00223d4294ff8f4363 >>> 100644 >>> --- a/ipalib/plugins/idrange.py >>> +++ b/ipalib/plugins/idrange.py >>> @@ -224,7 +224,7 @@ class idrange(LDAPObject): >>> if not any((options.get('pkey_only', False), >>> options.get('raw', False))): >>> range_type = entry_attrs['iparangetype'][0] >>> - entry_attrs['iparangetype'] = >>> self.range_types.get(range_type, None) >>> + entry_attrs['iparangetype'] = >>> [self.range_types.get(range_type, None)] >>> >>> # Remove the objectclass >>> if not keep_objectclass: >> Could you please extract this change into an independent patch? I'm >> thinking purely from possible backporting perspective. >> >> Otherwise looks good. > > Sure. Patches 0070 and 0071 attached. > > I'll link 0071 to the ticket for extending ID range types once it's > pushed, for record's sake. > > Tomas > Patches needed rebase. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0071-4-Return-ipaRangeType-as-a-list-in-idrange-commands.patch Type: text/x-patch Size: 1161 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0070-4-Remove-hardcoded-values-from-idrange-plugin-tests.patch Type: text/x-patch Size: 6375 bytes Desc: not available URL: From jcholast at redhat.com Wed Jun 19 09:05:10 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 19 Jun 2013 11:05:10 +0200 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <51C16268.9040001@redhat.com> References: <51C16268.9040001@redhat.com> Message-ID: <51C17446.1050406@redhat.com> Hi, On 19.6.2013 09:48, Tomas Babej wrote: > Hi, > > Provides a pluggable framework for generating configuration > scriptlets and instructions for various machine setups. > > Creates a new ipa-client-advise command, available to root user > on the IPA server. > > Also provides an example configuration plugin. I don't like how you abuse our object model in this patch. For example, why does Configuration inherit from Method? It does not represent method of any object, it doesn't even represent a runnable command. I see you added an artificial advise object, which uses the ldap2 backend, but doesn't actually use LDAP, this is also ugly. Please inherit from Plugin directly and create a new API namespace for advises instead. And don't call the class Configuration, it's misleading (Advise or Advisory is better IMHO). Honza -- Jan Cholasta From pvoborni at redhat.com Wed Jun 19 08:31:41 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 19 Jun 2013 10:31:41 +0200 Subject: [Freeipa-devel] [PATCH] 412 Remove entitlement support In-Reply-To: <51C1683B.60308@redhat.com> References: <51C1683B.60308@redhat.com> Message-ID: <51C16C6D.5080700@redhat.com> On 06/19/2013 10:13 AM, Martin Kosek wrote: > Entitlements code was not tested nor supported upstream since > version 3.0. Remove the associated code. > > https://fedorahosted.org/freeipa/ticket/3739 > > ---- > > As agreed on Triage meeting, I plan to push this patch to ipa-3-2 and master > branches. > > Martin > ACK on Web UI part. -- Petr Vobornik From pspacek at redhat.com Wed Jun 19 11:31:40 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 19 Jun 2013 13:31:40 +0200 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <51C16268.9040001@redhat.com> References: <51C16268.9040001@redhat.com> Message-ID: <51C1969C.9030800@redhat.com> On 19.6.2013 09:48, Tomas Babej wrote: > Hi, > > Provides a pluggable framework for generating configuration > scriptlets and instructions for various machine setups. > > Creates a new ipa-client-advise command, available to root user > on the IPA server. > > Also provides an example configuration plugin. > > https://fedorahosted.org/freeipa/ticket/3670 BTW, shouldn't we rename the tool to 'ipa-advise'? It is pluggable and I can imagine that it will be extended to generate/produce various recommendations for clients & servers ... -- Petr^2 Spacek From tbabej at redhat.com Wed Jun 19 12:02:57 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 19 Jun 2013 14:02:57 +0200 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <51C1969C.9030800@redhat.com> References: <51C16268.9040001@redhat.com> <51C1969C.9030800@redhat.com> Message-ID: <51C19DF1.9010900@redhat.com> On 06/19/2013 01:31 PM, Petr Spacek wrote: > On 19.6.2013 09:48, Tomas Babej wrote: >> Hi, >> >> Provides a pluggable framework for generating configuration >> scriptlets and instructions for various machine setups. >> >> Creates a new ipa-client-advise command, available to root user >> on the IPA server. >> >> Also provides an example configuration plugin. >> >> https://fedorahosted.org/freeipa/ticket/3670 > > BTW, shouldn't we rename the tool to 'ipa-advise'? It is pluggable and > I can imagine that it will be extended to generate/produce various > recommendations for clients & servers ... > I do not see any objections. Indeed the current name may be somewhat misleading given that it is meant to be run on the server. Do you have something particular in mind? Tomas From abokovoy at redhat.com Wed Jun 19 12:36:16 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 19 Jun 2013 15:36:16 +0300 Subject: [Freeipa-devel] [PATCH 0070] Remove hardcoded values from idrange plugin tests In-Reply-To: <51C16510.4060404@redhat.com> References: <51B5B4DD.4090201@redhat.com> <51B6E075.8040102@redhat.com> <20130611105917.GP26689@redhat.com> <51B706E7.3040607@redhat.com> <51C16510.4060404@redhat.com> Message-ID: <20130619123616.GH24492@redhat.com> On Wed, 19 Jun 2013, Tomas Babej wrote: > On 06/11/2013 01:15 PM, Tomas Babej wrote: >> On 06/11/2013 12:59 PM, Alexander Bokovoy wrote: >>> On Tue, 11 Jun 2013, Tomas Babej wrote: >>>> On 06/10/2013 01:13 PM, Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> Hardcoded values for range parameters such as base RID or range >>>>> size could be the reason the tests produced incorrect results, >>>>> as the ranges could get in conflict with already existing ranges >>>>> on the server. >>>>> >>>>> Patch dynamically chooses ID and RID range space at the end of >>>>> all ranges already present on the server. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3662 >>>>> >>>>> Tomas >>>> >>>> Patch altered to incorporate minor fixes for recent idrange >>>> objectclass changes. >>>> >>>> Tomas >>> >>>> From b35b10f1356c9714776f16aadec7ffbe95e2f41e Mon Sep 17 00:00:00 2001 >>>> From: Tomas Babej >>>> Date: Mon, 10 Jun 2013 13:08:50 +0200 >>>> Subject: [PATCH] Remove hardcoded values from idrange plugin tests >>>> >>>> Hardcoded values for range parameters such as base RID or range >>>> size could be the reason the tests produced incorrect results, >>>> as the ranges could get in conflict with already existing ranges >>>> on the server. >>>> >>>> Patch dynamically chooses ID and RID range space at the end of >>>> all ranges already present on the server. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3662 >>>> --- >>>> ipalib/plugins/idrange.py | 2 +- >>>> tests/test_xmlrpc/test_range_plugin.py | 90 >>>> ++++++++++++++++++++++------------ >>>> 2 files changed, 60 insertions(+), 32 deletions(-) >>>> >>>> diff --git a/ipalib/plugins/idrange.py b/ipalib/plugins/idrange.py >>>> index abca492978d04c71b78a89df8e5c2d1d51c06398..54b835e244fb60ee212a9c00223d4294ff8f4363 >>>> 100644 >>>> --- a/ipalib/plugins/idrange.py >>>> +++ b/ipalib/plugins/idrange.py >>>> @@ -224,7 +224,7 @@ class idrange(LDAPObject): >>>> if not any((options.get('pkey_only', False), >>>> options.get('raw', False))): >>>> range_type = entry_attrs['iparangetype'][0] >>>> - entry_attrs['iparangetype'] = >>>> self.range_types.get(range_type, None) >>>> + entry_attrs['iparangetype'] = >>>> [self.range_types.get(range_type, None)] >>>> >>>> # Remove the objectclass >>>> if not keep_objectclass: >>> Could you please extract this change into an independent patch? I'm >>> thinking purely from possible backporting perspective. >>> >>> Otherwise looks good. >> >> Sure. Patches 0070 and 0071 attached. >> >> I'll link 0071 to the ticket for extending ID range types once >> it's pushed, for record's sake. >> >> Tomas >> > Patches needed rebase. The tests now pass on a machine with existing trusts. However, I'm getting following errors in dirsrv's error log: [19/Jun/2013:15:34:58 +0300] find_sid_for_ldap_entry - [file ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [1447902850] into an unused SID. [19/Jun/2013:15:34:58 +0300] ipa_sidgen_add_post_op - [file ipa_sidgen.c, line 149]: Cannot add SID to new entry. [19/Jun/2013:15:34:59 +0300] find_sid_for_ldap_entry - [file ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [1447902950] into an unused SID. [19/Jun/2013:15:34:59 +0300] ipa_sidgen_add_post_op - [file ipa_sidgen.c, line 149]: Cannot add SID to new entry. [19/Jun/2013:15:35:01 +0300] ipa_range_check_pre_op - [file ipa_range_check.c, line 417]: New primary rid range overlaps with existing primary rid range. [19/Jun/2013:15:35:01 +0300] ipa_range_check_pre_op - [file ipa_range_check.c, line 417]: New secondary rid range overlaps with existing secondary rid range. [19/Jun/2013:15:35:01 +0300] ipa_range_check_pre_op - [file ipa_range_check.c, line 417]: New primary rid range overlaps with existing secondary rid range. [19/Jun/2013:15:35:01 +0300] ipa_range_check_pre_op - [file ipa_range_check.c, line 417]: New base range overlaps with existing base range. I think we still need to improve RID part of calculating the test range.. -- / Alexander Bokovoy From dpal at redhat.com Wed Jun 19 12:47:52 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 19 Jun 2013 08:47:52 -0400 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <51C19DF1.9010900@redhat.com> References: <51C16268.9040001@redhat.com> <51C1969C.9030800@redhat.com> <51C19DF1.9010900@redhat.com> Message-ID: <51C1A878.8070607@redhat.com> On 06/19/2013 08:02 AM, Tomas Babej wrote: > On 06/19/2013 01:31 PM, Petr Spacek wrote: >> On 19.6.2013 09:48, Tomas Babej wrote: >>> Hi, >>> >>> Provides a pluggable framework for generating configuration >>> scriptlets and instructions for various machine setups. >>> >>> Creates a new ipa-client-advise command, available to root user >>> on the IPA server. >>> >>> Also provides an example configuration plugin. >>> >>> https://fedorahosted.org/freeipa/ticket/3670 >> >> BTW, shouldn't we rename the tool to 'ipa-advise'? It is pluggable >> and I can imagine that it will be extended to generate/produce >> various recommendations for clients & servers ... >> > > I do not see any objections. > > Indeed the current name may be somewhat misleading given that it is > meant to be run on the server. > > Do you have something particular in mind? > > Tomas > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ipa-config-advisor ? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jcholast at redhat.com Wed Jun 19 12:54:59 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 19 Jun 2013 14:54:59 +0200 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <51C1A878.8070607@redhat.com> References: <51C16268.9040001@redhat.com> <51C1969C.9030800@redhat.com> <51C19DF1.9010900@redhat.com> <51C1A878.8070607@redhat.com> Message-ID: <51C1AA23.6050407@redhat.com> On 19.6.2013 14:47, Dmitri Pal wrote: > On 06/19/2013 08:02 AM, Tomas Babej wrote: >> Do you have something particular in mind? >> >> Tomas >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > > ipa-config-advisor ? > IMO we should stick to a verb in the name, so ipa-config-advise. -- Jan Cholasta From tbabej at redhat.com Wed Jun 19 13:13:03 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 19 Jun 2013 15:13:03 +0200 Subject: [Freeipa-devel] [PATCH 0070] Remove hardcoded values from idrange plugin tests In-Reply-To: <20130619123616.GH24492@redhat.com> References: <51B5B4DD.4090201@redhat.com> <51B6E075.8040102@redhat.com> <20130611105917.GP26689@redhat.com> <51B706E7.3040607@redhat.com> <51C16510.4060404@redhat.com> <20130619123616.GH24492@redhat.com> Message-ID: <51C1AE5F.2060001@redhat.com> On 06/19/2013 02:36 PM, Alexander Bokovoy wrote: > On Wed, 19 Jun 2013, Tomas Babej wrote: >> On 06/11/2013 01:15 PM, Tomas Babej wrote: >>> On 06/11/2013 12:59 PM, Alexander Bokovoy wrote: >>>> On Tue, 11 Jun 2013, Tomas Babej wrote: >>>>> On 06/10/2013 01:13 PM, Tomas Babej wrote: >>>>>> Hi, >>>>>> >>>>>> Hardcoded values for range parameters such as base RID or range >>>>>> size could be the reason the tests produced incorrect results, >>>>>> as the ranges could get in conflict with already existing ranges >>>>>> on the server. >>>>>> >>>>>> Patch dynamically chooses ID and RID range space at the end of >>>>>> all ranges already present on the server. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3662 >>>>>> >>>>>> Tomas >>>>> >>>>> Patch altered to incorporate minor fixes for recent idrange >>>>> objectclass changes. >>>>> >>>>> Tomas >>>> >>>>> From b35b10f1356c9714776f16aadec7ffbe95e2f41e Mon Sep 17 00:00:00 >>>>> 2001 >>>>> From: Tomas Babej >>>>> Date: Mon, 10 Jun 2013 13:08:50 +0200 >>>>> Subject: [PATCH] Remove hardcoded values from idrange plugin tests >>>>> >>>>> Hardcoded values for range parameters such as base RID or range >>>>> size could be the reason the tests produced incorrect results, >>>>> as the ranges could get in conflict with already existing ranges >>>>> on the server. >>>>> >>>>> Patch dynamically chooses ID and RID range space at the end of >>>>> all ranges already present on the server. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3662 >>>>> --- >>>>> ipalib/plugins/idrange.py | 2 +- >>>>> tests/test_xmlrpc/test_range_plugin.py | 90 >>>>> ++++++++++++++++++++++------------ >>>>> 2 files changed, 60 insertions(+), 32 deletions(-) >>>>> >>>>> diff --git a/ipalib/plugins/idrange.py b/ipalib/plugins/idrange.py >>>>> index >>>>> abca492978d04c71b78a89df8e5c2d1d51c06398..54b835e244fb60ee212a9c00223d4294ff8f4363 >>>>> 100644 >>>>> --- a/ipalib/plugins/idrange.py >>>>> +++ b/ipalib/plugins/idrange.py >>>>> @@ -224,7 +224,7 @@ class idrange(LDAPObject): >>>>> if not any((options.get('pkey_only', False), >>>>> options.get('raw', False))): >>>>> range_type = entry_attrs['iparangetype'][0] >>>>> - entry_attrs['iparangetype'] = >>>>> self.range_types.get(range_type, None) >>>>> + entry_attrs['iparangetype'] = >>>>> [self.range_types.get(range_type, None)] >>>>> >>>>> # Remove the objectclass >>>>> if not keep_objectclass: >>>> Could you please extract this change into an independent patch? I'm >>>> thinking purely from possible backporting perspective. >>>> >>>> Otherwise looks good. >>> >>> Sure. Patches 0070 and 0071 attached. >>> >>> I'll link 0071 to the ticket for extending ID range types once it's >>> pushed, for record's sake. >>> >>> Tomas >>> >> Patches needed rebase. > The tests now pass on a machine with existing trusts. > > However, I'm getting following errors in dirsrv's error log: > > [19/Jun/2013:15:34:58 +0300] find_sid_for_ldap_entry - [file > ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [1447902850] > into an unused SID. > [19/Jun/2013:15:34:58 +0300] ipa_sidgen_add_post_op - [file > ipa_sidgen.c, line 149]: Cannot add SID to new entry. > [19/Jun/2013:15:34:59 +0300] find_sid_for_ldap_entry - [file > ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [1447902950] > into an unused SID. > [19/Jun/2013:15:34:59 +0300] ipa_sidgen_add_post_op - [file > ipa_sidgen.c, line 149]: Cannot add SID to new entry. > [19/Jun/2013:15:35:01 +0300] ipa_range_check_pre_op - [file > ipa_range_check.c, line 417]: New primary rid range overlaps with > existing primary rid range. > [19/Jun/2013:15:35:01 +0300] ipa_range_check_pre_op - [file > ipa_range_check.c, line 417]: New secondary rid range overlaps with > existing secondary rid range. > [19/Jun/2013:15:35:01 +0300] ipa_range_check_pre_op - [file > ipa_range_check.c, line 417]: New primary rid range overlaps with > existing secondary rid range. > [19/Jun/2013:15:35:01 +0300] ipa_range_check_pre_op - [file > ipa_range_check.c, line 417]: New base range overlaps with existing base > range. > > I think we still need to improve RID part of calculating the test range.. > Aren't those logs that were produced by negative tests? Overlaps are handled by DS plugin, and only then the errors are propagated back to the IPA framework. Tomas From abokovoy at redhat.com Wed Jun 19 13:12:06 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 19 Jun 2013 16:12:06 +0300 Subject: [Freeipa-devel] [PATCH 0070] Remove hardcoded values from idrange plugin tests In-Reply-To: <51C1ACCB.5060306@redhat.com> References: <51B5B4DD.4090201@redhat.com> <51B6E075.8040102@redhat.com> <20130611105917.GP26689@redhat.com> <51B706E7.3040607@redhat.com> <51C16510.4060404@redhat.com> <20130619123616.GH24492@redhat.com> <51C1ACCB.5060306@redhat.com> Message-ID: <20130619131206.GK24492@redhat.com> On Wed, 19 Jun 2013, Tomas Babej wrote: >On Wed 19 Jun 2013 02:36:16 PM CEST, Alexander Bokovoy wrote: >>On Wed, 19 Jun 2013, Tomas Babej wrote: >>>On 06/11/2013 01:15 PM, Tomas Babej wrote: >>>>On 06/11/2013 12:59 PM, Alexander Bokovoy wrote: >>>>>On Tue, 11 Jun 2013, Tomas Babej wrote: >>>>>>On 06/10/2013 01:13 PM, Tomas Babej wrote: >>>>>>>Hi, >>>>>>> >>>>>>>Hardcoded values for range parameters such as base RID or range >>>>>>>size could be the reason the tests produced incorrect results, >>>>>>>as the ranges could get in conflict with already existing ranges >>>>>>>on the server. >>>>>>> >>>>>>>Patch dynamically chooses ID and RID range space at the end of >>>>>>>all ranges already present on the server. >>>>>>> >>>>>>>https://fedorahosted.org/freeipa/ticket/3662 >>>>>>> >>>>>>>Tomas >>>>>> >>>>>>Patch altered to incorporate minor fixes for recent idrange >>>>>>objectclass changes. >>>>>> >>>>>>Tomas >>>>> >>>>>>From b35b10f1356c9714776f16aadec7ffbe95e2f41e Mon Sep 17 00:00:00 >>>>>>2001 >>>>>>From: Tomas Babej >>>>>>Date: Mon, 10 Jun 2013 13:08:50 +0200 >>>>>>Subject: [PATCH] Remove hardcoded values from idrange plugin tests >>>>>> >>>>>>Hardcoded values for range parameters such as base RID or range >>>>>>size could be the reason the tests produced incorrect results, >>>>>>as the ranges could get in conflict with already existing ranges >>>>>>on the server. >>>>>> >>>>>>Patch dynamically chooses ID and RID range space at the end of >>>>>>all ranges already present on the server. >>>>>> >>>>>>https://fedorahosted.org/freeipa/ticket/3662 >>>>>>--- >>>>>>ipalib/plugins/idrange.py | 2 +- >>>>>>tests/test_xmlrpc/test_range_plugin.py | 90 >>>>>>++++++++++++++++++++++------------ >>>>>>2 files changed, 60 insertions(+), 32 deletions(-) >>>>>> >>>>>>diff --git a/ipalib/plugins/idrange.py b/ipalib/plugins/idrange.py >>>>>>index >>>>>>abca492978d04c71b78a89df8e5c2d1d51c06398..54b835e244fb60ee212a9c00223d4294ff8f4363 >>>>>>100644 >>>>>>--- a/ipalib/plugins/idrange.py >>>>>>+++ b/ipalib/plugins/idrange.py >>>>>>@@ -224,7 +224,7 @@ class idrange(LDAPObject): >>>>>> if not any((options.get('pkey_only', False), >>>>>> options.get('raw', False))): >>>>>> range_type = entry_attrs['iparangetype'][0] >>>>>>- entry_attrs['iparangetype'] = >>>>>>self.range_types.get(range_type, None) >>>>>>+ entry_attrs['iparangetype'] = >>>>>>[self.range_types.get(range_type, None)] >>>>>> >>>>>> # Remove the objectclass >>>>>> if not keep_objectclass: >>>>>Could you please extract this change into an independent patch? I'm >>>>>thinking purely from possible backporting perspective. >>>>> >>>>>Otherwise looks good. >>>> >>>>Sure. Patches 0070 and 0071 attached. >>>> >>>>I'll link 0071 to the ticket for extending ID range types once it's >>>>pushed, for record's sake. >>>> >>>>Tomas >>>> >>>Patches needed rebase. >>The tests now pass on a machine with existing trusts. >> >>However, I'm getting following errors in dirsrv's error log: >> >>[19/Jun/2013:15:34:58 +0300] find_sid_for_ldap_entry - [file >>ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [1447902850] >>into an unused SID. >>[19/Jun/2013:15:34:58 +0300] ipa_sidgen_add_post_op - [file >>ipa_sidgen.c, line 149]: Cannot add SID to new entry. >>[19/Jun/2013:15:34:59 +0300] find_sid_for_ldap_entry - [file >>ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [1447902950] >>into an unused SID. >>[19/Jun/2013:15:34:59 +0300] ipa_sidgen_add_post_op - [file >>ipa_sidgen.c, line 149]: Cannot add SID to new entry. >>[19/Jun/2013:15:35:01 +0300] ipa_range_check_pre_op - [file >>ipa_range_check.c, line 417]: New primary rid range overlaps with >>existing primary rid range. >>[19/Jun/2013:15:35:01 +0300] ipa_range_check_pre_op - [file >>ipa_range_check.c, line 417]: New secondary rid range overlaps with >>existing secondary rid range. >>[19/Jun/2013:15:35:01 +0300] ipa_range_check_pre_op - [file >>ipa_range_check.c, line 417]: New primary rid range overlaps with >>existing secondary rid range. >>[19/Jun/2013:15:35:01 +0300] ipa_range_check_pre_op - [file >>ipa_range_check.c, line 417]: New base range overlaps with existing base >>range. >> >>I think we still need to improve RID part of calculating the test range.. >> > >Aren't those logs that were produced by negative tests? > >Overlaps are handled by DS plugin, and only then the errors are >propagated back to the IPA framework. Uhm. Right. ACK then. -- / Alexander Bokovoy From abokovoy at redhat.com Wed Jun 19 13:03:43 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 19 Jun 2013 16:03:43 +0300 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <51C1AA23.6050407@redhat.com> References: <51C16268.9040001@redhat.com> <51C1969C.9030800@redhat.com> <51C19DF1.9010900@redhat.com> <51C1A878.8070607@redhat.com> <51C1AA23.6050407@redhat.com> Message-ID: <20130619130343.GJ24492@redhat.com> On Wed, 19 Jun 2013, Jan Cholasta wrote: >On 19.6.2013 14:47, Dmitri Pal wrote: >>On 06/19/2013 08:02 AM, Tomas Babej wrote: >>>Do you have something particular in mind? >>> >>>Tomas >>> >>>_______________________________________________ >>>Freeipa-devel mailing list >>>Freeipa-devel at redhat.com >>>https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> >>ipa-config-advisor ? >> > >IMO we should stick to a verb in the name, so ipa-config-advise. Then it is better to be simpler, ipa-advise is a nice name. -- / Alexander Bokovoy From mkosek at redhat.com Wed Jun 19 14:05:38 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 19 Jun 2013 16:05:38 +0200 Subject: [Freeipa-devel] [PATCH 0070] Remove hardcoded values from idrange plugin tests In-Reply-To: <20130619131206.GK24492@redhat.com> References: <51B5B4DD.4090201@redhat.com> <51B6E075.8040102@redhat.com> <20130611105917.GP26689@redhat.com> <51B706E7.3040607@redhat.com> <51C16510.4060404@redhat.com> <20130619123616.GH24492@redhat.com> <51C1ACCB.5060306@redhat.com> <20130619131206.GK24492@redhat.com> Message-ID: <51C1BAB2.3070103@redhat.com> On 06/19/2013 03:12 PM, Alexander Bokovoy wrote: > On Wed, 19 Jun 2013, Tomas Babej wrote: >> On Wed 19 Jun 2013 02:36:16 PM CEST, Alexander Bokovoy wrote: >>> On Wed, 19 Jun 2013, Tomas Babej wrote: >>>> On 06/11/2013 01:15 PM, Tomas Babej wrote: >>>>> On 06/11/2013 12:59 PM, Alexander Bokovoy wrote: >>>>>> On Tue, 11 Jun 2013, Tomas Babej wrote: >>>>>>> On 06/10/2013 01:13 PM, Tomas Babej wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Hardcoded values for range parameters such as base RID or range >>>>>>>> size could be the reason the tests produced incorrect results, >>>>>>>> as the ranges could get in conflict with already existing ranges >>>>>>>> on the server. >>>>>>>> >>>>>>>> Patch dynamically chooses ID and RID range space at the end of >>>>>>>> all ranges already present on the server. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/3662 >>>>>>>> >>>>>>>> Tomas >>>>>>> >>>>>>> Patch altered to incorporate minor fixes for recent idrange >>>>>>> objectclass changes. >>>>>>> >>>>>>> Tomas >>>>>> >>>>>>> From b35b10f1356c9714776f16aadec7ffbe95e2f41e Mon Sep 17 00:00:00 >>>>>>> 2001 >>>>>>> From: Tomas Babej >>>>>>> Date: Mon, 10 Jun 2013 13:08:50 +0200 >>>>>>> Subject: [PATCH] Remove hardcoded values from idrange plugin tests >>>>>>> >>>>>>> Hardcoded values for range parameters such as base RID or range >>>>>>> size could be the reason the tests produced incorrect results, >>>>>>> as the ranges could get in conflict with already existing ranges >>>>>>> on the server. >>>>>>> >>>>>>> Patch dynamically chooses ID and RID range space at the end of >>>>>>> all ranges already present on the server. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/3662 >>>>>>> --- >>>>>>> ipalib/plugins/idrange.py | 2 +- >>>>>>> tests/test_xmlrpc/test_range_plugin.py | 90 >>>>>>> ++++++++++++++++++++++------------ >>>>>>> 2 files changed, 60 insertions(+), 32 deletions(-) >>>>>>> >>>>>>> diff --git a/ipalib/plugins/idrange.py b/ipalib/plugins/idrange.py >>>>>>> index >>>>>>> abca492978d04c71b78a89df8e5c2d1d51c06398..54b835e244fb60ee212a9c00223d4294ff8f4363 >>>>>>> >>>>>>> 100644 >>>>>>> --- a/ipalib/plugins/idrange.py >>>>>>> +++ b/ipalib/plugins/idrange.py >>>>>>> @@ -224,7 +224,7 @@ class idrange(LDAPObject): >>>>>>> if not any((options.get('pkey_only', False), >>>>>>> options.get('raw', False))): >>>>>>> range_type = entry_attrs['iparangetype'][0] >>>>>>> - entry_attrs['iparangetype'] = >>>>>>> self.range_types.get(range_type, None) >>>>>>> + entry_attrs['iparangetype'] = >>>>>>> [self.range_types.get(range_type, None)] >>>>>>> >>>>>>> # Remove the objectclass >>>>>>> if not keep_objectclass: >>>>>> Could you please extract this change into an independent patch? I'm >>>>>> thinking purely from possible backporting perspective. >>>>>> >>>>>> Otherwise looks good. >>>>> >>>>> Sure. Patches 0070 and 0071 attached. >>>>> >>>>> I'll link 0071 to the ticket for extending ID range types once it's >>>>> pushed, for record's sake. >>>>> >>>>> Tomas >>>>> >>>> Patches needed rebase. >>> The tests now pass on a machine with existing trusts. >>> >>> However, I'm getting following errors in dirsrv's error log: >>> >>> [19/Jun/2013:15:34:58 +0300] find_sid_for_ldap_entry - [file >>> ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [1447902850] >>> into an unused SID. >>> [19/Jun/2013:15:34:58 +0300] ipa_sidgen_add_post_op - [file >>> ipa_sidgen.c, line 149]: Cannot add SID to new entry. >>> [19/Jun/2013:15:34:59 +0300] find_sid_for_ldap_entry - [file >>> ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [1447902950] >>> into an unused SID. >>> [19/Jun/2013:15:34:59 +0300] ipa_sidgen_add_post_op - [file >>> ipa_sidgen.c, line 149]: Cannot add SID to new entry. >>> [19/Jun/2013:15:35:01 +0300] ipa_range_check_pre_op - [file >>> ipa_range_check.c, line 417]: New primary rid range overlaps with >>> existing primary rid range. >>> [19/Jun/2013:15:35:01 +0300] ipa_range_check_pre_op - [file >>> ipa_range_check.c, line 417]: New secondary rid range overlaps with >>> existing secondary rid range. >>> [19/Jun/2013:15:35:01 +0300] ipa_range_check_pre_op - [file >>> ipa_range_check.c, line 417]: New primary rid range overlaps with >>> existing secondary rid range. >>> [19/Jun/2013:15:35:01 +0300] ipa_range_check_pre_op - [file >>> ipa_range_check.c, line 417]: New base range overlaps with existing base >>> range. >>> >>> I think we still need to improve RID part of calculating the test range.. >>> >> >> Aren't those logs that were produced by negative tests? >> >> Overlaps are handled by DS plugin, and only then the errors are propagated >> back to the IPA framework. > Uhm. Right. > > ACK then. > Pushed both to master. Martin From tbabej at redhat.com Wed Jun 19 14:09:13 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 19 Jun 2013 16:09:13 +0200 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <20130619130343.GJ24492@redhat.com> References: <51C16268.9040001@redhat.com> <51C1969C.9030800@redhat.com> <51C19DF1.9010900@redhat.com> <51C1A878.8070607@redhat.com> <51C1AA23.6050407@redhat.com> <20130619130343.GJ24492@redhat.com> Message-ID: <51C1BB89.6070002@redhat.com> On 06/19/2013 03:03 PM, Alexander Bokovoy wrote: > On Wed, 19 Jun 2013, Jan Cholasta wrote: >> On 19.6.2013 14:47, Dmitri Pal wrote: >>> On 06/19/2013 08:02 AM, Tomas Babej wrote: >>>> Do you have something particular in mind? >>>> >>>> Tomas >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >>> >>> ipa-config-advisor ? >>> >> >> IMO we should stick to a verb in the name, so ipa-config-advise. > Then it is better to be simpler, ipa-advise is a nice name. > In the work I have in progress right now, I changed the --setup option to --about, so now it is: # ipa-advise --about fedora-authconfig Tomas From mkosek at redhat.com Wed Jun 19 14:14:05 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 19 Jun 2013 16:14:05 +0200 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <20130619130343.GJ24492@redhat.com> References: <51C16268.9040001@redhat.com> <51C1969C.9030800@redhat.com> <51C19DF1.9010900@redhat.com> <51C1A878.8070607@redhat.com> <51C1AA23.6050407@redhat.com> <20130619130343.GJ24492@redhat.com> Message-ID: <51C1BCAD.4020400@redhat.com> On 06/19/2013 03:03 PM, Alexander Bokovoy wrote: > On Wed, 19 Jun 2013, Jan Cholasta wrote: >> On 19.6.2013 14:47, Dmitri Pal wrote: >>> On 06/19/2013 08:02 AM, Tomas Babej wrote: >>>> Do you have something particular in mind? >>>> >>>> Tomas >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >>> >>> ipa-config-advisor ? >>> >> >> IMO we should stick to a verb in the name, so ipa-config-advise. > Then it is better to be simpler, ipa-advise is a nice name. Isn't that too simple? Are you trying to create an all knowing Siri-like advisor for IPA? If I am a user, I would really not know what "ipa-advise" means and what advise could it give to me. # ipa-advise "what pair of socks should I take for today?" ipa-config-advise was better IMHO. Martin From jcholast at redhat.com Wed Jun 19 14:18:27 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 19 Jun 2013 16:18:27 +0200 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <51C1BB89.6070002@redhat.com> References: <51C16268.9040001@redhat.com> <51C1969C.9030800@redhat.com> <51C19DF1.9010900@redhat.com> <51C1A878.8070607@redhat.com> <51C1AA23.6050407@redhat.com> <20130619130343.GJ24492@redhat.com> <51C1BB89.6070002@redhat.com> Message-ID: <51C1BDB3.3060701@redhat.com> On 19.6.2013 16:09, Tomas Babej wrote: > On 06/19/2013 03:03 PM, Alexander Bokovoy wrote: >> On Wed, 19 Jun 2013, Jan Cholasta wrote: >>> On 19.6.2013 14:47, Dmitri Pal wrote: >>>> On 06/19/2013 08:02 AM, Tomas Babej wrote: >>>>> Do you have something particular in mind? >>>>> >>>>> Tomas >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>>> >>>> ipa-config-advisor ? >>>> >>> >>> IMO we should stick to a verb in the name, so ipa-config-advise. >> Then it is better to be simpler, ipa-advise is a nice name. >> > In the work I have in progress right now, I changed the --setup option > to --about, so now it is: > > # ipa-advise --about fedora-authconfig > Why is the option necessary? Why not make it just "ipa-advise fedora-authconfig"? -- Jan Cholasta From ssorce at redhat.com Wed Jun 19 14:46:05 2013 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 19 Jun 2013 10:46:05 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <51C1BCAD.4020400@redhat.com> References: <51C16268.9040001@redhat.com> <51C1969C.9030800@redhat.com> <51C19DF1.9010900@redhat.com> <51C1A878.8070607@redhat.com> <51C1AA23.6050407@redhat.com> <20130619130343.GJ24492@redhat.com> <51C1BCAD.4020400@redhat.com> Message-ID: <1290988309.4979837.1371653165405.JavaMail.root@redhat.com> ----- Original Message ----- > On 06/19/2013 03:03 PM, Alexander Bokovoy wrote: > > On Wed, 19 Jun 2013, Jan Cholasta wrote: > >> On 19.6.2013 14:47, Dmitri Pal wrote: > >>> On 06/19/2013 08:02 AM, Tomas Babej wrote: > >>>> Do you have something particular in mind? > >>>> > >>>> Tomas > >>>> > >>>> _______________________________________________ > >>>> Freeipa-devel mailing list > >>>> Freeipa-devel at redhat.com > >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel > >>> > >>> > >>> ipa-config-advisor ? > >>> > >> > >> IMO we should stick to a verb in the name, so ipa-config-advise. > > Then it is better to be simpler, ipa-advise is a nice name. > > Isn't that too simple? Are you trying to create an all knowing Siri-like > advisor for IPA? If I am a user, I would really not know what "ipa-advise" > means and what advise could it give to me. > > # ipa-advise "what pair of socks should I take for today?" > > ipa-config-advise was better IMHO. then as soon as you need to 'advise' on something that is not config related it becomes akward, also ipa-config-advise is much longer to type and 'config' doesn't really add much. As for the user 'man ipa-advise' will neatly explain what it will advise about, I think that is sufficient. Nobody will expect 'ipa'-advise to provide info about non-ipa related stuff anyway. As for the actual command line options I do wonder as well why you need a --setup or --about option at all. ipa-advise 'topic' is sufficient imo. options that may make sense are things like --verbose so that you can have a small excerpt with the short form and a much longer text with --verbose if necessary. Although maybe we should just reference man pages for longer text and not try to create a new manpage substitute, we certainly should always provide all the content in man pages first. Simo. -- Simo Sorce * Red Hat, Inc. * New York From dpal at redhat.com Wed Jun 19 16:13:51 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 19 Jun 2013 12:13:51 -0400 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <1290988309.4979837.1371653165405.JavaMail.root@redhat.com> References: <51C16268.9040001@redhat.com> <51C1969C.9030800@redhat.com> <51C19DF1.9010900@redhat.com> <51C1A878.8070607@redhat.com> <51C1AA23.6050407@redhat.com> <20130619130343.GJ24492@redhat.com> <51C1BCAD.4020400@redhat.com> <1290988309.4979837.1371653165405.JavaMail.root@redhat.com> Message-ID: <51C1D8BF.8070809@redhat.com> On 06/19/2013 10:46 AM, Simo Sorce wrote: > ----- Original Message ----- >> On 06/19/2013 03:03 PM, Alexander Bokovoy wrote: >>> On Wed, 19 Jun 2013, Jan Cholasta wrote: >>>> On 19.6.2013 14:47, Dmitri Pal wrote: >>>>> On 06/19/2013 08:02 AM, Tomas Babej wrote: >>>>>> Do you have something particular in mind? >>>>>> >>>>>> Tomas >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-devel mailing list >>>>>> Freeipa-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> >>>>> ipa-config-advisor ? >>>>> >>>> IMO we should stick to a verb in the name, so ipa-config-advise. >>> Then it is better to be simpler, ipa-advise is a nice name. >> Isn't that too simple? Are you trying to create an all knowing Siri-like >> advisor for IPA? If I am a user, I would really not know what "ipa-advise" >> means and what advise could it give to me. >> >> # ipa-advise "what pair of socks should I take for today?" >> >> ipa-config-advise was better IMHO. > then as soon as you need to 'advise' on something that is not config related it becomes akward, also ipa-config-advise is much longer to type and 'config' doesn't really add much. > > As for the user 'man ipa-advise' will neatly explain what it will advise about, I think that is sufficient. > Nobody will expect 'ipa'-advise to provide info about non-ipa related stuff anyway. > > As for the actual command line options I do wonder as well why you need a --setup or --about option at all. > > ipa-advise 'topic' is sufficient imo. > > options that may make sense are things like --verbose so that you can have a small excerpt with the short form and a much longer text with --verbose if necessary. Although maybe we should just reference man pages for longer text and not try to create a new manpage substitute, we certainly should always provide all the content in man pages first. > > Simo. > So if I want an advise about Solaris 11 client configuration would it look like this? ipa-advise config --client --distro=solaris --version=11 or ipa-advise client-config-solrais-11 -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From tbabej at redhat.com Wed Jun 19 16:18:17 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 19 Jun 2013 18:18:17 +0200 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <51C1D8BF.8070809@redhat.com> References: <51C16268.9040001@redhat.com> <51C1969C.9030800@redhat.com> <51C19DF1.9010900@redhat.com> <51C1A878.8070607@redhat.com> <51C1AA23.6050407@redhat.com> <20130619130343.GJ24492@redhat.com> <51C1BCAD.4020400@redhat.com> <1290988309.4979837.1371653165405.JavaMail.root@redhat.com> <51C1D8BF.8070809@redhat.com> Message-ID: <51C1D9C9.7090002@redhat.com> On 06/19/2013 06:13 PM, Dmitri Pal wrote: > On 06/19/2013 10:46 AM, Simo Sorce wrote: >> ----- Original Message ----- >>> On 06/19/2013 03:03 PM, Alexander Bokovoy wrote: >>>> On Wed, 19 Jun 2013, Jan Cholasta wrote: >>>>> On 19.6.2013 14:47, Dmitri Pal wrote: >>>>>> On 06/19/2013 08:02 AM, Tomas Babej wrote: >>>>>>> Do you have something particular in mind? >>>>>>> >>>>>>> Tomas >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Freeipa-devel mailing list >>>>>>> Freeipa-devel at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>> ipa-config-advisor ? >>>>>> >>>>> IMO we should stick to a verb in the name, so ipa-config-advise. >>>> Then it is better to be simpler, ipa-advise is a nice name. >>> Isn't that too simple? Are you trying to create an all knowing Siri-like >>> advisor for IPA? If I am a user, I would really not know what "ipa-advise" >>> means and what advise could it give to me. >>> >>> # ipa-advise "what pair of socks should I take for today?" >>> >>> ipa-config-advise was better IMHO. >> then as soon as you need to 'advise' on something that is not config related it becomes akward, also ipa-config-advise is much longer to type and 'config' doesn't really add much. >> >> As for the user 'man ipa-advise' will neatly explain what it will advise about, I think that is sufficient. >> Nobody will expect 'ipa'-advise to provide info about non-ipa related stuff anyway. >> >> As for the actual command line options I do wonder as well why you need a --setup or --about option at all. >> >> ipa-advise 'topic' is sufficient imo. >> >> options that may make sense are things like --verbose so that you can have a small excerpt with the short form and a much longer text with --verbose if necessary. Although maybe we should just reference man pages for longer text and not try to create a new manpage substitute, we certainly should always provide all the content in man pages first. >> >> Simo. >> > So if I want an advise about Solaris 11 client configuration would it > look like this? > > ipa-advise config --client --distro=solaris --version=11 > > or > > ipa-advise client-config-solrais-11 > > The latter. Tomas From dpal at redhat.com Wed Jun 19 16:19:38 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 19 Jun 2013 12:19:38 -0400 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <51C1D9C9.7090002@redhat.com> References: <51C16268.9040001@redhat.com> <51C1969C.9030800@redhat.com> <51C19DF1.9010900@redhat.com> <51C1A878.8070607@redhat.com> <51C1AA23.6050407@redhat.com> <20130619130343.GJ24492@redhat.com> <51C1BCAD.4020400@redhat.com> <1290988309.4979837.1371653165405.JavaMail.root@redhat.com> <51C1D8BF.8070809@redhat.com> <51C1D9C9.7090002@redhat.com> Message-ID: <51C1DA1A.6040800@redhat.com> On 06/19/2013 12:18 PM, Tomas Babej wrote: > On 06/19/2013 06:13 PM, Dmitri Pal wrote: >> On 06/19/2013 10:46 AM, Simo Sorce wrote: >>> ----- Original Message ----- >>>> On 06/19/2013 03:03 PM, Alexander Bokovoy wrote: >>>>> On Wed, 19 Jun 2013, Jan Cholasta wrote: >>>>>> On 19.6.2013 14:47, Dmitri Pal wrote: >>>>>>> On 06/19/2013 08:02 AM, Tomas Babej wrote: >>>>>>>> Do you have something particular in mind? >>>>>>>> >>>>>>>> Tomas >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Freeipa-devel mailing list >>>>>>>> Freeipa-devel at redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>>> ipa-config-advisor ? >>>>>>> >>>>>> IMO we should stick to a verb in the name, so ipa-config-advise. >>>>> Then it is better to be simpler, ipa-advise is a nice name. >>>> Isn't that too simple? Are you trying to create an all knowing >>>> Siri-like >>>> advisor for IPA? If I am a user, I would really not know what >>>> "ipa-advise" >>>> means and what advise could it give to me. >>>> >>>> # ipa-advise "what pair of socks should I take for today?" >>>> >>>> ipa-config-advise was better IMHO. >>> then as soon as you need to 'advise' on something that is not config >>> related it becomes akward, also ipa-config-advise is much longer to >>> type and 'config' doesn't really add much. >>> >>> As for the user 'man ipa-advise' will neatly explain what it will >>> advise about, I think that is sufficient. >>> Nobody will expect 'ipa'-advise to provide info about non-ipa >>> related stuff anyway. >>> >>> As for the actual command line options I do wonder as well why you >>> need a --setup or --about option at all. >>> >>> ipa-advise 'topic' is sufficient imo. >>> >>> options that may make sense are things like --verbose so that you >>> can have a small excerpt with the short form and a much longer text >>> with --verbose if necessary. Although maybe we should just reference >>> man pages for longer text and not try to create a new manpage >>> substitute, we certainly should always provide all the content in >>> man pages first. >>> >>> Simo. >>> >> So if I want an advise about Solaris 11 client configuration would it >> look like this? >> >> ipa-advise config --client --distro=solaris --version=11 >> >> or >> >> ipa-advise client-config-solrais-11 >> >> > > The latter. > > Tomas My point is that if the topics would be long and there will be many of them we should have a naming convention for them. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From tbabej at redhat.com Wed Jun 19 16:29:44 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 19 Jun 2013 18:29:44 +0200 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <51C1DA1A.6040800@redhat.com> References: <51C16268.9040001@redhat.com> <51C1969C.9030800@redhat.com> <51C19DF1.9010900@redhat.com> <51C1A878.8070607@redhat.com> <51C1AA23.6050407@redhat.com> <20130619130343.GJ24492@redhat.com> <51C1BCAD.4020400@redhat.com> <1290988309.4979837.1371653165405.JavaMail.root@redhat.com> <51C1D8BF.8070809@redhat.com> <51C1D9C9.7090002@redhat.com> <51C1DA1A.6040800@redhat.com> Message-ID: <51C1DC78.5020209@redhat.com> On 06/19/2013 06:19 PM, Dmitri Pal wrote: > On 06/19/2013 12:18 PM, Tomas Babej wrote: >> On 06/19/2013 06:13 PM, Dmitri Pal wrote: >>> On 06/19/2013 10:46 AM, Simo Sorce wrote: >>>> ----- Original Message ----- >>>>> On 06/19/2013 03:03 PM, Alexander Bokovoy wrote: >>>>>> On Wed, 19 Jun 2013, Jan Cholasta wrote: >>>>>>> On 19.6.2013 14:47, Dmitri Pal wrote: >>>>>>>> On 06/19/2013 08:02 AM, Tomas Babej wrote: >>>>>>>>> Do you have something particular in mind? >>>>>>>>> >>>>>>>>> Tomas >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Freeipa-devel mailing list >>>>>>>>> Freeipa-devel at redhat.com >>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>>>> ipa-config-advisor ? >>>>>>>> >>>>>>> IMO we should stick to a verb in the name, so ipa-config-advise. >>>>>> Then it is better to be simpler, ipa-advise is a nice name. >>>>> Isn't that too simple? Are you trying to create an all knowing >>>>> Siri-like >>>>> advisor for IPA? If I am a user, I would really not know what >>>>> "ipa-advise" >>>>> means and what advise could it give to me. >>>>> >>>>> # ipa-advise "what pair of socks should I take for today?" >>>>> >>>>> ipa-config-advise was better IMHO. >>>> then as soon as you need to 'advise' on something that is not config >>>> related it becomes akward, also ipa-config-advise is much longer to >>>> type and 'config' doesn't really add much. >>>> >>>> As for the user 'man ipa-advise' will neatly explain what it will >>>> advise about, I think that is sufficient. >>>> Nobody will expect 'ipa'-advise to provide info about non-ipa >>>> related stuff anyway. >>>> >>>> As for the actual command line options I do wonder as well why you >>>> need a --setup or --about option at all. >>>> >>>> ipa-advise 'topic' is sufficient imo. >>>> >>>> options that may make sense are things like --verbose so that you >>>> can have a small excerpt with the short form and a much longer text >>>> with --verbose if necessary. Although maybe we should just reference >>>> man pages for longer text and not try to create a new manpage >>>> substitute, we certainly should always provide all the content in >>>> man pages first. >>>> >>>> Simo. >>>> >>> So if I want an advise about Solaris 11 client configuration would it >>> look like this? >>> >>> ipa-advise config --client --distro=solaris --version=11 >>> >>> or >>> >>> ipa-advise client-config-solrais-11 >>> >>> >> The latter. >> >> Tomas > My point is that if the topics would be long and there will be many of > them we should have a naming convention for them. > Sure, but I am not so certain whether we can come up with anything reasonable, that can capture all the use cases and be simple enough at the same time. E.g., somebody might provide a plugin to generate records for DNS zone delegation (using Petr's idea here). Such a plugin does not really fit into client|server-os-version schema. We can probably start naming plugins in a fairly systematic way, and ensure that we will not create mess in the future via review process. Tomas From abokovoy at redhat.com Wed Jun 19 16:46:01 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 19 Jun 2013 19:46:01 +0300 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <51C1DC78.5020209@redhat.com> References: <51C19DF1.9010900@redhat.com> <51C1A878.8070607@redhat.com> <51C1AA23.6050407@redhat.com> <20130619130343.GJ24492@redhat.com> <51C1BCAD.4020400@redhat.com> <1290988309.4979837.1371653165405.JavaMail.root@redhat.com> <51C1D8BF.8070809@redhat.com> <51C1D9C9.7090002@redhat.com> <51C1DA1A.6040800@redhat.com> <51C1DC78.5020209@redhat.com> Message-ID: <20130619164601.GM24492@redhat.com> (please trim conversations) On Wed, 19 Jun 2013, Tomas Babej wrote: >>>>So if I want an advise about Solaris 11 client configuration would it >>>>look like this? >>>> >>>>ipa-advise config --client --distro=solaris --version=11 >>>> >>>>or >>>> >>>>ipa-advise client-config-solrais-11 >>>> >>>> >>>The latter. >>> >>>Tomas >>My point is that if the topics would be long and there will be many of >>them we should have a naming convention for them. >> > >Sure, but I am not so certain whether we can come up with anything >reasonable, that can capture all the use >cases and be simple enough at the same time. Making plugins to provide their activities named as -- will make it easy to group and use: ipa-advise config-solaris11-padl .... config-freebsd7-padl .... config-aix63-native .... list .... help .... setup-ipa-trust2ad .... setup-ipa-dnsdelegation and so on. ipa-advise list would show all plugins (filtering itself, i.e. list and help plugin) with their short descriptions. >E.g., somebody might provide a plugin to generate records for DNS >zone delegation (using Petr's idea here). Such a plugin does not >really fit into client|server-os-version schema. > >We can probably start naming plugins in a fairly systematic way, and >ensure that we will not create mess in the future via review process. Sure. -- / Alexander Bokovoy From dpal at redhat.com Wed Jun 19 16:49:19 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 19 Jun 2013 12:49:19 -0400 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <51C1DC78.5020209@redhat.com> References: <51C16268.9040001@redhat.com> <51C1969C.9030800@redhat.com> <51C19DF1.9010900@redhat.com> <51C1A878.8070607@redhat.com> <51C1AA23.6050407@redhat.com> <20130619130343.GJ24492@redhat.com> <51C1BCAD.4020400@redhat.com> <1290988309.4979837.1371653165405.JavaMail.root@redhat.com> <51C1D8BF.8070809@redhat.com> <51C1D9C9.7090002@redhat.com> <51C1DA1A.6040800@redhat.com> <51C1DC78.5020209@redhat.com> Message-ID: <51C1E10F.6020601@redhat.com> On 06/19/2013 12:29 PM, Tomas Babej wrote: > On 06/19/2013 06:19 PM, Dmitri Pal wrote: >> On 06/19/2013 12:18 PM, Tomas Babej wrote: >>> On 06/19/2013 06:13 PM, Dmitri Pal wrote: >>>> On 06/19/2013 10:46 AM, Simo Sorce wrote: >>>>> ----- Original Message ----- >>>>>> On 06/19/2013 03:03 PM, Alexander Bokovoy wrote: >>>>>>> On Wed, 19 Jun 2013, Jan Cholasta wrote: >>>>>>>> On 19.6.2013 14:47, Dmitri Pal wrote: >>>>>>>>> On 06/19/2013 08:02 AM, Tomas Babej wrote: >>>>>>>>>> Do you have something particular in mind? >>>>>>>>>> >>>>>>>>>> Tomas >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Freeipa-devel mailing list >>>>>>>>>> Freeipa-devel at redhat.com >>>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>>>>> ipa-config-advisor ? >>>>>>>>> >>>>>>>> IMO we should stick to a verb in the name, so ipa-config-advise. >>>>>>> Then it is better to be simpler, ipa-advise is a nice name. >>>>>> Isn't that too simple? Are you trying to create an all knowing >>>>>> Siri-like >>>>>> advisor for IPA? If I am a user, I would really not know what >>>>>> "ipa-advise" >>>>>> means and what advise could it give to me. >>>>>> >>>>>> # ipa-advise "what pair of socks should I take for today?" >>>>>> >>>>>> ipa-config-advise was better IMHO. >>>>> then as soon as you need to 'advise' on something that is not config >>>>> related it becomes akward, also ipa-config-advise is much longer to >>>>> type and 'config' doesn't really add much. >>>>> >>>>> As for the user 'man ipa-advise' will neatly explain what it will >>>>> advise about, I think that is sufficient. >>>>> Nobody will expect 'ipa'-advise to provide info about non-ipa >>>>> related stuff anyway. >>>>> >>>>> As for the actual command line options I do wonder as well why you >>>>> need a --setup or --about option at all. >>>>> >>>>> ipa-advise 'topic' is sufficient imo. >>>>> >>>>> options that may make sense are things like --verbose so that you >>>>> can have a small excerpt with the short form and a much longer text >>>>> with --verbose if necessary. Although maybe we should just reference >>>>> man pages for longer text and not try to create a new manpage >>>>> substitute, we certainly should always provide all the content in >>>>> man pages first. >>>>> >>>>> Simo. >>>>> >>>> So if I want an advise about Solaris 11 client configuration would it >>>> look like this? >>>> >>>> ipa-advise config --client --distro=solaris --version=11 >>>> >>>> or >>>> >>>> ipa-advise client-config-solrais-11 >>>> >>>> >>> The latter. >>> >>> Tomas >> My point is that if the topics would be long and there will be many of >> them we should have a naming convention for them. >> > > Sure, but I am not so certain whether we can come up with anything > reasonable, that can capture all the use > cases and be simple enough at the same time. > > E.g., somebody might provide a plugin to generate records for DNS zone > delegation (using Petr's idea here). Such a plugin does not really fit > into client|server-os-version schema. > > We can probably start naming plugins in a fairly systematic way, and > ensure that we will not create mess in the future via review process. > > Tomas No I am talking about naming conventions regarding : spaces, dashes, capitalization, verb use, noun use etc. So that we do not have "client-config-solrais-11" and "ConfiguringHPUX_11.23withKerberos" -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Wed Jun 19 16:50:31 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 19 Jun 2013 12:50:31 -0400 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <20130619164601.GM24492@redhat.com> References: <51C19DF1.9010900@redhat.com> <51C1A878.8070607@redhat.com> <51C1AA23.6050407@redhat.com> <20130619130343.GJ24492@redhat.com> <51C1BCAD.4020400@redhat.com> <1290988309.4979837.1371653165405.JavaMail.root@redhat.com> <51C1D8BF.8070809@redhat.com> <51C1D9C9.7090002@redhat.com> <51C1DA1A.6040800@redhat.com> <51C1DC78.5020209@redhat.com> <20130619164601.GM24492@redhat.com> Message-ID: <51C1E157.4090308@redhat.com> On 06/19/2013 12:46 PM, Alexander Bokovoy wrote: > (please trim conversations) > > On Wed, 19 Jun 2013, Tomas Babej wrote: >>>>> So if I want an advise about Solaris 11 client configuration would it >>>>> look like this? >>>>> >>>>> ipa-advise config --client --distro=solaris --version=11 >>>>> >>>>> or >>>>> >>>>> ipa-advise client-config-solrais-11 >>>>> >>>>> >>>> The latter. >>>> >>>> Tomas >>> My point is that if the topics would be long and there will be many of >>> them we should have a naming convention for them. >>> >> >> Sure, but I am not so certain whether we can come up with anything >> reasonable, that can capture all the use >> cases and be simple enough at the same time. > Making plugins to provide their activities named as > > -- > > will make it easy to group and use: > > ipa-advise config-solaris11-padl > .... config-freebsd7-padl > .... config-aix63-native > .... list > .... help > .... setup-ipa-trust2ad > .... setup-ipa-dnsdelegation > > and so on. > > ipa-advise list Yes this is exactly what I was talking about. Should be a part of design page in the naming convention section IMO. > > would show all plugins (filtering itself, i.e. list and help plugin) > with their short descriptions. > >> E.g., somebody might provide a plugin to generate records for DNS >> zone delegation (using Petr's idea here). Such a plugin does not >> really fit into client|server-os-version schema. >> >> We can probably start naming plugins in a fairly systematic way, and >> ensure that we will not create mess in the future via review process. > Sure. > > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From abokovoy at redhat.com Wed Jun 19 16:56:52 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 19 Jun 2013 19:56:52 +0300 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <51C1E157.4090308@redhat.com> References: <51C1AA23.6050407@redhat.com> <20130619130343.GJ24492@redhat.com> <51C1BCAD.4020400@redhat.com> <1290988309.4979837.1371653165405.JavaMail.root@redhat.com> <51C1D8BF.8070809@redhat.com> <51C1D9C9.7090002@redhat.com> <51C1DA1A.6040800@redhat.com> <51C1DC78.5020209@redhat.com> <20130619164601.GM24492@redhat.com> <51C1E157.4090308@redhat.com> Message-ID: <20130619165652.GA10478@redhat.com> On Wed, 19 Jun 2013, Dmitri Pal wrote: >On 06/19/2013 12:46 PM, Alexander Bokovoy wrote: >> (please trim conversations) >> >> On Wed, 19 Jun 2013, Tomas Babej wrote: >>>>>> So if I want an advise about Solaris 11 client configuration would it >>>>>> look like this? >>>>>> >>>>>> ipa-advise config --client --distro=solaris --version=11 >>>>>> >>>>>> or >>>>>> >>>>>> ipa-advise client-config-solrais-11 >>>>>> >>>>>> >>>>> The latter. >>>>> >>>>> Tomas >>>> My point is that if the topics would be long and there will be many of >>>> them we should have a naming convention for them. >>>> >>> >>> Sure, but I am not so certain whether we can come up with anything >>> reasonable, that can capture all the use >>> cases and be simple enough at the same time. >> Making plugins to provide their activities named as >> >> -- >> >> will make it easy to group and use: >> >> ipa-advise config-solaris11-padl >> .... config-freebsd7-padl >> .... config-aix63-native >> .... list >> .... help >> .... setup-ipa-trust2ad >> .... setup-ipa-dnsdelegation >> >> and so on. >> >> ipa-advise list > >Yes this is exactly what I was talking about. >Should be a part of design page in the naming convention section IMO. I've added it there: http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts#Major_configuration_options_and_enablement -- / Alexander Bokovoy From tbabej at redhat.com Wed Jun 19 18:07:08 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 19 Jun 2013 20:07:08 +0200 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <20130619165652.GA10478@redhat.com> References: <51C1AA23.6050407@redhat.com> <20130619130343.GJ24492@redhat.com> <51C1BCAD.4020400@redhat.com> <1290988309.4979837.1371653165405.JavaMail.root@redhat.com> <51C1D8BF.8070809@redhat.com> <51C1D9C9.7090002@redhat.com> <51C1DA1A.6040800@redhat.com> <51C1DC78.5020209@redhat.com> <20130619164601.GM24492@redhat.com> <51C1E157.4090308@redhat.com> <20130619165652.GA10478@redhat.com> Message-ID: <51C1F34C.5000805@redhat.com> [big snip] Providing new version which should address mentioned issues: - advice plugins now inherit directly from Plugin, initial approach via Method class was abandoned - new Namespace api.Advice collects all the advice plugins - tool renamed to ipa-advise to express a more general use case Additional improvements: - keywords are now generated out of Advice class's name, where underscores are replaced by hyphens - rewritten the example plugin in the docs, and provided more information there - instead of --setup option to provide configuration, ipa-advise takes one positional argument - renamed to ipa-advise Concerns: - man page might need more improvements I'll craft a design page for plugin authors, might be useful, even if the info is in the package docs. ----------------------------------------------- Here's a little preview: [tbabej at vm-001 ~]$ sudo ipa-advise fedora-authconfig ------------------------------------------------------------------------------------------------ Authconfig instructions for configuring Fedora 18/19 client with IPA server without use of SSSD. ------------------------------------------------------------------------------------------------ /sbin/authconfig --enableldap --ldapserver=vm-001.idm.com --enablerfc2307bis --enablekrb5 [tbabej at vm-001 ~]$ sudo ipa-advise fedora-authconfig4 invalid 'setup': No instructions are available for 'fedora_authconfig4'. See the list of available configuration advices using the --list option. [tbabej at vm-001 ~]$ sudo ipa-advise ------------------------- List of available advices ------------------------- fedora-authconfig : Authconfig instructions for configuring Fedora 18/19 client with IPA server without use of SSSD. Tomas Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0072-2-Provide-ipa-config-advise-tool.patch Type: text/x-patch Size: 18913 bytes Desc: not available URL: From rcritten at redhat.com Wed Jun 19 18:30:47 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 19 Jun 2013 14:30:47 -0400 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <51C1F34C.5000805@redhat.com> References: <51C1AA23.6050407@redhat.com> <20130619130343.GJ24492@redhat.com> <51C1BCAD.4020400@redhat.com> <1290988309.4979837.1371653165405.JavaMail.root@redhat.com> <51C1D8BF.8070809@redhat.com> <51C1D9C9.7090002@redhat.com> <51C1DA1A.6040800@redhat.com> <51C1DC78.5020209@redhat.com> <20130619164601.GM24492@redhat.com> <51C1E157.4090308@redhat.com> <20130619165652.GA10478@redhat.com> <51C1F34C.5000805@redhat.com> Message-ID: <51C1F8D7.3070109@redhat.com> Tomas Babej wrote: > [big snip] > > Providing new version which should address mentioned issues: > - advice plugins now inherit directly from Plugin, initial approach > via Method class was abandoned > - new Namespace api.Advice collects all the advice plugins > - tool renamed to ipa-advise to express a more general use case > > Additional improvements: > - keywords are now generated out of Advice class's name, where > underscores are replaced by hyphens > - rewritten the example plugin in the docs, and provided more > information there > - instead of --setup option to provide configuration, ipa-advise > takes one positional argument > - renamed to ipa-advise > > Concerns: > - man page might need more improvements > > I'll craft a design page for plugin authors, might be useful, even if > the info is in the package docs. > > ----------------------------------------------- > Here's a little preview: > > [tbabej at vm-001 ~]$ sudo ipa-advise fedora-authconfig > ------------------------------------------------------------------------------------------------ > > Authconfig instructions for configuring Fedora 18/19 client with IPA > server without use of SSSD. > ------------------------------------------------------------------------------------------------ > > /sbin/authconfig --enableldap --ldapserver=vm-001.idm.com > --enablerfc2307bis --enablekrb5 > > [tbabej at vm-001 ~]$ sudo ipa-advise fedora-authconfig4 > invalid 'setup': No instructions are available for 'fedora_authconfig4'. > See the list of available configuration advices using the --list option. > > [tbabej at vm-001 ~]$ sudo ipa-advise > ------------------------- > List of available advices > ------------------------- > fedora-authconfig : Authconfig instructions for configuring Fedora > 18/19 client with IPA server without use of SSSD. If it's just providing advise why does it need root access? Or is it expected to provide advise based on current configuration? rob From tbabej at redhat.com Wed Jun 19 18:37:55 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 19 Jun 2013 20:37:55 +0200 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <51C1F8D7.3070109@redhat.com> References: <51C1AA23.6050407@redhat.com> <20130619130343.GJ24492@redhat.com> <51C1BCAD.4020400@redhat.com> <1290988309.4979837.1371653165405.JavaMail.root@redhat.com> <51C1D8BF.8070809@redhat.com> <51C1D9C9.7090002@redhat.com> <51C1DA1A.6040800@redhat.com> <51C1DC78.5020209@redhat.com> <20130619164601.GM24492@redhat.com> <51C1E157.4090308@redhat.com> <20130619165652.GA10478@redhat.com> <51C1F34C.5000805@redhat.com> <51C1F8D7.3070109@redhat.com> Message-ID: <51C1FA83.5000705@redhat.com> On 06/19/2013 08:30 PM, Rob Crittenden wrote: > Tomas Babej wrote: >> [big snip] >> >> Providing new version which should address mentioned issues: >> - advice plugins now inherit directly from Plugin, initial approach >> via Method class was abandoned >> - new Namespace api.Advice collects all the advice plugins >> - tool renamed to ipa-advise to express a more general use case >> >> Additional improvements: >> - keywords are now generated out of Advice class's name, where >> underscores are replaced by hyphens >> - rewritten the example plugin in the docs, and provided more >> information there >> - instead of --setup option to provide configuration, ipa-advise >> takes one positional argument >> - renamed to ipa-advise >> >> Concerns: >> - man page might need more improvements >> >> I'll craft a design page for plugin authors, might be useful, even if >> the info is in the package docs. >> >> ----------------------------------------------- >> Here's a little preview: >> >> [tbabej at vm-001 ~]$ sudo ipa-advise fedora-authconfig >> ------------------------------------------------------------------------------------------------ >> >> >> Authconfig instructions for configuring Fedora 18/19 client with IPA >> server without use of SSSD. >> ------------------------------------------------------------------------------------------------ >> >> >> /sbin/authconfig --enableldap --ldapserver=vm-001.idm.com >> --enablerfc2307bis --enablekrb5 >> >> [tbabej at vm-001 ~]$ sudo ipa-advise fedora-authconfig4 >> invalid 'setup': No instructions are available for 'fedora_authconfig4'. >> See the list of available configuration advices using the --list option. >> >> [tbabej at vm-001 ~]$ sudo ipa-advise >> ------------------------- >> List of available advices >> ------------------------- >> fedora-authconfig : Authconfig instructions for configuring Fedora >> 18/19 client with IPA server without use of SSSD. > > If it's just providing advise why does it need root access? Or is it > expected to provide advise based on current configuration? > > rob > Original purpose I had in mind was to provide an option for plugin authors to connect via autobind to the LDAP. Now there's also a option of using our api commands, e.g. to read trust-related information out of the tree. However some parts of the tree are not exposed, so if some plugin needs to access information, about replica topology for example, I guess they would need to use this approach. Tomas From abokovoy at redhat.com Wed Jun 19 18:56:56 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 19 Jun 2013 21:56:56 +0300 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <51C1F8D7.3070109@redhat.com> References: <1290988309.4979837.1371653165405.JavaMail.root@redhat.com> <51C1D8BF.8070809@redhat.com> <51C1D9C9.7090002@redhat.com> <51C1DA1A.6040800@redhat.com> <51C1DC78.5020209@redhat.com> <20130619164601.GM24492@redhat.com> <51C1E157.4090308@redhat.com> <20130619165652.GA10478@redhat.com> <51C1F34C.5000805@redhat.com> <51C1F8D7.3070109@redhat.com> Message-ID: <20130619185656.GC10478@redhat.com> On Wed, 19 Jun 2013, Rob Crittenden wrote: >Tomas Babej wrote: >>[big snip] >> >>Providing new version which should address mentioned issues: >> - advice plugins now inherit directly from Plugin, initial approach >>via Method class was abandoned >> - new Namespace api.Advice collects all the advice plugins >> - tool renamed to ipa-advise to express a more general use case >> >>Additional improvements: >> - keywords are now generated out of Advice class's name, where >>underscores are replaced by hyphens >> - rewritten the example plugin in the docs, and provided more >>information there >> - instead of --setup option to provide configuration, ipa-advise >>takes one positional argument >> - renamed to ipa-advise >> >>Concerns: >> - man page might need more improvements >> >>I'll craft a design page for plugin authors, might be useful, even if >>the info is in the package docs. >> >>----------------------------------------------- >>Here's a little preview: >> >>[tbabej at vm-001 ~]$ sudo ipa-advise fedora-authconfig >>------------------------------------------------------------------------------------------------ >> >>Authconfig instructions for configuring Fedora 18/19 client with IPA >>server without use of SSSD. >>------------------------------------------------------------------------------------------------ >> >>/sbin/authconfig --enableldap --ldapserver=vm-001.idm.com >>--enablerfc2307bis --enablekrb5 >> >>[tbabej at vm-001 ~]$ sudo ipa-advise fedora-authconfig4 >>invalid 'setup': No instructions are available for 'fedora_authconfig4'. >>See the list of available configuration advices using the --list option. >> >>[tbabej at vm-001 ~]$ sudo ipa-advise >>------------------------- >>List of available advices >>------------------------- >> fedora-authconfig : Authconfig instructions for configuring Fedora >>18/19 client with IPA server without use of SSSD. > >If it's just providing advise why does it need root access? Or is it >expected to provide advise based on current configuration? Exactly. Getting ranges, configured trusts, etc. Not all of that information may be available under non-privileged account, especially if somebody would decide to plug in advices for backup or CA handling/configuration of advanced features. -- / Alexander Bokovoy From abokovoy at redhat.com Wed Jun 19 18:58:40 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 19 Jun 2013 21:58:40 +0300 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <51C1F34C.5000805@redhat.com> References: <51C1BCAD.4020400@redhat.com> <1290988309.4979837.1371653165405.JavaMail.root@redhat.com> <51C1D8BF.8070809@redhat.com> <51C1D9C9.7090002@redhat.com> <51C1DA1A.6040800@redhat.com> <51C1DC78.5020209@redhat.com> <20130619164601.GM24492@redhat.com> <51C1E157.4090308@redhat.com> <20130619165652.GA10478@redhat.com> <51C1F34C.5000805@redhat.com> Message-ID: <20130619185840.GD10478@redhat.com> On Wed, 19 Jun 2013, Tomas Babej wrote: > [big snip] > > Providing new version which should address mentioned issues: > - advice plugins now inherit directly from Plugin, initial > approach via Method class was abandoned > - new Namespace api.Advice collects all the advice plugins > - tool renamed to ipa-advise to express a more general use case > > Additional improvements: > - keywords are now generated out of Advice class's name, where > underscores are replaced by hyphens > - rewritten the example plugin in the docs, and provided more > information there > - instead of --setup option to provide configuration, ipa-advise > takes one positional argument > - renamed to ipa-advise > > Concerns: > - man page might need more improvements > > I'll craft a design page for plugin authors, might be useful, even > if the info is in the package docs. > > ----------------------------------------------- > Here's a little preview: > > [tbabej at vm-001 ~]$ sudo ipa-advise fedora-authconfig > ------------------------------------------------------------------------------------------------ > Authconfig instructions for configuring Fedora 18/19 client with IPA > server without use of SSSD. > ------------------------------------------------------------------------------------------------ > /sbin/authconfig --enableldap --ldapserver=vm-001.idm.com > --enablerfc2307bis --enablekrb5 As the output is almost usable for cut&paste to run on client machines, may be prefix the description/instructions with #? -- / Alexander Bokovoy From tbabej at redhat.com Wed Jun 19 19:10:20 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 19 Jun 2013 21:10:20 +0200 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <20130619185840.GD10478@redhat.com> References: <51C1BCAD.4020400@redhat.com> <1290988309.4979837.1371653165405.JavaMail.root@redhat.com> <51C1D8BF.8070809@redhat.com> <51C1D9C9.7090002@redhat.com> <51C1DA1A.6040800@redhat.com> <51C1DC78.5020209@redhat.com> <20130619164601.GM24492@redhat.com> <51C1E157.4090308@redhat.com> <20130619165652.GA10478@redhat.com> <51C1F34C.5000805@redhat.com> <20130619185840.GD10478@redhat.com> Message-ID: <51C2021C.7050706@redhat.com> [snip] >> Here's a little preview: >> >> [tbabej at vm-001 ~]$ sudo ipa-advise fedora-authconfig >> ------------------------------------------------------------------------------------------------ >> >> Authconfig instructions for configuring Fedora 18/19 client with IPA >> server without use of SSSD. >> ------------------------------------------------------------------------------------------------ >> >> /sbin/authconfig --enableldap --ldapserver=vm-001.idm.com >> --enablerfc2307bis --enablekrb5 > As the output is almost usable for cut&paste to run on client > machines, may be prefix the description/instructions with #? > Sure, that's a good idea. Then you could simply do [tbabej at vm-001 ~]$ sudo ipa-advise fedora-authconfig > script.sh [tbabej at vm-001 ~]$ scp script.sh vm-002:script.sh [tbabej at vm-002 ~]$ ./script.sh I'll include that change in the next revision Also, adding this to the wiki page for plugin authors as an convention wouldn't hurt. On the second thought, we run the risk of people mindlessly using the generated scripts without even looking at them though. Tomas From abokovoy at redhat.com Wed Jun 19 19:21:00 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 19 Jun 2013 22:21:00 +0300 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <51C2021C.7050706@redhat.com> References: <51C1D8BF.8070809@redhat.com> <51C1D9C9.7090002@redhat.com> <51C1DA1A.6040800@redhat.com> <51C1DC78.5020209@redhat.com> <20130619164601.GM24492@redhat.com> <51C1E157.4090308@redhat.com> <20130619165652.GA10478@redhat.com> <51C1F34C.5000805@redhat.com> <20130619185840.GD10478@redhat.com> <51C2021C.7050706@redhat.com> Message-ID: <20130619192100.GE10478@redhat.com> On Wed, 19 Jun 2013, Tomas Babej wrote: >[snip] >>>Here's a little preview: >>> >>>[tbabej at vm-001 ~]$ sudo ipa-advise fedora-authconfig >>>------------------------------------------------------------------------------------------------ >>> >>>Authconfig instructions for configuring Fedora 18/19 client with >>>IPA server without use of SSSD. >>>------------------------------------------------------------------------------------------------ >>> >>>/sbin/authconfig --enableldap --ldapserver=vm-001.idm.com >>>--enablerfc2307bis --enablekrb5 >>As the output is almost usable for cut&paste to run on client >>machines, may be prefix the description/instructions with #? >> > >Sure, that's a good idea. Then you could simply do > >[tbabej at vm-001 ~]$ sudo ipa-advise fedora-authconfig > script.sh >[tbabej at vm-001 ~]$ scp script.sh vm-002:script.sh >[tbabej at vm-002 ~]$ ./script.sh > >I'll include that change in the next revision > >Also, adding this to the wiki page for plugin authors as an >convention wouldn't hurt. > >On the second thought, we run the risk of people mindlessly using the >generated scripts without even looking at them though. Yep, that could happend. We can make those statements echoed on execution rather than put as comments: #!/bin/sh cat << "ADVISE_DESCRIPTION" ---------------------------------------------------------------- Authconfig instructions for configuring Fedora 18/19 client with IPA server without use of SSSD. ---------------------------------------------------------------- ADVISE_DESCRIPTION -- / Alexander Bokovoy From dpal at redhat.com Thu Jun 20 04:09:44 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 20 Jun 2013 00:09:44 -0400 Subject: [Freeipa-devel] IPA to IPA trusts Message-ID: <51C28088.20300@redhat.com> Hello, I have a stupid idea. We now have ability to make IPA trust AD and AD trust IPA. IPA pretends that it is AD. I wonder how hard it would be to setup the case when there are two IPA servers that both pretending that they are AD talking to each other. This might be a temp solution for IPA to IPA trusts until we do PADs. It might be a temp solution for use cases like this https://fedorahosted.org/freeipa/ticket/3742 I suspect that SSSD would have to be configured as if it is a member of an AD domain trusting another AD domain for this to work :-) -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From abokovoy at redhat.com Thu Jun 20 04:45:14 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 20 Jun 2013 07:45:14 +0300 Subject: [Freeipa-devel] IPA to IPA trusts In-Reply-To: <51C28088.20300@redhat.com> References: <51C28088.20300@redhat.com> Message-ID: <20130620044514.GF10478@redhat.com> On Thu, 20 Jun 2013, Dmitri Pal wrote: >Hello, > >I have a stupid idea. >We now have ability to make IPA trust AD and AD trust IPA. IPA pretends >that it is AD. >I wonder how hard it would be to setup the case when there are two IPA >servers that both pretending that they are AD talking to each other. This is the plan -- we want to reuse all the work for AD trusts to build up IPA to IPA trusts: SIDs, SSSD providers. However, we are not there yet (see below). >This might be a temp solution for IPA to IPA trusts until we do PADs. >It might be a temp solution for use cases like this >https://fedorahosted.org/freeipa/ticket/3742 We need to implement GC service server side. Additionally, we haven't yet implemented fully part of the trust procedure in smbd according to the spec, we rely on AD performing that part for us. Without real AD right now we'd have to know much more about the other side. -- / Alexander Bokovoy From pspacek at redhat.com Thu Jun 20 07:29:44 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 20 Jun 2013 09:29:44 +0200 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <20130619185656.GC10478@redhat.com> References: <1290988309.4979837.1371653165405.JavaMail.root@redhat.com> <51C1D8BF.8070809@redhat.com> <51C1D9C9.7090002@redhat.com> <51C1DA1A.6040800@redhat.com> <51C1DC78.5020209@redhat.com> <20130619164601.GM24492@redhat.com> <51C1E157.4090308@redhat.com> <20130619165652.GA10478@redhat.com> <51C1F34C.5000805@redhat.com> <51C1F8D7.3070109@redhat.com> <20130619185656.GC10478@redhat.com> Message-ID: <51C2AF68.3020606@redhat.com> On 19.6.2013 20:56, Alexander Bokovoy wrote: > On Wed, 19 Jun 2013, Rob Crittenden wrote: >> Tomas Babej wrote: >>> [big snip] >>> >>> Providing new version which should address mentioned issues: >>> - advice plugins now inherit directly from Plugin, initial approach >>> via Method class was abandoned >>> - new Namespace api.Advice collects all the advice plugins >>> - tool renamed to ipa-advise to express a more general use case >>> >>> Additional improvements: >>> - keywords are now generated out of Advice class's name, where >>> underscores are replaced by hyphens >>> - rewritten the example plugin in the docs, and provided more >>> information there >>> - instead of --setup option to provide configuration, ipa-advise >>> takes one positional argument >>> - renamed to ipa-advise >>> >>> Concerns: >>> - man page might need more improvements >>> >>> I'll craft a design page for plugin authors, might be useful, even if >>> the info is in the package docs. >>> >>> ----------------------------------------------- >>> Here's a little preview: >>> >>> [tbabej at vm-001 ~]$ sudo ipa-advise fedora-authconfig >>> ------------------------------------------------------------------------------------------------ >>> >>> >>> Authconfig instructions for configuring Fedora 18/19 client with IPA >>> server without use of SSSD. >>> ------------------------------------------------------------------------------------------------ >>> >>> >>> /sbin/authconfig --enableldap --ldapserver=vm-001.idm.com >>> --enablerfc2307bis --enablekrb5 >>> >>> [tbabej at vm-001 ~]$ sudo ipa-advise fedora-authconfig4 >>> invalid 'setup': No instructions are available for 'fedora_authconfig4'. >>> See the list of available configuration advices using the --list option. >>> >>> [tbabej at vm-001 ~]$ sudo ipa-advise >>> ------------------------- >>> List of available advices >>> ------------------------- >>> fedora-authconfig : Authconfig instructions for configuring Fedora >>> 18/19 client with IPA server without use of SSSD. >> >> If it's just providing advise why does it need root access? Or is it >> expected to provide advise based on current configuration? > Exactly. Getting ranges, configured trusts, etc. Not all of that > information may be available under non-privileged account, especially if > somebody would decide to plug in advices for backup or CA > handling/configuration of advanced features. I think that ipa-advise should not require root access *implicitly*. It would prevent lower-level admins from ipa-advise tool. IMHO plugins should try to get required information and print an 'Insufficient access rights, try it again as root/admin' error when appropriate. As a result, basic 'advices' (like recommended client configuration) will be accessible anybody and special 'advices' (something related to AD trusts etc.) will be accessible only to admins. -- Petr^2 Spacek From mkosek at redhat.com Thu Jun 20 07:35:50 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 20 Jun 2013 09:35:50 +0200 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <51C2AF68.3020606@redhat.com> References: <1290988309.4979837.1371653165405.JavaMail.root@redhat.com> <51C1D8BF.8070809@redhat.com> <51C1D9C9.7090002@redhat.com> <51C1DA1A.6040800@redhat.com> <51C1DC78.5020209@redhat.com> <20130619164601.GM24492@redhat.com> <51C1E157.4090308@redhat.com> <20130619165652.GA10478@redhat.com> <51C1F34C.5000805@redhat.com> <51C1F8D7.3070109@redhat.com> <20130619185656.GC10478@redhat.com> <51C2AF68.3020606@redhat.com> Message-ID: <51C2B0D6.1020607@redhat.com> On 06/20/2013 09:29 AM, Petr Spacek wrote: > On 19.6.2013 20:56, Alexander Bokovoy wrote: >> On Wed, 19 Jun 2013, Rob Crittenden wrote: >>> Tomas Babej wrote: >>>> [big snip] >>>> >>>> Providing new version which should address mentioned issues: >>>> - advice plugins now inherit directly from Plugin, initial approach >>>> via Method class was abandoned >>>> - new Namespace api.Advice collects all the advice plugins >>>> - tool renamed to ipa-advise to express a more general use case >>>> >>>> Additional improvements: >>>> - keywords are now generated out of Advice class's name, where >>>> underscores are replaced by hyphens >>>> - rewritten the example plugin in the docs, and provided more >>>> information there >>>> - instead of --setup option to provide configuration, ipa-advise >>>> takes one positional argument >>>> - renamed to ipa-advise >>>> >>>> Concerns: >>>> - man page might need more improvements >>>> >>>> I'll craft a design page for plugin authors, might be useful, even if >>>> the info is in the package docs. >>>> >>>> ----------------------------------------------- >>>> Here's a little preview: >>>> >>>> [tbabej at vm-001 ~]$ sudo ipa-advise fedora-authconfig >>>> ------------------------------------------------------------------------------------------------ >>>> >>>> >>>> >>>> Authconfig instructions for configuring Fedora 18/19 client with IPA >>>> server without use of SSSD. >>>> ------------------------------------------------------------------------------------------------ >>>> >>>> >>>> >>>> /sbin/authconfig --enableldap --ldapserver=vm-001.idm.com >>>> --enablerfc2307bis --enablekrb5 >>>> >>>> [tbabej at vm-001 ~]$ sudo ipa-advise fedora-authconfig4 >>>> invalid 'setup': No instructions are available for 'fedora_authconfig4'. >>>> See the list of available configuration advices using the --list option. >>>> >>>> [tbabej at vm-001 ~]$ sudo ipa-advise >>>> ------------------------- >>>> List of available advices >>>> ------------------------- >>>> fedora-authconfig : Authconfig instructions for configuring Fedora >>>> 18/19 client with IPA server without use of SSSD. >>> >>> If it's just providing advise why does it need root access? Or is it >>> expected to provide advise based on current configuration? >> Exactly. Getting ranges, configured trusts, etc. Not all of that >> information may be available under non-privileged account, especially if >> somebody would decide to plug in advices for backup or CA >> handling/configuration of advanced features. > > I think that ipa-advise should not require root access *implicitly*. It would > prevent lower-level admins from ipa-advise tool. > > IMHO plugins should try to get required information and print an 'Insufficient > access rights, try it again as root/admin' error when appropriate. > > As a result, basic 'advices' (like recommended client configuration) will be > accessible anybody and special 'advices' (something related to AD trusts etc.) > will be accessible only to admins. +1 I think the reason why Tomas did it as root was that he can that autobind to the DS. But he could easily operate in 2 modes, similarly to ipa-ldap-updater and simply just auth wuth GSSAPI when he is not logged as a root. Martin From mkosek at redhat.com Thu Jun 20 10:21:27 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 20 Jun 2013 12:21:27 +0200 Subject: [Freeipa-devel] [PATCH] Permit reads to ipatokenRadiusProxyUser objects In-Reply-To: <1371580050.23980.20.camel@localhost.localdomain> References: <1371580050.23980.20.camel@localhost.localdomain> Message-ID: <51C2D7A7.5070006@redhat.com> On 06/18/2013 08:27 PM, Nathaniel McCallum wrote: > Patch attached. > Hello Nathaniel, Thanks for the patch! I have just few general procedural comments with submitting patch: 1. As you are doing a work on an upstream ticket, please assign the upstream Trac ticket to yourself and accept it. When the patch is sent to the list, you should also mark the ticket as "patch sent". 2. Please follow our patch format: - https://fedorahosted.org/freeipa/wiki/PatchFormat This is just a short excerpt of our Development process: http://www.freeipa.org/page/Contribute#Development_Process Thank you, Martin From mkosek at redhat.com Thu Jun 20 10:24:44 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 20 Jun 2013 12:24:44 +0200 Subject: [Freeipa-devel] [PATCH] 0034 Improve handling of options in ipa-client-install In-Reply-To: <51B05902.8080902@redhat.com> References: <51AF47CC.5020709@redhat.com> <51B05902.8080902@redhat.com> Message-ID: <51C2D86C.1000004@redhat.com> On 06/06/2013 11:40 AM, Tomas Babej wrote: > On 06/05/2013 04:14 PM, Ana Krivokapic wrote: >> Hello, >> >> The attached patch should improve handling of client re-enrollment >> related options of ipa-client-install. >> >> https://fedorahosted.org/freeipa/ticket/3686 >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > ACK > > Tomas Pushed to master, ipa-3-2. Martin From tbabej at redhat.com Thu Jun 20 10:27:47 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 20 Jun 2013 12:27:47 +0200 Subject: [Freeipa-devel] [PATCH 0074] Do not redirect ipa/crl to HTTPS Message-ID: <51C2D923.5010906@redhat.com> Hi, this fixes https://fedorahosted.org/freeipa/ticket/3713 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0074-Do-not-redirect-ipa-crl-to-HTTPS.patch Type: text/x-patch Size: 1028 bytes Desc: not available URL: From tbabej at redhat.com Thu Jun 20 10:28:36 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 20 Jun 2013 12:28:36 +0200 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <51C2B0D6.1020607@redhat.com> References: <1290988309.4979837.1371653165405.JavaMail.root@redhat.com> <51C1D8BF.8070809@redhat.com> <51C1D9C9.7090002@redhat.com> <51C1DA1A.6040800@redhat.com> <51C1DC78.5020209@redhat.com> <20130619164601.GM24492@redhat.com> <51C1E157.4090308@redhat.com> <20130619165652.GA10478@redhat.com> <51C1F34C.5000805@redhat.com> <51C1F8D7.3070109@redhat.com> <20130619185656.GC10478@redhat.com> <51C2AF68.3020606@redhat.com> <51C2B0D6.1020607@redhat.com> Message-ID: <51C2D954.1030207@redhat.com> [snip] On 06/19/2013 08:58 PM, Alexander Bokovoy wrote: > As the output is almost usable for cut&paste to run on client > machines, may be prefix the description/instructions with #? [snip] > +1 > > I think the reason why Tomas did it as root was that he can that autobind to > the DS. But he could easily operate in 2 modes, similarly to ipa-ldap-updater > and simply just auth wuth GSSAPI when he is not logged as a root. > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Providing new version: - no longer requires root access defaultly - headers are printed out as comments Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0072-3-Provide-ipa-advise-tool.patch Type: text/x-patch Size: 18973 bytes Desc: not available URL: From mkosek at redhat.com Thu Jun 20 10:32:37 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 20 Jun 2013 12:32:37 +0200 Subject: [Freeipa-devel] [PATCH 0074] Do not redirect ipa/crl to HTTPS In-Reply-To: <51C2D923.5010906@redhat.com> References: <51C2D923.5010906@redhat.com> Message-ID: <51C2DA45.2060605@redhat.com> On 06/20/2013 12:27 PM, Tomas Babej wrote: > Hi, > > this fixes https://fedorahosted.org/freeipa/ticket/3713 > > Tomas > NACK. You also need to bump VERSION in the file, otherwise the change won't be applied to upgrades. Martin From tbabej at redhat.com Thu Jun 20 10:35:53 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 20 Jun 2013 12:35:53 +0200 Subject: [Freeipa-devel] [PATCH 0074] Do not redirect ipa/crl to HTTPS In-Reply-To: <51C2DA45.2060605@redhat.com> References: <51C2D923.5010906@redhat.com> <51C2DA45.2060605@redhat.com> Message-ID: <51C2DB09.5030502@redhat.com> On 06/20/2013 12:32 PM, Martin Kosek wrote: > On 06/20/2013 12:27 PM, Tomas Babej wrote: >> Hi, >> >> this fixes https://fedorahosted.org/freeipa/ticket/3713 >> >> Tomas >> > NACK. You also need to bump VERSION in the file, otherwise the change won't be > applied to upgrades. > > Martin Fixed. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0074-2-not-redirect-ipa-crl-to-HTTPS.patch Type: text/x-patch Size: 1148 bytes Desc: not available URL: From jcholast at redhat.com Thu Jun 20 10:52:40 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 20 Jun 2013 12:52:40 +0200 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <51C2D954.1030207@redhat.com> References: <1290988309.4979837.1371653165405.JavaMail.root@redhat.com> <51C1D8BF.8070809@redhat.com> <51C1D9C9.7090002@redhat.com> <51C1DA1A.6040800@redhat.com> <51C1DC78.5020209@redhat.com> <20130619164601.GM24492@redhat.com> <51C1E157.4090308@redhat.com> <20130619165652.GA10478@redhat.com> <51C1F34C.5000805@redhat.com> <51C1F8D7.3070109@redhat.com> <20130619185656.GC10478@redhat.com> <51C2AF68.3020606@redhat.com> <51C2B0D6.1020607@redhat.com> <51C2D954.1030207@redhat.com> Message-ID: <51C2DEF8.1040400@redhat.com> On 20.6.2013 12:28, Tomas Babej wrote: > Providing new version: > - no longer requires root access defaultly > - headers are printed out as comments > > Tomas > You still have reference(s) to previous names of the script in the patch: + """ + Base class for advices, plugins for ipa-config-advice. + """ Is the --list option absolutely necessary? If I read your code correctly, the list of advices is also returned when you run ipa-advise without arguments. Honza -- Jan Cholasta From tbabej at redhat.com Thu Jun 20 10:56:53 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 20 Jun 2013 12:56:53 +0200 Subject: [Freeipa-devel] [PATCH 0067] Add --use-posix option that forces trusted range type In-Reply-To: <51BF0247.4040604@redhat.com> References: <51B05207.4010100@redhat.com> <51BF0247.4040604@redhat.com> Message-ID: <51C2DFF5.8040608@redhat.com> On 06/17/2013 02:34 PM, Ana Krivokapic wrote: > On 06/06/2013 11:10 AM, Tomas Babej wrote: >> Hi, >> >> Adds --use-posix option to ipa trust-add command. It takes two >> allowed values: >> 'yes' : the 'ipa-ad-trust-posix' range type is enforced >> 'no' : the 'ipa-ad-trust' range type is enforced >> >> When --use-posix option is not specified, the range type should be >> determined by ID range discovery. >> >> https://fedorahosted.org/freeipa/ticket/3650 >> >> Tomas >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > The patch works nicely, but I have a few comments: > > 1) You added a new option to the API, but you forgot to bump the > IPA_API_VERSION_MINOR in the VERSION file. > > 2) Typo in commit message: "shold" instead of "should". > > 3) This construct: > > + if range_type is not None: > + if range_type != old_range_type: > > can be replaced with a more readable variant which also avoids nested ifs: > > + if range_type and range_type != old_range_type: > All fixed. > 4) Some unit tests to cover the behavior of the newly added option > would be nice. This is not doable at the moment, we have no unit test framework to test the trust-add command. > -- > Regards, > > Ana Krivokapic > Associate Software Engineer > FreeIPA team > Red Hat Inc. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0067-2-use-posix-option-that-forces-trusted-range-type.patch Type: text/x-patch Size: 5756 bytes Desc: not available URL: From mkosek at redhat.com Thu Jun 20 10:57:59 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 20 Jun 2013 12:57:59 +0200 Subject: [Freeipa-devel] [PATCH 0074] Do not redirect ipa/crl to HTTPS In-Reply-To: <51C2DB09.5030502@redhat.com> References: <51C2D923.5010906@redhat.com> <51C2DA45.2060605@redhat.com> <51C2DB09.5030502@redhat.com> Message-ID: <51C2E037.6080908@redhat.com> On 06/20/2013 12:35 PM, Tomas Babej wrote: > On 06/20/2013 12:32 PM, Martin Kosek wrote: >> On 06/20/2013 12:27 PM, Tomas Babej wrote: >>> Hi, >>> >>> this fixes https://fedorahosted.org/freeipa/ticket/3713 >>> >>> Tomas >>> >> NACK. You also need to bump VERSION in the file, otherwise the change won't be >> applied to upgrades. >> >> Martin > > Fixed. > > Tomas ACK. Pushed to master, ipa-3-2. Please just note I found a related SELinux issue with FreeIPA 3.3 development release. But this is not caused by your patch. Thanks, Martin From pspacek at redhat.com Thu Jun 20 12:30:33 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 20 Jun 2013 14:30:33 +0200 Subject: [Freeipa-devel] DNSSEC support design considerations: migration to RBTDB In-Reply-To: <1369319538.2769.24.camel@willson.li.ssimo.org> References: <51924269.8020000@redhat.com> <94125227.1971889.1368606594501.JavaMail.root@redhat.com> <5193A598.4050805@redhat.com> <1369051654.6162.12.camel@willson.li.ssimo.org> <519BA195.9050504@redhat.com> <1369161023.23339.20.camel@willson.li.ssimo.org> <519CDDBA.1010500@redhat.com> <1369252720.2769.23.camel@willson.li.ssimo.org> <519E0D09.3010108@redhat.com> <1369319538.2769.24.camel@willson.li.ssimo.org> Message-ID: <51C2F5E9.10109@redhat.com> Hello, On 23.5.2013 16:32, Simo Sorce wrote: > On Thu, 2013-05-23 at 14:35 +0200, Petr Spacek wrote: >> It looks that we agree on nearly all points (I apologize if >> overlooked >> something). I will prepare a design document for transition to RBTDB >> and then >> another design document for DNSSEC implementation. The current version of the design is available at: https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/RBTDB There are several questions inside (search for text "Question", it should find all of them). I would like to get your opinion about the problems. Note that 389 DS team decided to implement RFC 4533 (syncrepl), so persistent search is definitely obsolete and we can do synchronization in some clever way. -- Petr^2 Spacek From tbabej at redhat.com Thu Jun 20 12:37:09 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 20 Jun 2013 14:37:09 +0200 Subject: [Freeipa-devel] [PATCH] 0037 Do not display traceback to user In-Reply-To: <51BF0AF6.1050309@redhat.com> References: <51BF0AF6.1050309@redhat.com> Message-ID: <51C2F775.4060203@redhat.com> On 06/17/2013 03:11 PM, Ana Krivokapic wrote: > Hello, > > Logging tracebacks at the INFO level caused them to be displayed to user on the > command line. Change the log level to DEBUG, so that tracebacks are not visible > to user. > > https://fedorahosted.org/freeipa/ticket/3704 > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Thu Jun 20 13:12:26 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 20 Jun 2013 15:12:26 +0200 Subject: [Freeipa-devel] [PATCH 0165] Fix crash caused by race-condition between shutdown and update processing Message-ID: <51C2FFBA.5060505@redhat.com> Hello, Fix crash caused by race-condition between shutdown and update processing. Variable 'name' was uninitialized when manager_get_ldap_instance() returned ISC_R_NOTFOUND. The successive call to dns_name_dynamic() caused the crash. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0165-Fix-crash-caused-by-race-condition-between-shutdown-.patch Type: text/x-patch Size: 1312 bytes Desc: not available URL: From pspacek at redhat.com Thu Jun 20 13:20:51 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 20 Jun 2013 15:20:51 +0200 Subject: [Freeipa-devel] [PATCH 0166] Fix minor coding style issue in update_config() Message-ID: <51C301B3.4050909@redhat.com> Hello, Fix minor coding style issue in update_config(). -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0166-Fix-minor-coding-style-issue-in-update_config.patch Type: text/x-patch Size: 957 bytes Desc: not available URL: From rcritten at redhat.com Thu Jun 20 13:27:58 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 20 Jun 2013 09:27:58 -0400 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <51C2B0D6.1020607@redhat.com> References: <1290988309.4979837.1371653165405.JavaMail.root@redhat.com> <51C1D8BF.8070809@redhat.com> <51C1D9C9.7090002@redhat.com> <51C1DA1A.6040800@redhat.com> <51C1DC78.5020209@redhat.com> <20130619164601.GM24492@redhat.com> <51C1E157.4090308@redhat.com> <20130619165652.GA10478@redhat.com> <51C1F34C.5000805@redhat.com> <51C1F8D7.3070109@redhat.com> <20130619185656.GC10478@redhat.com> <51C2AF68.3020606@redhat.com> <51C2B0D6.1020607@redhat.com> Message-ID: <51C3035E.4090204@redhat.com> Martin Kosek wrote: > On 06/20/2013 09:29 AM, Petr Spacek wrote: >> On 19.6.2013 20:56, Alexander Bokovoy wrote: >>> On Wed, 19 Jun 2013, Rob Crittenden wrote: >>>> Tomas Babej wrote: >>>>> [big snip] >>>>> >>>>> Providing new version which should address mentioned issues: >>>>> - advice plugins now inherit directly from Plugin, initial approach >>>>> via Method class was abandoned >>>>> - new Namespace api.Advice collects all the advice plugins >>>>> - tool renamed to ipa-advise to express a more general use case >>>>> >>>>> Additional improvements: >>>>> - keywords are now generated out of Advice class's name, where >>>>> underscores are replaced by hyphens >>>>> - rewritten the example plugin in the docs, and provided more >>>>> information there >>>>> - instead of --setup option to provide configuration, ipa-advise >>>>> takes one positional argument >>>>> - renamed to ipa-advise >>>>> >>>>> Concerns: >>>>> - man page might need more improvements >>>>> >>>>> I'll craft a design page for plugin authors, might be useful, even if >>>>> the info is in the package docs. >>>>> >>>>> ----------------------------------------------- >>>>> Here's a little preview: >>>>> >>>>> [tbabej at vm-001 ~]$ sudo ipa-advise fedora-authconfig >>>>> ------------------------------------------------------------------------------------------------ >>>>> >>>>> >>>>> >>>>> Authconfig instructions for configuring Fedora 18/19 client with IPA >>>>> server without use of SSSD. >>>>> ------------------------------------------------------------------------------------------------ >>>>> >>>>> >>>>> >>>>> /sbin/authconfig --enableldap --ldapserver=vm-001.idm.com >>>>> --enablerfc2307bis --enablekrb5 >>>>> >>>>> [tbabej at vm-001 ~]$ sudo ipa-advise fedora-authconfig4 >>>>> invalid 'setup': No instructions are available for 'fedora_authconfig4'. >>>>> See the list of available configuration advices using the --list option. >>>>> >>>>> [tbabej at vm-001 ~]$ sudo ipa-advise >>>>> ------------------------- >>>>> List of available advices >>>>> ------------------------- >>>>> fedora-authconfig : Authconfig instructions for configuring Fedora >>>>> 18/19 client with IPA server without use of SSSD. >>>> >>>> If it's just providing advise why does it need root access? Or is it >>>> expected to provide advise based on current configuration? >>> Exactly. Getting ranges, configured trusts, etc. Not all of that >>> information may be available under non-privileged account, especially if >>> somebody would decide to plug in advices for backup or CA >>> handling/configuration of advanced features. >> >> I think that ipa-advise should not require root access *implicitly*. It would >> prevent lower-level admins from ipa-advise tool. >> >> IMHO plugins should try to get required information and print an 'Insufficient >> access rights, try it again as root/admin' error when appropriate. >> >> As a result, basic 'advices' (like recommended client configuration) will be >> accessible anybody and special 'advices' (something related to AD trusts etc.) >> will be accessible only to admins. > > +1 > > I think the reason why Tomas did it as root was that he can that autobind to > the DS. But he could easily operate in 2 modes, similarly to ipa-ldap-updater > and simply just auth wuth GSSAPI when he is not logged as a root. Alternatively, add a requires_root on the plugin level so that some plugins require root, others do not. rob From akrivoka at redhat.com Thu Jun 20 15:13:35 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 20 Jun 2013 17:13:35 +0200 Subject: [Freeipa-devel] [PATCHES] 0039-0040 systemd ipactl fixes Message-ID: <51C31C1F.2040307@redhat.com> Hello, Attached patches fix systemd and ipactl related bugs: https://fedorahosted.org/freeipa/ticket/3730 https://fedorahosted.org/freeipa/ticket/3729 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0039-Use-correct-DS-instance-in-ipactl-status.patch Type: text/x-patch Size: 3272 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0040-Avoid-systemd-service-deadlock-during-shutdown.patch Type: text/x-patch Size: 2331 bytes Desc: not available URL: From tbabej at redhat.com Thu Jun 20 15:15:24 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 20 Jun 2013 17:15:24 +0200 Subject: [Freeipa-devel] [PATCH 0075] Change group ownership of CRL publish directory Message-ID: <51C31C8C.2010200@redhat.com> Hi, Spec file modified so that /var/lib/ipa/pki-ca/publish/ is owned by pkiuser group. https://fedorahosted.org/freeipa/ticket/3727 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0075-Change-group-ownership-of-CRL-publish-directory.patch Type: text/x-patch Size: 1113 bytes Desc: not available URL: From akrivoka at redhat.com Thu Jun 20 15:28:11 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 20 Jun 2013 17:28:11 +0200 Subject: [Freeipa-devel] [PATCH 0067] Add --use-posix option that forces trusted range type In-Reply-To: <51C2DFF5.8040608@redhat.com> References: <51B05207.4010100@redhat.com> <51BF0247.4040604@redhat.com> <51C2DFF5.8040608@redhat.com> Message-ID: <51C31F8B.20200@redhat.com> On 06/20/2013 12:56 PM, Tomas Babej wrote: > On 06/17/2013 02:34 PM, Ana Krivokapic wrote: >> On 06/06/2013 11:10 AM, Tomas Babej wrote: >>> Hi, >>> >>> Adds --use-posix option to ipa trust-add command. It takes two >>> allowed values: >>> 'yes' : the 'ipa-ad-trust-posix' range type is enforced >>> 'no' : the 'ipa-ad-trust' range type is enforced >>> >>> When --use-posix option is not specified, the range type should be >>> determined by ID range discovery. >>> >>> https://fedorahosted.org/freeipa/ticket/3650 >>> >>> Tomas >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> The patch works nicely, but I have a few comments: >> >> 1) You added a new option to the API, but you forgot to bump the >> IPA_API_VERSION_MINOR in the VERSION file. >> >> 2) Typo in commit message: "shold" instead of "should". >> >> 3) This construct: >> >> + if range_type is not None: >> + if range_type != old_range_type: >> >> can be replaced with a more readable variant which also avoids nested ifs: >> >> + if range_type and range_type != old_range_type: >> > > All fixed. > >> 4) Some unit tests to cover the behavior of the newly added option would be nice. > > This is not doable at the moment, we have no unit test framework to test the > trust-add command. > >> -- >> Regards, >> >> Ana Krivokapic >> Associate Software Engineer >> FreeIPA team >> Red Hat Inc. >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Tomas ACK -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu Jun 20 15:33:53 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 20 Jun 2013 17:33:53 +0200 Subject: [Freeipa-devel] [PATCH 0075] Change group ownership of CRL publish directory In-Reply-To: <51C31C8C.2010200@redhat.com> References: <51C31C8C.2010200@redhat.com> Message-ID: <51C320E1.4040303@redhat.com> On 06/20/2013 05:15 PM, Tomas Babej wrote: > Hi, > > Spec file modified so that /var/lib/ipa/pki-ca/publish/ is owned > by pkiuser group. > > https://fedorahosted.org/freeipa/ticket/3727 > > Tomas > NACK. This won't fly. pkiuser is created by FreeIPA when server is installed, thus you cannot just simply change ownership in our spec file because in the time when package is installed or updated, pkiuser may not exist. I think you need to delete the %attr from spec file and set the correct ownership during ipa-{server,ca}-install. When CA is configured, we should also probably let ipa-upgradeconfig check this directory and amend when necessary (to fix affected IPA CA instances). Martin From simo at redhat.com Thu Jun 20 15:44:08 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 20 Jun 2013 11:44:08 -0400 Subject: [Freeipa-devel] [PATCH 0075] Change group ownership of CRL publish directory In-Reply-To: <51C320E1.4040303@redhat.com> References: <51C31C8C.2010200@redhat.com> <51C320E1.4040303@redhat.com> Message-ID: <1371743048.17111.61.camel@willson.li.ssimo.org> On Thu, 2013-06-20 at 17:33 +0200, Martin Kosek wrote: > On 06/20/2013 05:15 PM, Tomas Babej wrote: > > Hi, > > > > Spec file modified so that /var/lib/ipa/pki-ca/publish/ is owned > > by pkiuser group. > > > > https://fedorahosted.org/freeipa/ticket/3727 > > > > Tomas > > > > NACK. This won't fly. pkiuser is created by FreeIPA when server is installed, > thus you cannot just simply change ownership in our spec file because in the > time when package is installed or updated, pkiuser may not exist. > > I think you need to delete the %attr from spec file and set the correct > ownership during ipa-{server,ca}-install. When CA is configured, we should also > probably let ipa-upgradeconfig check this directory and amend when necessary > (to fix affected IPA CA instances). Probably even better to not create the directory via rpm at all, but make ipa-ca-install create it and remove it when --uninstall is run. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Thu Jun 20 15:47:55 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 20 Jun 2013 17:47:55 +0200 Subject: [Freeipa-devel] [PATCH 0075] Change group ownership of CRL publish directory In-Reply-To: <1371743048.17111.61.camel@willson.li.ssimo.org> References: <51C31C8C.2010200@redhat.com> <51C320E1.4040303@redhat.com> <1371743048.17111.61.camel@willson.li.ssimo.org> Message-ID: <51C3242B.4070604@redhat.com> On 06/20/2013 05:44 PM, Simo Sorce wrote: > On Thu, 2013-06-20 at 17:33 +0200, Martin Kosek wrote: >> On 06/20/2013 05:15 PM, Tomas Babej wrote: >>> Hi, >>> >>> Spec file modified so that /var/lib/ipa/pki-ca/publish/ is owned >>> by pkiuser group. >>> >>> https://fedorahosted.org/freeipa/ticket/3727 >>> >>> Tomas >>> >> >> NACK. This won't fly. pkiuser is created by FreeIPA when server is installed, >> thus you cannot just simply change ownership in our spec file because in the >> time when package is installed or updated, pkiuser may not exist. >> >> I think you need to delete the %attr from spec file and set the correct >> ownership during ipa-{server,ca}-install. When CA is configured, we should also >> probably let ipa-upgradeconfig check this directory and amend when necessary >> (to fix affected IPA CA instances). > > Probably even better to not create the directory via rpm at all, but > make ipa-ca-install create it and remove it when --uninstall is run. > > Simo. This could also work, sure. Could we then at least mark this directory in our spec file as %ghost? So that "rpm -qf /var/lib/ipa/pki-ca/publish/" gives some information? Martin From simo at redhat.com Thu Jun 20 16:00:27 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 20 Jun 2013 12:00:27 -0400 Subject: [Freeipa-devel] [PATCH 0075] Change group ownership of CRL publish directory In-Reply-To: <51C3242B.4070604@redhat.com> References: <51C31C8C.2010200@redhat.com> <51C320E1.4040303@redhat.com> <1371743048.17111.61.camel@willson.li.ssimo.org> <51C3242B.4070604@redhat.com> Message-ID: <1371744027.17111.69.camel@willson.li.ssimo.org> On Thu, 2013-06-20 at 17:47 +0200, Martin Kosek wrote: > On 06/20/2013 05:44 PM, Simo Sorce wrote: > > On Thu, 2013-06-20 at 17:33 +0200, Martin Kosek wrote: > >> On 06/20/2013 05:15 PM, Tomas Babej wrote: > >>> Hi, > >>> > >>> Spec file modified so that /var/lib/ipa/pki-ca/publish/ is owned > >>> by pkiuser group. > >>> > >>> https://fedorahosted.org/freeipa/ticket/3727 > >>> > >>> Tomas > >>> > >> > >> NACK. This won't fly. pkiuser is created by FreeIPA when server is installed, > >> thus you cannot just simply change ownership in our spec file because in the > >> time when package is installed or updated, pkiuser may not exist. > >> > >> I think you need to delete the %attr from spec file and set the correct > >> ownership during ipa-{server,ca}-install. When CA is configured, we should also > >> probably let ipa-upgradeconfig check this directory and amend when necessary > >> (to fix affected IPA CA instances). > > > > Probably even better to not create the directory via rpm at all, but > > make ipa-ca-install create it and remove it when --uninstall is run. > > > > Simo. > > This could also work, sure. Could we then at least mark this directory in our > spec file as %ghost? So that "rpm -qf /var/lib/ipa/pki-ca/publish/" gives some > information? I guess so. Simo. -- Simo Sorce * Red Hat, Inc * New York From akrivoka at redhat.com Thu Jun 20 16:11:40 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 20 Jun 2013 18:11:40 +0200 Subject: [Freeipa-devel] [PATCH] 421 Fix default value selection in radio widget In-Reply-To: <51C098D7.4030105@redhat.com> References: <51C098D7.4030105@redhat.com> Message-ID: <51C329BC.5010804@redhat.com> On 06/18/2013 07:28 PM, Petr Vobornik wrote: > Fix default value selection in radio widget > > https://fedorahosted.org/freeipa/ticket/3718 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel The web UI now displays 'Forward policy' as 'Forward first' when no policy is active (e.g. in case of empty Global DNS Configuration). Do we really want to have a default value for this particular radio button? Shouldn't it be unselected as default? -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Jun 20 17:41:02 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 20 Jun 2013 13:41:02 -0400 Subject: [Freeipa-devel] [PATCH 0075] Change group ownership of CRL publish directory In-Reply-To: <1371743048.17111.61.camel@willson.li.ssimo.org> References: <51C31C8C.2010200@redhat.com> <51C320E1.4040303@redhat.com> <1371743048.17111.61.camel@willson.li.ssimo.org> Message-ID: <51C33EAE.4010500@redhat.com> Simo Sorce wrote: > On Thu, 2013-06-20 at 17:33 +0200, Martin Kosek wrote: >> On 06/20/2013 05:15 PM, Tomas Babej wrote: >>> Hi, >>> >>> Spec file modified so that /var/lib/ipa/pki-ca/publish/ is owned >>> by pkiuser group. >>> >>> https://fedorahosted.org/freeipa/ticket/3727 >>> >>> Tomas >>> >> >> NACK. This won't fly. pkiuser is created by FreeIPA when server is installed, >> thus you cannot just simply change ownership in our spec file because in the >> time when package is installed or updated, pkiuser may not exist. >> >> I think you need to delete the %attr from spec file and set the correct >> ownership during ipa-{server,ca}-install. When CA is configured, we should also >> probably let ipa-upgradeconfig check this directory and amend when necessary >> (to fix affected IPA CA instances). > > Probably even better to not create the directory via rpm at all, but > make ipa-ca-install create it and remove it when --uninstall is run. > > Simo. It should be ghosted at a minimum to show what package owns it. rob From tbabej at redhat.com Fri Jun 21 07:16:11 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 21 Jun 2013 09:16:11 +0200 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <51C2DEF8.1040400@redhat.com> References: <1290988309.4979837.1371653165405.JavaMail.root@redhat.com> <51C1D8BF.8070809@redhat.com> <51C1D9C9.7090002@redhat.com> <51C1DA1A.6040800@redhat.com> <51C1DC78.5020209@redhat.com> <20130619164601.GM24492@redhat.com> <51C1E157.4090308@redhat.com> <20130619165652.GA10478@redhat.com> <51C1F34C.5000805@redhat.com> <51C1F8D7.3070109@redhat.com> <20130619185656.GC10478@redhat.com> <51C2AF68.3020606@redhat.com> <51C2B0D6.1020607@redhat.com> <51C2D954.1030207@redhat.com> <51C2DEF8.1040400@redhat.com> Message-ID: <51C3FDBB.7060902@redhat.com> On 06/20/2013 12:52 PM, Jan Cholasta wrote: > On 20.6.2013 12:28, Tomas Babej wrote: >> Providing new version: >> - no longer requires root access defaultly >> - headers are printed out as comments >> >> Tomas >> > > You still have reference(s) to previous names of the script in the patch: > > + """ > + Base class for advices, plugins for ipa-config-advice. > + """ > Fixed. > Is the --list option absolutely necessary? If I read your code > correctly, the list of advices is also returned when you run > ipa-advise without arguments. > > Honza > New version: - provides require_root setting for plugins - options --list removed, man pages altered accordingly I'm also thinking about propagating the --verbose, etc. options provided by default by AdminTool down to plugin level so that plugin authors can make use of them. What do you think? Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0072-4-Provide-ipa-advise-tool.patch Type: text/x-patch Size: 19127 bytes Desc: not available URL: From jcholast at redhat.com Fri Jun 21 07:32:18 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 21 Jun 2013 09:32:18 +0200 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <51C3FDBB.7060902@redhat.com> References: <1290988309.4979837.1371653165405.JavaMail.root@redhat.com> <51C1D8BF.8070809@redhat.com> <51C1D9C9.7090002@redhat.com> <51C1DA1A.6040800@redhat.com> <51C1DC78.5020209@redhat.com> <20130619164601.GM24492@redhat.com> <51C1E157.4090308@redhat.com> <20130619165652.GA10478@redhat.com> <51C1F34C.5000805@redhat.com> <51C1F8D7.3070109@redhat.com> <20130619185656.GC10478@redhat.com> <51C2AF68.3020606@redhat.com> <51C2B0D6.1020607@redhat.com> <51C2D954.1030207@redhat.com> <51C2DEF8.1040400@redhat.com> <51C3FDBB.7060902@redhat.com> Message-ID: <51C40182.9000306@redhat.com> On 21.6.2013 09:16, Tomas Babej wrote: > I'm also thinking about propagating the --verbose, etc. options provided > by default by AdminTool down to plugin level so that plugin authors can > make use of them. What do you think? +1 -- Jan Cholasta From pvoborni at redhat.com Fri Jun 21 08:56:16 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 21 Jun 2013 10:56:16 +0200 Subject: [Freeipa-devel] Web UI integration tests Message-ID: <51C41530.7000300@redhat.com> Sending an initial implementation of Web UI integration tests. The effort is documented at http://www.freeipa.org/page/Web_UI_Integration_Tests . The coverage is not complete but rather basic. Sending it now as this is ongoing task. Currently it tries to open all facets and dialogs and perform add,mod,find,delete,add/remove associations for every entity except trusts (to be implemented). First two attached patches are changing Web UI to be little more test-friendly - they add some names to element and such. Tests are in the last patch. https://fedorahosted.org/freeipa/ticket/3744 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0422-Better-automated-test-support.patch Type: text/x-patch Size: 5664 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0423-Fix-container-element-in-adder-dialogs.patch Type: text/x-patch Size: 2757 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0424-Upstream-Web-UI-tests.patch Type: text/x-patch Size: 146127 bytes Desc: not available URL: From tbabej at redhat.com Fri Jun 21 09:45:14 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 21 Jun 2013 11:45:14 +0200 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <51C40182.9000306@redhat.com> References: <1290988309.4979837.1371653165405.JavaMail.root@redhat.com> <51C1D8BF.8070809@redhat.com> <51C1D9C9.7090002@redhat.com> <51C1DA1A.6040800@redhat.com> <51C1DC78.5020209@redhat.com> <20130619164601.GM24492@redhat.com> <51C1E157.4090308@redhat.com> <20130619165652.GA10478@redhat.com> <51C1F34C.5000805@redhat.com> <51C1F8D7.3070109@redhat.com> <20130619185656.GC10478@redhat.com> <51C2AF68.3020606@redhat.com> <51C2B0D6.1020607@redhat.com> <51C2D954.1030207@redhat.com> <51C2DEF8.1040400@redhat.com> <51C3FDBB.7060902@redhat.com> <51C40182.9000306@redhat.com> Message-ID: <51C420AA.4080007@redhat.com> On 06/21/2013 09:32 AM, Jan Cholasta wrote: > On 21.6.2013 09:16, Tomas Babej wrote: >> I'm also thinking about propagating the --verbose, etc. options provided >> by default by AdminTool down to plugin level so that plugin authors can >> make use of them. What do you think? > > +1 > Newly added features: - options propagated to plugins - made plugin content creation more comfortable, now 3 classes of output are available (debug, comment, command) Now pretty much everything that comes into my mind is addressed, so please have a look at the current implementation. Any suggestions welcome. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0072-5-Provide-ipa-advise-tool.patch Type: text/x-patch Size: 20594 bytes Desc: not available URL: From akrivoka at redhat.com Fri Jun 21 11:52:40 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 21 Jun 2013 13:52:40 +0200 Subject: [Freeipa-devel] [PATCH 0073] Remove support for IPA deployments with no persistent search In-Reply-To: <51B86955.6040905@redhat.com> References: <51B86955.6040905@redhat.com> Message-ID: <51C43E88.7000807@redhat.com> On 06/12/2013 02:28 PM, Tomas Babej wrote: > Hi, > > Drops the code from ipa-server-install, ipa-dns-install and the > BindInstance itself. Also changed ipa-upgradeconfig script so > that it does not set zone_refresh to 0 on upgrades, as the option > is deprecated, but rather removes it altogether. > > https://fedorahosted.org/freeipa/ticket/3632 > > Tomas > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel 1) ipa-server-install (with no DNS), followed by ipa-dns-install now fails, because you missed one reference to options.persistent_search in ipa-dns-install: if options.serial_autoincrement and not options.persistent_search: parser.error('persistent search feature is required for ' 'DNS SOA serial autoincrement') 2) I wonder if we can also remove the '--zone-notif' option from ipa-server-install and ipa-dns-install. It is already deprecated so maybe this is a good time to drop it altogether? 3) You can remove the 'persistant_search' attribute of the BindInstance class, and just hardcode the value to "yes" in the '__setup_sub_dict()' method. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Fri Jun 21 12:11:41 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 21 Jun 2013 14:11:41 +0200 Subject: [Freeipa-devel] [PATCH 0075] Change group ownership of CRL publish directory In-Reply-To: <1371744027.17111.69.camel@willson.li.ssimo.org> References: <51C31C8C.2010200@redhat.com> <51C320E1.4040303@redhat.com> <1371743048.17111.61.camel@willson.li.ssimo.org> <51C3242B.4070604@redhat.com> <1371744027.17111.69.camel@willson.li.ssimo.org> Message-ID: <51C442FD.2000009@redhat.com> On 06/20/2013 06:00 PM, Simo Sorce wrote: > On Thu, 2013-06-20 at 17:47 +0200, Martin Kosek wrote: >> On 06/20/2013 05:44 PM, Simo Sorce wrote: >>> On Thu, 2013-06-20 at 17:33 +0200, Martin Kosek wrote: >>>> On 06/20/2013 05:15 PM, Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> Spec file modified so that /var/lib/ipa/pki-ca/publish/ is owned >>>>> by pkiuser group. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3727 >>>>> >>>>> Tomas >>>>> >>>> NACK. This won't fly. pkiuser is created by FreeIPA when server is installed, >>>> thus you cannot just simply change ownership in our spec file because in the >>>> time when package is installed or updated, pkiuser may not exist. >>>> >>>> I think you need to delete the %attr from spec file and set the correct >>>> ownership during ipa-{server,ca}-install. When CA is configured, we should also >>>> probably let ipa-upgradeconfig check this directory and amend when necessary >>>> (to fix affected IPA CA instances). >>> Probably even better to not create the directory via rpm at all, but >>> make ipa-ca-install create it and remove it when --uninstall is run. >>> >>> Simo. >> This could also work, sure. Could we then at least mark this directory in our >> spec file as %ghost? So that "rpm -qf /var/lib/ipa/pki-ca/publish/" gives some >> information? > I guess so. > > Simo. > Updated version attached. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0075-2-group-ownership-of-CRL-publish-directory.patch Type: text/x-patch Size: 5314 bytes Desc: not available URL: From mkosek at redhat.com Fri Jun 21 12:15:25 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 21 Jun 2013 14:15:25 +0200 Subject: [Freeipa-devel] [PATCH 0075] Change group ownership of CRL publish directory In-Reply-To: <51C442FD.2000009@redhat.com> References: <51C31C8C.2010200@redhat.com> <51C320E1.4040303@redhat.com> <1371743048.17111.61.camel@willson.li.ssimo.org> <51C3242B.4070604@redhat.com> <1371744027.17111.69.camel@willson.li.ssimo.org> <51C442FD.2000009@redhat.com> Message-ID: <51C443DD.1090202@redhat.com> On 06/21/2013 02:11 PM, Tomas Babej wrote: > On 06/20/2013 06:00 PM, Simo Sorce wrote: >> On Thu, 2013-06-20 at 17:47 +0200, Martin Kosek wrote: >>> On 06/20/2013 05:44 PM, Simo Sorce wrote: >>>> On Thu, 2013-06-20 at 17:33 +0200, Martin Kosek wrote: >>>>> On 06/20/2013 05:15 PM, Tomas Babej wrote: >>>>>> Hi, >>>>>> >>>>>> Spec file modified so that /var/lib/ipa/pki-ca/publish/ is owned >>>>>> by pkiuser group. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3727 >>>>>> >>>>>> Tomas >>>>>> >>>>> NACK. This won't fly. pkiuser is created by FreeIPA when server is installed, >>>>> thus you cannot just simply change ownership in our spec file because in the >>>>> time when package is installed or updated, pkiuser may not exist. >>>>> >>>>> I think you need to delete the %attr from spec file and set the correct >>>>> ownership during ipa-{server,ca}-install. When CA is configured, we should >>>>> also >>>>> probably let ipa-upgradeconfig check this directory and amend when necessary >>>>> (to fix affected IPA CA instances). >>>> Probably even better to not create the directory via rpm at all, but >>>> make ipa-ca-install create it and remove it when --uninstall is run. >>>> >>>> Simo. >>> This could also work, sure. Could we then at least mark this directory in our >>> spec file as %ghost? So that "rpm -qf /var/lib/ipa/pki-ca/publish/" gives some >>> information? >> I guess so. >> >> Simo. >> > > Updated version attached. > > Tomas Looks good by reading (I did not test it), maybe just one nitpick: + root_logger.warning("Error while removing CRL publish " + "directory: %s" % str(e)) This should read: + root_logger.warning("Error while removing CRL publish " + "directory: %s", e) We do not need to format the string before it is really logged and we also do not need to convert it to "str" as we already requested the conversion to string by "%s". Martin From tbabej at redhat.com Fri Jun 21 12:18:55 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 21 Jun 2013 14:18:55 +0200 Subject: [Freeipa-devel] [PATCH 0075] Change group ownership of CRL publish directory In-Reply-To: <51C443DD.1090202@redhat.com> References: <51C31C8C.2010200@redhat.com> <51C320E1.4040303@redhat.com> <1371743048.17111.61.camel@willson.li.ssimo.org> <51C3242B.4070604@redhat.com> <1371744027.17111.69.camel@willson.li.ssimo.org> <51C442FD.2000009@redhat.com> <51C443DD.1090202@redhat.com> Message-ID: <51C444AF.3070709@redhat.com> On 06/21/2013 02:15 PM, Martin Kosek wrote: > On 06/21/2013 02:11 PM, Tomas Babej wrote: >> On 06/20/2013 06:00 PM, Simo Sorce wrote: >>> On Thu, 2013-06-20 at 17:47 +0200, Martin Kosek wrote: >>>> On 06/20/2013 05:44 PM, Simo Sorce wrote: >>>>> On Thu, 2013-06-20 at 17:33 +0200, Martin Kosek wrote: >>>>>> On 06/20/2013 05:15 PM, Tomas Babej wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Spec file modified so that /var/lib/ipa/pki-ca/publish/ is owned >>>>>>> by pkiuser group. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/3727 >>>>>>> >>>>>>> Tomas >>>>>>> >>>>>> NACK. This won't fly. pkiuser is created by FreeIPA when server is installed, >>>>>> thus you cannot just simply change ownership in our spec file because in the >>>>>> time when package is installed or updated, pkiuser may not exist. >>>>>> >>>>>> I think you need to delete the %attr from spec file and set the correct >>>>>> ownership during ipa-{server,ca}-install. When CA is configured, we should >>>>>> also >>>>>> probably let ipa-upgradeconfig check this directory and amend when necessary >>>>>> (to fix affected IPA CA instances). >>>>> Probably even better to not create the directory via rpm at all, but >>>>> make ipa-ca-install create it and remove it when --uninstall is run. >>>>> >>>>> Simo. >>>> This could also work, sure. Could we then at least mark this directory in our >>>> spec file as %ghost? So that "rpm -qf /var/lib/ipa/pki-ca/publish/" gives some >>>> information? >>> I guess so. >>> >>> Simo. >>> >> Updated version attached. >> >> Tomas > Looks good by reading (I did not test it), maybe just one nitpick: > > + root_logger.warning("Error while removing CRL publish " > + "directory: %s" % str(e)) > > This should read: > + root_logger.warning("Error while removing CRL publish " > + "directory: %s", e) > > We do not need to format the string before it is really logged and we also do > not need to convert it to "str" as we already requested the conversion to > string by "%s". > > Martin Fixed. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0075-3-group-ownership-of-CRL-publish-directory.patch Type: text/x-patch Size: 5309 bytes Desc: not available URL: From tbabej at redhat.com Fri Jun 21 12:39:22 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 21 Jun 2013 14:39:22 +0200 Subject: [Freeipa-devel] [PATCH 0030] Require rid-base and secondary-rid-base options in idrange-add when trust exists In-Reply-To: <51B8AAAA.2000701@redhat.com> References: <51A4C406.5000206@redhat.com> <51A8DF79.9070700@redhat.com> <51B09703.9080801@redhat.com> <51B72F80.4000902@redhat.com> <51B74A5A.2050903@redhat.com> <20130611162438.GS26689@redhat.com> <51B751A0.2070705@redhat.com> <20130611164457.GT26689@redhat.com> <51B8AAAA.2000701@redhat.com> Message-ID: <51C4497A.30306@redhat.com> On 06/12/2013 07:06 PM, Ana Krivokapic wrote: > On 06/11/2013 06:44 PM, Alexander Bokovoy wrote: >> On Tue, 11 Jun 2013, Martin Kosek wrote: >>>>> 2) Is the used ldapsearch really the best way to find out if Trust is >>>>> configured on a given master? Isn't a search in cn=masters,cn=ipa,... better? >>>>> Alexander? >>>> What would the search in cn=masters,cn=ipa,.. give? >>>> >>>> We can have multiple CIFS services per realm. However, only those in >>>> 'adtrust agents' group are the ones which are real DCs. And since >>>> membership in the group is not handled via framework or UI, it is clear >>>> indication that ipa-adtrust-install was run. >>> It would say if there as an appropriate service configured by >>> ipa-adtrust-install. In this case, >>> "cn=ADTRUST,cn=FQDN,cn=masters,cn=ipa,cn=etc,SUFFIX. I am asking because this >>> is a standard way in FreeIPA to ask for configured services. >>> >>> If that does not work for Trust, then your alternative way should be OK too. >> This would work for making sure that ipa-adtrust-install was run on a >> specific server. It will not work for making sure trusts are enabled >> but in this case we only need to know that we have configured the host >> to be a DC so your approach is fine. >> >> I'm fine to use this approach, somehow it slipped out of my view when we >> discussed it with Ana.. >> >> > I amended the name of the new command to 'adtrust_is_enabled'. I also simplified > the LDAP search used in the command, as suggested by Martin and Alexander. > > Updated patch is attached. > Can you please rebase the patch? I think tests -> ipatests change is the culprit here. Tomas From akrivoka at redhat.com Fri Jun 21 13:38:44 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 21 Jun 2013 15:38:44 +0200 Subject: [Freeipa-devel] [PATCH 0030] Require rid-base and secondary-rid-base options in idrange-add when trust exists In-Reply-To: <51C4497A.30306@redhat.com> References: <51A4C406.5000206@redhat.com> <51A8DF79.9070700@redhat.com> <51B09703.9080801@redhat.com> <51B72F80.4000902@redhat.com> <51B74A5A.2050903@redhat.com> <20130611162438.GS26689@redhat.com> <51B751A0.2070705@redhat.com> <20130611164457.GT26689@redhat.com> <51B8AAAA.2000701@redhat.com> <51C4497A.30306@redhat.com> Message-ID: <51C45764.6020701@redhat.com> On 06/21/2013 02:39 PM, Tomas Babej wrote: > On 06/12/2013 07:06 PM, Ana Krivokapic wrote: >> On 06/11/2013 06:44 PM, Alexander Bokovoy wrote: >>> On Tue, 11 Jun 2013, Martin Kosek wrote: >>>>>> 2) Is the used ldapsearch really the best way to find out if Trust is >>>>>> configured on a given master? Isn't a search in cn=masters,cn=ipa,... >>>>>> better? >>>>>> Alexander? >>>>> What would the search in cn=masters,cn=ipa,.. give? >>>>> >>>>> We can have multiple CIFS services per realm. However, only those in >>>>> 'adtrust agents' group are the ones which are real DCs. And since >>>>> membership in the group is not handled via framework or UI, it is clear >>>>> indication that ipa-adtrust-install was run. >>>> It would say if there as an appropriate service configured by >>>> ipa-adtrust-install. In this case, >>>> "cn=ADTRUST,cn=FQDN,cn=masters,cn=ipa,cn=etc,SUFFIX. I am asking because this >>>> is a standard way in FreeIPA to ask for configured services. >>>> >>>> If that does not work for Trust, then your alternative way should be OK too. >>> This would work for making sure that ipa-adtrust-install was run on a >>> specific server. It will not work for making sure trusts are enabled >>> but in this case we only need to know that we have configured the host >>> to be a DC so your approach is fine. >>> >>> I'm fine to use this approach, somehow it slipped out of my view when we >>> discussed it with Ana.. >>> >>> >> I amended the name of the new command to 'adtrust_is_enabled'. I also simplified >> the LDAP search used in the command, as suggested by Martin and Alexander. >> >> Updated patch is attached. >> > > Can you please rebase the patch? I think tests -> ipatests change is the > culprit here. > > Tomas Sure, rebased patch is attached. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0030-05-Require-rid-base-and-secondary-rid-base-in-idrange-a.patch Type: text/x-patch Size: 16202 bytes Desc: not available URL: From tbabej at redhat.com Fri Jun 21 13:59:25 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 21 Jun 2013 15:59:25 +0200 Subject: [Freeipa-devel] [PATCH 0030] Require rid-base and secondary-rid-base options in idrange-add when trust exists In-Reply-To: <51C45764.6020701@redhat.com> References: <51A4C406.5000206@redhat.com> <51A8DF79.9070700@redhat.com> <51B09703.9080801@redhat.com> <51B72F80.4000902@redhat.com> <51B74A5A.2050903@redhat.com> <20130611162438.GS26689@redhat.com> <51B751A0.2070705@redhat.com> <20130611164457.GT26689@redhat.com> <51B8AAAA.2000701@redhat.com> <51C4497A.30306@redhat.com> <51C45764.6020701@redhat.com> Message-ID: <51C45C3D.5090204@redhat.com> On 06/21/2013 03:38 PM, Ana Krivokapic wrote: > On 06/21/2013 02:39 PM, Tomas Babej wrote: >> On 06/12/2013 07:06 PM, Ana Krivokapic wrote: >>> On 06/11/2013 06:44 PM, Alexander Bokovoy wrote: >>>> On Tue, 11 Jun 2013, Martin Kosek wrote: >>>>>>> 2) Is the used ldapsearch really the best way to find out if Trust is >>>>>>> configured on a given master? Isn't a search in cn=masters,cn=ipa,... >>>>>>> better? >>>>>>> Alexander? >>>>>> What would the search in cn=masters,cn=ipa,.. give? >>>>>> >>>>>> We can have multiple CIFS services per realm. However, only those in >>>>>> 'adtrust agents' group are the ones which are real DCs. And since >>>>>> membership in the group is not handled via framework or UI, it is clear >>>>>> indication that ipa-adtrust-install was run. >>>>> It would say if there as an appropriate service configured by >>>>> ipa-adtrust-install. In this case, >>>>> "cn=ADTRUST,cn=FQDN,cn=masters,cn=ipa,cn=etc,SUFFIX. I am asking because this >>>>> is a standard way in FreeIPA to ask for configured services. >>>>> >>>>> If that does not work for Trust, then your alternative way should be OK too. >>>> This would work for making sure that ipa-adtrust-install was run on a >>>> specific server. It will not work for making sure trusts are enabled >>>> but in this case we only need to know that we have configured the host >>>> to be a DC so your approach is fine. >>>> >>>> I'm fine to use this approach, somehow it slipped out of my view when we >>>> discussed it with Ana.. >>>> >>>> >>> I amended the name of the new command to 'adtrust_is_enabled'. I also simplified >>> the LDAP search used in the command, as suggested by Martin and Alexander. >>> >>> Updated patch is attached. >>> >> Can you please rebase the patch? I think tests -> ipatests change is the >> culprit here. >> >> Tomas > Sure, rebased patch is attached. > ACK Tomas From simo at redhat.com Fri Jun 21 14:19:48 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 21 Jun 2013 10:19:48 -0400 Subject: [Freeipa-devel] DNSSEC support design considerations: migration to RBTDB In-Reply-To: <51C2F5E9.10109@redhat.com> References: <51924269.8020000@redhat.com> <94125227.1971889.1368606594501.JavaMail.root@redhat.com> <5193A598.4050805@redhat.com> <1369051654.6162.12.camel@willson.li.ssimo.org> <519BA195.9050504@redhat.com> <1369161023.23339.20.camel@willson.li.ssimo.org> <519CDDBA.1010500@redhat.com> <1369252720.2769.23.camel@willson.li.ssimo.org> <519E0D09.3010108@redhat.com> <1369319538.2769.24.camel@willson.li.ssimo.org> <51C2F5E9.10109@redhat.com> Message-ID: <1371824388.17111.118.camel@willson.li.ssimo.org> On Thu, 2013-06-20 at 14:30 +0200, Petr Spacek wrote: > Hello, > > On 23.5.2013 16:32, Simo Sorce wrote: > > On Thu, 2013-05-23 at 14:35 +0200, Petr Spacek wrote: > >> It looks that we agree on nearly all points (I apologize if > >> overlooked > >> something). I will prepare a design document for transition to RBTDB > >> and then > >> another design document for DNSSEC implementation. > > The current version of the design is available at: > https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/RBTDB Great write-up, thanks. > There are several questions inside (search for text "Question", it should find > all of them). I would like to get your opinion about the problems. > > Note that 389 DS team decided to implement RFC 4533 (syncrepl), so persistent > search is definitely obsolete and we can do synchronization in some clever way. Answering inline here after quoting the questions for the doc: > Periodical re-synchronization > > Questions * Do we still need periodical re-synchronization if 389 DS team implements RFC 4533 (syncrepl)? It wasn't considered in the initial design. We probably do. We have to be especially careful of the case when a replica is re-initialized. We should either automatically detect that this is happening or change ipa-replica-manage to kick named some how. We also need a tool or maybe a special attribute in LDAP that is monitored so that we can tell bind-dyndb-ldap to do a full rebuild of the cache on demand. This way admins can force a rebuild if they end up noticing something wrong. * What about dynamic updates during re-synchronization? Should we return a temporary error ? Or maybe just queue up the change and apply it right after the resync operation has finished ? * How to get sorted list of entries from LDAP? Use LDAP server-side sorting? Do we have necessary indices? We can do client side sorting as well I guess, I do not have a strong opinion here. The main reason why you need ordering is to detect delete records right ? Is thee a way to mark rdtdb records as updated instead (with a generation number) and then do a second pass on the rbtdb tree and remove any record that was not updated with the generation number ? This would also allow us to keep accepting dynamic updates by simply marking records as generation+1 so that the resync will not overwrite records that are updated during the resync phase. > (Filesystem) cache maintenance > Questions: How often should we save the cache from operating memory to disk? Prerequisite to be able to evaluate this question. How expensive is it to save the cache ? Is DNS responsive during the save or does the operation block updates or other functionality ? * On shutdown only? NACK, you are left with very stale data on crashes. * On start-up (after initial synchronization) and on shutdown? It makes sense to dump right after a big synchronization if it doesn't add substantial operational issues. Otherwise maybe a short interval after synchronization. * Periodically? How often? At the end of periodical re-synchronization? Periodically is probably a good idea, if I understand it correctly it means that it will make it possible to substantially reduce the load on startup as we will have less data to fetch from a syncrepl requiest. * Each N updates? I prefer a combination of each N updates but with time limits to avoid doing it too often. Ie something like every 1000 changes but not more often than every 30 minutes and not less often than 8 hours. (Numbers completely made up and need to be tuned based on the answer about the prerequisites question above). * If N % of the database was changed? (pspacek's favorite) The problem with using % database is that for very small zones you risk getting stuff saved too often, as changing a few records quickly makes the % big compared to the zone size. For example a zone with 50 records has a 10% change after just 5 records are changed. Conversely a big zone requires a huge amount of changes before the % of changes builds up leading potentially to dumping the database too infrequently. Example, zone with 100000 records, means you have to get 10000 changes before you come to the 10% mark. If dyndns updates are disabled this means the zone may never get saved for weeks or months. A small zone will also syncrepl quickly so it would be useless to save it often while a big zone is better if it is up to date on disk so the syncrepl operation will cost less on startup. Finally N % is also hard to compute. What do you consider into it ? Only total number of record changed ? Or do you factor in also if the same record is changed multiple times ? Consider fringe cases, zone with 1000 entries where only 1 entry is changed 2000 times in a short period (malfunctioning client (or attack) sending lots of updates for their record. Additional questions: I see you mention: "Cache non-existing records, i.e. do not repeat LDAP search for each query" I assume this is fine and we rely on syncrepl to give us an update and override the negative cache if the record that has been negatively cached suddenly appears via replication through another master, right ? If we rely on syncrepl, are we going to ever make direct LDAP searches at all ? Or do we rely fully on having it send us any changes and therefore we always reply directly from the rbtdb database ? Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Mon Jun 24 07:35:45 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 24 Jun 2013 09:35:45 +0200 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <51C420AA.4080007@redhat.com> References: <1290988309.4979837.1371653165405.JavaMail.root@redhat.com> <51C1D8BF.8070809@redhat.com> <51C1D9C9.7090002@redhat.com> <51C1DA1A.6040800@redhat.com> <51C1DC78.5020209@redhat.com> <20130619164601.GM24492@redhat.com> <51C1E157.4090308@redhat.com> <20130619165652.GA10478@redhat.com> <51C1F34C.5000805@redhat.com> <51C1F8D7.3070109@redhat.com> <20130619185656.GC10478@redhat.com> <51C2AF68.3020606@redhat.com> <51C2B0D6.1020607@redhat.com> <51C2D954.1030207@redhat.com> <51C2DEF8.1040400@redhat.com> <51C3FDBB.7060902@redhat.com> <51C40182.9000306@redhat.com> <51C420AA.4080007@redhat.com> Message-ID: <51C7F6D1.7090004@redhat.com> On 21.6.2013 11:45, Tomas Babej wrote: > On 06/21/2013 09:32 AM, Jan Cholasta wrote: >> On 21.6.2013 09:16, Tomas Babej wrote: >>> I'm also thinking about propagating the --verbose, etc. options provided >>> by default by AdminTool down to plugin level so that plugin authors can >>> make use of them. What do you think? >> >> +1 >> > > Newly added features: > > - options propagated to plugins > - made plugin content creation more comfortable, now 3 classes of output are > available (debug, comment, command) > > Now pretty much everything that comes into my mind is addressed, so please > have a look > at the current implementation. > > Any suggestions welcome. > New version: > - provides require_root setting for plugins What would happen if require_root = False, UID = 1234 but the plugin requires root access? (I.e. there is an error in the require_root value.) I don't like this boolean, because plugin author has to test the plugin and maintain the boolean after each change in the plugin. From my (naive) point of view it is error prone and unnecessary. Proper error handling seems like 'the right way'? to me. -- Petr^2 Spacek From pviktori at redhat.com Mon Jun 24 08:33:58 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 24 Jun 2013 10:33:58 +0200 Subject: [Freeipa-devel] [PATCHES] 0227-0229 freeipa-tests package & Beaker integration plugin In-Reply-To: <51BF5F0D.4060605@redhat.com> References: <51A4D370.6030307@redhat.com> <51BB18A4.2070607@redhat.com> <51BB2257.40504@redhat.com> <51BF0396.2030806@redhat.com> <51BF0A9F.2030600@redhat.com> <51BF20DD.9070803@redhat.com> <51BF2688.6080307@redhat.com> <51BF5F0D.4060605@redhat.com> Message-ID: <51C80476.3040401@redhat.com> On 06/17/2013 09:10 PM, Dmitri Pal wrote: > On 06/17/2013 11:08 AM, Petr Viktorin wrote: >>>> ipa-run-tests --with-beakerlib is horribly slow for me, is that >>>> expected? >> >> Yes. For every logged line, BeakerLib's default logging backend starts >> up Python, parses a XML file, appends the line, and writes the XML out >> again. So especially with longer runs it's really slow. > > Is there any way to solve this problem? > For example send the output over the DBUS to a special service that > would have the python already loaded and would do the appending to the > files and writing the output. > Also there can be an optimization that it would not save the file up > until the change affects a different file. > > The logic would be: > > loop: > If do not have an open output file open one and keep it in memory > Read a request for update until receive a special message for > termination or a signal, then break out of the loop > If the request for update for the same file update the file > Else save currently open file and start a new one, add data to the > newly started file > end > close currently open file I hope Beaker does something like you described. The slow part is only the XML backend, which gets selected if you run BeakerLib without Beaker. We could write (or find?) a faster logging backend but it's not really necessary. Without Beaker the BeakerLib logging is not of much use anyway. -- Petr? From pvoborni at redhat.com Mon Jun 24 10:42:49 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 24 Jun 2013 12:42:49 +0200 Subject: [Freeipa-devel] [PATCH] 421 Fix default value selection in radio widget In-Reply-To: <51C329BC.5010804@redhat.com> References: <51C098D7.4030105@redhat.com> <51C329BC.5010804@redhat.com> Message-ID: <51C822A9.9060301@redhat.com> On 06/20/2013 06:11 PM, Ana Krivokapic wrote: > On 06/18/2013 07:28 PM, Petr Vobornik wrote: >> Fix default value selection in radio widget >> >> https://fedorahosted.org/freeipa/ticket/3718>> > > The web UI now displays 'Forward policy' as 'Forward first' when no > policy is active (e.g. in case of empty Global DNS Configuration). Do we > really want to have a default value for this particular radio button? > Shouldn't it be unselected as default? > > -- > Regards, > > Ana Krivokapic IMO checking 'Forward first' when value is missing is correct. 'Forward first' is default in BIND so It tells admin what is the effective value and therefore admin doesn't have to remember what are the defaults. There is one case when it would make sense to leave it unchecked. That is when no Global forwarder is set. 'Forward policy' is not used in that case. -- Petr Vobornik From pviktori at redhat.com Mon Jun 24 12:21:25 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 24 Jun 2013 14:21:25 +0200 Subject: [Freeipa-devel] [PATCH] 0033 Fail when adding a trust with a different range In-Reply-To: <51C166D7.8040203@redhat.com> References: <51A87688.2070107@redhat.com> <51B1B2DF.3050101@redhat.com> <51B20107.4050405@redhat.com> <51B59854.1030404@redhat.com> <51B5F137.5060803@redhat.com> <20130612082316.GU26689@redhat.com> <51B84206.30601@redhat.com> <51B84A17.5000207@redhat.com> <51B99C2D.7010301@redhat.com> <51C166D7.8040203@redhat.com> Message-ID: <51C839C5.60100@redhat.com> On 06/19/2013 10:07 AM, Tomas Babej wrote: > On 06/13/2013 12:17 PM, Ana Krivokapic wrote: >> On 06/12/2013 12:14 PM, Martin Kosek wrote: >>> On 06/12/2013 11:40 AM, Tomas Babej wrote: >>>> On 06/12/2013 10:23 AM, Alexander Bokovoy wrote: >>>>> On Mon, 10 Jun 2013, Ana Krivokapic wrote: >>>>>>> And once here(added by your patch): >>>>>>> >>>>>>> + if not self.validate_range(*keys, **options): >>>>>>> + raise errors.ValidationError( >>>>>>> + name=_('id range'), >>>>>>> + error=_( >>>>>>> + 'An id range already exists for this trust. ' >>>>>>> + 'You should either delete the old range, or ' >>>>>>> + 'exclude --base-id/--range-size options from the >>>>>>> command.' >>>>>>> >>>>>>> I'd suggest we have one common place, say validate_range() function as >>>>>>> we have now, >>>>>>> that contains all the checks (more coming in the future for sure). >>>>>>> >>>>>>> That would mean that the whole trust-add command will fail in the case >>>>>>> that "ID range >>>>>>> with the same name but different domain SID already exists", since we >>>>>>> now call validate_range() >>>>>>> within execute() method. I checked with Alexander and we agreed that >>>>>>> this is more desired behaviour. >>>>>>> >>>>>>> This would also result to reducement of the number of API calls, which >>>>>>> is a nice benefit. >>>>>>> >>>>>>> Tomas >>>>>> This updated patch completely separates validation logic and object >>>>>> creation logic of the trust_add command. I added two new methods: >>>>>> >>>>>> * validate_range(), which ensures that the options and environment >>>>>> related to idrange is valid, and >>>>>> * validate_options, which takes care of other general validation >>>>>> >>>>>> One change introduced in this patch is making the >>>>>> __populate_remote_domain() method of TrustDomainJoins class public, and >>>>>> calling it from trust_add. This was necessary in order to enable >>>>>> discovering details of the trusted domain in validation phase. >>>>> Looks good overall but I'd suggest to wrap populate_remote_domain() >>>>> calls in join_ad_* methods instead of removing them. If remote domain is >>>>> not initialized (i.e. not(isinstance(self.remote_domain,TrustedDomainInstance)), >>>>> then call populate_remote_domain() as it was before. >> Fixed. >> >>>> I tested the patch and it works fine. >>>> >>>> There's a lot of refactoring done, but the changes preserve equal state. Aside >>>> from >>>> Alexander's comment up here, I have but one nitpick. >>>> >>>> There are few constructs of the form: >>>> >>>> try: >>>> value = dictionary['keyword'] >>>> except KeyError: >>>> value = None >>>> >>>> or >>>> >>>> if 'keyword' in dictionary: >>>> value = dictionary['keyword'] >>>> else: >>>> value = None >>>> >>>> Can you please substitute these with "value = dictionary.get(keyword, None)"? >>>> Not everywhere, but there are places where it can improve readability of the code. >>> You can even use just "value = dictionary.get(keyword)" as None is the default >>> return value: >>> >>>>>> print {}.get("foo") >> Fixed. >> >>> None >>> >>> Martin >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Updated patch attached. >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > ACK > > Tomas Pushed to master. -- Petr? From pviktori at redhat.com Mon Jun 24 12:26:03 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 24 Jun 2013 14:26:03 +0200 Subject: [Freeipa-devel] [PATCH] 0037 Do not display traceback to user In-Reply-To: <51C2F775.4060203@redhat.com> References: <51BF0AF6.1050309@redhat.com> <51C2F775.4060203@redhat.com> Message-ID: <51C83ADB.5060609@redhat.com> On 06/20/2013 02:37 PM, Tomas Babej wrote: > On 06/17/2013 03:11 PM, Ana Krivokapic wrote: >> Hello, >> >> Logging tracebacks at the INFO level caused them to be displayed to user on the >> command line. Change the log level to DEBUG, so that tracebacks are not visible >> to user. >> >> https://fedorahosted.org/freeipa/ticket/3704 >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > ACK > > Tomas > Pushed to master, ipa-3-2. -- Petr? From tbabej at redhat.com Mon Jun 24 12:27:06 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 24 Jun 2013 14:27:06 +0200 Subject: [Freeipa-devel] [PATCH] 0029 Make sure replication works after DM password is changed In-Reply-To: <1370961745.2400.96.camel@aleeredhat.laptop> References: <519357F3.3080408@redhat.com> <51935D92.8080407@redhat.com> <51936395.20409@redhat.com> <51937353.3090501@redhat.com> <51B19888.2050803@redhat.com> <51B5E43F.809@redhat.com> <1370961745.2400.96.camel@aleeredhat.laptop> Message-ID: <51C83B1A.40000@redhat.com> On 06/11/2013 04:42 PM, Ade Lee wrote: [snip] > Just FYI, we plan to do a new release of pki-core today > (pki-core-10.0.3-2) to address this issue. >> -- >> Regards, >> >> Ana Krivokapic >> Associate Software Engineer >> FreeIPA team >> Red Hat Inc. > Ok, so I tested the patch, since pki-core has the PkiExport command fixed now. I'm getting a little bit further now. [tbabej at vm-127 ~]$ sudo ipa-replica-prepare --ip-address 10.34.47.129 vm-129.idm.lab.eng.brq.redhat.com Directory Manager (existing master) password: Preparing replica for vm-129.idm.lab.eng.brq.redhat.com from vm-127.idm.lab.eng.brq.redhat.com Constraint violation: Failed to update password With debug output, I get (snipped out irrelevant parts): Directory Manager (existing master) password: ipa.ipaserver.plugins.ldap2.ldap2: DEBUG: Created connection context.ldap2_57668944 ipa.ipapython.ipaldap.SchemaCache: DEBUG: retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-IDM-LAB-ENG-BRQ-REDHAT-COM.socket conn= ipa.ipaserver.plugins.ldap2.ldap2: DEBUG: Destroyed connection context.ldap2_57668944 ipa: DEBUG: Search DNS for vm-129.idm.lab.eng.brq.redhat.com ipa: DEBUG: Search failed: [Errno -2] Name or service not known ipa.ipapython.ipaldap.SchemaCache: DEBUG: flushing ldapi://%2fvar%2frun%2fslapd-IDM-LAB-ENG-BRQ-REDHAT-COM.socket from SchemaCache ipa.ipapython.ipaldap.SchemaCache: DEBUG: retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-IDM-LAB-ENG-BRQ-REDHAT-COM.socket conn= ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: Not logging to a file ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: ipa-replica-prepare was invoked with arguments ['vm-129.idm.lab.eng.brq.redhat.com'] and options: {'log_file': None, 'verbose': True, 'reverse_zone': None, 'setup_pkinit': True, 'http_pin': None, 'quiet': False, 'http_pkcs12': None, 'pkinit_pkcs12': None, 'ca_file': '/root/cacert.p12', 'no_reverse': False, 'dirsrv_pkcs12': None, 'password': None, 'ip_address': CheckedIPAddress('10.34.47.129'), 'dirsrv_pin': None, 'pkinit_pin': None} ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: INFO: Preparing replica for vm-129.idm.lab.eng.brq.redhat.com from vm-127.idm.lab.eng.brq.redhat.com ipa.ipapython.ipaldap.SchemaCache: DEBUG: flushing ldapi://%2fvar%2frun%2fslapd-IDM-LAB-ENG-BRQ-REDHAT-COM.socket from SchemaCache ipa.ipapython.ipaldap.SchemaCache: DEBUG: retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-IDM-LAB-ENG-BRQ-REDHAT-COM.socket conn= ipa: DEBUG: Starting external process ipa: DEBUG: args=/usr/bin/PKCS12Export -d /etc/pki/pki-tomcat/alias/ -p /tmp/tmprgUrso -w /tmp/tmp6SBBXF -o /root/cacert.p12 ipa: DEBUG: Process finished, return code=0 ipa: DEBUG: stdout= ipa: DEBUG: stderr= ipa.ipaserver.plugins.ldap2.ldap2: DEBUG: Created connection context.ldap2_139884970376144 ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py", line 245, in run self.copy_ds_certificate() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py", line 281, in copy_ds_certificate self.update_pki_admin_password() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py", line 520, in update_pki_admin_password ldap.modify_password(dn, self.dirman_password) File "/usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py", line 332, in modify_password self.conn.passwd_s(dn, old_pass, new_pass) File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ self.gen.throw(type, value, traceback) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 919, in error_handler raise errors.DatabaseError(desc=desc, info=info) ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: The ipa-replica-prepare command failed, exception: DatabaseError: Constraint violation: Failed to update password ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: ERROR: Constraint violation: Failed to update password Tomas From pviktori at redhat.com Mon Jun 24 12:31:10 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 24 Jun 2013 14:31:10 +0200 Subject: [Freeipa-devel] [PATCH 0030] Require rid-base and secondary-rid-base options in idrange-add when trust exists In-Reply-To: <51C45C3D.5090204@redhat.com> References: <51A4C406.5000206@redhat.com> <51A8DF79.9070700@redhat.com> <51B09703.9080801@redhat.com> <51B72F80.4000902@redhat.com> <51B74A5A.2050903@redhat.com> <20130611162438.GS26689@redhat.com> <51B751A0.2070705@redhat.com> <20130611164457.GT26689@redhat.com> <51B8AAAA.2000701@redhat.com> <51C4497A.30306@redhat.com> <51C45764.6020701@redhat.com> <51C45C3D.5090204@redhat.com> Message-ID: <51C83C0E.9080302@redhat.com> On 06/21/2013 03:59 PM, Tomas Babej wrote: > On 06/21/2013 03:38 PM, Ana Krivokapic wrote: >> On 06/21/2013 02:39 PM, Tomas Babej wrote: >>> On 06/12/2013 07:06 PM, Ana Krivokapic wrote: >>>> On 06/11/2013 06:44 PM, Alexander Bokovoy wrote: >>>>> On Tue, 11 Jun 2013, Martin Kosek wrote: >>>>>>>> 2) Is the used ldapsearch really the best way to find out if >>>>>>>> Trust is >>>>>>>> configured on a given master? Isn't a search in >>>>>>>> cn=masters,cn=ipa,... >>>>>>>> better? >>>>>>>> Alexander? >>>>>>> What would the search in cn=masters,cn=ipa,.. give? >>>>>>> >>>>>>> We can have multiple CIFS services per realm. However, only those in >>>>>>> 'adtrust agents' group are the ones which are real DCs. And since >>>>>>> membership in the group is not handled via framework or UI, it is >>>>>>> clear >>>>>>> indication that ipa-adtrust-install was run. >>>>>> It would say if there as an appropriate service configured by >>>>>> ipa-adtrust-install. In this case, >>>>>> "cn=ADTRUST,cn=FQDN,cn=masters,cn=ipa,cn=etc,SUFFIX. I am asking >>>>>> because this >>>>>> is a standard way in FreeIPA to ask for configured services. >>>>>> >>>>>> If that does not work for Trust, then your alternative way should >>>>>> be OK too. >>>>> This would work for making sure that ipa-adtrust-install was run on a >>>>> specific server. It will not work for making sure trusts are enabled >>>>> but in this case we only need to know that we have configured the host >>>>> to be a DC so your approach is fine. >>>>> >>>>> I'm fine to use this approach, somehow it slipped out of my view >>>>> when we >>>>> discussed it with Ana.. >>>>> >>>>> >>>> I amended the name of the new command to 'adtrust_is_enabled'. I >>>> also simplified >>>> the LDAP search used in the command, as suggested by Martin and >>>> Alexander. >>>> >>>> Updated patch is attached. >>>> >>> Can you please rebase the patch? I think tests -> ipatests change is the >>> culprit here. >>> >>> Tomas >> Sure, rebased patch is attached. >> > ACK > > Tomas Pushed to master. -- Petr? From deanhunter at comcast.net Fri Jun 21 21:54:12 2013 From: deanhunter at comcast.net (Dean Hunter) Date: Fri, 21 Jun 2013 16:54:12 -0500 Subject: [Freeipa-devel] Bug? Message-ID: <1371851652.1954.10.camel@developer.hunter.org> Is this a bug for which I should open a bug report? # Configure the Network File Server yum install --assumeyes freeipa-admintools Loaded plugins: langpacks, refresh-packagekit Package freeipa-admintools-3.2.1-1.fc19.x86_64 already installed and latest version Nothing to do echo adminpassword | kinit admin Password for admin at HUNTER.ORG ipa service-add nfs/ipa19.hunter.org ----------------------------------------------- Added service "nfs/ipa19.hunter.org at HUNTER.ORG" ----------------------------------------------- Principal: nfs/ipa19.hunter.org at HUNTER.ORG Managed by: ipa19.hunter.org ipa-getkeytab \\ --keytab /etc/krb5.keytab \\ --principal nfs/ipa19.hunter.org \\ --server ipa19.hunter.org Failed to retrieve encryption type Camellia-128 CTS mode with CMAC (#25) Failed to retrieve encryption type Camellia-256 CTS mode with CMAC (#26) kdestroy -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Mon Jun 24 12:55:08 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 24 Jun 2013 14:55:08 +0200 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <51C7F6D1.7090004@redhat.com> References: <1290988309.4979837.1371653165405.JavaMail.root@redhat.com> <51C1D8BF.8070809@redhat.com> <51C1D9C9.7090002@redhat.com> <51C1DA1A.6040800@redhat.com> <51C1DC78.5020209@redhat.com> <20130619164601.GM24492@redhat.com> <51C1E157.4090308@redhat.com> <20130619165652.GA10478@redhat.com> <51C1F34C.5000805@redhat.com> <51C1F8D7.3070109@redhat.com> <20130619185656.GC10478@redhat.com> <51C2AF68.3020606@redhat.com> <51C2B0D6.1020607@redhat.com> <51C2D954.1030207@redhat.com> <51C2DEF8.1040400@redhat.com> <51C3FDBB.7060902@redhat.com> <51C40182.9000306@redhat.com> <51C420AA.4080007@redhat.com> <51C7F6D1.7090004@redhat.com> Message-ID: <51C841AC.1050604@redhat.com> On 06/24/2013 09:35 AM, Petr Spacek wrote: > What would happen if require_root = False, UID = 1234 but the plugin > requires root access? (I.e. there is an error in the require_root value.) The calling of particular external command that requires root access for its execution will fail. > > I don't like this boolean, because plugin author has to test the > plugin and maintain the boolean after each change in the plugin. From > my (naive) point of view it is error prone and unnecessary. Why? From my point of view, it simplifies the work for the plugin author, since he can set the boolean if he knows that plugin will need root access to require information needed. Without it: - If he wanted to stay user-friendly he would have to implement the check for effective UID in every plugin. - If he did not, he would be having his command fail with (often) cryptic errors. > > Proper error handling seems like 'the right way'? to me. > What kind of proper error handling? The errors are now properly handled via AdminTool's framework. Tomas From rcritten at redhat.com Mon Jun 24 13:00:05 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 24 Jun 2013 09:00:05 -0400 Subject: [Freeipa-devel] Bug? In-Reply-To: <1371851652.1954.10.camel@developer.hunter.org> References: <1371851652.1954.10.camel@developer.hunter.org> Message-ID: <51C842D5.2090005@redhat.com> Dean Hunter wrote: > Is this a bug for which I should open a bug report? > > # Configure the Network File Server > > yum install --assumeyes freeipa-admintools > Loaded plugins: langpacks, refresh-packagekit > Package freeipa-admintools-3.2.1-1.fc19.x86_64 already installed and > latest version > Nothing to do > > echo adminpassword | kinit admin > Password for admin at HUNTER.ORG > > ipa service-add nfs/ipa19.hunter.org > ----------------------------------------------- > Added service "nfs/ipa19.hunter.org at HUNTER. > ORG" > ----------------------------------------------- > Principal: nfs/ipa19.hunter.org at HUNTER.ORG > Managed by: ipa19.hunter.org > > ipa-getkeytab \\ > --keytab /etc/krb5.keytab \\ > --principal nfs/ipa19.hunter.org \\ > --server ipa19.hunter.org > Failed to retrieve encryption type Camellia-128 CTS mode with CMAC (#25) > Failed to retrieve encryption type Camellia-256 CTS mode with CMAC (#26) > > kdestroy Not really. Camellia was enabled by default in 1.11 (it was added back in 1.9, but disabled by default). IPA does not currently enable the cipher on the KDC. So this is the client requesting all enabled ciphers and the server not returning the Camellia ciphers. It is just a warning. At best this is an RFE to enable Camellia by default on the KDC. rob From akrivoka at redhat.com Mon Jun 24 14:01:20 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 24 Jun 2013 16:01:20 +0200 Subject: [Freeipa-devel] [PATCH] 421 Fix default value selection in radio widget In-Reply-To: <51C822A9.9060301@redhat.com> References: <51C098D7.4030105@redhat.com> <51C329BC.5010804@redhat.com> <51C822A9.9060301@redhat.com> Message-ID: <51C85130.4030300@redhat.com> On 06/24/2013 12:42 PM, Petr Vobornik wrote: > On 06/20/2013 06:11 PM, Ana Krivokapic wrote: >> On 06/18/2013 07:28 PM, Petr Vobornik wrote: >>> Fix default value selection in radio widget >>> >>> https://fedorahosted.org/freeipa/ticket/3718>> >> >> The web UI now displays 'Forward policy' as 'Forward first' when no >> policy is active (e.g. in case of empty Global DNS Configuration). Do we >> really want to have a default value for this particular radio button? >> Shouldn't it be unselected as default? >> >> -- >> Regards, >> >> Ana Krivokapic > > IMO checking 'Forward first' when value is missing is correct. 'Forward first' > is default in BIND so It tells admin what is the effective value and therefore > admin doesn't have to remember what are the defaults. OK, that makes sense. > > There is one case when it would make sense to leave it unchecked. That is when > no Global forwarder is set. 'Forward policy' is not used in that case. So in that case 'Forward policy' should be disabled. In other words, it should only be enabled when 'Global forwarders' is not empty. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From pviktori at redhat.com Mon Jun 24 14:22:01 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 24 Jun 2013 16:22:01 +0200 Subject: [Freeipa-devel] [PATCH 0067] Add --use-posix option that forces trusted range type In-Reply-To: <51C2DFF5.8040608@redhat.com> References: <51B05207.4010100@redhat.com> <51BF0247.4040604@redhat.com> <51C2DFF5.8040608@redhat.com> Message-ID: <51C85609.3000103@redhat.com> On 06/20/2013 12:56 PM, Tomas Babej wrote: > On 06/17/2013 02:34 PM, Ana Krivokapic wrote: >> On 06/06/2013 11:10 AM, Tomas Babej wrote: >>> Hi, >>> >>> Adds --use-posix option to ipa trust-add command. It takes two >>> allowed values: >>> 'yes' : the 'ipa-ad-trust-posix' range type is enforced >>> 'no' : the 'ipa-ad-trust' range type is enforced >>> >>> When --use-posix option is not specified, the range type should be >>> determined by ID range discovery. >>> >>> https://fedorahosted.org/freeipa/ticket/3650 >>> >>> Tomas >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> The patch works nicely, but I have a few comments: >> >> 1) You added a new option to the API, but you forgot to bump the >> IPA_API_VERSION_MINOR in the VERSION file. >> >> 2) Typo in commit message: "shold" instead of "should". >> >> 3) This construct: >> >> + if range_type is not None: >> + if range_type != old_range_type: >> >> can be replaced with a more readable variant which also avoids nested ifs: >> >> + if range_type and range_type != old_range_type: >> > > All fixed. > >> 4) Some unit tests to cover the behavior of the newly added option >> would be nice. > > This is not doable at the moment, we have no unit test framework to test > the trust-add command. > >> -- >> Regards, >> >> Ana Krivokapic >> Associate Software Engineer >> FreeIPA team >> Red Hat Inc. >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Tomas I don't know much about AD trusts, but a command-line/API option that takes a 'yes' or 'no' string raised a tiny warning flag for me. It looks like it's possible that there can be other range types in the future than posix and algorithmic? If that's the case, there should be a --range-type option instead. (If not, I'd still go for --range-type but that would just be bikeshedding.) In any case I think an explicit 'auto' option would be nice. But that's just an outsider's view, maybe --use-posix makes more sense. AFAIK, for CLI changes there should be a a design page; is this covered anywhere? -- Petr? From thozza at redhat.com Mon Jun 24 14:50:34 2013 From: thozza at redhat.com (Tomas Hozza) Date: Mon, 24 Jun 2013 10:50:34 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0166] Fix minor coding style issue in update_config() In-Reply-To: <51C301B3.4050909@redhat.com> References: <51C301B3.4050909@redhat.com> Message-ID: <679904429.11839637.1372085434755.JavaMail.root@redhat.com> ACK The patch looks good. Regards, Tomas Hozza ----- Original Message ----- > Hello, > > Fix minor coding style issue in update_config(). > > -- > Petr^2 Spacek > From pvoborni at redhat.com Mon Jun 24 14:59:55 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 24 Jun 2013 16:59:55 +0200 Subject: [Freeipa-devel] [PATCH] 421 Fix default value selection in radio widget In-Reply-To: <51C85130.4030300@redhat.com> References: <51C098D7.4030105@redhat.com> <51C329BC.5010804@redhat.com> <51C822A9.9060301@redhat.com> <51C85130.4030300@redhat.com> Message-ID: <51C85EEB.6000106@redhat.com> On 06/24/2013 04:01 PM, Ana Krivokapic wrote: > On 06/24/2013 12:42 PM, Petr Vobornik wrote: >> On 06/20/2013 06:11 PM, Ana Krivokapic wrote: >>> On 06/18/2013 07:28 PM, Petr Vobornik wrote: >>>> Fix default value selection in radio widget >>>> >>>> https://fedorahosted.org/freeipa/ticket/3718>> >>> >>> The web UI now displays 'Forward policy' as 'Forward first' when no >>> policy is active (e.g. in case of empty Global DNS Configuration). Do we >>> really want to have a default value for this particular radio button? >>> Shouldn't it be unselected as default? >>> >>> -- >>> Regards, >>> >>> Ana Krivokapic >> >> IMO checking 'Forward first' when value is missing is correct. 'Forward first' >> is default in BIND so It tells admin what is the effective value and therefore >> admin doesn't have to remember what are the defaults. > > OK, that makes sense. > >> >> There is one case when it would make sense to leave it unchecked. That is when >> no Global forwarder is set. 'Forward policy' is not used in that case. > > So in that case 'Forward policy' should be disabled. In other words, it should > only be enabled when 'Global forwarders' is not empty. > I've discussed it with Ana in person and we've agreed on that the current approach is sufficient (ACK). Pushed to master, ipa-3-2. -- Petr Vobornik From pvoborni at redhat.com Mon Jun 24 16:13:52 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 24 Jun 2013 18:13:52 +0200 Subject: [Freeipa-devel] [PATCH] 425 Do not redirect to https in /ipa/ui on non-HTML files Message-ID: <51C87040.4070203@redhat.com> Those resources are needed by page which has to use http(browser config) prior to acceptance of CA cert. https://fedorahosted.org/freeipa/ticket/3748 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0425-Do-not-redirect-to-https-in-ipa-ui-on-non-HTML-files.patch Type: text/x-patch Size: 1119 bytes Desc: not available URL: From tbabej at redhat.com Mon Jun 24 17:00:34 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 24 Jun 2013 19:00:34 +0200 Subject: [Freeipa-devel] [PATCH] 425 Do not redirect to https in /ipa/ui on non-HTML files In-Reply-To: <51C87040.4070203@redhat.com> References: <51C87040.4070203@redhat.com> Message-ID: <51C87B32.30309@redhat.com> On 06/24/2013 06:13 PM, Petr Vobornik wrote: > Those resources are needed by page which has to use http(browser > config) prior to acceptance of CA cert. > > https://fedorahosted.org/freeipa/ticket/3748 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel I think you (technically) need to update the version in the first commented line. (Probably would not be an issue for anybody, since we haven't done a release since it was last changed) Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Tue Jun 25 06:22:43 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 25 Jun 2013 08:22:43 +0200 Subject: [Freeipa-devel] [PATCH 0073] Remove support for IPA deployments with no persistent search In-Reply-To: <51C43E88.7000807@redhat.com> References: <51B86955.6040905@redhat.com> <51C43E88.7000807@redhat.com> Message-ID: <51C93733.2080706@redhat.com> On 06/21/2013 01:52 PM, Ana Krivokapic wrote: > On 06/12/2013 02:28 PM, Tomas Babej wrote: ... > 2) I wonder if we can also remove the '--zone-notif' option from > ipa-server-install and ipa-dns-install. It is already deprecated so maybe this > is a good time to drop it altogether? +1, this zone was already hidden and deprecated for a year now, so I think it is safe for it to be removed. Martin From mkosek at redhat.com Tue Jun 25 06:24:21 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 25 Jun 2013 08:24:21 +0200 Subject: [Freeipa-devel] [PATCHES] 0227-0229 freeipa-tests package & Beaker integration plugin In-Reply-To: <51C80476.3040401@redhat.com> References: <51A4D370.6030307@redhat.com> <51BB18A4.2070607@redhat.com> <51BB2257.40504@redhat.com> <51BF0396.2030806@redhat.com> <51BF0A9F.2030600@redhat.com> <51BF20DD.9070803@redhat.com> <51BF2688.6080307@redhat.com> <51BF5F0D.4060605@redhat.com> <51C80476.3040401@redhat.com> Message-ID: <51C93795.3010708@redhat.com> On 06/24/2013 10:33 AM, Petr Viktorin wrote: > On 06/17/2013 09:10 PM, Dmitri Pal wrote: >> On 06/17/2013 11:08 AM, Petr Viktorin wrote: >>>>> ipa-run-tests --with-beakerlib is horribly slow for me, is that >>>>> expected? >>> >>> Yes. For every logged line, BeakerLib's default logging backend starts >>> up Python, parses a XML file, appends the line, and writes the XML out >>> again. So especially with longer runs it's really slow. >> >> Is there any way to solve this problem? >> For example send the output over the DBUS to a special service that >> would have the python already loaded and would do the appending to the >> files and writing the output. >> Also there can be an optimization that it would not save the file up >> until the change affects a different file. >> >> The logic would be: >> >> loop: >> If do not have an open output file open one and keep it in memory >> Read a request for update until receive a special message for >> termination or a signal, then break out of the loop >> If the request for update for the same file update the file >> Else save currently open file and start a new one, add data to the >> newly started file >> end >> close currently open file > > I hope Beaker does something like you described. The slow part is only the XML > backend, which gets selected if you run BeakerLib without Beaker. > We could write (or find?) a faster logging backend but it's not really > necessary. Without Beaker the BeakerLib logging is not of much use anyway. > Right. In our upstream continuous integration testing, this option should be off -> no logging performance issues for us. Martin From mkosek at redhat.com Tue Jun 25 06:55:43 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 25 Jun 2013 08:55:43 +0200 Subject: [Freeipa-devel] Bug? In-Reply-To: <51C842D5.2090005@redhat.com> References: <1371851652.1954.10.camel@developer.hunter.org> <51C842D5.2090005@redhat.com> Message-ID: <51C93EEF.5060701@redhat.com> On 06/24/2013 03:00 PM, Rob Crittenden wrote: > Dean Hunter wrote: >> Is this a bug for which I should open a bug report? >> >> # Configure the Network File Server >> >> yum install --assumeyes freeipa-admintools >> Loaded plugins: langpacks, refresh-packagekit >> Package freeipa-admintools-3.2.1-1.fc19.x86_64 already installed and >> latest version >> Nothing to do >> >> echo adminpassword | kinit admin >> Password for admin at HUNTER.ORG >> >> ipa service-add nfs/ipa19.hunter.org >> ----------------------------------------------- >> Added service "nfs/ipa19.hunter.org at HUNTER. >> ORG" >> ----------------------------------------------- >> Principal: nfs/ipa19.hunter.org at HUNTER.ORG >> Managed by: ipa19.hunter.org >> >> ipa-getkeytab \\ >> --keytab /etc/krb5.keytab \\ >> --principal nfs/ipa19.hunter.org \\ >> --server ipa19.hunter.org >> Failed to retrieve encryption type Camellia-128 CTS mode with CMAC (#25) >> Failed to retrieve encryption type Camellia-256 CTS mode with CMAC (#26) >> >> kdestroy > > Not really. Camellia was enabled by default in 1.11 (it was added back in 1.9, > but disabled by default). IPA does not currently enable the cipher on the KDC. > > So this is the client requesting all enabled ciphers and the server not > returning the Camellia ciphers. It is just a warning. > > At best this is an RFE to enable Camellia by default on the KDC. > > rob I filed an upstream ticket: https://fedorahosted.org/freeipa/ticket/3749 Thanks Dean and Rob! Martin From mkosek at redhat.com Tue Jun 25 06:58:31 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 25 Jun 2013 08:58:31 +0200 Subject: [Freeipa-devel] [PATCH 0067] Add --use-posix option that forces trusted range type In-Reply-To: <51C85609.3000103@redhat.com> References: <51B05207.4010100@redhat.com> <51BF0247.4040604@redhat.com> <51C2DFF5.8040608@redhat.com> <51C85609.3000103@redhat.com> Message-ID: <51C93F97.4080001@redhat.com> On 06/24/2013 04:22 PM, Petr Viktorin wrote: > On 06/20/2013 12:56 PM, Tomas Babej wrote: >> On 06/17/2013 02:34 PM, Ana Krivokapic wrote: >>> On 06/06/2013 11:10 AM, Tomas Babej wrote: >>>> Hi, >>>> >>>> Adds --use-posix option to ipa trust-add command. It takes two >>>> allowed values: >>>> 'yes' : the 'ipa-ad-trust-posix' range type is enforced >>>> 'no' : the 'ipa-ad-trust' range type is enforced >>>> >>>> When --use-posix option is not specified, the range type should be >>>> determined by ID range discovery. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3650 >>>> >>>> Tomas >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >>> The patch works nicely, but I have a few comments: >>> >>> 1) You added a new option to the API, but you forgot to bump the >>> IPA_API_VERSION_MINOR in the VERSION file. >>> >>> 2) Typo in commit message: "shold" instead of "should". >>> >>> 3) This construct: >>> >>> + if range_type is not None: >>> + if range_type != old_range_type: >>> >>> can be replaced with a more readable variant which also avoids nested ifs: >>> >>> + if range_type and range_type != old_range_type: >>> >> >> All fixed. >> >>> 4) Some unit tests to cover the behavior of the newly added option >>> would be nice. >> >> This is not doable at the moment, we have no unit test framework to test >> the trust-add command. >> >>> -- >>> Regards, >>> >>> Ana Krivokapic >>> Associate Software Engineer >>> FreeIPA team >>> Red Hat Inc. >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> Tomas > > I don't know much about AD trusts, but a command-line/API option that takes a > 'yes' or 'no' string raised a tiny warning flag for me. > > It looks like it's possible that there can be other range types in the future > than posix and algorithmic? If that's the case, there should be a --range-type > option instead. (If not, I'd still go for --range-type but that would just be > bikeshedding.) > > In any case I think an explicit 'auto' option would be nice. > > But that's just an outsider's view, maybe --use-posix makes more sense. > > > AFAIK, for CLI changes there should be a a design page; is this covered anywhere? It should be covered in the parent RFE ticket: https://fedorahosted.org/freeipa/ticket/2904 I see it is not there. This is still a task for Tomas or Alexander. Martin From jcholast at redhat.com Tue Jun 25 07:18:57 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 25 Jun 2013 09:18:57 +0200 Subject: [Freeipa-devel] [PATCH 0067] Add --use-posix option that forces trusted range type In-Reply-To: <51C85609.3000103@redhat.com> References: <51B05207.4010100@redhat.com> <51BF0247.4040604@redhat.com> <51C2DFF5.8040608@redhat.com> <51C85609.3000103@redhat.com> Message-ID: <51C94461.5040400@redhat.com> On 24.6.2013 16:22, Petr Viktorin wrote: > I don't know much about AD trusts, but a command-line/API option that > takes a 'yes' or 'no' string raised a tiny warning flag for me. > > It looks like it's possible that there can be other range types in the > future than posix and algorithmic? If that's the case, there should be a > --range-type option instead. (If not, I'd still go for --range-type but > that would just be bikeshedding.) > > In any case I think an explicit 'auto' option would be nice. > > But that's just an outsider's view, maybe --use-posix makes more sense. > +1 -- Jan Cholasta From jcholast at redhat.com Tue Jun 25 08:34:40 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 25 Jun 2013 10:34:40 +0200 Subject: [Freeipa-devel] [PATCH] 141 Fix CA-less check in ipa-replica-install and ipa-ca-install Message-ID: <51C95620.6040506@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-141-Fix-CA-less-check-in-ipa-replica-install-and-ipa-ca-.patch Type: text/x-patch Size: 1411 bytes Desc: not available URL: From jcholast at redhat.com Tue Jun 25 08:54:55 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 25 Jun 2013 10:54:55 +0200 Subject: [Freeipa-devel] [PATCH] 142 Do not skip SSSD known hosts in ipa-client-install --ssh-trust-dns Message-ID: <51C95ADF.10300@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-142-Do-not-skip-SSSD-known-hosts-in-ipa-client-install-s.patch Type: text/x-patch Size: 1362 bytes Desc: not available URL: From thozza at redhat.com Tue Jun 25 10:13:11 2013 From: thozza at redhat.com (Tomas Hozza) Date: Tue, 25 Jun 2013 06:13:11 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0165] Fix crash caused by race-condition between shutdown and update processing In-Reply-To: <51C2FFBA.5060505@redhat.com> References: <51C2FFBA.5060505@redhat.com> Message-ID: <844825390.12105304.1372155191958.JavaMail.root@redhat.com> ACK. Works as expected. Regards, Tomas Hozza ----- Original Message ----- > Hello, > > Fix crash caused by race-condition between shutdown and update processing. > > Variable 'name' was uninitialized when manager_get_ldap_instance() returned > ISC_R_NOTFOUND. The successive call to dns_name_dynamic() caused the crash. > > -- > Petr^2 Spacek > From mkosek at redhat.com Tue Jun 25 10:22:43 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 25 Jun 2013 12:22:43 +0200 Subject: [Freeipa-devel] [PATCH] 425 Do not redirect to https in /ipa/ui on non-HTML files In-Reply-To: <51C87B32.30309@redhat.com> References: <51C87040.4070203@redhat.com> <51C87B32.30309@redhat.com> Message-ID: <51C96F73.9060502@redhat.com> On 06/24/2013 07:00 PM, Tomas Babej wrote: > On 06/24/2013 06:13 PM, Petr Vobornik wrote: >> Those resources are needed by page which has to use http(browser config) >> prior to acceptance of CA cert. >> >> https://fedorahosted.org/freeipa/ticket/3748 >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > I think you (technically) need to update the version in the first commented line. Thanks for pointing this out Tomas. I see you learned a lesson last time :-) > > (Probably would not be an issue for anybody, since we haven't done a release > since it was last changed) Yeah, this is not critical. But it may still make sense to bump the number, if just for a sake of consistency if someone would do some "git blame" investigation based on this line. Martin From pvoborni at redhat.com Tue Jun 25 10:24:56 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 25 Jun 2013 12:24:56 +0200 Subject: [Freeipa-devel] [PATCH] 425 Do not redirect to https in /ipa/ui on non-HTML files In-Reply-To: <51C96F73.9060502@redhat.com> References: <51C87040.4070203@redhat.com> <51C87B32.30309@redhat.com> <51C96F73.9060502@redhat.com> Message-ID: <51C96FF8.5070209@redhat.com> On 06/25/2013 12:22 PM, Martin Kosek wrote: > On 06/24/2013 07:00 PM, Tomas Babej wrote: >> On 06/24/2013 06:13 PM, Petr Vobornik wrote: >>> Those resources are needed by page which has to use http(browser config) >>> prior to acceptance of CA cert. >>> >>> https://fedorahosted.org/freeipa/ticket/3748 >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> I think you (technically) need to update the version in the first commented line. > > Thanks for pointing this out Tomas. I see you learned a lesson last time :-) > >> >> (Probably would not be an issue for anybody, since we haven't done a release >> since it was last changed) > > Yeah, this is not critical. But it may still make sense to bump the number, if > just for a sake of consistency if someone would do some "git blame" > investigation based on this line. > > Martin > Version bumped, updated patch attached. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0425-1-Do-not-redirect-to-https-in-ipa-ui-on-non-HTML-files.patch Type: text/x-patch Size: 1253 bytes Desc: not available URL: From pspacek at redhat.com Tue Jun 25 11:54:05 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 25 Jun 2013 13:54:05 +0200 Subject: [Freeipa-devel] [PATCH 0166] Fix minor coding style issue in update_config() In-Reply-To: <679904429.11839637.1372085434755.JavaMail.root@redhat.com> References: <51C301B3.4050909@redhat.com> <679904429.11839637.1372085434755.JavaMail.root@redhat.com> Message-ID: <51C984DD.1080409@redhat.com> On 24.6.2013 16:50, Tomas Hozza wrote: > ACK Pushed to master: 0bcf544fbcedee7cf3eb74a5bcd4749ce4ebc089 > > The patch looks good. > > Regards, > > Tomas Hozza > > ----- Original Message ----- >> Hello, >> >> Fix minor coding style issue in update_config(). >> >> -- >> Petr^2 Spacek >> -- Petr^2 Spacek From pspacek at redhat.com Tue Jun 25 11:54:08 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 25 Jun 2013 13:54:08 +0200 Subject: [Freeipa-devel] [PATCH 0165] Fix crash caused by race-condition between shutdown and update processing In-Reply-To: <844825390.12105304.1372155191958.JavaMail.root@redhat.com> References: <51C2FFBA.5060505@redhat.com> <844825390.12105304.1372155191958.JavaMail.root@redhat.com> Message-ID: <51C984E0.6040304@redhat.com> On 25.6.2013 12:13, Tomas Hozza wrote: > ACK. Pushed to master: 12e31102f18aa4676e3ac7da4334806dc8afc801 > > Works as expected. > > Regards, > > Tomas Hozza > > ----- Original Message ----- >> Hello, >> >> Fix crash caused by race-condition between shutdown and update processing. >> >> Variable 'name' was uninitialized when manager_get_ldap_instance() returned >> ISC_R_NOTFOUND. The successive call to dns_name_dynamic() caused the crash. >> >> -- >> Petr^2 Spacek >> -- Petr^2 Spacek From pviktori at redhat.com Tue Jun 25 12:08:28 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 25 Jun 2013 14:08:28 +0200 Subject: [Freeipa-devel] [PATCHES] 0230-0240 Integration testing framework In-Reply-To: <51BB3A63.3090002@redhat.com> References: <51A88DA9.806@redhat.com> <51B5E72E.80000@redhat.com> <51B9B824.7030301@redhat.com> <51BB2674.602@redhat.com> <51BB2B8C.9020403@redhat.com> <51BB3A63.3090002@redhat.com> Message-ID: <51C9883C.8030204@redhat.com> On 06/14/2013 05:44 PM, Petr Viktorin wrote: > On 06/14/2013 04:41 PM, Jan Cholasta wrote: >> On 14.6.2013 16:19, Jan Cholasta wrote: >>> Hi, >>> >>> On 13.6.2013 14:16, Petr Viktorin wrote: >>>> On 06/10/2013 04:48 PM, Petr Viktorin wrote: >>>>> On 05/31/2013 01:46 PM, Petr Viktorin wrote: >>>>>> Apply on top of my patches 0227-0234. >>>>>> >>>>>> These patches add an initial integration testing framework. >>>>>> >>>>>> Patch 0230 adds a plugin for ordered test classes. >>>>>> Nose orders methods within a test suite alphabetically, but we >>>>>> generally >>>>>> want to run them in the order defined. This adds the @ordered >>>>>> decorator >>>>>> that causes Nose to do just that, provided the plugin is loaded and >>>>>> enabled, and that the methods are defined in the same file. The >>>>>> ipa-run-tests wrapper is changed to enable the plugin. >>>>>> In the future we may want to use this for unit tests as well. It >>>>>> might >>>>>> also make sense to separate it from the FreeIPA project altogether. >>>>>> >>>>>> Patch 0231 adds configuration for tests. This reads environment >>>>>> variables like: >>>>>> - MASTER (FQDN of initial server) >>>>>> - REPLICA (space-separated FQDNs of replicas) >>>>>> - CLIENT (space-separated FQDNs of clients), >>>>>> - IPATEST_DIR (directory the tests use on the remote machines) >>>>>> etc., and loads them into an easy-to use Python object. >>>>>> A tool called ipa-test-config is provided that generates a full >>>>>> set of >>>>>> environment variables for shell-based tests from these, either >>>>>> global or >>>>>> specific for a given host. >>>>>> If environment variables don't work for us, alternate configuration >>>>>> methods can be added in the future. >>> >>> I think you forgot to add "%dir >>> %{python_sitelib}/ipatests/test_integration" to the spec file. >>> >>> Is the "self = cls()" line at the beginning of Config.from_env() >>> intentional? >>> >>> + self = cls() >>> + env_normalize(env) >>> + >>> + self = cls(test_dir=env.get('IPATEST_DIR') or '/root/ipatests', > > No. I removed it, thanks for thee catch. > >> Also typo in commit message: "Integration tests are be configured ..." > > Thanks, fixed. > >>>>>> >>>>>> Patch 0232 adds an integration test framework. >>>>>> This extends Host object available from the configuration with >>>>>> methods >>>>>> to run commands and copy files on the remote host, and adds a base >>>>>> class >>>>>> for integration tests which can currently install and uninstall IPA >>>>>> in a >>>>>> "star" topology. (In the future, the install/uninstall code should >>>>>> also >>>>>> be made available as a shell command.) >>>>>> A simple test for user replication between two masters is provided. >>>>>> Log files from the remote hosts can be marked for collection, but the >>>>>> actual collection is left to a Nose plugin. >>>>>> The base class uses the @ordered decorator mentioned above. >>>>>> >>>>>> Patch 0233 improves on how commands are run on remote hosts. >>>>>> In the previous patch, the process's stdin and stdout were combined >>>>>> as a >>>>>> quick hack to avoid the problem that if we first read stdout and then >>>>>> stderr, then stderr's buffer can fill up and we'd deadlock (and the >>>>>> other way around). With this patch the streams are read in parallel. >>>>>> In the future this can be extended to calling whole commands in >>>>>> parallel >>>>>> (e.g. uninstalling IPA on all the hosts at once). >>>>>> >>>>>> Patch 0234 adds log collection to the BeakerLib integration plugin. >>>>>> This tars up the marked logs, downloads then, and calls >>>>>> rlFileSubmit on >>>>>> them. >> >> Missing space in commit message: "... log files fromthe remote ..." > > Thanks, fixed. > >>>>>> >>>>>> --- >>>>> >>>>> Attaching additional patches: >>>>> >>>>> Patch 0237 configures logging in ipa-run-tests to forward messages >>>>> from >>>>> the IPA logging machinery to a normal Python logger. This way the logs >>>>> are captured >>>>> The logs are also printed to stderr so that there's some activity on >>>>> the >>>>> terminal after you run the utility. >>>>> >>>>> Patch 0238 makes it possible to use RSA private SSH keys to log in to >>>>> the remote machines. The key is given in $IPA_ROOT_SSH_KEY, and >>>>> used if >>>>> $IPA_ROOT_SSH_PASSWORD is empty. >>>>> I've added this to the design page. >>> >>> It seems that the code prefers password authentication over public key >>> authentication if both are configured. IMO it would be better if it did >>> the opposite. > > Good point, fixed, design page updated. > >>>>> Patch 0239 makes test setup change the hostname, /etc/hosts, and >>>>> /etc/resolv.conf to match the configured values. These should be >>>>> equivalent to the fixes in >>>>> https://github.com/freeipa/tests/blob/master/ipa-tests/beaker/ipa-server/shared/ipa-install.sh#L733 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> In test teardown, the changes are undone. >>>> >>>> I've rebased the patrchset and added small fixes for patches 0232 and >>>> 0239. >>>> >>>> New patch 0240 contains a few fixes/improvements to the Host class that >>>> were not trivial to rebase into previous patches. >>>> >>>> The WIP patch adds a sketch of some of the tests for CA-less >>>> (http://www.freeipa.org/page/V3/CA-less_install#Test_Plan). Please >>>> comment if you can see where things can be improved for test authors! >>> >>> Just a word of warning, there are still a few test cases I need to add >>> to the CA-less test plan. > > Sure. I did this mainly to see how things look from the test author's > point of view. > Adding two additional patches for better Beaker integration: Patch 0241 allows e.g. adding ticket numbers for automatic test case management Patch 0242 should bring the BeakerLib logging closer to what traditional Beaker tests output -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0241.3-Use-dosctrings-in-BeakerLib-phase-descriptions.patch Type: text/x-patch Size: 1906 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0242.3-Make-BeakerLib-logging-less-verbose.patch Type: text/x-patch Size: 7517 bytes Desc: not available URL: From pspacek at redhat.com Tue Jun 25 12:29:31 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 25 Jun 2013 14:29:31 +0200 Subject: [Freeipa-devel] [PATCH 0167-0168] Release bind-dyndb-ldap 3.4. Message-ID: <51C98D2B.60700@redhat.com> Hello, Update NEWS file for upcoming 3.4 release. Pushed to master: ca7f5db6bdf86a813a470dd3b64c442b2a72d28e Bump NVR to 3.4. Pushed to master: 6e00a2e186f045df771ef558c90d4c6570d9feb1 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0167-Update-NEWS-file-for-upcoming-3.4-release.patch Type: text/x-patch Size: 667 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0168-Bump-NVR-to-3.4.patch Type: text/x-patch Size: 1197 bytes Desc: not available URL: From akrivoka at redhat.com Tue Jun 25 13:59:34 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 25 Jun 2013 15:59:34 +0200 Subject: [Freeipa-devel] [PATCH] 0041 Fix bug in adtrustinstance Message-ID: <51C9A246.1020201@redhat.com> Hello, Attached patch fixes https://fedorahosted.org/freeipa/ticket/3746. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0041-Fix-bug-in-adtrustinstance.patch Type: text/x-patch Size: 1310 bytes Desc: not available URL: From pspacek at redhat.com Tue Jun 25 14:31:45 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 25 Jun 2013 16:31:45 +0200 Subject: [Freeipa-devel] Announcing bind-dyndb-ldap version 3.4 Message-ID: <51C9A9D1.9050909@redhat.com> The FreeIPA team is proud to announce bind-dyndb-ldap version 3.4. It can be downloaded from https://fedorahosted.org/released/bind-dyndb-ldap/. The new version has also been built for Fedora 19 and and is on its way to updates-testing: https://admin.fedoraproject.org/updates/bind-dyndb-ldap-3.4-1.fc19 This release includes one fix. == Changes in 3.4 == [1] Crash during BIND shutdown caused by race condition in update processing was fixed. == Upgrading == An server can be upgraded simply by installing updated rpms. BIND has to be restarted manually after the RPM installation. You will need to clean up configuration file /etc/named.conf if your configuration contains typos or other unsupported options. Downgrading back to any 2.x version is supported under following conditions: - new object class idnsForwardZone is not utilized - record types not supported by 2.x versions are not utilized - configured connection count is >= 3 (to prevent deadlocks in 2.x releases) == Important change planned for 4.0 release == Configurations with and without persistent search are now deprecated. Support for 'zone_refresh' and 'psearch' options will be removed in 4.0 release. Bind-dyndb-ldap 4.0 will require LDAP server with support for RFC 4533. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list: http://www.redhat.com/mailman/listinfo/freeipa-users -- Petr Spacek Software engineer Red Hat From akrivoka at redhat.com Tue Jun 25 15:28:09 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 25 Jun 2013 17:28:09 +0200 Subject: [Freeipa-devel] [PATCH] 0029 Make sure replication works after DM password is changed In-Reply-To: <51C83B1A.40000@redhat.com> References: <519357F3.3080408@redhat.com> <51935D92.8080407@redhat.com> <51936395.20409@redhat.com> <51937353.3090501@redhat.com> <51B19888.2050803@redhat.com> <51B5E43F.809@redhat.com> <1370961745.2400.96.camel@aleeredhat.laptop> <51C83B1A.40000@redhat.com> Message-ID: <51C9B709.9030707@redhat.com> On 06/24/2013 02:27 PM, Tomas Babej wrote: > On 06/11/2013 04:42 PM, Ade Lee wrote: > [snip] >> Just FYI, we plan to do a new release of pki-core today (pki-core-10.0.3-2) >> to address this issue. >>> -- >>> Regards, >>> >>> Ana Krivokapic >>> Associate Software Engineer >>> FreeIPA team >>> Red Hat Inc. >> > Ok, so I tested the patch, since pki-core has the PkiExport command fixed now. > > I'm getting a little bit further now. > > [tbabej at vm-127 ~]$ sudo ipa-replica-prepare --ip-address 10.34.47.129 > vm-129.idm.lab.eng.brq.redhat.com > Directory Manager (existing master) password: > > Preparing replica for vm-129.idm.lab.eng.brq.redhat.com from > vm-127.idm.lab.eng.brq.redhat.com > Constraint violation: Failed to update password > > With debug output, I get (snipped out irrelevant parts): > > Directory Manager (existing master) password: > > ipa.ipaserver.plugins.ldap2.ldap2: DEBUG: Created connection > context.ldap2_57668944 > ipa.ipapython.ipaldap.SchemaCache: DEBUG: retrieving schema for SchemaCache > url=ldapi://%2fvar%2frun%2fslapd-IDM-LAB-ENG-BRQ-REDHAT-COM.socket > conn= > ipa.ipaserver.plugins.ldap2.ldap2: DEBUG: Destroyed connection > context.ldap2_57668944 > ipa: DEBUG: Search DNS for vm-129.idm.lab.eng.brq.redhat.com > ipa: DEBUG: Search failed: [Errno -2] Name or service not known > ipa.ipapython.ipaldap.SchemaCache: DEBUG: flushing > ldapi://%2fvar%2frun%2fslapd-IDM-LAB-ENG-BRQ-REDHAT-COM.socket from SchemaCache > ipa.ipapython.ipaldap.SchemaCache: DEBUG: retrieving schema for SchemaCache > url=ldapi://%2fvar%2frun%2fslapd-IDM-LAB-ENG-BRQ-REDHAT-COM.socket > conn= > ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: Not logging > to a file > ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: > ipa-replica-prepare was invoked with arguments > ['vm-129.idm.lab.eng.brq.redhat.com'] and options: {'log_file': None, > 'verbose': True, 'reverse_zone': None, 'setup_pkinit': True, 'http_pin': None, > 'quiet': False, 'http_pkcs12': None, 'pkinit_pkcs12': None, 'ca_file': > '/root/cacert.p12', 'no_reverse': False, 'dirsrv_pkcs12': None, 'password': > None, 'ip_address': CheckedIPAddress('10.34.47.129'), 'dirsrv_pin': None, > 'pkinit_pin': None} > ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: INFO: Preparing > replica for vm-129.idm.lab.eng.brq.redhat.com from > vm-127.idm.lab.eng.brq.redhat.com > ipa.ipapython.ipaldap.SchemaCache: DEBUG: flushing > ldapi://%2fvar%2frun%2fslapd-IDM-LAB-ENG-BRQ-REDHAT-COM.socket from SchemaCache > ipa.ipapython.ipaldap.SchemaCache: DEBUG: retrieving schema for SchemaCache > url=ldapi://%2fvar%2frun%2fslapd-IDM-LAB-ENG-BRQ-REDHAT-COM.socket > conn= > ipa: DEBUG: Starting external process > ipa: DEBUG: args=/usr/bin/PKCS12Export -d /etc/pki/pki-tomcat/alias/ -p > /tmp/tmprgUrso -w /tmp/tmp6SBBXF -o /root/cacert.p12 > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr= > ipa.ipaserver.plugins.ldap2.ldap2: DEBUG: Created connection > context.ldap2_139884970376144 > ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: File > "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute > return_value = self.run() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py", > line 245, in run > self.copy_ds_certificate() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py", > line 281, in copy_ds_certificate > self.update_pki_admin_password() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py", > line 520, in update_pki_admin_password > ldap.modify_password(dn, self.dirman_password) > File "/usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py", line > 332, in modify_password > self.conn.passwd_s(dn, old_pass, new_pass) > File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ > self.gen.throw(type, value, traceback) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 919, in > error_handler > raise errors.DatabaseError(desc=desc, info=info) > > ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: The > ipa-replica-prepare command failed, exception: DatabaseError: Constraint > violation: Failed to update password > ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: ERROR: Constraint > violation: Failed to update password > > Tomas It seems that this time the culprit is 389-ds-base packages. The password change is rejected when using the latest version of 389-ds-base (389-ds-base-1.3.1.2-1.fc19.x86_64). I tried testing it with a previous version (389-ds-base-1.3.0.5-1.fc19.x86_64) and it works. I open an upstream ticket for the 389 DS project: https://fedorahosted.org/389/ticket/47406. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From pvoborni at redhat.com Wed Jun 26 06:59:55 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 26 Jun 2013 08:59:55 +0200 Subject: [Freeipa-devel] [PATCH] 426 Create Firefox configuration extension on CA-less install Message-ID: <51CA916B.9030505@redhat.com> Create: * kerberosauth.xpi * krb.js even when --http_pkcs12 option is used. https://fedorahosted.org/freeipa/ticket/3747 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0426-Create-Firefox-configuration-extension-on-CA-less-in.patch Type: text/x-patch Size: 6169 bytes Desc: not available URL: From pspacek at redhat.com Wed Jun 26 08:12:48 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 26 Jun 2013 10:12:48 +0200 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <51C841AC.1050604@redhat.com> References: <1290988309.4979837.1371653165405.JavaMail.root@redhat.com> <51C1D8BF.8070809@redhat.com> <51C1D9C9.7090002@redhat.com> <51C1DA1A.6040800@redhat.com> <51C1DC78.5020209@redhat.com> <20130619164601.GM24492@redhat.com> <51C1E157.4090308@redhat.com> <20130619165652.GA10478@redhat.com> <51C1F34C.5000805@redhat.com> <51C1F8D7.3070109@redhat.com> <20130619185656.GC10478@redhat.com> <51C2AF68.3020606@redhat.com> <51C2B0D6.1020607@redhat.com> <51C2D954.1030207@redhat.com> <51C2DEF8.1040400@redhat.com> <51C3FDBB.7060902@redhat.com> <51C40182.9000306@redhat.com> <51C420AA.4080007@redhat.com> <51C7F6D1.7090004@redhat.com> <51C841AC.1050604@redhat.com> Message-ID: <51CAA280.9090900@redhat.com> On 24.6.2013 14:55, Tomas Babej wrote: > On 06/24/2013 09:35 AM, Petr Spacek wrote: >> What would happen if require_root = False, UID = 1234 but the plugin >> requires root access? (I.e. there is an error in the require_root value.) > > The calling of particular external command that requires root access for its > execution will fail. >> >> I don't like this boolean, because plugin author has to test the plugin and >> maintain the boolean after each change in the plugin. From my (naive) point >> of view it is error prone and unnecessary. > > Why? From my point of view, it simplifies the work for the plugin author, > since he can set the boolean if he knows that plugin will need root access to > require information needed. I see the opposite part: "Root" requirement can change over time (during plugin and IPA development), so the plugin maintainer has to maintain this boolean. > Without it: > - If he wanted to stay user-friendly he would have to implement the check for > effective UID in every plugin. > - If he did not, he would be having his command fail with (often) cryptic errors. > >> >> Proper error handling seems like 'the right way'? to me. >> > > What kind of proper error handling? The errors are now properly handled via > AdminTool's framework. Appropriate error handling = Return 'Permission denied' if particular operation requires higher privileges. IMHO 'cryptic' error message is bad in any case, so the right way how to fix 'cryptic' error messages is to fix the places where errors are thrown. I don't think that additional checks in 'advisor' to hide 'cryptic' errors are the right approach. -- Petr^2 Spacek From pviktori at redhat.com Wed Jun 26 09:01:45 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 26 Jun 2013 11:01:45 +0200 Subject: [Freeipa-devel] [PATCH] 141 Fix CA-less check in ipa-replica-install and ipa-ca-install In-Reply-To: <51C95620.6040506@redhat.com> References: <51C95620.6040506@redhat.com> Message-ID: <51CAADF9.5050909@redhat.com> On 06/25/2013 10:34 AM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza ACK, pushed to master, ipa-3-2 master: 76dc2176f9e53fc7da760a516359f7cb2eb62035 ipa-3-2: 6ff3ef35ee19d49144ce66e88339918a2ab9a355 -- Petr? From mkosek at redhat.com Wed Jun 26 11:42:54 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 26 Jun 2013 13:42:54 +0200 Subject: [Freeipa-devel] [PATCH] 122 Enable SASL mapping fallback In-Reply-To: <5162E2DE.2090307@redhat.com> References: <514C673E.70800@redhat.com> <515DE634.6020105@redhat.com> <5162E085.5030709@redhat.com> <5162E2DE.2090307@redhat.com> Message-ID: <51CAD3BE.5080800@redhat.com> On 04/08/2013 05:31 PM, Rob Crittenden wrote: > Jan Cholasta wrote: >> On 4.4.2013 22:44, Rob Crittenden wrote: >>> This patch works well enough against a devel build at >>> http://nkinder.fedorapeople.org/389-devel/ without the Requires on 1.3.1 >>> (the devel build still claims to be 1.3.0.5). >> >> I bumped Requires because says >> it is planned for 1.3.1. >> >>> >>> The patch itself doesn't do much yet but it does what it says it does. >> >> Correct, it is just a pre-requirement for automated replication recovery >> and external user mapping. >> >> Automated replication recovery is currently in beer exchange: >> . >> >> As for external user mapping, I'm going to need more input on that. >> Alexander and Simo should know more, adding them to CC. >> >> Honza >> > > Sure. I didn't mean to imply anything was wrong with the patch, just that we > couldn't push it just yet. It seems to do the right thing according to the > 389-ds docs, the bits just aren't ready officially yet. > > rob > As 389-ds-base 1.3.1.1 requested in the ticket is already out, I think we should revive these patches. Martin From tbabej at redhat.com Wed Jun 26 12:03:59 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 26 Jun 2013 14:03:59 +0200 Subject: [Freeipa-devel] [PATCH] 412 Remove entitlement support In-Reply-To: <51C16C6D.5080700@redhat.com> References: <51C1683B.60308@redhat.com> <51C16C6D.5080700@redhat.com> Message-ID: <51CAD8AF.3090605@redhat.com> On 06/19/2013 10:31 AM, Petr Vobornik wrote: > On 06/19/2013 10:13 AM, Martin Kosek wrote: >> Entitlements code was not tested nor supported upstream since >> version 3.0. Remove the associated code. >> >> https://fedorahosted.org/freeipa/ticket/3739 >> >> ---- >> >> As agreed on Triage meeting, I plan to push this patch to ipa-3-2 and >> master >> branches. >> >> Martin >> > > > ACK on Web UI part. ACK on the IPA part Tomas From akrivoka at redhat.com Wed Jun 26 12:59:37 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 26 Jun 2013 14:59:37 +0200 Subject: [Freeipa-devel] [PATCH] 425 Do not redirect to https in /ipa/ui on non-HTML files In-Reply-To: <51C96FF8.5070209@redhat.com> References: <51C87040.4070203@redhat.com> <51C87B32.30309@redhat.com> <51C96F73.9060502@redhat.com> <51C96FF8.5070209@redhat.com> Message-ID: <51CAE5B9.9070602@redhat.com> On 06/25/2013 12:24 PM, Petr Vobornik wrote: > On 06/25/2013 12:22 PM, Martin Kosek wrote: >> On 06/24/2013 07:00 PM, Tomas Babej wrote: >>> On 06/24/2013 06:13 PM, Petr Vobornik wrote: >>>> Those resources are needed by page which has to use http(browser config) >>>> prior to acceptance of CA cert. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3748 >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >>> I think you (technically) need to update the version in the first commented >>> line. >> >> Thanks for pointing this out Tomas. I see you learned a lesson last time :-) >> >>> >>> (Probably would not be an issue for anybody, since we haven't done a release >>> since it was last changed) >> >> Yeah, this is not critical. But it may still make sense to bump the number, if >> just for a sake of consistency if someone would do some "git blame" >> investigation based on this line. >> >> Martin >> > > Version bumped, updated patch attached. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Wed Jun 26 13:02:05 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 26 Jun 2013 15:02:05 +0200 Subject: [Freeipa-devel] [PATCH] 122 Enable SASL mapping fallback In-Reply-To: <51CAD3BE.5080800@redhat.com> References: <514C673E.70800@redhat.com> <515DE634.6020105@redhat.com> <5162E085.5030709@redhat.com> <5162E2DE.2090307@redhat.com> <51CAD3BE.5080800@redhat.com> Message-ID: <51CAE64D.9020609@redhat.com> On 26.6.2013 13:42, Martin Kosek wrote: > As 389-ds-base 1.3.1.1 requested in the ticket is already out, I think we > should revive these patches. > > Martin > Rebased patch attached. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-122.1-Enable-SASL-mapping-fallback.patch Type: text/x-patch Size: 5198 bytes Desc: not available URL: From mkosek at redhat.com Wed Jun 26 13:04:12 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 26 Jun 2013 15:04:12 +0200 Subject: [Freeipa-devel] [PATCH] 425 Do not redirect to https in /ipa/ui on non-HTML files In-Reply-To: <51CAE5B9.9070602@redhat.com> References: <51C87040.4070203@redhat.com> <51C87B32.30309@redhat.com> <51C96F73.9060502@redhat.com> <51C96FF8.5070209@redhat.com> <51CAE5B9.9070602@redhat.com> Message-ID: <51CAE6CC.2020408@redhat.com> On 06/26/2013 02:59 PM, Ana Krivokapic wrote: > On 06/25/2013 12:24 PM, Petr Vobornik wrote: >> On 06/25/2013 12:22 PM, Martin Kosek wrote: >>> On 06/24/2013 07:00 PM, Tomas Babej wrote: >>>> On 06/24/2013 06:13 PM, Petr Vobornik wrote: >>>>> Those resources are needed by page which has to use http(browser config) >>>>> prior to acceptance of CA cert. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3748 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>>> I think you (technically) need to update the version in the first commented >>>> line. >>> >>> Thanks for pointing this out Tomas. I see you learned a lesson last time :-) >>> >>>> >>>> (Probably would not be an issue for anybody, since we haven't done a release >>>> since it was last changed) >>> >>> Yeah, this is not critical. But it may still make sense to bump the number, if >>> just for a sake of consistency if someone would do some "git blame" >>> investigation based on this line. >>> >>> Martin >>> >> >> Version bumped, updated patch attached. >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > ACK > Pushed to master, ipa-3-2. Martin From jpazdziora at redhat.com Wed Jun 26 19:43:15 2013 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Wed, 26 Jun 2013 21:43:15 +0200 Subject: [Freeipa-devel] [PATCH] 142 Do not skip SSSD known hosts in ipa-client-install --ssh-trust-dns In-Reply-To: <51C95ADF.10300@redhat.com> References: <51C95ADF.10300@redhat.com> Message-ID: <20130626194315.GE10699@redhat.com> On Tue, Jun 25, 2013 at 10:54:55AM +0200, Jan Cholasta wrote: > > the attached patch fixes . Ack. -- Jan Pazdziora | adelton at #ipa*, #brno Principal Software Engineer, Identity Management Engineering, Red Hat From akrivoka at redhat.com Wed Jun 26 22:26:37 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 27 Jun 2013 00:26:37 +0200 Subject: [Freeipa-devel] [PATCH] 426 Create Firefox configuration extension on CA-less install In-Reply-To: <51CA916B.9030505@redhat.com> References: <51CA916B.9030505@redhat.com> Message-ID: <51CB6A9D.7010105@redhat.com> On 06/26/2013 08:59 AM, Petr Vobornik wrote: > Create: > * kerberosauth.xpi > * krb.js > > even when --http_pkcs12 option is used. > > https://fedorahosted.org/freeipa/ticket/3747 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel In the logging statement in httpinstance.py, 'configure.jar' should be in lower case: root_logger.warning('Object-signing certificate was not found. ' 'Configure.jar was not created.') -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu Jun 27 06:50:02 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 27 Jun 2013 08:50:02 +0200 Subject: [Freeipa-devel] [PATCH] 142 Do not skip SSSD known hosts in ipa-client-install --ssh-trust-dns In-Reply-To: <20130626194315.GE10699@redhat.com> References: <51C95ADF.10300@redhat.com> <20130626194315.GE10699@redhat.com> Message-ID: <51CBE09A.2020802@redhat.com> On 06/26/2013 09:43 PM, Jan Pazdziora wrote: > On Tue, Jun 25, 2013 at 10:54:55AM +0200, Jan Cholasta wrote: >> >> the attached patch fixes . > > Ack. > Pushed to master, ipa-3-2. Martin From mkosek at redhat.com Thu Jun 27 08:20:05 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 27 Jun 2013 10:20:05 +0200 Subject: [Freeipa-devel] [PATCH 0075] Change group ownership of CRL publish directory In-Reply-To: <51C444AF.3070709@redhat.com> References: <51C31C8C.2010200@redhat.com> <51C320E1.4040303@redhat.com> <1371743048.17111.61.camel@willson.li.ssimo.org> <51C3242B.4070604@redhat.com> <1371744027.17111.69.camel@willson.li.ssimo.org> <51C442FD.2000009@redhat.com> <51C443DD.1090202@redhat.com> <51C444AF.3070709@redhat.com> Message-ID: <51CBF5B5.4000501@redhat.com> On 06/21/2013 02:18 PM, Tomas Babej wrote: > On 06/21/2013 02:15 PM, Martin Kosek wrote: >> On 06/21/2013 02:11 PM, Tomas Babej wrote: >>> On 06/20/2013 06:00 PM, Simo Sorce wrote: >>>> On Thu, 2013-06-20 at 17:47 +0200, Martin Kosek wrote: >>>>> On 06/20/2013 05:44 PM, Simo Sorce wrote: >>>>>> On Thu, 2013-06-20 at 17:33 +0200, Martin Kosek wrote: >>>>>>> On 06/20/2013 05:15 PM, Tomas Babej wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Spec file modified so that /var/lib/ipa/pki-ca/publish/ is owned >>>>>>>> by pkiuser group. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/3727 >>>>>>>> >>>>>>>> Tomas >>>>>>>> >>>>>>> NACK. This won't fly. pkiuser is created by FreeIPA when server is >>>>>>> installed, >>>>>>> thus you cannot just simply change ownership in our spec file because in >>>>>>> the >>>>>>> time when package is installed or updated, pkiuser may not exist. >>>>>>> >>>>>>> I think you need to delete the %attr from spec file and set the correct >>>>>>> ownership during ipa-{server,ca}-install. When CA is configured, we should >>>>>>> also >>>>>>> probably let ipa-upgradeconfig check this directory and amend when >>>>>>> necessary >>>>>>> (to fix affected IPA CA instances). >>>>>> Probably even better to not create the directory via rpm at all, but >>>>>> make ipa-ca-install create it and remove it when --uninstall is run. >>>>>> >>>>>> Simo. >>>>> This could also work, sure. Could we then at least mark this directory in our >>>>> spec file as %ghost? So that "rpm -qf /var/lib/ipa/pki-ca/publish/" gives >>>>> some >>>>> information? >>>> I guess so. >>>> >>>> Simo. >>>> >>> Updated version attached. >>> >>> Tomas >> Looks good by reading (I did not test it), maybe just one nitpick: >> >> + root_logger.warning("Error while removing CRL publish " >> + "directory: %s" % str(e)) >> >> This should read: >> + root_logger.warning("Error while removing CRL publish " >> + "directory: %s", e) >> >> We do not need to format the string before it is really logged and we also do >> not need to convert it to "str" as we already requested the conversion to >> string by "%s". >> >> Martin > Fixed. > > Tomas The patch itself works fine, but there are still SELinux related questions and concerns which may also affect the patch (currently it does not work with enforced SELinux). I posted them to the relevant Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=976308 Martin From pvoborni at redhat.com Thu Jun 27 09:48:08 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 27 Jun 2013 11:48:08 +0200 Subject: [Freeipa-devel] [PATCH] 426 Create Firefox configuration extension on CA-less install In-Reply-To: <51CB6A9D.7010105@redhat.com> References: <51CA916B.9030505@redhat.com> <51CB6A9D.7010105@redhat.com> Message-ID: <51CC0A58.4000804@redhat.com> On 06/27/2013 12:26 AM, Ana Krivokapic wrote: > On 06/26/2013 08:59 AM, Petr Vobornik wrote: >> Create: >> * kerberosauth.xpi >> * krb.js >> >> even when --http_pkcs12 option is used. >> >> https://fedorahosted.org/freeipa/ticket/3747 > > In the logging statement in httpinstance.py, 'configure.jar' should be > in lower case: > > root_logger.warning('Object-signing certificate was not > found. ' > 'Configure.jar was not created.') > > -- > Regards, > > Ana Krivokapic Thanks. I've also changed the sentence structure to avoid starting the sentence with lower case letter. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0426-1-Create-Firefox-configuration-extension-on-CA-less-in.patch Type: text/x-patch Size: 6180 bytes Desc: not available URL: From akrivoka at redhat.com Thu Jun 27 10:08:24 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 27 Jun 2013 12:08:24 +0200 Subject: [Freeipa-devel] [PATCH] 426 Create Firefox configuration extension on CA-less install In-Reply-To: <51CC0A58.4000804@redhat.com> References: <51CA916B.9030505@redhat.com> <51CB6A9D.7010105@redhat.com> <51CC0A58.4000804@redhat.com> Message-ID: <51CC0F18.8000506@redhat.com> On 06/27/2013 11:48 AM, Petr Vobornik wrote: > On 06/27/2013 12:26 AM, Ana Krivokapic wrote: >> On 06/26/2013 08:59 AM, Petr Vobornik wrote: >>> Create: >>> * kerberosauth.xpi >>> * krb.js >>> >>> even when --http_pkcs12 option is used. >>> >>> https://fedorahosted.org/freeipa/ticket/3747 >> >> In the logging statement in httpinstance.py, 'configure.jar' should be >> in lower case: >> >> root_logger.warning('Object-signing certificate was not >> found. ' >> 'Configure.jar was not created.') >> >> -- >> Regards, >> >> Ana Krivokapic > > Thanks. > > I've also changed the sentence structure to avoid starting the sentence with > lower case letter. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Thu Jun 27 10:32:20 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 27 Jun 2013 12:32:20 +0200 Subject: [Freeipa-devel] [PATCH] 412 Remove entitlement support In-Reply-To: <51CAD8AF.3090605@redhat.com> References: <51C1683B.60308@redhat.com> <51C16C6D.5080700@redhat.com> <51CAD8AF.3090605@redhat.com> Message-ID: <51CC14B4.7020505@redhat.com> On 26.6.2013 14:03, Tomas Babej wrote: > On 06/19/2013 10:31 AM, Petr Vobornik wrote: >> On 06/19/2013 10:13 AM, Martin Kosek wrote: >>> Entitlements code was not tested nor supported upstream since >>> version 3.0. Remove the associated code. >>> >>> https://fedorahosted.org/freeipa/ticket/3739 >>> >>> ---- >>> >>> As agreed on Triage meeting, I plan to push this patch to ipa-3-2 and >>> master >>> branches. >>> >>> Martin >>> >> >> >> ACK on Web UI part. > > ACK on the IPA part > > Tomas > ipa-upgradeconfig fails for me when upgrading from version with entitlement plugin to version without entitlement plugin: 2013-06-26T22:22:43Z DEBUG /usr/sbin/ipa-upgradeconfig was invoked with options: {'debug': False, 'quiet': True} 2013-06-26T22:22:43Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' 2013-06-26T22:22:43Z DEBUG importing all plugin modules in '/usr/lib/python2.7/site-packages/ipalib/plugins'... 2013-06-26T22:22:43Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/entitle.py' 2013-06-26T22:22:43Z DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 614, in run_script return_value = main_function() File "/usr/sbin/ipa-upgradeconfig", line 872, in main api.finalize() File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 674, in finalize self.__do_if_not_done('load_plugins') File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 454, in __do_if_not_done getattr(self, name)() File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 613, in load_plugins self.import_plugins('ipalib') File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 655, in import_plugins __import__(fullname) File "/usr/lib/python2.7/site-packages/ipalib/plugins/entitle.py", line 180, in class entitle(LDAPObject): File "/usr/lib/python2.7/site-packages/ipalib/plugins/entitle.py", line 184, in entitle container_dn = api.env.container_entitlements 2013-06-26T22:22:43Z DEBUG The ipa-upgradeconfig command failed, exception: AttributeError: 'Env' object has no attribute 'container_entitlements' Honza -- Jan Cholasta From pviktori at redhat.com Thu Jun 27 14:03:45 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 27 Jun 2013 16:03:45 +0200 Subject: [Freeipa-devel] [PATCH] 426 Create Firefox configuration extension on CA-less install In-Reply-To: <51CC0F18.8000506@redhat.com> References: <51CA916B.9030505@redhat.com> <51CB6A9D.7010105@redhat.com> <51CC0A58.4000804@redhat.com> <51CC0F18.8000506@redhat.com> Message-ID: <51CC4641.4090006@redhat.com> On 06/27/2013 12:08 PM, Ana Krivokapic wrote: > On 06/27/2013 11:48 AM, Petr Vobornik wrote: >> On 06/27/2013 12:26 AM, Ana Krivokapic wrote: >>> On 06/26/2013 08:59 AM, Petr Vobornik wrote: >>>> Create: >>>> * kerberosauth.xpi >>>> * krb.js >>>> >>>> even when --http_pkcs12 option is used. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3747 >>> >>> In the logging statement in httpinstance.py, 'configure.jar' should be >>> in lower case: >>> >>> root_logger.warning('Object-signing certificate was not >>> found. ' >>> 'Configure.jar was not created.') >>> >>> -- >>> Regards, >>> >>> Ana Krivokapic >> >> Thanks. >> >> I've also changed the sentence structure to avoid starting the >> sentence with lower case letter. >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > ACK Pushed to master, ipa-3-2. master: f5bc155f56a3673a419f921db18e64f8647065ec ipa-3-2: 2f3d918d749eb6341fd6269435d49fc569ee3d5c -- Petr? From jcholast at redhat.com Thu Jun 27 14:55:25 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 27 Jun 2013 16:55:25 +0200 Subject: [Freeipa-devel] [PATCHES] 143-147 Improve performance with large groups Message-ID: <51CC525D.60702@redhat.com> Hi, the attached patches are an attempt to solve without actually removing ipausers. I have done some basic timing on IPA with 10k users, the results are: ipa user-add: 18 s originally, 4 s with the patches ipa user-del: 54 s originally, 7 s with the patches Other commands should be affected as well, especially del commands (deleting an entry triggers a originally unindexed search in the referint plugin) and member manipulation commands (full member list is no longer fetched and stored back when adding/removing members). Patch 147 fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-143-Use-LDAP-search-instead-of-group_show-to-check-if-a-.patch Type: text/x-patch Size: 5836 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-144-Use-LDAP-search-instead-of-group_show-to-check-for-a.patch Type: text/x-patch Size: 9000 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-145-Use-LDAP-modify-operation-directly-to-add-remove-gro.patch Type: text/x-patch Size: 3272 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-146-Add-missing-substring-indices-for-attributes-searche.patch Type: text/x-patch Size: 7824 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-147-Add-missing-equality-index-for-ipaUniqueId.patch Type: text/x-patch Size: 1409 bytes Desc: not available URL: From mkosek at redhat.com Thu Jun 27 14:56:54 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 27 Jun 2013 16:56:54 +0200 Subject: [Freeipa-devel] [PATCH] 412 Remove entitlement support In-Reply-To: <51CC14B4.7020505@redhat.com> References: <51C1683B.60308@redhat.com> <51C16C6D.5080700@redhat.com> <51CAD8AF.3090605@redhat.com> <51CC14B4.7020505@redhat.com> Message-ID: <51CC52B6.30908@redhat.com> On 06/27/2013 12:32 PM, Jan Cholasta wrote: > On 26.6.2013 14:03, Tomas Babej wrote: >> On 06/19/2013 10:31 AM, Petr Vobornik wrote: >>> On 06/19/2013 10:13 AM, Martin Kosek wrote: >>>> Entitlements code was not tested nor supported upstream since >>>> version 3.0. Remove the associated code. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3739 >>>> >>>> ---- >>>> >>>> As agreed on Triage meeting, I plan to push this patch to ipa-3-2 and >>>> master >>>> branches. >>>> >>>> Martin >>>> >>> >>> >>> ACK on Web UI part. >> >> ACK on the IPA part >> >> Tomas >> > > ipa-upgradeconfig fails for me when upgrading from version with entitlement > plugin to version without entitlement plugin: > > 2013-06-26T22:22:43Z DEBUG /usr/sbin/ipa-upgradeconfig was invoked with > options: {'debug': False, 'quiet': True} > 2013-06-26T22:22:43Z DEBUG Loading Index file from > '/var/lib/ipa/sysrestore/sysrestore.index' > 2013-06-26T22:22:43Z DEBUG importing all plugin modules in > '/usr/lib/python2.7/site-packages/ipalib/plugins'... > > 2013-06-26T22:22:43Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/entitle.py' > 2013-06-26T22:22:43Z DEBUG File > "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 614, > in run_script > return_value = main_function() > > File "/usr/sbin/ipa-upgradeconfig", line 872, in main > api.finalize() > > File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 674, in > finalize > self.__do_if_not_done('load_plugins') > > File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 454, in > __do_if_not_done > getattr(self, name)() > > File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 613, in > load_plugins > self.import_plugins('ipalib') > > File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 655, in > import_plugins > __import__(fullname) > > File "/usr/lib/python2.7/site-packages/ipalib/plugins/entitle.py", line 180, > in > class entitle(LDAPObject): > > File "/usr/lib/python2.7/site-packages/ipalib/plugins/entitle.py", line 184, > in entitle > container_dn = api.env.container_entitlements > > 2013-06-26T22:22:43Z DEBUG The ipa-upgradeconfig command failed, exception: > AttributeError: 'Env' object has no attribute 'container_entitlements' > > Honza > This happens because we run ipa-upgradeconfig in %post while there was still entitlements plugin. I think that clean solution for this plugin (and also for other future occurrences of this issue) is to run upgrade/server restart process only in %posttrans. In the end, I iterated to the attached patch. With this spec change, I was able to upgrade from FreeIPA 3.2 to current master version without any entitlements related upgrade error. Adding Alexander and Rob to CC to double-check this upgrade-related change, I want to be sure I didn't do something stupid. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-413-run-server-upgrade-and-restart-in-posttrans.patch Type: text/x-patch Size: 2810 bytes Desc: not available URL: From mkosek at redhat.com Thu Jun 27 15:12:21 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 27 Jun 2013 17:12:21 +0200 Subject: [Freeipa-devel] [PATCH] 122 Enable SASL mapping fallback In-Reply-To: <51CAE64D.9020609@redhat.com> References: <514C673E.70800@redhat.com> <515DE634.6020105@redhat.com> <5162E085.5030709@redhat.com> <5162E2DE.2090307@redhat.com> <51CAD3BE.5080800@redhat.com> <51CAE64D.9020609@redhat.com> Message-ID: <51CC5655.5020603@redhat.com> On 06/26/2013 03:02 PM, Jan Cholasta wrote: > On 26.6.2013 13:42, Martin Kosek wrote: >> As 389-ds-base 1.3.1.1 requested in the ticket is already out, I think we >> should revive these patches. >> >> Martin >> > > Rebased patch attached. > > Honza > ACK. Pushed to master, ipa-3-2 (rebased). Martin From mkosek at redhat.com Thu Jun 27 15:23:17 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 27 Jun 2013 17:23:17 +0200 Subject: [Freeipa-devel] [PATCHES] 143-147 Improve performance with large groups In-Reply-To: <51CC525D.60702@redhat.com> References: <51CC525D.60702@redhat.com> Message-ID: <51CC58E5.8070500@redhat.com> On 06/27/2013 04:55 PM, Jan Cholasta wrote: > Hi, > > the attached patches are an attempt to solve > without actually removing ipausers. > > I have done some basic timing on IPA with 10k users, the results are: > > ipa user-add: 18 s originally, 4 s with the patches > ipa user-del: 54 s originally, 7 s with the patches > > Other commands should be affected as well, especially del commands (deleting an > entry triggers a originally unindexed search in the referint plugin) and member > manipulation commands (full member list is no longer fetched and stored back > when adding/removing members). > > Patch 147 fixes . > > Honza > Thanks for this effort! I quickly went through the patches, they mostly look harmless. Except the following: Subject: [PATCH 4/5] Add missing substring indices for attributes managed by the referint plugin. AFAIK, sub index is a very expensive index - as we discussed offline - adding Rich to advise and confirm this. I think you added it because some plugin was doing substring/wildcard search when an LDAP entry was being deleted - did you identify which one it is? Because I would rather get rid of the bad search than adding so many sub indices. Secondly, did you also check Web UI performance? I think we could noticeable improve user/group lists performance if we added a new (hidden) option to suppress loading membership information which could then be utilized by Web UI. Adding Petr Vobornik to CC to consider this. Martin From jcholast at redhat.com Thu Jun 27 15:31:12 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 27 Jun 2013 17:31:12 +0200 Subject: [Freeipa-devel] [PATCHES] 143-147 Improve performance with large groups In-Reply-To: <51CC58E5.8070500@redhat.com> References: <51CC525D.60702@redhat.com> <51CC58E5.8070500@redhat.com> Message-ID: <51CC5AC0.1090702@redhat.com> On 27.6.2013 17:23, Martin Kosek wrote: > Thanks for this effort! > > I quickly went through the patches, they mostly look harmless. Except the > following: > > Subject: [PATCH 4/5] Add missing substring indices for attributes managed by > the referint plugin. > > AFAIK, sub index is a very expensive index - as we discussed offline - adding > Rich to advise and confirm this. I think you added it because some plugin was > doing substring/wildcard search when an LDAP entry was being deleted - did you > identify which one it is? Because I would rather get rid of the bad search than > adding so many sub indices. The search is hard-coded in the referint plugin, see . > > Secondly, did you also check Web UI performance? I think we could noticeable > improve user/group lists performance if we added a new (hidden) option to > suppress loading membership information which could then be utilized by Web UI. > Adding Petr Vobornik to CC to consider this. No, not yet. Honza -- Jan Cholasta From rmeggins at redhat.com Thu Jun 27 15:34:42 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 27 Jun 2013 09:34:42 -0600 Subject: [Freeipa-devel] [PATCHES] 143-147 Improve performance with large groups In-Reply-To: <51CC5AC0.1090702@redhat.com> References: <51CC525D.60702@redhat.com> <51CC58E5.8070500@redhat.com> <51CC5AC0.1090702@redhat.com> Message-ID: <51CC5B92.5040905@redhat.com> On 06/27/2013 09:31 AM, Jan Cholasta wrote: > On 27.6.2013 17:23, Martin Kosek wrote: >> Thanks for this effort! >> >> I quickly went through the patches, they mostly look harmless. Except >> the >> following: >> >> Subject: [PATCH 4/5] Add missing substring indices for attributes >> managed by >> the referint plugin. >> >> AFAIK, sub index is a very expensive index - as we discussed offline >> - adding >> Rich to advise and confirm this. I think you added it because some >> plugin was >> doing substring/wildcard search when an LDAP entry was being deleted >> - did you >> identify which one it is? Because I would rather get rid of the bad >> search than >> adding so many sub indices. > > The search is hard-coded in the referint plugin, see > . Not sure if it makes sense to do a wildcard/substr search here - please file a ticket with 389 to investigate. sub index isn't necessarily a bad thing - in this case it may be more beneficial than harmful - if you have enough nsslapd-idlistscanlimit to hold the entire candidate list in a single id list without hurting performance (i.e. a list of 10000 entries is probably ok - a list of 1000000 entries is not) > >> >> Secondly, did you also check Web UI performance? I think we could >> noticeable >> improve user/group lists performance if we added a new (hidden) >> option to >> suppress loading membership information which could then be utilized >> by Web UI. >> Adding Petr Vobornik to CC to consider this. > > No, not yet. > > Honza > From jcholast at redhat.com Thu Jun 27 15:59:59 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 27 Jun 2013 17:59:59 +0200 Subject: [Freeipa-devel] [PATCHES] 143-147 Improve performance with large groups In-Reply-To: <51CC5B92.5040905@redhat.com> References: <51CC525D.60702@redhat.com> <51CC58E5.8070500@redhat.com> <51CC5AC0.1090702@redhat.com> <51CC5B92.5040905@redhat.com> Message-ID: <51CC617F.9090305@redhat.com> On 27.6.2013 17:34, Rich Megginson wrote: > On 06/27/2013 09:31 AM, Jan Cholasta wrote: >> The search is hard-coded in the referint plugin, see >> . >> > > Not sure if it makes sense to do a wildcard/substr search here - please > file a ticket with 389 to investigate. https://fedorahosted.org/389/ticket/47411 -- Jan Cholasta From pspacek at redhat.com Thu Jun 27 16:23:19 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 27 Jun 2013 18:23:19 +0200 Subject: [Freeipa-devel] DNSSEC support design considerations: migration to RBTDB In-Reply-To: <1371824388.17111.118.camel@willson.li.ssimo.org> References: <51924269.8020000@redhat.com> <94125227.1971889.1368606594501.JavaMail.root@redhat.com> <5193A598.4050805@redhat.com> <1369051654.6162.12.camel@willson.li.ssimo.org> <519BA195.9050504@redhat.com> <1369161023.23339.20.camel@willson.li.ssimo.org> <519CDDBA.1010500@redhat.com> <1369252720.2769.23.camel@willson.li.ssimo.org> <519E0D09.3010108@redhat.com> <1369319538.2769.24.camel@willson.li.ssimo.org> <51C2F5E9.10109@redhat.com> <1371824388.17111.118.camel@willson.li.ssimo.org> Message-ID: <51CC66F7.8020001@redhat.com> On 21.6.2013 16:19, Simo Sorce wrote: > On Thu, 2013-06-20 at 14:30 +0200, Petr Spacek wrote: >> On 23.5.2013 16:32, Simo Sorce wrote: >>> On Thu, 2013-05-23 at 14:35 +0200, Petr Spacek wrote: >>>> It looks that we agree on nearly all points (I apologize if >>>> overlooked >>>> something). I will prepare a design document for transition to RBTDB >>>> and then >>>> another design document for DNSSEC implementation. >> >> The current version of the design is available at: >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/RBTDB > > Great write-up, thanks. > >> There are several questions inside (search for text "Question", it should find >> all of them). I would like to get your opinion about the problems. >> >> Note that 389 DS team decided to implement RFC 4533 (syncrepl), so persistent >> search is definitely obsolete and we can do synchronization in some clever way. > > > Answering inline here after quoting the questions for the doc: > > > Periodical re-synchronization > > > > Questions > > * Do we still need periodical re-synchronization if 389 DS > team implements RFC 4533 (syncrepl)? It wasn't > considered in the initial design. > > We probably do. We have to be especially careful of the case when a > replica is re-initialized. We should either automatically detect that > this is happening or change ipa-replica-manage to kick named some how. > > We also need a tool or maybe a special attribute in LDAP that is > monitored so that we can tell bind-dyndb-ldap to do a full rebuild of > the cache on demand. This way admins can force a rebuild if they end up > noticing something wrong. Is it acceptable to let admin to delete files & restart named manually? I don't wont to overcomplicate things at the beginning ... > * What about dynamic updates during re-synchronization? > > Should we return a temporary error ? Or maybe just queue up the change > and apply it right after the resync operation has finished ? Unfortunately, the only reasonable error code is SERVFAIL. It is completely up to client if it tries to do update again or not. I personally don't like queuing of updates because it confuses clients: Update is accepted by server but the client still can see an old value (for limited period of time). > * How to get sorted list of entries from LDAP? Use LDAP > server-side sorting? Do we have necessary indices? > > We can do client side sorting as well I guess, I do not have a strong > opinion here. The main reason why you need ordering is to detect delete > records right ? Exactly. I realized that server-side sorting doesn't make sense because we plan to use syncrepl, so there is nothing to sort - only the flow of incremental updates. > Is thee a way to mark rdtdb records as updated instead > (with a generation number) and then do a second pass on the rbtdb tree > and remove any record that was not updated with the generation number ? There is no 'generation' number, but we can extend the auxiliary database (i.e. database with UUID=>DNS name mapping) with generation number. We will get UUID along with each update from LDAP, so we can simply use UUID for database lookup. Then we can go though the UUID database and delete all records which don't have generation == expected_value. > This would also allow us to keep accepting dynamic updates by simply > marking records as generation+1 so that the resync will not overwrite > records that are updated during the resync phase. I agree. The simplest variant can solve the basic case where 1 update was received during re-synchronization. Proposed (simple) solution: 1) At the beginning of re-synchronization, set curr_gen = prev_gen+1 2) For each entry in LDAP do (via syncrepl): - Only if entry['gen'] < curr_gen: -- Overwrite data in local RBTDB with data from LDAP -- Overwrite entry['gen'] = curr_gen - Else: Do nothing In parallel: 1) Update request received from a client 2) Write new data to LDAP (syncrepl should cope with this) 3) Read UUID from LDAP (via RFC 4527 controls) 4) Write curr_gen to UUID database 5) Write data to local RBTDB 6) Reply 'update accepted' to the client Crash at any time should not hurt: Curr_gen will be incremented on restart and re-sychronization will be restarted. The worst case is that update will be stored in LDAP but client will not get reply because of crash (i.e. client times out). There is a drawback: Two or more successive updates to a single entry can create race condition, as described at https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/RBTDB#Raceconditions1 . The reason is that generation number is not incremented each time, but only overwritten with current global value (i.e. old + 1). I don't like the other option with incrementing generation number. It could create nasty corner cases during re-synchronization and handling updates made directly in LDAP/by other DNS server. It is not nice, but I think that we can live with it. The important fact is that consistency will be (eventually) re-established. > > (Filesystem) cache maintenance > > > Questions: How often should we save the cache from operating > memory to disk? > > Prerequisite to be able to evaluate this question. How expensive is it > to save the cache ? My test zone contains 65535 AAAA records, 255 A records, 1 SOA + 1 NS record. Benchmark results: zone dump < 0.5 s (to text file) zone load < 1 s (from text file) zone delete < 9 s (LOL. This is caused by implementation details of RBTDB.) LDAP search on the whole sub-tree: < 15 s Load time for bind-dyndb-ldap 3.x: < 120 s > Is DNS responsive during the save or does the > operation block updates or other functionality ? AFAIK it should not affect anything. Internal transaction mechanism should handle all these situations and allow queries/updates to proceed. > * On shutdown only? > > NACK, you are left with very stale data on crashes. > > * On start-up (after initial synchronization) and on > shutdown? > > It makes sense to dump right after a big synchronization if it doesn't > add substantial operational issues. Otherwise maybe a short interval > after synchronization. > > * Periodically? How often? At the end of periodical > re-synchronization? > > Periodically is probably a good idea, if I understand it correctly it > means that it will make it possible to substantially reduce the load on > startup as we will have less data to fetch from a syncrepl requiest. We probably misunderstood each other. I thought that re-synchronization will trigger full re-load from LDAP, so the whole sub-tree will be transferred on each re-synchronization. (I.e. syncrepl will be started again without the 'cookie'.) For example: time|event 0:00 BIND start, changes from the last known state requested 0:02 changes were applied to local copy - consistency should be restored 0:05 incremental update from LDAP came in 0:55 DNS dynamic update came in, local copy & LDAP were updated 0:55 incremental update from LDAP came in (i.e. the update from previous line) 1:05 incremental update from LDAP came in 4:05 incremental update from LDAP came in 8:00 full reload is started (by timer) 8:05 full reload is finished (all potential inconsistencies were corrected) 9:35 incremental update from LDAP came in ... It is pretty demanding game. That is the reason why I asked if we want to do re-synchronizations automatically... Originally, I planed to write a script which would compare data in LDAP with zone file on disk. This script could be used for debugging & automated testing, so we can assess if the code behaves correctly and decide if we want to implement automatic re-synchronization when necessary. In all cases, the admin can simply delete files on disk and restart BIND - everything will be downloaded from LDAP again. > * Each N updates? > > I prefer a combination of each N updates but with time limits to avoid > doing it too often. > Ie something like every 1000 changes but not more often than every 30 > minutes and not less often than 8 hours. (Numbers completely made up and > need to be tuned based on the answer about the prerequisites question > above). Sounds reasonable. > * If N % of the database was changed? (pspacek's favorite) > > The problem with using % database is that for very small zones you risk > getting stuff saved too often, as changing a few records quickly makes > the % big compared to the zone size. For example a zone with 50 records > has a 10% change after just 5 records are changed. Conversely a big zone > requires a huge amount of changes before the % of changes builds up > leading potentially to dumping the database too infrequently. Example, > zone with 100000 records, means you have to get 10000 changes before you > come to the 10% mark. If dyndns updates are disabled this means the zone > may never get saved for weeks or months. > A small zone will also syncrepl quickly so it would be useless to save > it often while a big zone is better if it is up to date on disk so the > syncrepl operation will cost less on startup. > > Finally N % is also hard to compute. What do you consider into it ? > Only total number of record changed ? Or do you factor in also if the > same record is changed multiple times ? > Consider fringe cases, zone with 1000 entries where only 1 entry is > changed 2000 times in a short period (malfunctioning client (or attack) > sending lots of updates for their record. I will add another option: * After each re-synchronization (including start-up) + on shutdown. This is my favourite, but it is dependent on re-synchronization intervals. It could be combined with 'each N updates + time limits' described above. > Additional questions: > > I see you mention: > "Cache non-existing records, i.e. do not repeat LDAP search for each > query" > > I assume this is fine and we rely on syncrepl to give us an update and > override the negative cache if the record that has been negatively > cached suddenly appears via replication through another master, right ? Yes. The point is that there will not be any 'cache', but authoritative copy of the DNS sub-tree in LDAP. Hit or miss in the 'local copy' will be authoritative. > If we rely on syncrepl, are we going to ever make direct LDAP searches > at all ? Or do we rely fully on having it send us any changes and > therefore we always reply directly from the rbtdb database ? Basically yes, we don't need to do any search. We will use separate connections only LDAP modifications (DNS dynamic updates). The only 'search-like' operation (except syncrepl) will be Read Entry Controls after modification (RFC 4527). This allows us to read UUID of newly created entry in LDAP without an additional search. -- Petr^2 Spacek From simo at redhat.com Thu Jun 27 16:43:21 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 27 Jun 2013 12:43:21 -0400 Subject: [Freeipa-devel] DNSSEC support design considerations: migration to RBTDB In-Reply-To: <51CC66F7.8020001@redhat.com> References: <51924269.8020000@redhat.com> <94125227.1971889.1368606594501.JavaMail.root@redhat.com> <5193A598.4050805@redhat.com> <1369051654.6162.12.camel@willson.li.ssimo.org> <519BA195.9050504@redhat.com> <1369161023.23339.20.camel@willson.li.ssimo.org> <519CDDBA.1010500@redhat.com> <1369252720.2769.23.camel@willson.li.ssimo.org> <519E0D09.3010108@redhat.com> <1369319538.2769.24.camel@willson.li.ssimo.org> <51C2F5E9.10109@redhat.com> <1371824388.17111.118.camel@willson.li.ssimo.org> <51CC66F7.8020001@redhat.com> Message-ID: <1372351401.18685.35.camel@willson.li.ssimo.org> On Thu, 2013-06-27 at 18:23 +0200, Petr Spacek wrote: > On 21.6.2013 16:19, Simo Sorce wrote: > > On Thu, 2013-06-20 at 14:30 +0200, Petr Spacek wrote: > >> On 23.5.2013 16:32, Simo Sorce wrote: > >>> On Thu, 2013-05-23 at 14:35 +0200, Petr Spacek wrote: > >>>> It looks that we agree on nearly all points (I apologize if > >>>> overlooked > >>>> something). I will prepare a design document for transition to RBTDB > >>>> and then > >>>> another design document for DNSSEC implementation. > >> > >> The current version of the design is available at: > >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/RBTDB > > > > Great write-up, thanks. > > > >> There are several questions inside (search for text "Question", it should find > >> all of them). I would like to get your opinion about the problems. > >> > >> Note that 389 DS team decided to implement RFC 4533 (syncrepl), so persistent > >> search is definitely obsolete and we can do synchronization in some clever way. > > > > > > Answering inline here after quoting the questions for the doc: > > > > > Periodical re-synchronization > > > > > > Questions > > > > * Do we still need periodical re-synchronization if 389 DS > > team implements RFC 4533 (syncrepl)? It wasn't > > considered in the initial design. > > > > We probably do. We have to be especially careful of the case when a > > replica is re-initialized. We should either automatically detect that > > this is happening or change ipa-replica-manage to kick named some how. > > > > We also need a tool or maybe a special attribute in LDAP that is > > monitored so that we can tell bind-dyndb-ldap to do a full rebuild of > > the cache on demand. This way admins can force a rebuild if they end up > > noticing something wrong. > Is it acceptable to let admin to delete files & restart named manually? I > don't wont to overcomplicate things at the beginning ... Sure, probably fine, we can have a tool that simply just does that for starters, and later on we can make it do more complex things if needed. > > * What about dynamic updates during re-synchronization? > > > > Should we return a temporary error ? Or maybe just queue up the change > > and apply it right after the resync operation has finished ? > Unfortunately, the only reasonable error code is SERVFAIL. It is completely up > to client if it tries to do update again or not. > > I personally don't like queuing of updates because it confuses clients: Update > is accepted by server but the client still can see an old value (for limited > period of time). Another option is to mark fields so that they are not updated with older values, and just allow the thing to succeed. > > * How to get sorted list of entries from LDAP? Use LDAP > > server-side sorting? Do we have necessary indices? > > > > We can do client side sorting as well I guess, I do not have a strong > > opinion here. The main reason why you need ordering is to detect delete > > records right ? > Exactly. I realized that server-side sorting doesn't make sense because we > plan to use syncrepl, so there is nothing to sort - only the flow of > incremental updates. Syncrepl includes notice of deletions too, right ? > > Is thee a way to mark rdtdb records as updated instead > > (with a generation number) and then do a second pass on the rbtdb tree > > and remove any record that was not updated with the generation number ? > There is no 'generation' number, but we can extend the auxiliary database > (i.e. database with UUID=>DNS name mapping) with generation number. We will > get UUID along with each update from LDAP, so we can simply use UUID for > database lookup. > > Then we can go though the UUID database and delete all records which don't > have generation == expected_value. Yes, something like this should work. > > This would also allow us to keep accepting dynamic updates by simply > > marking records as generation+1 so that the resync will not overwrite > > records that are updated during the resync phase. > I agree. The simplest variant can solve the basic case where 1 update was > received during re-synchronization. > > Proposed (simple) solution: > 1) At the beginning of re-synchronization, set curr_gen = prev_gen+1 > 2) For each entry in LDAP do (via syncrepl): > - Only if entry['gen'] < curr_gen: > -- Overwrite data in local RBTDB with data from LDAP > -- Overwrite entry['gen'] = curr_gen > - Else: Do nothing > > In parallel: > 1) Update request received from a client > 2) Write new data to LDAP (syncrepl should cope with this) > 3) Read UUID from LDAP (via RFC 4527 controls) > 4) Write curr_gen to UUID database > 5) Write data to local RBTDB > 6) Reply 'update accepted' to the client > > Crash at any time should not hurt: Curr_gen will be incremented on restart and > re-sychronization will be restarted. Yep. > The worst case is that update will be stored in LDAP but client will not get > reply because of crash (i.e. client times out). Not a big deal. This can always happen for clients, as the network connection might be severed after the reply is sent and before is received. So clients must always be prepared for this event. > There is a drawback: Two or more successive updates to a single entry can > create race condition, as described at > https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/RBTDB#Raceconditions1 . > > The reason is that generation number is not incremented each time, but only > overwritten with current global value (i.e. old + 1). > > > I don't like the other option with incrementing generation number. It could > create nasty corner cases during re-synchronization and handling updates made > directly in LDAP/by other DNS server. > > It is not nice, but I think that we can live with it. The important fact is > that consistency will be (eventually) re-established. Yes, I think it is a corner case we can live with. > > > (Filesystem) cache maintenance > > > > > Questions: How often should we save the cache from operating > > memory to disk? > > > > Prerequisite to be able to evaluate this question. How expensive is it > > to save the cache ? > My test zone contains 65535 AAAA records, 255 A records, 1 SOA + 1 NS record. > > Benchmark results: > zone dump < 0.5 s (to text file) > zone load < 1 s (from text file) > zone delete < 9 s (LOL. This is caused by implementation details of RBTDB.) > > LDAP search on the whole sub-tree: < 15 s Ouch, this looks very slow, missing indexes ?) Is this just the search? or is it search + zone load ? > Load time for bind-dyndb-ldap 3.x: < 120 s So, a reload from scratch can take many 10s of seconds on big zones, did this test include DNSSEC signing ? Or would we need to add that on top ? > > Is DNS responsive during the save or does the > > operation block updates or other functionality ? > AFAIK it should not affect anything. Internal transaction mechanism should > handle all these situations and allow queries/updates to proceed. > > > * On shutdown only? > > > > NACK, you are left with very stale data on crashes. > > > > * On start-up (after initial synchronization) and on > > shutdown? > > > > It makes sense to dump right after a big synchronization if it doesn't > > add substantial operational issues. Otherwise maybe a short interval > > after synchronization. > > > > * Periodically? How often? At the end of periodical > > re-synchronization? > > > > Periodically is probably a good idea, if I understand it correctly it > > means that it will make it possible to substantially reduce the load on > > startup as we will have less data to fetch from a syncrepl requiest. > We probably misunderstood each other. I thought that re-synchronization will > trigger full re-load from LDAP, so the whole sub-tree will be transferred on > each re-synchronization. (I.e. syncrepl will be started again without the > 'cookie'.) No, this was my understanding as well. > For example: > time|event > 0:00 BIND start, changes from the last known state requested > 0:02 changes were applied to local copy - consistency should be restored > 0:05 incremental update from LDAP came in > 0:55 DNS dynamic update came in, local copy & LDAP were updated > 0:55 incremental update from LDAP came in (i.e. the update from previous line) > 1:05 incremental update from LDAP came in > 4:05 incremental update from LDAP came in > 8:00 full reload is started (by timer) > 8:05 full reload is finished (all potential inconsistencies were corrected) > 9:35 incremental update from LDAP came in > ... > > It is pretty demanding game. That is the reason why I asked if we want to do > re-synchronizations automatically... Right. > Originally, I planed to write a script which would compare data in LDAP with > zone file on disk. This script could be used for debugging & automated > testing, so we can assess if the code behaves correctly and decide if we want > to implement automatic re-synchronization when necessary. Wouldn't this script be subject to races depending at what time it is accessing either LDAP or the file ? The main issue here is that it is hard to know when doing a full re-sync is necessary. And because it is expensive I am wary of doing it automatically too often. However perhaps a timed event so it is done once a day it is not a bad idea. > In all cases, the admin can simply delete files on disk and restart BIND - > everything will be downloaded from LDAP again. Right, we should wrap this knowledge into a tool that does it for the admin like we did with the sss_cache tool for sssd caches. > > * Each N updates? > > > > I prefer a combination of each N updates but with time limits to avoid > > doing it too often. > > Ie something like every 1000 changes but not more often than every 30 > > minutes and not less often than 8 hours. (Numbers completely made up and > > need to be tuned based on the answer about the prerequisites question > > above). > Sounds reasonable. > > > * If N % of the database was changed? (pspacek's favorite) > > > > The problem with using % database is that for very small zones you risk > > getting stuff saved too often, as changing a few records quickly makes > > the % big compared to the zone size. For example a zone with 50 records > > has a 10% change after just 5 records are changed. Conversely a big zone > > requires a huge amount of changes before the % of changes builds up > > leading potentially to dumping the database too infrequently. Example, > > zone with 100000 records, means you have to get 10000 changes before you > > come to the 10% mark. If dyndns updates are disabled this means the zone > > may never get saved for weeks or months. > > A small zone will also syncrepl quickly so it would be useless to save > > it often while a big zone is better if it is up to date on disk so the > > syncrepl operation will cost less on startup. > > > > Finally N % is also hard to compute. What do you consider into it ? > > Only total number of record changed ? Or do you factor in also if the > > same record is changed multiple times ? > > Consider fringe cases, zone with 1000 entries where only 1 entry is > > changed 2000 times in a short period (malfunctioning client (or attack) > > sending lots of updates for their record. > > I will add another option: > * After each re-synchronization (including start-up) + on shutdown. > > This is my favourite, but it is dependent on re-synchronization intervals. It > could be combined with 'each N updates + time limits' described above. > > > > Additional questions: > > > > I see you mention: > > "Cache non-existing records, i.e. do not repeat LDAP search for each > > query" > > > > I assume this is fine and we rely on syncrepl to give us an update and > > override the negative cache if the record that has been negatively > > cached suddenly appears via replication through another master, right ? > Yes. The point is that there will not be any 'cache', but authoritative copy > of the DNS sub-tree in LDAP. Hit or miss in the 'local copy' will be > authoritative. Ok. > > If we rely on syncrepl, are we going to ever make direct LDAP searches > > at all ? Or do we rely fully on having it send us any changes and > > therefore we always reply directly from the rbtdb database ? > Basically yes, we don't need to do any search. We will use separate > connections only LDAP modifications (DNS dynamic updates). Ok. > The only 'search-like' operation (except syncrepl) will be Read Entry Controls > after modification (RFC 4527). This allows us to read UUID of newly created > entry in LDAP without an additional search. Makes sense. Thanks a lot this plan looks good to me. Ship it! :-) Simo. -- Simo Sorce * Red Hat, Inc * New York From pvoborni at redhat.com Fri Jun 28 13:00:29 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 28 Jun 2013 15:00:29 +0200 Subject: [Freeipa-devel] [PATCH] 427 Disable checkboxes and radios for readonly attributes Message-ID: <51CD88ED.3040600@redhat.com> https://fedorahosted.org/freeipa/ticket/3764 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0427-Disable-checkboxes-and-radios-for-readonly-attribute.patch Type: text/x-patch Size: 2977 bytes Desc: not available URL: From abokovoy at redhat.com Fri Jun 28 19:16:54 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 28 Jun 2013 22:16:54 +0300 Subject: [Freeipa-devel] F19 is broken w.r.t. user password change Message-ID: <20130628191653.GA24422@redhat.com> Hi! Found today when preparing my talk at LVEE conference: When running 'ipa passwd ' or 'kinit ' for the first time (i.e. forcing a password change), ipa-pwd-extop causes denial of password change: [28/Jun/2013:22:02:43 +0300] ipa-pwd-extop - Received extended operation request with OID 1.3.6.1.4.1.4203.1.11.1 .... [28/Jun/2013:22:02:43 +0300] ipa-pwd-extop - Pre-Encoded passwords are not valid [28/Jun/2013:22:02:43 +0300] roles-plugin - --> roles_post_op [28/Jun/2013:22:02:43 +0300] roles-plugin - --> roles_cache_change_notify [28/Jun/2013:22:02:43 +0300] roles-plugin - <-- roles_post_op [28/Jun/2013:22:02:43 +0300] ipa-pwd-extop - Failed to update password Apparently, we receive password encoded as {SSHA} scheme and it breaks any password change. Appropriate code checks are in daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c:719-738 I've reproduced it with Fedora 19 RC2 ISO, with git master rpms, and with freeipa-devel repo. Basically, this is release blocker for 3.3 right now. -- / Alexander Bokovoy From abokovoy at redhat.com Sat Jun 29 04:46:50 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 29 Jun 2013 07:46:50 +0300 Subject: [Freeipa-devel] F19 is broken w.r.t. user password change In-Reply-To: <20130628191653.GA24422@redhat.com> References: <20130628191653.GA24422@redhat.com> Message-ID: <20130629044650.GE24422@redhat.com> On Fri, 28 Jun 2013, Alexander Bokovoy wrote: >Hi! > >Found today when preparing my talk at LVEE conference: > >When running 'ipa passwd ' or 'kinit ' for the first time >(i.e. forcing a password change), ipa-pwd-extop causes denial of >password change: > >[28/Jun/2013:22:02:43 +0300] ipa-pwd-extop - Received extended operation request with OID 1.3.6.1.4.1.4203.1.11.1 >.... >[28/Jun/2013:22:02:43 +0300] ipa-pwd-extop - Pre-Encoded passwords are not valid >[28/Jun/2013:22:02:43 +0300] roles-plugin - --> roles_post_op >[28/Jun/2013:22:02:43 +0300] roles-plugin - --> roles_cache_change_notify >[28/Jun/2013:22:02:43 +0300] roles-plugin - <-- roles_post_op >[28/Jun/2013:22:02:43 +0300] ipa-pwd-extop - Failed to update password > >Apparently, we receive password encoded as {SSHA} scheme and it breaks >any password change. Appropriate code checks are in >daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c:719-738 > >I've reproduced it with Fedora 19 RC2 ISO, with git master rpms, and >with freeipa-devel repo. Basically, this is release blocker for 3.3 >right now. Thanks to Nathan to point out to this change in 389-ds-base: http://directory.fedoraproject.org/wiki/Password_Administrator I added passwordAdminDn: cn=admins,cn=groups,cn=accounts,$SUFFIX to cn=config and got it fixed for stock FreeIPA configuration. However, the change like this would not be enough for delegated roles. Patch that fixes basic problem is attached, please review. -- / Alexander Bokovoy -------------- next part -------------- >From 47c4334c53e6b92a791561b25e83e37ed19decce Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Sat, 29 Jun 2013 07:01:10 +0300 Subject: [PATCH] set passwordAdminDN by default in cn=config In 389-ds directory adminstrators can define a user, or a group of users, who are "Password Administrators", for example helpdesk employees. Set password administrators to cn=admins,cn=groups,cn=accounts,$SUFFIX by default. Without passwordAdminDN attribute set, neither user can change their password via FreeIPA, nor admins can reset user passwords with 389-ds-base 1.3.1.2-1. --- install/updates/10-config.update | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/install/updates/10-config.update b/install/updates/10-config.update index c631b2c..1a57ba0 100644 --- a/install/updates/10-config.update +++ b/install/updates/10-config.update @@ -4,6 +4,11 @@ dn: cn=config only:nsslapd-ssl-check-hostname: on +# Make sure cn=admins are capable to change password schema +# See http://directory.fedoraproject.org/wiki/Password_Administrator for details +dn: cn=config +only:passwordAdminDN: 'cn=admins,cn=groups,cn=accounts,$SUFFIX' + # Remove incorrect placement dn: cn=Kerberos Principal Name,cn=IPA MODRDN,cn=plugins,cn=config remove: nsslapd-pluginPrecedence: 60 @@ -57,3 +62,4 @@ addifnew:nsSaslMapPriority: 10 dn: cn=Name Only,cn=mapping,cn=sasl,cn=config addifnew:nsSaslMapPriority: 10 + -- 1.8.1.4 From simo at redhat.com Sat Jun 29 17:03:39 2013 From: simo at redhat.com (Simo Sorce) Date: Sat, 29 Jun 2013 13:03:39 -0400 Subject: [Freeipa-devel] F19 is broken w.r.t. user password change In-Reply-To: <20130629044650.GE24422@redhat.com> References: <20130628191653.GA24422@redhat.com> <20130629044650.GE24422@redhat.com> Message-ID: <1372525419.31944.13.camel@willson.li.ssimo.org> On Sat, 2013-06-29 at 07:46 +0300, Alexander Bokovoy wrote: > On Fri, 28 Jun 2013, Alexander Bokovoy wrote: > >Hi! > > > >Found today when preparing my talk at LVEE conference: > > > >When running 'ipa passwd ' or 'kinit ' for the first time > >(i.e. forcing a password change), ipa-pwd-extop causes denial of > >password change: > > > >[28/Jun/2013:22:02:43 +0300] ipa-pwd-extop - Received extended operation request with OID 1.3.6.1.4.1.4203.1.11.1 > >.... > >[28/Jun/2013:22:02:43 +0300] ipa-pwd-extop - Pre-Encoded passwords are not valid > >[28/Jun/2013:22:02:43 +0300] roles-plugin - --> roles_post_op > >[28/Jun/2013:22:02:43 +0300] roles-plugin - --> roles_cache_change_notify > >[28/Jun/2013:22:02:43 +0300] roles-plugin - <-- roles_post_op > >[28/Jun/2013:22:02:43 +0300] ipa-pwd-extop - Failed to update password > > > >Apparently, we receive password encoded as {SSHA} scheme and it breaks > >any password change. Appropriate code checks are in > >daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c:719-738 > > > >I've reproduced it with Fedora 19 RC2 ISO, with git master rpms, and > >with freeipa-devel repo. Basically, this is release blocker for 3.3 > >right now. > Thanks to Nathan to point out to this change in 389-ds-base: > http://directory.fedoraproject.org/wiki/Password_Administrator > > I added > > passwordAdminDn: cn=admins,cn=groups,cn=accounts,$SUFFIX > > to cn=config and got it fixed for stock FreeIPA configuration. > However, the change like this would not be enough for delegated roles. > > Patch that fixes basic problem is attached, please review. Although the patch 'fixes' the problem for the admin group it break s the IPA model. We need to get a way to disable this behavior in 389DS (we already do our own checks since long), and work for a long term solution where policy checks can be delegated to a plugin. It is a priority to revert the new logic in 389DS immediately, and work on a plan. Simo. -- Simo Sorce * Red Hat, Inc * New York