On Thu, Jun 04, 2015 at 03:58:25PM +0200, Martin Basti wrote:
> On 04/06/15 15:48, Martin Kosek wrote:
> >On 06/04/2015 03:40 PM, Martin Basti wrote:
> >>On 04/06/15 08:59, Fraser Tweedale wrote:
> >>>On Wed, Jun 03, 2015 at 06:49:13PM +0200, Martin Basti wrote:
> >>>>On 03/06/15 16:17, Fraser Tweedale wrote:
> >>>>>On Tue, Jun 02, 2015 at 06:37:42PM +0200, Martin Basti wrote:
> >>>>>>On 02/06/15 14:11, Fraser Tweedale wrote:
> >>>>>>>On Mon, Jun 01, 2015 at 05:22:28PM +1000, Fraser Tweedale wrote:
> >>>>>>>>On Mon, Jun 01, 2015 at 05:10:58PM +1000, Fraser Tweedale wrote:
> >>>>>>>>>On Fri, May 29, 2015 at 01:03:46PM +0200, Martin Kosek wrote:
> >>>>>>>>>>On 05/29/2015 11:21 AM, Martin Basti wrote:
> >>>>>>>>>>>On 29/05/15 06:17, Fraser Tweedale wrote:
> >>>>>>>>>>>>On Thu, May 28, 2015 at 02:42:53PM +0200, Martin Basti wrote:
> >>>>>>>>>>>>>On 28/05/15 11:48, Martin Basti wrote:
> >>>>>>>>>>>>>>On 27/05/15 16:04, Fraser Tweedale wrote:
> >>>>>>>>>>>>>>>Hello all,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>Fresh certificate management patchset; Changelog:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>- Now depends on patch freeipa-ftweedal-0014 for correct
> >>>>>>>>>>>>>>>cert-request behaviour with host and service principals.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>- Updated Dogtag dependency to 10.2.4-1.  Should should be in
> >>>>>>>>>>>>>>>f22 soon, but for f22 right now or for f21, please grab from my
> >>>>>>>>>>>>>>>copr: https://copr.fedoraproject.org/coprs/ftweedal/freeipa/
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>    Martin^1 could you please add to the quasi-official freeipa
> >>>>>>>>>>>>>>>    copr?  SRPM lives at
> >>>>>>>>>>>>>>>    https://frase.id.au/pki-core-10.2.4-1.fc21.src.rpm.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>- cert-request now verifies that for user principals, CSR CN
> >>>>>>>>>>>>>>>matches uid and, DN emailAddress and SAN rfc822Name match 
> >>>>>>>>>>>>>>>user's
> >>>>>>>>>>>>>>>email address, if either of those is present.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>- Fixed one or two other sneaky little bugs.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>On Wed, May 27, 2015 at 01:59:30AM +1000, Fraser Tweedale 
> >>>>>>>>>>>>>>>wrote:
> >>>>>>>>>>>>>>>>Hi all,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>Please find attached the latest certificate management
> >>>>>>>>>>>>>>>>patchset, which introduces the `caacl' plugin and various 
> >>>>>>>>>>>>>>>>fixes
> >>>>>>>>>>>>>>>>and improvement to earlier patches.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>One important change to earlier patches is reverting the name
> >>>>>>>>>>>>>>>>of the default profile to 'caIPAserviceCert' and using the
> >>>>>>>>>>>>>>>>existing instance of this profile on upgrade (but not install)
> >>>>>>>>>>>>>>>>in case it has been modified.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>Other notes:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>- Still have changes in ipa-server-install (fewer lines now,
> >>>>>>>>>>>>>>>>though)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>- Still have the ugly import hack.  It is not a high priority
> >>>>>>>>>>>>>>>>for me, i.e. I think it should wait until after alpha
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>- Still need to update 'service' and 'host' plugins to support
> >>>>>>>>>>>>>>>>multiple certificates.  (The userCertificate attribute schema
> >>>>>>>>>>>>>>>>itself is multi-valued, so there are no schema issues here)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>- The TODOs in [1]; mostly certprofile CLI conveniences and
> >>>>>>>>>>>>>>>>supporting multiple profiles for hosts and services (which
> >>>>>>>>>>>>>>>>requires changes to framework only, not schema).  [1]:
> >>>>>>>>>>>>>>>>http://idm.etherpad.corp.redhat.com/rhel72-cert-mgmt-progress
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>Happy reviewing!  I am pleased with the initial cut of the
> >>>>>>>>>>>>>>>>caacl plugin but I'm sure you will find some things to be 
> >>>>>>>>>>>>>>>>fixed
> >>>>>>>>>>>>>>>>:)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>Cheers, Fraser
> >>>>>>>>>>>>>>[root@vm-093 ~]#  ipa-replica-prepare vm-094.example.com
> >>>>>>>>>>>>>>--ip-address 10.34.78.94 Directory Manager (existing master)
> >>>>>>>>>>>>>>password:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>Preparing replica for vm-094.example.com from vm-093.example.com
> >>>>>>>>>>>>>>Creating SSL certificate for the Directory Server not 
> >>>>>>>>>>>>>>well-formed
> >>>>>>>>>>>>>>(invalid token): line 2, column 14
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>I cannot create replica file.  It work on the upgraded server,
> >>>>>>>>>>>>>>but it doesn't work on the newly installed server.  I'm not sure
> >>>>>>>>>>>>>>if this causes your patches which modifies the ca-installer, or
> >>>>>>>>>>>>>>the newer version of dogtag.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>Or if there was any other changes in master, I will continue to
> >>>>>>>>>>>>>>investigate with new RPM from master branch.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>Martin^2
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>ipa-replica-prepare works for: * master branch * master branch +
> >>>>>>>>>>>>>pki-ca 10.2.4-1
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>So something in your patches is breaking it
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>Martin^2
> >>>>>>>>>>>>>
> >>>>>>>>>>>>Martin, master + my patches with pki 10.2.4-1 is working for me on
> >>>>>>>>>>>>f21 and f22.  Can you provide ipa-replica-prepare --debug output 
> >>>>>>>>>>>>and
> >>>>>>>>>>>>Dogtag debug log?  ( /var/log/pki/pki-tomcat/ca/debug )
> >>>>>>>>>>>>
> >>>>>>>>>>>>Thanks,
> >>>>>>>>>>>>Fraser
> >>>>>>>>>>>I can not reproduce it today. And I already recycled the VMs from
> >>>>>>>>>>>yesterday. :-(
> >>>>>>>>>>>
> >>>>>>>>>>In that case I would suggest ACKing&pushing the patch and fixing the
> >>>>>>>>>>bug if
> >>>>>>>>>>it comes again. The tree may now be a bit unstable, given the 
> >>>>>>>>>>number of
> >>>>>>>>>>patches going in.
> >>>>>>>>>>
> >>>>>>>>>>My main motivation here is to unblock Fraser.
> >>>>>>>>>>
> >>>>>>>>>>Thanks,
> >>>>>>>>>>Martin
> >>>>>>>>>Rebased patchset attached; no other changes.
> >>>>>>>>Heads up: I just discovered I have introduced a bug with
> >>>>>>>>ipa-replica-install, when it is spawning the CA instance.  I think
> >>>>>>>>replication it only causes issues with ``--setup-ca``.
> >>>>>>>>
> >>>>>>>>I will try and sort it out tomorrow or later tonight (I have to head
> >>>>>>>>out for a few hours now, though); and I'm not suggesting it should
> >>>>>>>>block the push but it's something to be aware of.
> >>>>>>>>
> >>>>>>>>Cheers,
> >>>>>>>>Fraser
> >>>>>>>>
> >>>>>>>New patchset attached ; haven't gotten to the bottom of the
> >>>>>>>ipa-replica-install issue mentioned above, but it fixes an upgrade
> >>>>>>>bug.
> >>>>>>>
> >>>>>>>The change is:
> >>>>>>>
> >>>>>>>diff --git a/ipaserver/install/server/upgrade.py
> >>>>>>>b/ipaserver/install/server/upgrade.py
> >>>>>>>index c288282..c5f4d37 100644
> >>>>>>>--- a/ipaserver/install/server/upgrade.py
> >>>>>>>+++ b/ipaserver/install/server/upgrade.py
> >>>>>>>@@ -316,7 +316,7 @@ def ca_enable_ldap_profile_subsystem(ca):
> >>>>>>>                   caconfig.CS_CFG_PATH,
> >>>>>>>                   directive,
> >>>>>>>                   separator='=')
> >>>>>>>-            if value == 'ProfileSubsystem':
> >>>>>>>+            if value == 
> >>>>>>>'com.netscape.cmscore.profile.ProfileSubsystem':
> >>>>>>>                   needs_update = True
> >>>>>>>                   break
> >>>>>>>       except OSError, e:
> >>>>>>>@@ -328,7 +328,7 @@ def ca_enable_ldap_profile_subsystem(ca):
> >>>>>>>           installutils.set_directive(
> >>>>>>>               caconfig.CS_CFG_PATH,
> >>>>>>>               directive,
> >>>>>>>-            'LDAPProfileSubsystem',
> >>>>>>>+            'com.netscape.cmscore.profile.LDAPProfileSubsystem',
> >>>>>>>               quotes=False,
> >>>>>>>               separator='=')
> >>>>>>>
> >>>>>>>Cheers,
> >>>>>>>Fraser
> >>>>>>>
> >>>>>>>
> >>>>>>Thank you,
> >>>>>>
> >>>>>>1)
> >>>>>>ipa-getcert request  (getcert -c IPA)
> >>>>>>doesnt work,
> >>>>>>
> >>>>>>Request ID '20150602145845':
> >>>>>>      status: CA_REJECTED
> >>>>>>      ca-error: Server at https://vm-137.example.com/ipa/xml denied our
> >>>>>>request, giving up: 3007 (RPC failed at server.  'profile_id' is 
> >>>>>>required).
> >>>>>>
> >>>>>>2)
> >>>>>>Error from rpm install
> >>>>>>Unexpected error - see /var/log/ipaupgrade.log for details:
> >>>>>>SkipPluginModule: dogtag not selected as RA plugin
> >>>>>>
> >>>>>>Just for record as known issue, this will be fixed later in a new patch.
> >>>>>>
> >>>>>>3)
> >>>>>>+        Str('profile_id', validate_profile_id,
> >>>>>>+            label=_("Profile ID"),
> >>>>>>+            doc=_("Certificate Profile to use"),
> >>>>>>+        )
> >>>>>>Please mark this param as optional. ('profile_id?')
> >>>>>>This will fix issue 1, but 1 will need a option to specify profile_id
> >>>>>>
> >>>>>>Also move API related change from patch 9 to patch 11 + increment 
> >>>>>>VERSION
> >>>>>>
> >>>>>>4)
> >>>>>>* Maybe I do everything wrong :)
> >>>>>>
> >>>>>>   I'm not able to create certificate stored in FILE, via ipa-getcert 
> >>>>>> request.
> >>>>>>I'm getting error:
> >>>>>>status: CA_UNREACHABLE
> >>>>>>      ca-error: Server at https://vm-137.example.com/ipa/xml failed 
> >>>>>> request,
> >>>>>>will retry: 4001 (RPC failed at server. vm-137.example....@example.com: 
> >>>>>>host
> >>>>>>not found).
> >>>>>>
> >>>>>>or error:
> >>>>>>Request ID '20150602154115':
> >>>>>>      status: CA_REJECTED
> >>>>>>      ca-error: Server at https://vm-137.example.com/ipa/xml denied our
> >>>>>>request, giving up: 2100 (RPC failed at server.  Insufficient access: 
> >>>>>>not
> >>>>>>allowed to perform this command).
> >>>>>>(I'm root and kinited as admin)
> >>>>>>
> >>>>>>Maybe additional ACI is required for cert_request as it is 
> >>>>>>VirtualCommand
> >>>>>>
> >>>>>>
> >>>>>>-- 
> >>>>>>Martin Basti
> >>>>>>
> >>>>>Thanks for report.  Attached patchset should fix the certmonger
> >>>>>issues, and also makes cert-request --profile-id argument optional.
> >>>>>
> >>>>>The changes were fixup'd into the appropriate patches but the
> >>>>>combined diff follows.  (Note that the API.txt and VERSION changes
> >>>>>you recommended were executed but are missing from this diff.)
> >>>>>
> >>>>>Thanks,
> >>>>>Fraser
> >>>>>
> >>>>>diff --git a/ipalib/plugins/caacl.py b/ipalib/plugins/caacl.py
> >>>>>index c09df86..a9dde86 100644
> >>>>>--- a/ipalib/plugins/caacl.py
> >>>>>+++ b/ipalib/plugins/caacl.py
> >>>>>@@ -12,7 +12,7 @@ from ipalib.plugins.baseldap import (
> >>>>>       LDAPUpdate, LDAPRetrieve, LDAPAddMember, LDAPRemoveMember,
> >>>>>       pkey_to_value)
> >>>>>   from ipalib.plugins.certprofile import validate_profile_id
> >>>>>-from ipalib.plugins.service import normalize_principal
> >>>>>+from ipalib.plugins.service import normalize_principal, 
> >>>>>split_any_principal
> >>>>>   from ipalib import _, ngettext
> >>>>>   from ipapython.dn import DN
> >>>>>@@ -69,7 +69,7 @@ def _acl_make_request(principal_type, principal, 
> >>>>>ca_ref,
> >>>>>profile_id):
> >>>>>           groups = user_obj.get('memberof_group', [])
> >>>>>           groups += user_obj.get('memberofindirect_group', [])
> >>>>>       elif principal_type == 'host':
> >>>>>-        hostname = principal[5:]
> >>>>>+        service, hostname, realm = split_any_principal(principal)
> >>>>>           host_obj = api.Command.host_show(hostname)['result']
> >>>>>           groups = host_obj.get('memberof_hostgroup', [])
> >>>>>           groups += host_obj.get('memberofindirect_hostgroup', [])
> >>>>>diff --git a/ipalib/plugins/cert.py b/ipalib/plugins/cert.py
> >>>>>index 70ae610..1878e5a 100644
> >>>>>--- a/ipalib/plugins/cert.py
> >>>>>+++ b/ipalib/plugins/cert.py
> >>>>>@@ -247,7 +247,7 @@ class cert_request(VirtualCommand):
> >>>>>               default=False,
> >>>>>               autofill=True
> >>>>>           ),
> >>>>>-        Str('profile_id', validate_profile_id,
> >>>>>+        Str('profile_id?', validate_profile_id,
> >>>>>               label=_("Profile ID"),
> >>>>>               doc=_("Certificate Profile to use"),
> >>>>>           )
> >>>>>@@ -346,7 +346,14 @@ class cert_request(VirtualCommand):
> >>>>>           bind_principal = split_any_principal(getattr(context, 
> >>>>> 'principal'))
> >>>>>           bind_service, bind_name, bind_realm = bind_principal
> >>>>>-        if bind_principal != principal:
> >>>>>+        if bind_service is None:
> >>>>>+            bind_principal_type = USER
> >>>>>+        elif bind_service == 'host':
> >>>>>+            bind_principal_type = HOST
> >>>>>+        else:
> >>>>>+            bind_principal_type = SERVICE
> >>>>>+
> >>>>>+        if bind_principal != principal and bind_principal_type != HOST:
> >>>>>               # Can the bound principal request certs for another 
> >>>>> principal?
> >>>>>               self.check_access()
> >>>>>@@ -359,7 +366,7 @@ class cert_request(VirtualCommand):
> >>>>>                   error=_("Failure decoding Certificate Signing Request:
> >>>>>%s") % e)
> >>>>>           # host principals may bypass allowed ext check
> >>>>>-        if bind_service != 'host':
> >>>>>+        if bind_principal_type != HOST:
> >>>>>               for ext in extensions:
> >>>>>                   operation = self._allowed_extensions.get(ext)
> >>>>>                   if operation:
> >>>>>diff --git a/ipapython/dogtag.py b/ipapython/dogtag.py
> >>>>>index 659751e..53085f7 100644
> >>>>>--- a/ipapython/dogtag.py
> >>>>>+++ b/ipapython/dogtag.py
> >>>>>@@ -47,7 +47,7 @@ INCLUDED_PROFILES = {
> >>>>>       (u'caIPAserviceCert', u'Standard profile for network services', 
> >>>>> True),
> >>>>>       }
> >>>>>-DEFAULT_PROFILE = 'caIPAserviceCert'
> >>>>>+DEFAULT_PROFILE = u'caIPAserviceCert'
> >>>>>   class Dogtag10Constants(object):
> >>>>>       DOGTAG_VERSION = 10
> >>>>Should the user certificates behave in the same way as host and service
> >>>>certificates, i.e should be revoked after user-del or user-mod operation??
> >>>>If yes it would be an additional patch.
> >>>>
> >>>>Please move API.txt fragment from patch 9 to patch 11
> >>>>With this change ACK for patches 1-11, to unblock testing. For patches 
> >>>>12-13
> >>>>I need more time.
> >>>>
> >>>>-- 
> >>>>Martin Basti
> >>>>
> >>>Updated patches attached.  Only your requested change for 1-11.  For
> >>>12-13 (caacl plugin) it was updated to LDAPAddMember and
> >>>LDAPRemoveMember functionality for adding profiles to ACL - this has
> >>>the desirable effect of making sure the profile actually exists :)
> >>>
> >>>Thanks,
> >>>Fraser
> >>Hello,
> >>
> >>design page needs upgrade
> >>
> >>Please fix
> >>1)
> >>ngettext/ugettext missing? (several times)
> >>('%i object added.', '%i objects added.')
> >>
> >>2)
> >>   --allprofiles=BOOL  Allow use of all profiles
> >>   --allusers=BOOL     Allow all users
> >>   --allhosts=BOOL     Allow all hosts
> >>   --allservices=BOOL  Allow all services
> >>
> >>Other commands use the separate words with '-', I suggest to use
> >>--all-profiles=True, etc..
> >For these, should we follow the example in hbacrule or sudorule:
> >
> ># ipa hbacrule-mod --help
> >Usage: ipa [global-options] hbacrule-mod NAME [options]
> >
> >Modify an HBAC rule.
> >Options:
> >   -h, --help            show this help message and exit
> >   --usercat=['all']     User category the rule applies to
> >   --hostcat=['all']     Host category the rule applies to
> >   --servicecat=['all']  Service category the rule applies to
> >
> >i.e. what I think Martin describes  in 4)
> >
> >>3)
> >>In the following example, there is missing ACL name:
> >>+    ipa caacl-add-user --user=alice
> >>
> >>4)
> >>attributes 'ipaCaAclAllCAs', 'ipaCaAclAllProfiles', 'ipaCaAclAllUsers',
> >>'ipaCaAclAllHosts', 'ipaCaAclAllServices' should be called 
> >>ipaCaAclCAsCategory,
> >>etc... to be consistent, please reuse usercategory, hostcategory, etc. and
> >>create new category attribute definitions for the rest.
> >>Please read sudorule.py for details.
> >>Respectively instead BOOLEAN True, the value 'all' should be there. This 
> >>allows
> >>to extend it in future.
> >>
> >>5)
> >>Missing referint plugin configuration for attribute 
> >>'ipacaaclmembercertprofile'
> >>Please add it into install/updates/25-referint.update (+ other member
> >>attributes if missing)
> >>
> >>6)
> >>ACI:
> >>'memberhostgroup' is not virtual nor real attribute, please remove it from
> >>there (Honza told me there is an error in HBAC ipa plugin, I will send fix)
> >>
> 7)
> Missing upgrade?
> 
> +        self.step("creating default CA ACL rule", self.add_caacl)
> 
> This was added to dsinstance, but I cannot found it in upgrade.
> 
What heuristic should we use?  We only ever want to add it on the
first upgrade.  Is it appropriate to do something like this:

    if sysupgrade.get_upgrade_state(...):
        return

    acls = search_caacls_in_ldap()
    if not acls:
        add_default_acl()

    sysupgrade.set_upgrade_state(..., True)


This will only ever try to add the default ACL once, and it will
only actually add it if there are no caacl objects.

Next problem - I tried to implement the above but always had LDAP
connection problems.  What is the sure-fire way to talk to LDAP
during upgrade process?

Cheers,
Fraser

-- 
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

Reply via email to