Re: [Freeipa-devel] [PATCH 0364] Remove unused files rdlist.c and rdlist.h
On 18.5.2015 17:10, Lukas Slebodnik wrote: On (15/05/15 11:44), Petr Spacek wrote: Hello, Remove unused files rdlist.c and rdlist.h. I noticed this cruft while preparing the previous patchset. This patch is independent and applicable directly to master branch. I had an issue with applicable directly to master branch :-) I had to use 3-way merge. You know, master is fast-moving target :-) From 274f5ea92866c50c77c59f6dabc64c3bdf162ace Mon Sep 17 00:00:00 2001 From: Petr Spacek pspa...@redhat.com Date: Fri, 15 May 2015 11:41:02 +0200 Subject: [PATCH] Remove unused files rdlist.c and rdlist.h. --- src/Makefile.am | 2 - src/ldap_driver.c | 1 - src/ldap_helper.c | 1 - src/rdlist.c| 261 src/rdlist.h| 46 - src/zone_register.c | 1 - 6 files changed, 312 deletions(-) delete mode 100644 src/rdlist.c delete mode 100644 src/rdlist.h Functions are not used since commit a78db0312873babbccd4a94dec90b46b02c694ad Author: Petr Spacek pspa...@redhat.com Date: Wed Aug 14 14:41:17 2013 +0200 Use RBTDB instead of internal LDAP cache. make distcheck passed. ACK Thank you! Pushed to master: 3f7c8bbd18f467f5fd596c1458f97d1a9cb68e76 -- Petr^2 Spacek -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] Password vault
Dne 18.5.2015 v 21:17 Endi Sukma Dewata napsal(a): Please take a look at the attached new patch which includes some of your changes you proposed. On 5/14/2015 7:17 PM, Endi Sukma Dewata wrote: On 5/14/2015 1:42 PM, Jan Cholasta wrote: Question: Services in IPA are identified by Kerberos principal. Why are service vaults identified by hostname alone? The service vaults are actually identified by the hostname and service name assuming the principal is in this format: name/host@realm. The vault is stored in cn=name, cn=host, cn=services, cn=vaults, suffix. When accessing a vault service you are supposed to specify the name and the host (except for vault-find which will return all services in the same host): $ ipa vault-find --host host $ ipa vault-add name --host host Are there other service principal formats that we need to support? Do we need to support services of different realms? Well, users are identified by username (uid attribute), hosts by hostname (fqdn attribute) and services by principal name (krbprincipalname attribute). Each of them has separate container and is also uniquely identified by principal name. I guess it would make sense to follow that for vaults as well, in which case service vaults should be called host vaults (because they are created in a host-specific container, not a service-specific one) and maybe real service vaults should be added. There's no plan for host vaults in the design doc, but it's not impossible to add it in the future. What is the use case? I suppose we can change the service vault into a container, and possibly add generic user vaults too (in addition to private user vaults), the interface will look like this: $ ipa vault-add PrivateVault $ ipa vault-add ServiceVault --service name/hostname $ ipa vault-add SharedVault --shared $ ipa vault-add UsersVault --user username $ ipa vault-add HostVault --host hostname Basically we'll need a new parameter for each new container. For the initial implementation we only need the first 2 or 3. I changed the 'host vaults' to become 'service vaults'. The interface will look like this: $ ipa vault-find --service HTTP/server.example.com $ ipa vault-add test --service HTTP/server.example.com I also added user vaults: $ ipa vault-find --user testuser $ ipa vault-add test --user testuser Private vaults is a special case of user vaults where username=you. Host vaults can be added later once we define the use case. OK. 1. The following code in get_dn() is causing problems for vault-find. dn = super(vault, self).get_dn(*keys, **options) rdn = dn[0] container_dn = DN(*dn[1:]) The super.get_dn() will return cn=vaults, suffix, so the rdn will become cn=vaults and container_dn will become suffix. When combined with the subcontainer (private/shared/service) it will produce an invalid DN. Right, fixed. I should have tested the patch before posting it, my bad, sorry. OK. This change has been included in this patch. OK. 2. Not sure if it'related to #1, the vault-find is failing. $ ipa vault-find ipa: ERROR: an internal error has occurred The error_log shows TypeError: 'NoneType' object is not iterable Fixed. It was caused by missing return value in vault_find.exc_callback. We can actually ignore all NotFound errors since now all containers are either created automatically or already created by default. if call_func.__name__ == 'find_entries': if isinstance(exc, errors.NotFound): shared = options.get('shared') # if private or service container has not been created, ignore if not shared: raise errors.EmptyResult(reason=str(exc)) The original code was only ignoring NotFound errors on user vaults because previously only the user containers was supposed to be created automatically, and there wasn't a plan to provide service container. This change has been included and it will ignore all NotFound errors. OK. 3. The --shared option in vault-find is now requiring an argument even though it's a Flag. $ ipa vault-find --shared Usage: ipa [global-options] vault-find [CRITERIA] [options] ipa: error: --shared option requires an argument Fixed. OK. Not sure which code you changed, but the new patch doesn't exhibit this problem. I changed Flag('shared') to Flag('shared?'). 4. The following code in get_dn() is incorrect: principal = getattr(context, 'principal') (name, realm) = split_principal(principal) name = name.split('/') if len(name) == 1: container_dn = DN(('cn', 'users'), container_dn) else: container_dn = DN(('cn', 'services'), container_dn) container_dn = DN(('cn', name[-1]), container_dn) A service does not have a private container like users (cn=username, cn=users, cn=vaults). The entry cn=name, cn=host, cn=services, cn=vaults is a service vault, not a container. The service vault is used by the admin to provide a secret for a service. I'm not sure what the behavior should
Re: [Freeipa-devel] [PATCHES 0001-0007] Profile management
Dne 15.5.2015 v 14:27 Martin Basti napsal(a): On 15/05/15 10:24, Fraser Tweedale wrote: Please find attached latest patches including new patches: - 0006 enable LDAP-based profiles in Dogtag on upgrade - 0007 import included profiles during install or upgrade There is one TODO in the patches where some more code is needed on Dogtag side, and another TODO (not in patches) to migrate caIPAserviceCert profile to DefaultService profile and switch to using DefaultService for cerificate issuance (as the default profile). Jan and Martin, further comments to earlier reviews inline. Cheers, Fraser On Wed, May 13, 2015 at 10:39:55AM +0200, Jan Cholasta wrote: Dne 13.5.2015 v 10:36 Martin Basti napsal(a): On 13/05/15 10:06, Jan Cholasta wrote: Hi, Dne 5.5.2015 v 10:38 Martin Basti napsal(a): On 05/05/15 08:29, Fraser Tweedale wrote: On Mon, May 04, 2015 at 06:35:45PM +0200, Martin Basti wrote: On 04/05/15 15:36, Fraser Tweedale wrote: Hello, Please review the first cut of the 'certprofile' command and other changes associated with the Certificate Profiles feature[1]. Custom profiles can't be used yet because 'cert-request' has not been updated, but you can manage the profiles (find, show, import, modify, delete). There's a bit more work to do on profile management and a lot more to do for using profiles and sub-CAs. I am tracking my progress on etherpad[2] so if you are reviewing check there for the TODO list and some commentary. If you want to test: for f21, please use Dogtag from my copr[2]. For f22 the required version is in updates-testing (or my copr). In summary: this is not the whole feature, just the first functional part. Since it is my first experience developing in the IPA framework I want to get patches out so you can point out all the things I did wrong or overlooked, and I can fix them. Don't hold back :) [1] http://www.freeipa.org/page/V4/Certificate_Profiles [2] http://idm.etherpad.corp.redhat.com/rhel72-cert-mgmt-progress [3] http://copr.fedoraproject.org/coprs/ftweedal/freeipa/ Thank you for patches, I have no idea what kind of dogtag magic is happening there, but I have a few comments related to IPA: Thanks for reviewing, Martin. Comments inline. You are welcome, comments inline. Martin^2 Upgrade: 1) +config.set(CA, pki_profiles_in_ldap, True) IMO this will work only for new installations. For upgrade you may need to add this to ipa-upgradeconfig OK. 2) +dn: cn=certprofiles,cn=etc,$SUFFIX +changetype: add +objectClass: nsContainer +objectClass: top +cn: certprofiles IMO this will work only for new installations. For upgrade you may need to add it into update file as well, with the 'default' keyword I don't understand about the 'default' keyword - can you expain this some more? In an upgrade file: dn: cn=certprofiles,cn=etc,$SUFFIX default:objectClass: nsContainer default:objectClass: top default:cn: certprofiles Maybe we should do what DNS does and have a container for CA specific stuff in the suffix: cn=ca,$SUFFIX. The container would be created only if CA is installed. Certificate profile container would then be cn=certprofiles,cn=ca,$SUFFIX. I haven't changed this for the current patchset. What are the implications / motivations for changing it. To have everything CA-specific in one place and created only when CA is installed. This is consistent with DNS, the other optional IPA component. 3) Your patch 0004 will work on new installations only. You may need to add that new step into ipa-upgradeconfig. Must be that step there during installation? If not you can create just one update file, which will be applied at the end of installation and during upgrade. This change must be made to the Dogtag directory (not IPA) - can an update file be used to do that? If not, is ipa-upgradeconfig the best place to make this change? If it is change in LDAP, you can use updatefile: dn: cn=aclResources,$SUFFIX add:resourceACLS: certServer.profile.configuration:read,modify:allow (read,modify) group=Certificate Manager Agents:Certificate Manager agents may modify (create/update/delete) and read profiles Please temporarily use my patch freeipa-mbasti-231-4, (which will be pushed soon) to avoid issues with CSV Note that this update should be done only if CA is installed. In that case, you must create update plugins. I would prefer a CAInstance method called during install and in ipa-upgradeconfig. So more or less what Fraser already did, except the ipa-upgradeconfig part. Patch 0004 was updated and now has CAInstance method during install, and ipa-upgradeconfig method for upgrade. It would be better if you used the same CAInstance method both for install and upgrade, instead of duplicating the code. You shouldn't use the deprecated modify_s method of IPAdmin. This is not very nice: +sysupgrade.set_upgrade_state(*upgrade_state_args + (True,)) Martin^2 Other issues: 1) I do not see modifications in API.txt file 2) We use new
[Freeipa-devel] [PATCH 0035] do not check for directory manager password during KRA uninstall
https://fedorahosted.org/freeipa/ticket/5028 -- Martin^3 Babinsky From 96aae7a619c808e979699b56b5905e1e836a4f8b Mon Sep 17 00:00:00 2001 From: Martin Babinsky mbabi...@redhat.com Date: Tue, 19 May 2015 13:01:27 +0200 Subject: [PATCH] do not check for directory manager password during KRA uninstall ipa-kra-install validates and asks for directory manager password during uninstallation phase. Since this password is never used during service uninstall, the uninstaller will not perform these checks anymore. https://fedorahosted.org/freeipa/ticket/5028 --- ipaserver/install/ipa_kra_install.py | 17 ++--- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/ipaserver/install/ipa_kra_install.py b/ipaserver/install/ipa_kra_install.py index 099737fa9ae3ad5bbfb36772cb0ced9c676043f4..53b3cf413e56d2b45678e0b7abfa49ba32d3c2cb 100644 --- a/ipaserver/install/ipa_kra_install.py +++ b/ipaserver/install/ipa_kra_install.py @@ -74,19 +74,13 @@ class KRAInstall(admintool.AdminTool): installutils.check_server_configuration() -if self.options.unattended and self.options.password is None: -self.option_parser.error( -Directory Manager password must be specified using -p - in unattended mode -) - api.bootstrap(in_server=True) api.finalize() def ask_for_options(self): super(KRAInstall, self).ask_for_options() -if not self.options.password: +if not self.options.unattended and self.options.password is None: self.options.password = installutils.read_password( Directory Manager, confirm=False, validate=False, retry=False) @@ -116,6 +110,9 @@ class KRAUninstaller(KRAInstall): Cannot uninstall. There is no KRA installed on this system. ) +def ask_for_options(self): +pass + def run(self): super(KRAUninstaller, self).run() dogtag_constants = dogtag.configured_constants() @@ -152,6 +149,12 @@ class KRAInstaller(KRAInstall): def validate_options(self, needs_root=True): super(KRAInstaller, self).validate_options(needs_root=True) +if self.options.unattended and self.options.password is None: +self.option_parser.error( +Directory Manager password must be specified using -p + in unattended mode +) + dogtag_version = int(api.env.dogtag_version) enable_kra = api.env.enable_kra -- 2.1.0 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCHES 0001-0007] Profile management
On Tue, May 19, 2015 at 10:52:49AM +0200, Jan Cholasta wrote: Dne 15.5.2015 v 14:27 Martin Basti napsal(a): On 15/05/15 10:24, Fraser Tweedale wrote: Please find attached latest patches including new patches: - 0006 enable LDAP-based profiles in Dogtag on upgrade - 0007 import included profiles during install or upgrade There is one TODO in the patches where some more code is needed on Dogtag side, and another TODO (not in patches) to migrate caIPAserviceCert profile to DefaultService profile and switch to using DefaultService for cerificate issuance (as the default profile). Jan and Martin, further comments to earlier reviews inline. Cheers, Fraser On Wed, May 13, 2015 at 10:39:55AM +0200, Jan Cholasta wrote: Dne 13.5.2015 v 10:36 Martin Basti napsal(a): On 13/05/15 10:06, Jan Cholasta wrote: Hi, Dne 5.5.2015 v 10:38 Martin Basti napsal(a): On 05/05/15 08:29, Fraser Tweedale wrote: On Mon, May 04, 2015 at 06:35:45PM +0200, Martin Basti wrote: On 04/05/15 15:36, Fraser Tweedale wrote: Hello, Please review the first cut of the 'certprofile' command and other changes associated with the Certificate Profiles feature[1]. Custom profiles can't be used yet because 'cert-request' has not been updated, but you can manage the profiles (find, show, import, modify, delete). There's a bit more work to do on profile management and a lot more to do for using profiles and sub-CAs. I am tracking my progress on etherpad[2] so if you are reviewing check there for the TODO list and some commentary. If you want to test: for f21, please use Dogtag from my copr[2]. For f22 the required version is in updates-testing (or my copr). In summary: this is not the whole feature, just the first functional part. Since it is my first experience developing in the IPA framework I want to get patches out so you can point out all the things I did wrong or overlooked, and I can fix them. Don't hold back :) [1] http://www.freeipa.org/page/V4/Certificate_Profiles [2] http://idm.etherpad.corp.redhat.com/rhel72-cert-mgmt-progress [3] http://copr.fedoraproject.org/coprs/ftweedal/freeipa/ Thank you for patches, I have no idea what kind of dogtag magic is happening there, but I have a few comments related to IPA: Thanks for reviewing, Martin. Comments inline. You are welcome, comments inline. Martin^2 Upgrade: 1) +config.set(CA, pki_profiles_in_ldap, True) IMO this will work only for new installations. For upgrade you may need to add this to ipa-upgradeconfig OK. 2) +dn: cn=certprofiles,cn=etc,$SUFFIX +changetype: add +objectClass: nsContainer +objectClass: top +cn: certprofiles IMO this will work only for new installations. For upgrade you may need to add it into update file as well, with the 'default' keyword I don't understand about the 'default' keyword - can you expain this some more? In an upgrade file: dn: cn=certprofiles,cn=etc,$SUFFIX default:objectClass: nsContainer default:objectClass: top default:cn: certprofiles Maybe we should do what DNS does and have a container for CA specific stuff in the suffix: cn=ca,$SUFFIX. The container would be created only if CA is installed. Certificate profile container would then be cn=certprofiles,cn=ca,$SUFFIX. I haven't changed this for the current patchset. What are the implications / motivations for changing it. To have everything CA-specific in one place and created only when CA is installed. This is consistent with DNS, the other optional IPA component. OK, I'll change it. Sub-CA data and Certificate Identity Mapping settings could also be stored under there, when implemented. 3) Your patch 0004 will work on new installations only. You may need to add that new step into ipa-upgradeconfig. Must be that step there during installation? If not you can create just one update file, which will be applied at the end of installation and during upgrade. This change must be made to the Dogtag directory (not IPA) - can an update file be used to do that? If not, is ipa-upgradeconfig the best place to make this change? If it is change in LDAP, you can use updatefile: dn: cn=aclResources,$SUFFIX add:resourceACLS: certServer.profile.configuration:read,modify:allow (read,modify) group=Certificate Manager Agents:Certificate Manager agents may modify (create/update/delete) and read profiles Please temporarily use my patch freeipa-mbasti-231-4, (which will be pushed soon) to avoid issues with CSV Note that this update should be done only if CA is installed. In that case, you must create update plugins. I would prefer a CAInstance method called during install and in ipa-upgradeconfig. So more or less what Fraser already did, except the ipa-upgradeconfig part. Patch 0004 was updated and now has CAInstance method during install, and ipa-upgradeconfig method for upgrade. It would be better if you used the same CAInstance method both
[Freeipa-devel] IPAUpgrade.create_instance causing ipa-server-install failure
I am experiencing ipa-server-install failure which seems to be caused by IPAUpgrade.__start_nowait() (upgradeinstance.py:174). It is claimed that the LDAP connection will wait for the (Unix) socket but it does not - instead it fails to connect. Did something chance recently that would cause the connction to not wait for the socket? For now I am working around it with a short sleep in __start_nowait. ipaserver-install.log sample beneath. Cheers, Fraser 2015-05-20T03:50:37Z DEBUG Upgrading IPA: 2015-05-20T03:50:37Z DEBUG [1/9]: stopping directory server 2015-05-20T03:50:37Z DEBUG Starting external process 2015-05-20T03:50:37Z DEBUG args='/bin/systemctl' 'stop' 'dirsrv@IPA-LOCAL.service' 2015-05-20T03:50:40Z DEBUG Process finished, return code=0 2015-05-20T03:50:40Z DEBUG stdout= 2015-05-20T03:50:40Z DEBUG stderr= 2015-05-20T03:50:40Z DEBUG duration: 3 seconds 2015-05-20T03:50:40Z DEBUG [2/9]: saving configuration 2015-05-20T03:50:40Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2015-05-20T03:50:40Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2015-05-20T03:50:40Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2015-05-20T03:50:40Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2015-05-20T03:50:40Z DEBUG duration: 0 seconds 2015-05-20T03:50:40Z DEBUG [3/9]: disabling listeners 2015-05-20T03:50:40Z DEBUG duration: 0 seconds 2015-05-20T03:50:40Z DEBUG [4/9]: enabling DS global lock 2015-05-20T03:50:40Z DEBUG duration: 0 seconds 2015-05-20T03:50:40Z DEBUG [5/9]: starting directory server 2015-05-20T03:50:40Z DEBUG Starting external process 2015-05-20T03:50:40Z DEBUG args='/bin/systemctl' 'start' 'dirsrv@IPA-LOCAL.service' 2015-05-20T03:50:40Z DEBUG Process finished, return code=0 2015-05-20T03:50:40Z DEBUG stdout= 2015-05-20T03:50:40Z DEBUG stderr= 2015-05-20T03:50:40Z DEBUG duration: 0 seconds 2015-05-20T03:50:40Z DEBUG [6/9]: upgrading server 2015-05-20T03:50:41Z DEBUG importing all plugin modules in '/usr/lib/python2.7/site-packages/ipalib/plugins'... 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/aci.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/automember.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/automount.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/baseuser.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/batch.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/config.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/delegation.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/group.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacrule.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacsvc.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacsvcgroup.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/hbactest.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/host.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/hostgroup.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/idrange.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/idviews.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/internal.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/kerberos.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/krbtpolicy.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/migration.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/misc.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/netgroup.py' 2015-05-20T03:50:41Z DEBUG importing plugin module
Re: [Freeipa-devel] [PATCHES 0001-0007] Profile management
On Wed, May 20, 2015 at 07:40:44AM +0200, Jan Cholasta wrote: Dne 19.5.2015 v 13:50 Fraser Tweedale napsal(a): On Tue, May 19, 2015 at 10:52:49AM +0200, Jan Cholasta wrote: Dne 15.5.2015 v 14:27 Martin Basti napsal(a): On 15/05/15 10:24, Fraser Tweedale wrote: Please find attached latest patches including new patches: - 0006 enable LDAP-based profiles in Dogtag on upgrade - 0007 import included profiles during install or upgrade There is one TODO in the patches where some more code is needed on Dogtag side, and another TODO (not in patches) to migrate caIPAserviceCert profile to DefaultService profile and switch to using DefaultService for cerificate issuance (as the default profile). Jan and Martin, further comments to earlier reviews inline. Cheers, Fraser On Wed, May 13, 2015 at 10:39:55AM +0200, Jan Cholasta wrote: Dne 13.5.2015 v 10:36 Martin Basti napsal(a): On 13/05/15 10:06, Jan Cholasta wrote: Hi, Dne 5.5.2015 v 10:38 Martin Basti napsal(a): On 05/05/15 08:29, Fraser Tweedale wrote: On Mon, May 04, 2015 at 06:35:45PM +0200, Martin Basti wrote: On 04/05/15 15:36, Fraser Tweedale wrote: Hello, Please review the first cut of the 'certprofile' command and other changes associated with the Certificate Profiles feature[1]. Custom profiles can't be used yet because 'cert-request' has not been updated, but you can manage the profiles (find, show, import, modify, delete). There's a bit more work to do on profile management and a lot more to do for using profiles and sub-CAs. I am tracking my progress on etherpad[2] so if you are reviewing check there for the TODO list and some commentary. If you want to test: for f21, please use Dogtag from my copr[2]. For f22 the required version is in updates-testing (or my copr). In summary: this is not the whole feature, just the first functional part. Since it is my first experience developing in the IPA framework I want to get patches out so you can point out all the things I did wrong or overlooked, and I can fix them. Don't hold back :) [1] http://www.freeipa.org/page/V4/Certificate_Profiles [2] http://idm.etherpad.corp.redhat.com/rhel72-cert-mgmt-progress [3] http://copr.fedoraproject.org/coprs/ftweedal/freeipa/ Thank you for patches, I have no idea what kind of dogtag magic is happening there, but I have a few comments related to IPA: Thanks for reviewing, Martin. Comments inline. You are welcome, comments inline. Martin^2 Upgrade: 1) +config.set(CA, pki_profiles_in_ldap, True) IMO this will work only for new installations. For upgrade you may need to add this to ipa-upgradeconfig OK. 2) +dn: cn=certprofiles,cn=etc,$SUFFIX +changetype: add +objectClass: nsContainer +objectClass: top +cn: certprofiles IMO this will work only for new installations. For upgrade you may need to add it into update file as well, with the 'default' keyword I don't understand about the 'default' keyword - can you expain this some more? In an upgrade file: dn: cn=certprofiles,cn=etc,$SUFFIX default:objectClass: nsContainer default:objectClass: top default:cn: certprofiles Maybe we should do what DNS does and have a container for CA specific stuff in the suffix: cn=ca,$SUFFIX. The container would be created only if CA is installed. Certificate profile container would then be cn=certprofiles,cn=ca,$SUFFIX. I haven't changed this for the current patchset. What are the implications / motivations for changing it. To have everything CA-specific in one place and created only when CA is installed. This is consistent with DNS, the other optional IPA component. OK, I'll change it. Sub-CA data and Certificate Identity Mapping settings could also be stored under there, when implemented. Yes, Sub-CAs should also be stored there, but certificate identity mappings should work even without CA installed, so they should be stored somewhere else, like cn=etc. That makes sense. 3) Your patch 0004 will work on new installations only. You may need to add that new step into ipa-upgradeconfig. Must be that step there during installation? If not you can create just one update file, which will be applied at the end of installation and during upgrade. This change must be made to the Dogtag directory (not IPA) - can an update file be used to do that? If not, is ipa-upgradeconfig the best place to make this change? If it is change in LDAP, you can use updatefile: dn: cn=aclResources,$SUFFIX add:resourceACLS: certServer.profile.configuration:read,modify:allow (read,modify) group=Certificate Manager Agents:Certificate Manager agents may modify (create/update/delete) and read profiles Please temporarily use my patch freeipa-mbasti-231-4, (which will be pushed soon) to avoid issues with CSV Note that this update should be done only if CA is installed. In that case, you must create update plugins. I would prefer a CAInstance
Re: [Freeipa-devel] [PATCHES 0001-0007] Profile management
Dne 19.5.2015 v 13:50 Fraser Tweedale napsal(a): On Tue, May 19, 2015 at 10:52:49AM +0200, Jan Cholasta wrote: Dne 15.5.2015 v 14:27 Martin Basti napsal(a): On 15/05/15 10:24, Fraser Tweedale wrote: Please find attached latest patches including new patches: - 0006 enable LDAP-based profiles in Dogtag on upgrade - 0007 import included profiles during install or upgrade There is one TODO in the patches where some more code is needed on Dogtag side, and another TODO (not in patches) to migrate caIPAserviceCert profile to DefaultService profile and switch to using DefaultService for cerificate issuance (as the default profile). Jan and Martin, further comments to earlier reviews inline. Cheers, Fraser On Wed, May 13, 2015 at 10:39:55AM +0200, Jan Cholasta wrote: Dne 13.5.2015 v 10:36 Martin Basti napsal(a): On 13/05/15 10:06, Jan Cholasta wrote: Hi, Dne 5.5.2015 v 10:38 Martin Basti napsal(a): On 05/05/15 08:29, Fraser Tweedale wrote: On Mon, May 04, 2015 at 06:35:45PM +0200, Martin Basti wrote: On 04/05/15 15:36, Fraser Tweedale wrote: Hello, Please review the first cut of the 'certprofile' command and other changes associated with the Certificate Profiles feature[1]. Custom profiles can't be used yet because 'cert-request' has not been updated, but you can manage the profiles (find, show, import, modify, delete). There's a bit more work to do on profile management and a lot more to do for using profiles and sub-CAs. I am tracking my progress on etherpad[2] so if you are reviewing check there for the TODO list and some commentary. If you want to test: for f21, please use Dogtag from my copr[2]. For f22 the required version is in updates-testing (or my copr). In summary: this is not the whole feature, just the first functional part. Since it is my first experience developing in the IPA framework I want to get patches out so you can point out all the things I did wrong or overlooked, and I can fix them. Don't hold back :) [1] http://www.freeipa.org/page/V4/Certificate_Profiles [2] http://idm.etherpad.corp.redhat.com/rhel72-cert-mgmt-progress [3] http://copr.fedoraproject.org/coprs/ftweedal/freeipa/ Thank you for patches, I have no idea what kind of dogtag magic is happening there, but I have a few comments related to IPA: Thanks for reviewing, Martin. Comments inline. You are welcome, comments inline. Martin^2 Upgrade: 1) +config.set(CA, pki_profiles_in_ldap, True) IMO this will work only for new installations. For upgrade you may need to add this to ipa-upgradeconfig OK. 2) +dn: cn=certprofiles,cn=etc,$SUFFIX +changetype: add +objectClass: nsContainer +objectClass: top +cn: certprofiles IMO this will work only for new installations. For upgrade you may need to add it into update file as well, with the 'default' keyword I don't understand about the 'default' keyword - can you expain this some more? In an upgrade file: dn: cn=certprofiles,cn=etc,$SUFFIX default:objectClass: nsContainer default:objectClass: top default:cn: certprofiles Maybe we should do what DNS does and have a container for CA specific stuff in the suffix: cn=ca,$SUFFIX. The container would be created only if CA is installed. Certificate profile container would then be cn=certprofiles,cn=ca,$SUFFIX. I haven't changed this for the current patchset. What are the implications / motivations for changing it. To have everything CA-specific in one place and created only when CA is installed. This is consistent with DNS, the other optional IPA component. OK, I'll change it. Sub-CA data and Certificate Identity Mapping settings could also be stored under there, when implemented. Yes, Sub-CAs should also be stored there, but certificate identity mappings should work even without CA installed, so they should be stored somewhere else, like cn=etc. 3) Your patch 0004 will work on new installations only. You may need to add that new step into ipa-upgradeconfig. Must be that step there during installation? If not you can create just one update file, which will be applied at the end of installation and during upgrade. This change must be made to the Dogtag directory (not IPA) - can an update file be used to do that? If not, is ipa-upgradeconfig the best place to make this change? If it is change in LDAP, you can use updatefile: dn: cn=aclResources,$SUFFIX add:resourceACLS: certServer.profile.configuration:read,modify:allow (read,modify) group=Certificate Manager Agents:Certificate Manager agents may modify (create/update/delete) and read profiles Please temporarily use my patch freeipa-mbasti-231-4, (which will be pushed soon) to avoid issues with CSV Note that this update should be done only if CA is installed. In that case, you must create update plugins. I would prefer a CAInstance method called during install and in ipa-upgradeconfig. So more or less what Fraser already did, except the ipa-upgradeconfig part. Patch 0004 was updated and now has CAInstance method during
Re: [Freeipa-devel] [UPSTREAM_FAILURES] Latest changes affect freeipa builds and client configuration
On Tue, May 19, 2015 at 05:42:15PM +0200, Martin Babinsky wrote: Hello Oleg, On 05/19/2015 05:21 PM, Oleg Fayans wrote: Dear colleagues I would like to notify you, that: 1. some of the recent changes in the upstream repo have broken the freeipa-client configuration. The symptoms are as follows: at some point during ipa-server-install the process fails with the following error: Restarting the web server Configuration of client side components failed! ipa-client-install returned: Command ''/usr/sbin/ipa-client-install' '--on-master' '--unattended' '--domain' 'myhome.net' '--server' 'testmaster.myhome.net' '--realm' 'MYHOME.NET' '--hostname' 'testmaster.myhome.net'' returned non-zero exit status 1 Looking at the ipaclient-install.log I could tell that the client was unable to authorize with the freshly installed master (kerberos issue?) I've attached the corresponding logs together with the session transcript of ipa-server-install command. This issue is observed since last Thursday at least. This error (and others of similar nature) should be fixed by the following commits: 7ff7b1f533cc10c44acf6020b545b253de1ad37b * move IPA-related http runtime directories to common subdirectory 5a741b614f39a148d849877e743200de5a7302db * explicitly destroy httpd service ccache file during httpinstance removal This was the issue I encountered (and am no longer encountering thanks to these commits). Cheers, Fraser -- Martin^3 Babinsky -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0245] Fix uniqueness plugins vol. 2
Dne 13.5.2015 v 12:56 Martin Babinsky napsal(a): On 05/12/2015 09:03 PM, Martin Basti wrote: On 12/05/15 18:23, Martin Basti wrote: https://fedorahosted.org/freeipa/ticket/4921 To test this, the mkosek/freeipa-master copr repo with 389-ds-base 1.3.4.0 is needed. All previous changes to uniqueness plugins were made just in master branch so upgrade will not work correctly from master to newer master. From IPA 4.1 to master should work as expected. Patch attached. Updated patch attached. -- Martin Basti ACK Pushed to master: fbdfd688b9d04cfef3cd595a26c4cbf49f30e0f1 -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0248] DNSSEC: Fix: Do not recreate kasp.db if already exists
Dne 15.5.2015 v 12:10 Petr Spacek napsal(a): On 14.5.2015 17:09, Martin Basti wrote: https://fedorahosted.org/freeipa/ticket/4657 Patch attached. ACK for this change but it generally it would be nice if function __setup_dnssec had some meaningful name, e.g. __setup_opendnssec_db. Pushed to: master: ebd91461132d2aa7d5166d03ccfe7b0d49df2c8a ipa-4-1: d7cfc1107bcd63eaa4c5282672c088dcbd1ebf9b -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0325] Add Domain Level feature
On 05/19/2015 03:36 PM, Martin Kosek wrote: On 05/19/2015 03:22 PM, Tomas Babej wrote: ... 3) Domain level is just a single integer and it should be treated as such, there's no need for an LDAPObject plugin and other unnecessary complexities. The implemetation could be as simple as (from top of my head, untested): That's right, I also considered this approach, but as far as I know you do not get the permission handling for the global DomainLevel entry otherwise. Ludwig, I changed the path for the global entry to cn=DomainLevel. I know this particular DN was added to the design by Simo, but why do we want to use CamelCase with LDAP object? Wouldn't cn=Domain Level,cn=ipa,cn=etc,SUFFIX be a better place for it? This is the last time we can change it, so I am asking now. Then, we will be stuck with this DN forever. I don't mind using cn=Domain Level , but where does the entry live, here you say cn=Domain Level,cn=ipa,cn=etc,SUFFIX and in the design page it is: cn=DomainLevel,cn=etc,SUFFIX The current version of the topology plugin is looking for cn=DomainLevel,cn=ipa,cn=etc,SUFFIX but I want to change it to do a search on objectclass=ipaDomainLevelConfig -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0325] Add Domain Level feature
On 05/19/2015 03:49 PM, Ludwig Krispenz wrote: On 05/19/2015 03:36 PM, Martin Kosek wrote: On 05/19/2015 03:22 PM, Tomas Babej wrote: ... 3) Domain level is just a single integer and it should be treated as such, there's no need for an LDAPObject plugin and other unnecessary complexities. The implemetation could be as simple as (from top of my head, untested): That's right, I also considered this approach, but as far as I know you do not get the permission handling for the global DomainLevel entry otherwise. Ludwig, I changed the path for the global entry to cn=DomainLevel. I know this particular DN was added to the design by Simo, but why do we want to use CamelCase with LDAP object? Wouldn't cn=Domain Level,cn=ipa,cn=etc,SUFFIX be a better place for it? This is the last time we can change it, so I am asking now. Then, we will be stuck with this DN forever. I don't mind using cn=Domain Level , but where does the entry live, here you say cn=Domain Level,cn=ipa,cn=etc,SUFFIX and in the design page it is: cn=DomainLevel,cn=etc,SUFFIX The current version of the topology plugin is looking for cn=DomainLevel,cn=ipa,cn=etc,SUFFIX but I want to change it to do a search on objectclass=ipaDomainLevelConfig I see - we all need to unify the location apparently. I updated the design page to use cn=Domain Level,cn=ipa,cn=etc,SUFFIX. Tomas, please send the updated patch set, it should be an extremely simple change :-) -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0325] Add Domain Level feature
On 05/19/2015 03:56 PM, Tomas Babej wrote: On 05/19/2015 03:51 PM, Martin Kosek wrote: On 05/19/2015 03:49 PM, Ludwig Krispenz wrote: On 05/19/2015 03:36 PM, Martin Kosek wrote: On 05/19/2015 03:22 PM, Tomas Babej wrote: ... 3) Domain level is just a single integer and it should be treated as such, there's no need for an LDAPObject plugin and other unnecessary complexities. The implemetation could be as simple as (from top of my head, untested): That's right, I also considered this approach, but as far as I know you do not get the permission handling for the global DomainLevel entry otherwise. Ludwig, I changed the path for the global entry to cn=DomainLevel. I know this particular DN was added to the design by Simo, but why do we want to use CamelCase with LDAP object? Wouldn't cn=Domain Level,cn=ipa,cn=etc,SUFFIX be a better place for it? This is the last time we can change it, so I am asking now. Then, we will be stuck with this DN forever. I don't mind using cn=Domain Level , but where does the entry live, here you say cn=Domain Level,cn=ipa,cn=etc,SUFFIX and in the design page it is: cn=DomainLevel,cn=etc,SUFFIX The current version of the topology plugin is looking for cn=DomainLevel,cn=ipa,cn=etc,SUFFIX but I want to change it to do a search on objectclass=ipaDomainLevelConfig I see - we all need to unify the location apparently. I updated the design page to use cn=Domain Level,cn=ipa,cn=etc,SUFFIX. Tomas, please send the updated patch set, it should be an extremely simple change :-) I prefer the ipa parent and the space in the name, so I'm glad we could agree on this without much bikeshedding. Updated patch attaced. Tomas I still see +# Create default Domain Level entry if it does not exist +dn: cn=DomainLevel,cn=ipa,cn=etc,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: objectClass: ipaDomainLevelConfig +default: ipaDomainLevel: 0 ... -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0325] Add Domain Level feature
On 05/14/2015 11:48 AM, Jan Cholasta wrote: Hi, Dne 14.5.2015 v 11:00 Tomas Babej napsal(a): Hi, this patch implements the domain level feature. https://fedorahosted.org/freeipa/ticket/5018 Tomas 1) +# Create entry proclaiming Domain Level support of this master +# This will update the supported Domain Levels during upgrade +dn: cn=Domain Level support,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: objectClass: ipaConfigObject +default: objectClass: ipaSupportedDomainLevelConfig +only: ipaMinDomainLevel: $MIN_DOMAIN_LEVEL +only: ipaMaxDomainLevel: $MAX_DOMAIN_LEVEL The design states that supported domain levels should be stored directly in cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX and I agree with that - there is no reason to have this information in a separate entry. I agree, this is an error on my part - I read the design as stored in entry under cn=$FQDN,cn=masters, not in the entry itself. 2) I though we agreed to call the command domainlevel-set instead of domainlevel-raise: https://www.redhat.com/archives/freeipa-devel/2015-May/msg00101.html. Fixed. 3) Domain level is just a single integer and it should be treated as such, there's no need for an LDAPObject plugin and other unnecessary complexities. The implemetation could be as simple as (from top of my head, untested): That's right, I also considered this approach, but as far as I know you do not get the permission handling for the global DomainLevel entry otherwise. Ludwig, I changed the path for the global entry to cn=DomainLevel. Updated patch attached. Tomas From d66b08f923b150977dc88da507443d393ce82fd1 Mon Sep 17 00:00:00 2001 From: Tomas Babej tba...@redhat.com Date: Thu, 14 May 2015 10:49:55 +0200 Subject: [PATCH] Add Domain Level feature https://fedorahosted.org/freeipa/ticket/5018 --- ACI.txt| 2 + API.txt| 22 ++ install/share/72domainlevels.ldif | 6 ++ install/share/Makefile.am | 1 + install/updates/72-domainlevels.update | 13 install/updates/Makefile.am| 1 + ipalib/constants.py| 3 + ipalib/errors.py | 16 ipalib/plugins/domainlevel.py | 137 + ipaserver/install/dsinstance.py| 1 + ipaserver/install/ldapupdate.py| 5 ++ 11 files changed, 207 insertions(+) create mode 100644 install/share/72domainlevels.ldif create mode 100644 install/updates/72-domainlevels.update create mode 100644 ipalib/plugins/domainlevel.py diff --git a/ACI.txt b/ACI.txt index 933b57cb93e833981867953b516a67484f13dca3..6791e0c8d813ba22357960bc3b34911802513f2c 100644 --- a/ACI.txt +++ b/ACI.txt @@ -50,6 +50,8 @@ dn: dc=ipa,dc=example aci: (target = ldap:///idnsname=*,cn=dns,dc=ipa,dc=example;)(version 3.0;acl permission:System: Remove DNS Entries;allow (delete) groupdn = ldap:///cn=System: Remove DNS Entries,cn=permissions,cn=pbac,dc=ipa,dc=example;) dn: dc=ipa,dc=example aci: (targetattr = a6record || record || afsdbrecord || arecord || certrecord || cn || cnamerecord || dlvrecord || dnamerecord || dnsclass || dnsttl || dsrecord || hinforecord || idnsallowdynupdate || idnsallowquery || idnsallowsyncptr || idnsallowtransfer || idnsforwarders || idnsforwardpolicy || idnsname || idnssecinlinesigning || idnssoaexpire || idnssoaminimum || idnssoamname || idnssoarefresh || idnssoaretry || idnssoarname || idnssoaserial || idnsupdatepolicy || idnszoneactive || keyrecord || kxrecord || locrecord || managedby || mdrecord || minforecord || mxrecord || naptrrecord || nsec3paramrecord || nsecrecord || nsrecord || nxtrecord || ptrrecord || rrsigrecord || sigrecord || srvrecord || sshfprecord || tlsarecord || txtrecord)(target = ldap:///idnsname=*,cn=dns,dc=ipa,dc=example;)(version 3.0;acl permission:System: Update DNS Entries;allow (write) groupdn = ldap:///cn=System: Update DNS Entries,cn=permissions,cn=pbac,dc=ipa,dc=example;) +dn: dc=ipa,dc=example +aci: (targetattr = createtimestamp || entryusn || ipadomainlevel || modifytimestamp || objectclass)(targetfilter = (objectclass=ipadomainlevelconfig))(version 3.0;acl permission:System: Read Domain Level;allow (compare,read,search) userdn = ldap:///all;;) dn: cn=groups,cn=accounts,dc=ipa,dc=example aci: (targetfilter = (|(objectclass=ipausergroup)(objectclass=posixgroup)))(version 3.0;acl permission:System: Add Groups;allow (add) groupdn = ldap:///cn=System: Add Groups,cn=permissions,cn=pbac,dc=ipa,dc=example;) dn: cn=groups,cn=accounts,dc=ipa,dc=example diff --git a/API.txt b/API.txt index 346e35fda536f8411f8ea8f2dc32af4caebf3fca..df7d9edbf4c9285ba2d93bc72848b903b28d0fa8 100644 --- a/API.txt +++ b/API.txt @@ -1283,6 +1283,28 @@ option: Str('version?', exclude='webui') output: Entry('result', type 'dict', Gettext('A dictionary representing an LDAP entry', domain='ipa',
Re: [Freeipa-devel] [PATCH 0325] Add Domain Level feature
Dne 19.5.2015 v 15:22 Tomas Babej napsal(a): On 05/14/2015 11:48 AM, Jan Cholasta wrote: Hi, Dne 14.5.2015 v 11:00 Tomas Babej napsal(a): Hi, this patch implements the domain level feature. https://fedorahosted.org/freeipa/ticket/5018 Tomas 1) +# Create entry proclaiming Domain Level support of this master +# This will update the supported Domain Levels during upgrade +dn: cn=Domain Level support,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: objectClass: ipaConfigObject +default: objectClass: ipaSupportedDomainLevelConfig +only: ipaMinDomainLevel: $MIN_DOMAIN_LEVEL +only: ipaMaxDomainLevel: $MAX_DOMAIN_LEVEL The design states that supported domain levels should be stored directly in cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX and I agree with that - there is no reason to have this information in a separate entry. I agree, this is an error on my part - I read the design as stored in entry under cn=$FQDN,cn=masters, not in the entry itself. Maybe we can also rename ipaSupportedDomainLevelConfig to ipaMaster? 2) I though we agreed to call the command domainlevel-set instead of domainlevel-raise: https://www.redhat.com/archives/freeipa-devel/2015-May/msg00101.html. Fixed. 3) Domain level is just a single integer and it should be treated as such, there's no need for an LDAPObject plugin and other unnecessary complexities. The implemetation could be as simple as (from top of my head, untested): That's right, I also considered this approach, but as far as I know you do not get the permission handling for the global DomainLevel entry otherwise. The proper thing to do in such cases is to add the permissions to NONOBJECT_PERMISSIONS in ipaserver.install.plugins.update_managed_permissions. Ludwig, I changed the path for the global entry to cn=DomainLevel. Updated patch attached. Tomas -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0035] do not check for directory manager password during KRA uninstall
On 05/19/2015 01:17 PM, Martin Babinsky wrote: https://fedorahosted.org/freeipa/ticket/5028 updated patch attached -- Martin^3 Babinsky From b7c20fa1e2e7d27b8eb968bb57955c7620f83e50 Mon Sep 17 00:00:00 2001 From: Martin Babinsky mbabi...@redhat.com Date: Tue, 19 May 2015 13:01:27 +0200 Subject: [PATCH] do not check for directory manager password during KRA uninstall ipa-kra-install validates and asks for directory manager password during uninstallation phase. Since this password is never used during service uninstall, the uninstaller will not perform these checks anymore. https://fedorahosted.org/freeipa/ticket/5028 --- ipaserver/install/ipa_kra_install.py | 34 +- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/ipaserver/install/ipa_kra_install.py b/ipaserver/install/ipa_kra_install.py index 099737fa9ae3ad5bbfb36772cb0ced9c676043f4..08b4331f4d1741b6970c676283401abf0d861673 100644 --- a/ipaserver/install/ipa_kra_install.py +++ b/ipaserver/install/ipa_kra_install.py @@ -74,26 +74,9 @@ class KRAInstall(admintool.AdminTool): installutils.check_server_configuration() -if self.options.unattended and self.options.password is None: -self.option_parser.error( -Directory Manager password must be specified using -p - in unattended mode -) - api.bootstrap(in_server=True) api.finalize() -def ask_for_options(self): -super(KRAInstall, self).ask_for_options() - -if not self.options.password: -self.options.password = installutils.read_password( -Directory Manager, confirm=False, -validate=False, retry=False) -if self.options.password is None: -raise admintool.ScriptError( -Directory Manager password required) - @classmethod def get_command_class(cls, options, args): if options.uninstall: @@ -152,6 +135,12 @@ class KRAInstaller(KRAInstall): def validate_options(self, needs_root=True): super(KRAInstaller, self).validate_options(needs_root=True) +if self.options.unattended and self.options.password is None: +self.option_parser.error( +Directory Manager password must be specified using -p + in unattended mode +) + dogtag_version = int(api.env.dogtag_version) enable_kra = api.env.enable_kra @@ -187,6 +176,17 @@ class KRAInstaller(KRAInstall): self.option_parser.error(Too many parameters provided. No replica file is required.) +def ask_for_options(self): +super(KRAInstall, self).ask_for_options() + +if not self.options.unattended and self.options.password is None: +self.options.password = installutils.read_password( +Directory Manager, confirm=False, +validate=False, retry=False) +if self.options.password is None: +raise admintool.ScriptError( +Directory Manager password required) + def _run(self): super(KRAInstaller, self).run() print dedent(self.INSTALLER_START_MESSAGE) -- 2.1.0 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0247] Modularization of the DNS subsytem installer
Dne 15.5.2015 v 16:44 Martin Basti napsal(a): On 14/05/15 15:16, Martin Basti wrote: Required for new installers. Patch attached. Updated patch attached. Thanks, ACK. Pushed to master: ae9c3e2dce000ed185b28e2e6e85043ad8d001ed -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCHES 0033-0034] fix recent bugs introduced by letting httpd use file-based ccache
On 05/15/2015 04:41 PM, Martin Babinsky wrote: On 05/15/2015 04:25 PM, Jan Cholasta wrote: Dne 15.5.2015 v 16:16 Martin Babinsky napsal(a): These two patches fix two issues reported by David Kupka in most recent freeipa-master builds, which are caused by my previous patch 0031 provide a dedicated ccache file to httpd. Patch 0033 moves `clientcaches` and `krbcache` directories under a common `ipa/` subdir in Apache runtime dir (`/var/run/httpd`). This fixes a situation when both mod_auth_kerb and mod_auth_gssapi are installed together with IPA. The removal of the former Apache module removes also the `krbcache` directory, thus invalidating the ccache path in KRB5CCNAME. This of course causes spectacular explosions when calling RPC interface (aka always). Patch 0034 forces HTTPInstance to explicitly remove ccache specified in our `httpd.service` override during uninstall. This fixes an issue related to uninstall of an old IPA server and immediate install of new IPA server. In this case the old CCache is left in httpd runtime dir, causing Decrypt integrity check failed errors when connecting to RPC interface (Old tickets are being send to KDC having new Apache secret key). However, issuing 'kdestroy -A' as apache user is not enough, because systemd daemons use completely different isolated environments (and thus completely different KRB5CCNAME than apache user). That's why we have to explicitly remove ccache using 'kdestroy -c'. I would like to thank David for pointing out these issues. Don't forget to bump the version at the top of install/conf/ipa.conf. Attaching updated patch 0033 with the bumped version. Hi! Works for me, ACK. -- David Kupka -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCHES 0239-0243] Server Upgrade: minor fixes
Dne 13.5.2015 v 15:22 David Kupka napsal(a): On 05/12/2015 02:44 PM, Martin Basti wrote: https://fedorahosted.org/freeipa/ticket/4904 Patches attached. Works for me, ACK. Pushed to master: 99c0b918a7cdf4ea6f24b4cbe687d9cafd21de24 -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0325] Add Domain Level feature
On 05/19/2015 03:22 PM, Tomas Babej wrote: ... 3) Domain level is just a single integer and it should be treated as such, there's no need for an LDAPObject plugin and other unnecessary complexities. The implemetation could be as simple as (from top of my head, untested): That's right, I also considered this approach, but as far as I know you do not get the permission handling for the global DomainLevel entry otherwise. Ludwig, I changed the path for the global entry to cn=DomainLevel. I know this particular DN was added to the design by Simo, but why do we want to use CamelCase with LDAP object? Wouldn't cn=Domain Level,cn=ipa,cn=etc,SUFFIX be a better place for it? This is the last time we can change it, so I am asking now. Then, we will be stuck with this DN forever. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0048 Remove unused enable() method from DogtagInstance.
Dne 14.5.2015 v 17:41 David Kupka napsal(a): On 05/13/2015 12:07 PM, Martin Basti wrote: On 12/05/15 16:54, David Kupka wrote: On 05/12/2015 02:16 PM, Martin Basti wrote: On 12/05/15 13:53, David Kupka wrote: DogtagInstance.enable() overrides Service.enable() and does nothing usefulll. Also removing it solves bug discovered recently in uninstall procedure. NACK 1) this is used in step() call, which means the tomcatd will be enabled in systemd, and we do not want this. Services should be disabled and managed just by ipactl. 2) Which method now store state of tomcatd before IPA changes it? To solve this please rename method to, for example, store_state(), and add appropriate description, or put backup_state() call into different appropriate step. Martin^2 Thanks for catching that, updated patch attached. I discussed this with Honza, and would be better to remove the enable sysrestore status at all, because it is just IPA instance of CA, and instance with the same name cannot be there otherwise installation will fail, so there is no reason to store status. Patch attached, untested. Thanks, this works too and probably looks better, ACK. Pushed to master: 0167919ba88ef718e7b678380ebfe3ddb4566831 -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCHES 0033-0034] fix recent bugs introduced by letting httpd use file-based ccache
Dne 19.5.2015 v 14:31 David Kupka napsal(a): On 05/15/2015 04:41 PM, Martin Babinsky wrote: On 05/15/2015 04:25 PM, Jan Cholasta wrote: Dne 15.5.2015 v 16:16 Martin Babinsky napsal(a): These two patches fix two issues reported by David Kupka in most recent freeipa-master builds, which are caused by my previous patch 0031 provide a dedicated ccache file to httpd. Patch 0033 moves `clientcaches` and `krbcache` directories under a common `ipa/` subdir in Apache runtime dir (`/var/run/httpd`). This fixes a situation when both mod_auth_kerb and mod_auth_gssapi are installed together with IPA. The removal of the former Apache module removes also the `krbcache` directory, thus invalidating the ccache path in KRB5CCNAME. This of course causes spectacular explosions when calling RPC interface (aka always). Patch 0034 forces HTTPInstance to explicitly remove ccache specified in our `httpd.service` override during uninstall. This fixes an issue related to uninstall of an old IPA server and immediate install of new IPA server. In this case the old CCache is left in httpd runtime dir, causing Decrypt integrity check failed errors when connecting to RPC interface (Old tickets are being send to KDC having new Apache secret key). However, issuing 'kdestroy -A' as apache user is not enough, because systemd daemons use completely different isolated environments (and thus completely different KRB5CCNAME than apache user). That's why we have to explicitly remove ccache using 'kdestroy -c'. I would like to thank David for pointing out these issues. Don't forget to bump the version at the top of install/conf/ipa.conf. Attaching updated patch 0033 with the bumped version. Hi! Works for me, ACK. Pushed to master: 5a741b614f39a148d849877e743200de5a7302db -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0325] Add Domain Level feature
On 05/19/2015 03:51 PM, Martin Kosek wrote: On 05/19/2015 03:49 PM, Ludwig Krispenz wrote: On 05/19/2015 03:36 PM, Martin Kosek wrote: On 05/19/2015 03:22 PM, Tomas Babej wrote: ... 3) Domain level is just a single integer and it should be treated as such, there's no need for an LDAPObject plugin and other unnecessary complexities. The implemetation could be as simple as (from top of my head, untested): That's right, I also considered this approach, but as far as I know you do not get the permission handling for the global DomainLevel entry otherwise. Ludwig, I changed the path for the global entry to cn=DomainLevel. I know this particular DN was added to the design by Simo, but why do we want to use CamelCase with LDAP object? Wouldn't cn=Domain Level,cn=ipa,cn=etc,SUFFIX be a better place for it? This is the last time we can change it, so I am asking now. Then, we will be stuck with this DN forever. I don't mind using cn=Domain Level , but where does the entry live, here you say cn=Domain Level,cn=ipa,cn=etc,SUFFIX and in the design page it is: cn=DomainLevel,cn=etc,SUFFIX The current version of the topology plugin is looking for cn=DomainLevel,cn=ipa,cn=etc,SUFFIX but I want to change it to do a search on objectclass=ipaDomainLevelConfig I see - we all need to unify the location apparently. I updated the design page to use cn=Domain Level,cn=ipa,cn=etc,SUFFIX. Tomas, please send the updated patch set, it should be an extremely simple change :-) I prefer the ipa parent and the space in the name, so I'm glad we could agree on this without much bikeshedding. Updated patch attaced. Tomas From 40607c32294e74baf11aca15aca20c7b20ad16df Mon Sep 17 00:00:00 2001 From: Tomas Babej tba...@redhat.com Date: Thu, 14 May 2015 10:49:55 +0200 Subject: [PATCH] Add Domain Level feature https://fedorahosted.org/freeipa/ticket/5018 --- ACI.txt| 2 + API.txt| 22 ++ install/share/72domainlevels.ldif | 6 ++ install/share/Makefile.am | 1 + install/updates/72-domainlevels.update | 13 install/updates/Makefile.am| 1 + ipalib/constants.py| 3 + ipalib/errors.py | 16 ipalib/plugins/domainlevel.py | 137 + ipaserver/install/dsinstance.py| 1 + ipaserver/install/ldapupdate.py| 5 ++ 11 files changed, 207 insertions(+) create mode 100644 install/share/72domainlevels.ldif create mode 100644 install/updates/72-domainlevels.update create mode 100644 ipalib/plugins/domainlevel.py diff --git a/ACI.txt b/ACI.txt index 933b57cb93e833981867953b516a67484f13dca3..6791e0c8d813ba22357960bc3b34911802513f2c 100644 --- a/ACI.txt +++ b/ACI.txt @@ -50,6 +50,8 @@ dn: dc=ipa,dc=example aci: (target = ldap:///idnsname=*,cn=dns,dc=ipa,dc=example;)(version 3.0;acl permission:System: Remove DNS Entries;allow (delete) groupdn = ldap:///cn=System: Remove DNS Entries,cn=permissions,cn=pbac,dc=ipa,dc=example;) dn: dc=ipa,dc=example aci: (targetattr = a6record || record || afsdbrecord || arecord || certrecord || cn || cnamerecord || dlvrecord || dnamerecord || dnsclass || dnsttl || dsrecord || hinforecord || idnsallowdynupdate || idnsallowquery || idnsallowsyncptr || idnsallowtransfer || idnsforwarders || idnsforwardpolicy || idnsname || idnssecinlinesigning || idnssoaexpire || idnssoaminimum || idnssoamname || idnssoarefresh || idnssoaretry || idnssoarname || idnssoaserial || idnsupdatepolicy || idnszoneactive || keyrecord || kxrecord || locrecord || managedby || mdrecord || minforecord || mxrecord || naptrrecord || nsec3paramrecord || nsecrecord || nsrecord || nxtrecord || ptrrecord || rrsigrecord || sigrecord || srvrecord || sshfprecord || tlsarecord || txtrecord)(target = ldap:///idnsname=*,cn=dns,dc=ipa,dc=example;)(version 3.0;acl permission:System: Update DNS Entries;allow (write) groupdn = ldap:///cn=System: Update DNS Entries,cn=permissions,cn=pbac,dc=ipa,dc=example;) +dn: dc=ipa,dc=example +aci: (targetattr = createtimestamp || entryusn || ipadomainlevel || modifytimestamp || objectclass)(targetfilter = (objectclass=ipadomainlevelconfig))(version 3.0;acl permission:System: Read Domain Level;allow (compare,read,search) userdn = ldap:///all;;) dn: cn=groups,cn=accounts,dc=ipa,dc=example aci: (targetfilter = (|(objectclass=ipausergroup)(objectclass=posixgroup)))(version 3.0;acl permission:System: Add Groups;allow (add) groupdn = ldap:///cn=System: Add Groups,cn=permissions,cn=pbac,dc=ipa,dc=example;) dn: cn=groups,cn=accounts,dc=ipa,dc=example diff --git a/API.txt b/API.txt index 346e35fda536f8411f8ea8f2dc32af4caebf3fca..df7d9edbf4c9285ba2d93bc72848b903b28d0fa8 100644 --- a/API.txt +++ b/API.txt @@ -1283,6 +1283,28 @@ option: Str('version?', exclude='webui') output: Entry('result', type 'dict', Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output:
Re: [Freeipa-devel] [PATCH 0325] Add Domain Level feature
On 05/19/2015 03:59 PM, Martin Kosek wrote: On 05/19/2015 03:56 PM, Tomas Babej wrote: On 05/19/2015 03:51 PM, Martin Kosek wrote: On 05/19/2015 03:49 PM, Ludwig Krispenz wrote: On 05/19/2015 03:36 PM, Martin Kosek wrote: On 05/19/2015 03:22 PM, Tomas Babej wrote: ... 3) Domain level is just a single integer and it should be treated as such, there's no need for an LDAPObject plugin and other unnecessary complexities. The implemetation could be as simple as (from top of my head, untested): That's right, I also considered this approach, but as far as I know you do not get the permission handling for the global DomainLevel entry otherwise. Ludwig, I changed the path for the global entry to cn=DomainLevel. I know this particular DN was added to the design by Simo, but why do we want to use CamelCase with LDAP object? Wouldn't cn=Domain Level,cn=ipa,cn=etc,SUFFIX be a better place for it? This is the last time we can change it, so I am asking now. Then, we will be stuck with this DN forever. I don't mind using cn=Domain Level , but where does the entry live, here you say cn=Domain Level,cn=ipa,cn=etc,SUFFIX and in the design page it is: cn=DomainLevel,cn=etc,SUFFIX The current version of the topology plugin is looking for cn=DomainLevel,cn=ipa,cn=etc,SUFFIX but I want to change it to do a search on objectclass=ipaDomainLevelConfig I see - we all need to unify the location apparently. I updated the design page to use cn=Domain Level,cn=ipa,cn=etc,SUFFIX. Tomas, please send the updated patch set, it should be an extremely simple change :-) I prefer the ipa parent and the space in the name, so I'm glad we could agree on this without much bikeshedding. Updated patch attaced. Tomas I still see +# Create default Domain Level entry if it does not exist +dn: cn=DomainLevel,cn=ipa,cn=etc,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: objectClass: ipaDomainLevelConfig +default: ipaDomainLevel: 0 ... Right, the space eluded me there, thanks for the catch. Tomas From de418a2b2f7fb4e80b4c52a382319bfe06ded0d2 Mon Sep 17 00:00:00 2001 From: Tomas Babej tba...@redhat.com Date: Thu, 14 May 2015 10:49:55 +0200 Subject: [PATCH] Add Domain Level feature https://fedorahosted.org/freeipa/ticket/5018 --- ACI.txt| 2 + API.txt| 22 ++ install/share/72domainlevels.ldif | 6 ++ install/share/Makefile.am | 1 + install/updates/72-domainlevels.update | 13 install/updates/Makefile.am| 1 + ipalib/constants.py| 3 + ipalib/errors.py | 16 ipalib/plugins/domainlevel.py | 137 + ipaserver/install/dsinstance.py| 1 + ipaserver/install/ldapupdate.py| 5 ++ 11 files changed, 207 insertions(+) create mode 100644 install/share/72domainlevels.ldif create mode 100644 install/updates/72-domainlevels.update create mode 100644 ipalib/plugins/domainlevel.py diff --git a/ACI.txt b/ACI.txt index 933b57cb93e833981867953b516a67484f13dca3..6791e0c8d813ba22357960bc3b34911802513f2c 100644 --- a/ACI.txt +++ b/ACI.txt @@ -50,6 +50,8 @@ dn: dc=ipa,dc=example aci: (target = ldap:///idnsname=*,cn=dns,dc=ipa,dc=example;)(version 3.0;acl permission:System: Remove DNS Entries;allow (delete) groupdn = ldap:///cn=System: Remove DNS Entries,cn=permissions,cn=pbac,dc=ipa,dc=example;) dn: dc=ipa,dc=example aci: (targetattr = a6record || record || afsdbrecord || arecord || certrecord || cn || cnamerecord || dlvrecord || dnamerecord || dnsclass || dnsttl || dsrecord || hinforecord || idnsallowdynupdate || idnsallowquery || idnsallowsyncptr || idnsallowtransfer || idnsforwarders || idnsforwardpolicy || idnsname || idnssecinlinesigning || idnssoaexpire || idnssoaminimum || idnssoamname || idnssoarefresh || idnssoaretry || idnssoarname || idnssoaserial || idnsupdatepolicy || idnszoneactive || keyrecord || kxrecord || locrecord || managedby || mdrecord || minforecord || mxrecord || naptrrecord || nsec3paramrecord || nsecrecord || nsrecord || nxtrecord || ptrrecord || rrsigrecord || sigrecord || srvrecord || sshfprecord || tlsarecord || txtrecord)(target = ldap:///idnsname=*,cn=dns,dc=ipa,dc=example;)(version 3.0;acl permission:System: Update DNS Entries;allow (write) groupdn = ldap:///cn=System: Update DNS Entries,cn=permissions,cn=pbac,dc=ipa,dc=example;) +dn: dc=ipa,dc=example +aci: (targetattr = createtimestamp || entryusn || ipadomainlevel || modifytimestamp || objectclass)(targetfilter = (objectclass=ipadomainlevelconfig))(version 3.0;acl permission:System: Read Domain Level;allow (compare,read,search) userdn = ldap:///all;;) dn: cn=groups,cn=accounts,dc=ipa,dc=example aci: (targetfilter = (|(objectclass=ipausergroup)(objectclass=posixgroup)))(version 3.0;acl permission:System: Add Groups;allow (add) groupdn = ldap:///cn=System: Add
[Freeipa-devel] [PATCH] 1112 Add service constraint delegation plugin
Add a plugin to manage service delegations, like the one allowing the HTTP service to obtain an ldap service ticket on behalf of the user. This does not include impersonation targets, so one cannot yet limit by user what tickets can be obtained. There is also no referential integrity for the memberPrincipal attribute since it is a string and not a DN. I don't see a way around this that isn't either clunky or requires a 389-ds plugin, both of which are overkill in this case IMHO. If you wonder why all the overrides it's because all of this is stored in the same container, and membership-like functions are used for a non-DN attribute (memberPrincipal). I used Alexander's patch in the ticket as a jumping off point. rob From 1fce6388c70911cc2dc0659fffdf1b7f493d9949 Mon Sep 17 00:00:00 2001 From: Rob Crittenden rcrit...@redhat.com Date: Thu, 14 May 2015 13:08:58 + Subject: [PATCH] Add plugin to manage service constraints Service Constraints are the delegation model used by ipa-kdb to grant service A to obtain a TGT for a user against service B. https://fedorahosted.org/freeipa/ticket/3644 --- API.txt| 72 VERSION| 4 +- install/updates/20-indices.update | 9 + install/updates/25-referint.update | 1 + ipalib/plugins/serviceconstraint.py| 444 +++ ipatests/test_xmlrpc/objectclasses.py | 11 + .../test_xmlrpc/test_serviceconstraint_plugin.py | 478 + 7 files changed, 1017 insertions(+), 2 deletions(-) create mode 100644 ipalib/plugins/serviceconstraint.py create mode 100644 ipatests/test_xmlrpc/test_serviceconstraint_plugin.py diff --git a/API.txt b/API.txt index 0808f3c64595495c8a9e60da5cbd689d5cdc6224..b548132a1e119204cd8452c4b8db80fa00263ccc 100644 --- a/API.txt +++ b/API.txt @@ -3694,6 +3694,78 @@ option: Str('version?', exclude='webui') output: Entry('result', type 'dict', Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('summary', (type 'unicode', type 'NoneType'), None) output: PrimaryKey('value', None, None) +command: serviceconstraint_add +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='constraint_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][ a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.-]?$', primary_key=True, required=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: StrEnum('type', values=(u'rule', u'target')) +option: Str('version?', exclude='webui') +output: Entry('result', type 'dict', Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (type 'unicode', type 'NoneType'), None) +output: PrimaryKey('value', None, None) +command: serviceconstraint_add_member +args: 1,6,3 +arg: Str('cn', attribute=True, cli_name='constraint_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][ a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Str('principal*', alwaysask=True, cli_name='principals', csv=True) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('target*', alwaysask=True, cli_name='targets', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', type 'int', None) +output: Output('failed', type 'dict', None) +output: Entry('result', type 'dict', Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +command: serviceconstraint_del +args: 1,2,3 +arg: Str('cn', attribute=True, cli_name='constraint_name', maxlength=255, multivalue=True, pattern='^[a-zA-Z0-9_.][ a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.-]?$', primary_key=True, query=True, required=True) +option: Flag('continue', autofill=True, cli_name='continue', default=False) +option: Str('version?', exclude='webui') +output: Output('result', type 'dict', None) +output: Output('summary', (type 'unicode', type 'NoneType'), None) +output: ListOfPrimaryKeys('value', None, None) +command: serviceconstraint_find +args: 1,9,4 +arg: Str('criteria?', noextrawhitespace=False) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('cn', attribute=True, autofill=False, cli_name='constraint_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][ a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.-]?$', primary_key=True, query=True, required=False) +option: Flag('no_members',
Re: [Freeipa-devel] [PATCH 0249] DNSSEC: update kasp configuration template: increase key size lifetime
Dne 15.5.2015 v 13:33 Martin Basti napsal(a): On 15/05/15 13:12, Petr Spacek wrote: On 14.5.2015 17:23, Martin Basti wrote: https://fedorahosted.org/freeipa/ticket/4657 Looking at 3072 bit key size, I think we can prolong KSK key rotation period to 2 years. It should be okay according to http://dx.doi.org/10.6028/NIST.SP.800-81-2 section 11.2. Modified patch is attached. Thank you for reviewing it :-) ACK Pushed to: master: 96f6d6ca09922f56aa63cfdebc934bd9db0d3ed5 ipa-4-1: 9b7fe37c9d3a8a11c3485c73fd67f90298e793c5 -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] Password vault
Before I send another patch I have some questions below. On 5/19/2015 3:27 AM, Jan Cholasta wrote: I changed the 'host vaults' to become 'service vaults'. The interface will look like this: $ ipa vault-find --service HTTP/server.example.com $ ipa vault-add test --service HTTP/server.example.com I also added user vaults: $ ipa vault-find --user testuser $ ipa vault-add test --user testuser Private vaults is a special case of user vaults where username=you. Host vaults can be added later once we define the use case. OK. I suppose you meant you're OK with not adding host vaults now? 4. The following code in get_dn() is incorrect: principal = getattr(context, 'principal') (name, realm) = split_principal(principal) name = name.split('/') if len(name) == 1: container_dn = DN(('cn', 'users'), container_dn) else: container_dn = DN(('cn', 'services'), container_dn) container_dn = DN(('cn', name[-1]), container_dn) A service does not have a private container like users (cn=username, cn=users, cn=vaults). The entry cn=name, cn=host, cn=services, cn=vaults is a service vault, not a container. The service vault is used by the admin to provide a secret for a service. I'm not sure what the behavior should be if a service is executing a vault command that uses a private container such as: $ ipa vault-add test Maybe it should just generate an error. Users, hosts and services are all user-like objects, is there a reason not to support private vaults for all of them? As mentioned above, it's not required in the design doc, but we can add it if there's a clear use case. I agree that at least for now we can change the service vault into a service container to store multiple service's private vaults. I don't really care about having a clear use case, I would prefer if the design was elegant enough to handle *all* the cases without any extra effort. The only way to know if the design will be future proof is if we have at least some idea how it will be used. Without that there is no guarantee. Host principals have this form: host/hostname@realm, so with the current code they will be considered a service and will have a service container. Do you want to add a new cn=hosts container just for hosts? Unless we have a specific reason (i.e. use case) I don't see a need to add specific code for hosts now, or at least until we get the core vault functionality working. 5. In create_container() why do you need to reconstruct the container_dn on each invocation even though the value is fixed? container_dn = DN(self.container_dn, self.api.env.basedn) Because self.api may not necessarily be the same as ipalib.api. Under what scenario would that be a problem? When someone uses the plugin with a different API object than ipalib.api. The original code seems to be working fine with ipalib.api. The current best practice is to use self.api and *all* new plugin code should do that. If it is a problem, why do we still use ipalib.api to initialize container_dn vault class attribute? container_dn = api.env.container_vault Then in get_dn() we basically construct the container_dn variable with values from both self.api and ipalib.api: container_dn = DN(self.container_dn, self.api.env.basedn) When is the self.api actually initialized? Can we initialize the container_dn (or base_dn as in the original code) attribute immediately after that? Not yet, but this will be fixed in the future. (Also, container_dn is part of the LDAPObject API, unlike base_dn used in the original code.) Is there a ticket for this? This change is not included. The code will now obtain the values from apilib.api.env at init time and store it in class attributes so it can be reused. container_dn = api.env.container_vault base_dn = DN(container_dn, api.env.basedn) Sorry, but no. Please just follow the best practice instead of trying to invent something new. This is not the right time and place to discuss this. We should be discussing the vault, not framework idiosyncracies. OK. 6. The loop in create_container() is incorrect. Suppose we're creating a container cn=A, cn=B, suffix and the parent container cn=B, suffix doesn't exist yet. The first add_entry() invocation will fail as expected, but instead of adding the parent entry the whole method will fail. Right, fixed. It's still not working. The new code is trying to add cn=vaults first, and it stops because it already exists, but the intermediary entries are still not added. Also the DN displayed in the message misleading: $ ipa vault-add test ipa: ERROR: container entry (cn=vaults) not found $ ipa vault-add test --host server.example.com ipa: ERROR: container entry (cn=vaults) not found The unit tests are failing because of this. I forgot to remove the break statement in the for loop. This change is not included. The original code and the tests work just fine. I would prefer if it was done
Re: [Freeipa-devel] [PATCH] 832-850 Stage Users Web UI and its prerequisites
On 05/15/2015 05:38 PM, David Kupka wrote: On 05/15/2015 12:34 PM, Petr Vobornik wrote: On 05/15/2015 10:59 AM, Petr Vobornik wrote: Stage User Web UI is actually just the last four patches(847-850). I expect that patch 848 - deleter dialog needs some adjustments (was discussed offline). The rest are prerequisites, namely: - update of patternfly - update navigation code to support multiple entities under one entity tree (it broke a memory feature/bug of the navigation) - support for facet tabs in sidebar Attaching new version of 847-1. The old version did not apply because I had also a new version of topology plugin UI (will be send later today) in my git tree. Hi! thanks for patches. Please note that I tested only functionality because I'm not familiar with WebUI internals. I tried your patch set together with Thierry's ULC patches and found following issues: 1) Missing all but 'Delete' actions in single stage user view. 'Enable', 'Disable', 'Unlock', 'Add OTP Token' and 'Rebuild auto membership ' actions are not relevant here. 2) Missing 'Restore' action in single preserve user view. 3) When deleting preserved user there are options to preserve or permanently delete user. This doesn't make sense and don't work. Preserved user is always permanently removed. 4) Action 'Delete' in single user view deletes the user without asking whether to 'preserve' or 'delete permanently'. *) I would prefer if the choice between 'preserve' and 'permanently delete' in delete dialog was done by directly clicking button not switching 'mode' radio button and then clicking 'delete'. Otherwise everything seems to work well. Hello, Petr this is looking very nice and easy to use. I am not an expert of the console, so I run the demo use case and was able to complete all the steps (being a stage adminitrator). The only remark I have is that when activating a stage user, the message mentions 'users' be the CLI actually supports only one user. Are you sure you want to activate selected users Except that this is perfect for me. Thanks a lot thierry -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0035] do not check for directory manager password during KRA uninstall
On 19/05/15 16:19, Martin Babinsky wrote: On 05/19/2015 01:17 PM, Martin Babinsky wrote: https://fedorahosted.org/freeipa/ticket/5028 updated patch attached Thanks. ACK -- Martin Basti -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH 0250] Pylint: fix false positive warning
Patch attached. -- Martin Basti From 45feb51a815276b2ea77dfe30ea007e058a40b7e Mon Sep 17 00:00:00 2001 From: Martin Basti mba...@redhat.com Date: Tue, 19 May 2015 18:37:43 +0200 Subject: [PATCH] Pylint: fix false positive warning for domain --- install/tools/ipa-server-install | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/install/tools/ipa-server-install b/install/tools/ipa-server-install index 7926a52a0b69c2684b6a04652af7c819a297dc63..cb6e1abe2016c0f8cefc35b1d685373f05b3ef89 100755 --- a/install/tools/ipa-server-install +++ b/install/tools/ipa-server-install @@ -952,7 +952,7 @@ def main(): else: domain_name = options.domain_name -domain_name = domain_name.lower() +domain_name = domain_name.lower() # pylint: disable=E1103 if not options.realm_name: realm_name = read_realm_name(domain_name, options.unattended) -- 2.1.0 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH 0036] merge KRA installation machinery to a single module
This patch is required for the installer ref@#$%ing work (https://fedorahosted.org/freeipa/ticket/4468). It required quite a bit of hacking to get it work as expected, but I hope that it's not so bad. Requires PATCH 0035 do not check for directory manager password during KRA uninstall to apply. -- Martin^3 Babinsky From 9d6fceb2c869d2939edf714eda02f90de0cf88f7 Mon Sep 17 00:00:00 2001 From: Martin Babinsky mbabi...@redhat.com Date: Fri, 15 May 2015 19:02:22 +0200 Subject: [PATCH] merge KRA installation machinery to a single module This is a prerequisite to further refactoring of KRA install/uninstall functionality in all IPA install scripts. https://fedorahosted.org/freeipa/ticket/4468 --- install/tools/ipa-replica-install| 21 +++ install/tools/ipa-server-install | 26 +++- ipaserver/install/ipa_kra_install.py | 118 --- ipaserver/install/kra.py | 116 ++ 4 files changed, 158 insertions(+), 123 deletions(-) create mode 100644 ipaserver/install/kra.py diff --git a/install/tools/ipa-replica-install b/install/tools/ipa-replica-install index f68cc8cf4722264ecea2f1f50de3aa245be24ef9..d0c4a28fcf0bf0a2693ffef10626a8f99a69c8bc 100755 --- a/install/tools/ipa-replica-install +++ b/install/tools/ipa-replica-install @@ -37,10 +37,10 @@ from ipaserver.install import memcacheinstance, dnskeysyncinstance from ipaserver.install import otpdinstance from ipaserver.install.replication import replica_conn_check, ReplicationManager from ipaserver.install.installutils import ( -create_replica_config, read_replica_info_kra_enabled, private_ccache) +create_replica_config, private_ccache) from ipaserver.plugins.ldap2 import ldap2 from ipaserver.install import cainstance -from ipaserver.install import krainstance +from ipaserver.install import kra from ipaserver.install import dns as dns_installer from ipalib import api, create_api, errors, util, certstore, x509 from ipalib.constants import CACERT @@ -473,12 +473,12 @@ def main(): config.setup_kra = options.setup_kra if config.setup_kra: -if not config.setup_ca: -print CA must be installed with the KRA -sys.exit(1) -if not read_replica_info_kra_enabled(config.dir): -print KRA is not installed on the master system -sys.exit(1) +try: +kra.check_install(options, dirman_password, + config.setup_ca, filename) +except RuntimeError as e: +print str(e) +exit(1) installutils.verify_fqdn(config.master_host_name, options.no_host_dns) @@ -660,10 +660,7 @@ def main(): ds.apply_updates() if options.setup_kra: -kra = krainstance.install_replica_kra(config) -service.print_msg(Restarting the directory server) -ds.restart() -kra.enable_client_auth_to_db(kra.dogtag_constants.KRA_CS_CFG_PATH) +kra.install(options, dirman_password, replica_file=filename) else: service.print_msg(Restarting the directory server) ds.restart() diff --git a/install/tools/ipa-server-install b/install/tools/ipa-server-install index cb6e1abe2016c0f8cefc35b1d685373f05b3ef89..f4ef71d84d30d79f70f164c30f274d8769b3e319 100755 --- a/install/tools/ipa-server-install +++ b/install/tools/ipa-server-install @@ -53,13 +53,13 @@ from ipaserver.install import httpinstance from ipaserver.install import ntpinstance from ipaserver.install import certs from ipaserver.install import cainstance -from ipaserver.install import krainstance from ipaserver.install import memcacheinstance from ipaserver.install import otpdinstance from ipaserver.install import sysupgrade from ipaserver.install import replication from ipaserver.install import dns as dns_installer from ipaserver.install import service, installutils +from ipaserver.install import kra from ipapython import version from ipapython import certmonger from ipapython import ipaldap @@ -577,11 +577,12 @@ def uninstall(): if cads_instance.is_configured(): cads_instance.uninstall() -kra_instance = krainstance.KRAInstance( -api.env.realm, dogtag_constants=dogtag_constants) -kra_instance.stop_tracking_certificates() -if kra_instance.is_installed(): -kra_instance.uninstall() +try: +kra.check_uninstall() +except RuntimeError: +pass +else: +kra.uninstall() ca_instance = cainstance.CAInstance( api.env.realm, certs.NSS_DIR, dogtag_constants=dogtag_constants) @@ -1290,18 +1291,7 @@ def main(): http.restart() if setup_kra: -kra = krainstance.KRAInstance(realm_name, -dogtag_constants=dogtag.install_constants) -kra.configure_instance(host_name, domain_name, dm_password, - dm_password, subject_base=options.subject) - -# This is done within stopped_service
Re: [Freeipa-devel] [UPSTREAM_FAILURES] Latest changes affect freeipa builds and client configuration
Hello Oleg, On 05/19/2015 05:21 PM, Oleg Fayans wrote: Dear colleagues I would like to notify you, that: 1. some of the recent changes in the upstream repo have broken the freeipa-client configuration. The symptoms are as follows: at some point during ipa-server-install the process fails with the following error: Restarting the web server Configuration of client side components failed! ipa-client-install returned: Command ''/usr/sbin/ipa-client-install' '--on-master' '--unattended' '--domain' 'myhome.net' '--server' 'testmaster.myhome.net' '--realm' 'MYHOME.NET' '--hostname' 'testmaster.myhome.net'' returned non-zero exit status 1 Looking at the ipaclient-install.log I could tell that the client was unable to authorize with the freshly installed master (kerberos issue?) I've attached the corresponding logs together with the session transcript of ipa-server-install command. This issue is observed since last Thursday at least. This error (and others of similar nature) should be fixed by the following commits: 7ff7b1f533cc10c44acf6020b545b253de1ad37b * move IPA-related http runtime directories to common subdirectory 5a741b614f39a148d849877e743200de5a7302db * explicitly destroy httpd service ccache file during httpinstance removal -- Martin^3 Babinsky -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0035] do not check for directory manager password during KRA uninstall
On 19/05/15 16:41, Martin Basti wrote: On 19/05/15 16:19, Martin Babinsky wrote: On 05/19/2015 01:17 PM, Martin Babinsky wrote: https://fedorahosted.org/freeipa/ticket/5028 updated patch attached Thanks. ACK NACK, lint failed -- Martin Basti -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0250] Pylint: fix false positive warning
On 05/19/2015 06:56 PM, Martin Basti wrote: Patch attached. ACK Pushed to master: ab69a0b1a74e639d23ba8e684d402eaf7582c67c -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 832-850 Stage Users Web UI and its prerequisites
On 05/19/2015 05:34 PM, thierry bordaz wrote: On 05/15/2015 05:38 PM, David Kupka wrote: On 05/15/2015 12:34 PM, Petr Vobornik wrote: On 05/15/2015 10:59 AM, Petr Vobornik wrote: Stage User Web UI is actually just the last four patches(847-850). I expect that patch 848 - deleter dialog needs some adjustments (was discussed offline). The rest are prerequisites, namely: - update of patternfly - update navigation code to support multiple entities under one entity tree (it broke a memory feature/bug of the navigation) - support for facet tabs in sidebar Attaching new version of 847-1. The old version did not apply because I had also a new version of topology plugin UI (will be send later today) in my git tree. Hi! thanks for patches. Please note that I tested only functionality because I'm not familiar with WebUI internals. I tried your patch set together with Thierry's ULC patches and found following issues: 1) Missing all but 'Delete' actions in single stage user view. 'Enable', 'Disable', 'Unlock', 'Add OTP Token' and 'Rebuild auto membership ' actions are not relevant here. Fixed in patch 850-1. 2) Missing 'Restore' action in single preserve user view. Will be added later. 3) When deleting preserved user there are options to preserve or permanently delete user. This doesn't make sense and don't work. Preserved user is always permanently removed. Fixed in patch new patch 853 4) Action 'Delete' in single user view deletes the user without asking whether to 'preserve' or 'delete permanently'. Will be fixed later. *) I would prefer if the choice between 'preserve' and 'permanently delete' in delete dialog was done by directly clicking button not switching 'mode' radio button and then clicking 'delete'. Otherwise everything seems to work well. Hello, Petr this is looking very nice and easy to use. I am not an expert of the console, so I run the demo use case and was able to complete all the steps (being a stage adminitrator). The only remark I have is that when activating a stage user, the message mentions 'users' be the CLI actually supports only one user. Are you sure you want to activate selected users You can select multiple users and activate them in UI. It will call stageuser_activate for each user. Except that this is perfect for me. Thanks a lot thierry In this new patch set there are also new icons. Instead of http://fontawesome.io/icon/plus/ - restore action has http://fontawesome.io/icon/heart/ - activate action has http://fontawesome.io/icon/check/ There are also new icons which indicates user state(in page header) in stage user details page. - stage users have http://fontawesome.io/icon/wrench/ - preserved users have http://fontawesome.io/icon/trash-o/ -- Petr Vobornik From 76ca6c223b842aecb87c41ee87164cc6eb3b0fb9 Mon Sep 17 00:00:00 2001 From: Petr Vobornik pvobo...@redhat.com Date: Tue, 19 May 2015 18:48:06 +0200 Subject: [PATCH] webui: prefer search facet's deleter dialog Deleter dialog in search facet is now chosen in order as follows: - facet's, defined as spec, e.g.: deleter_dialog: { $factory: IPA.user.deleter_dialog } - entity's, the same but it entity spec - default, which is IPA.search_deleter_dialog Previous didn't allow to override entity dialog with facet one and also definition by spec was not allowed. --- install/ui/src/freeipa/search.js | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/install/ui/src/freeipa/search.js b/install/ui/src/freeipa/search.js index 87523b673e9595ec02af2f5ed8fed5838cf8f958..941597561b50e17230a7f56affc9bd853b44b738 100644 --- a/install/ui/src/freeipa/search.js +++ b/install/ui/src/freeipa/search.js @@ -22,6 +22,7 @@ */ define([ +'./builder', './ipa', './jquery', './phases', @@ -30,7 +31,7 @@ define([ './spec_util', './text', './facet'], -function(IPA, $, phases, reg, rpc, su, text, mod_facet) { +function(builder, IPA, $, phases, reg, rpc, su, text, mod_facet) { var exp = {}; @@ -111,7 +112,7 @@ IPA.search_facet = function(spec, no_init) { */ that.command_options = spec.command_options || {}; -that.deleter_dialog = spec.deleter_dialog || IPA.search_deleter_dialog; +that.deleter_dialog = spec.deleter_dialog; that.create_header = function(container) { @@ -191,10 +192,12 @@ IPA.search_facet = function(spec, no_init) { return null; } -var dialog = that.managed_entity.get_dialog('remove'); - +var dialog = builder.build('', that.deleter_dialog); if (!dialog) { -dialog = that.deleter_dialog(); +dialog = that.managed_entity.get_dialog('remove'); +} +if (!dialog) { +dialog = IPA.search_deleter_dialog(); } dialog.entity_name = that.managed_entity.name; -- 2.1.0 From 043dd3c66b94fa88a129428d6a261a33128a5e8b Mon Sep 17 00:00:00 2001 From: Petr Vobornik
Re: [Freeipa-devel] [PATCH] 1112 Add service constraint delegation plugin
Rob Crittenden wrote: Add a plugin to manage service delegations, like the one allowing the HTTP service to obtain an ldap service ticket on behalf of the user. This does not include impersonation targets, so one cannot yet limit by user what tickets can be obtained. There is also no referential integrity for the memberPrincipal attribute since it is a string and not a DN. I don't see a way around this that isn't either clunky or requires a 389-ds plugin, both of which are overkill in this case IMHO. If you wonder why all the overrides it's because all of this is stored in the same container, and membership-like functions are used for a non-DN attribute (memberPrincipal). I used Alexander's patch in the ticket as a jumping off point. Removed a couple of hardcoded domain/realm elements in the tests. rob From b1366069b4494cac38d486d9dda02a03226fd0d3 Mon Sep 17 00:00:00 2001 From: Rob Crittenden rcrit...@redhat.com Date: Thu, 14 May 2015 13:08:58 + Subject: [PATCH] Add plugin to manage service constraints Service Constraints are the delegation model used by ipa-kdb to grant service A to obtain a TGT for a user against service B. https://fedorahosted.org/freeipa/ticket/3644 --- API.txt| 72 VERSION| 4 +- install/updates/20-indices.update | 9 + install/updates/25-referint.update | 1 + ipalib/plugins/serviceconstraint.py| 444 +++ ipatests/test_xmlrpc/objectclasses.py | 11 + .../test_xmlrpc/test_serviceconstraint_plugin.py | 479 + 7 files changed, 1018 insertions(+), 2 deletions(-) create mode 100644 ipalib/plugins/serviceconstraint.py create mode 100644 ipatests/test_xmlrpc/test_serviceconstraint_plugin.py diff --git a/API.txt b/API.txt index 0808f3c64595495c8a9e60da5cbd689d5cdc6224..b548132a1e119204cd8452c4b8db80fa00263ccc 100644 --- a/API.txt +++ b/API.txt @@ -3694,6 +3694,78 @@ option: Str('version?', exclude='webui') output: Entry('result', type 'dict', Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('summary', (type 'unicode', type 'NoneType'), None) output: PrimaryKey('value', None, None) +command: serviceconstraint_add +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='constraint_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][ a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.-]?$', primary_key=True, required=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: StrEnum('type', values=(u'rule', u'target')) +option: Str('version?', exclude='webui') +output: Entry('result', type 'dict', Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (type 'unicode', type 'NoneType'), None) +output: PrimaryKey('value', None, None) +command: serviceconstraint_add_member +args: 1,6,3 +arg: Str('cn', attribute=True, cli_name='constraint_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][ a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Str('principal*', alwaysask=True, cli_name='principals', csv=True) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('target*', alwaysask=True, cli_name='targets', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', type 'int', None) +output: Output('failed', type 'dict', None) +output: Entry('result', type 'dict', Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +command: serviceconstraint_del +args: 1,2,3 +arg: Str('cn', attribute=True, cli_name='constraint_name', maxlength=255, multivalue=True, pattern='^[a-zA-Z0-9_.][ a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.-]?$', primary_key=True, query=True, required=True) +option: Flag('continue', autofill=True, cli_name='continue', default=False) +option: Str('version?', exclude='webui') +output: Output('result', type 'dict', None) +output: Output('summary', (type 'unicode', type 'NoneType'), None) +output: ListOfPrimaryKeys('value', None, None) +command: serviceconstraint_find +args: 1,9,4 +arg: Str('criteria?', noextrawhitespace=False) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('cn', attribute=True, autofill=False, cli_name='constraint_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][
Re: [Freeipa-devel] [TEST PLAN] User lifecycle plugin
On 05/13/2015 05:54 PM, Martin Basti wrote: On 13/05/15 17:44, David Kupka wrote: On 05/13/2015 02:57 PM, Lenka Ryznarova wrote: Hi, I've prepared test plan design for User Lifecycle Plugin - [1]. Please review and let me know if you have any comments on that. Thanks, Lenka [1] http://www.freeipa.org/page/V4/User_Life-Cycle_Management/Test_Plan Hi, thanks for sharing the test plan. I've quickly looked at it and have just 2 notes: 1) please add Verify that specific GID number of a staged entry is preserved after activation 2) In a block of tests Try activating staged entry with every-possible-attribute please add a activation tests. It should be possible to add/modify the attributes in staging are freely all the check must be applied when the user is activated. Hello, following tests are out of scope of API tests, but would be nice to have: * test to make sure the staged/deleted user is unable to kinit * opposite case the reactivated user is able to kinit (if this case is valid) * ACI tests: to make sure only proper roles can manipulate with staged users. Hello Lenka, This is looking as a very good set of tests. If you have time, you may also add those tests: * try do a simple bind with a stage/delete user * option only-delete, also-delete and --deleted are deprecated.. sorry the design is not up-to-date, now it is --preserved flag * Run the tests as admin * Run the tests as a stageadm (member of 'User administrator') * Try to update a stageuser with invalid uid/gidnumber (0 , or string) * Check that activated and undelete users are member of ipausers * Being authenticated with a newly activated user, check you have limited access to entries (only modify yourself) * Try to add (ldapadd) an entry directly in delete container, should not be allowed even for admin. * Create a user that is member of a 'system provisioning' role. 'system provisioning' role has the 'Stage user provisioning' priviledge. This user should only be allow to add 'stage' user (no read, delete, mod) Thanks thierry -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 851-852 webui: datetime widget with datepicker
On 05/18/2015 03:40 PM, Petr Vobornik wrote: Datetime widget was transform from a simple text input to 3 separate inputs: - date with bootstrap-datepicker - hour - minute e.g.: Validity end[ 2015-05-18 ] [23]:[01] UTC Vendor[ abc] Editation of seconds is not supported. https://fedorahosted.org/freeipa/ticket/4347 Works well for me. I would have only a small nitpick that it would be nice if the current date was highlighted in the datepicker widget for better orientation. Otherwise ACK. -- Martin^3 Babinsky -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 830 webui: fix empty table border in Firefox
On 05/15/2015 11:01 AM, Petr Vobornik wrote: Firefox suffers from: https://bugzilla.mozilla.org/show_bug.cgi?id=409254 This is a workaround to fix it. ACK -- Martin^3 Babinsky -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0035] do not check for directory manager password during KRA uninstall
On 05/19/2015 05:55 PM, Martin Basti wrote: On 19/05/15 16:41, Martin Basti wrote: On 19/05/15 16:19, Martin Babinsky wrote: On 05/19/2015 01:17 PM, Martin Babinsky wrote: https://fedorahosted.org/freeipa/ticket/5028 updated patch attached Thanks. ACK NACK, lint failed Attaching patch that passes lint. -- Martin^3 Babinsky From ed5ac82ff1574c0fa78b201605be5aec3a446895 Mon Sep 17 00:00:00 2001 From: Martin Babinsky mbabi...@redhat.com Date: Tue, 19 May 2015 13:01:27 +0200 Subject: [PATCH] do not check for directory manager password during KRA uninstall ipa-kra-install validates and asks for directory manager password during uninstallation phase. Since this password is never used during service uninstall, the uninstaller will not perform these checks anymore. https://fedorahosted.org/freeipa/ticket/5028 --- ipaserver/install/ipa_kra_install.py | 34 +- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/ipaserver/install/ipa_kra_install.py b/ipaserver/install/ipa_kra_install.py index 099737fa9ae3ad5bbfb36772cb0ced9c676043f4..386da286ab11b043ebd12e18047c73e23baa5672 100644 --- a/ipaserver/install/ipa_kra_install.py +++ b/ipaserver/install/ipa_kra_install.py @@ -74,26 +74,9 @@ class KRAInstall(admintool.AdminTool): installutils.check_server_configuration() -if self.options.unattended and self.options.password is None: -self.option_parser.error( -Directory Manager password must be specified using -p - in unattended mode -) - api.bootstrap(in_server=True) api.finalize() -def ask_for_options(self): -super(KRAInstall, self).ask_for_options() - -if not self.options.password: -self.options.password = installutils.read_password( -Directory Manager, confirm=False, -validate=False, retry=False) -if self.options.password is None: -raise admintool.ScriptError( -Directory Manager password required) - @classmethod def get_command_class(cls, options, args): if options.uninstall: @@ -152,6 +135,12 @@ class KRAInstaller(KRAInstall): def validate_options(self, needs_root=True): super(KRAInstaller, self).validate_options(needs_root=True) +if self.options.unattended and self.options.password is None: +self.option_parser.error( +Directory Manager password must be specified using -p + in unattended mode +) + dogtag_version = int(api.env.dogtag_version) enable_kra = api.env.enable_kra @@ -187,6 +176,17 @@ class KRAInstaller(KRAInstall): self.option_parser.error(Too many parameters provided. No replica file is required.) +def ask_for_options(self): +super(KRAInstaller, self).ask_for_options() + +if not self.options.unattended and self.options.password is None: +self.options.password = installutils.read_password( +Directory Manager, confirm=False, +validate=False, retry=False) +if self.options.password is None: +raise admintool.ScriptError( +Directory Manager password required) + def _run(self): super(KRAInstaller, self).run() print dedent(self.INSTALLER_START_MESSAGE) -- 2.1.0 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code