From mbabinsk at redhat.com Mon May 4 08:50:10 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 04 May 2015 10:50:10 +0200 Subject: [Freeipa-devel] [PATCH 0031] provide a dedicated ccache file to httpd In-Reply-To: <20150430062325.GG11785@redhat.com> References: <554117FB.7070203@redhat.com> <5541B88A.4080506@redhat.com> <20150430062325.GG11785@redhat.com> Message-ID: <554732C2.3030707@redhat.com> On 04/30/2015 08:23 AM, Alexander Bokovoy wrote: > On Thu, 30 Apr 2015, Jan Cholasta wrote: >> Hi, >> >> Dne 29.4.2015 v 19:42 Martin Babinsky napsal(a): >>> The attached patch is a merge of PATCHES 0031-0032 incorporating Simo's >>> and Martin's suggestions (see e.g. >>> https://www.redhat.com/archives/freeipa-devel/2015-April/msg00327.html >>> for reference). >>> >>> https://fedorahosted.org/freeipa/ticket/4973 >> >> IMHO we should set the environment variable in >> /etc/systemd/system/httpd.service, instead of providing a new service >> file, because we are just changing configuration, not creating a new >> concurrent httpd instance, as is the case with ipa-memcached, and also >> not using alternative httpd implementation which masks the current >> one, as is the case with bind-pkcs11. It would simplify the whole >> thing significantly and it's even recommended in httpd.service to do > I agree. > >> so: >> >> # For example, to pass additional options (for instance, -D >> definitions) to the >> # httpd binary at startup, you need to create a file named >> # "/etc/systemd/system/httpd.service" containing: >> # .include /lib/systemd/system/httpd.service >> # [Service] >> # Environment=OPTIONS=-DMY_DEFINE >> >> (BTW I wonder why /etc/sysconfig/httpd support was removed from httpd >> in Fedora >> (), >> it seems like a better place to customize environment variables, >> rather than having to create a modified service file...) > We had discussion with Joe Orton (httpd maintainer) a while ago and his > arguments were following: > ---- > Hi guys, we made that change to adopt what is considered "best practice" > for systemd. The change is not in RHEL7, only Fedora >= 20. > > I would not say we are strongly wedded to that change, but the use case > you provide seems very weak. /etc/sysconfig/httpd is intended to be > user-configurable and if users do "rm -f /etc/sysconfig/httpd" then > Fedora packages should keep working correctly. Can we find a more > robust way to achieve the same results? Why is it required that the > environment variable is set globally within /usr/sbin/httpd? > > ... [and later in dicussion] > > I'd argue that in this case you should not be using httpd.service as-is; > instead it would be correct to create an "httpd-ipa.service" unit file > or similar, which can ".include" the system httpd.service, and sets up > the appropriate Environment= (or EnvironmentFile=) directly. > > Also, if the intent is to purely to change mod_auth_kerb's interaction > with libkrb5 is there no way to do this via the libkrb API - or > mod_auth_kerb's existing use thereof? > > The use of /etc/sysconfig/httpd has historically been a mild PITA and > I'm not seeing a compelling reason to revert the decision to kill it > here. > ---- > >> Anyway, I would prefer if we set it in a way that works on non-systemd >> distros as well. Can't we just set "GssapiCredStore >> ccache:FILE:/var/run/httpd/krbcache/krb5ccache" in >> /etc/httpd/conf.d/ipa.conf? > It is not just mod_auth_gssapi, it is needed for users of the > credentials obtained by mod_auth_gssapi. mod_auth_gssapi only sets > KRB5CCNAME value when there is delegation of credentials in use and > there is something to delegate. > > Ok, attaching updated patches. After the discussion with Martin^1 we decided to play it safe and put KRB5CCNAME into /etc/systemd/system/httpd.service. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0031.2-provide-dedicated-ccache-file-for-httpd.patch Type: text/x-patch Size: 2384 bytes Desc: not available URL: From mkosek at redhat.com Mon May 4 08:50:15 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 04 May 2015 10:50:15 +0200 Subject: [Freeipa-devel] User Certificates in 4.2 - design and questions Message-ID: <554732C7.5000109@redhat.com> Hello, Please let me promote the design for one of the major FreeIPA 4.2 features, the (user) certificates and Smart Card integration: http://www.freeipa.org/page/V4/User_Certificates The design went through couple interim discussions between developers outside of this list, so there should not be too many objections. But still, please free to comment or improve the design yourself. For FreeIPA 4.2, I think this resolves in following, quite limited, scope of work: * Adding eq, pres indices for userCertificate * Applying new policy of storing certificate in userCertificate attribute, based on upcoming Certificate Profile feature by Fraser. * Making sure that multiple certificates can be added to userCertificate attribute manually by CLI and UI The "Certificate Identity Mapping" part will probably be moved to 4.3+, unless there is extra pool of development resources. There is still something to be resolved - how should the certificates be revoked in object-del or object-disable actions? Currently, certificate is always stored in userCertificate and it's serial is used for revoke operation in Dogtag. But that will not be true in 4.2+ since some certificates will not be stored in accounts. Do we only want to revoke those that have policy to be stored in the userCertificate attribute? Does not sound right to me. Or do we need a Dogtag API that would allow us to query (or even revoke directly) all certificates generated for a user/service/host and revoke them, regardless whether they are stored in userCertificate attribute or not? Thanks. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From mbasti at redhat.com Mon May 4 09:57:13 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 04 May 2015 11:57:13 +0200 Subject: [Freeipa-devel] [PATCHES 0235-0237] Use global DS write lock during upgrade In-Reply-To: <553F80D3.6070606@redhat.com> References: <553F80D3.6070606@redhat.com> Message-ID: <55474279.7030103@redhat.com> On 28/04/15 14:45, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/4925 > > I had to use ldif parser to edit DSE file instead (patch 236) and due > to cyclic import caused by upgrade instace and dsintance I had to move > realm_to_serverid from dsinstance to installutils. > > Patches attached. > > > Updated patches attached. -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0235.2-move-realm_to_serverid-to-installutils-module.patch Type: text/x-patch Size: 19591 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0236.2-Server-Upgrade-use-LDIF-parser-to-modify-DSE.ldif.patch Type: text/x-patch Size: 8154 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0237.2-Server-Upgrade-enable-DS-global-lock-during-upgrade.patch Type: text/x-patch Size: 5990 bytes Desc: not available URL: From jcholast at redhat.com Mon May 4 11:17:03 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 04 May 2015 13:17:03 +0200 Subject: [Freeipa-devel] [PATCHES 0227-0229] Server upgrade: introduce ipa-server-upgrade command In-Reply-To: <5540DC5A.8000604@redhat.com> References: <552E7527.9020306@redhat.com> <5535EA59.3060408@redhat.com> <55360AD4.1020703@redhat.com> <5538CFA9.9080700@redhat.com> <553E1FA8.8020503@redhat.com> <553E4B8E.6000103@redhat.com> <553E629B.3090809@redhat.com> <55406D5E.8090207@redhat.com> <55407E1B.5080904@redhat.com> <55407FC7.1060502@redhat.com> <5540AF51.7070906@redhat.com> <5540B4F5.2060801@redhat.com> <5540B76A.9020809@redhat.com> <5540B9A0.2010006@redhat.com> <5540BF0E.7060206@redhat.com> <5540DC5A.8000604@redhat.com> Message-ID: <5547552F.1000908@redhat.com> Dne 29.4.2015 v 15:27 Martin Basti napsal(a): > On 29/04/15 13:22, Martin Kosek wrote: >> On 04/29/2015 12:59 PM, Martin Kosek wrote: >>> On 04/29/2015 12:50 PM, Martin Basti wrote: >>>> On 29/04/15 12:39, Martin Kosek wrote: >>>>> On 04/29/2015 12:15 PM, Martin Basti wrote: >>>>>> On 29/04/15 08:52, Jan Cholasta wrote: >>>>>>> Dne 29.4.2015 v 08:45 Martin Kosek napsal(a): >>>>>>>> On 04/29/2015 07:34 AM, Jan Cholasta wrote: >>>>> ... >>>>>>>>> The command line tool class should be named "ServerUpgrade" >>>>>>>>> rather than >>>>>>>>> "IPAServerUpgrade" for consistency with others. >>>>>>>>> >>>>>>>>> The deprecated --debug option should not be used in new commands. >>>>>>>> Why is --debug option deprecated? I thought we wanted to >>>>>>>> deprecate --verbose >>>>>>>> option as --debug is used in most our CLI tools. Well, except >>>>>>>> ipa-ldap-updated >>>>>>>> which for some reasons marks --debug as deprecated. It does not >>>>>>>> matter now, >>>>>>>> given the command is removed/changed. >>>>>>> AdminTool provides --debug as a deprecated alias for --verbose >>>>>>> when a >>>>>>> subclass requests it. It seems the decision to deprecate --debug >>>>>>> was already >>>>>>> made back when AdminTool was introduced, so let's trust that >>>>>>> decision. >>>>>>> >>>>>> Yes that is reason. >>>>> No, it's not. >>>>> >>>>> I will update design as well >>>>> >>>>> Nope. This decision was never made this way, AFAIR. --debug is what >>>>> all the >>>>> main tools (ipa-server-install, ipa-replica-install, >>>>> ipa-client-install) use >>>>> and we never agreed that we want to change it. >>>>> >>>>> In fact, I think I remember some discussion from Devconf.cz time, >>>>> when we >>>>> mentioned that the ipa-ldap-updater has it the deprecated status >>>>> wrong way, >>>>> that we want --debug. CCing Simo since he may have been in the >>>>> conversation. >>>> http://freeipa.org/page/V3/Logging_and_output >>>> >>>> "In commands that currently have it, the `-d, --debug` option will >>>> become a >>>> deprecated alias for --verbose." >>> I see, I must somehow missed that aspect of the miniframework. Well, >>> question >>> is - is it really a good decision and thing we should do? >>> >>> I.e. slowly moving towards --verbose option, deprecating --debug, >>> given we use >>> --debug in most commands and people are using it? This could cause >>> lot of >>> unnecessary churn in stable distributions that would wish to rebase >>> to FreeIPA, >>> like CentOS or RHEL - and for what reason? >>> >>> I will be against removing --debug option from the main commands >>> unless there >>> is a very good reason and justification to do so. >>> >>> Martin >> I talked to Martin in person. If --debug option is not removed and is >> kept in >> the old commands and you really want to go with the --verbose option >> crusade, I >> can live with it. >> >> Martin > Updated patches attached. > > * Removed --debug version > * I also added log message that version check was skipped > Thanks, ACK. Pushed to master: 3debc7b2b54b7926dcd2b26a37b3dc0677c3bc61 -- Jan Cholasta From ftweedal at redhat.com Mon May 4 13:01:02 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 4 May 2015 23:01:02 +1000 Subject: [Freeipa-devel] User Certificates in 4.2 - design and questions In-Reply-To: <554732C7.5000109@redhat.com> References: <554732C7.5000109@redhat.com> Message-ID: <20150504130102.GP16379@dhcp-40-8.bne.redhat.com> On Mon, May 04, 2015 at 10:50:15AM +0200, Martin Kosek wrote: > Hello, > > Please let me promote the design for one of the major FreeIPA 4.2 features, the > (user) certificates and Smart Card integration: > > http://www.freeipa.org/page/V4/User_Certificates > > The design went through couple interim discussions between developers outside > of this list, so there should not be too many objections. But still, please > free to comment or improve the design yourself. > > For FreeIPA 4.2, I think this resolves in following, quite limited, scope of work: > * Adding eq, pres indices for userCertificate > * Applying new policy of storing certificate in userCertificate attribute, > based on upcoming Certificate Profile feature by Fraser. > * Making sure that multiple certificates can be added to userCertificate > attribute manually by CLI and UI > > The "Certificate Identity Mapping" part will probably be moved to 4.3+, unless > there is extra pool of development resources. > > There is still something to be resolved - how should the certificates be > revoked in object-del or object-disable actions? Currently, certificate is > always stored in userCertificate and it's serial is used for revoke operation > in Dogtag. But that will not be true in 4.2+ since some certificates will not > be stored in accounts. > > Do we only want to revoke those that have policy to be stored in the > userCertificate attribute? Does not sound right to me. Or do we need a Dogtag > API that would allow us to query (or even revoke directly) all certificates > generated for a user/service/host and revoke them, regardless whether they are > stored in userCertificate attribute or not? > If the DN or other searchable attributes bear a principal name, existing APIs should be sufficient (if a little awkward). But Dogtag does not know about principals, it only knows what is on the cert (and a few other things, like the profile that was used). Later, when we implement GSSAPI and ACL enforcement in Dogtag (https://fedorahosted.org/freeipa/ticket/5011) we can also store the principal that issued the certificate for a concrete association in Dogtag, which can be used to locate certificates for a principal. Considering known use cases in which one would not want to store the issued cert in IPA, some of these have short lived certs so revocation is not an issue. With that in mind I think it would be OK, for 4.2 at least, to not provide a way in IPA to revoke a cert that was issued via IPA but not stored; it can still be revoked using Dogtag directly, and we could provide pointers to Dogtag documentation. The important thing is to manage the user expectations for 4.2. > Thanks. > > -- > Martin Kosek > Supervisor, Software Engineering - Identity Management Team > Red Hat Inc. From mbabinsk at redhat.com Mon May 4 13:36:01 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 04 May 2015 15:36:01 +0200 Subject: [Freeipa-devel] [PATCHES 0235-0237] Use global DS write lock during upgrade In-Reply-To: <55474279.7030103@redhat.com> References: <553F80D3.6070606@redhat.com> <55474279.7030103@redhat.com> Message-ID: <554775C1.8020504@redhat.com> On 05/04/2015 11:57 AM, Martin Basti wrote: > On 28/04/15 14:45, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/4925 >> >> I had to use ldif parser to edit DSE file instead (patch 236) and due >> to cyclic import caused by upgrade instace and dsintance I had to move >> realm_to_serverid from dsinstance to installutils. >> >> Patches attached. >> >> >> > > Updated patches attached. > > -- > Martin Basti > ACK -- Martin^3 Babinsky From ftweedal at redhat.com Mon May 4 13:36:41 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 4 May 2015 23:36:41 +1000 Subject: [Freeipa-devel] [PATCHES 0001-0005] Profile management commands Message-ID: <20150504133641.GQ16379@dhcp-40-8.bne.redhat.com> 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/ -------------- next part -------------- >From 399e9e3cb41fae66b6e448905f7e8d2a3738e30a Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 20 Apr 2015 23:20:19 -0400 Subject: [PATCH 1/5] Install CA with LDAP profiles backend Install the Dogtag CA to use the LDAPProfileSubsystem instead of the default (file-based) ProfileSubsystem. Part of: https://fedorahosted.org/freeipa/ticket/4560 --- ipaserver/install/cainstance.py | 1 + 1 file changed, 1 insertion(+) diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index 8ccfd1a822fab557dc1b6bf6d0e7de3ef495efbb..7241494749480375b548c7fb8930b3f93d728e79 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -505,6 +505,7 @@ class CAInstance(DogtagInstance): config.set("CA", "pki_restart_configured_instance", "False") config.set("CA", "pki_backup_keys", "True") config.set("CA", "pki_backup_password", self.admin_password) + config.set("CA", "pki_profiles_in_ldap", "True") # Client security database config.set("CA", "pki_client_database_dir", self.agent_db) -- 2.1.0 -------------- next part -------------- >From 75feec051438d1a9c13a289db396ef34ebb8f075 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Tue, 21 Apr 2015 02:24:10 -0400 Subject: [PATCH 2/5] Add schema for certificate profiles The certprofile object class is used to track IPA-managed certificate profiles in Dogtag and store IPA-specific settings. Part of: https://fedorahosted.org/freeipa/ticket/57 --- install/share/60certificate-profiles.ldif | 4 ++++ install/share/Makefile.am | 1 + install/share/bootstrap-template.ldif | 6 ++++++ ipaserver/install/dsinstance.py | 1 + 4 files changed, 12 insertions(+) create mode 100644 install/share/60certificate-profiles.ldif diff --git a/install/share/60certificate-profiles.ldif b/install/share/60certificate-profiles.ldif new file mode 100644 index 0000000000000000000000000000000000000000..aa98ad2a17e560996477411b666888c2280394b7 --- /dev/null +++ b/install/share/60certificate-profiles.ldif @@ -0,0 +1,4 @@ +dn: cn=schema +attributeTypes: (2.16.840.1.113730.3.8.19.1.2 NAME 'ipaCertProfileSummary' DESC 'Certificate Profile summary' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 SINGLE-VALUE X-ORIGIN 'IPA v4.2' ) +attributeTypes: (2.16.840.1.113730.3.8.19.1.3 NAME 'ipaCertProfileStoreIssued' DESC 'Store certificates issued using this profile' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA v4.2' ) +objectClasses: (2.16.840.1.113730.3.8.19.2.1 NAME 'ipaCertProfile' SUP top STRUCTURAL MUST ( cn $ ipaCertProfileSummary $ ipaCertProfileStoreIssued ) X-ORIGIN 'IPA v4.2' ) diff --git a/install/share/Makefile.am b/install/share/Makefile.am index ca6128e2911ab5c0a773dd553f8e67eab944f120..2cae5279079cdd3e0d793667f4d1bf4e44757b9e 100644 --- a/install/share/Makefile.am +++ b/install/share/Makefile.am @@ -16,6 +16,7 @@ app_DATA = \ 60basev3.ldif \ 60ipadns.ldif \ 60ipapk11.ldif \ + 60certificate-profiles.ldif \ 61kerberos-ipav3.ldif \ 65ipacertstore.ldif \ 65ipasudo.ldif \ diff --git a/install/share/bootstrap-template.ldif b/install/share/bootstrap-template.ldif index 06b82aa4ae74e7766d0c09a63aa75fa222e7ab7d..1d74842ed544678dd080e34e1eef88983852f1d2 100644 --- a/install/share/bootstrap-template.ldif +++ b/install/share/bootstrap-template.ldif @@ -429,3 +429,9 @@ cn: ${REALM}_id_range ipaBaseID: $IDSTART ipaIDRangeSize: $IDRANGE_SIZE ipaRangeType: ipa-local + +dn: cn=certprofiles,cn=etc,$SUFFIX +changetype: add +objectClass: nsContainer +objectClass: top +cn: certprofiles diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py index 8a76e773f0a464529331d9e2e459c9cc5ea0522e..b562792f72e6821925911902fd49e0829e461559 100644 --- a/ipaserver/install/dsinstance.py +++ b/ipaserver/install/dsinstance.py @@ -55,6 +55,7 @@ IPA_SCHEMA_FILES = ("60kerberos.ldif", "60basev3.ldif", "60ipapk11.ldif", "60ipadns.ldif", + "60certificate-profiles.ldif", "61kerberos-ipav3.ldif", "65ipacertstore.ldif", "65ipasudo.ldif", -- 2.1.0 -------------- next part -------------- >From cb8701e32c61a9e28995c185fddc4436970cdde3 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Wed, 29 Apr 2015 06:07:58 -0400 Subject: [PATCH 3/5] ipa-pki-proxy: provide access to profiles REST API Part of: https://fedorahosted.org/freeipa/ticket/57 --- install/conf/ipa-pki-proxy.conf | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/install/conf/ipa-pki-proxy.conf b/install/conf/ipa-pki-proxy.conf index 5d21156848f3b5ddf14c42d92a26a30a9f94af36..70de496ddf640465365551c713989c34b0dba179 100644 --- a/install/conf/ipa-pki-proxy.conf +++ b/install/conf/ipa-pki-proxy.conf @@ -11,7 +11,7 @@ ProxyRequests Off # matches for admin port and installer - + NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate NSSVerifyClient none ProxyPassMatch ajp://localhost:$DOGTAG_PORT @@ -26,5 +26,13 @@ ProxyRequests Off ProxyPassReverse ajp://localhost:$DOGTAG_PORT +# matches for REST API + + NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate + NSSVerifyClient require + ProxyPassMatch ajp://localhost:$DOGTAG_PORT + ProxyPassReverse ajp://localhost:$DOGTAG_PORT + + # Only enable this on servers that are not generating a CRL ${CLONE}RewriteRule ^/ipa/crl/MasterCRL.bin https://$FQDN/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL [L,R=301,NC] -- 2.1.0 -------------- next part -------------- >From f1d33fe35dfb8e325a250a3c0439419cf10b7090 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Thu, 30 Apr 2015 23:50:41 -0400 Subject: [PATCH 4/5] cainstance: add ACL to allow CA agent to modify profiles Part of: https://fedorahosted.org/freeipa/ticket/57 --- ipaserver/install/cainstance.py | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index 7241494749480375b548c7fb8930b3f93d728e79..81fd8a47d3cebe0659d5b3158928f578c0a75059 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -471,6 +471,7 @@ class CAInstance(DogtagInstance): self.step("requesting RA certificate from CA", self.__request_ra_certificate) self.step("issuing RA agent certificate", self.__issue_ra_cert) self.step("adding RA agent as a trusted user", self.__configure_ra) + self.step("authorizing RA to modify profiles", self.__configure_profiles_acl) self.step("configure certmonger for renewals", self.configure_certmonger_renewal) self.step("configure certificate renewals", self.configure_renewal) if not self.clone: @@ -942,6 +943,19 @@ class CAInstance(DogtagInstance): conn.unbind() + def __configure_profiles_acl(self): + """Allow the Certificate Manager Agents group to modify profiles.""" + dn = DN(('cn', 'aclResources'), self.basedn) + modlist = [(ldap.MOD_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' + ])] + conn = ipaldap.IPAdmin(self.fqdn, self.ds_port) + conn.do_simple_bind(DN(('cn', 'Directory Manager')), self.dm_password) + conn.modify_s(dn, modlist) + conn.unbind() + def __run_certutil(self, args, database=None, pwd_file=None, stdin=None): if not database: database = self.ra_agent_db -- 2.1.0 -------------- next part -------------- >From 3a301bbf1584def121c981cf0d8ad1b7a23c4aca Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Thu, 30 Apr 2015 04:55:29 -0400 Subject: [PATCH 5/5] Add certprofile plugin Add the 'certprofile' plugin which defines the commands for managing certificate profiles and associated permissions. Also update Dogtag network code in 'ipapython.dogtag' to support headers and arbitrary request bodies, to facilitate use of the Dogtag profiles REST API. Part of: https://fedorahosted.org/freeipa/ticket/57 --- ACI.txt | 8 ++ install/updates/40-delegation.update | 8 ++ ipalib/constants.py | 1 + ipalib/plugins/certprofile.py | 240 +++++++++++++++++++++++++++++++++++ ipapython/dogtag.py | 27 ++-- ipaserver/plugins/dogtag.py | 145 ++++++++++++++++++++- 6 files changed, 417 insertions(+), 12 deletions(-) create mode 100644 ipalib/plugins/certprofile.py diff --git a/ACI.txt b/ACI.txt index 933b57cb93e833981867953b516a67484f13dca3..5547f4bb4e2b3e4b53813757f3d2f9170e805ae5 100644 --- a/ACI.txt +++ b/ACI.txt @@ -22,6 +22,14 @@ dn: cn=automount,dc=ipa,dc=example aci: (targetattr = "automountmapname || description")(targetfilter = "(objectclass=automountmap)")(version 3.0;acl "permission:System: Modify Automount Maps";allow (write) groupdn = "ldap:///cn=System: Modify Automount Maps,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: cn=automount,dc=ipa,dc=example aci: (targetfilter = "(objectclass=automountmap)")(version 3.0;acl "permission:System: Remove Automount Maps";allow (delete) groupdn = "ldap:///cn=System: Remove Automount Maps,cn=permissions,cn=pbac,dc=ipa,dc=example";) +dn: cn=certprofiles,cn=etc,dc=ipa,dc=example +aci: (targetfilter = "(objectclass=ipacertprofile)")(version 3.0;acl "permission:System: Delete Certificate Profile";allow (delete) groupdn = "ldap:///cn=System: Delete Certificate Profile,cn=permissions,cn=pbac,dc=ipa,dc=example";) +dn: cn=certprofiles,cn=etc,dc=ipa,dc=example +aci: (targetfilter = "(objectclass=ipacertprofile)")(version 3.0;acl "permission:System: Import Certificate Profile";allow (add) groupdn = "ldap:///cn=System: Import Certificate Profile,cn=permissions,cn=pbac,dc=ipa,dc=example";) +dn: cn=certprofiles,cn=etc,dc=ipa,dc=example +aci: (targetattr = "cn || ipacertprofilestoreissued || ipacertprofilesummary")(targetfilter = "(objectclass=ipacertprofile)")(version 3.0;acl "permission:System: Modify Certificate Profile";allow (write) groupdn = "ldap:///cn=System: Modify Certificate Profile,cn=permissions,cn=pbac,dc=ipa,dc=example";) +dn: cn=certprofiles,cn=etc,dc=ipa,dc=example +aci: (targetattr = "cn || createtimestamp || entryusn || ipacertprofilestoreissued || ipacertprofilesummary || modifytimestamp || objectclass")(targetfilter = "(objectclass=ipacertprofile)")(version 3.0;acl "permission:System: Read Certificate Profiles";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=ipaconfig,cn=etc,dc=ipa,dc=example aci: (targetattr = "cn || createtimestamp || entryusn || ipacertificatesubjectbase || ipaconfigstring || ipacustomfields || ipadefaultemaildomain || ipadefaultloginshell || ipadefaultprimarygroup || ipagroupobjectclasses || ipagroupsearchfields || ipahomesrootdir || ipakrbauthzdata || ipamaxusernamelength || ipamigrationenabled || ipapwdexpadvnotify || ipasearchrecordslimit || ipasearchtimelimit || ipaselinuxusermapdefault || ipaselinuxusermaporder || ipauserauthtype || ipauserobjectclasses || ipausersearchfields || modifytimestamp || objectclass")(targetfilter = "(objectclass=ipaguiconfig)")(version 3.0;acl "permission:System: Read Global Configuration";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=costemplates,cn=accounts,dc=ipa,dc=example diff --git a/install/updates/40-delegation.update b/install/updates/40-delegation.update index 32af498190a23ddfd202a5cad75409f60a70d78b..fd474bcd12c935e1485959c5763d6773d31c8bd7 100644 --- a/install/updates/40-delegation.update +++ b/install/updates/40-delegation.update @@ -237,3 +237,11 @@ default:ipapermissiontype: SYSTEM dn: cn=config add:aci: '(version 3.0;acl "permission:Add Configuration Sub-Entries";allow (add) groupdn = "ldap:///cn=Add Configuration Sub-Entries,cn=permissions,cn=pbac,$SUFFIX";)' + +# CA Administrators +dn: cn=CA Administrator,cn=privileges,cn=pbac,$SUFFIX +default:objectClass: nestedgroup +default:objectClass: groupofnames +default:objectClass: top +default:cn: CA Administrator +default:description: CA Administrator diff --git a/ipalib/constants.py b/ipalib/constants.py index f1e14702ffdf5a3bd23a62b1fdd2ee3cd95d84f8..02ba78e4b024c32b602c74e123ce305fbf247b8f 100644 --- a/ipalib/constants.py +++ b/ipalib/constants.py @@ -116,6 +116,7 @@ DEFAULT_CONFIG = ( ('container_otp', DN(('cn', 'otp'))), ('container_radiusproxy', DN(('cn', 'radiusproxy'))), ('container_views', DN(('cn', 'views'), ('cn', 'accounts'))), + ('container_certprofile', DN(('cn', 'certprofiles'), ('cn', 'etc'))), # Ports, hosts, and URIs: ('xmlrpc_uri', 'http://localhost:8888/ipa/xml'), diff --git a/ipalib/plugins/certprofile.py b/ipalib/plugins/certprofile.py new file mode 100644 index 0000000000000000000000000000000000000000..9ef8acc07b8c4608573ccfb52f7519586dfec0ee --- /dev/null +++ b/ipalib/plugins/certprofile.py @@ -0,0 +1,240 @@ +# Authors: +# Fraser Tweedale +# +# Copyright (C) 2015 Red Hat +# see file 'COPYING' for use and warranty information +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation, either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see . + +import re + +from ipalib import api, Bool, File, Str +from ipalib import output +from ipalib.plugable import Registry +from ipalib.plugins.virtual import VirtualCommand +from ipalib.plugins.baseldap import \ + LDAPObject, LDAPSearch, LDAPCreate, LDAPDelete, LDAPUpdate, LDAPRetrieve +from ipalib import ngettext +from ipalib.text import _ + +from ipalib import errors +import ipalib.plugins.cert + + +__doc__ = _(""" +Manage Certificate Profiles + +Certificate Profiles are used by Certificate Authority (CA) in the signing of +certificates to determine if a Certificate Signing Request (CSR) is acceptable, +and if so what features and extensions will be present on the certificate. + +The Certificate Profile format is the property-list format understood by the +Dogtag or Red Hat Certificate System CA. + +PROFILE ID SYNTAX: + +A Profile ID is a string without spaces or punctuation starting with a letter +and followed by a sequence of letters, digits or underscore ("_"). + +EXAMPLES: + + Import a profile that will not store issued certificates: + ipa certprofile-import ShortLivedUserCert \\ + --file UserCert.profile --summary "User Certificates" \\ + --store=false + + Delete a certificate profile: + ipa certprofile-del ShortLivedUserCert + + Show information about a profile: + ipa certprofile-show ShortLivedUserCert + + Search for profiles that do not store certificates: + ipa certprofile-find --store=false + +""") + + +register = Registry() + + +profile_id_pattern = re.compile('^[a-zA-Z]\w*$') + + +def validate_profile_id(ugettext, value): + """Ensure profile ID matches form required by CA.""" + if profile_id_pattern.match(value) is None: + return _('invalid Profile ID') + else: + return None + + + at register() +class certprofile(LDAPObject): + """ + Certificate Profile object. + """ + container_dn = api.env.container_certprofile + object_name = _('Certificate Profile') + object_name_plural = _('Certificate Profiles') + object_class = ['ipacertprofile'] + default_attributes = [ + 'cn', 'ipacertprofilesummary', 'ipacertprofilestoreissued' + ] + search_attributes = [ + 'cn', 'ipacertprofilesummary', 'ipacertprofilestoreissued' + ] + rdn_is_primary_key = True + label = _('Certificate Profiles') + label_singular = _('Certificate Profile') + + takes_params = ( + Str('cn', validate_profile_id, + primary_key=True, + cli_name='id', + label=_('Profile ID'), + doc=_('Profile ID for referring to this profile'), + ), + Str('ipacertprofilesummary', + required=True, + cli_name='summary', + label=_('Profile summary'), + doc=_('Brief summary of this profile'), + ), + Bool('ipacertprofilestoreissued', + default=True, + cli_name='store', + label=_('Store issued certificates'), + doc=_('Whether to store certs issued using this profile'), + ), + ) + + permission_filter_objectclasses = ['ipacertprofile'] + managed_permissions = { + 'System: Read Certificate Profiles': { + 'replaces_global_anonymous_aci': True, + 'ipapermbindruletype': 'all', + 'ipapermright': {'read', 'search', 'compare'}, + 'ipapermdefaultattr': { + 'cn', + 'ipacertprofilesummary', + 'ipacertprofilestoreissued', + 'objectclass', + }, + }, + 'System: Import Certificate Profile': { + 'ipapermright': {'add'}, + 'replaces': [ + '(target = "ldap:///cn=*,cn=certprofiles,cn=etc,$SUFFIX")(version 3.0;acl "permission:Import Certificate Profile";allow (add) groupdn = "ldap:///cn=Import Certificate Profile,cn=permissions,cn=pbac,$SUFFIX";)', + ], + 'default_privileges': {'CA Administrator'}, + }, + 'System: Delete Certificate Profile': { + 'ipapermright': {'delete'}, + 'replaces': [ + '(target = "ldap:///cn=*,cn=certprofiles,cn=etc,$SUFFIX")(version 3.0;acl "permission:Delete Certificate Profile";allow (delete) groupdn = "ldap:///cn=Delete Certificate Profile,cn=permissions,cn=pbac,$SUFFIX";)', + ], + 'default_privileges': {'CA Administrator'}, + }, + 'System: Modify Certificate Profile': { + 'ipapermright': {'write'}, + 'ipapermdefaultattr': { + 'cn', + 'ipacertprofilesummary', + 'ipacertprofilestoreissued', + }, + 'replaces': [ + '(targetattr = "cn || ipacertprofilesummary || ipacertprofilestoreissued")(target = "ldap:///cn=*,cn=certprofiles,cn=etc,$SUFFIX")(version 3.0;acl "permission:Modify Certificate Profile";allow (write) groupdn = "ldap:///cn=Modify Certificate Profile,cn=permissions,cn=pbac,$SUFFIX";)', + ], + 'default_privileges': {'CA Administrator'}, + }, + } + + + + at register() +class certprofile_find(LDAPSearch): + __doc__ = _("Search for Certificate Profiles.") + msg_summary = ngettext( + '%(count)d profile matched', '%(count)d profiles matched', 0 + ) + + + at register() +class certprofile_show(LDAPRetrieve): + __doc__ = _("Display the properties of a Certificate Profile.") + + + at register() +class certprofile_import(LDAPCreate): + __doc__ = _("Import a Certificate Profile.") + msg_summary = _('Imported profile "%(value)s"') + takes_options = ( + File('profile', + label=_('Filename'), + cli_name='file', + flags=('virtual_attribute',), + ), + ) + + PROFILE_ID_PATTERN = re.compile('^profileId=(\w+)', re.MULTILINE) + + def pre_callback(self, ldap, dn, entry, entry_attrs, *keys, **options): + ipalib.plugins.cert.ca_enabled_check() + match = self.PROFILE_ID_PATTERN.search(options['profile']) + if match is None: + raise errors.ValidationError(name='profile', + error=_("Profile ID is not present in profile data")) + elif keys[0] != match.group(1): + raise errors.ValidationError(name='profile', + error=_("Profile ID '%(cli_value)s' does not match profile data '%(file_value)s'") + % {'cli_value': keys[0], 'file_value': match.group(1)} + ) + return dn + + + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + """Import the profile into Dogtag and enable it. + + If the operation succeeds, update the LDAP entry to 'enabled'. + If the operation fails, remove the LDAP entry. + """ + try: + with self.api.Backend.profile as profile_api: + profile_api.create_profile(options['profile']) + profile_api.enable_profile(keys[0]) + except: + # something went wrong ; delete entry + ldap.delete_entry(dn) + raise + + return dn + + + at register() +class certprofile_del(LDAPDelete): + __doc__ = _("Delete a Certificate Profile.") + msg_summary = _('Deleted profile "%(value)s"') + + def post_callback(self, ldap, dn, *keys, **options): + with self.api.Backend.profile as profile_api: + profile_api.disable_profile(keys[0]) + profile_api.delete_profile(keys[0]) + return dn + + + at register() +class certprofile_mod(LDAPUpdate): + __doc__ = _("Modify Certificate Profile configuration.") + msg_summary = _('Modified Certificate Profile "%(value)s') diff --git a/ipapython/dogtag.py b/ipapython/dogtag.py index c74b8736a4b15f7bf081206b52b9876a8c4928af..563396710d76cdd6953066b4b023a89da6013cd9 100644 --- a/ipapython/dogtag.py +++ b/ipapython/dogtag.py @@ -233,9 +233,12 @@ def ca_status(ca_host=None, use_proxy=True): return _parse_ca_status(body) -def https_request(host, port, url, secdir, password, nickname, **kw): +def https_request(host, port, url, secdir, password, nickname, + method='POST', headers=None, body=None, **kw): """ + :param method: HTTP request method (defalut: 'POST') :param url: The path (not complete URL!) to post to. + :param body: The request body (encodes kw if None) :param kw: Keyword arguments to encode into POST body. :return: (http_status, http_reason_phrase, http_headers, http_body) as (integer, unicode, dict, str) @@ -254,9 +257,11 @@ def https_request(host, port, url, secdir, password, nickname, **kw): nickname, password, nss.get_default_certdb()) return conn - body = urlencode(kw) + if body is None: + body = urlencode(kw) return _httplib_request( - 'https', host, port, url, connection_factory, body) + 'https', host, port, url, connection_factory, body, + method=method, headers=headers) def http_request(host, port, url, **kw): @@ -288,11 +293,13 @@ def unauthenticated_https_request(host, port, url, **kw): def _httplib_request( - protocol, host, port, path, connection_factory, request_body): + protocol, host, port, path, connection_factory, request_body, + method='POST', headers=None): """ :param request_body: Request body :param connection_factory: Connection class to use. Will be called with the host and port arguments. + :param method: HTTP request method (default: 'POST') Perform a HTTP(s) request. """ @@ -301,13 +308,15 @@ def _httplib_request( uri = '%s://%s%s' % (protocol, ipautil.format_netloc(host, port), path) root_logger.debug('request %r', uri) root_logger.debug('request body %r', request_body) + + headers = headers or {} + if method == 'POST' \ + and 'content-type' not in (str(k).lower() for k in headers.viewkeys()): + headers['content-type'] = 'application/x-www-form-urlencoded' + try: conn = connection_factory(host, port) - conn.request( - 'POST', uri, - body=request_body, - headers={'Content-type': 'application/x-www-form-urlencoded'}, - ) + conn.request(method, uri, body=request_body, headers=headers) res = conn.getresponse() http_status = res.status diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py index 52bdb0d4245594785e718c63242e27cee0e59322..2ba4af490683a305d669d9afca4899d8f3d5ed6c 100644 --- a/ipaserver/plugins/dogtag.py +++ b/ipaserver/plugins/dogtag.py @@ -4,8 +4,9 @@ # Jason Gerard DeRose # Rob Crittenden # John Dennis +# Fraser Tweedale # -# Copyright (C) 2014 Red Hat +# Copyright (C) 2014, 2015 Red Hat # see file 'COPYING' for use and warranty information # # This program is free software; you can redistribute it and/or modify @@ -238,17 +239,20 @@ digits and nothing else follows. ''' import datetime +import json from lxml import etree import tempfile import time import urllib2 +import pki from pki.client import PKIConnection import pki.crypto as cryptoutil from pki.kra import KRAClient from ipalib import Backend from ipapython.dn import DN +import ipapython.cookie import ipapython.dogtag from ipapython import ipautil from ipaserver.install.certs import CertDB @@ -1268,7 +1272,7 @@ if api.env.ra_plugin != 'dogtag': raise SkipPluginModule(reason='dogtag not selected as RA plugin') import os, random from ipaserver.plugins import rabase -from ipalib.errors import CertificateOperationError +import ipalib.errors as errors from ipalib.constants import TYPE_ERROR from ipalib.util import cachedproperty from ipapython import dogtag @@ -1318,7 +1322,7 @@ class ra(rabase.rabase): err_msg = u'%s (%s)' % (err_msg, detail) self.error('%s.%s(): %s', self.fullname, func_name, err_msg) - raise CertificateOperationError(error=err_msg) + raise errors.CertificateOperationError(error=err_msg) @cachedproperty def ca_host(self): @@ -1923,3 +1927,138 @@ class kra(Backend): return KRAClient(connection, crypto) api.register(kra) + + +class profile(Backend): + """ + Profile management backend plugin. + """ + def __init__(self): + if api.env.in_tree: + self.sec_dir = api.env.dot_ipa + os.sep + 'alias' + self.pwd_file = self.sec_dir + os.sep + '.pwd' + else: + self.sec_dir = paths.HTTPD_ALIAS_DIR + self.pwd_file = paths.ALIAS_PWDFILE_TXT + self.noise_file = self.sec_dir + os.sep + '.noise' + self.ipa_key_size = "2048" + self.ipa_certificate_nickname = "ipaCert" + self.ca_certificate_nickname = "caCert" + try: + f = open(self.pwd_file, "r") + self.password = f.readline().strip() + f.close() + except IOError: + self.password = '' + super(profile, self).__init__() + + # session cookie + self.cookie = None + + @cachedproperty + def ca_host(self): + """ + :return: host + as str + + Select our CA host. + """ + ldap2 = self.api.Backend.ldap2 + if host_has_service(api.env.ca_host, ldap2, "CA"): + return api.env.ca_host + if api.env.host != api.env.ca_host: + if host_has_service(api.env.host, ldap2, "CA"): + return api.env.host + host = select_any_master(ldap2) + if host: + return host + else: + return api.env.ca_host + + def __enter__(self): + """Log into the REST API""" + if self.cookie is not None: + return + status, status_text, resp_headers, resp_body = dogtag.https_request( + self.ca_host, self.env.ca_agent_port, '/ca/rest/account/login', + self.sec_dir, self.password, self.ipa_certificate_nickname, + method='GET' + ) + cookies = ipapython.cookie.Cookie.parse(resp_headers.get('set-cookie', '')) + if status != 200 or len(cookies) == 0: + raise errors.RemoteRetrieveError(reason=_('Failed to authenticate to CA REST API')) + self.cookie = str(cookies[0]) + return self + + def __exit__(self, exc_type, exc_value, traceback): + """Log out of the REST API""" + # TODO logout + self.cookie = None + + def _ssldo(self, method, path, headers=None, body=None): + """ + :param url: The URL to post to. + :param kw: Keyword arguments to encode into POST body. + :return: (http_status, http_reason_phrase, http_headers, http_body) + as (integer, unicode, dict, str) + + Perform an HTTPS request + """ + if self.cookie is None: + raise errors.RemoteRetrieveError( + reason=_("REST API is not logged in.")) + + headers = headers or {} + headers['Cookie'] = self.cookie + + # perform main request + status, status_text, resp_headers, resp_body = dogtag.https_request( + self.ca_host, self.env.ca_agent_port, path, + self.sec_dir, self.password, self.ipa_certificate_nickname, + method=method, headers=headers, body=body + ) + if status < 200 or status >= 300: + explanation = self._parse_dogtag_error(resp_body) or '' + if not explanation: print resp_body # NOCOMMIT + raise errors.RemoteRetrieveError( + reason=_('Non-2xx response from CA REST API: %(status)d %(status_text)s. %(explanation)s') + % {'status': status, 'status_text': status_text, 'explanation': explanation} + ) + return (status, status_text, resp_headers, resp_body) + + @staticmethod + def _parse_dogtag_error(body): + try: + return pki.PKIException.from_json(json.loads(body)) + except: + return None + + def create_profile(self, profile_data): + """ + Import the profile into Dogtag + """ + self._ssldo('POST', '/ca/rest/profiles/raw', + headers={'Content-type': 'application/xml'}, + body=profile_data + ) + + def enable_profile(self, profile_id): + """ + Enable the profile in Dogtag + """ + self._ssldo('POST', + '/ca/rest/profiles/{}?action=enable'.format(profile_id)) + + def disable_profile(self, profile_id): + """ + Enable the profile in Dogtag + """ + self._ssldo('POST', + '/ca/rest/profiles/{}?action=disable'.format(profile_id)) + + def delete_profile(self, profile_id): + self._ssldo('DELETE', '/ca/rest/profiles/{}'.format(profile_id), + headers={'Accept': 'application/json'}) + + +api.register(profile) -- 2.1.0 From mkosek at redhat.com Mon May 4 14:41:42 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 04 May 2015 16:41:42 +0200 Subject: [Freeipa-devel] User Certificates in 4.2 - design and questions In-Reply-To: <20150504130102.GP16379@dhcp-40-8.bne.redhat.com> References: <554732C7.5000109@redhat.com> <20150504130102.GP16379@dhcp-40-8.bne.redhat.com> Message-ID: <55478526.8060604@redhat.com> On 05/04/2015 03:01 PM, Fraser Tweedale wrote: > On Mon, May 04, 2015 at 10:50:15AM +0200, Martin Kosek wrote: >> Hello, >> >> Please let me promote the design for one of the major FreeIPA 4.2 features, the >> (user) certificates and Smart Card integration: >> >> http://www.freeipa.org/page/V4/User_Certificates >> >> The design went through couple interim discussions between developers outside >> of this list, so there should not be too many objections. But still, please >> free to comment or improve the design yourself. >> >> For FreeIPA 4.2, I think this resolves in following, quite limited, scope of work: >> * Adding eq, pres indices for userCertificate >> * Applying new policy of storing certificate in userCertificate attribute, >> based on upcoming Certificate Profile feature by Fraser. >> * Making sure that multiple certificates can be added to userCertificate >> attribute manually by CLI and UI >> >> The "Certificate Identity Mapping" part will probably be moved to 4.3+, unless >> there is extra pool of development resources. >> >> There is still something to be resolved - how should the certificates be >> revoked in object-del or object-disable actions? Currently, certificate is >> always stored in userCertificate and it's serial is used for revoke operation >> in Dogtag. But that will not be true in 4.2+ since some certificates will not >> be stored in accounts. >> >> Do we only want to revoke those that have policy to be stored in the >> userCertificate attribute? Does not sound right to me. Or do we need a Dogtag >> API that would allow us to query (or even revoke directly) all certificates >> generated for a user/service/host and revoke them, regardless whether they are >> stored in userCertificate attribute or not? >> > If the DN or other searchable attributes bear a principal name, > existing APIs should be sufficient (if a little awkward). But > Dogtag does not know about principals, it only knows what is on the > cert (and a few other things, like the profile that was used). Kerberos principal SAN is added when the certificate is requested via Certmonger, but we do not add it when requested via cert-request command (yet). So we cannot depend on it. > Later, when we implement GSSAPI and ACL enforcement in Dogtag > (https://fedorahosted.org/freeipa/ticket/5011) we can also store the > principal that issued the certificate for a concrete association in > Dogtag, which can be used to locate certificates for a principal. Right, sounds as something we should do. I commented in the ticket. > Considering known use cases in which one would not want to store the > issued cert in IPA, some of these have short lived certs so > revocation is not an issue. With that in mind I think it would be > OK, for 4.2 at least, to not provide a way in IPA to revoke a cert > that was issued via IPA but not stored; it can still be revoked > using Dogtag directly, and we could provide pointers to Dogtag > documentation. The important thing is to manage the user > expectations for 4.2. Hm, maybe - Simo, if you disagree, please shout. In this case, we would need to make sure this side effect of the userCertificate policy is very well documented. From mbasti at redhat.com Mon May 4 16:35:45 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 04 May 2015 18:35:45 +0200 Subject: [Freeipa-devel] [PATCHES 0001-0005] Profile management commands In-Reply-To: <20150504133641.GQ16379@dhcp-40-8.bne.redhat.com> References: <20150504133641.GQ16379@dhcp-40-8.bne.redhat.com> Message-ID: <55479FE1.1020005@redhat.com> 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: 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 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 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. Other issues: 1) I do not see modifications in API.txt file 2) We use new shorter license header # # Copyright (C) 2015 FreeIPA Contributors see COPYING for license # 3) +from ipalib.plugins.baseldap import \ + LDAPObject, LDAPSearch, LDAPCreate, LDAPDelete, LDAPUpdate, LDAPRetrieve please use 'import ( modules, .. )' instead of '\' 4) + if method == 'POST' \ + and 'content-type' not in (str(k).lower() for k in headers.viewkeys()): again, please use if ( ... ): instead \ 5) +import ipalib.errors as errors in dogtag.py Can you use from ipalib import errors, instead? 6) + def __exit__(self, exc_type, exc_value, traceback): + """Log out of the REST API""" + # TODO logout + self.cookie = None This is forgotten, or will be this fixed later? 7) + if not explanation: print resp_body # NOCOMMIT Martin^2 -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssorce at redhat.com Mon May 4 19:23:22 2015 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 04 May 2015 15:23:22 -0400 Subject: [Freeipa-devel] User Certificates in 4.2 - design and questions In-Reply-To: <55478526.8060604@redhat.com> References: <554732C7.5000109@redhat.com> <20150504130102.GP16379@dhcp-40-8.bne.redhat.com> <55478526.8060604@redhat.com> Message-ID: <1430767402.916.84.camel@willson.usersys.redhat.com> On Mon, 2015-05-04 at 16:41 +0200, Martin Kosek wrote: > On 05/04/2015 03:01 PM, Fraser Tweedale wrote: > > On Mon, May 04, 2015 at 10:50:15AM +0200, Martin Kosek wrote: > >> Hello, > >> > >> Please let me promote the design for one of the major FreeIPA 4.2 features, the > >> (user) certificates and Smart Card integration: > >> > >> http://www.freeipa.org/page/V4/User_Certificates > >> > >> The design went through couple interim discussions between developers outside > >> of this list, so there should not be too many objections. But still, please > >> free to comment or improve the design yourself. > >> > >> For FreeIPA 4.2, I think this resolves in following, quite limited, scope of work: > >> * Adding eq, pres indices for userCertificate > >> * Applying new policy of storing certificate in userCertificate attribute, > >> based on upcoming Certificate Profile feature by Fraser. > >> * Making sure that multiple certificates can be added to userCertificate > >> attribute manually by CLI and UI > >> > >> The "Certificate Identity Mapping" part will probably be moved to 4.3+, unless > >> there is extra pool of development resources. > >> > >> There is still something to be resolved - how should the certificates be > >> revoked in object-del or object-disable actions? Currently, certificate is > >> always stored in userCertificate and it's serial is used for revoke operation > >> in Dogtag. But that will not be true in 4.2+ since some certificates will not > >> be stored in accounts. > >> > >> Do we only want to revoke those that have policy to be stored in the > >> userCertificate attribute? Does not sound right to me. Or do we need a Dogtag > >> API that would allow us to query (or even revoke directly) all certificates > >> generated for a user/service/host and revoke them, regardless whether they are > >> stored in userCertificate attribute or not? > >> > > If the DN or other searchable attributes bear a principal name, > > existing APIs should be sufficient (if a little awkward). But > > Dogtag does not know about principals, it only knows what is on the > > cert (and a few other things, like the profile that was used). > > Kerberos principal SAN is added when the certificate is requested via > Certmonger, but we do not add it when requested via cert-request command (yet). > So we cannot depend on it. > > > Later, when we implement GSSAPI and ACL enforcement in Dogtag > > (https://fedorahosted.org/freeipa/ticket/5011) we can also store the > > principal that issued the certificate for a concrete association in > > Dogtag, which can be used to locate certificates for a principal. > > Right, sounds as something we should do. I commented in the ticket. > > > Considering known use cases in which one would not want to store the > > issued cert in IPA, some of these have short lived certs so > > revocation is not an issue. With that in mind I think it would be > > OK, for 4.2 at least, to not provide a way in IPA to revoke a cert > > that was issued via IPA but not stored; it can still be revoked > > using Dogtag directly, and we could provide pointers to Dogtag > > documentation. The important thing is to manage the user > > expectations for 4.2. > > Hm, maybe - Simo, if you disagree, please shout. In this case, we would need to > make sure this side effect of the userCertificate policy is very well documented. I do not disagree, in most cases when a user (or computer object) is deleted, there is really no need to actually revoke the cert. Keep in mind that revocation list growth is also a concern. So I am fine *not* revoking certs automatically and instead documenting best practices for certs lifecycle management (ie deleting certs when not useful) and how to manually/explicitly revoke certs only when actually compromised (for hosts), or when needed (user leaves organization and may retain a copy of the private key, unlikly when the cert was in a Smart Card which has been returned and wiped). Simo. From ftweedal at redhat.com Tue May 5 06:29:34 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 5 May 2015 16:29:34 +1000 Subject: [Freeipa-devel] [PATCHES 0001-0005] Profile management commands In-Reply-To: <55479FE1.1020005@redhat.com> References: <20150504133641.GQ16379@dhcp-40-8.bne.redhat.com> <55479FE1.1020005@redhat.com> Message-ID: <20150505062934.GU16379@dhcp-40-8.bne.redhat.com> 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. > 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? > 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? > Other issues: > 1) > I do not see modifications in API.txt file > > 2) > We use new shorter license header > # > # Copyright (C) 2015 FreeIPA Contributors see COPYING for license > # > > 3) > +from ipalib.plugins.baseldap import \ > + LDAPObject, LDAPSearch, LDAPCreate, LDAPDelete, LDAPUpdate, > LDAPRetrieve > > please use 'import ( modules, .. )' instead of '\' > > 4) > + if method == 'POST' \ > + and 'content-type' not in (str(k).lower() for k in > headers.viewkeys()): > > again, please use if ( ... ): instead \ > > 5) > +import ipalib.errors as errors > in dogtag.py > > Can you use from ipalib import errors, instead? > > 6) > + def __exit__(self, exc_type, exc_value, traceback): > + """Log out of the REST API""" > + # TODO logout > + self.cookie = None > > This is forgotten, or will be this fixed later? > > 7) > + if not explanation: print resp_body # NOCOMMIT > These are all fixed for the next patchset. Thanks! Fraser > Martin^2 > > -- > Martin Basti > From mkosek at redhat.com Tue May 5 06:38:28 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 05 May 2015 08:38:28 +0200 Subject: [Freeipa-devel] User Certificates in 4.2 - design and questions In-Reply-To: <1430767402.916.84.camel@willson.usersys.redhat.com> References: <554732C7.5000109@redhat.com> <20150504130102.GP16379@dhcp-40-8.bne.redhat.com> <55478526.8060604@redhat.com> <1430767402.916.84.camel@willson.usersys.redhat.com> Message-ID: <55486564.4020400@redhat.com> On 05/04/2015 09:23 PM, Simo Sorce wrote: > On Mon, 2015-05-04 at 16:41 +0200, Martin Kosek wrote: >> On 05/04/2015 03:01 PM, Fraser Tweedale wrote: >>> On Mon, May 04, 2015 at 10:50:15AM +0200, Martin Kosek wrote: >>>> Hello, >>>> >>>> Please let me promote the design for one of the major FreeIPA 4.2 features, the >>>> (user) certificates and Smart Card integration: >>>> >>>> http://www.freeipa.org/page/V4/User_Certificates >>>> >>>> The design went through couple interim discussions between developers outside >>>> of this list, so there should not be too many objections. But still, please >>>> free to comment or improve the design yourself. >>>> >>>> For FreeIPA 4.2, I think this resolves in following, quite limited, scope of work: >>>> * Adding eq, pres indices for userCertificate >>>> * Applying new policy of storing certificate in userCertificate attribute, >>>> based on upcoming Certificate Profile feature by Fraser. >>>> * Making sure that multiple certificates can be added to userCertificate >>>> attribute manually by CLI and UI >>>> >>>> The "Certificate Identity Mapping" part will probably be moved to 4.3+, unless >>>> there is extra pool of development resources. >>>> >>>> There is still something to be resolved - how should the certificates be >>>> revoked in object-del or object-disable actions? Currently, certificate is >>>> always stored in userCertificate and it's serial is used for revoke operation >>>> in Dogtag. But that will not be true in 4.2+ since some certificates will not >>>> be stored in accounts. >>>> >>>> Do we only want to revoke those that have policy to be stored in the >>>> userCertificate attribute? Does not sound right to me. Or do we need a Dogtag >>>> API that would allow us to query (or even revoke directly) all certificates >>>> generated for a user/service/host and revoke them, regardless whether they are >>>> stored in userCertificate attribute or not? >>>> >>> If the DN or other searchable attributes bear a principal name, >>> existing APIs should be sufficient (if a little awkward). But >>> Dogtag does not know about principals, it only knows what is on the >>> cert (and a few other things, like the profile that was used). >> >> Kerberos principal SAN is added when the certificate is requested via >> Certmonger, but we do not add it when requested via cert-request command (yet). >> So we cannot depend on it. >> >>> Later, when we implement GSSAPI and ACL enforcement in Dogtag >>> (https://fedorahosted.org/freeipa/ticket/5011) we can also store the >>> principal that issued the certificate for a concrete association in >>> Dogtag, which can be used to locate certificates for a principal. >> >> Right, sounds as something we should do. I commented in the ticket. >> >>> Considering known use cases in which one would not want to store the >>> issued cert in IPA, some of these have short lived certs so >>> revocation is not an issue. With that in mind I think it would be >>> OK, for 4.2 at least, to not provide a way in IPA to revoke a cert >>> that was issued via IPA but not stored; it can still be revoked >>> using Dogtag directly, and we could provide pointers to Dogtag >>> documentation. The important thing is to manage the user >>> expectations for 4.2. >> >> Hm, maybe - Simo, if you disagree, please shout. In this case, we would need to >> make sure this side effect of the userCertificate policy is very well documented. > > I do not disagree, in most cases when a user (or computer object) is > deleted, there is really no need to actually revoke the cert. > Keep in mind that revocation list growth is also a concern. Right. IIRC some of our users had problems with CRL list size also, making us to create ticket https://fedorahosted.org/freeipa/ticket/4048 > So I am fine *not* revoking certs automatically and instead documenting > best practices for certs lifecycle management (ie deleting certs when > not useful) and how to manually/explicitly revoke certs only when > actually compromised (for hosts), or when needed (user leaves > organization and may retain a copy of the private key, unlikly when the > cert was in a Smart Card which has been returned and wiped). Well, makes sense to me. I added a section to the design: http://www.freeipa.org/page/V4/User_Certificates#Revocation_of_the_Certificates We just need to be cautious here because this would be a change in behavior compared to FreeIPA 4.1 and older. Should this be another global/per-profile policy setting that administrator could set up? From jcholast at redhat.com Tue May 5 06:57:07 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 05 May 2015 08:57:07 +0200 Subject: [Freeipa-devel] [PATCH] 0005 User life cycle: del/mod/find/show stageuser commands In-Reply-To: <553F9BCE.6010000@redhat.com> References: <552F964E.2060304@redhat.com> <553F437D.5080103@redhat.com> <553F44B7.6040100@redhat.com> <553F476E.8080502@redhat.com> <553F9BCE.6010000@redhat.com> Message-ID: <554869C3.2040509@redhat.com> Hi, Dne 28.4.2015 v 16:40 thierry bordaz napsal(a): > On 04/28/2015 10:40 AM, David Kupka wrote: >> On 04/28/2015 10:28 AM, thierry bordaz wrote: >>> On 04/28/2015 10:23 AM, David Kupka wrote: >>>> On 04/16/2015 01:00 PM, thierry bordaz wrote: >>>>> Hello, >>>>> >>>>> Here is the next patch for User life cycle that introduces >>>>> del/mod/find and show stageuser plugin commands. >>>>> >>>>> * 0000-User Life Cycle (create containers and scoping DS plugins): >>>>> *pushed* >>>>> * 0001-User-Life-Cycle-Exclude-subtree-for-ipaUniqueID-gene.patch: >>>>> *pushed* >>>>> * 0002-User-life-cycle-stageuser-add-verb.patch: *pushed* >>>>> * 0007-User-life-cycle-allows-MODRDN-from-ldap2.patch: *pushed* >>>>> * 0003-User-life-cycle-new-stageuser-commands-del-mod-find-*under >>>>> review *(this one)** >>>>> * 0004-User-life-cycle-new-stageuser-commands-activate.patch >>>>> * 0005-User-life-cycle-new-stageuser-commands-activate-prov.patch >>>>> * 0006-User-life-cycle-user-del-supports-permanently-preser.patch >>>>> * 0008-User-life-cycle-user-find-support-finding-delete-use.patch >>>>> * 0009-User-life-cycle-support-of-user-undel.patch >>>>> * 0010-User-life-cycle-DNA-DS-plugin-should-exclude-provisi.patch >>>>> * 0011-User-life-cycle-lockout-provisioning-stage-and-delet.patch >>>>> * 0012-User-life-cycle-Create-stage-Admin-provisioning-acco.patch >>>>> * 0013-User-life-cycle-Stage-Admin-permission-priviledge.patch >>>>> >>>>> Thanks >>>>> thierry >>>>> >>>>> >>>>> >>>>> >>>> Hi Thierry, >>>> thanks for the patch, the code looks good to me but there is probably >>>> a bug in ACIs. >>>> After creating a stage user and setting password for him I can kinit >>>> as the stage user. I'm unable to login to the IPA client and id >>>> command for this stage user responds "no such user" but I can kinit >>>> and invoke ipa commands. >>>> >>>> Steps: >>>> 0. build freeipa with your patch >>>> 1. # ipa-server-install >>>> 2. $ kinit admin >>>> 3. $ ipa stageuser-add suser0 --first Stage --last User --password >>>> 4. $ kdestroy >>>> 5. $ kinit suser0 >>>> 6. $ ipa user-find >>>> >>>> Actual: >>>> Prints out list of ipa users. >>>> >>>> Expected: >>>> kinit fails with "suser0 at ... not found in Kerberos database" >>>> >>> Hi David, >>> >>> Thank you so much for having looked at this patch :-) >>> You are right. The Staging users (as well as the Delete users) are not >>> lockout in that patch. >>> The patch >>> 0011-User-life-cycle-lockout-provisioning-stage-and-delet.patch will >>> take care of this. >>> >>> Do you prefer that I merged the two patches right now ? >>> >>> thanks >>> thierry >>> >> >> Hi Thierry, >> no, it is not necessary to merge the patches it's ok to have it >> separated. I'm not sure if the patch should be pushed now or rather >> wait and push it together with the others. >> I'm looking forward to next ULC patches from you. >> > > > Hi David, > > Here are all the available patches. > I also attach a test script that is a kind of regression tests that I am > using. > > Thanks again > thierry > > Some issues I have found during a quick read of the patches: Patch 0005: 1) This does nothing and can be safely removed: + def pre_callback(self, ldap, dn, *keys, **options): + assert isinstance(dn, DN) + return dn 2) stageuser_{mod,find,show} have a lot of code that seems to be copy-pasted from user_{mod,find,show}. I would prefer if the code was shared instead of copy-pasted, preferably in baseuser_{mod,find,show}. Patch 0006: 1) These do nothing and can be safely removed: + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): + assert isinstance(dn, DN) + return dn + + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + assert isinstance(dn, DN) + return dn 2) You should use output.standard_entry for has_output, as you are only returning one entry. Or you could add support for activating multiple users at once. 3) IMO the "time to build the new entry" and "add the active entry" parts should be done by calling user-add, so that the (active) user creation routine is the same. 4) Please use a single line to separate method definitions in classes. Patch 008: 1) I guess you forgot to remove these: + self.log.error("====> user-add pre_callback 1 %s " % dn) + self.log.error("====> user-add pre_callback %s " % dn) 2) + takes_options = LDAPDelete.takes_options + ( This should be "baseuser_del.takes_options + ...". Honza -- Jan Cholasta From mbasti at redhat.com Tue May 5 08:38:05 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 05 May 2015 10:38:05 +0200 Subject: [Freeipa-devel] [PATCHES 0001-0005] Profile management commands In-Reply-To: <20150505062934.GU16379@dhcp-40-8.bne.redhat.com> References: <20150504133641.GQ16379@dhcp-40-8.bne.redhat.com> <55479FE1.1020005@redhat.com> <20150505062934.GU16379@dhcp-40-8.bne.redhat.com> Message-ID: <5548816D.6050304@redhat.com> 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 >> 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 >> Other issues: >> 1) >> I do not see modifications in API.txt file >> >> 2) >> We use new shorter license header >> # >> # Copyright (C) 2015 FreeIPA Contributors see COPYING for license >> # >> >> 3) >> +from ipalib.plugins.baseldap import \ >> + LDAPObject, LDAPSearch, LDAPCreate, LDAPDelete, LDAPUpdate, >> LDAPRetrieve >> >> please use 'import ( modules, .. )' instead of '\' >> >> 4) >> + if method == 'POST' \ >> + and 'content-type' not in (str(k).lower() for k in >> headers.viewkeys()): >> >> again, please use if ( ... ): instead \ >> >> 5) >> +import ipalib.errors as errors >> in dogtag.py >> >> Can you use from ipalib import errors, instead? >> >> 6) >> + def __exit__(self, exc_type, exc_value, traceback): >> + """Log out of the REST API""" >> + # TODO logout >> + self.cookie = None >> >> This is forgotten, or will be this fixed later? >> >> 7) >> + if not explanation: print resp_body # NOCOMMIT >> > These are all fixed for the next patchset. > > Thanks! > Fraser > >> Martin^2 >> >> -- >> Martin Basti >> -- Martin Basti From pvoborni at redhat.com Tue May 5 08:59:51 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 05 May 2015 10:59:51 +0200 Subject: [Freeipa-devel] [PATCH] 814-818 migrate-ds: optimize adding users to default group In-Reply-To: <554233E4.5040608@redhat.com> References: <5527AC09.7060707@redhat.com> <554233E4.5040608@redhat.com> Message-ID: <55488687.9070407@redhat.com> On 04/30/2015 03:53 PM, Martin Basti wrote: > On 10/04/15 12:55, Petr Vobornik wrote: >> The essential patch is 814. >> >> 815 a proposal for new option. >> >> 816 and 818 are cleanup patches. >> >> 817 little optimization. >> >> == [PATCH] 814 migrate-ds: optimize adding users to default group == >> Migrate-ds searches for user without a group and adds them to default >> group. There is no point in checking if the user's selected by >> previous query are not member of default group because they are not >> member of any group. >> >> The operation is also speeded up by not fetching the default group. >> Users are added right away. >> >> https://fedorahosted.org/freeipa/ticket/4950 >> > NACK > > Users haven't been added into ipa default group after migration. Fixed in patch 815. > > Just nitpick > > 1) too many parentheses > api.log.error(('Adding new members to default group failed: > %s \n' > 'members: %s') % (e, (','.join(member_dns)))) > You can use this instead: > api.log.error('Adding new members to default group failed: > %s \n' > 'members: %s', e, ','.join(member_dns)) Fixed. > > == [PATCH] 815 migrate-ds: skip default group options == >> New option --use-default-group=False could be used to disable adding of >> migrated users into default group. >> >> By default, the default group is no longer POSIX therefore it doesn't >> fulfill the original idea of providing GID and therefore it could be >> skipped during migration. > LGTM the option got so the default would be applied. + autofill=True, >> >> == [PATCH] 816 migrate-ds: remove unused def_group_gid context >> property == >> it's no longer used anywhere >> > 1) > You can remove the unused variable 'g_attrs' removed >> == [PATCH] 817 migrate-ds: optimize gid checks by utilizing dictionary >> nature of set == >> > LGTM >> == [PATCH] 818 migrate-ds: log migrated group members only on debug level == >> It pollutes error_log. >> > 1) > you do not need % formatting in logger > api.log.debug('migrating %s group %s' , member_attr, m) fixed and also changed "migrating %s user %s'" line to debug, which was the actual reason for this patch. >> >> > > Martin^2 > -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0818-1-migrate-ds-log-migrated-group-members-only-on-debug-.patch Type: text/x-patch Size: 1397 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0817-1-migrate-ds-optimize-gid-checks-by-utilizing-dictiona.patch Type: text/x-patch Size: 1877 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0816-1-migrate-ds-remove-unused-def_group_gid-context-prope.patch Type: text/x-patch Size: 1338 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0815-1-migrate-ds-skip-default-group-options.patch Type: text/x-patch Size: 5146 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0814-1-migrate-ds-optimize-adding-users-to-default-group.patch Type: text/x-patch Size: 2988 bytes Desc: not available URL: From pvoborni at redhat.com Tue May 5 09:45:45 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 05 May 2015 11:45:45 +0200 Subject: [Freeipa-devel] [PATCH 0046] Remove unneeded --ip-address option in ipa-adtrust-install In-Reply-To: <553FBBC4.8050904@redhat.com> References: <553F8891.10809@redhat.com> <553FBBC4.8050904@redhat.com> Message-ID: <55489149.5020300@redhat.com> On 04/28/2015 06:56 PM, Martin Basti wrote: > On 28/04/15 15:36, Gabe Alford wrote: >> On Tue, Apr 28, 2015 at 7:18 AM, Martin Basti > > wrote: >> >> On 27/04/15 15:02, Gabe Alford wrote: >>> Hello, >>> >>> Fix for https://fedorahosted.org/freeipa/ticket/4575 >>> >> > > Thank you, ACK! Pushed to master: 26c1851e98f31f11cf52b36bcb7e399ccbb2af17 > > This check is not needed anymore, it will not work with dualstack, and > adtrustisntance is installed on IPA server which must have resolvable IP > address. > -- Petr Vobornik From pvoborni at redhat.com Tue May 5 09:48:32 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 05 May 2015 11:48:32 +0200 Subject: [Freeipa-devel] [PATCH 0230] Server upgrade: fix comment in ldapupdater In-Reply-To: <5540DA35.5090300@redhat.com> References: <552FD1C8.8030403@redhat.com> <553E66E7.6010107@redhat.com> <553F81A5.90800@redhat.com> <5540DA35.5090300@redhat.com> Message-ID: <554891F0.5020801@redhat.com> On 04/29/2015 03:18 PM, David Kupka wrote: > On 04/28/2015 02:48 PM, Martin Basti wrote: >> On 27/04/15 18:42, David Kupka wrote: >>> On 04/16/2015 05:14 PM, Martin Basti wrote: >>>> https://fedorahosted.org/freeipa/ticket/4904 >>>> >>>> Patch attached >>>> >>>> >>>> >>> >>> I guess the rest of the comment is also outdated. Can you update it, >>> too? >>> >> Updated patch attached. >> > ACK. > Pushed to master: 81df7b501e9adca119f671a6466a52a9e38503f2 -- Petr Vobornik From pvoborni at redhat.com Tue May 5 09:51:21 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 05 May 2015 11:51:21 +0200 Subject: [Freeipa-devel] [PATCH 0083] Fix a signedness bug in OTP code In-Reply-To: <554241AE.4050207@redhat.com> References: <1430145037.2682.15.camel@redhat.com> <554241AE.4050207@redhat.com> Message-ID: <55489299.9050107@redhat.com> On 04/30/2015 04:52 PM, Martin Babinsky wrote: > On 04/27/2015 04:30 PM, Nathaniel McCallum wrote: >> This bug caused negative token windows to wrap-around, causing issues >> with TOTP authentication and (especially) synchronization. >> >> https://fedorahosted.org/freeipa/ticket/4990 >> > ACK > Pushed to: master: 978298882b06dcf8a86a8d6ec60d7f1266aac697 ipa-4-1: 352360a879dde3bc68cf0753bc9ba7623f5d0759 -- Petr Vobornik From pvoborni at redhat.com Tue May 5 09:57:20 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 05 May 2015 11:57:20 +0200 Subject: [Freeipa-devel] [PATCHES 0235-0237] Use global DS write lock during upgrade In-Reply-To: <554775C1.8020504@redhat.com> References: <553F80D3.6070606@redhat.com> <55474279.7030103@redhat.com> <554775C1.8020504@redhat.com> Message-ID: <55489400.6020801@redhat.com> On 05/04/2015 03:36 PM, Martin Babinsky wrote: > On 05/04/2015 11:57 AM, Martin Basti wrote: >> On 28/04/15 14:45, Martin Basti wrote: >>> https://fedorahosted.org/freeipa/ticket/4925 >>> >>> I had to use ldif parser to edit DSE file instead (patch 236) and due >>> to cyclic import caused by upgrade instace and dsintance I had to move >>> realm_to_serverid from dsinstance to installutils. >>> >>> Patches attached. >>> >>> >>> >> >> Updated patches attached. >> >> -- >> Martin Basti >> > ACK > pushed to master: * 522cbb23f129033f836e40282ca41e76d315cbe3 move realm_to_serverid to installutils module * 882ce85ad566a1f426398ce346829b1a4dcb5422 Server Upgrade: use LDIF parser to modify DSE.ldif * 5db962d167c77388d6b80fd22d69a1ca475f03cc Server Upgrade: enable DS global lock during upgrade -- Petr Vobornik From pvoborni at redhat.com Tue May 5 11:15:31 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 05 May 2015 13:15:31 +0200 Subject: [Freeipa-devel] [PATCH 0047] Unsaved changes dialog inconsistent In-Reply-To: References: <553E593B.7040505@redhat.com> <252255323.10008954.1430315967619.JavaMail.zimbra@redhat.com> Message-ID: <5548A653.2030903@redhat.com> On 04/30/2015 07:43 PM, Gabe Alford wrote: > Thanks Kyle and Petr. > > Update patch attached. Renaming the buttons also requires to update webui integration tests in ipatests/test_webui, quick search: ipatests/test_webui/test_realmdomains.py:42,48 ipatests/test_webui/ui_driver.py:1221,1246,1464,1483 > > On Wed, Apr 29, 2015 at 7:59 AM, Kyle Baker wrote: > >> >> ----- Original Message ----- >>> On 04/27/2015 03:03 PM, Gabe Alford wrote: >>>> Hello, >>>> >>>> Fix for https://fedorahosted.org/freeipa/ticket/4926 >>>> >>>> Thanks, >>>> >>>> Gabe >>>> >>> >>> PatternFly has new recommendations for terminology and wording [1]. I'm >>> not entirely sure if the usage of 'save' here is good. PF defines 'edit' >>> as the recommended term. The page doesn't say if 'save' is not >>> recommended, though. Save seems to me as a confirmation of editing. >> >> Yes I think save would be best here based on the message given. >> >> Thanks for checking out the Terminology screen! >> >>> >>> Kyle, could you advise what is the best term for reflecting user changes >>> and for confirmation of this action? >>> >>> Technical notes: >>> 1. it would be better to add a new string and then use it in the button >>> instead of having 'Save' text for '@i18n:buttons.update' definition. >>> >>> 2. String changes in internal.py should be also reflected in >>> install/ui/test/data/ipa_init.json (for static web ui demo). >>> >>> 3. optional: in addition to text change, buttons and related actions >>> could also be renamed (same reasons as in 1). It's more proper but much >>> more complicated. >>> >>> >>> [1] >> https://www.patternfly.org/styles/terminology-and-wording/#action-labels >>> -- >>> Petr Vobornik >>> >> > -- Petr Vobornik From tbabej at redhat.com Tue May 5 12:02:03 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 05 May 2015 14:02:03 +0200 Subject: [Freeipa-devel] [PATCHES 306-316] Automated migration tool from Winsync In-Reply-To: <5540B23A.9060404@redhat.com> References: <54FD8369.10803@redhat.com> <54FF0F46.3010109@redhat.com> <55005D3C.5090304@redhat.com> <5540B23A.9060404@redhat.com> Message-ID: <5548B13B.60607@redhat.com> On 04/29/2015 12:28 PM, Tomas Babej wrote: > > > On 03/11/2015 04:20 PM, Jan Cholasta wrote: >> Hi, >> >> Dne 10.3.2015 v 16:35 Tomas Babej napsal(a): >>> >>> On 03/09/2015 12:26 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> this couple of patches provides a initial implementation of the >>>> winsync migration tool: >>>> >>>> https://fedorahosted.org/freeipa/ticket/4524 >>>> >>>> Some parts could use some polishing, but this is a sound foundation. >>>> >>>> Tomas >>>> >>>> >>>> >>> >>> Attaching one more patch to the bundle. This one should make the >>> winsync >>> tool readily available after install. >>> >>> Tomas >>> >>> >> >> Nitpicks: >> >> The winsync_migrate module should be in ipaserver.install. Also I >> don't see why it has to be a package when there is just one short >> file in it. >> >> By convention, the AdminTool subclass should be named WinsyncMigrate, >> or the tool should be named ipa-migrate-winsync. >> >> Honza >> > > Updated patches attached. > > Tomas Rebased patches with cleaned membership bits. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0306-3-2-winsync-migrate-Add-initial-plumbing.patch Type: text/x-patch Size: 5629 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0307-3-2-winsync-migrate-Add-a-way-to-find-all-winsync-users.patch Type: text/x-patch Size: 2206 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0308-3-2-migrate-winsync-Create-user-ID-overrides-in-place-of.patch Type: text/x-patch Size: 2450 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0309-3-2-migrate-winsync-Add-option-validation-and-handling.patch Type: text/x-patch Size: 2524 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0310-3-2-winsync-migrate-Move-the-api-initalization-and-LDAP-.patch Type: text/x-patch Size: 1974 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0311-3-2-dcerpc-Change-logging-level-for-debug-information.patch Type: text/x-patch Size: 1345 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0312-3-2-dcerpc-Add-debugging-message-to-failing-kinit-as-htt.patch Type: text/x-patch Size: 912 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0313-3-2-winsync-migrate-Require-root-privileges.patch Type: text/x-patch Size: 1010 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0314-3-2-idviews-Do-not-abort-the-find-show-commands-on-conve.patch Type: text/x-patch Size: 1785 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0315-3-2-winsync-migrate-Require-explicit-specification-of-th.patch Type: text/x-patch Size: 3132 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0316-3-2-winsync-migrate-Delete-winsync-agreement-prior-to-mi.patch Type: text/x-patch Size: 2853 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0317-3-2-winsync-migrate-Rename-to-tool-to-achive-consistency.patch Type: text/x-patch Size: 2696 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0318-3-2-winsync-migrate-Move-the-tool-under-ipaserver.instal.patch Type: text/x-patch Size: 1294 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0319-3-2-winsync-migrate-Include-the-tool-parts-in-Makefile-a.patch Type: text/x-patch Size: 1223 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0320-3-2-idviews-Fallback-to-AD-DC-LDAP-only-if-specifically-.patch Type: text/x-patch Size: 15670 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0321-3-2-man-Add-manpage-for-ipa-winsync-migrate.patch Type: text/x-patch Size: 2847 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0322-3-2-winsync_migrate-Migrate-memberships-of-the-winsynced.patch Type: text/x-patch Size: 2984 bytes Desc: not available URL: From redhatrises at gmail.com Tue May 5 12:36:48 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Tue, 5 May 2015 06:36:48 -0600 Subject: [Freeipa-devel] [PATCH 0047] Unsaved changes dialog inconsistent In-Reply-To: <5548A653.2030903@redhat.com> References: <553E593B.7040505@redhat.com> <252255323.10008954.1430315967619.JavaMail.zimbra@redhat.com> <5548A653.2030903@redhat.com> Message-ID: Thanks Petr. I thought I had grepped all that out. Guess I didn't do it from the top of the tree. Updated patch attached. On Tue, May 5, 2015 at 5:15 AM, Petr Vobornik wrote: > On 04/30/2015 07:43 PM, Gabe Alford wrote: > >> Thanks Kyle and Petr. >> >> Update patch attached. >> > > Renaming the buttons also requires to update webui integration tests in > ipatests/test_webui, quick search: > ipatests/test_webui/test_realmdomains.py:42,48 > ipatests/test_webui/ui_driver.py:1221,1246,1464,1483 > > > > >> On Wed, Apr 29, 2015 at 7:59 AM, Kyle Baker wrote: >> >> >>> ----- Original Message ----- >>> >>>> On 04/27/2015 03:03 PM, Gabe Alford wrote: >>>> >>>>> Hello, >>>>> >>>>> Fix for https://fedorahosted.org/freeipa/ticket/4926 >>>>> >>>>> Thanks, >>>>> >>>>> Gabe >>>>> >>>>> >>>> PatternFly has new recommendations for terminology and wording [1]. I'm >>>> not entirely sure if the usage of 'save' here is good. PF defines 'edit' >>>> as the recommended term. The page doesn't say if 'save' is not >>>> recommended, though. Save seems to me as a confirmation of editing. >>>> >>> >>> Yes I think save would be best here based on the message given. >>> >>> Thanks for checking out the Terminology screen! >>> >>> >>>> Kyle, could you advise what is the best term for reflecting user changes >>>> and for confirmation of this action? >>>> >>>> Technical notes: >>>> 1. it would be better to add a new string and then use it in the button >>>> instead of having 'Save' text for '@i18n:buttons.update' definition. >>>> >>>> 2. String changes in internal.py should be also reflected in >>>> install/ui/test/data/ipa_init.json (for static web ui demo). >>>> >>>> 3. optional: in addition to text change, buttons and related actions >>>> could also be renamed (same reasons as in 1). It's more proper but much >>>> more complicated. >>>> >>>> >>>> [1] >>>> >>> https://www.patternfly.org/styles/terminology-and-wording/#action-labels >>> >>>> -- >>>> Petr Vobornik >>>> >>>> >>> >> > > -- > Petr Vobornik > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0047-3-Unsaved-changes-dialog-internally-inconsistent.patch Type: text/x-patch Size: 9461 bytes Desc: not available URL: From pspacek at redhat.com Tue May 5 12:44:31 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 05 May 2015 14:44:31 +0200 Subject: [Freeipa-devel] Fwd: [openssl-users] removing Kerberos support from OpenSSL In-Reply-To: <55487D88.7010909@openssl.org> References: <55487D88.7010909@openssl.org> Message-ID: <5548BB2F.8060006@redhat.com> Hello! Is this somehow interesting for us? Petr^2 Spacek -------- Forwarded Message -------- Subject: [openssl-users] Kerberos Date: Tue, 05 May 2015 09:21:28 +0100 From: Matt Caswell Reply-To: openssl-users at openssl.org To: openssl-users at openssl.org, openssl-dev at openssl.org I am considering removing Kerberos support from OpenSSL 1.1.0. There are a number of problems with the functionality as it stands, and it seems to me to be a very rarely used feature. I'm interested in hearing any opinions on this (either for or against). Thanks in advance for your input, Matt _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From ftweedal at redhat.com Tue May 5 12:52:55 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 5 May 2015 22:52:55 +1000 Subject: [Freeipa-devel] User Certificates in 4.2 - design and questions In-Reply-To: <55486564.4020400@redhat.com> References: <554732C7.5000109@redhat.com> <20150504130102.GP16379@dhcp-40-8.bne.redhat.com> <55478526.8060604@redhat.com> <1430767402.916.84.camel@willson.usersys.redhat.com> <55486564.4020400@redhat.com> Message-ID: <20150505125255.GV16379@dhcp-40-8.bne.redhat.com> On Tue, May 05, 2015 at 08:38:28AM +0200, Martin Kosek wrote: > On 05/04/2015 09:23 PM, Simo Sorce wrote: > > On Mon, 2015-05-04 at 16:41 +0200, Martin Kosek wrote: > >> On 05/04/2015 03:01 PM, Fraser Tweedale wrote: > >>> On Mon, May 04, 2015 at 10:50:15AM +0200, Martin Kosek wrote: > >>>> Hello, > >>>> > >>>> Please let me promote the design for one of the major FreeIPA 4.2 features, the > >>>> (user) certificates and Smart Card integration: > >>>> > >>>> http://www.freeipa.org/page/V4/User_Certificates > >>>> > >>>> The design went through couple interim discussions between developers outside > >>>> of this list, so there should not be too many objections. But still, please > >>>> free to comment or improve the design yourself. > >>>> > >>>> For FreeIPA 4.2, I think this resolves in following, quite limited, scope of work: > >>>> * Adding eq, pres indices for userCertificate > >>>> * Applying new policy of storing certificate in userCertificate attribute, > >>>> based on upcoming Certificate Profile feature by Fraser. > >>>> * Making sure that multiple certificates can be added to userCertificate > >>>> attribute manually by CLI and UI > >>>> > >>>> The "Certificate Identity Mapping" part will probably be moved to 4.3+, unless > >>>> there is extra pool of development resources. > >>>> > >>>> There is still something to be resolved - how should the certificates be > >>>> revoked in object-del or object-disable actions? Currently, certificate is > >>>> always stored in userCertificate and it's serial is used for revoke operation > >>>> in Dogtag. But that will not be true in 4.2+ since some certificates will not > >>>> be stored in accounts. > >>>> > >>>> Do we only want to revoke those that have policy to be stored in the > >>>> userCertificate attribute? Does not sound right to me. Or do we need a Dogtag > >>>> API that would allow us to query (or even revoke directly) all certificates > >>>> generated for a user/service/host and revoke them, regardless whether they are > >>>> stored in userCertificate attribute or not? > >>>> > >>> If the DN or other searchable attributes bear a principal name, > >>> existing APIs should be sufficient (if a little awkward). But > >>> Dogtag does not know about principals, it only knows what is on the > >>> cert (and a few other things, like the profile that was used). > >> > >> Kerberos principal SAN is added when the certificate is requested via > >> Certmonger, but we do not add it when requested via cert-request command (yet). > >> So we cannot depend on it. > >> > >>> Later, when we implement GSSAPI and ACL enforcement in Dogtag > >>> (https://fedorahosted.org/freeipa/ticket/5011) we can also store the > >>> principal that issued the certificate for a concrete association in > >>> Dogtag, which can be used to locate certificates for a principal. > >> > >> Right, sounds as something we should do. I commented in the ticket. > >> > >>> Considering known use cases in which one would not want to store the > >>> issued cert in IPA, some of these have short lived certs so > >>> revocation is not an issue. With that in mind I think it would be > >>> OK, for 4.2 at least, to not provide a way in IPA to revoke a cert > >>> that was issued via IPA but not stored; it can still be revoked > >>> using Dogtag directly, and we could provide pointers to Dogtag > >>> documentation. The important thing is to manage the user > >>> expectations for 4.2. > >> > >> Hm, maybe - Simo, if you disagree, please shout. In this case, we would need to > >> make sure this side effect of the userCertificate policy is very well documented. > > > > I do not disagree, in most cases when a user (or computer object) is > > deleted, there is really no need to actually revoke the cert. > > Keep in mind that revocation list growth is also a concern. > > Right. IIRC some of our users had problems with CRL list size also, making us > to create ticket > > https://fedorahosted.org/freeipa/ticket/4048 > > > So I am fine *not* revoking certs automatically and instead documenting > > best practices for certs lifecycle management (ie deleting certs when > > not useful) and how to manually/explicitly revoke certs only when > > actually compromised (for hosts), or when needed (user leaves > > organization and may retain a copy of the private key, unlikly when the > > cert was in a Smart Card which has been returned and wiped). > > Well, makes sense to me. I added a section to the design: > http://www.freeipa.org/page/V4/User_Certificates#Revocation_of_the_Certificates > > We just need to be cautious here because this would be a change in behavior > compared to FreeIPA 4.1 and older. Should this be another global/per-profile > policy setting that administrator could set up? Since the design no longer includes storing certificate metadata (this includes the profile used) it cannot be a per-profile setting. It could be a global config and/or an option to cert-del. Also, we are already changing some of the behaviour about revocation - cert-request will no longer revoke previous certificate(s). If other changes are needed, now is a good time. From mbasti at redhat.com Tue May 5 13:00:01 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 05 May 2015 15:00:01 +0200 Subject: [Freeipa-devel] [PATCHES 0233-0234] DNSSEC: forwarders validation In-Reply-To: <55423032.9080505@redhat.com> References: <553A3D88.6080200@redhat.com> <55423032.9080505@redhat.com> Message-ID: <5548BED1.1060806@redhat.com> On 30/04/15 15:37, David Kupka wrote: > On 04/24/2015 02:56 PM, Martin Basti wrote: >> Patches attached. >> >> >> >> > Hi, > thanks for patches. > > 1. You changed message in DNSServerNotRespondingWarning class but not > the test in ipatest/test_xmlrpc/test_dns_plugin.py > > nitpick. Please spell 'edns' correctly. I've seen several instances of > 'ends'. > Thank you, updated patches attached: * new error messages * logging to debug log server output if exception was raised * fixed test * fixed spelling -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0233.2-DNSSEC-Improve-global-forwarders-validation.patch Type: text/x-patch Size: 15982 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0234.2-DNSSEC-validate-forward-zone-forwarders.patch Type: text/x-patch Size: 10937 bytes Desc: not available URL: From pspacek at redhat.com Tue May 5 15:24:27 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 05 May 2015 17:24:27 +0200 Subject: [Freeipa-devel] [PATCH 0322-0337] Fix mysterious failures in PTR record synchronization Message-ID: <5548E0AB.8090600@redhat.com> Hello, Attached patch set is the best fix for https://fedorahosted.org/bind-dyndb-ldap/ticket/155 I was able to write. This patch set should fix vast majority of race conditions. Unfortunately it cannot be 100 % reliable without support for LDAP transactions. For convenience you can download the whole tree from https://github.com/pspacek/bind-dyndb-ldap/commits/t155.syncptr HEAD = da2552632f6ce67f1bb9d9b3cdd3e0a8e06ce9ea Enjoy. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0322-SyncPTR-Read-PTR-record-values-from-RBTDB-instead-of.patch Type: text/x-patch Size: 18057 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0323-Split-SyncPTR-code-into-separate-module.patch Type: text/x-patch Size: 33163 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0324-Move-journal-maintenance-functions-to-zone.c.patch Type: text/x-patch Size: 5411 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0325-Move-SOA-serial-update-functions-to-zone.c.patch Type: text/x-patch Size: 7569 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0326-Move-helper-functions-for-diff-manipulation-to-zone..patch Type: text/x-patch Size: 4762 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0327-Move-DEFAULT_TTL-to-header-ldap_entry.h.patch Type: text/x-patch Size: 1229 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0328-Return-ISC_R_SUCCESS-from-rdataset_to_diff-to-be-con.patch Type: text/x-patch Size: 1484 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0329-SyncPTR-Use-database-API-for-modifications-to-preven.patch Type: text/x-patch Size: 14934 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0330-Zone-SOA-serial-functions-now-accept-NULL-output-par.patch Type: text/x-patch Size: 2611 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0331-SyncPTR-Bump-SOA-serial-immediatelly-during-PTR-sync.patch Type: text/x-patch Size: 905 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0332-SyncPTR-Record-PTR-synchronization-into-zone-journal.patch Type: text/x-patch Size: 855 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0333-SyncPTR-Do-update-asynchronously-to-prevent-race-con.patch Type: text/x-patch Size: 12299 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0334-Remove-unused-structure-ldap_qresult.patch Type: text/x-patch Size: 1071 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0335-SyncPTR-Improve-logging.patch Type: text/x-patch Size: 8323 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0336-SyncPTR-Do-not-return-SERVFAIL-if-reverse-zone-does-.patch Type: text/x-patch Size: 2134 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0337-SyncPTR-New-PTR-records-inherit-TTL-value-from-respe.patch Type: text/x-patch Size: 3192 bytes Desc: not available URL: From mkosek at redhat.com Wed May 6 06:11:05 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 06 May 2015 08:11:05 +0200 Subject: [Freeipa-devel] [PATCH 424] install: Introduce installer framework ipapython.install In-Reply-To: <554105ED.90204@redhat.com> References: <552FCB4E.4050402@redhat.com> <5531157F.80106@redhat.com> <5534FBB6.3050001@redhat.com> <553513A7.3070704@redhat.com> <554105ED.90204@redhat.com> Message-ID: <5549B079.5020007@redhat.com> On 04/29/2015 06:25 PM, Jan Cholasta wrote: > Dne 20.4.2015 v 16:56 Jan Cholasta napsal(a): >> Dne 20.4.2015 v 15:14 Martin Basti napsal(a): >>> On 17/04/15 16:15, Jan Cholasta wrote: >>>> Dne 16.4.2015 v 16:46 Jan Cholasta napsal(a): >>>>> Hi, >>>>> >>>>> the attached patch adds the basics of the new installer framework. >>>>> >>>>> As a next step, I plan to convert the install scripts to use the >>>>> framework with their old code (the old code will be gradually ported to >>>>> the framework later). >>>>> >>>>> (Note I didn't manage to write docstrings today, expect update >>>>> tomorrow.) >>>> >>>> Added some docstrings. >>>> >>>> Also updated the patch to reflect little brainstorming David and I had >>>> this morning. >>>> >>>>> >>>>> Honza >>>> >>>> >>>> >>> Hello, see comments bellow: >>> >>> 1) We started using new shorter License header in files: >>> # >>> # Copyright (C) 2015 FreeIPA Contributors see COPYING for license >>> # >> >> OK. >> >>> >>> 2) IMO this will not work, NoneType has no 'obj' attribute >>> + else: >>> + if isinstance(value, from_): >>> + value = None >>> + stack.append(value.obj) >>> + continue >> >> Right. >> >>> >>> 3) Multiple inheritance. I do not like it much. >>> +class CompositeInstaller(Installer, CompositeConfigurator): >> >> I guess you are antagonistic to multiple inheritance because of how >> other languages (like C++) do it. In Python it can be pretty elegant and >> is basis for e.g. the mixin design pattern. >> >>> >>> Installer and CompositeConfigurator inherites from Configurator class, >>> and all of them implements _generator method. >> >> Both of them call super()._generator(), so it's no problem (same for >> other methods). >> >>> >>> If I understand correctly >>> (https://www.python.org/download/releases/2.3/mro/) the >>> Installer._generator method will be used in this case. >>> However in case when CompositeConfigurator has more levels (respectively >>> it is more specialized) of inheritance, it could take precedence and its >>> _generator method may be used instead. >> >> The order of precedence is defined by the order of base classes in the >> class definition. >> >>> >>> I'm afraid this may suddenly stop working. >>> Maybe I'm wrong, please fix me. >> >> As long as you call the super class, it will work fine. >> >>> >>> And Multiple inheritance is not easily readable, this is even a diamond >>> inheritance model. >> >> Cooperative inheritance is used by design and IMHO is easily readable if >> you know how to read it. Every class defines a single bit of behavior. >> Without cooperative inheritance, it would have to be hardcoded and/or >> hacked around, which I wanted to avoid. >> >> This blog post explains it nicely: >> . >> > > Updated patch attached. > > Also attached is patch 425 which migrates ipa-server-install to the install > framework. Good job there. I am just curious, will this framework and new option processing be friendly to other types of option passing than just via options? I mean tickets https://fedorahosted.org/freeipa/ticket/4517 https://fedorahosted.org/freeipa/ticket/4468 Especially 4517 is important, we need to be able to run # cat install.conf ds_password=Secret123 admin_password=Secret456 ip_address=123456 setup_dns=False # ipa-server-install --unattended --conf install.conf I assume yes, but I am just making sure. From jcholast at redhat.com Wed May 6 06:22:17 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 06 May 2015 08:22:17 +0200 Subject: [Freeipa-devel] [PATCH 424] install: Introduce installer framework ipapython.install In-Reply-To: <5549B079.5020007@redhat.com> References: <552FCB4E.4050402@redhat.com> <5531157F.80106@redhat.com> <5534FBB6.3050001@redhat.com> <553513A7.3070704@redhat.com> <554105ED.90204@redhat.com> <5549B079.5020007@redhat.com> Message-ID: <5549B319.2060109@redhat.com> Dne 6.5.2015 v 08:11 Martin Kosek napsal(a): > On 04/29/2015 06:25 PM, Jan Cholasta wrote: >> Dne 20.4.2015 v 16:56 Jan Cholasta napsal(a): >>> Dne 20.4.2015 v 15:14 Martin Basti napsal(a): >>>> On 17/04/15 16:15, Jan Cholasta wrote: >>>>> Dne 16.4.2015 v 16:46 Jan Cholasta napsal(a): >>>>>> Hi, >>>>>> >>>>>> the attached patch adds the basics of the new installer framework. >>>>>> >>>>>> As a next step, I plan to convert the install scripts to use the >>>>>> framework with their old code (the old code will be gradually ported to >>>>>> the framework later). >>>>>> >>>>>> (Note I didn't manage to write docstrings today, expect update >>>>>> tomorrow.) >>>>> >>>>> Added some docstrings. >>>>> >>>>> Also updated the patch to reflect little brainstorming David and I had >>>>> this morning. >>>>> >>>>>> >>>>>> Honza >>>>> >>>>> >>>>> >>>> Hello, see comments bellow: >>>> >>>> 1) We started using new shorter License header in files: >>>> # >>>> # Copyright (C) 2015 FreeIPA Contributors see COPYING for license >>>> # >>> >>> OK. >>> >>>> >>>> 2) IMO this will not work, NoneType has no 'obj' attribute >>>> + else: >>>> + if isinstance(value, from_): >>>> + value = None >>>> + stack.append(value.obj) >>>> + continue >>> >>> Right. >>> >>>> >>>> 3) Multiple inheritance. I do not like it much. >>>> +class CompositeInstaller(Installer, CompositeConfigurator): >>> >>> I guess you are antagonistic to multiple inheritance because of how >>> other languages (like C++) do it. In Python it can be pretty elegant and >>> is basis for e.g. the mixin design pattern. >>> >>>> >>>> Installer and CompositeConfigurator inherites from Configurator class, >>>> and all of them implements _generator method. >>> >>> Both of them call super()._generator(), so it's no problem (same for >>> other methods). >>> >>>> >>>> If I understand correctly >>>> (https://www.python.org/download/releases/2.3/mro/) the >>>> Installer._generator method will be used in this case. >>>> However in case when CompositeConfigurator has more levels (respectively >>>> it is more specialized) of inheritance, it could take precedence and its >>>> _generator method may be used instead. >>> >>> The order of precedence is defined by the order of base classes in the >>> class definition. >>> >>>> >>>> I'm afraid this may suddenly stop working. >>>> Maybe I'm wrong, please fix me. >>> >>> As long as you call the super class, it will work fine. >>> >>>> >>>> And Multiple inheritance is not easily readable, this is even a diamond >>>> inheritance model. >>> >>> Cooperative inheritance is used by design and IMHO is easily readable if >>> you know how to read it. Every class defines a single bit of behavior. >>> Without cooperative inheritance, it would have to be hardcoded and/or >>> hacked around, which I wanted to avoid. >>> >>> This blog post explains it nicely: >>> . >>> >> >> Updated patch attached. >> >> Also attached is patch 425 which migrates ipa-server-install to the install >> framework. > > Good job there. I am just curious, will this framework and new option > processing be friendly to other types of option passing than just via options? > I mean tickets > > https://fedorahosted.org/freeipa/ticket/4517 > https://fedorahosted.org/freeipa/ticket/4468 > > Especially 4517 is important, we need to be able to run > > # cat install.conf > ds_password=Secret123 > admin_password=Secret456 > ip_address=123456 > setup_dns=False > > # ipa-server-install --unattended --conf install.conf > > I assume yes, but I am just making sure. Yes, definitely. -- Jan Cholasta From mkosek at redhat.com Wed May 6 06:47:28 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 06 May 2015 08:47:28 +0200 Subject: [Freeipa-devel] Wiki: automatic bookkeeping of Design documents Message-ID: <5549B900.3060607@redhat.com> Hello all, Knowing the sorrow and unmaintained state of the pages collecting links to our designs [1][2], I think we need to execute the second half of my evil plan for Design Document management. We have the Feature design box (see top right corner, e.g. in [3]), so we can easily automatically generate mediawiki categories. The first I implemented in the template are "FreeIPA $VERSION Design" when target version is filled (and design is thus accepted for a release) and "FreeIPA Design Proposal" for others. We can be creative with other categories in future, if needed. But even these 2 and a DynamicPageList plugin allowed me to create automatically generated design lists, in [4]. I had to update the box in many designs, however. Makes sense? If yes, I would update these pages. Of course, this requires developers to maintain the Feature box properly, but I think it's worth it. [1] http://www.freeipa.org/page/V4_Proposals [2] http://www.freeipa.org/page/V4_Designs [3] http://www.freeipa.org/page/V4/User_Certificates [4] http://www.freeipa.org/page/Talk:V4_Designs -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From mkosek at redhat.com Wed May 6 06:52:10 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 06 May 2015 08:52:10 +0200 Subject: [Freeipa-devel] User Certificates in 4.2 - design and questions In-Reply-To: <55486564.4020400@redhat.com> References: <554732C7.5000109@redhat.com> <20150504130102.GP16379@dhcp-40-8.bne.redhat.com> <55478526.8060604@redhat.com> <1430767402.916.84.camel@willson.usersys.redhat.com> <55486564.4020400@redhat.com> Message-ID: <5549BA1A.1010702@redhat.com> On 05/05/2015 08:38 AM, Martin Kosek wrote: > On 05/04/2015 09:23 PM, Simo Sorce wrote: >> On Mon, 2015-05-04 at 16:41 +0200, Martin Kosek wrote: ... >> So I am fine *not* revoking certs automatically and instead documenting >> best practices for certs lifecycle management (ie deleting certs when >> not useful) and how to manually/explicitly revoke certs only when >> actually compromised (for hosts), or when needed (user leaves >> organization and may retain a copy of the private key, unlikly when the >> cert was in a Smart Card which has been returned and wiped). > > Well, makes sense to me. I added a section to the design: > http://www.freeipa.org/page/V4/User_Certificates#Revocation_of_the_Certificates > > We just need to be cautious here because this would be a change in behavior > compared to FreeIPA 4.1 and older. Should this be another global/per-profile > policy setting that administrator could set up? Honza said it is a good idea off-list (well, thank you!), so I added the proposal in the design page to make this option part of the per-profile certificate management policy: http://www.freeipa.org/page/V4/User_Certificates#Configuration If there are objections, please holler. From mkosek at redhat.com Wed May 6 07:29:31 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 06 May 2015 09:29:31 +0200 Subject: [Freeipa-devel] Domain Level feature kick-off Message-ID: <5549C2DB.5000605@redhat.com> Hello, as already discussed in December [1], we will need to implement domain levels in FreeIPA 4.2 to make sure we can manage the replication agreement by Topology plugin. I created a ticket for this feature [3] and linked it with Simo's design. The proposed scope for the feature is written in the ticket itself. Tomas agreed he would work on this. The first consumer is Ludwig's topology plugin. Seeing Ludwig's initial patches [4], I suspect he chose a different format (major/minor) for the domain level value, but as we discussed in [2], it will rather be a numerical value, raised only when needed. This is something for Tomas and Ludwig to coordinate together. I am not sure if Custodia work will need this, maybe the new ipa-replica-install would just check if Custodia is there or not and not decide on Domain Levels... we will see. The design page does not list the actual API, but I expect it to be very simple for now, maybe just $ ipa domainlevel-show $ ipa domainlevel-raise NUMBER Makes sense? [1] http://www.redhat.com/archives/freeipa-devel/2014-December/msg00199.html [2] http://www.redhat.com/archives/freeipa-devel/2014-December/msg00221.html [3] https://fedorahosted.org/freeipa/ticket/5018 [4] http://www.redhat.com/archives/freeipa-devel/2015-April/msg00096.html -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From tbabej at redhat.com Wed May 6 08:12:22 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 06 May 2015 10:12:22 +0200 Subject: [Freeipa-devel] [PATCHES 306-316] Automated migration tool from Winsync In-Reply-To: <5548B13B.60607@redhat.com> References: <54FD8369.10803@redhat.com> <54FF0F46.3010109@redhat.com> <55005D3C.5090304@redhat.com> <5540B23A.9060404@redhat.com> <5548B13B.60607@redhat.com> Message-ID: <5549CCE6.3010006@redhat.com> On 05/05/2015 02:02 PM, Tomas Babej wrote: > > > On 04/29/2015 12:28 PM, Tomas Babej wrote: >> >> >> On 03/11/2015 04:20 PM, Jan Cholasta wrote: >>> Hi, >>> >>> Dne 10.3.2015 v 16:35 Tomas Babej napsal(a): >>>> >>>> On 03/09/2015 12:26 PM, Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> this couple of patches provides a initial implementation of the >>>>> winsync migration tool: >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4524 >>>>> >>>>> Some parts could use some polishing, but this is a sound foundation. >>>>> >>>>> Tomas >>>>> >>>>> >>>>> >>>> >>>> Attaching one more patch to the bundle. This one should make the >>>> winsync >>>> tool readily available after install. >>>> >>>> Tomas >>>> >>>> >>> >>> Nitpicks: >>> >>> The winsync_migrate module should be in ipaserver.install. Also I >>> don't see why it has to be a package when there is just one short >>> file in it. >>> >>> By convention, the AdminTool subclass should be named >>> WinsyncMigrate, or the tool should be named ipa-migrate-winsync. >>> >>> Honza >>> >> >> Updated patches attached. >> >> Tomas > > Rebased patches with cleaned membership bits. > > Tomas I did some self-review, updated patches attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0306-4-winsync-migrate-Add-initial-plumbing.patch Type: text/x-patch Size: 5629 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0307-4-winsync-migrate-Add-a-way-to-find-all-winsync-users.patch Type: text/x-patch Size: 2206 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0308-4-migrate-winsync-Create-user-ID-overrides-in-place-of.patch Type: text/x-patch Size: 2450 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0309-4-migrate-winsync-Add-option-validation-and-handling.patch Type: text/x-patch Size: 2524 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0310-4-winsync-migrate-Move-the-api-initalization-and-LDAP-.patch Type: text/x-patch Size: 1974 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0311-4-dcerpc-Change-logging-level-for-debug-information.patch Type: text/x-patch Size: 1345 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0312-4-dcerpc-Add-debugging-message-to-failing-kinit-as-htt.patch Type: text/x-patch Size: 912 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0313-4-winsync-migrate-Require-root-privileges.patch Type: text/x-patch Size: 1010 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0314-4-idviews-Do-not-abort-the-find-show-commands-on-conve.patch Type: text/x-patch Size: 1785 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0315-4-winsync-migrate-Require-explicit-specification-of-th.patch Type: text/x-patch Size: 3132 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0316-4-winsync-migrate-Delete-winsync-agreement-prior-to-mi.patch Type: text/x-patch Size: 2853 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0317-4-winsync-migrate-Rename-to-tool-to-achive-consistency.patch Type: text/x-patch Size: 2696 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0318-4-winsync-migrate-Move-the-tool-under-ipaserver.instal.patch Type: text/x-patch Size: 1294 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0319-4-winsync-migrate-Include-the-tool-parts-in-Makefile-a.patch Type: text/x-patch Size: 1223 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0320-4-idviews-Fallback-to-AD-DC-LDAP-only-if-specifically-.patch Type: text/x-patch Size: 15670 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0321-4-man-Add-manpage-for-ipa-winsync-migrate.patch Type: text/x-patch Size: 2847 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0322-4-winsync_migrate-Migrate-memberships-of-the-winsynced.patch Type: text/x-patch Size: 3193 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0323-4-winsync_migrate-Generalize-membership-migration.patch Type: text/x-patch Size: 7165 bytes Desc: not available URL: From pspacek at redhat.com Wed May 6 09:03:54 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 06 May 2015 11:03:54 +0200 Subject: [Freeipa-devel] Wiki: automatic bookkeeping of Design documents In-Reply-To: <5549B900.3060607@redhat.com> References: <5549B900.3060607@redhat.com> Message-ID: <5549D8FA.2020101@redhat.com> On 6.5.2015 08:47, Martin Kosek wrote: > Hello all, > > Knowing the sorrow and unmaintained state of the pages collecting links to our > designs [1][2], I think we need to execute the second half of my evil plan for > Design Document management. > > We have the Feature design box (see top right corner, e.g. in [3]), so we can > easily automatically generate mediawiki categories. The first I implemented in > the template are "FreeIPA $VERSION Design" when target version is filled (and > design is thus accepted for a release) and "FreeIPA Design Proposal" for > others. We can be creative with other categories in future, if needed. > > But even these 2 and a DynamicPageList plugin allowed me to create > automatically generated design lists, in [4]. I had to update the box in many > designs, however. > > Makes sense? If yes, I would update these pages. Of course, this requires > developers to maintain the Feature box properly, but I think it's worth it. It makes sense do me if we document the rules. E.g. 'design is accepted if and only if version + reviewer fields are filled' or something like that. > [1] http://www.freeipa.org/page/V4_Proposals > [2] http://www.freeipa.org/page/V4_Designs > [3] http://www.freeipa.org/page/V4/User_Certificates > [4] http://www.freeipa.org/page/Talk:V4_Designs -- Petr^2 Spacek From pvoborni at redhat.com Wed May 6 10:20:34 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 06 May 2015 12:20:34 +0200 Subject: [Freeipa-devel] Wiki: automatic bookkeeping of Design documents In-Reply-To: <5549B900.3060607@redhat.com> References: <5549B900.3060607@redhat.com> Message-ID: <5549EAF2.3040606@redhat.com> On 05/06/2015 08:47 AM, Martin Kosek wrote: > Hello all, > > Knowing the sorrow and unmaintained state of the pages collecting links to our > designs [1][2], I think we need to execute the second half of my evil plan for > Design Document management. > > We have the Feature design box (see top right corner, e.g. in [3]), so we can > easily automatically generate mediawiki categories. The first I implemented in > the template are "FreeIPA $VERSION Design" when target version is filled (and > design is thus accepted for a release) and "FreeIPA Design Proposal" for > others. We can be creative with other categories in future, if needed. > > But even these 2 and a DynamicPageList plugin allowed me to create > automatically generated design lists, in [4]. I had to update the box in many > designs, however. > > Makes sense? If yes, I would update these pages. Of course, this requires > developers to maintain the Feature box properly, but I think it's worth it. I like it. What do you think about keeping design proposals on the same page with approved designs as is now in [4]? When I'm looking for some design, it often happens that I'm not sure on which page it is. With both lists on the same page, one could do simple search to find the design quickly. > > > [1] http://www.freeipa.org/page/V4_Proposals > [2] http://www.freeipa.org/page/V4_Designs > [3] http://www.freeipa.org/page/V4/User_Certificates > [4] http://www.freeipa.org/page/Talk:V4_Designs > -- Petr Vobornik From pspacek at redhat.com Wed May 6 10:52:52 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 06 May 2015 12:52:52 +0200 Subject: [Freeipa-devel] bind-dyndb-ldap: [PATCH] Add note about installation from Git to README. In-Reply-To: <5549E947.2070707@redhat.com> References: <5549E947.2070707@redhat.com> Message-ID: <5549F284.3060008@redhat.com> Hello David, don't be shy and share your patches with the ipa-devel list :-) Anyway, I did few changes to the patch and pushed it as commit 8e42fe2add7f97e9c9412b08306e73d6ec53a20e to master branch. Thank you! -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-dkupka-0001-Add-note-about-installation-from-Git-to-README.patch Type: text/x-patch Size: 824 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-dkupka-0001-2-Add-note-about-installation-from-Git-to-README.patch Type: text/x-patch Size: 855 bytes Desc: not available URL: From mkosek at redhat.com Wed May 6 11:11:11 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 06 May 2015 13:11:11 +0200 Subject: [Freeipa-devel] Wiki: automatic bookkeeping of Design documents In-Reply-To: <5549EAF2.3040606@redhat.com> References: <5549B900.3060607@redhat.com> <5549EAF2.3040606@redhat.com> Message-ID: <5549F6CF.2070001@redhat.com> On 05/06/2015 12:20 PM, Petr Vobornik wrote: > On 05/06/2015 08:47 AM, Martin Kosek wrote: >> Hello all, >> >> Knowing the sorrow and unmaintained state of the pages collecting links to our >> designs [1][2], I think we need to execute the second half of my evil plan for >> Design Document management. >> >> We have the Feature design box (see top right corner, e.g. in [3]), so we can >> easily automatically generate mediawiki categories. The first I implemented in >> the template are "FreeIPA $VERSION Design" when target version is filled (and >> design is thus accepted for a release) and "FreeIPA Design Proposal" for >> others. We can be creative with other categories in future, if needed. >> >> But even these 2 and a DynamicPageList plugin allowed me to create >> automatically generated design lists, in [4]. I had to update the box in many >> designs, however. >> >> Makes sense? If yes, I would update these pages. Of course, this requires >> developers to maintain the Feature box properly, but I think it's worth it. > > I like it. > > What do you think about keeping design proposals on the same page with approved > designs as is now in [4]? When I'm looking for some design, it often happens > that I'm not sure on which page it is. With both lists on the same page, one > could do simple search to find the design quickly. I guess I could live with V4_Proposals page merged to V4_Designs. The number of proposed is not that big. But I do not think the confusion should happen - designs for next versions should be versioned, in Trac tickets and thus seen on the V4_Designs page or in the ticket. >> [1] http://www.freeipa.org/page/V4_Proposals >> [2] http://www.freeipa.org/page/V4_Designs >> [3] http://www.freeipa.org/page/V4/User_Certificates >> [4] http://www.freeipa.org/page/Talk:V4_Designs >> From mbasti at redhat.com Wed May 6 11:17:43 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 06 May 2015 13:17:43 +0200 Subject: [Freeipa-devel] [PATCHES 0231-0232] Server Upgrade: support base64 encoded values in update files + remove CSV In-Reply-To: <55409129.8020606@redhat.com> References: <552FD1C0.2040104@redhat.com> <5538D21A.8040000@redhat.com> <553E1802.8050409@redhat.com> <553E4BD7.4010707@redhat.com> <55409129.8020606@redhat.com> Message-ID: <5549F857.2060008@redhat.com> On 29/04/15 10:07, Jan Cholasta wrote: > Dne 27.4.2015 v 16:46 Martin Basti napsal(a): >> On 27/04/15 13:05, Martin Basti wrote: >>> On 23/04/15 13:06, Martin Basti wrote: >>>> On 16/04/15 17:14, Martin Basti wrote: >>>>> https://fedorahosted.org/freeipa/ticket/4984 >>>>> >>>>> I had to remove CSV (which is evil) to be able fix this ticket. >>>>> >>>>> Patches attached. >>>>> >>>>> >>>>> >>>> Updated patches attached. >>>> >>>> -- >>>> Martin Basti >>>> >>>> >>> Rebased patches attached. >>> >>> -- >>> Martin Basti >>> >>> >> rebased patches attached >> >> -- >> Martin Basti >> >> >> > > ACK on patch 231. > > BTW I have found a 7 year old bug caused by CSV while reviewing it: > . > > There is also similar git-only bug in > install/updates/10-uniqueness.update: > > default:uniqueness-subtrees: 'cn=accounts,$SUFFIX' > default:uniqueness-subtrees: 'cn=deleted > users,cn=accounts,cn=provisioning,$SUFFIX' > > but your patch fixes it. > > I will review patch 232 later. > > Honza > Honza doesn't like original 232 so much. Updated patch 232 attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0231.4-Server-Upgrade-remove-CSV-from-upgrade-files.patch Type: text/x-patch Size: 127820 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0232.5-Server-Upgrade-Allow-base64-encoded-values.patch Type: text/x-patch Size: 7726 bytes Desc: not available URL: From mbasti at redhat.com Wed May 6 11:22:00 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 06 May 2015 13:22:00 +0200 Subject: [Freeipa-devel] [PATCH 0238] Server Upgrade: fix broken memberUid index Message-ID: <5549F958.1040508@redhat.com> https://fedorahosted.org/freeipa/ticket/5007 Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0238-Server-Upgrade-fix-memberUid-index.patch Type: text/x-patch Size: 942 bytes Desc: not available URL: From mbasti at redhat.com Wed May 6 11:23:21 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 06 May 2015 13:23:21 +0200 Subject: [Freeipa-devel] [PATCH 0238] Server Upgrade: fix broken memberUid index In-Reply-To: <5549F958.1040508@redhat.com> References: <5549F958.1040508@redhat.com> Message-ID: <5549F9A9.50107@redhat.com> On 06/05/15 13:22, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5007 > > Patch attached. > > > Requires patch mbasti-231-4 -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Wed May 6 11:37:41 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 06 May 2015 13:37:41 +0200 Subject: [Freeipa-devel] [PATCH] 825 webui-ci: fix type error in host_tasks inicializations Message-ID: <5549FD05.6010203@redhat.com> host_tasks initializations were not modified along with pytest migration -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0825-webui-ci-fix-type-error-in-host_tasks-inicialization.patch Type: text/x-patch Size: 1677 bytes Desc: not available URL: From mbabinsk at redhat.com Wed May 6 11:54:35 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 06 May 2015 13:54:35 +0200 Subject: [Freeipa-devel] [PATCH 0032] prevent duplicate IDs when setting up multiple replicas against single master Message-ID: <554A00FB.60205@redhat.com> The attached patch tries to fix https://fedorahosted.org/freeipa/ticket/4378 After discussion with Thierry we concluded that while this issue is more complex than it seems, the transition from REPLACE to DEL/ADD operations when updating nsDS5ReplicaId should suffice for this ticket. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0032-prevent-duplicate-IDs-when-setting-up-multiple-repli.patch Type: text/x-patch Size: 5150 bytes Desc: not available URL: From ssorce at redhat.com Wed May 6 11:55:17 2015 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 06 May 2015 07:55:17 -0400 Subject: [Freeipa-devel] Wiki: automatic bookkeeping of Design documents In-Reply-To: <5549B900.3060607@redhat.com> References: <5549B900.3060607@redhat.com> Message-ID: <1430913317.916.90.camel@willson.usersys.redhat.com> On Wed, 2015-05-06 at 08:47 +0200, Martin Kosek wrote: > Hello all, > > Knowing the sorrow and unmaintained state of the pages collecting links to our > designs [1][2], I think we need to execute the second half of my evil plan for > Design Document management. > > We have the Feature design box (see top right corner, e.g. in [3]), so we can > easily automatically generate mediawiki categories. The first I implemented in > the template are "FreeIPA $VERSION Design" when target version is filled (and > design is thus accepted for a release) and "FreeIPA Design Proposal" for > others. We can be creative with other categories in future, if needed. > > But even these 2 and a DynamicPageList plugin allowed me to create > automatically generated design lists, in [4]. I had to update the box in many > designs, however. > > Makes sense? If yes, I would update these pages. Of course, this requires > developers to maintain the Feature box properly, but I think it's worth it. > > > [1] http://www.freeipa.org/page/V4_Proposals > [2] http://www.freeipa.org/page/V4_Designs > [3] http://www.freeipa.org/page/V4/User_Certificates > [4] http://www.freeipa.org/page/Talk:V4_Designs > +1 From abokovoy at redhat.com Wed May 6 11:58:23 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 6 May 2015 14:58:23 +0300 Subject: [Freeipa-devel] Wiki: automatic bookkeeping of Design documents In-Reply-To: <5549B900.3060607@redhat.com> References: <5549B900.3060607@redhat.com> Message-ID: <20150506115823.GS11785@redhat.com> On Wed, 06 May 2015, Martin Kosek wrote: >Hello all, > >Knowing the sorrow and unmaintained state of the pages collecting links to our >designs [1][2], I think we need to execute the second half of my evil plan for >Design Document management. > >We have the Feature design box (see top right corner, e.g. in [3]), so we can >easily automatically generate mediawiki categories. The first I implemented in >the template are "FreeIPA $VERSION Design" when target version is filled (and >design is thus accepted for a release) and "FreeIPA Design Proposal" for >others. We can be creative with other categories in future, if needed. > >But even these 2 and a DynamicPageList plugin allowed me to create >automatically generated design lists, in [4]. I had to update the box in many >designs, however. > >Makes sense? If yes, I would update these pages. Of course, this requires >developers to maintain the Feature box properly, but I think it's worth it. > > >[1] http://www.freeipa.org/page/V4_Proposals >[2] http://www.freeipa.org/page/V4_Designs >[3] http://www.freeipa.org/page/V4/User_Certificates >[4] http://www.freeipa.org/page/Talk:V4_Designs Looks very good, thanks! -- / Alexander Bokovoy From tbordaz at redhat.com Wed May 6 12:22:00 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 06 May 2015 14:22:00 +0200 Subject: [Freeipa-devel] [PATCH 0032] prevent duplicate IDs when setting up multiple replicas against single master In-Reply-To: <554A00FB.60205@redhat.com> References: <554A00FB.60205@redhat.com> Message-ID: <554A0768.9000107@redhat.com> On 05/06/2015 01:54 PM, Martin Babinsky wrote: > The attached patch tries to fix > https://fedorahosted.org/freeipa/ticket/4378 > > After discussion with Thierry we concluded that while this issue is > more complex than it seems, the transition from REPLACE to DEL/ADD > operations when updating nsDS5ReplicaId should suffice for this ticket. > Hello Martin, Few comments, you are using MOD_DEL 'replicaID' with None value. So this is going to delete all previous values and it should be equivalent to a MOD_REPL. I was thinking you wanted to retrieve the id_value and call MOD_DEL 'replicaID' . So that if by the time you fetched the replicaId, an other replica updated the replicaId, the MOD_DEL/MOD_ADD would fail and you need a new iteration. If replicaId was multi-valued and you want to make it single valued, you may want to do create a more complex MOD (e.g. (ldap.MOD_DELETE, 'nsDS5ReplicaId', str(value1), (ldap.MOD_DELETE, 'nsDS5ReplicaId', str(value2)...) If it is updating successfully do you want to return 'retval' or 'retval+1' ? If several replicas try to update the replicaId of the master and the current replicaId is 1000. Replica1 successfully updates the replicaId and gets 1001 as the new value. Replica2 successfully updates the replicaId and gets 1002. The final value on master will be 1002, but replica1 will assum it is 1001. Is it a problem ? thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkrispen at redhat.com Wed May 6 12:47:31 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 06 May 2015 14:47:31 +0200 Subject: [Freeipa-devel] ipa-replica-manage del fails to delete host entry Message-ID: <554A0D63.50409@redhat.com> Hi, in recent posts about corrupted ruvs, there also was the error about failing cleanup, like: ipa-replica-manage del vm-162.idm.lab.eng.brq.redhat.com .. Failed to cleanup vm-162.idm.lab.eng.brq.redhat.com entries: Not allowed on non-leaf entry in the access log we see [06/May/2015:14:19:11 +0200]conn=30 op=17 SRCH base="cn=vm-162.idm.lab.eng.brq.redhat.com,cn=masters,cn=ipa,cn=etc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" scope=2 filter="(objectClass=*)" attrs=ALL [06/May/2015:14:19:11 +0200] conn=30 op=17 RESULT err=0 tag=101 nentries=6 etime=0 notes=U [06/May/2015:14:19:11 +0200] conn=30 op=18 DEL dn="cn=vm-162.idm.lab.eng.brq.redhat.com,cn=masters,cn=ipa,cn=etc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" [06/May/2015:14:19:11 +0200] conn=30 op=18 RESULT err=66 tag=107 nentries=0 etime=0 which means that there was an attempt to remove the host before the services in replica_cleanup we have: # delete master entry with all active services try: dn = DN(('cn', replica), ('cn', 'masters'), ('cn', 'ipa'),('cn', 'etc'), self.suffix) entries = self.conn.get_entries(dn, ldap.SCOPE_SUBTREE) if entries: entries.sort(key=len, reverse=True) for entry in entries: self.conn.delete_entry(entry) this intends to delete children befor the parent, as teh dns of children are longer, but get_entries does return a list of entries, not DNs, and so the sorting does not work as can be seen in this example: >>> list = [('123456','A'),('123','B'),('12345678','C')] >>> list.sort(key=len,reverse=True) >>> for l in list: ... print l ... ('123456', 'A') ('123', 'B') ('12345678', 'C') -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Wed May 6 13:07:52 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 06 May 2015 15:07:52 +0200 Subject: [Freeipa-devel] ipa-replica-manage del fails to delete host entry In-Reply-To: <554A0D63.50409@redhat.com> References: <554A0D63.50409@redhat.com> Message-ID: <554A1228.9030800@redhat.com> On 05/06/2015 02:47 PM, Ludwig Krispenz wrote: > > Hi, > in recent posts about corrupted ruvs, there also was the error about > failing cleanup, like: > > ipa-replica-manage del vm-162.idm.lab.eng.brq.redhat.com > > .. > Failed to cleanup vm-162.idm.lab.eng.brq.redhat.com entries: Not > allowed on non-leaf entry > > in the access log we see > > [06/May/2015:14:19:11 +0200]conn=30 op=17 SRCH > base="cn=vm-162.idm.lab.eng.brq.redhat.com,cn=masters,cn=ipa,cn=etc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" > scope=2 filter="(objectClass=*)" attrs=ALL > > [06/May/2015:14:19:11 +0200] conn=30 op=17 RESULT err=0 tag=101 > nentries=6 etime=0 notes=U > [06/May/2015:14:19:11 +0200] conn=30 op=18 DEL > dn="cn=vm-162.idm.lab.eng.brq.redhat.com,cn=masters,cn=ipa,cn=etc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" > [06/May/2015:14:19:11 +0200] conn=30 op=18 RESULT err=66 tag=107 > nentries=0 etime=0 > > which means that there was an attempt to remove the host before the > services > > in replica_cleanup we have: > > # delete master entry with all active services > > try: > dn = DN(('cn', replica), ('cn', 'masters'), ('cn', 'ipa'),('cn', > 'etc'), self.suffix) > entries = self.conn.get_entries(dn, ldap.SCOPE_SUBTREE) > if entries: > entries.sort(key=len, reverse=True) > for entry in entries: > self.conn.delete_entry(entry) > > this intends to delete children befor the parent, as teh dns of > children are longer, but get_entries does return a list of entries, > not DNs, and so the sorting does not work as can be seen in this example: > > >>> list = [('123456','A'),('123','B'),('12345678','C')] > > >>> list.sort(key=len,reverse=True) > > >>> for l in list: > > ... print l > > ... > > ('123456', 'A') > > ('123', 'B') > > ('12345678', 'C') > > > A quick fix would be to use key=lambda x: len(x.dn) then. Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0324-replica-manage-Properly-delete-nested-entries.patch Type: text/x-patch Size: 2251 bytes Desc: not available URL: From mbabinsk at redhat.com Wed May 6 13:19:05 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 06 May 2015 15:19:05 +0200 Subject: [Freeipa-devel] [PATCH 0032] prevent duplicate IDs when setting up multiple replicas against single master In-Reply-To: <554A0768.9000107@redhat.com> References: <554A00FB.60205@redhat.com> <554A0768.9000107@redhat.com> Message-ID: <554A14C9.90605@redhat.com> Hello Thierry, replies are inline. On 05/06/2015 02:22 PM, thierry bordaz wrote: > On 05/06/2015 01:54 PM, Martin Babinsky wrote: >> The attached patch tries to fix >> https://fedorahosted.org/freeipa/ticket/4378 >> >> After discussion with Thierry we concluded that while this issue is >> more complex than it seems, the transition from REPLACE to DEL/ADD >> operations when updating nsDS5ReplicaId should suffice for this ticket. >> > Hello Martin, > > Few comments, you are using MOD_DEL 'replicaID' with None value. So this > is going to delete all previous values and it should be equivalent to a > MOD_REPL. > I was thinking you wanted to retrieve the id_value and call MOD_DEL > 'replicaID' . So that if by the time you fetched the > replicaId, an other replica updated the replicaId, the MOD_DEL/MOD_ADD > would fail and you need a new iteration. > Sorry I didn't know you can MOD_DEL a particular value (I'm LDAP noob I know). Will fix this. > If replicaId was multi-valued and you want to make it single valued, you > may want to do create a more complex MOD (e.g. (ldap.MOD_DELETE, > 'nsDS5ReplicaId', str(value1), (ldap.MOD_DELETE, 'nsDS5ReplicaId', > str(value2)...) > AFAIK ReplicaId is single-valued (looking at the schema right now) so this shouldn't be problem. > If it is updating successfully do you want to return 'retval' or > 'retval+1' ? > > If several replicas try to update the replicaId of the master and the > current replicaId is 1000. > Replica1 successfully updates the replicaId and gets 1001 as the new value. > Replica2 successfully updates the replicaId and gets 1002. > The final value on master will be 1002, but replica1 will assum it is > 1001. Is it a problem ? > I studied the code in the master branch and IIUC (and please correct me if I got this wrong) nsDS5ReplicaId attribute in 'cn=replication,cn=etc,$SUFFIX' represents replicaID of the _next_ replica that will be installed. So if a replica is installed, it sets the current value of nsDS5ReplicaId as its replica ID (the function returns 'retval') and then increments it in 'cn=replication,cn=etc,$SUFFIX' entry ('retval + 1' is written to master) so that the next installed replica fetches this updated value. So the case you described should be the expected behavior. To change it would require different patch IMHO. > thanks > thierry -- Martin^3 Babinsky From mbasti at redhat.com Wed May 6 13:20:57 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 06 May 2015 15:20:57 +0200 Subject: [Freeipa-devel] [PATCHES 0233-0234] DNSSEC: forwarders validation In-Reply-To: <5548BED1.1060806@redhat.com> References: <553A3D88.6080200@redhat.com> <55423032.9080505@redhat.com> <5548BED1.1060806@redhat.com> Message-ID: <554A1539.3040002@redhat.com> On 05/05/15 15:00, Martin Basti wrote: > On 30/04/15 15:37, David Kupka wrote: >> On 04/24/2015 02:56 PM, Martin Basti wrote: >>> Patches attached. >>> >>> >>> >>> >> Hi, >> thanks for patches. >> >> 1. You changed message in DNSServerNotRespondingWarning class but not >> the test in ipatest/test_xmlrpc/test_dns_plugin.py >> >> nitpick. Please spell 'edns' correctly. I've seen several instances >> of 'ends'. >> > Thank you, > > updated patches attached: > * new error messages > * logging to debug log server output if exception was raised > * fixed test > * fixed spelling > > > Fixed tests (again) Updated patches attached -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0233.3-DNSSEC-Improve-global-forwarders-validation.patch Type: text/x-patch Size: 15981 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0234.3-DNSSEC-validate-forward-zone-forwarders.patch Type: text/x-patch Size: 16442 bytes Desc: not available URL: From tbordaz at redhat.com Wed May 6 14:25:35 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 06 May 2015 16:25:35 +0200 Subject: [Freeipa-devel] [PATCH 0032] prevent duplicate IDs when setting up multiple replicas against single master In-Reply-To: <554A14C9.90605@redhat.com> References: <554A00FB.60205@redhat.com> <554A0768.9000107@redhat.com> <554A14C9.90605@redhat.com> Message-ID: <554A245F.4060507@redhat.com> On 05/06/2015 03:19 PM, Martin Babinsky wrote: > Hello Thierry, > > replies are inline. > > On 05/06/2015 02:22 PM, thierry bordaz wrote: >> On 05/06/2015 01:54 PM, Martin Babinsky wrote: >>> The attached patch tries to fix >>> https://fedorahosted.org/freeipa/ticket/4378 >>> >>> After discussion with Thierry we concluded that while this issue is >>> more complex than it seems, the transition from REPLACE to DEL/ADD >>> operations when updating nsDS5ReplicaId should suffice for this ticket. >>> >> Hello Martin, >> >> Few comments, you are using MOD_DEL 'replicaID' with None value. So this >> is going to delete all previous values and it should be equivalent to a >> MOD_REPL. >> I was thinking you wanted to retrieve the id_value and call MOD_DEL >> 'replicaID' . So that if by the time you fetched the >> replicaId, an other replica updated the replicaId, the MOD_DEL/MOD_ADD >> would fail and you need a new iteration. >> > Sorry I didn't know you can MOD_DEL a particular value (I'm LDAP noob > I know). Will fix this. >> If replicaId was multi-valued and you want to make it single valued, you >> may want to do create a more complex MOD (e.g. (ldap.MOD_DELETE, >> 'nsDS5ReplicaId', str(value1), (ldap.MOD_DELETE, 'nsDS5ReplicaId', >> str(value2)...) >> > AFAIK ReplicaId is single-valued (looking at the schema right now) so > this shouldn't be problem. >> If it is updating successfully do you want to return 'retval' or >> 'retval+1' ? >> >> If several replicas try to update the replicaId of the master and the >> current replicaId is 1000. >> Replica1 successfully updates the replicaId and gets 1001 as the new >> value. >> Replica2 successfully updates the replicaId and gets 1002. >> The final value on master will be 1002, but replica1 will assum it is >> 1001. Is it a problem ? >> > I studied the code in the master branch and IIUC (and please correct > me if I got this wrong) nsDS5ReplicaId attribute in > 'cn=replication,cn=etc,$SUFFIX' represents replicaID of the _next_ > replica that will be installed. > > So if a replica is installed, it sets the current value of > nsDS5ReplicaId as its replica ID (the function returns 'retval') and > then increments it in 'cn=replication,cn=etc,$SUFFIX' entry ('retval + > 1' is written to master) so that the next installed replica fetches > this updated value. > > So the case you described should be the expected behavior. To change > it would require different patch IMHO. Thank for your precious explanations, in fact the value in 'cn=replication,cn=etc,SUFFIX' is the next available replicaId value and is the centralized mechanism that assign unique replicaID. The risk was that several replica pick the same value. So yes it is important that the MOD_DEL specifies the previously read value so that the test/set will be atomic. If several replicas read the same value, only the faster one will use it to install the replica. thanks thierry >> thanks >> thierry > > From mkubik at redhat.com Wed May 6 14:25:47 2015 From: mkubik at redhat.com (Milan Kubik) Date: Wed, 06 May 2015 16:25:47 +0200 Subject: [Freeipa-devel] [PATCH] 800 rpc-client: add forms based auth support In-Reply-To: <54E5F883.1090702@redhat.com> References: <54E5F883.1090702@redhat.com> Message-ID: <554A246B.4060109@redhat.com> On 02/19/2015 03:51 PM, Petr Vobornik wrote: > This patch is a prerequisite for patch 801 which will follow. It was > developed to enable to use ipalib RPC client in Web UI tests. Plus it > will enable to significantly speed up Web UI tests suite (if > preparation of data is transformed to use this method). > > Partly related https://fedorahosted.org/freeipa/ticket/4772 and > https://fedorahosted.org/freeipa/ticket/4307 > > > Leverage session support to enable forms-based authenticate in rpc > client. > > In order to do that session support in KerbTransport was moved to new > SessionTransport. RPCClient.create_connection is then modified to > force forms-based auth if new optional options - user and password are > specified. For this case SessionTransport is used and user is > authenticated by calling > 'https://ipa.server/ipa/session/login_password'. Session cookie is > stored and used in subsequent calls. > > This feature is usable for use cases where one wants to call the API > without being on ipa client. Non-being on ipa client also means that > IPA's NSS database and configuration is not available. Therefore one > has to define "~/.ipa/default.conf" in a similar way as ipa client > does and prepare a NSS database with IPA CA cert. > > Usage: > > api.Backend.rpcclient.connect( > nss_dir=my_nss_dir_path, > user=user, > password=password > ) > > It's possible to switch users with: > > api.Backend.rpcclient.disconnect() > > api.Backend.rpcclient.connect( > nss_dir=my_nss_dir_path, > user=other_user, > password=other_password > ) > > Or check connection with: > > api.Backend.rpcclient.isconnected() > > Example: download a CA cert and add it to a new temporary NSS database: > from urllib2 import urlparse > from ipaplatform.paths import paths > from ipapython import certdb, ipautil > from ipapython.ipautil import run > from ipalib import x509 > > # create new NSSDatabase > tmp_db = certdb.NSSDatabase() > pwd_file = ipautil.write_tmp_file(ipautil.ipa_generate_password()) > tmp_db.create_db(pwd_file.name) > > # download and add cert > url = urlparse.urlunparse(('http', ipautil.format_netloc(ipa_server), > '/ipa/config/ca.crt', '', '', '')) > stdout, stderr, rc = run([paths.BIN_WGET, "-O", "-", url]) > certs = x509.load_certificate_list(stdout, tmp_db.secdir) > ca_certs = [cert.der_data for cert in certs] > for i, cert in enumerate(ca_certs): > tmp_db.add_cert(cert, 'CA certificate %d' % (i + 1), 'C,,') > > my_nss_dir_path = tmp_db.secdir > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Hi, thanks for the patch. Please, fix the pep8 complaints. Can someone else look at the code as well, please? Thanks, Milan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkubik at redhat.com Wed May 6 14:28:38 2015 From: mkubik at redhat.com (Milan Kubik) Date: Wed, 06 May 2015 16:28:38 +0200 Subject: [Freeipa-devel] [PATCH] 807 webui-ci: do not open 2 browser windows In-Reply-To: <54E5F88D.5030800@redhat.com> References: <54E5F88D.5030800@redhat.com> Message-ID: <554A2516.7020109@redhat.com> On 02/19/2015 03:51 PM, Petr Vobornik wrote: > Only for master branch. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK Milan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ofayans at redhat.com Wed May 6 14:47:16 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 06 May 2015 16:47:16 +0200 Subject: [Freeipa-devel] Replication Topology design feedback In-Reply-To: <55478654.3080906@redhat.com> References: <55422CAF.4050403@redhat.com> <5547802E.1040000@redhat.com> <55478654.3080906@redhat.com> Message-ID: <554A2974.3000203@redhat.com> Hi Ludwig, I have a question. What is the proper way of removing ipa replica from the server that is replication-topology-aware? Standard way `ipa-replica-manage del` does not work anymore, since the topology is controlled by the plugin, but I was unable to remove it using topology-aware tools as well. Here is the transcript of my session: http://pastebin.test.redhat.com/281213 Thanks in advance! On 05/04/2015 04:46 PM, Martin Kosek wrote: > Thanks for answers. > > BTW, for future, I think Oleg that it would be useful to ask this questions on > freeipa-devel directly as it may be helpful to other developers and we would > have it archived for other uses. > > On 05/04/2015 04:20 PM, Ludwig Krispenz wrote: >> On 04/30/2015 03:22 PM, Oleg Fayans wrote: >>> Hi Ludwig, >>> >>> While getting myself familiar with Replication Topology Plugin design >>> page I've found a number of places that need some clarifications. >>> >>> 1. >>>> Check at startup. >>>> When the directory server starts, the plugin init and start functions >>> are executed, they will read the domain level >>>> attribute and act accordingly >>> Could you describe how exactly should the plugin work depending on the >>> domain level revealed. >> there are only two scenarios: >> 1] domain_level < plugin_level: >> the plugin does almost nothing, reading its config and waiting for a dom level >> increase >> 2] doamin_level >= plugin_level: >> the plugin controls topology for managed servers, rejecting direct mods of >> replication agreements, transforming adding/deleting/modification of segments >> into corresponding actions on replication agreements >>> 2. >>>> Check for modify operation >>>> If an admin or tool changes the domain level the plugin detects this >>> change and performs initialization tasks if the >>>> domain level is greater than the plugin version >>> The same here: what exactly happens after the domain level has changed. >> if the domain level raises, so that teh plugin becomes active, this will happen >> on all servers since domain level is replicated. >> the plugin will read all the exisu?ing info inthe shared tree, read all >> replication configuration and match them creating missing data in both areas: >> cn=config and shared tree >>> 3. Regarding the startup delay. How can I make sure the plugin has started? >>> As far as I understood the Topology plugin needs to be started only >>> after all other plugins are started to prevent it from making a tree >>> changes before it is able to be replicated. The question is: how do I >>> check whether all other plugins are already started? >> the plugin should be started when the server starts, it will expose this in the >> root dse and you can search for it, I just updated teh design page with an example >>> 4. Shared configuration layout >>> It is written there, that the replication topology information can be >>> configured to be stored in the custom place of the tree. How do we do that? >> The configuration is in the plugin conf in cn=config. At the moment it is >> populated when a DS instance is created. >> >>> Most probably I''ll have some more questions once I have the branch >>> installed. >>> >>> Thank you! >>> -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mbasti at redhat.com Wed May 6 14:49:55 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 06 May 2015 16:49:55 +0200 Subject: [Freeipa-devel] [PATCH] 814-818 migrate-ds: optimize adding users to default group In-Reply-To: <55488687.9070407@redhat.com> References: <5527AC09.7060707@redhat.com> <554233E4.5040608@redhat.com> <55488687.9070407@redhat.com> Message-ID: <554A2A13.7030005@redhat.com> On 05/05/15 10:59, Petr Vobornik wrote: > On 04/30/2015 03:53 PM, Martin Basti wrote: >> On 10/04/15 12:55, Petr Vobornik wrote: >>> The essential patch is 814. >>> >>> 815 a proposal for new option. >>> >>> 816 and 818 are cleanup patches. >>> >>> 817 little optimization. >>> >>> == [PATCH] 814 migrate-ds: optimize adding users to default group == >>> Migrate-ds searches for user without a group and adds them to default >>> group. There is no point in checking if the user's selected by >>> previous query are not member of default group because they are not >>> member of any group. >>> >>> The operation is also speeded up by not fetching the default group. >>> Users are added right away. >>> >>> https://fedorahosted.org/freeipa/ticket/4950 >>> >> NACK >> >> Users haven't been added into ipa default group after migration. > > Fixed in patch 815. > >> >> Just nitpick >> >> 1) too many parentheses >> api.log.error(('Adding new members to default group failed: >> %s \n' >> 'members: %s') % (e, >> (','.join(member_dns)))) >> You can use this instead: >> api.log.error('Adding new members to default group failed: >> %s \n' >> 'members: %s', e, ','.join(member_dns)) > > Fixed. > >> >> == [PATCH] 815 migrate-ds: skip default group options == >>> New option --use-default-group=False could be used to disable adding of >>> migrated users into default group. >>> >>> By default, the default group is no longer POSIX therefore it doesn't >>> fulfill the original idea of providing GID and therefore it could be >>> skipped during migration. >> LGTM > > the option got so the default would be applied. > + autofill=True, > > >>> >>> == [PATCH] 816 migrate-ds: remove unused def_group_gid context >>> property == >>> it's no longer used anywhere >>> >> 1) >> You can remove the unused variable 'g_attrs' > > removed > >>> == [PATCH] 817 migrate-ds: optimize gid checks by utilizing dictionary >>> nature of set == >>> >> LGTM >>> == [PATCH] 818 migrate-ds: log migrated group members only on debug >>> level == >>> It pollutes error_log. >>> >> 1) >> you do not need % formatting in logger >> api.log.debug('migrating %s group %s' , member_attr, m) > > fixed and also changed "migrating %s user %s'" line to debug, which > was the actual reason for this patch. > >>> >>> >> >> Martin^2 >> > > Thanks. 1) Please create new API file, probably missing autofill in API.txt: Option 'use_def_group?' in command 'migrate_ds' in API file not found Options count in migrate_ds of 18 doesn't match expected: 19 Option use_def_group? of command migrate_ds in ipalib, not in API file: Bool('use_def_group?', autofill=True, cli_name='use_default_group', default=True) There are one or more changes to the API. Either undo the API changes or update API.txt and increment the major version in VERSION. 2) ipa: error: --use-default-group option does not take a value and a nitpick: patch 814 1) Why this change? - api.log.debug('Adding %d users to group%s duration %s', - len(new_members), mode, d) + api.log.info('Adding %d users to group%s duration %s', + len(member_dns), mode, d) -- Martin Basti From dkupka at redhat.com Wed May 6 14:54:24 2015 From: dkupka at redhat.com (David Kupka) Date: Wed, 06 May 2015 16:54:24 +0200 Subject: [Freeipa-devel] [PATCH 0322-0337] Fix mysterious failures in PTR record synchronization In-Reply-To: <5548E0AB.8090600@redhat.com> References: <5548E0AB.8090600@redhat.com> Message-ID: <554A2B20.6060908@redhat.com> On 05/05/2015 05:24 PM, Petr Spacek wrote: > Hello, > > Attached patch set is the best fix for > https://fedorahosted.org/bind-dyndb-ldap/ticket/155 > I was able to write. > > This patch set should fix vast majority of race conditions. Unfortunately it > cannot be 100 % reliable without support for LDAP transactions. > > For convenience you can download the whole tree from > https://github.com/pspacek/bind-dyndb-ldap/commits/t155.syncptr > HEAD = da2552632f6ce67f1bb9d9b3cdd3e0a8e06ce9ea > > Enjoy. > Hi, thanks for the patch set. I tested only a functionality because I really don't know the code base of bind nor bind-dyndb-ldap. To test the patch set I used ipa-client-install with patch freeipa-dkupka-0035-6. DNS server does not return an error unless creation/update of record that I requested has failed. This is exactly the behavior I expect, thanks. -- David Kupka From lkrispen at redhat.com Wed May 6 15:00:52 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 06 May 2015 17:00:52 +0200 Subject: [Freeipa-devel] Replication Topology design feedback In-Reply-To: <554A2974.3000203@redhat.com> References: <55422CAF.4050403@redhat.com> <5547802E.1040000@redhat.com> <55478654.3080906@redhat.com> <554A2974.3000203@redhat.com> Message-ID: <554A2CA4.2070806@redhat.com> hi, you have to remove the server from the manged servers, ipa-replica-manage del would do it, but it fails in line:13 "not allowed on leaf entry" This is a bug I reported today. In my tests I did use a script to delete a master and its services (before). Tomas has proposed a fix, which should allow ipa-replica-manage del succeed. What is interesting in your log is line:7, it contains a corrpted ruv, and we have been trying to reproduce this, but did fail so far. Could you provide me a full log of actvities you have don in this test scenario ? Regards, Ludwig On 05/06/2015 04:47 PM, Oleg Fayans wrote: > Hi Ludwig, > > I have a question. What is the proper way of removing ipa replica from > the server that is replication-topology-aware? Standard way > `ipa-replica-manage del` does not work anymore, since the topology is > controlled by the plugin, but I was unable to remove it using > topology-aware tools as well. Here is the transcript of my session: > http://pastebin.test.redhat.com/281213 > > Thanks in advance! > > > On 05/04/2015 04:46 PM, Martin Kosek wrote: >> Thanks for answers. >> >> BTW, for future, I think Oleg that it would be useful to ask this questions on >> freeipa-devel directly as it may be helpful to other developers and we would >> have it archived for other uses. >> >> On 05/04/2015 04:20 PM, Ludwig Krispenz wrote: >>> On 04/30/2015 03:22 PM, Oleg Fayans wrote: >>>> Hi Ludwig, >>>> >>>> While getting myself familiar with Replication Topology Plugin design >>>> page I've found a number of places that need some clarifications. >>>> >>>> 1. >>>>> Check at startup. >>>>> When the directory server starts, the plugin init and start functions >>>> are executed, they will read the domain level >>>>> attribute and act accordingly >>>> Could you describe how exactly should the plugin work depending on the >>>> domain level revealed. >>> there are only two scenarios: >>> 1] domain_level < plugin_level: >>> the plugin does almost nothing, reading its config and waiting for a dom level >>> increase >>> 2] doamin_level >= plugin_level: >>> the plugin controls topology for managed servers, rejecting direct mods of >>> replication agreements, transforming adding/deleting/modification of segments >>> into corresponding actions on replication agreements >>>> 2. >>>>> Check for modify operation >>>>> If an admin or tool changes the domain level the plugin detects this >>>> change and performs initialization tasks if the >>>>> domain level is greater than the plugin version >>>> The same here: what exactly happens after the domain level has changed. >>> if the domain level raises, so that teh plugin becomes active, this will happen >>> on all servers since domain level is replicated. >>> the plugin will read all the exisu?ing info inthe shared tree, read all >>> replication configuration and match them creating missing data in both areas: >>> cn=config and shared tree >>>> 3. Regarding the startup delay. How can I make sure the plugin has started? >>>> As far as I understood the Topology plugin needs to be started only >>>> after all other plugins are started to prevent it from making a tree >>>> changes before it is able to be replicated. The question is: how do I >>>> check whether all other plugins are already started? >>> the plugin should be started when the server starts, it will expose this in the >>> root dse and you can search for it, I just updated teh design page with an example >>>> 4. Shared configuration layout >>>> It is written there, that the replication topology information can be >>>> configured to be stored in the custom place of the tree. How do we do that? >>> The configuration is in the plugin conf in cn=config. At the moment it is >>> populated when a DS instance is created. >>> >>>> Most probably I''ll have some more questions once I have the branch >>>> installed. >>>> >>>> Thank you! >>>> From mbabinsk at redhat.com Wed May 6 15:56:45 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 06 May 2015 17:56:45 +0200 Subject: [Freeipa-devel] [PATCH 0032] prevent duplicate IDs when setting up multiple replicas against single master In-Reply-To: <554A245F.4060507@redhat.com> References: <554A00FB.60205@redhat.com> <554A0768.9000107@redhat.com> <554A14C9.90605@redhat.com> <554A245F.4060507@redhat.com> Message-ID: <554A39BD.5060609@redhat.com> On 05/06/2015 04:25 PM, thierry bordaz wrote: > On 05/06/2015 03:19 PM, Martin Babinsky wrote: >> Hello Thierry, >> >> replies are inline. >> >> On 05/06/2015 02:22 PM, thierry bordaz wrote: >>> On 05/06/2015 01:54 PM, Martin Babinsky wrote: >>>> The attached patch tries to fix >>>> https://fedorahosted.org/freeipa/ticket/4378 >>>> >>>> After discussion with Thierry we concluded that while this issue is >>>> more complex than it seems, the transition from REPLACE to DEL/ADD >>>> operations when updating nsDS5ReplicaId should suffice for this ticket. >>>> >>> Hello Martin, >>> >>> Few comments, you are using MOD_DEL 'replicaID' with None value. So this >>> is going to delete all previous values and it should be equivalent to a >>> MOD_REPL. >>> I was thinking you wanted to retrieve the id_value and call MOD_DEL >>> 'replicaID' . So that if by the time you fetched the >>> replicaId, an other replica updated the replicaId, the MOD_DEL/MOD_ADD >>> would fail and you need a new iteration. >>> >> Sorry I didn't know you can MOD_DEL a particular value (I'm LDAP noob >> I know). Will fix this. >>> If replicaId was multi-valued and you want to make it single valued, you >>> may want to do create a more complex MOD (e.g. (ldap.MOD_DELETE, >>> 'nsDS5ReplicaId', str(value1), (ldap.MOD_DELETE, 'nsDS5ReplicaId', >>> str(value2)...) >>> >> AFAIK ReplicaId is single-valued (looking at the schema right now) so >> this shouldn't be problem. >>> If it is updating successfully do you want to return 'retval' or >>> 'retval+1' ? >>> >>> If several replicas try to update the replicaId of the master and the >>> current replicaId is 1000. >>> Replica1 successfully updates the replicaId and gets 1001 as the new >>> value. >>> Replica2 successfully updates the replicaId and gets 1002. >>> The final value on master will be 1002, but replica1 will assum it is >>> 1001. Is it a problem ? >>> >> I studied the code in the master branch and IIUC (and please correct >> me if I got this wrong) nsDS5ReplicaId attribute in >> 'cn=replication,cn=etc,$SUFFIX' represents replicaID of the _next_ >> replica that will be installed. >> >> So if a replica is installed, it sets the current value of >> nsDS5ReplicaId as its replica ID (the function returns 'retval') and >> then increments it in 'cn=replication,cn=etc,$SUFFIX' entry ('retval + >> 1' is written to master) so that the next installed replica fetches >> this updated value. >> >> So the case you described should be the expected behavior. To change >> it would require different patch IMHO. > > Thank for your precious explanations, in fact the value in > 'cn=replication,cn=etc,SUFFIX' is the next available replicaId value and > is the centralized mechanism that assign unique replicaID. > > The risk was that several replica pick the same value. So yes it is > important that the MOD_DEL specifies the previously read value so that > the test/set will be atomic. If several replicas read the same value, > only the faster one will use it to install the replica. > > thanks > thierry >>> thanks >>> thierry >> >> > Attaching updated patch with fixed MOD_DELETE operation. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0032.1-prevent-duplicate-IDs-when-setting-up-multiple-repli.patch Type: text/x-patch Size: 5152 bytes Desc: not available URL: From tbordaz at redhat.com Wed May 6 17:41:57 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 06 May 2015 19:41:57 +0200 Subject: [Freeipa-devel] [PATCH 0032] prevent duplicate IDs when setting up multiple replicas against single master In-Reply-To: <554A39BD.5060609@redhat.com> References: <554A00FB.60205@redhat.com> <554A0768.9000107@redhat.com> <554A14C9.90605@redhat.com> <554A245F.4060507@redhat.com> <554A39BD.5060609@redhat.com> Message-ID: <554A5265.3010101@redhat.com> On 05/06/2015 05:56 PM, Martin Babinsky wrote: > On 05/06/2015 04:25 PM, thierry bordaz wrote: >> On 05/06/2015 03:19 PM, Martin Babinsky wrote: >>> Hello Thierry, >>> >>> replies are inline. >>> >>> On 05/06/2015 02:22 PM, thierry bordaz wrote: >>>> On 05/06/2015 01:54 PM, Martin Babinsky wrote: >>>>> The attached patch tries to fix >>>>> https://fedorahosted.org/freeipa/ticket/4378 >>>>> >>>>> After discussion with Thierry we concluded that while this issue is >>>>> more complex than it seems, the transition from REPLACE to DEL/ADD >>>>> operations when updating nsDS5ReplicaId should suffice for this >>>>> ticket. >>>>> >>>> Hello Martin, >>>> >>>> Few comments, you are using MOD_DEL 'replicaID' with None value. So >>>> this >>>> is going to delete all previous values and it should be equivalent >>>> to a >>>> MOD_REPL. >>>> I was thinking you wanted to retrieve the id_value and call MOD_DEL >>>> 'replicaID' . So that if by the time you fetched the >>>> replicaId, an other replica updated the replicaId, the MOD_DEL/MOD_ADD >>>> would fail and you need a new iteration. >>>> >>> Sorry I didn't know you can MOD_DEL a particular value (I'm LDAP noob >>> I know). Will fix this. >>>> If replicaId was multi-valued and you want to make it single >>>> valued, you >>>> may want to do create a more complex MOD (e.g. (ldap.MOD_DELETE, >>>> 'nsDS5ReplicaId', str(value1), (ldap.MOD_DELETE, 'nsDS5ReplicaId', >>>> str(value2)...) >>>> >>> AFAIK ReplicaId is single-valued (looking at the schema right now) so >>> this shouldn't be problem. >>>> If it is updating successfully do you want to return 'retval' or >>>> 'retval+1' ? >>>> >>>> If several replicas try to update the replicaId of the master and the >>>> current replicaId is 1000. >>>> Replica1 successfully updates the replicaId and gets 1001 as the new >>>> value. >>>> Replica2 successfully updates the replicaId and gets 1002. >>>> The final value on master will be 1002, but replica1 will assum it is >>>> 1001. Is it a problem ? >>>> >>> I studied the code in the master branch and IIUC (and please correct >>> me if I got this wrong) nsDS5ReplicaId attribute in >>> 'cn=replication,cn=etc,$SUFFIX' represents replicaID of the _next_ >>> replica that will be installed. >>> >>> So if a replica is installed, it sets the current value of >>> nsDS5ReplicaId as its replica ID (the function returns 'retval') and >>> then increments it in 'cn=replication,cn=etc,$SUFFIX' entry ('retval + >>> 1' is written to master) so that the next installed replica fetches >>> this updated value. >>> >>> So the case you described should be the expected behavior. To change >>> it would require different patch IMHO. >> >> Thank for your precious explanations, in fact the value in >> 'cn=replication,cn=etc,SUFFIX' is the next available replicaId value and >> is the centralized mechanism that assign unique replicaID. >> >> The risk was that several replica pick the same value. So yes it is >> important that the MOD_DEL specifies the previously read value so that >> the test/set will be atomic. If several replicas read the same value, >> only the faster one will use it to install the replica. >> >> thanks >> thierry >>>> thanks >>>> thierry >>> >>> >> > > Attaching updated patch with fixed MOD_DELETE operation. > Hi Martin, The fix looks good to me except I think you need to do (ldap.MOD_DELETE, 'nsDS5ReplicaId', *str(*retval*)*) thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkupka at redhat.com Thu May 7 06:59:53 2015 From: dkupka at redhat.com (David Kupka) Date: Thu, 07 May 2015 08:59:53 +0200 Subject: [Freeipa-devel] [PATCHES 0233-0234] DNSSEC: forwarders validation In-Reply-To: <554A1539.3040002@redhat.com> References: <553A3D88.6080200@redhat.com> <55423032.9080505@redhat.com> <5548BED1.1060806@redhat.com> <554A1539.3040002@redhat.com> Message-ID: <554B0D69.5040008@redhat.com> On 05/06/2015 03:20 PM, Martin Basti wrote: > On 05/05/15 15:00, Martin Basti wrote: >> On 30/04/15 15:37, David Kupka wrote: >>> On 04/24/2015 02:56 PM, Martin Basti wrote: >>>> Patches attached. >>>> >>>> >>>> >>>> >>> Hi, >>> thanks for patches. >>> >>> 1. You changed message in DNSServerNotRespondingWarning class but not >>> the test in ipatest/test_xmlrpc/test_dns_plugin.py >>> >>> nitpick. Please spell 'edns' correctly. I've seen several instances >>> of 'ends'. >>> >> Thank you, >> >> updated patches attached: >> * new error messages >> * logging to debug log server output if exception was raised >> * fixed test >> * fixed spelling >> >> >> > Fixed tests (again) > > Updated patches attached > The code looks good to me and tests are no longer broken. (I would prefer better fix of the tests but given that the priorities are different now it can wait.) Petr, can you please confirm that the patch set works for you? -- David Kupka From dkupka at redhat.com Thu May 7 08:04:46 2015 From: dkupka at redhat.com (David Kupka) Date: Thu, 07 May 2015 10:04:46 +0200 Subject: [Freeipa-devel] [PATCH] 381 Fix stop_tracking_certificates call in ipa-restore In-Reply-To: <547ED698.8080201@redhat.com> References: <547ED698.8080201@redhat.com> Message-ID: <554B1C9E.3060509@redhat.com> On 12/03/2014 10:23 AM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Hi, thanks for patch (with 5 months delay :-) The patch needs a trivial rebase but otherwise works for me and is needed for ipa-restore to work. -- David Kupka From jcholast at redhat.com Thu May 7 08:11:03 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 07 May 2015 10:11:03 +0200 Subject: [Freeipa-devel] [PATCH] 381 Fix stop_tracking_certificates call in ipa-restore In-Reply-To: <554B1C9E.3060509@redhat.com> References: <547ED698.8080201@redhat.com> <554B1C9E.3060509@redhat.com> Message-ID: <554B1E17.90004@redhat.com> Dne 7.5.2015 v 10:04 David Kupka napsal(a): > On 12/03/2014 10:23 AM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > Hi, > thanks for patch (with 5 months delay :-) The patch needs a trivial > rebase but otherwise works for me and is needed for ipa-restore to work. > Here you go. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-381.1-Fix-stop_tracking_certificates-call-in-ipa-restore.patch Type: text/x-patch Size: 1394 bytes Desc: not available URL: From dkupka at redhat.com Thu May 7 08:21:27 2015 From: dkupka at redhat.com (David Kupka) Date: Thu, 07 May 2015 10:21:27 +0200 Subject: [Freeipa-devel] [PATCH] 381 Fix stop_tracking_certificates call in ipa-restore In-Reply-To: <554B1E17.90004@redhat.com> References: <547ED698.8080201@redhat.com> <554B1C9E.3060509@redhat.com> <554B1E17.90004@redhat.com> Message-ID: <554B2087.70201@redhat.com> On 05/07/2015 10:11 AM, Jan Cholasta wrote: > Dne 7.5.2015 v 10:04 David Kupka napsal(a): >> On 12/03/2014 10:23 AM, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patch fixes . >>> >>> Honza >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >> Hi, >> thanks for patch (with 5 months delay :-) The patch needs a trivial >> rebase but otherwise works for me and is needed for ipa-restore to work. >> > > Here you go. > ACK. -- David Kupka From jcholast at redhat.com Thu May 7 08:30:06 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 07 May 2015 10:30:06 +0200 Subject: [Freeipa-devel] [PATCH] 381 Fix stop_tracking_certificates call in ipa-restore In-Reply-To: <554B2087.70201@redhat.com> References: <547ED698.8080201@redhat.com> <554B1C9E.3060509@redhat.com> <554B1E17.90004@redhat.com> <554B2087.70201@redhat.com> Message-ID: <554B228E.8010102@redhat.com> Dne 7.5.2015 v 10:21 David Kupka napsal(a): > On 05/07/2015 10:11 AM, Jan Cholasta wrote: >> Dne 7.5.2015 v 10:04 David Kupka napsal(a): >>> On 12/03/2014 10:23 AM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> the attached patch fixes >>>> . >>>> >>>> Honza >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>> Hi, >>> thanks for patch (with 5 months delay :-) The patch needs a trivial >>> rebase but otherwise works for me and is needed for ipa-restore to work. >>> >> >> Here you go. >> > ACK. > Pushed to master: 37784625eba7d9f7f3cbd18483708a45ece3061e -- Jan Cholasta From pvoborni at redhat.com Thu May 7 08:40:32 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 07 May 2015 10:40:32 +0200 Subject: [Freeipa-devel] [PATCH 0047] Unsaved changes dialog inconsistent In-Reply-To: References: <553E593B.7040505@redhat.com> <252255323.10008954.1430315967619.JavaMail.zimbra@redhat.com> <5548A653.2030903@redhat.com> Message-ID: <554B2500.5010606@redhat.com> On 05/05/2015 02:36 PM, Gabe Alford wrote: > Thanks Petr. I thought I had grepped all that out. Guess I didn't do it > from the top of the tree. > > Updated patch attached. ACK Pushed to: master: d1a0474d1851cd54a1fa7bdf4a0dc0ed452a0090 ipa-4-1: 5ac5564227757dfc367ca74fe86e99114d5b582b > > On Tue, May 5, 2015 at 5:15 AM, Petr Vobornik wrote: > >> On 04/30/2015 07:43 PM, Gabe Alford wrote: >> >>> Thanks Kyle and Petr. >>> >>> Update patch attached. >>> >> >> Renaming the buttons also requires to update webui integration tests in >> ipatests/test_webui, quick search: >> ipatests/test_webui/test_realmdomains.py:42,48 >> ipatests/test_webui/ui_driver.py:1221,1246,1464,1483 >> >> >> >> >>> On Wed, Apr 29, 2015 at 7:59 AM, Kyle Baker wrote: >>> >>> >>>> ----- Original Message ----- >>>> >>>>> On 04/27/2015 03:03 PM, Gabe Alford wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> Fix for https://fedorahosted.org/freeipa/ticket/4926 >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Gabe >>>>>> >>>>>> >>>>> PatternFly has new recommendations for terminology and wording [1]. I'm >>>>> not entirely sure if the usage of 'save' here is good. PF defines 'edit' >>>>> as the recommended term. The page doesn't say if 'save' is not >>>>> recommended, though. Save seems to me as a confirmation of editing. >>>>> >>>> >>>> Yes I think save would be best here based on the message given. >>>> >>>> Thanks for checking out the Terminology screen! >>>> >>>> >>>>> Kyle, could you advise what is the best term for reflecting user changes >>>>> and for confirmation of this action? >>>>> >>>>> Technical notes: >>>>> 1. it would be better to add a new string and then use it in the button >>>>> instead of having 'Save' text for '@i18n:buttons.update' definition. >>>>> >>>>> 2. String changes in internal.py should be also reflected in >>>>> install/ui/test/data/ipa_init.json (for static web ui demo). >>>>> >>>>> 3. optional: in addition to text change, buttons and related actions >>>>> could also be renamed (same reasons as in 1). It's more proper but much >>>>> more complicated. >>>>> >>>>> >>>>> [1] >>>>> >>>> https://www.patternfly.org/styles/terminology-and-wording/#action-labels >>>> >>>>> -- >>>>> Petr Vobornik >>>>> >>>>> >>>> >>> >> >> -- >> Petr Vobornik >> > -- Petr Vobornik From pvoborni at redhat.com Thu May 7 08:43:58 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 07 May 2015 10:43:58 +0200 Subject: [Freeipa-devel] [PATCH] 821 webui: add pwpolicy link to group details page if group has associated pwpolicy In-Reply-To: <554218C1.7090108@redhat.com> References: <55312D8E.8020400@redhat.com> <554218C1.7090108@redhat.com> Message-ID: <554B25CE.8070302@redhat.com> On 04/30/2015 01:57 PM, Martin Babinsky wrote: > On 04/17/2015 05:58 PM, Petr Vobornik wrote: >> https://fedorahosted.org/freeipa/ticket/4982 >> >> > ACK > Pushed to master: b61f4bc538573fcf76c69b52698045dcb0f99e55 -- Petr Vobornik From pvoborni at redhat.com Thu May 7 08:46:16 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 07 May 2015 10:46:16 +0200 Subject: [Freeipa-devel] [PATCH] 807 webui-ci: do not open 2 browser windows In-Reply-To: <554A2516.7020109@redhat.com> References: <54E5F88D.5030800@redhat.com> <554A2516.7020109@redhat.com> Message-ID: <554B2658.8070401@redhat.com> On 05/06/2015 04:28 PM, Milan Kubik wrote: > On 02/19/2015 03:51 PM, Petr Vobornik wrote: >> Only for master branch. >> > ACK > > Milan > Pushed to master: a1ccdc33dfc5de3480b9ad407f4a95d01258008d -- Petr Vobornik From mbasti at redhat.com Thu May 7 09:09:43 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 07 May 2015 11:09:43 +0200 Subject: [Freeipa-devel] [PATCHES 0231-0232] Server Upgrade: support base64 encoded values in update files + remove CSV In-Reply-To: <5549F857.2060008@redhat.com> References: <552FD1C0.2040104@redhat.com> <5538D21A.8040000@redhat.com> <553E1802.8050409@redhat.com> <553E4BD7.4010707@redhat.com> <55409129.8020606@redhat.com> <5549F857.2060008@redhat.com> Message-ID: <554B2BD7.2020300@redhat.com> On 06/05/15 13:17, Martin Basti wrote: > On 29/04/15 10:07, Jan Cholasta wrote: >> Dne 27.4.2015 v 16:46 Martin Basti napsal(a): >>> On 27/04/15 13:05, Martin Basti wrote: >>>> On 23/04/15 13:06, Martin Basti wrote: >>>>> On 16/04/15 17:14, Martin Basti wrote: >>>>>> https://fedorahosted.org/freeipa/ticket/4984 >>>>>> >>>>>> I had to remove CSV (which is evil) to be able fix this ticket. >>>>>> >>>>>> Patches attached. >>>>>> >>>>>> >>>>>> >>>>> Updated patches attached. >>>>> >>>>> -- >>>>> Martin Basti >>>>> >>>>> >>>> Rebased patches attached. >>>> >>>> -- >>>> Martin Basti >>>> >>>> >>> rebased patches attached >>> >>> -- >>> Martin Basti >>> >>> >>> >> >> ACK on patch 231. >> >> BTW I have found a 7 year old bug caused by CSV while reviewing it: >> . >> >> There is also similar git-only bug in >> install/updates/10-uniqueness.update: >> >> default:uniqueness-subtrees: 'cn=accounts,$SUFFIX' >> default:uniqueness-subtrees: 'cn=deleted >> users,cn=accounts,cn=provisioning,$SUFFIX' >> >> but your patch fixes it. >> >> I will review patch 232 later. >> >> Honza >> > Honza doesn't like original 232 so much. > > Updated patch 232 attached > > > Updated patch 232 attached -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0231.4-Server-Upgrade-remove-CSV-from-upgrade-files.patch Type: text/x-patch Size: 127820 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0232.6-Server-Upgrade-Allow-base64-encoded-values.patch Type: text/x-patch Size: 7696 bytes Desc: not available URL: From pspacek at redhat.com Thu May 7 10:19:05 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 07 May 2015 12:19:05 +0200 Subject: [Freeipa-devel] [PATCHES 0233-0234] DNSSEC: forwarders validation In-Reply-To: <554B0D69.5040008@redhat.com> References: <553A3D88.6080200@redhat.com> <55423032.9080505@redhat.com> <5548BED1.1060806@redhat.com> <554A1539.3040002@redhat.com> <554B0D69.5040008@redhat.com> Message-ID: <554B3C19.9080002@redhat.com> On 7.5.2015 08:59, David Kupka wrote: > On 05/06/2015 03:20 PM, Martin Basti wrote: >> On 05/05/15 15:00, Martin Basti wrote: >>> On 30/04/15 15:37, David Kupka wrote: >>>> On 04/24/2015 02:56 PM, Martin Basti wrote: >>>>> Patches attached. >>>>> >>>>> >>>>> >>>>> >>>> Hi, >>>> thanks for patches. >>>> >>>> 1. You changed message in DNSServerNotRespondingWarning class but not >>>> the test in ipatest/test_xmlrpc/test_dns_plugin.py >>>> >>>> nitpick. Please spell 'edns' correctly. I've seen several instances >>>> of 'ends'. >>>> >>> Thank you, >>> >>> updated patches attached: >>> * new error messages >>> * logging to debug log server output if exception was raised >>> * fixed test >>> * fixed spelling >>> >>> >>> >> Fixed tests (again) >> >> Updated patches attached >> > The code looks good to me and tests are no longer broken. (I would prefer > better fix of the tests but given that the priorities are different now it can > wait.) > > Petr, can you please confirm that the patch set works for you? Sorry, NACK: $ ipa dnsforwardzone-add ptr.test. --forwarder=10.34.47.236 Server will check DNS forwarder(s). This may take some time, please wait ... ipa: ERROR: an internal error has occurred # /var/log/httpd/error_log ipa: ERROR: non-public: AssertionError: Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 350, in wsgi_execute result = self.Command[name](*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 443, in __call__ ret = self.run(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 760, in run return self.execute(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 4444, in execute **options) File "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 4405, in _warning_if_forwarders_do_not_work log=self.log) File "/usr/lib/python2.7/site-packages/ipalib/util.py", line 715, in validate_dnssec_zone_forwarder_step2 timeout=timeout) File "/usr/lib/python2.7/site-packages/ipalib/util.py", line 610, in _resolve_record assert isinstance(nameserver_ip, basestring) AssertionError ipa: INFO: [jsonserver_session] admin at IPA.EXAMPLE: dnsforwardzone_add(, idnsforwarders=(u'10.34.47.236',), all=False, raw=False, version=u'2.116'): AssertionError This is constantly reproducible in my vm-090.abc. Let me know if you want to take a look. I'm attaching little response.patch which improves compatibility with older python-dns packages. This patch allows IPA to work while error messages are simply not as nice as they could be with latest python-dns :-) check_fwd_msg.patch is a little nitpick, just to make sure everyone understands the message. BTW why some messages in check_forwarders() are printed using 'print' and others using logger? I would prefer to use logger for everything to make sure that logs contain all the information, including warnings. Thank you for your time! -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: response.patch Type: text/x-patch Size: 415 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: check_fwd_msg.patch Type: text/x-patch Size: 611 bytes Desc: not available URL: From mbabinsk at redhat.com Thu May 7 11:05:57 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 07 May 2015 13:05:57 +0200 Subject: [Freeipa-devel] [PATCH 0032] prevent duplicate IDs when setting up multiple replicas against single master In-Reply-To: <554A5265.3010101@redhat.com> References: <554A00FB.60205@redhat.com> <554A0768.9000107@redhat.com> <554A14C9.90605@redhat.com> <554A245F.4060507@redhat.com> <554A39BD.5060609@redhat.com> <554A5265.3010101@redhat.com> Message-ID: <554B4715.7090408@redhat.com> On 05/06/2015 07:41 PM, thierry bordaz wrote: > On 05/06/2015 05:56 PM, Martin Babinsky wrote: >> On 05/06/2015 04:25 PM, thierry bordaz wrote: >>> On 05/06/2015 03:19 PM, Martin Babinsky wrote: >>>> Hello Thierry, >>>> >>>> replies are inline. >>>> >>>> On 05/06/2015 02:22 PM, thierry bordaz wrote: >>>>> On 05/06/2015 01:54 PM, Martin Babinsky wrote: >>>>>> The attached patch tries to fix >>>>>> https://fedorahosted.org/freeipa/ticket/4378 >>>>>> >>>>>> After discussion with Thierry we concluded that while this issue is >>>>>> more complex than it seems, the transition from REPLACE to DEL/ADD >>>>>> operations when updating nsDS5ReplicaId should suffice for this >>>>>> ticket. >>>>>> >>>>> Hello Martin, >>>>> >>>>> Few comments, you are using MOD_DEL 'replicaID' with None value. So >>>>> this >>>>> is going to delete all previous values and it should be equivalent >>>>> to a >>>>> MOD_REPL. >>>>> I was thinking you wanted to retrieve the id_value and call MOD_DEL >>>>> 'replicaID' . So that if by the time you fetched the >>>>> replicaId, an other replica updated the replicaId, the MOD_DEL/MOD_ADD >>>>> would fail and you need a new iteration. >>>>> >>>> Sorry I didn't know you can MOD_DEL a particular value (I'm LDAP noob >>>> I know). Will fix this. >>>>> If replicaId was multi-valued and you want to make it single >>>>> valued, you >>>>> may want to do create a more complex MOD (e.g. (ldap.MOD_DELETE, >>>>> 'nsDS5ReplicaId', str(value1), (ldap.MOD_DELETE, 'nsDS5ReplicaId', >>>>> str(value2)...) >>>>> >>>> AFAIK ReplicaId is single-valued (looking at the schema right now) so >>>> this shouldn't be problem. >>>>> If it is updating successfully do you want to return 'retval' or >>>>> 'retval+1' ? >>>>> >>>>> If several replicas try to update the replicaId of the master and the >>>>> current replicaId is 1000. >>>>> Replica1 successfully updates the replicaId and gets 1001 as the new >>>>> value. >>>>> Replica2 successfully updates the replicaId and gets 1002. >>>>> The final value on master will be 1002, but replica1 will assum it is >>>>> 1001. Is it a problem ? >>>>> >>>> I studied the code in the master branch and IIUC (and please correct >>>> me if I got this wrong) nsDS5ReplicaId attribute in >>>> 'cn=replication,cn=etc,$SUFFIX' represents replicaID of the _next_ >>>> replica that will be installed. >>>> >>>> So if a replica is installed, it sets the current value of >>>> nsDS5ReplicaId as its replica ID (the function returns 'retval') and >>>> then increments it in 'cn=replication,cn=etc,$SUFFIX' entry ('retval + >>>> 1' is written to master) so that the next installed replica fetches >>>> this updated value. >>>> >>>> So the case you described should be the expected behavior. To change >>>> it would require different patch IMHO. >>> >>> Thank for your precious explanations, in fact the value in >>> 'cn=replication,cn=etc,SUFFIX' is the next available replicaId value and >>> is the centralized mechanism that assign unique replicaID. >>> >>> The risk was that several replica pick the same value. So yes it is >>> important that the MOD_DEL specifies the previously read value so that >>> the test/set will be atomic. If several replicas read the same value, >>> only the faster one will use it to install the replica. >>> >>> thanks >>> thierry >>>>> thanks >>>>> thierry >>>> >>>> >>> >> >> Attaching updated patch with fixed MOD_DELETE operation. >> > > Hi Martin, > > The fix looks good to me except I think you need to do (ldap.MOD_DELETE, > 'nsDS5ReplicaId', *str(*retval*)*) > > thanks > thierry Attaching updated patch. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0032.2-prevent-duplicate-IDs-when-setting-up-multiple-repli.patch Type: text/x-patch Size: 5157 bytes Desc: not available URL: From pvoborni at redhat.com Thu May 7 11:17:39 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 07 May 2015 13:17:39 +0200 Subject: [Freeipa-devel] [PATCH] 814-818 migrate-ds: optimize adding users to default group In-Reply-To: <554A2A13.7030005@redhat.com> References: <5527AC09.7060707@redhat.com> <554233E4.5040608@redhat.com> <55488687.9070407@redhat.com> <554A2A13.7030005@redhat.com> Message-ID: <554B49D3.5090901@redhat.com> On 05/06/2015 04:49 PM, Martin Basti wrote: > On 05/05/15 10:59, Petr Vobornik wrote: >> On 04/30/2015 03:53 PM, Martin Basti wrote: >>> On 10/04/15 12:55, Petr Vobornik wrote: >>>> The essential patch is 814. >>>> >>>> 815 a proposal for new option. >>>> >>>> 816 and 818 are cleanup patches. >>>> >>>> 817 little optimization. >>>> >>>> == [PATCH] 814 migrate-ds: optimize adding users to default group == >>>> Migrate-ds searches for user without a group and adds them to default >>>> group. There is no point in checking if the user's selected by >>>> previous query are not member of default group because they are not >>>> member of any group. >>>> >>>> The operation is also speeded up by not fetching the default group. >>>> Users are added right away. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4950 >>>> >>> NACK >>> >>> Users haven't been added into ipa default group after migration. >> >> Fixed in patch 815. >> >>> >>> Just nitpick >>> >>> 1) too many parentheses >>> api.log.error(('Adding new members to default group failed: >>> %s \n' >>> 'members: %s') % (e, >>> (','.join(member_dns)))) >>> You can use this instead: >>> api.log.error('Adding new members to default group failed: >>> %s \n' >>> 'members: %s', e, ','.join(member_dns)) >> >> Fixed. >> >>> >>> == [PATCH] 815 migrate-ds: skip default group options == >>>> New option --use-default-group=False could be used to disable adding of >>>> migrated users into default group. >>>> >>>> By default, the default group is no longer POSIX therefore it doesn't >>>> fulfill the original idea of providing GID and therefore it could be >>>> skipped during migration. >>> LGTM >> >> the option got so the default would be applied. >> + autofill=True, >> >> >>>> >>>> == [PATCH] 816 migrate-ds: remove unused def_group_gid context >>>> property == >>>> it's no longer used anywhere >>>> >>> 1) >>> You can remove the unused variable 'g_attrs' >> >> removed >> >>>> == [PATCH] 817 migrate-ds: optimize gid checks by utilizing dictionary >>>> nature of set == >>>> >>> LGTM >>>> == [PATCH] 818 migrate-ds: log migrated group members only on debug >>>> level == >>>> It pollutes error_log. >>>> >>> 1) >>> you do not need % formatting in logger >>> api.log.debug('migrating %s group %s' , member_attr, m) >> >> fixed and also changed "migrating %s user %s'" line to debug, which >> was the actual reason for this patch. >> >>>> >>>> >>> >>> Martin^2 >>> >> >> > Thanks. > > 1) > Please create new API file, probably missing autofill in API.txt: > > Option 'use_def_group?' in command 'migrate_ds' in API file not found > Options count in migrate_ds of 18 doesn't match expected: 19 > Option use_def_group? of command migrate_ds in ipalib, not in API file: > Bool('use_def_group?', autofill=True, cli_name='use_default_group', > default=True) > > There are one or more changes to the API. > Either undo the API changes or update API.txt and increment the major > version in VERSION. you could just wrote that I forgot to run ./makeapi ;) > > 2) > ipa: error: --use-default-group option does not take a value Attached new patch #826 which should fix the issue. Not sure if Honza(CCd) will like it. "(default: true)" added to option description for better UX. > > and a nitpick: > > patch 814 > 1) > Why this change? > > - api.log.debug('Adding %d users to group%s duration %s', > - len(new_members), mode, d) > + api.log.info('Adding %d users to group%s duration %s', > + len(member_dns), mode, d) So that there will be a record in a default(not debug) log that something happened. The reason is that it also affects users, without a group, that are already present on the system. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0818-2-migrate-ds-log-migrated-group-members-only-on-debug-.patch Type: text/x-patch Size: 1397 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0817-2-migrate-ds-optimize-gid-checks-by-utilizing-dictiona.patch Type: text/x-patch Size: 1877 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0816-2-migrate-ds-remove-unused-def_group_gid-context-prope.patch Type: text/x-patch Size: 1338 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0815-2-migrate-ds-skip-default-group-option.patch Type: text/x-patch Size: 5201 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0814-2-migrate-ds-optimize-adding-users-to-default-group.patch Type: text/x-patch Size: 2988 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0826-cli-differentiate-Flag-a-Bool-when-autofill-is-set.patch Type: text/x-patch Size: 1629 bytes Desc: not available URL: From tbordaz at redhat.com Thu May 7 11:28:38 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 07 May 2015 13:28:38 +0200 Subject: [Freeipa-devel] [PATCH 0032] prevent duplicate IDs when setting up multiple replicas against single master In-Reply-To: <554B4715.7090408@redhat.com> References: <554A00FB.60205@redhat.com> <554A0768.9000107@redhat.com> <554A14C9.90605@redhat.com> <554A245F.4060507@redhat.com> <554A39BD.5060609@redhat.com> <554A5265.3010101@redhat.com> <554B4715.7090408@redhat.com> Message-ID: <554B4C66.6030909@redhat.com> On 05/07/2015 01:05 PM, Martin Babinsky wrote: > On 05/06/2015 07:41 PM, thierry bordaz wrote: >> On 05/06/2015 05:56 PM, Martin Babinsky wrote: >>> On 05/06/2015 04:25 PM, thierry bordaz wrote: >>>> On 05/06/2015 03:19 PM, Martin Babinsky wrote: >>>>> Hello Thierry, >>>>> >>>>> replies are inline. >>>>> >>>>> On 05/06/2015 02:22 PM, thierry bordaz wrote: >>>>>> On 05/06/2015 01:54 PM, Martin Babinsky wrote: >>>>>>> The attached patch tries to fix >>>>>>> https://fedorahosted.org/freeipa/ticket/4378 >>>>>>> >>>>>>> After discussion with Thierry we concluded that while this issue is >>>>>>> more complex than it seems, the transition from REPLACE to DEL/ADD >>>>>>> operations when updating nsDS5ReplicaId should suffice for this >>>>>>> ticket. >>>>>>> >>>>>> Hello Martin, >>>>>> >>>>>> Few comments, you are using MOD_DEL 'replicaID' with None value. So >>>>>> this >>>>>> is going to delete all previous values and it should be equivalent >>>>>> to a >>>>>> MOD_REPL. >>>>>> I was thinking you wanted to retrieve the id_value and call MOD_DEL >>>>>> 'replicaID' . So that if by the time you fetched the >>>>>> replicaId, an other replica updated the replicaId, the >>>>>> MOD_DEL/MOD_ADD >>>>>> would fail and you need a new iteration. >>>>>> >>>>> Sorry I didn't know you can MOD_DEL a particular value (I'm LDAP noob >>>>> I know). Will fix this. >>>>>> If replicaId was multi-valued and you want to make it single >>>>>> valued, you >>>>>> may want to do create a more complex MOD (e.g. (ldap.MOD_DELETE, >>>>>> 'nsDS5ReplicaId', str(value1), (ldap.MOD_DELETE, 'nsDS5ReplicaId', >>>>>> str(value2)...) >>>>>> >>>>> AFAIK ReplicaId is single-valued (looking at the schema right now) so >>>>> this shouldn't be problem. >>>>>> If it is updating successfully do you want to return 'retval' or >>>>>> 'retval+1' ? >>>>>> >>>>>> If several replicas try to update the replicaId of the master and >>>>>> the >>>>>> current replicaId is 1000. >>>>>> Replica1 successfully updates the replicaId and gets 1001 as the new >>>>>> value. >>>>>> Replica2 successfully updates the replicaId and gets 1002. >>>>>> The final value on master will be 1002, but replica1 will assum >>>>>> it is >>>>>> 1001. Is it a problem ? >>>>>> >>>>> I studied the code in the master branch and IIUC (and please correct >>>>> me if I got this wrong) nsDS5ReplicaId attribute in >>>>> 'cn=replication,cn=etc,$SUFFIX' represents replicaID of the _next_ >>>>> replica that will be installed. >>>>> >>>>> So if a replica is installed, it sets the current value of >>>>> nsDS5ReplicaId as its replica ID (the function returns 'retval') and >>>>> then increments it in 'cn=replication,cn=etc,$SUFFIX' entry >>>>> ('retval + >>>>> 1' is written to master) so that the next installed replica fetches >>>>> this updated value. >>>>> >>>>> So the case you described should be the expected behavior. To change >>>>> it would require different patch IMHO. >>>> >>>> Thank for your precious explanations, in fact the value in >>>> 'cn=replication,cn=etc,SUFFIX' is the next available replicaId >>>> value and >>>> is the centralized mechanism that assign unique replicaID. >>>> >>>> The risk was that several replica pick the same value. So yes it is >>>> important that the MOD_DEL specifies the previously read value so that >>>> the test/set will be atomic. If several replicas read the same value, >>>> only the faster one will use it to install the replica. >>>> >>>> thanks >>>> thierry >>>>>> thanks >>>>>> thierry >>>>> >>>>> >>>> >>> >>> Attaching updated patch with fixed MOD_DELETE operation. >>> >> >> Hi Martin, >> >> The fix looks good to me except I think you need to do (ldap.MOD_DELETE, >> 'nsDS5ReplicaId', *str(*retval*)*) >> >> thanks >> thierry > > Attaching updated patch. > Thanks Martin, The fix is good for me. Ack. thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Thu May 7 11:34:04 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 07 May 2015 13:34:04 +0200 Subject: [Freeipa-devel] [PATCH] 800 rpc-client: add forms based auth support In-Reply-To: <554A246B.4060109@redhat.com> References: <54E5F883.1090702@redhat.com> <554A246B.4060109@redhat.com> Message-ID: <554B4DAC.7040909@redhat.com> On 05/06/2015 04:25 PM, Milan Kubik wrote: > On 02/19/2015 03:51 PM, Petr Vobornik wrote: >> This patch is a prerequisite for patch 801 which will follow. It was >> developed to enable to use ipalib RPC client in Web UI tests. Plus it >> will enable to significantly speed up Web UI tests suite (if >> preparation of data is transformed to use this method). >> >> Partly related https://fedorahosted.org/freeipa/ticket/4772 and >> https://fedorahosted.org/freeipa/ticket/4307 >> >> >> Leverage session support to enable forms-based authenticate in rpc >> client. >> >> In order to do that session support in KerbTransport was moved to new >> SessionTransport. RPCClient.create_connection is then modified to >> force forms-based auth if new optional options - user and password are >> specified. For this case SessionTransport is used and user is >> authenticated by calling >> 'https://ipa.server/ipa/session/login_password'. Session cookie is >> stored and used in subsequent calls. >> >> This feature is usable for use cases where one wants to call the API >> without being on ipa client. Non-being on ipa client also means that >> IPA's NSS database and configuration is not available. Therefore one >> has to define "~/.ipa/default.conf" in a similar way as ipa client >> does and prepare a NSS database with IPA CA cert. >> >> Usage: >> >> api.Backend.rpcclient.connect( >> nss_dir=my_nss_dir_path, >> user=user, >> password=password >> ) >> >> It's possible to switch users with: >> >> api.Backend.rpcclient.disconnect() >> >> api.Backend.rpcclient.connect( >> nss_dir=my_nss_dir_path, >> user=other_user, >> password=other_password >> ) >> >> Or check connection with: >> >> api.Backend.rpcclient.isconnected() >> >> Example: download a CA cert and add it to a new temporary NSS database: >> from urllib2 import urlparse >> from ipaplatform.paths import paths >> from ipapython import certdb, ipautil >> from ipapython.ipautil import run >> from ipalib import x509 >> >> # create new NSSDatabase >> tmp_db = certdb.NSSDatabase() >> pwd_file = ipautil.write_tmp_file(ipautil.ipa_generate_password()) >> tmp_db.create_db(pwd_file.name) >> >> # download and add cert >> url = urlparse.urlunparse(('http', ipautil.format_netloc(ipa_server), >> '/ipa/config/ca.crt', '', '', '')) >> stdout, stderr, rc = run([paths.BIN_WGET, "-O", "-", url]) >> certs = x509.load_certificate_list(stdout, tmp_db.secdir) >> ca_certs = [cert.der_data for cert in certs] >> for i, cert in enumerate(ca_certs): >> tmp_db.add_cert(cert, 'CA certificate %d' % (i + 1), 'C,,') >> >> my_nss_dir_path = tmp_db.secdir >> >> > > thanks for the patch. Please, fix the pep8 complaints. I've fixed existing E128 error in imports. But the remaining: $ git diff HEAD~1 -U0 | pep8 --diff ./ipalib/rpc.py:518:80: E501 line too long (86 > 79 characters) ./ipalib/rpc.py:524:80: E501 line too long (84 > 79 characters) ./ipalib/rpc.py:609:80: E501 line too long (80 > 79 characters) ./ipalib/rpc.py:634:80: E501 line too long (82 > 79 characters) ./ipalib/rpc.py:641:80: E501 line too long (94 > 79 characters) ./ipalib/rpc.py:796:80: E501 line too long (80 > 79 characters) ./ipalib/rpc.py:800:80: E501 line too long (82 > 79 characters) ./ipalib/rpc.py:913:80: E501 line too long (84 > 79 characters) I won't fix. Since it's just E501 in moved code. > > Can someone else look at the code as well, please? > > Thanks, > Milan > -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0800-1-rpc-client-add-forms-based-auth-support.patch Type: text/x-patch Size: 20244 bytes Desc: not available URL: From pvoborni at redhat.com Thu May 7 11:38:07 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 07 May 2015 13:38:07 +0200 Subject: [Freeipa-devel] [PATCH] 801-806 webui-ci: otptoken tests In-Reply-To: <54E5F888.2000402@redhat.com> References: <54E5F888.2000402@redhat.com> Message-ID: <554B4E9F.1070806@redhat.com> On 02/19/2015 03:51 PM, Petr Vobornik wrote: > https://fedorahosted.org/freeipa/ticket/4307 > > For ipa-4-1 apply: > - patch 800 (different thread) > - patches 801-806 > > For master apply: > - patch 800 (different thread) > - patch 807 (different thread) > - patch 801-master > - patches 802-806 > > Patch 801 allows to use ipalib rpc client in Web UI test suite. > Patches 802-805 are various ui_driver fixes to allow stuff in patch 806. > > == [PATCH] 806 webui-ci: otptoken tests == > > Basic otptoken Web UI CI coverage. > > tests: > * crud for otptokens as admin > * crud for normal users > * checks fields of adder dialog for both token types and user role > (admin/user) > * token actions as admin (enable, disable, delete) > * token actions as normal user (delete) > * login as normal user with hotp and totp token > * sync token hotp and totp token as normal user and then login > > https://fedorahosted.org/freeipa/ticket/4307 > > == [PATCH] 805 webui-ci: allow custom names for disable/enable actions == > > Not all disable and enable actions are called 'disable' and 'enable'. > > == [PATCH] 804 webui-ci: allow to update pkey in post-add in basic-crud > tests == > > == [PATCH] 803 webui-ci: add post_add_action == > > post add action allows to fill autogenerated values, e.g. a pkey of new > otptoken. > > This value can be then used in other subsequent test which would depend > on it - like crud tests. > > == [PATCH] 802 webui-ci: fix negative visibility check == > > Allow to define, that element doesn't have to be present on a page for > negative visible checks. > > E.g. if element is added only if it's displayed and is removed otherwise. > > == [PATCH] 801 webui-ci: support direct IPA API calls == > > Add IPA API support to ui_driver. It leverages new ipalib RPC client's > forms based authentication. It then allows to call an IPA API while > the machine is not an IPA client nor is kerberized. > > api's environment values are taken from test configuration and > therefore duplication in ~/.ipa/default.conf is not required. > > Since the machine doesn't have to be IPA client, it then also doesn't > have nss database with IPA's CA certificate. Therefore on each API > initialization a new NSS database is created with a CA certificate > downloaded from IPA. This db is deleted in tearDown phase. > > Usage: > > 1. as admin one can immediately call rpc commands, api will be > initialized upon first request and is available under self.api > (assuming self is ui_driver): > self.api.Command.user_del(USER_ID, **{'continue': True}) > > 2. to reconnect as other user: > self.reconnect_api(USER_ID, USER_PW) > > 3. reconnect back as admin: > self.reconnect_api() > Patch #803 needed rebase. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0806-1-webui-ci-otptoken-tests.patch Type: text/x-patch Size: 15040 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0805-1-webui-ci-allow-custom-names-for-disable-enable-actio.patch Type: text/x-patch Size: 1705 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0804-1-webui-ci-allow-to-update-pkey-in-post-add-in-basic-c.patch Type: text/x-patch Size: 1504 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0803-1-webui-ci-add-post_add_action.patch Type: text/x-patch Size: 2136 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0802-1-webui-ci-fix-negative-visibility-check.patch Type: text/x-patch Size: 1556 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0801-1-webui-ci-support-direct-IPA-API-calls.patch Type: text/x-patch Size: 6003 bytes Desc: not available URL: From mbabinsk at redhat.com Thu May 7 11:48:17 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 07 May 2015 13:48:17 +0200 Subject: [Freeipa-devel] [PATCH 0238] Server Upgrade: fix broken memberUid index In-Reply-To: <5549F9A9.50107@redhat.com> References: <5549F958.1040508@redhat.com> <5549F9A9.50107@redhat.com> Message-ID: <554B5101.6010605@redhat.com> On 05/06/2015 01:23 PM, Martin Basti wrote: > On 06/05/15 13:22, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5007 >> >> Patch attached. >> >> >> > Requires patch mbasti-231-4 > > -- > Martin Basti > ACK -- Martin^3 Babinsky From pvoborni at redhat.com Thu May 7 11:56:32 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 07 May 2015 13:56:32 +0200 Subject: [Freeipa-devel] [PATCH 0032] prevent duplicate IDs when setting up multiple replicas against single master In-Reply-To: <554B4C66.6030909@redhat.com> References: <554A00FB.60205@redhat.com> <554A0768.9000107@redhat.com> <554A14C9.90605@redhat.com> <554A245F.4060507@redhat.com> <554A39BD.5060609@redhat.com> <554A5265.3010101@redhat.com> <554B4715.7090408@redhat.com> <554B4C66.6030909@redhat.com> Message-ID: <554B52F0.3020509@redhat.com> On 05/07/2015 01:28 PM, thierry bordaz wrote: > On 05/07/2015 01:05 PM, Martin Babinsky wrote: >> On 05/06/2015 07:41 PM, thierry bordaz wrote: >> >> Attaching updated patch. >> > Thanks Martin, > > The fix is good for me. Ack. > > thierry > Pushed to master: e2a42efe33d5e6cb08e1988f7253caf56eda11df -- Petr Vobornik From pspacek at redhat.com Thu May 7 12:55:37 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 07 May 2015 14:55:37 +0200 Subject: [Freeipa-devel] [PATCH 0338] Add includes to zone.c to improve compatibility with BIND 9.9.4 Message-ID: <554B60C9.2030403@redhat.com> Hello, This is minor improvement for patch set related to ticket #155. Add includes to zone.c to improve compatibility with BIND 9.9.4. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0338-Add-includes-to-zone.c-to-improve-compatibility-with.patch Type: text/x-patch Size: 741 bytes Desc: not available URL: From pvoborni at redhat.com Thu May 7 13:57:42 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 07 May 2015 15:57:42 +0200 Subject: [Freeipa-devel] [PATCH] 827 Update BUILD.txt Message-ID: <554B6F56.4010106@redhat.com> Add note about `dnf builddep` command and link to http://www.freeipa.org/page/Build page which contains information about copr repos -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0827-Update-BUILD.txt.patch Type: text/x-patch Size: 2632 bytes Desc: not available URL: From pvoborni at redhat.com Thu May 7 13:59:17 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 07 May 2015 15:59:17 +0200 Subject: [Freeipa-devel] [PATCH 0007] Changed in-tree development setup instructions In-Reply-To: <20150103205329.GA27759@tscherf.redhat.com> References: <20150103205329.GA27759@tscherf.redhat.com> Message-ID: <554B6FB5.6020204@redhat.com> On 01/03/2015 09:53 PM, Thorsten Scherf wrote: > Changed in-tree development setup instructions > Instructions on how to setup an in-tree development server were not > were > clear in the existing BUILD.txt. Setup procedure has been extended and > corrected. > Hello, thanks for the patch. There were trailing whitespace errors, but I've fixed them. ACK Pushed to master: 83e2552cdd99e67415148c0a7a317f3e3c45b831 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tscherf-0007-2-Changed-in-tree-development-setup-instructions.patch Type: text/x-patch Size: 1358 bytes Desc: not available URL: From pvoborni at redhat.com Thu May 7 14:00:47 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 07 May 2015 16:00:47 +0200 Subject: [Freeipa-devel] [PATCH 0026] ipa-server-install: deprecate manual setting of master KDC password In-Reply-To: <551C09BF.5050107@redhat.com> References: <551C09BF.5050107@redhat.com> Message-ID: <554B700F.8080809@redhat.com> On 04/01/2015 05:07 PM, Martin Babinsky wrote: > https://fedorahosted.org/freeipa/ticket/4516 > ACK Pushed to master: 059a4c188760ec7360ccb68a5c8a292afb21d35e -- Petr Vobornik From pvoborni at redhat.com Thu May 7 14:03:51 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 07 May 2015 16:03:51 +0200 Subject: [Freeipa-devel] [PATCH 0028] update 'api.env.ca_host' if a different hostname is used during server install In-Reply-To: <552BE6C5.2050603@redhat.com> References: <552BE6C5.2050603@redhat.com> Message-ID: <554B70C7.4000702@redhat.com> On 04/13/2015 05:54 PM, Martin Babinsky wrote: > https://fedorahosted.org/freeipa/ticket/4936 > ACK Pushed to master: 825d4fc9e7fc80e07a68daf35b5eb0c171e821af -- Petr Vobornik From pvoborni at redhat.com Thu May 7 14:06:54 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 07 May 2015 16:06:54 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Test Objectclass of postdetach group In-Reply-To: <1425536977.15996.1.camel@dhcp130-146.brq.redhat.com> References: <1425536977.15996.1.camel@dhcp130-146.brq.redhat.com> Message-ID: <554B717E.5000402@redhat.com> On 03/05/2015 07:29 AM, Lenka Ryznarova wrote: > Patch related to ticket > https://fedorahosted.org/freeipa/ticket/4909 > > Lenka > 1. There is a trailing whitespace test_group_plugin.py:1128, I've fixed it. ACK Pushed to master: b7af1825468720dfac6ee1259c845ec70d12ca43 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-lryznaro-0001-1-Test-Objectclass-of-postdetach-group.patch Type: text/x-patch Size: 3337 bytes Desc: not available URL: From tbordaz at redhat.com Thu May 7 14:32:34 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 07 May 2015 16:32:34 +0200 Subject: [Freeipa-devel] [PATCH] manage replication topology in the shared tree In-Reply-To: <5540A1D5.2000301@redhat.com> References: <552B84C5.80300@redhat.com> <553522A2.9090007@redhat.com> <55360F10.7010804@redhat.com> <553DF0C6.30403@redhat.com> <5540A1D5.2000301@redhat.com> Message-ID: <554B7782.7050807@redhat.com> On 04/29/2015 11:18 AM, Ludwig Krispenz wrote: > Hi, thanks again, so there is some work to do, but see some answers inline > On 04/27/2015 10:18 AM, thierry bordaz wrote: >> On 04/21/2015 10:49 AM, Ludwig Krispenz wrote: >>> >>> On 04/20/2015 06:00 PM, thierry bordaz wrote: >>>> On 04/13/2015 10:56 AM, Ludwig Krispenz wrote: >>>>> Hi, >>>>> >>>>> in the attachment you find the latest state of the "topology >>>>> plugin", it implements what is defined in the design page: >>>>> http://www.freeipa.org/page/V4/Manage_replication_topology (which >>>>> is also waiting for a reviewer) >>>>> >>>>> It contains the plugin itself and a core of ipa commands to >>>>> manage a topology. to be really applicable, some work outside is >>>>> required, eg the management of the domain level and a decision >>>>> where the binddn group should be maintained. >>>>> >>>>> Thanks, >>>>> Ludwig >>>>> >>>>> >>>> Hello Ludwig, >>>> >>>> Quite long review to do. So far I only looked at the startup phase >>>> and I have only few questions and comments. >>> Thanks for your time, and I'm looking forward to your review of the >>> other parts, you raise some valid points. >>> I'll try to answer some of them inline, but will integrate some into >>> a next version of the patch >>>> >>>> In ipa_topo_start, do you need to get argc/argv as you are not >>>> using plugin-argxx attributes ? >>> no. It was a leftover from a "standard" plugin >>>> >>>> >>>> topo_plugin_conf configuration parameters are not freed when the >>>> plugin is closed. Is it closed only at shutdown ? >>>> Also I would initiatlize it to {NULL}. >>> So far it is not planned to be dynamic, but I will addres the memory >>> management >>>> >>>> In case the config does not contain any >>>> nsslapd-topo-plugin-shared-replica-root, I wonder if >>>> ipa_topo_apply_shared_config may crash as shared_replica_root will >>>> be NULL. >>>> or at least in >>>> ipa_topo_apply_shared_replica_config/ipa_topo_util_get_replica_conf. >>>> >>>> Also if nsslapd-topo-plugin-shared-replica-root contains an invalid >>>> root suffix (typo), topoRepl remains NULL and >>>> ipa_topo_util_get_replica_conf/ipa_topo_cfg_replica_add can crash. >>> for the two comments above, I was assuming that plugin conf and >>> shared tree would be setup by ipa tools and server setup, so >>> assuming only valid data, but you are right, checking for bad data >>> doesn't hurt. >>>> >>>> In ipa_topo_util_segment_from_entry, if the config entry has no >>>> direction/left/right it will crash. Shouldn't it return an error if >>>> the config is invalid. >>> adding a segment should be done with the ipa command 'ipa >>> topologysegment-add ...' and this always provides a direction (param >>> or default). If you try to add a segment directly, direction is a >>> required attribute of teh segment objectclass, so it should be rejected- >>>> >>>> The update of domainLevel may start the plugin. If two mods update >>>> the domainLevel they could be done in parallele. >>> yes :-( >>>> >>>> >>>> In ipa_topo_util_update_agmt_list, if there is a marked agmnt but >>>> no segment it deletes the agreement. >>>> Is it possible there is a segment but no agmnt ? For example, if >>>> the server were stopped or crashed after the segment was created >>>> but before the local config was updated. >>> then it should be created from the segment >>>> >>>> >>>> Hosts are taken from shared config tree (cn=masters,), is it >>>> possible to have a replica agreement to a host that is not under >>>> 'cn=masters,' >>> yes, it will be ignored by the plugin >>>> >>>> >>>> thanks >>>> thierry >>>> >>> >> >> >> Hi Ludwig, >> >> I continued the review of the design/topology plugin code. This is >> really an interesting plugin but unfortunately I have not yet >> reviewed all the parts. >> >> I went through the design and digging the related parts in the code. >> So far I need to review the rest starting at >> http://www.freeipa.org/page/V4/Manage_replication_topology#connectivity_management. >> >> I think I did ~50% design but may be more than 50% of the code. >> >> Here are additional points: >> >> >> in ipa_topo_set_domain_level, you may record the new Domain level >> value as FATAL (it is already recorded in case of oneline import) >> > this just records the actual domain level, I don't think we need to > log it every time, only if it is changed should be sufficient (to verify) >> >> >> ipa_topo_be_state_change is called for any backend going online. >> Domain level and start should be done only for a backend mapping >> a shared-replica-root. >> > yes, the comment is already there, but the actual check isn't, so it > would be recreated at online init of any backend, think it is not too > bad, but will change it >> >> Also the plugin can be started many times (each online init), >> ipa_topo_util_start is not protected by a lock >> Some fields will leak (in ipa_topo_init_shared_config) >> Also I wonder if you reinit several times the same replica-root, >> its previous config will leak. (replica->repl_segments) >> > you shouldn't :-), but needs to be made safer >> >> >> In ipa_topo_apply_shared_replica_config, >> I do not see where replica_config is kept (leak ?) >> > it is created and set to the shared_conf data, but if it aready > exists, it will leak (that's probably the case above), it should be > freed when the plugin is stopped >> >> >> ipa_topo_util_start/ipa_topo_apply_shared_config is called at >> startup or during online-init. >> For online-init, if the plugin was already active, what is the >> need of calling ipa_topo_util_start ? >> > you don't know if the data in the shared tree are teh same as before >> >> For online-init, It initializes all the replica-root. Could it >> init only the reinitialized replic-root ? >> > yes, it could (sjhould). >> >> >> in >> http://www.freeipa.org/page/V4/Manage_replication_topology#shared_configuration:_database, >> it mentions ipaReplTopoConfigMaster. >> Is it implemented ? >> > it is there as a concept, not completed >> >> >> in >> http://www.freeipa.org/page/V4/Manage_replication_topology#shared_configuration:_segment, >> what happens if a server under cn=masters is removed ? >> > for all its manages suffixes, the marked segments connecting it are > removed, the ldap principal is removed form the binddn groups >> >> >> in >> http://www.freeipa.org/page/V4/Manage_replication_topology#shared_configuration:_example. >> There is a segment cn=111_to_102. For example it was created by >> vm-111 when topology plugin starts with 'dc=example,dc=com' . >> What prevents vm-102 topology plugins to create the segment >> cn=102_to_111 ? >> > the pre add check should prevent this, but if you do it > simultaneously, two segments will be added and one will be ignored > when the internal segments are updated (double check) >> >> >> in ipa_topo_post_mod. >> Is it 100% that if we have 'cn=replica >> example,cn=topology,dc=example,dc=com' then it exists the related >> config in topo_shared_conf.replicas. >> In ipa_topo_util_get_replica_conf, it is looking like the entry >> can exist before the related config is added. >> In that case when modifying a segment >> ipa_topo_util_get_conf_for_segment will return 'tconf' config >> that is not linked in topo_shared_conf.replicas tconf will leak >> and I am unsure the post_mod is fully processed. >> >> In ipa_topo_post_mod >> in ipa_topo_util_segment_update if the >> segment.ipaReplTopoSegmentDirection was "none" and MOD set it to >> "both", segment->right/left are not set but it is said to be >> bidirectional >> > I'm no longer sure if we have a valid scenario, need to think about it > again >> >> >> ipaReplTopoSegmentStatus: can not find it in the design >> > it was forgotten when the method to marjk agreements was last chnged :-) >> >> >> in ipa_topo_util_existing_agmts_update, my understanding is that >> a host only updates its local replica agreement. >> > that's the only agreements it can update with internal ops >> >> So even if the segment update is replicated, others hosts will >> not skip updates where ->origin is not themself. >> > you mean will skip/ignore ? >> >> I think you may add a comment about this as it looks an important >> thing. >> Also I did not find this comment in the design but may be I >> missed it. >> > ok >> >> >> in ipa_topo_util_existing_agmts_update, it applies the mods on >> left or on right. That means we do not support serveral instance >> on the same machine. I also missed that point in the design. >> >> in ipa_topo_agmt_mod, it does nothing when deleting a managed >> attribute ? >> >> in ipa_topo_agmt_mod, if update of the replica agreement fails >> (ipa_topo_agreement_dn or ipa_topo_util_modify) you may log a message >> >> in ipa_topo_agmt_mod, if the mod is not related to any managed >> attribute, there is no replica agreement update but the 'dn' is >> not freed. >> >> in ipa_topo_post_mod, I do not see 'domainLevel' in the schema. >> Is it stored in an extensible object ? >> > the mod of an agreeement via the plugin was a bit neglected in my > tests, will check again and answer later >> >> >> > Hi Ludwig, Last (late) part of the review :-) In ipa_topo_agmt_setup, the 'cn' of the replica agreement need to be freed. My understanding is that ipa_topo_apply_shared_config will not be called twice in parallel. Correct ? In ipa_topo_util_update_agmt_list, 'filter' will leak In ipa_topo_util_update_agmt_list, shouldn't 'smods' be freed ? In ipa_topo_util_segment_merge,.. difficult to understand but nice :-) When merging, depending on which server the merge will occur, we may decide to duplicate the first replica_agreement managed attributes or to keep the values given in the added segment. (at least it is what I understand :-\ ) In ipa_topo_util_update_segments_for_host, when adding a replica we lookup all the RA toward that replica. But if RA is related to a not managed repl_root, I think it may crash in ipa_topo_util_segment_write/ipa_topo_segment_dn (conf=NULL) ipa_topo_connection_fanout returns allocated targets/node_fanout. I do not see where it is freed in ipa_topo_check_disconnect_reject. In design, it is said that in preop internal operation by topology_plugin are successful. Where is it tested ? Regarding the design: I have not found the list of operation that the admnistrator has to do before activating the plugin. For example, if a non marked replica agreement exists it is deleted if there is no segment to the replicahost. Does that mean that all segments must be created or RA marked before activating the plugin ? If some attributes are skipped from replication (reduce replication trafic or DMZ), the checking of the connectivity become complex. For example if a replica receives only parts of the attributes and an other all the attributes. The decision to create a replica agreement to a new replica depends if we want fractional/full replication. Thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkrispen at redhat.com Thu May 7 14:41:20 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 07 May 2015 16:41:20 +0200 Subject: [Freeipa-devel] [PATCH] manage replication topology in the shared tree In-Reply-To: <554B7782.7050807@redhat.com> References: <552B84C5.80300@redhat.com> <553522A2.9090007@redhat.com> <55360F10.7010804@redhat.com> <553DF0C6.30403@redhat.com> <5540A1D5.2000301@redhat.com> <554B7782.7050807@redhat.com> Message-ID: <554B7990.5010804@redhat.com> Thanks, I will look into it and try to add what's missing and also try to make the design a bit more clear. Ludwig On 05/07/2015 04:32 PM, thierry bordaz wrote: > On 04/29/2015 11:18 AM, Ludwig Krispenz wrote: >> Hi, thanks again, so there is some work to do, but see some answers >> inline >> On 04/27/2015 10:18 AM, thierry bordaz wrote: >>> On 04/21/2015 10:49 AM, Ludwig Krispenz wrote: >>>> >>>> On 04/20/2015 06:00 PM, thierry bordaz wrote: >>>>> On 04/13/2015 10:56 AM, Ludwig Krispenz wrote: >>>>>> Hi, >>>>>> >>>>>> in the attachment you find the latest state of the "topology >>>>>> plugin", it implements what is defined in the design page: >>>>>> http://www.freeipa.org/page/V4/Manage_replication_topology (which >>>>>> is also waiting for a reviewer) >>>>>> >>>>>> It contains the plugin itself and a core of ipa commands to >>>>>> manage a topology. to be really applicable, some work outside is >>>>>> required, eg the management of the domain level and a decision >>>>>> where the binddn group should be maintained. >>>>>> >>>>>> Thanks, >>>>>> Ludwig >>>>>> >>>>>> >>>>> Hello Ludwig, >>>>> >>>>> Quite long review to do. So far I only looked at the startup phase >>>>> and I have only few questions and comments. >>>> Thanks for your time, and I'm looking forward to your review of the >>>> other parts, you raise some valid points. >>>> I'll try to answer some of them inline, but will integrate some >>>> into a next version of the patch >>>>> >>>>> In ipa_topo_start, do you need to get argc/argv as you are not >>>>> using plugin-argxx attributes ? >>>> no. It was a leftover from a "standard" plugin >>>>> >>>>> >>>>> topo_plugin_conf configuration parameters are not freed when the >>>>> plugin is closed. Is it closed only at shutdown ? >>>>> Also I would initiatlize it to {NULL}. >>>> So far it is not planned to be dynamic, but I will addres the >>>> memory management >>>>> >>>>> In case the config does not contain any >>>>> nsslapd-topo-plugin-shared-replica-root, I wonder if >>>>> ipa_topo_apply_shared_config may crash as shared_replica_root will >>>>> be NULL. >>>>> or at least in >>>>> ipa_topo_apply_shared_replica_config/ipa_topo_util_get_replica_conf. >>>>> >>>>> Also if nsslapd-topo-plugin-shared-replica-root contains an >>>>> invalid root suffix (typo), topoRepl remains NULL and >>>>> ipa_topo_util_get_replica_conf/ipa_topo_cfg_replica_add can crash. >>>> for the two comments above, I was assuming that plugin conf and >>>> shared tree would be setup by ipa tools and server setup, so >>>> assuming only valid data, but you are right, checking for bad data >>>> doesn't hurt. >>>>> >>>>> In ipa_topo_util_segment_from_entry, if the config entry has no >>>>> direction/left/right it will crash. Shouldn't it return an error >>>>> if the config is invalid. >>>> adding a segment should be done with the ipa command 'ipa >>>> topologysegment-add ...' and this always provides a direction >>>> (param or default). If you try to add a segment directly, direction >>>> is a required attribute of teh segment objectclass, so it should be >>>> rejected- >>>>> >>>>> The update of domainLevel may start the plugin. If two mods update >>>>> the domainLevel they could be done in parallele. >>>> yes :-( >>>>> >>>>> >>>>> In ipa_topo_util_update_agmt_list, if there is a marked agmnt but >>>>> no segment it deletes the agreement. >>>>> Is it possible there is a segment but no agmnt ? For example, if >>>>> the server were stopped or crashed after the segment was created >>>>> but before the local config was updated. >>>> then it should be created from the segment >>>>> >>>>> >>>>> Hosts are taken from shared config tree (cn=masters,), is it >>>>> possible to have a replica agreement to a host that is not under >>>>> 'cn=masters,' >>>> yes, it will be ignored by the plugin >>>>> >>>>> >>>>> thanks >>>>> thierry >>>>> >>>> >>> >>> >>> Hi Ludwig, >>> >>> I continued the review of the design/topology plugin code. This is >>> really an interesting plugin but unfortunately I have not yet >>> reviewed all the parts. >>> >>> I went through the design and digging the related parts in the code. >>> So far I need to review the rest starting at >>> http://www.freeipa.org/page/V4/Manage_replication_topology#connectivity_management. >>> >>> I think I did ~50% design but may be more than 50% of the code. >>> >>> Here are additional points: >>> >>> >>> in ipa_topo_set_domain_level, you may record the new Domain >>> level value as FATAL (it is already recorded in case of oneline >>> import) >>> >> this just records the actual domain level, I don't think we need to >> log it every time, only if it is changed should be sufficient (to verify) >>> >>> >>> ipa_topo_be_state_change is called for any backend going online. >>> Domain level and start should be done only for a backend mapping >>> a shared-replica-root. >>> >> yes, the comment is already there, but the actual check isn't, so it >> would be recreated at online init of any backend, think it is not too >> bad, but will change it >>> >>> Also the plugin can be started many times (each online init), >>> ipa_topo_util_start is not protected by a lock >>> Some fields will leak (in ipa_topo_init_shared_config) >>> Also I wonder if you reinit several times the same replica-root, >>> its previous config will leak. (replica->repl_segments) >>> >> you shouldn't :-), but needs to be made safer >>> >>> >>> In ipa_topo_apply_shared_replica_config, >>> I do not see where replica_config is kept (leak ?) >>> >> it is created and set to the shared_conf data, but if it aready >> exists, it will leak (that's probably the case above), it should be >> freed when the plugin is stopped >>> >>> >>> ipa_topo_util_start/ipa_topo_apply_shared_config is called at >>> startup or during online-init. >>> For online-init, if the plugin was already active, what is the >>> need of calling ipa_topo_util_start ? >>> >> you don't know if the data in the shared tree are teh same as before >>> >>> For online-init, It initializes all the replica-root. Could it >>> init only the reinitialized replic-root ? >>> >> yes, it could (sjhould). >>> >>> >>> in >>> http://www.freeipa.org/page/V4/Manage_replication_topology#shared_configuration:_database, >>> it mentions ipaReplTopoConfigMaster. >>> Is it implemented ? >>> >> it is there as a concept, not completed >>> >>> >>> in >>> http://www.freeipa.org/page/V4/Manage_replication_topology#shared_configuration:_segment, >>> what happens if a server under cn=masters is removed ? >>> >> for all its manages suffixes, the marked segments connecting it are >> removed, the ldap principal is removed form the binddn groups >>> >>> >>> in >>> http://www.freeipa.org/page/V4/Manage_replication_topology#shared_configuration:_example. >>> There is a segment cn=111_to_102. For example it was created by >>> vm-111 when topology plugin starts with 'dc=example,dc=com' . >>> What prevents vm-102 topology plugins to create the segment >>> cn=102_to_111 ? >>> >> the pre add check should prevent this, but if you do it >> simultaneously, two segments will be added and one will be ignored >> when the internal segments are updated (double check) >>> >>> >>> in ipa_topo_post_mod. >>> Is it 100% that if we have 'cn=replica >>> example,cn=topology,dc=example,dc=com' then it exists the >>> related config in topo_shared_conf.replicas. >>> In ipa_topo_util_get_replica_conf, it is looking like the entry >>> can exist before the related config is added. >>> In that case when modifying a segment >>> ipa_topo_util_get_conf_for_segment will return 'tconf' config >>> that is not linked in topo_shared_conf.replicas tconf will leak >>> and I am unsure the post_mod is fully processed. >>> >>> In ipa_topo_post_mod >>> in ipa_topo_util_segment_update if the >>> segment.ipaReplTopoSegmentDirection was "none" and MOD set it to >>> "both", segment->right/left are not set but it is said to be >>> bidirectional >>> >> I'm no longer sure if we have a valid scenario, need to think about >> it again >>> >>> >>> ipaReplTopoSegmentStatus: can not find it in the design >>> >> it was forgotten when the method to marjk agreements was last chnged :-) >>> >>> >>> in ipa_topo_util_existing_agmts_update, my understanding is that >>> a host only updates its local replica agreement. >>> >> that's the only agreements it can update with internal ops >>> >>> So even if the segment update is replicated, others hosts will >>> not skip updates where ->origin is not themself. >>> >> you mean will skip/ignore ? >>> >>> I think you may add a comment about this as it looks an >>> important thing. >>> Also I did not find this comment in the design but may be I >>> missed it. >>> >> ok >>> >>> >>> in ipa_topo_util_existing_agmts_update, it applies the mods on >>> left or on right. That means we do not support serveral instance >>> on the same machine. I also missed that point in the design. >>> >>> in ipa_topo_agmt_mod, it does nothing when deleting a managed >>> attribute ? >>> >>> in ipa_topo_agmt_mod, if update of the replica agreement fails >>> (ipa_topo_agreement_dn or ipa_topo_util_modify) you may log a >>> message >>> >>> in ipa_topo_agmt_mod, if the mod is not related to any managed >>> attribute, there is no replica agreement update but the 'dn' is >>> not freed. >>> >>> in ipa_topo_post_mod, I do not see 'domainLevel' in the schema. >>> Is it stored in an extensible object ? >>> >> the mod of an agreeement via the plugin was a bit neglected in my >> tests, will check again and answer later >>> >>> >>> >> > > > Hi Ludwig, > > Last (late) part of the review :-) > > In ipa_topo_agmt_setup, the 'cn' of the replica agreement need to be > freed. > > My understanding is that ipa_topo_apply_shared_config will not be > called twice in parallel. Correct ? > > In ipa_topo_util_update_agmt_list, 'filter' will leak > > In ipa_topo_util_update_agmt_list, shouldn't 'smods' be freed ? > > In ipa_topo_util_segment_merge,.. difficult to understand but nice :-) > When merging, depending on which server the merge will occur, we may > decide to duplicate the first replica_agreement managed attributes > or to keep the values given in the added segment. (at least it is > what I understand :-\ ) > > > In ipa_topo_util_update_segments_for_host, when adding a replica we > lookup all the RA toward that replica. But if RA is related to a not > managed repl_root, I think it may crash in > ipa_topo_util_segment_write/ipa_topo_segment_dn (conf=NULL) > > > ipa_topo_connection_fanout returns allocated targets/node_fanout. I do > not see where it is freed in ipa_topo_check_disconnect_reject. > > In design, it is said that in preop internal operation by > topology_plugin are successful. Where is it tested ? > > Regarding the design: > I have not found the list of operation that the admnistrator has to do > before activating the plugin. For example, if a non marked replica > agreement exists it is deleted if there is no segment to the > replicahost. Does that mean that all segments must be created or RA > marked before activating the plugin ? > > If some attributes are skipped from replication (reduce replication > trafic or DMZ), the checking of the connectivity become complex. > For example if a replica receives only parts of the attributes and an > other all the attributes. The decision to create a replica agreement > to a new replica depends if we want fractional/full replication. > > Thanks > thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu May 7 15:06:22 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 07 May 2015 17:06:22 +0200 Subject: [Freeipa-devel] [PATCH] 827 Update BUILD.txt In-Reply-To: <554B6F56.4010106@redhat.com> References: <554B6F56.4010106@redhat.com> Message-ID: <554B7F6E.1070907@redhat.com> On 07/05/15 15:57, Petr Vobornik wrote: > Add note about `dnf builddep` command and link to > http://www.freeipa.org/page/Build page which contains information > about copr repos > > ACK -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Thu May 7 15:14:11 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 07 May 2015 17:14:11 +0200 Subject: [Freeipa-devel] [PATCH] 827 Update BUILD.txt In-Reply-To: <554B7F6E.1070907@redhat.com> References: <554B6F56.4010106@redhat.com> <554B7F6E.1070907@redhat.com> Message-ID: <554B8143.10108@redhat.com> On 05/07/2015 05:06 PM, Martin Basti wrote: > On 07/05/15 15:57, Petr Vobornik wrote: >> Add note about `dnf builddep` command and link to >> http://www.freeipa.org/page/Build page which contains information >> about copr repos >> >> > ACK > Pushed to master: b88f5333ec039cf8a40c0377323554a451730ac7 -- Petr Vobornik From mbabinsk at redhat.com Thu May 7 16:04:54 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 07 May 2015 18:04:54 +0200 Subject: [Freeipa-devel] [PATCH] 823 ipaldap: raise DatabaseError on unbind if disconnected In-Reply-To: <553A298E.2020807@redhat.com> References: <5538C84C.9020407@redhat.com> <5538E1CB.8040705@redhat.com> <1429820290.5680.7.camel@redhat.com> <5539D24B.5050600@redhat.com> <553A298E.2020807@redhat.com> Message-ID: <554B8D26.70904@redhat.com> On 04/24/2015 01:31 PM, Petr Vobornik wrote: > On 04/24/2015 07:19 AM, Jan Cholasta wrote: >> Dne 23.4.2015 v 22:18 Nathaniel McCallum napsal(a): >>> On Thu, 2015-04-23 at 14:12 +0200, Petr Vobornik wrote: >>>> On 04/23/2015 12:24 PM, Petr Vobornik wrote: >>>>> If unbind was called when disconnected it raised: >>>>> AttributeError: 'NoneType' object has no attribute 'unbind_s' >>>>> >>>>> AttributeError is not a public error and therefore it prevented >>>>> ldap2.destroy_connection() to be called multiple times. >>>>> >>>>> fixes: >>>>> https://fedorahosted.org/freeipa/ticket/4991 >>>>> >>>>> Note: this issue also prevented rpcserver.change_password from >>>>> working. >>>>> Therefore I think that there might have been an error in recent >>>>> ipaldap >>>>> refactoring and if #4991 was not run on master then there might >>>>> have >>>>> been other issue, which probably have been fixed by the >>>>> refactoring. >>>>> >>>> >>>> After discussion with Honza, the approach was changed. >>>> >>>> Also I've added patch which removes unnecessary incorrect code which >>>> revealed the regression. >>>> >>>> Additional testing shows that these patches actually don't fix the >>>> original issue of #4991. See >>>> https://fedorahosted.org/freeipa/ticket/4991#comment:4 >>> >>> 0823 - ACK >>> 0824 - ACK >>> >>> Nathaniel >>> >> >> I would prefer if the connection was closed manually in patch 824, IMO >> it is a good practice to release resources once you are done with them >> just in time, and I don't think you can always trust the automatic >> disconnect at the end of request. >> > > Changed (also in user-status command). > > > ACK -- Martin^3 Babinsky From mbasti at redhat.com Thu May 7 16:12:49 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 07 May 2015 18:12:49 +0200 Subject: [Freeipa-devel] [PATCHES 0233-0234] DNSSEC: forwarders validation In-Reply-To: <554B3C19.9080002@redhat.com> References: <553A3D88.6080200@redhat.com> <55423032.9080505@redhat.com> <5548BED1.1060806@redhat.com> <554A1539.3040002@redhat.com> <554B0D69.5040008@redhat.com> <554B3C19.9080002@redhat.com> Message-ID: <554B8F01.9010501@redhat.com> On 07/05/15 12:19, Petr Spacek wrote: > On 7.5.2015 08:59, David Kupka wrote: >> On 05/06/2015 03:20 PM, Martin Basti wrote: >>> On 05/05/15 15:00, Martin Basti wrote: >>>> On 30/04/15 15:37, David Kupka wrote: >>>>> On 04/24/2015 02:56 PM, Martin Basti wrote: >>>>>> Patches attached. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Hi, >>>>> thanks for patches. >>>>> >>>>> 1. You changed message in DNSServerNotRespondingWarning class but not >>>>> the test in ipatest/test_xmlrpc/test_dns_plugin.py >>>>> >>>>> nitpick. Please spell 'edns' correctly. I've seen several instances >>>>> of 'ends'. >>>>> >>>> Thank you, >>>> >>>> updated patches attached: >>>> * new error messages >>>> * logging to debug log server output if exception was raised >>>> * fixed test >>>> * fixed spelling >>>> >>>> >>>> >>> Fixed tests (again) >>> >>> Updated patches attached >>> >> The code looks good to me and tests are no longer broken. (I would prefer >> better fix of the tests but given that the priorities are different now it can >> wait.) >> >> Petr, can you please confirm that the patch set works for you? > Sorry, NACK: > > $ ipa dnsforwardzone-add ptr.test. --forwarder=10.34.47.236 > Server will check DNS forwarder(s). > This may take some time, please wait ... > ipa: ERROR: an internal error has occurred > > # /var/log/httpd/error_log > ipa: ERROR: non-public: AssertionError: > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 350, in > wsgi_execute > result = self.Command[name](*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 443, in > __call__ > ret = self.run(*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 760, in run > return self.execute(*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 4444, in > execute > **options) > File "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 4405, in > _warning_if_forwarders_do_not_work > log=self.log) > File "/usr/lib/python2.7/site-packages/ipalib/util.py", line 715, in > validate_dnssec_zone_forwarder_step2 > timeout=timeout) > File "/usr/lib/python2.7/site-packages/ipalib/util.py", line 610, in > _resolve_record > assert isinstance(nameserver_ip, basestring) > AssertionError > ipa: INFO: [jsonserver_session] admin at IPA.EXAMPLE: dnsforwardzone_add( name ptr.test.>, idnsforwarders=(u'10.34.47.236',), all=False, raw=False, > version=u'2.116'): AssertionError > > This is constantly reproducible in my vm-090.abc. Let me know if you want to > take a look. > > > I'm attaching little response.patch which improves compatibility with older > python-dns packages. This patch allows IPA to work while error messages are > simply not as nice as they could be with latest python-dns :-) > > check_fwd_msg.patch is a little nitpick, just to make sure everyone > understands the message. > > BTW why some messages in check_forwarders() are printed using 'print' and > others using logger? I would prefer to use logger for everything to make sure > that logs contain all the information, including warnings. > > Thank you for your time! > Thank you, fixed. I added missing except block after forwarders validation step2. Updated patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0233.4-DNSSEC-Improve-global-forwarders-validation.patch Type: text/x-patch Size: 16165 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0234.4-DNSSEC-validate-forward-zone-forwarders.patch Type: text/x-patch Size: 16709 bytes Desc: not available URL: From pvoborni at redhat.com Thu May 7 16:17:42 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 07 May 2015 18:17:42 +0200 Subject: [Freeipa-devel] [PATCH] 823 ipaldap: raise DatabaseError on unbind if disconnected In-Reply-To: <554B8D26.70904@redhat.com> References: <5538C84C.9020407@redhat.com> <5538E1CB.8040705@redhat.com> <1429820290.5680.7.camel@redhat.com> <5539D24B.5050600@redhat.com> <553A298E.2020807@redhat.com> <554B8D26.70904@redhat.com> Message-ID: <554B9026.6090507@redhat.com> On 05/07/2015 06:04 PM, Martin Babinsky wrote: > On 04/24/2015 01:31 PM, Petr Vobornik wrote: >> On 04/24/2015 07:19 AM, Jan Cholasta wrote: >>> Dne 23.4.2015 v 22:18 Nathaniel McCallum napsal(a): >>>> On Thu, 2015-04-23 at 14:12 +0200, Petr Vobornik wrote: >>>>> On 04/23/2015 12:24 PM, Petr Vobornik wrote: >>>>>> If unbind was called when disconnected it raised: >>>>>> AttributeError: 'NoneType' object has no attribute 'unbind_s' >>>>>> >>>>>> AttributeError is not a public error and therefore it prevented >>>>>> ldap2.destroy_connection() to be called multiple times. >>>>>> >>>>>> >>>>> >>>>> After discussion with Honza, the approach was changed. >>>>> >>>>> Also I've added patch which removes unnecessary incorrect code which >>>>> revealed the regression. >>>>> >>>>> Additional testing shows that these patches actually don't fix the >>>>> original issue of #4991. See >>>>> https://fedorahosted.org/freeipa/ticket/4991#comment:4 >>>> >>>> 0823 - ACK >>>> 0824 - ACK >>>> >>>> Nathaniel >>>> >>> >>> I would prefer if the connection was closed manually in patch 824, IMO >>> it is a good practice to release resources once you are done with them >>> just in time, and I don't think you can always trust the automatic >>> disconnect at the end of request. >>> >> >> Changed (also in user-status command). >> >> >> > ACK > 823-2: Pushed to master: 7d10547ae3098b96762846ff36e813042a503d59 824-2: Pushed to master: 375eb7583334f231c27420c80b1b074e0cc554fe -- Petr Vobornik From mbasti at redhat.com Thu May 7 17:01:03 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 07 May 2015 19:01:03 +0200 Subject: [Freeipa-devel] [PATCH] 814-818 migrate-ds: optimize adding users to default group In-Reply-To: <554B49D3.5090901@redhat.com> References: <5527AC09.7060707@redhat.com> <554233E4.5040608@redhat.com> <55488687.9070407@redhat.com> <554A2A13.7030005@redhat.com> <554B49D3.5090901@redhat.com> Message-ID: <554B9A4F.3080500@redhat.com> On 07/05/15 13:17, Petr Vobornik wrote: > On 05/06/2015 04:49 PM, Martin Basti wrote: >> On 05/05/15 10:59, Petr Vobornik wrote: >>> On 04/30/2015 03:53 PM, Martin Basti wrote: >>>> On 10/04/15 12:55, Petr Vobornik wrote: >>>>> The essential patch is 814. >>>>> >>>>> 815 a proposal for new option. >>>>> >>>>> 816 and 818 are cleanup patches. >>>>> >>>>> 817 little optimization. >>>>> >>>>> == [PATCH] 814 migrate-ds: optimize adding users to default group == >>>>> Migrate-ds searches for user without a group and adds them to default >>>>> group. There is no point in checking if the user's selected by >>>>> previous query are not member of default group because they are not >>>>> member of any group. >>>>> >>>>> The operation is also speeded up by not fetching the default group. >>>>> Users are added right away. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4950 >>>>> >>>> NACK >>>> >>>> Users haven't been added into ipa default group after migration. >>> >>> Fixed in patch 815. >>> >>>> >>>> Just nitpick >>>> >>>> 1) too many parentheses >>>> api.log.error(('Adding new members to default group >>>> failed: >>>> %s \n' >>>> 'members: %s') % (e, >>>> (','.join(member_dns)))) >>>> You can use this instead: >>>> api.log.error('Adding new members to default group >>>> failed: >>>> %s \n' >>>> 'members: %s', e, ','.join(member_dns)) >>> >>> Fixed. >>> >>>> >>>> == [PATCH] 815 migrate-ds: skip default group options == >>>>> New option --use-default-group=False could be used to disable >>>>> adding of >>>>> migrated users into default group. >>>>> >>>>> By default, the default group is no longer POSIX therefore it doesn't >>>>> fulfill the original idea of providing GID and therefore it could be >>>>> skipped during migration. >>>> LGTM >>> >>> the option got so the default would be applied. >>> + autofill=True, >>> >>> >>>>> >>>>> == [PATCH] 816 migrate-ds: remove unused def_group_gid context >>>>> property == >>>>> it's no longer used anywhere >>>>> >>>> 1) >>>> You can remove the unused variable 'g_attrs' >>> >>> removed >>> >>>>> == [PATCH] 817 migrate-ds: optimize gid checks by utilizing >>>>> dictionary >>>>> nature of set == >>>>> >>>> LGTM >>>>> == [PATCH] 818 migrate-ds: log migrated group members only on debug >>>>> level == >>>>> It pollutes error_log. >>>>> >>>> 1) >>>> you do not need % formatting in logger >>>> api.log.debug('migrating %s group %s' , member_attr, m) >>> >>> fixed and also changed "migrating %s user %s'" line to debug, which >>> was the actual reason for this patch. >>> >>>>> >>>>> >>>> >>>> Martin^2 >>>> >>> >>> >> Thanks. >> >> 1) >> Please create new API file, probably missing autofill in API.txt: >> >> Option 'use_def_group?' in command 'migrate_ds' in API file not found >> Options count in migrate_ds of 18 doesn't match expected: 19 >> Option use_def_group? of command migrate_ds in ipalib, not in API file: >> Bool('use_def_group?', autofill=True, cli_name='use_default_group', >> default=True) >> >> There are one or more changes to the API. >> Either undo the API changes or update API.txt and increment the major >> version in VERSION. > > you could just wrote that I forgot to run ./makeapi ;) > >> >> 2) >> ipa: error: --use-default-group option does not take a value > > Attached new patch #826 which should fix the issue. Not sure if > Honza(CCd) will like it. > > "(default: true)" added to option description for better UX. > >> >> and a nitpick: >> >> patch 814 >> 1) >> Why this change? >> >> - api.log.debug('Adding %d users to group%s duration %s', >> - len(new_members), mode, d) >> + api.log.info('Adding %d users to group%s duration %s', >> + len(member_dns), mode, d) > > So that there will be a record in a default(not debug) log that > something happened. The reason is that it also affects users, without > a group, that are already present on the system. > As we personally talked with Honza, and he agreed with param modification, then ACK for all patches. -- Martin Basti From pvoborni at redhat.com Thu May 7 17:24:57 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 07 May 2015 19:24:57 +0200 Subject: [Freeipa-devel] [PATCH] 828 webui: don't log in back after logout Message-ID: <554B9FE9.2070503@redhat.com> Automatic login attempt is initiated by first failed xhr request which happens in metadata phase. New phase was added before metadata phase. It interrupts UI load and shows login page if it's directly after logout(marked in session storage). Successfull manual login resolves the phase so that metadata phase can follow. https://fedorahosted.org/freeipa/ticket/5008 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0828-webui-don-t-log-in-back-after-logout.patch Type: text/x-patch Size: 2774 bytes Desc: not available URL: From mbasti at redhat.com Thu May 7 17:54:08 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 07 May 2015 19:54:08 +0200 Subject: [Freeipa-devel] [PATCHES 0231-0232] Server Upgrade: support base64 encoded values in update files + remove CSV In-Reply-To: <554B2BD7.2020300@redhat.com> References: <552FD1C0.2040104@redhat.com> <5538D21A.8040000@redhat.com> <553E1802.8050409@redhat.com> <553E4BD7.4010707@redhat.com> <55409129.8020606@redhat.com> <5549F857.2060008@redhat.com> <554B2BD7.2020300@redhat.com> Message-ID: <554BA6C0.1020205@redhat.com> On 07/05/15 11:09, Martin Basti wrote: > On 06/05/15 13:17, Martin Basti wrote: >> On 29/04/15 10:07, Jan Cholasta wrote: >>> Dne 27.4.2015 v 16:46 Martin Basti napsal(a): >>>> On 27/04/15 13:05, Martin Basti wrote: >>>>> On 23/04/15 13:06, Martin Basti wrote: >>>>>> On 16/04/15 17:14, Martin Basti wrote: >>>>>>> https://fedorahosted.org/freeipa/ticket/4984 >>>>>>> >>>>>>> I had to remove CSV (which is evil) to be able fix this ticket. >>>>>>> >>>>>>> Patches attached. >>>>>>> >>>>>>> >>>>>>> >>>>>> Updated patches attached. >>>>>> >>>>>> -- >>>>>> Martin Basti >>>>>> >>>>>> >>>>> Rebased patches attached. >>>>> >>>>> -- >>>>> Martin Basti >>>>> >>>>> >>>> rebased patches attached >>>> >>>> -- >>>> Martin Basti >>>> >>>> >>>> >>> >>> ACK on patch 231. >>> >>> BTW I have found a 7 year old bug caused by CSV while reviewing it: >>> . >>> >>> There is also similar git-only bug in >>> install/updates/10-uniqueness.update: >>> >>> default:uniqueness-subtrees: 'cn=accounts,$SUFFIX' >>> default:uniqueness-subtrees: 'cn=deleted >>> users,cn=accounts,cn=provisioning,$SUFFIX' >>> >>> but your patch fixes it. >>> >>> I will review patch 232 later. >>> >>> Honza >>> >> Honza doesn't like original 232 so much. >> >> Updated patch 232 attached >> >> >> > Updated patch 232 attached > > -- > Martin Basti > > Updated patches attached. -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0231.7-Server-Upgrade-remove-CSV-from-upgrade-files.patch Type: text/x-patch Size: 128933 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0232.7-Server-Upgrade-Allow-base64-encoded-values.patch Type: text/x-patch Size: 16946 bytes Desc: not available URL: From abokovoy at redhat.com Fri May 8 13:07:53 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 8 May 2015 16:07:53 +0300 Subject: [Freeipa-devel] [PATCH] 0178 Fix AD trusts in Fedora 22 Message-ID: <20150508130753.GA4748@onega.vda.li> Hi, attached patch fixes issues with Samba 4.2 in Fedora 22. See commit message for the details. Note that you'll also need Samba fixes from https://bugzilla.redhat.com/show_bug.cgi?id=1219832 to test the patch. Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1219834 -- / Alexander Bokovoy -------------- next part -------------- From 35ab765554e3469daae204fb045eb4281f4f4f36 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 8 May 2015 12:09:13 +0000 Subject: [PATCH] ipaserver/dcerpc: Ensure LSA pipe has session key before using it With Samba 4.2 there is a bug that prevents Samba to consider Kerberos credentials used by IPA httpd process when talking to smbd. As result, LSA RPC connection is seen as anonymous by Samba client code and we cannot derive session key to use for encrypting trust secrets before transmitting them. Additionally, rewrite of the SMB protocol support in Samba caused previously working logic of choosing DCE RPC binding string to fail. We need to try a different set of priorities until they fail or succeed. Requires Samba fixes from https://bugzilla.redhat.com/show_bug.cgi?id=1219832 Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1219834 --- ipaserver/dcerpc.py | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index e342c49..25f8bf8 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -89,6 +89,10 @@ dcerpc_error_codes = { -1073741811: # NT_STATUS_INVALID_PARAMETER errors.RemoteRetrieveError( reason=_('AD domain controller complains about communication sequence. It may mean unsynchronized time on both sides, for example')), + -1073741776: # NT_STATUS_INVALID_PARAMETER_MIX, we simply will skip the binding + access_denied_error, + -1073741772: # NT_STATUS_OBJECT_NAME_NOT_FOUND + errors.RemoteRetrieveError(reason=_('CIFS server configuration does not allow access to \\\\pipe\\lsarpc')), } dcerpc_error_messages = { @@ -728,16 +732,20 @@ class TrustDomainInstance(object): return attempts = 0 + session_attempts = 0 bindings = self.__gen_lsa_bindings(remote_host) for binding in bindings: try: self._pipe = self.__gen_lsa_connection(binding) - if self._pipe: + if self._pipe and self._pipe.session_key: break except errors.ACIError, e: attempts = attempts + 1 + except RuntimeError, e: + # When session key is not available, we just skip this binding + session_attempts = session_attempts + 1 - if self._pipe is None and attempts == len(bindings): + if self._pipe is None and (attempts + session_attemps) == len(bindings): raise errors.ACIError( info=_('CIFS server %(host)s denied your credentials') % dict(host=remote_host)) @@ -745,6 +753,7 @@ class TrustDomainInstance(object): raise errors.RemoteRetrieveError( reason=_('Cannot establish LSA connection to %(host)s. Is CIFS server running?') % dict(host=remote_host)) self.binding = binding + self.session_key = self._pipe.session_key def __gen_lsa_bindings(self, remote_host): """ @@ -753,11 +762,11 @@ class TrustDomainInstance(object): Generate all we can use. init_lsa_pipe() will try them one by one until there is one working. - We try NCACN_NP before NCACN_IP_TCP and signed sessions before unsigned. + We try NCACN_NP before NCACN_IP_TCP and use SMB2 before SMB1 or defaults. """ transports = (u'ncacn_np', u'ncacn_ip_tcp') - options = ( u',', u'') - binding_template=lambda x,y,z: u'%s:%s[%s]' % (x, y, z) + options = ( u'smb2', u'smb1', u'') + binding_template=lambda x,y,z: u'%s:%s[%s,print]' % (x, y, z) return [binding_template(t, remote_host, o) for t in transports for o in options] def retrieve_anonymously(self, remote_host, discover_srv=False, search_pdc=False): -- 2.4.0 From mbabinsk at redhat.com Mon May 11 09:47:43 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 11 May 2015 11:47:43 +0200 Subject: [Freeipa-devel] [PATCH] 819-820 jQuery.ordered_map: faster creation In-Reply-To: <5531195C.4020105@redhat.com> References: <5531195C.4020105@redhat.com> Message-ID: <55507ABF.2020900@redhat.com> On 04/17/2015 04:31 PM, Petr Vobornik wrote: > Improve performance of Web UI with very large user groups or any other > usage which adds a lot of values into jQuery.ordered_map. > > ACK -- Martin^3 Babinsky From mkubik at redhat.com Mon May 11 11:25:18 2015 From: mkubik at redhat.com (Milan Kubik) Date: Mon, 11 May 2015 13:25:18 +0200 Subject: [Freeipa-devel] [PATCH] 801-806 webui-ci: otptoken tests In-Reply-To: <554B4E9F.1070806@redhat.com> References: <54E5F888.2000402@redhat.com> <554B4E9F.1070806@redhat.com> Message-ID: <5550919E.9090802@redhat.com> On 05/07/2015 01:38 PM, Petr Vobornik wrote: > On 02/19/2015 03:51 PM, Petr Vobornik wrote: >> https://fedorahosted.org/freeipa/ticket/4307 >> >> For ipa-4-1 apply: >> - patch 800 (different thread) >> - patches 801-806 >> >> For master apply: >> - patch 800 (different thread) >> - patch 807 (different thread) >> - patch 801-master >> - patches 802-806 >> >> Patch 801 allows to use ipalib rpc client in Web UI test suite. >> Patches 802-805 are various ui_driver fixes to allow stuff in patch 806. >> >> == [PATCH] 806 webui-ci: otptoken tests == >> >> Basic otptoken Web UI CI coverage. >> >> tests: >> * crud for otptokens as admin >> * crud for normal users >> * checks fields of adder dialog for both token types and user role >> (admin/user) >> * token actions as admin (enable, disable, delete) >> * token actions as normal user (delete) >> * login as normal user with hotp and totp token >> * sync token hotp and totp token as normal user and then login >> >> https://fedorahosted.org/freeipa/ticket/4307 >> >> == [PATCH] 805 webui-ci: allow custom names for disable/enable >> actions == >> >> Not all disable and enable actions are called 'disable' and 'enable'. >> >> == [PATCH] 804 webui-ci: allow to update pkey in post-add in basic-crud >> tests == >> >> == [PATCH] 803 webui-ci: add post_add_action == >> >> post add action allows to fill autogenerated values, e.g. a pkey of new >> otptoken. >> >> This value can be then used in other subsequent test which would depend >> on it - like crud tests. >> >> == [PATCH] 802 webui-ci: fix negative visibility check == >> >> Allow to define, that element doesn't have to be present on a page for >> negative visible checks. >> >> E.g. if element is added only if it's displayed and is removed >> otherwise. >> >> == [PATCH] 801 webui-ci: support direct IPA API calls == >> >> Add IPA API support to ui_driver. It leverages new ipalib RPC client's >> forms based authentication. It then allows to call an IPA API while >> the machine is not an IPA client nor is kerberized. >> >> api's environment values are taken from test configuration and >> therefore duplication in ~/.ipa/default.conf is not required. >> >> Since the machine doesn't have to be IPA client, it then also doesn't >> have nss database with IPA's CA certificate. Therefore on each API >> initialization a new NSS database is created with a CA certificate >> downloaded from IPA. This db is deleted in tearDown phase. >> >> Usage: >> >> 1. as admin one can immediately call rpc commands, api will be >> initialized upon first request and is available under self.api >> (assuming self is ui_driver): >> self.api.Command.user_del(USER_ID, **{'continue': True}) >> >> 2. to reconnect as other user: >> self.reconnect_api(USER_ID, USER_PW) >> >> 3. reconnect back as admin: >> self.reconnect_api() >> > > Patch #803 needed rebase. > > Hi, thanks for the patches. Please, fix pep8 complaints in 803, 805 and 806. Also, change the header in 806 to the shorter version, please. # # Copyright (C) 2015 FreeIPA Contributors see COPYING for license # Patches 801, 802 and 804 look good to me. The test cases in 806 look good to me as well. Milan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Mon May 11 11:41:35 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 11 May 2015 13:41:35 +0200 Subject: [Freeipa-devel] [PATCH 424] install: Introduce installer framework ipapython.install In-Reply-To: <5549B319.2060109@redhat.com> References: <552FCB4E.4050402@redhat.com> <5531157F.80106@redhat.com> <5534FBB6.3050001@redhat.com> <553513A7.3070704@redhat.com> <554105ED.90204@redhat.com> <5549B079.5020007@redhat.com> <5549B319.2060109@redhat.com> Message-ID: <5550956F.9080002@redhat.com> Dne 6.5.2015 v 08:22 Jan Cholasta napsal(a): > Dne 6.5.2015 v 08:11 Martin Kosek napsal(a): >> On 04/29/2015 06:25 PM, Jan Cholasta wrote: >>> Dne 20.4.2015 v 16:56 Jan Cholasta napsal(a): >>>> Dne 20.4.2015 v 15:14 Martin Basti napsal(a): >>>>> On 17/04/15 16:15, Jan Cholasta wrote: >>>>>> Dne 16.4.2015 v 16:46 Jan Cholasta napsal(a): >>>>>>> Hi, >>>>>>> >>>>>>> the attached patch adds the basics of the new installer framework. >>>>>>> >>>>>>> As a next step, I plan to convert the install scripts to use the >>>>>>> framework with their old code (the old code will be gradually >>>>>>> ported to >>>>>>> the framework later). >>>>>>> >>>>>>> (Note I didn't manage to write docstrings today, expect update >>>>>>> tomorrow.) >>>>>> >>>>>> Added some docstrings. >>>>>> >>>>>> Also updated the patch to reflect little brainstorming David and I >>>>>> had >>>>>> this morning. >>>>>> >>>>>>> >>>>>>> Honza >>>>>> >>>>>> >>>>>> >>>>> Hello, see comments bellow: >>>>> >>>>> 1) We started using new shorter License header in files: >>>>> # >>>>> # Copyright (C) 2015 FreeIPA Contributors see COPYING for license >>>>> # >>>> >>>> OK. >>>> >>>>> >>>>> 2) IMO this will not work, NoneType has no 'obj' attribute >>>>> + else: >>>>> + if isinstance(value, from_): >>>>> + value = None >>>>> + stack.append(value.obj) >>>>> + continue >>>> >>>> Right. >>>> >>>>> >>>>> 3) Multiple inheritance. I do not like it much. >>>>> +class CompositeInstaller(Installer, CompositeConfigurator): >>>> >>>> I guess you are antagonistic to multiple inheritance because of how >>>> other languages (like C++) do it. In Python it can be pretty elegant >>>> and >>>> is basis for e.g. the mixin design pattern. >>>> >>>>> >>>>> Installer and CompositeConfigurator inherites from Configurator class, >>>>> and all of them implements _generator method. >>>> >>>> Both of them call super()._generator(), so it's no problem (same for >>>> other methods). >>>> >>>>> >>>>> If I understand correctly >>>>> (https://www.python.org/download/releases/2.3/mro/) the >>>>> Installer._generator method will be used in this case. >>>>> However in case when CompositeConfigurator has more levels >>>>> (respectively >>>>> it is more specialized) of inheritance, it could take precedence >>>>> and its >>>>> _generator method may be used instead. >>>> >>>> The order of precedence is defined by the order of base classes in the >>>> class definition. >>>> >>>>> >>>>> I'm afraid this may suddenly stop working. >>>>> Maybe I'm wrong, please fix me. >>>> >>>> As long as you call the super class, it will work fine. >>>> >>>>> >>>>> And Multiple inheritance is not easily readable, this is even a >>>>> diamond >>>>> inheritance model. >>>> >>>> Cooperative inheritance is used by design and IMHO is easily >>>> readable if >>>> you know how to read it. Every class defines a single bit of behavior. >>>> Without cooperative inheritance, it would have to be hardcoded and/or >>>> hacked around, which I wanted to avoid. >>>> >>>> This blog post explains it nicely: >>>> . >>>> >>> >>> Updated patch attached. >>> >>> Also attached is patch 425 which migrates ipa-server-install to the >>> install >>> framework. >> >> Good job there. I am just curious, will this framework and new option >> processing be friendly to other types of option passing than just via >> options? >> I mean tickets >> >> https://fedorahosted.org/freeipa/ticket/4517 >> https://fedorahosted.org/freeipa/ticket/4468 >> >> Especially 4517 is important, we need to be able to run >> >> # cat install.conf >> ds_password=Secret123 >> admin_password=Secret456 >> ip_address=123456 >> setup_dns=False >> >> # ipa-server-install --unattended --conf install.conf >> >> I assume yes, but I am just making sure. > > Yes, definitely. > Updated patches attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-424.3-install-Introduce-installer-framework-ipapython.inst.patch Type: text/x-patch Size: 33740 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-425.1-install-Migrate-ipa-server-install-to-the-install-fr.patch Type: text/x-patch Size: 129601 bytes Desc: not available URL: From lkrispen at redhat.com Mon May 11 12:15:26 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Mon, 11 May 2015 14:15:26 +0200 Subject: [Freeipa-devel] Domain Level feature kick-off In-Reply-To: <5549C2DB.5000605@redhat.com> References: <5549C2DB.5000605@redhat.com> Message-ID: <55509D5E.3090208@redhat.com> On 05/06/2015 09:29 AM, Martin Kosek wrote: > Hello, > > as already discussed in December [1], we will need to implement domain levels > in FreeIPA 4.2 to make sure we can manage the replication agreement by Topology > plugin. > > I created a ticket for this feature [3] and linked it with Simo's design. The > proposed scope for the feature is written in the ticket itself. Tomas agreed he > would work on this. > > The first consumer is Ludwig's topology plugin. Seeing Ludwig's initial patches > [4], I suspect he chose a different format (major/minor) for the domain level > value, but as we discussed in [2], it will rather be a numerical value, raised > only when needed. This is something for Tomas and Ludwig to coordinate together. the topology plugin also accepts a single numerical value, eg 3. It will internally parse this to 3.0 and use this. > > I am not sure if Custodia work will need this, maybe the new > ipa-replica-install would just check if Custodia is there or not and not decide > on Domain Levels... we will see. > > The design page does not list the actual API, but I expect it to be very simple > for now, maybe just > > $ ipa domainlevel-show > $ ipa domainlevel-raise NUMBER > > Makes sense? > > [1] http://www.redhat.com/archives/freeipa-devel/2014-December/msg00199.html > [2] http://www.redhat.com/archives/freeipa-devel/2014-December/msg00221.html > [3] https://fedorahosted.org/freeipa/ticket/5018 > [4] http://www.redhat.com/archives/freeipa-devel/2015-April/msg00096.html > From jcholast at redhat.com Mon May 11 13:18:29 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 11 May 2015 15:18:29 +0200 Subject: [Freeipa-devel] Domain Level feature kick-off In-Reply-To: <5549C2DB.5000605@redhat.com> References: <5549C2DB.5000605@redhat.com> Message-ID: <5550AC25.1030802@redhat.com> Dne 6.5.2015 v 09:29 Martin Kosek napsal(a): > Hello, > > as already discussed in December [1], we will need to implement domain levels > in FreeIPA 4.2 to make sure we can manage the replication agreement by Topology > plugin. > > I created a ticket for this feature [3] and linked it with Simo's design. The > proposed scope for the feature is written in the ticket itself. Tomas agreed he > would work on this. > > The first consumer is Ludwig's topology plugin. Seeing Ludwig's initial patches > [4], I suspect he chose a different format (major/minor) for the domain level > value, but as we discussed in [2], it will rather be a numerical value, raised > only when needed. This is something for Tomas and Ludwig to coordinate together. > > I am not sure if Custodia work will need this, maybe the new > ipa-replica-install would just check if Custodia is there or not and not decide > on Domain Levels... we will see. > > The design page does not list the actual API, but I expect it to be very simple > for now, maybe just > > $ ipa domainlevel-show > $ ipa domainlevel-raise NUMBER I would think $ ipa domain-show $ ipa domain-set-level NUMBER because "domain level" does not sound like an object, but rather a "level" property of a "domain" object. > > Makes sense? > > [1] http://www.redhat.com/archives/freeipa-devel/2014-December/msg00199.html > [2] http://www.redhat.com/archives/freeipa-devel/2014-December/msg00221.html > [3] https://fedorahosted.org/freeipa/ticket/5018 > [4] http://www.redhat.com/archives/freeipa-devel/2015-April/msg00096.html > -- Jan Cholasta From mkosek at redhat.com Mon May 11 13:34:39 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 11 May 2015 15:34:39 +0200 Subject: [Freeipa-devel] Domain Level feature kick-off In-Reply-To: <5550AC25.1030802@redhat.com> References: <5549C2DB.5000605@redhat.com> <5550AC25.1030802@redhat.com> Message-ID: <5550AFEF.9010100@redhat.com> On 05/11/2015 03:18 PM, Jan Cholasta wrote: > Dne 6.5.2015 v 09:29 Martin Kosek napsal(a): >> Hello, >> >> as already discussed in December [1], we will need to implement domain levels >> in FreeIPA 4.2 to make sure we can manage the replication agreement by Topology >> plugin. >> >> I created a ticket for this feature [3] and linked it with Simo's design. The >> proposed scope for the feature is written in the ticket itself. Tomas agreed he >> would work on this. >> >> The first consumer is Ludwig's topology plugin. Seeing Ludwig's initial patches >> [4], I suspect he chose a different format (major/minor) for the domain level >> value, but as we discussed in [2], it will rather be a numerical value, raised >> only when needed. This is something for Tomas and Ludwig to coordinate together. >> >> I am not sure if Custodia work will need this, maybe the new >> ipa-replica-install would just check if Custodia is there or not and not decide >> on Domain Levels... we will see. >> >> The design page does not list the actual API, but I expect it to be very simple >> for now, maybe just >> >> $ ipa domainlevel-show >> $ ipa domainlevel-raise NUMBER > > I would think > > $ ipa domain-show > $ ipa domain-set-level NUMBER > > because "domain level" does not sound like an object, but rather a "level" > property of a "domain" object. I think the point here was that the Domain Level is a separate LDAP object with just that value. So the naming seemed pretty self-explanatory and consistent to me. With using just "domain-*" we are blocking ourselves for the time when real "Domain" object shows up. > >> >> Makes sense? >> >> [1] http://www.redhat.com/archives/freeipa-devel/2014-December/msg00199.html >> [2] http://www.redhat.com/archives/freeipa-devel/2014-December/msg00221.html >> [3] https://fedorahosted.org/freeipa/ticket/5018 >> [4] http://www.redhat.com/archives/freeipa-devel/2015-April/msg00096.html >> > > From jcholast at redhat.com Mon May 11 13:50:23 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 11 May 2015 15:50:23 +0200 Subject: [Freeipa-devel] Domain Level feature kick-off In-Reply-To: <5550AFEF.9010100@redhat.com> References: <5549C2DB.5000605@redhat.com> <5550AC25.1030802@redhat.com> <5550AFEF.9010100@redhat.com> Message-ID: <5550B39F.1040800@redhat.com> Dne 11.5.2015 v 15:34 Martin Kosek napsal(a): > On 05/11/2015 03:18 PM, Jan Cholasta wrote: >> Dne 6.5.2015 v 09:29 Martin Kosek napsal(a): >>> Hello, >>> >>> as already discussed in December [1], we will need to implement domain levels >>> in FreeIPA 4.2 to make sure we can manage the replication agreement by Topology >>> plugin. >>> >>> I created a ticket for this feature [3] and linked it with Simo's design. The >>> proposed scope for the feature is written in the ticket itself. Tomas agreed he >>> would work on this. >>> >>> The first consumer is Ludwig's topology plugin. Seeing Ludwig's initial patches >>> [4], I suspect he chose a different format (major/minor) for the domain level >>> value, but as we discussed in [2], it will rather be a numerical value, raised >>> only when needed. This is something for Tomas and Ludwig to coordinate together. >>> >>> I am not sure if Custodia work will need this, maybe the new >>> ipa-replica-install would just check if Custodia is there or not and not decide >>> on Domain Levels... we will see. >>> >>> The design page does not list the actual API, but I expect it to be very simple >>> for now, maybe just >>> >>> $ ipa domainlevel-show >>> $ ipa domainlevel-raise NUMBER >> >> I would think >> >> $ ipa domain-show >> $ ipa domain-set-level NUMBER >> >> because "domain level" does not sound like an object, but rather a "level" >> property of a "domain" object. > > I think the point here was that the Domain Level is a separate LDAP object with > just that value. So the naming seemed pretty self-explanatory and consistent to me. That seems to me like an implementation detail rather than something against which to model the API. (Come on, singleton object with a single property?) > > With using just "domain-*" we are blocking ourselves for the time when real > "Domain" object shows up. I don't see why it should. Anyway, I don't have a strong opinion on this, except I like "set" better than "raise". -- Jan Cholasta From mkosek at redhat.com Mon May 11 13:56:16 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 11 May 2015 15:56:16 +0200 Subject: [Freeipa-devel] Domain Level feature kick-off In-Reply-To: <5550B39F.1040800@redhat.com> References: <5549C2DB.5000605@redhat.com> <5550AC25.1030802@redhat.com> <5550AFEF.9010100@redhat.com> <5550B39F.1040800@redhat.com> Message-ID: <5550B500.2020607@redhat.com> On 05/11/2015 03:50 PM, Jan Cholasta wrote: > Dne 11.5.2015 v 15:34 Martin Kosek napsal(a): >> On 05/11/2015 03:18 PM, Jan Cholasta wrote: >>> Dne 6.5.2015 v 09:29 Martin Kosek napsal(a): >>>> Hello, >>>> >>>> as already discussed in December [1], we will need to implement domain levels >>>> in FreeIPA 4.2 to make sure we can manage the replication agreement by >>>> Topology >>>> plugin. >>>> >>>> I created a ticket for this feature [3] and linked it with Simo's design. The >>>> proposed scope for the feature is written in the ticket itself. Tomas >>>> agreed he >>>> would work on this. >>>> >>>> The first consumer is Ludwig's topology plugin. Seeing Ludwig's initial >>>> patches >>>> [4], I suspect he chose a different format (major/minor) for the domain level >>>> value, but as we discussed in [2], it will rather be a numerical value, raised >>>> only when needed. This is something for Tomas and Ludwig to coordinate >>>> together. >>>> >>>> I am not sure if Custodia work will need this, maybe the new >>>> ipa-replica-install would just check if Custodia is there or not and not >>>> decide >>>> on Domain Levels... we will see. >>>> >>>> The design page does not list the actual API, but I expect it to be very >>>> simple >>>> for now, maybe just >>>> >>>> $ ipa domainlevel-show >>>> $ ipa domainlevel-raise NUMBER >>> >>> I would think >>> >>> $ ipa domain-show >>> $ ipa domain-set-level NUMBER >>> >>> because "domain level" does not sound like an object, but rather a "level" >>> property of a "domain" object. >> >> I think the point here was that the Domain Level is a separate LDAP object with >> just that value. So the naming seemed pretty self-explanatory and consistent >> to me. > > That seems to me like an implementation detail rather than something against > which to model the API. (Come on, singleton object with a single property?) IIRC, that was the point. To have this value in a single LDAP object without other settings, so that components can simply "watch" this object or have syncrepl on it, without receiving false positives (as they would have with for example "config-*" object). >> With using just "domain-*" we are blocking ourselves for the time when real >> "Domain" object shows up. > > I don't see why it should. > > Anyway, I don't have a strong opinion on this, except I like "set" better than > "raise". I liked the raise more as it does not give people the hopes that domain level can be lowered once it was raised :-) From npmccallum at redhat.com Mon May 11 14:09:58 2015 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 11 May 2015 10:09:58 -0400 Subject: [Freeipa-devel] Fwd: [openssl-users] removing Kerberos support from OpenSSL In-Reply-To: <5548BB2F.8060006@redhat.com> References: <55487D88.7010909@openssl.org> <5548BB2F.8060006@redhat.com> Message-ID: <1431353398.2560.5.camel@redhat.com> Yes and no. The current Kerberos support is insecure and should not be used. The main problem is that the session key is reused for all TLS connections. This prevents perfect forward secrecy. That being said, we have been toying around with the idea of making a new standard for GSSAPI/TLS which uses a DH or a PAKE to ensure that both sides contribute entropy to a random encryption key. However, we have to get some of the other standards work off our plates before we can tackle such a large task. In short: existing Kerberos support should be removed from OpenSSL. Nathaniel On Tue, 2015-05-05 at 14:44 +0200, Petr Spacek wrote: > Hello! > > Is this somehow interesting for us? > > Petr^2 Spacek > > > -------- Forwarded Message -------- > Subject: [openssl-users] Kerberos > Date: Tue, 05 May 2015 09:21:28 +0100 > From: Matt Caswell > Reply-To: openssl-users at openssl.org > To: openssl-users at openssl.org, openssl-dev at openssl.org > > I am considering removing Kerberos support from OpenSSL 1.1.0. There > are > a number of problems with the functionality as it stands, and it > seems > to me to be a very rarely used feature. I'm interested in hearing any > opinions on this (either for or against). > > Thanks in advance for your input, > > Matt > _______________________________________________ > openssl-users mailing list > To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-users > From jcholast at redhat.com Mon May 11 14:13:38 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 11 May 2015 16:13:38 +0200 Subject: [Freeipa-devel] Domain Level feature kick-off In-Reply-To: <5550B500.2020607@redhat.com> References: <5549C2DB.5000605@redhat.com> <5550AC25.1030802@redhat.com> <5550AFEF.9010100@redhat.com> <5550B39F.1040800@redhat.com> <5550B500.2020607@redhat.com> Message-ID: <5550B912.2000200@redhat.com> Dne 11.5.2015 v 15:56 Martin Kosek napsal(a): > On 05/11/2015 03:50 PM, Jan Cholasta wrote: >> Dne 11.5.2015 v 15:34 Martin Kosek napsal(a): >>> On 05/11/2015 03:18 PM, Jan Cholasta wrote: >>>> Dne 6.5.2015 v 09:29 Martin Kosek napsal(a): >>>>> Hello, >>>>> >>>>> as already discussed in December [1], we will need to implement domain levels >>>>> in FreeIPA 4.2 to make sure we can manage the replication agreement by >>>>> Topology >>>>> plugin. >>>>> >>>>> I created a ticket for this feature [3] and linked it with Simo's design. The >>>>> proposed scope for the feature is written in the ticket itself. Tomas >>>>> agreed he >>>>> would work on this. >>>>> >>>>> The first consumer is Ludwig's topology plugin. Seeing Ludwig's initial >>>>> patches >>>>> [4], I suspect he chose a different format (major/minor) for the domain level >>>>> value, but as we discussed in [2], it will rather be a numerical value, raised >>>>> only when needed. This is something for Tomas and Ludwig to coordinate >>>>> together. >>>>> >>>>> I am not sure if Custodia work will need this, maybe the new >>>>> ipa-replica-install would just check if Custodia is there or not and not >>>>> decide >>>>> on Domain Levels... we will see. >>>>> >>>>> The design page does not list the actual API, but I expect it to be very >>>>> simple >>>>> for now, maybe just >>>>> >>>>> $ ipa domainlevel-show >>>>> $ ipa domainlevel-raise NUMBER >>>> >>>> I would think >>>> >>>> $ ipa domain-show >>>> $ ipa domain-set-level NUMBER >>>> >>>> because "domain level" does not sound like an object, but rather a "level" >>>> property of a "domain" object. >>> >>> I think the point here was that the Domain Level is a separate LDAP object with >>> just that value. So the naming seemed pretty self-explanatory and consistent >>> to me. >> >> That seems to me like an implementation detail rather than something against >> which to model the API. (Come on, singleton object with a single property?) > > IIRC, that was the point. To have this value in a single LDAP object without > other settings, so that components can simply "watch" this object or have > syncrepl on it, without receiving false positives (as they would have with for > example "config-*" object). OK, so it indeed is just an implementation detail - if it was possible to watch just a single attribute of an entry, it could be stored in more meaningful location, but it's not, so it can't. > >>> With using just "domain-*" we are blocking ourselves for the time when real >>> "Domain" object shows up. >> >> I don't see why it should. >> >> Anyway, I don't have a strong opinion on this, except I like "set" better than >> "raise". > > I liked the raise more as it does not give people the hopes that domain level > can be lowered once it was raised :-) > I like "set" because it is very explicit - "raise" not so much, it might mean "raise to specific value" or "raise by specific value" and maybe other things. -- Jan Cholasta From pvoborni at redhat.com Mon May 11 14:29:48 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 11 May 2015 16:29:48 +0200 Subject: [Freeipa-devel] Domain Level feature kick-off In-Reply-To: <5550B912.2000200@redhat.com> References: <5549C2DB.5000605@redhat.com> <5550AC25.1030802@redhat.com> <5550AFEF.9010100@redhat.com> <5550B39F.1040800@redhat.com> <5550B500.2020607@redhat.com> <5550B912.2000200@redhat.com> Message-ID: <5550BCDC.5070309@redhat.com> On 05/11/2015 04:13 PM, Jan Cholasta wrote: > Dne 11.5.2015 v 15:56 Martin Kosek napsal(a): >> On 05/11/2015 03:50 PM, Jan Cholasta wrote: >>> Dne 11.5.2015 v 15:34 Martin Kosek napsal(a): >>>> On 05/11/2015 03:18 PM, Jan Cholasta wrote: >>>>> Dne 6.5.2015 v 09:29 Martin Kosek napsal(a): >>>>>> Hello, >>>>>> >>>>>> as already discussed in December [1], we will need to implement >>>>>> domain levels >>>>>> in FreeIPA 4.2 to make sure we can manage the replication >>>>>> agreement by >>>>>> Topology >>>>>> plugin. >>>>>> >>>>>> I created a ticket for this feature [3] and linked it with Simo's >>>>>> design. The >>>>>> proposed scope for the feature is written in the ticket itself. Tomas >>>>>> agreed he >>>>>> would work on this. >>>>>> >>>>>> The first consumer is Ludwig's topology plugin. Seeing Ludwig's >>>>>> initial >>>>>> patches >>>>>> [4], I suspect he chose a different format (major/minor) for the >>>>>> domain level >>>>>> value, but as we discussed in [2], it will rather be a numerical >>>>>> value, raised >>>>>> only when needed. This is something for Tomas and Ludwig to >>>>>> coordinate >>>>>> together. >>>>>> >>>>>> I am not sure if Custodia work will need this, maybe the new >>>>>> ipa-replica-install would just check if Custodia is there or not >>>>>> and not >>>>>> decide >>>>>> on Domain Levels... we will see. >>>>>> >>>>>> The design page does not list the actual API, but I expect it to >>>>>> be very >>>>>> simple >>>>>> for now, maybe just >>>>>> >>>>>> $ ipa domainlevel-show >>>>>> $ ipa domainlevel-raise NUMBER >>>>> >>>>> I would think >>>>> >>>>> $ ipa domain-show >>>>> $ ipa domain-set-level NUMBER >>>>> >>>>> because "domain level" does not sound like an object, but rather a >>>>> "level" >>>>> property of a "domain" object. >>>> >>>> I think the point here was that the Domain Level is a separate LDAP >>>> object with >>>> just that value. So the naming seemed pretty self-explanatory and >>>> consistent >>>> to me. >>> >>> That seems to me like an implementation detail rather than something >>> against >>> which to model the API. (Come on, singleton object with a single >>> property?) >> >> IIRC, that was the point. To have this value in a single LDAP object >> without >> other settings, so that components can simply "watch" this object or have >> syncrepl on it, without receiving false positives (as they would have >> with for >> example "config-*" object). > > OK, so it indeed is just an implementation detail - if it was possible > to watch just a single attribute of an entry, it could be stored in more > meaningful location, but it's not, so it can't. > >> >>>> With using just "domain-*" we are blocking ourselves for the time >>>> when real >>>> "Domain" object shows up. >>> >>> I don't see why it should. >>> >>> Anyway, I don't have a strong opinion on this, except I like "set" >>> better than >>> "raise". >> >> I liked the raise more as it does not give people the hopes that >> domain level >> can be lowered once it was raised :-) >> > > I like "set" because it is very explicit - "raise" not so much, it might > mean "raise to specific value" or "raise by specific value" and maybe > other things. > +1 for domainlevel - there is no and most likely won't be a singleton domain object, hence domainlevel is the object. In other words: what domain? I would argue that the feature should be called a "realm level" because there is only one realm but multiple domains in the realm. +1 for set -- Petr Vobornik From jcholast at redhat.com Mon May 11 14:34:06 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 11 May 2015 16:34:06 +0200 Subject: [Freeipa-devel] Domain Level feature kick-off In-Reply-To: <5550BCDC.5070309@redhat.com> References: <5549C2DB.5000605@redhat.com> <5550AC25.1030802@redhat.com> <5550AFEF.9010100@redhat.com> <5550B39F.1040800@redhat.com> <5550B500.2020607@redhat.com> <5550B912.2000200@redhat.com> <5550BCDC.5070309@redhat.com> Message-ID: <5550BDDE.2020402@redhat.com> Dne 11.5.2015 v 16:29 Petr Vobornik napsal(a): > On 05/11/2015 04:13 PM, Jan Cholasta wrote: >> Dne 11.5.2015 v 15:56 Martin Kosek napsal(a): >>> On 05/11/2015 03:50 PM, Jan Cholasta wrote: >>>> Dne 11.5.2015 v 15:34 Martin Kosek napsal(a): >>>>> On 05/11/2015 03:18 PM, Jan Cholasta wrote: >>>>>> Dne 6.5.2015 v 09:29 Martin Kosek napsal(a): >>>>>>> Hello, >>>>>>> >>>>>>> as already discussed in December [1], we will need to implement >>>>>>> domain levels >>>>>>> in FreeIPA 4.2 to make sure we can manage the replication >>>>>>> agreement by >>>>>>> Topology >>>>>>> plugin. >>>>>>> >>>>>>> I created a ticket for this feature [3] and linked it with Simo's >>>>>>> design. The >>>>>>> proposed scope for the feature is written in the ticket itself. >>>>>>> Tomas >>>>>>> agreed he >>>>>>> would work on this. >>>>>>> >>>>>>> The first consumer is Ludwig's topology plugin. Seeing Ludwig's >>>>>>> initial >>>>>>> patches >>>>>>> [4], I suspect he chose a different format (major/minor) for the >>>>>>> domain level >>>>>>> value, but as we discussed in [2], it will rather be a numerical >>>>>>> value, raised >>>>>>> only when needed. This is something for Tomas and Ludwig to >>>>>>> coordinate >>>>>>> together. >>>>>>> >>>>>>> I am not sure if Custodia work will need this, maybe the new >>>>>>> ipa-replica-install would just check if Custodia is there or not >>>>>>> and not >>>>>>> decide >>>>>>> on Domain Levels... we will see. >>>>>>> >>>>>>> The design page does not list the actual API, but I expect it to >>>>>>> be very >>>>>>> simple >>>>>>> for now, maybe just >>>>>>> >>>>>>> $ ipa domainlevel-show >>>>>>> $ ipa domainlevel-raise NUMBER >>>>>> >>>>>> I would think >>>>>> >>>>>> $ ipa domain-show >>>>>> $ ipa domain-set-level NUMBER >>>>>> >>>>>> because "domain level" does not sound like an object, but rather a >>>>>> "level" >>>>>> property of a "domain" object. >>>>> >>>>> I think the point here was that the Domain Level is a separate LDAP >>>>> object with >>>>> just that value. So the naming seemed pretty self-explanatory and >>>>> consistent >>>>> to me. >>>> >>>> That seems to me like an implementation detail rather than something >>>> against >>>> which to model the API. (Come on, singleton object with a single >>>> property?) >>> >>> IIRC, that was the point. To have this value in a single LDAP object >>> without >>> other settings, so that components can simply "watch" this object or >>> have >>> syncrepl on it, without receiving false positives (as they would have >>> with for >>> example "config-*" object). >> >> OK, so it indeed is just an implementation detail - if it was possible >> to watch just a single attribute of an entry, it could be stored in more >> meaningful location, but it's not, so it can't. >> >>> >>>>> With using just "domain-*" we are blocking ourselves for the time >>>>> when real >>>>> "Domain" object shows up. >>>> >>>> I don't see why it should. >>>> >>>> Anyway, I don't have a strong opinion on this, except I like "set" >>>> better than >>>> "raise". >>> >>> I liked the raise more as it does not give people the hopes that >>> domain level >>> can be lowered once it was raised :-) >>> >> >> I like "set" because it is very explicit - "raise" not so much, it might >> mean "raise to specific value" or "raise by specific value" and maybe >> other things. >> > > +1 for domainlevel - there is no and most likely won't be a singleton > domain object, hence domainlevel is the object. But there is: api.env.basedn aka the suffix. > In other words: what > domain? I would argue that the feature should be called a "realm level" > because there is only one realm but multiple domains in the realm. That depends on the definition of "domain" :-) But I think "realm level" does indeed fit better in our Kerberos-centric world. > > +1 for set -- Jan Cholasta From mkosek at redhat.com Mon May 11 14:36:54 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 11 May 2015 16:36:54 +0200 Subject: [Freeipa-devel] Domain Level feature kick-off In-Reply-To: <5550BDDE.2020402@redhat.com> References: <5549C2DB.5000605@redhat.com> <5550AC25.1030802@redhat.com> <5550AFEF.9010100@redhat.com> <5550B39F.1040800@redhat.com> <5550B500.2020607@redhat.com> <5550B912.2000200@redhat.com> <5550BCDC.5070309@redhat.com> <5550BDDE.2020402@redhat.com> Message-ID: <5550BE86.8060205@redhat.com> On 05/11/2015 04:34 PM, Jan Cholasta wrote: > Dne 11.5.2015 v 16:29 Petr Vobornik napsal(a): >> On 05/11/2015 04:13 PM, Jan Cholasta wrote: >>> Dne 11.5.2015 v 15:56 Martin Kosek napsal(a): >>>> On 05/11/2015 03:50 PM, Jan Cholasta wrote: >>>>> Dne 11.5.2015 v 15:34 Martin Kosek napsal(a): >>>>>> On 05/11/2015 03:18 PM, Jan Cholasta wrote: >>>>>>> Dne 6.5.2015 v 09:29 Martin Kosek napsal(a): >>>>>>>> Hello, >>>>>>>> >>>>>>>> as already discussed in December [1], we will need to implement >>>>>>>> domain levels >>>>>>>> in FreeIPA 4.2 to make sure we can manage the replication >>>>>>>> agreement by >>>>>>>> Topology >>>>>>>> plugin. >>>>>>>> >>>>>>>> I created a ticket for this feature [3] and linked it with Simo's >>>>>>>> design. The >>>>>>>> proposed scope for the feature is written in the ticket itself. >>>>>>>> Tomas >>>>>>>> agreed he >>>>>>>> would work on this. >>>>>>>> >>>>>>>> The first consumer is Ludwig's topology plugin. Seeing Ludwig's >>>>>>>> initial >>>>>>>> patches >>>>>>>> [4], I suspect he chose a different format (major/minor) for the >>>>>>>> domain level >>>>>>>> value, but as we discussed in [2], it will rather be a numerical >>>>>>>> value, raised >>>>>>>> only when needed. This is something for Tomas and Ludwig to >>>>>>>> coordinate >>>>>>>> together. >>>>>>>> >>>>>>>> I am not sure if Custodia work will need this, maybe the new >>>>>>>> ipa-replica-install would just check if Custodia is there or not >>>>>>>> and not >>>>>>>> decide >>>>>>>> on Domain Levels... we will see. >>>>>>>> >>>>>>>> The design page does not list the actual API, but I expect it to >>>>>>>> be very >>>>>>>> simple >>>>>>>> for now, maybe just >>>>>>>> >>>>>>>> $ ipa domainlevel-show >>>>>>>> $ ipa domainlevel-raise NUMBER >>>>>>> >>>>>>> I would think >>>>>>> >>>>>>> $ ipa domain-show >>>>>>> $ ipa domain-set-level NUMBER >>>>>>> >>>>>>> because "domain level" does not sound like an object, but rather a >>>>>>> "level" >>>>>>> property of a "domain" object. >>>>>> >>>>>> I think the point here was that the Domain Level is a separate LDAP >>>>>> object with >>>>>> just that value. So the naming seemed pretty self-explanatory and >>>>>> consistent >>>>>> to me. >>>>> >>>>> That seems to me like an implementation detail rather than something >>>>> against >>>>> which to model the API. (Come on, singleton object with a single >>>>> property?) >>>> >>>> IIRC, that was the point. To have this value in a single LDAP object >>>> without >>>> other settings, so that components can simply "watch" this object or >>>> have >>>> syncrepl on it, without receiving false positives (as they would have >>>> with for >>>> example "config-*" object). >>> >>> OK, so it indeed is just an implementation detail - if it was possible >>> to watch just a single attribute of an entry, it could be stored in more >>> meaningful location, but it's not, so it can't. >>> >>>> >>>>>> With using just "domain-*" we are blocking ourselves for the time >>>>>> when real >>>>>> "Domain" object shows up. >>>>> >>>>> I don't see why it should. >>>>> >>>>> Anyway, I don't have a strong opinion on this, except I like "set" >>>>> better than >>>>> "raise". >>>> >>>> I liked the raise more as it does not give people the hopes that >>>> domain level >>>> can be lowered once it was raised :-) >>>> >>> >>> I like "set" because it is very explicit - "raise" not so much, it might >>> mean "raise to specific value" or "raise by specific value" and maybe >>> other things. >>> >> >> +1 for domainlevel - there is no and most likely won't be a singleton >> domain object, hence domainlevel is the object. > > But there is: api.env.basedn aka the suffix. > >> In other words: what >> domain? I would argue that the feature should be called a "realm level" >> because there is only one realm but multiple domains in the realm. > > That depends on the definition of "domain" :-) But I think "realm level" does > indeed fit better in our Kerberos-centric world. Maybe. But we try to hide Kerberos specifics... I think the idea was to make it sound similar to AD's Domain Functional Level. > >> >> +1 for set > From mkosek at redhat.com Mon May 11 15:02:59 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 11 May 2015 17:02:59 +0200 Subject: [Freeipa-devel] ipa-replica-manage del fails to delete host entry In-Reply-To: <554A1228.9030800@redhat.com> References: <554A0D63.50409@redhat.com> <554A1228.9030800@redhat.com> Message-ID: <5550C4A3.3020900@redhat.com> On 05/06/2015 03:07 PM, Tomas Babej wrote: > > > On 05/06/2015 02:47 PM, Ludwig Krispenz wrote: >> >> Hi, >> in recent posts about corrupted ruvs, there also was the error about failing >> cleanup, like: >> >> ipa-replica-manage del vm-162.idm.lab.eng.brq.redhat.com >> >> .. >> Failed to cleanup vm-162.idm.lab.eng.brq.redhat.com entries: Not allowed on >> non-leaf entry >> >> in the access log we see >> >> [06/May/2015:14:19:11 +0200]conn=30 op=17 SRCH >> base="cn=vm-162.idm.lab.eng.brq.redhat.com,cn=masters,cn=ipa,cn=etc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" >> scope=2 filter="(objectClass=*)" attrs=ALL >> >> [06/May/2015:14:19:11 +0200] conn=30 op=17 RESULT err=0 tag=101 nentries=6 >> etime=0 notes=U >> [06/May/2015:14:19:11 +0200] conn=30 op=18 DEL >> dn="cn=vm-162.idm.lab.eng.brq.redhat.com,cn=masters,cn=ipa,cn=etc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" >> >> [06/May/2015:14:19:11 +0200] conn=30 op=18 RESULT err=66 tag=107 nentries=0 >> etime=0 >> >> which means that there was an attempt to remove the host before the services >> >> in replica_cleanup we have: >> >> # delete master entry with all active services >> >> try: >> dn = DN(('cn', replica), ('cn', 'masters'), ('cn', 'ipa'),('cn', 'etc'), >> self.suffix) >> entries = self.conn.get_entries(dn, ldap.SCOPE_SUBTREE) >> if entries: >> entries.sort(key=len, reverse=True) >> for entry in entries: >> self.conn.delete_entry(entry) >> >> this intends to delete children befor the parent, as teh dns of children are >> longer, but get_entries does return a list of entries, not DNs, and so the >> sorting does not work as can be seen in this example: >> >> >>> list = [('123456','A'),('123','B'),('12345678','C')] >> >> >>> list.sort(key=len,reverse=True) >> >> >>> for l in list: >> >> ... print l >> >> ... >> >> ('123456', 'A') >> >> ('123', 'B') >> >> ('12345678', 'C') >> >> >> > > A quick fix would be to use key=lambda x: len(x.dn) then. > > Tomas Thanks. But please link the patch proposal to https://fedorahosted.org/freeipa/ticket/5019 to not loose track of it. Thanks, Martin From pspacek at redhat.com Mon May 11 15:42:29 2015 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 11 May 2015 17:42:29 +0200 Subject: [Freeipa-devel] Domain Level feature kick-off In-Reply-To: <5550BE86.8060205@redhat.com> References: <5549C2DB.5000605@redhat.com> <5550AC25.1030802@redhat.com> <5550AFEF.9010100@redhat.com> <5550B39F.1040800@redhat.com> <5550B500.2020607@redhat.com> <5550B912.2000200@redhat.com> <5550BCDC.5070309@redhat.com> <5550BDDE.2020402@redhat.com> <5550BE86.8060205@redhat.com> Message-ID: <5550CDE5.4020309@redhat.com> On 11.5.2015 16:36, Martin Kosek wrote: > On 05/11/2015 04:34 PM, Jan Cholasta wrote: >> Dne 11.5.2015 v 16:29 Petr Vobornik napsal(a): >>> On 05/11/2015 04:13 PM, Jan Cholasta wrote: >>>> Dne 11.5.2015 v 15:56 Martin Kosek napsal(a): >>>>> On 05/11/2015 03:50 PM, Jan Cholasta wrote: >>>>>> Dne 11.5.2015 v 15:34 Martin Kosek napsal(a): >>>>>>> On 05/11/2015 03:18 PM, Jan Cholasta wrote: >>>>>>>> Dne 6.5.2015 v 09:29 Martin Kosek napsal(a): >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> as already discussed in December [1], we will need to implement >>>>>>>>> domain levels >>>>>>>>> in FreeIPA 4.2 to make sure we can manage the replication >>>>>>>>> agreement by >>>>>>>>> Topology >>>>>>>>> plugin. >>>>>>>>> >>>>>>>>> I created a ticket for this feature [3] and linked it with Simo's >>>>>>>>> design. The >>>>>>>>> proposed scope for the feature is written in the ticket itself. >>>>>>>>> Tomas >>>>>>>>> agreed he >>>>>>>>> would work on this. >>>>>>>>> >>>>>>>>> The first consumer is Ludwig's topology plugin. Seeing Ludwig's >>>>>>>>> initial >>>>>>>>> patches >>>>>>>>> [4], I suspect he chose a different format (major/minor) for the >>>>>>>>> domain level >>>>>>>>> value, but as we discussed in [2], it will rather be a numerical >>>>>>>>> value, raised >>>>>>>>> only when needed. This is something for Tomas and Ludwig to >>>>>>>>> coordinate >>>>>>>>> together. >>>>>>>>> >>>>>>>>> I am not sure if Custodia work will need this, maybe the new >>>>>>>>> ipa-replica-install would just check if Custodia is there or not >>>>>>>>> and not >>>>>>>>> decide >>>>>>>>> on Domain Levels... we will see. >>>>>>>>> >>>>>>>>> The design page does not list the actual API, but I expect it to >>>>>>>>> be very >>>>>>>>> simple >>>>>>>>> for now, maybe just >>>>>>>>> >>>>>>>>> $ ipa domainlevel-show >>>>>>>>> $ ipa domainlevel-raise NUMBER >>>>>>>> >>>>>>>> I would think >>>>>>>> >>>>>>>> $ ipa domain-show >>>>>>>> $ ipa domain-set-level NUMBER >>>>>>>> >>>>>>>> because "domain level" does not sound like an object, but rather a >>>>>>>> "level" >>>>>>>> property of a "domain" object. >>>>>>> >>>>>>> I think the point here was that the Domain Level is a separate LDAP >>>>>>> object with >>>>>>> just that value. So the naming seemed pretty self-explanatory and >>>>>>> consistent >>>>>>> to me. >>>>>> >>>>>> That seems to me like an implementation detail rather than something >>>>>> against >>>>>> which to model the API. (Come on, singleton object with a single >>>>>> property?) >>>>> >>>>> IIRC, that was the point. To have this value in a single LDAP object >>>>> without >>>>> other settings, so that components can simply "watch" this object or >>>>> have >>>>> syncrepl on it, without receiving false positives (as they would have >>>>> with for >>>>> example "config-*" object). >>>> >>>> OK, so it indeed is just an implementation detail - if it was possible >>>> to watch just a single attribute of an entry, it could be stored in more >>>> meaningful location, but it's not, so it can't. It is perfectly possible with SyncRepl protocol. >>>>>>> With using just "domain-*" we are blocking ourselves for the time >>>>>>> when real >>>>>>> "Domain" object shows up. >>>>>> >>>>>> I don't see why it should. >>>>>> >>>>>> Anyway, I don't have a strong opinion on this, except I like "set" >>>>>> better than >>>>>> "raise". >>>>> >>>>> I liked the raise more as it does not give people the hopes that >>>>> domain level >>>>> can be lowered once it was raised :-) >>>>> >>>> >>>> I like "set" because it is very explicit - "raise" not so much, it might >>>> mean "raise to specific value" or "raise by specific value" and maybe >>>> other things. >>>> >>> >>> +1 for domainlevel - there is no and most likely won't be a singleton >>> domain object, hence domainlevel is the object. >> >> But there is: api.env.basedn aka the suffix. >> >>> In other words: what >>> domain? I would argue that the feature should be called a "realm level" >>> because there is only one realm but multiple domains in the realm. >> >> That depends on the definition of "domain" :-) But I think "realm level" does >> indeed fit better in our Kerberos-centric world. > > Maybe. But we try to hide Kerberos specifics... I think the idea was to make it > sound similar to AD's Domain Functional Level. So call it 'functional level' :-) -- Petr^2 Spacek From lkrispen at redhat.com Mon May 11 16:03:25 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Mon, 11 May 2015 18:03:25 +0200 Subject: [Freeipa-devel] Domain Level feature kick-off In-Reply-To: <5550CDE5.4020309@redhat.com> References: <5549C2DB.5000605@redhat.com> <5550AC25.1030802@redhat.com> <5550AFEF.9010100@redhat.com> <5550B39F.1040800@redhat.com> <5550B500.2020607@redhat.com> <5550B912.2000200@redhat.com> <5550BCDC.5070309@redhat.com> <5550BDDE.2020402@redhat.com> <5550BE86.8060205@redhat.com> <5550CDE5.4020309@redhat.com> Message-ID: <5550D2CD.3050202@redhat.com> On 05/11/2015 05:42 PM, Petr Spacek wrote: > On 11.5.2015 16:36, Martin Kosek wrote: >> On 05/11/2015 04:34 PM, Jan Cholasta wrote: >>> Dne 11.5.2015 v 16:29 Petr Vobornik napsal(a): >>>> On 05/11/2015 04:13 PM, Jan Cholasta wrote: >>>>> Dne 11.5.2015 v 15:56 Martin Kosek napsal(a): >>>>>> On 05/11/2015 03:50 PM, Jan Cholasta wrote: >>>>>>> Dne 11.5.2015 v 15:34 Martin Kosek napsal(a): >>>>>>>> On 05/11/2015 03:18 PM, Jan Cholasta wrote: >>>>>>>>> Dne 6.5.2015 v 09:29 Martin Kosek napsal(a): >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> as already discussed in December [1], we will need to implement >>>>>>>>>> domain levels >>>>>>>>>> in FreeIPA 4.2 to make sure we can manage the replication >>>>>>>>>> agreement by >>>>>>>>>> Topology >>>>>>>>>> plugin. >>>>>>>>>> >>>>>>>>>> I created a ticket for this feature [3] and linked it with Simo's >>>>>>>>>> design. The >>>>>>>>>> proposed scope for the feature is written in the ticket itself. >>>>>>>>>> Tomas >>>>>>>>>> agreed he >>>>>>>>>> would work on this. >>>>>>>>>> >>>>>>>>>> The first consumer is Ludwig's topology plugin. Seeing Ludwig's >>>>>>>>>> initial >>>>>>>>>> patches >>>>>>>>>> [4], I suspect he chose a different format (major/minor) for the >>>>>>>>>> domain level >>>>>>>>>> value, but as we discussed in [2], it will rather be a numerical >>>>>>>>>> value, raised >>>>>>>>>> only when needed. This is something for Tomas and Ludwig to >>>>>>>>>> coordinate >>>>>>>>>> together. >>>>>>>>>> >>>>>>>>>> I am not sure if Custodia work will need this, maybe the new >>>>>>>>>> ipa-replica-install would just check if Custodia is there or not >>>>>>>>>> and not >>>>>>>>>> decide >>>>>>>>>> on Domain Levels... we will see. >>>>>>>>>> >>>>>>>>>> The design page does not list the actual API, but I expect it to >>>>>>>>>> be very >>>>>>>>>> simple >>>>>>>>>> for now, maybe just >>>>>>>>>> >>>>>>>>>> $ ipa domainlevel-show >>>>>>>>>> $ ipa domainlevel-raise NUMBER >>>>>>>>> I would think >>>>>>>>> >>>>>>>>> $ ipa domain-show >>>>>>>>> $ ipa domain-set-level NUMBER >>>>>>>>> >>>>>>>>> because "domain level" does not sound like an object, but rather a >>>>>>>>> "level" >>>>>>>>> property of a "domain" object. >>>>>>>> I think the point here was that the Domain Level is a separate LDAP >>>>>>>> object with >>>>>>>> just that value. So the naming seemed pretty self-explanatory and >>>>>>>> consistent >>>>>>>> to me. >>>>>>> That seems to me like an implementation detail rather than something >>>>>>> against >>>>>>> which to model the API. (Come on, singleton object with a single >>>>>>> property?) >>>>>> IIRC, that was the point. To have this value in a single LDAP object >>>>>> without >>>>>> other settings, so that components can simply "watch" this object or >>>>>> have >>>>>> syncrepl on it, without receiving false positives (as they would have >>>>>> with for >>>>>> example "config-*" object). >>>>> OK, so it indeed is just an implementation detail - if it was possible >>>>> to watch just a single attribute of an entry, it could be stored in more >>>>> meaningful location, but it's not, so it can't. > It is perfectly possible with SyncRepl protocol. > >>>>>>>> With using just "domain-*" we are blocking ourselves for the time >>>>>>>> when real >>>>>>>> "Domain" object shows up. >>>>>>> I don't see why it should. >>>>>>> >>>>>>> Anyway, I don't have a strong opinion on this, except I like "set" >>>>>>> better than >>>>>>> "raise". >>>>>> I liked the raise more as it does not give people the hopes that >>>>>> domain level >>>>>> can be lowered once it was raised :-) >>>>>> >>>>> I like "set" because it is very explicit - "raise" not so much, it might >>>>> mean "raise to specific value" or "raise by specific value" and maybe >>>>> other things. >>>>> >>>> +1 for domainlevel - there is no and most likely won't be a singleton >>>> domain object, hence domainlevel is the object. >>> But there is: api.env.basedn aka the suffix. >>> >>>> In other words: what >>>> domain? I would argue that the feature should be called a "realm level" >>>> because there is only one realm but multiple domains in the realm. >>> That depends on the definition of "domain" :-) But I think "realm level" does >>> indeed fit better in our Kerberos-centric world. >> Maybe. But we try to hide Kerberos specifics... I think the idea was to make it >> sound similar to AD's Domain Functional Level. > So call it 'functional level' :-) This thread is about implementing the design provided in Simo's "domain level" design page, we had discussed this before, do we really need to iterate it again ? > From jcholast at redhat.com Mon May 11 16:08:24 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 11 May 2015 18:08:24 +0200 Subject: [Freeipa-devel] [PATCHES 0231-0232] Server Upgrade: support base64 encoded values in update files + remove CSV In-Reply-To: <554BA6C0.1020205@redhat.com> References: <552FD1C0.2040104@redhat.com> <5538D21A.8040000@redhat.com> <553E1802.8050409@redhat.com> <553E4BD7.4010707@redhat.com> <55409129.8020606@redhat.com> <5549F857.2060008@redhat.com> <554B2BD7.2020300@redhat.com> <554BA6C0.1020205@redhat.com> Message-ID: <5550D3F8.8000606@redhat.com> Dne 7.5.2015 v 19:54 Martin Basti napsal(a): > On 07/05/15 11:09, Martin Basti wrote: >> On 06/05/15 13:17, Martin Basti wrote: >>> On 29/04/15 10:07, Jan Cholasta wrote: >>>> Dne 27.4.2015 v 16:46 Martin Basti napsal(a): >>>>> On 27/04/15 13:05, Martin Basti wrote: >>>>>> On 23/04/15 13:06, Martin Basti wrote: >>>>>>> On 16/04/15 17:14, Martin Basti wrote: >>>>>>>> https://fedorahosted.org/freeipa/ticket/4984 >>>>>>>> >>>>>>>> I had to remove CSV (which is evil) to be able fix this ticket. >>>>>>>> >>>>>>>> Patches attached. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Updated patches attached. >>>>>>> >>>>>>> -- >>>>>>> Martin Basti >>>>>>> >>>>>>> >>>>>> Rebased patches attached. >>>>>> >>>>>> -- >>>>>> Martin Basti >>>>>> >>>>>> >>>>> rebased patches attached >>>>> >>>>> -- >>>>> Martin Basti >>>>> >>>>> >>>>> >>>> >>>> ACK on patch 231. >>>> >>>> BTW I have found a 7 year old bug caused by CSV while reviewing it: >>>> . >>>> >>>> There is also similar git-only bug in >>>> install/updates/10-uniqueness.update: >>>> >>>> default:uniqueness-subtrees: 'cn=accounts,$SUFFIX' >>>> default:uniqueness-subtrees: 'cn=deleted >>>> users,cn=accounts,cn=provisioning,$SUFFIX' >>>> >>>> but your patch fixes it. >>>> >>>> I will review patch 232 later. >>>> >>>> Honza >>>> >>> Honza doesn't like original 232 so much. >>> >>> Updated patch 232 attached >>> >>> >>> >> Updated patch 232 attached >> >> -- >> Martin Basti >> >> > Updated patches attached. > > -- > Martin Basti > ACK. Pushed to master: 520bbd001b68bc51a79c2b4a9684fb1c12a582cd -- Jan Cholasta From jcholast at redhat.com Mon May 11 16:44:05 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 11 May 2015 18:44:05 +0200 Subject: [Freeipa-devel] Domain Level feature kick-off In-Reply-To: <5550D2CD.3050202@redhat.com> References: <5549C2DB.5000605@redhat.com> <5550AC25.1030802@redhat.com> <5550AFEF.9010100@redhat.com> <5550B39F.1040800@redhat.com> <5550B500.2020607@redhat.com> <5550B912.2000200@redhat.com> <5550BCDC.5070309@redhat.com> <5550BDDE.2020402@redhat.com> <5550BE86.8060205@redhat.com> <5550CDE5.4020309@redhat.com> <5550D2CD.3050202@redhat.com> Message-ID: <5550DC55.5080503@redhat.com> Dne 11.5.2015 v 18:03 Ludwig Krispenz napsal(a): > > On 05/11/2015 05:42 PM, Petr Spacek wrote: >> On 11.5.2015 16:36, Martin Kosek wrote: >>> On 05/11/2015 04:34 PM, Jan Cholasta wrote: >>>> Dne 11.5.2015 v 16:29 Petr Vobornik napsal(a): >>>>> On 05/11/2015 04:13 PM, Jan Cholasta wrote: >>>>>> Dne 11.5.2015 v 15:56 Martin Kosek napsal(a): >>>>>>> On 05/11/2015 03:50 PM, Jan Cholasta wrote: >>>>>>>> Dne 11.5.2015 v 15:34 Martin Kosek napsal(a): >>>>>>>>> On 05/11/2015 03:18 PM, Jan Cholasta wrote: >>>>>>>>>> Dne 6.5.2015 v 09:29 Martin Kosek napsal(a): >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> as already discussed in December [1], we will need to implement >>>>>>>>>>> domain levels >>>>>>>>>>> in FreeIPA 4.2 to make sure we can manage the replication >>>>>>>>>>> agreement by >>>>>>>>>>> Topology >>>>>>>>>>> plugin. >>>>>>>>>>> >>>>>>>>>>> I created a ticket for this feature [3] and linked it with >>>>>>>>>>> Simo's >>>>>>>>>>> design. The >>>>>>>>>>> proposed scope for the feature is written in the ticket itself. >>>>>>>>>>> Tomas >>>>>>>>>>> agreed he >>>>>>>>>>> would work on this. >>>>>>>>>>> >>>>>>>>>>> The first consumer is Ludwig's topology plugin. Seeing Ludwig's >>>>>>>>>>> initial >>>>>>>>>>> patches >>>>>>>>>>> [4], I suspect he chose a different format (major/minor) for the >>>>>>>>>>> domain level >>>>>>>>>>> value, but as we discussed in [2], it will rather be a numerical >>>>>>>>>>> value, raised >>>>>>>>>>> only when needed. This is something for Tomas and Ludwig to >>>>>>>>>>> coordinate >>>>>>>>>>> together. >>>>>>>>>>> >>>>>>>>>>> I am not sure if Custodia work will need this, maybe the new >>>>>>>>>>> ipa-replica-install would just check if Custodia is there or not >>>>>>>>>>> and not >>>>>>>>>>> decide >>>>>>>>>>> on Domain Levels... we will see. >>>>>>>>>>> >>>>>>>>>>> The design page does not list the actual API, but I expect it to >>>>>>>>>>> be very >>>>>>>>>>> simple >>>>>>>>>>> for now, maybe just >>>>>>>>>>> >>>>>>>>>>> $ ipa domainlevel-show >>>>>>>>>>> $ ipa domainlevel-raise NUMBER >>>>>>>>>> I would think >>>>>>>>>> >>>>>>>>>> $ ipa domain-show >>>>>>>>>> $ ipa domain-set-level NUMBER >>>>>>>>>> >>>>>>>>>> because "domain level" does not sound like an object, but >>>>>>>>>> rather a >>>>>>>>>> "level" >>>>>>>>>> property of a "domain" object. >>>>>>>>> I think the point here was that the Domain Level is a separate >>>>>>>>> LDAP >>>>>>>>> object with >>>>>>>>> just that value. So the naming seemed pretty self-explanatory and >>>>>>>>> consistent >>>>>>>>> to me. >>>>>>>> That seems to me like an implementation detail rather than >>>>>>>> something >>>>>>>> against >>>>>>>> which to model the API. (Come on, singleton object with a single >>>>>>>> property?) >>>>>>> IIRC, that was the point. To have this value in a single LDAP object >>>>>>> without >>>>>>> other settings, so that components can simply "watch" this object or >>>>>>> have >>>>>>> syncrepl on it, without receiving false positives (as they would >>>>>>> have >>>>>>> with for >>>>>>> example "config-*" object). >>>>>> OK, so it indeed is just an implementation detail - if it was >>>>>> possible >>>>>> to watch just a single attribute of an entry, it could be stored >>>>>> in more >>>>>> meaningful location, but it's not, so it can't. >> It is perfectly possible with SyncRepl protocol. >> >>>>>>>>> With using just "domain-*" we are blocking ourselves for the time >>>>>>>>> when real >>>>>>>>> "Domain" object shows up. >>>>>>>> I don't see why it should. >>>>>>>> >>>>>>>> Anyway, I don't have a strong opinion on this, except I like "set" >>>>>>>> better than >>>>>>>> "raise". >>>>>>> I liked the raise more as it does not give people the hopes that >>>>>>> domain level >>>>>>> can be lowered once it was raised :-) >>>>>>> >>>>>> I like "set" because it is very explicit - "raise" not so much, it >>>>>> might >>>>>> mean "raise to specific value" or "raise by specific value" and maybe >>>>>> other things. >>>>>> >>>>> +1 for domainlevel - there is no and most likely won't be a singleton >>>>> domain object, hence domainlevel is the object. >>>> But there is: api.env.basedn aka the suffix. >>>> >>>>> In other words: what >>>>> domain? I would argue that the feature should be called a "realm >>>>> level" >>>>> because there is only one realm but multiple domains in the realm. >>>> That depends on the definition of "domain" :-) But I think "realm >>>> level" does >>>> indeed fit better in our Kerberos-centric world. >>> Maybe. But we try to hide Kerberos specifics... I think the idea was >>> to make it >>> sound similar to AD's Domain Functional Level. >> So call it 'functional level' :-) > This thread is about implementing the design provided in Simo's "domain > level" design page, we had discussed this before, do we really need to > iterate it again ? I don't think anyone is actually suggesting to make changes to the design. Right? -- Jan Cholasta From npmccallum at redhat.com Mon May 11 16:51:23 2015 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 11 May 2015 12:51:23 -0400 Subject: [Freeipa-devel] Fwd: [openssl-users] removing Kerberos support from OpenSSL In-Reply-To: <1431353398.2560.5.camel@redhat.com> References: <55487D88.7010909@openssl.org> <5548BB2F.8060006@redhat.com> <1431353398.2560.5.camel@redhat.com> Message-ID: <1431363083.2560.6.camel@redhat.com> Nico Williams has made an interesting proposal on this topic: http://marc.info/?l=openssl-users&m=143136162429551&w=2 It is probably worth discussing. On Mon, 2015-05-11 at 10:09 -0400, Nathaniel McCallum wrote: > Yes and no. > > The current Kerberos support is insecure and should not be used. The > main > problem is that the session key is reused for all TLS connections. > This > prevents perfect forward secrecy. > > That being said, we have been toying around with the idea of making > a new > standard for GSSAPI/TLS which uses a DH or a PAKE to ensure that both > sides contribute entropy to a random encryption key. > > However, we have to get some of the other standards work off our > plates > before we can tackle such a large task. > > In short: existing Kerberos support should be removed from OpenSSL. > > Nathaniel > > On Tue, 2015-05-05 at 14:44 +0200, Petr Spacek wrote: > > Hello! > > > > Is this somehow interesting for us? > > > > Petr^2 Spacek > > > > > > -------- Forwarded Message -------- > > Subject: [openssl-users] Kerberos > > Date: Tue, 05 May 2015 09:21:28 +0100 > > From: Matt Caswell > > Reply-To: openssl-users at openssl.org > > To: openssl-users at openssl.org, openssl-dev at openssl.org > > > > I am considering removing Kerberos support from OpenSSL 1.1.0. > > There > > are > > a number of problems with the functionality as it stands, and it > > seems > > to me to be a very rarely used feature. I'm interested in hearing > > any > > opinions on this (either for or against). > > > > Thanks in advance for your input, > > > > Matt > > _______________________________________________ > > openssl-users mailing list > > To unsubscribe: > > https://mta.openssl.org/mailman/listinfo/openssl-users > > > From lkrispen at redhat.com Mon May 11 17:55:30 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Mon, 11 May 2015 19:55:30 +0200 Subject: [Freeipa-devel] Domain Level feature kick-off In-Reply-To: <5550DC55.5080503@redhat.com> References: <5549C2DB.5000605@redhat.com> <5550AC25.1030802@redhat.com> <5550AFEF.9010100@redhat.com> <5550B39F.1040800@redhat.com> <5550B500.2020607@redhat.com> <5550B912.2000200@redhat.com> <5550BCDC.5070309@redhat.com> <5550BDDE.2020402@redhat.com> <5550BE86.8060205@redhat.com> <5550CDE5.4020309@redhat.com> <5550D2CD.3050202@redhat.com> <5550DC55.5080503@redhat.com> Message-ID: <5550ED12.9040005@redhat.com> On 05/11/2015 06:44 PM, Jan Cholasta wrote: > Dne 11.5.2015 v 18:03 Ludwig Krispenz napsal(a): >> >> On 05/11/2015 05:42 PM, Petr Spacek wrote: >>> On 11.5.2015 16:36, Martin Kosek wrote: >>>> On 05/11/2015 04:34 PM, Jan Cholasta wrote: >>>>> Dne 11.5.2015 v 16:29 Petr Vobornik napsal(a): >>>>>> On 05/11/2015 04:13 PM, Jan Cholasta wrote: >>>>>>> Dne 11.5.2015 v 15:56 Martin Kosek napsal(a): >>>>>>>> On 05/11/2015 03:50 PM, Jan Cholasta wrote: >>>>>>>>> Dne 11.5.2015 v 15:34 Martin Kosek napsal(a): >>>>>>>>>> On 05/11/2015 03:18 PM, Jan Cholasta wrote: >>>>>>>>>>> Dne 6.5.2015 v 09:29 Martin Kosek napsal(a): >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> as already discussed in December [1], we will need to >>>>>>>>>>>> implement >>>>>>>>>>>> domain levels >>>>>>>>>>>> in FreeIPA 4.2 to make sure we can manage the replication >>>>>>>>>>>> agreement by >>>>>>>>>>>> Topology >>>>>>>>>>>> plugin. >>>>>>>>>>>> >>>>>>>>>>>> I created a ticket for this feature [3] and linked it with >>>>>>>>>>>> Simo's >>>>>>>>>>>> design. The >>>>>>>>>>>> proposed scope for the feature is written in the ticket >>>>>>>>>>>> itself. >>>>>>>>>>>> Tomas >>>>>>>>>>>> agreed he >>>>>>>>>>>> would work on this. >>>>>>>>>>>> >>>>>>>>>>>> The first consumer is Ludwig's topology plugin. Seeing >>>>>>>>>>>> Ludwig's >>>>>>>>>>>> initial >>>>>>>>>>>> patches >>>>>>>>>>>> [4], I suspect he chose a different format (major/minor) >>>>>>>>>>>> for the >>>>>>>>>>>> domain level >>>>>>>>>>>> value, but as we discussed in [2], it will rather be a >>>>>>>>>>>> numerical >>>>>>>>>>>> value, raised >>>>>>>>>>>> only when needed. This is something for Tomas and Ludwig to >>>>>>>>>>>> coordinate >>>>>>>>>>>> together. >>>>>>>>>>>> >>>>>>>>>>>> I am not sure if Custodia work will need this, maybe the new >>>>>>>>>>>> ipa-replica-install would just check if Custodia is there >>>>>>>>>>>> or not >>>>>>>>>>>> and not >>>>>>>>>>>> decide >>>>>>>>>>>> on Domain Levels... we will see. >>>>>>>>>>>> >>>>>>>>>>>> The design page does not list the actual API, but I expect >>>>>>>>>>>> it to >>>>>>>>>>>> be very >>>>>>>>>>>> simple >>>>>>>>>>>> for now, maybe just >>>>>>>>>>>> >>>>>>>>>>>> $ ipa domainlevel-show >>>>>>>>>>>> $ ipa domainlevel-raise NUMBER >>>>>>>>>>> I would think >>>>>>>>>>> >>>>>>>>>>> $ ipa domain-show >>>>>>>>>>> $ ipa domain-set-level NUMBER >>>>>>>>>>> >>>>>>>>>>> because "domain level" does not sound like an object, but >>>>>>>>>>> rather a >>>>>>>>>>> "level" >>>>>>>>>>> property of a "domain" object. >>>>>>>>>> I think the point here was that the Domain Level is a separate >>>>>>>>>> LDAP >>>>>>>>>> object with >>>>>>>>>> just that value. So the naming seemed pretty self-explanatory >>>>>>>>>> and >>>>>>>>>> consistent >>>>>>>>>> to me. >>>>>>>>> That seems to me like an implementation detail rather than >>>>>>>>> something >>>>>>>>> against >>>>>>>>> which to model the API. (Come on, singleton object with a single >>>>>>>>> property?) >>>>>>>> IIRC, that was the point. To have this value in a single LDAP >>>>>>>> object >>>>>>>> without >>>>>>>> other settings, so that components can simply "watch" this >>>>>>>> object or >>>>>>>> have >>>>>>>> syncrepl on it, without receiving false positives (as they would >>>>>>>> have >>>>>>>> with for >>>>>>>> example "config-*" object). >>>>>>> OK, so it indeed is just an implementation detail - if it was >>>>>>> possible >>>>>>> to watch just a single attribute of an entry, it could be stored >>>>>>> in more >>>>>>> meaningful location, but it's not, so it can't. >>> It is perfectly possible with SyncRepl protocol. >>> >>>>>>>>>> With using just "domain-*" we are blocking ourselves for the >>>>>>>>>> time >>>>>>>>>> when real >>>>>>>>>> "Domain" object shows up. >>>>>>>>> I don't see why it should. >>>>>>>>> >>>>>>>>> Anyway, I don't have a strong opinion on this, except I like >>>>>>>>> "set" >>>>>>>>> better than >>>>>>>>> "raise". >>>>>>>> I liked the raise more as it does not give people the hopes that >>>>>>>> domain level >>>>>>>> can be lowered once it was raised :-) >>>>>>>> >>>>>>> I like "set" because it is very explicit - "raise" not so much, it >>>>>>> might >>>>>>> mean "raise to specific value" or "raise by specific value" and >>>>>>> maybe >>>>>>> other things. >>>>>>> >>>>>> +1 for domainlevel - there is no and most likely won't be a >>>>>> singleton >>>>>> domain object, hence domainlevel is the object. >>>>> But there is: api.env.basedn aka the suffix. >>>>> >>>>>> In other words: what >>>>>> domain? I would argue that the feature should be called a "realm >>>>>> level" >>>>>> because there is only one realm but multiple domains in the realm. >>>>> That depends on the definition of "domain" :-) But I think "realm >>>>> level" does >>>>> indeed fit better in our Kerberos-centric world. >>>> Maybe. But we try to hide Kerberos specifics... I think the idea was >>>> to make it >>>> sound similar to AD's Domain Functional Level. >>> So call it 'functional level' :-) >> This thread is about implementing the design provided in Simo's "domain >> level" design page, we had discussed this before, do we really need to >> iterate it again ? > > I don't think anyone is actually suggesting to make changes to the > design. Right? well, the design all over talks about domain levels, the entry is specified as cn=domainlevel, .... so the discussion is questioning the design From abokovoy at redhat.com Tue May 12 05:37:07 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 12 May 2015 08:37:07 +0300 Subject: [Freeipa-devel] [PATCH] 0178 Fix AD trusts in Fedora 22 In-Reply-To: <20150508130753.GA4748@onega.vda.li> References: <20150508130753.GA4748@onega.vda.li> Message-ID: <20150512053707.GF5152@redhat.com> On Fri, 08 May 2015, Alexander Bokovoy wrote: >Hi, > >attached patch fixes issues with Samba 4.2 in Fedora 22. > >See commit message for the details. Note that you'll >also need Samba fixes from https://bugzilla.redhat.com/show_bug.cgi?id=1219832 >to test the patch. > >Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1219834 An update is available in Bodhi: https://admin.fedoraproject.org/updates/samba-4.2.1-8.fc22,freeipa-4.1.4-3.fc22 Please test and support. -- / Alexander Bokovoy From abokovoy at redhat.com Tue May 12 05:50:20 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 12 May 2015 08:50:20 +0300 Subject: [Freeipa-devel] [PATCH 0031] provide a dedicated ccache file to httpd In-Reply-To: <554732C2.3030707@redhat.com> References: <554117FB.7070203@redhat.com> <5541B88A.4080506@redhat.com> <20150430062325.GG11785@redhat.com> <554732C2.3030707@redhat.com> Message-ID: <20150512055020.GH5152@redhat.com> On Mon, 04 May 2015, Martin Babinsky wrote: >On 04/30/2015 08:23 AM, Alexander Bokovoy wrote: >>On Thu, 30 Apr 2015, Jan Cholasta wrote: >>>Hi, >>> >>>Dne 29.4.2015 v 19:42 Martin Babinsky napsal(a): >>>>The attached patch is a merge of PATCHES 0031-0032 incorporating Simo's >>>>and Martin's suggestions (see e.g. >>>>https://www.redhat.com/archives/freeipa-devel/2015-April/msg00327.html >>>>for reference). >>>> >>>>https://fedorahosted.org/freeipa/ticket/4973 >>> >>>IMHO we should set the environment variable in >>>/etc/systemd/system/httpd.service, instead of providing a new service >>>file, because we are just changing configuration, not creating a new >>>concurrent httpd instance, as is the case with ipa-memcached, and also >>>not using alternative httpd implementation which masks the current >>>one, as is the case with bind-pkcs11. It would simplify the whole >>>thing significantly and it's even recommended in httpd.service to do >>I agree. >> >>>so: >>> >>> # For example, to pass additional options (for instance, -D >>>definitions) to the >>> # httpd binary at startup, you need to create a file named >>> # "/etc/systemd/system/httpd.service" containing: >>> # .include /lib/systemd/system/httpd.service >>> # [Service] >>> # Environment=OPTIONS=-DMY_DEFINE >>> >>>(BTW I wonder why /etc/sysconfig/httpd support was removed from httpd >>>in Fedora >>>(), >>>it seems like a better place to customize environment variables, >>>rather than having to create a modified service file...) >>We had discussion with Joe Orton (httpd maintainer) a while ago and his >>arguments were following: >>---- >>Hi guys, we made that change to adopt what is considered "best practice" >>for systemd. The change is not in RHEL7, only Fedora >= 20. >> >>I would not say we are strongly wedded to that change, but the use case >>you provide seems very weak. /etc/sysconfig/httpd is intended to be >>user-configurable and if users do "rm -f /etc/sysconfig/httpd" then >>Fedora packages should keep working correctly. Can we find a more >>robust way to achieve the same results? Why is it required that the >>environment variable is set globally within /usr/sbin/httpd? >> >>... [and later in dicussion] >> >>I'd argue that in this case you should not be using httpd.service as-is; >>instead it would be correct to create an "httpd-ipa.service" unit file >>or similar, which can ".include" the system httpd.service, and sets up >>the appropriate Environment= (or EnvironmentFile=) directly. >> >>Also, if the intent is to purely to change mod_auth_kerb's interaction >>with libkrb5 is there no way to do this via the libkrb API - or >>mod_auth_kerb's existing use thereof? >> >>The use of /etc/sysconfig/httpd has historically been a mild PITA and >>I'm not seeing a compelling reason to revert the decision to kill it >>here. >>---- >> >>>Anyway, I would prefer if we set it in a way that works on non-systemd >>>distros as well. Can't we just set "GssapiCredStore >>>ccache:FILE:/var/run/httpd/krbcache/krb5ccache" in >>>/etc/httpd/conf.d/ipa.conf? >>It is not just mod_auth_gssapi, it is needed for users of the >>credentials obtained by mod_auth_gssapi. mod_auth_gssapi only sets >>KRB5CCNAME value when there is delegation of credentials in use and >>there is something to delegate. >> >> > >Ok, attaching updated patches. After the discussion with Martin^1 we >decided to play it safe and put KRB5CCNAME into >/etc/systemd/system/httpd.service. > >-- >Martin^3 Babinsky >From 6042f4ce093890394da4f6e625d5cc745b285c35 Mon Sep 17 00:00:00 2001 >From: Martin Babinsky >Date: Tue, 28 Apr 2015 16:24:02 +0200 >Subject: [PATCH] provide dedicated ccache file for httpd > >httpd service stores Kerberos credentials in kernel keyring which gets >destroyed and recreated during service install/upgrade, causing problems when >the process is run under SELinux context other than 'unconfined_t'. This patch >enables HTTPInstance to set up a dedicated CCache file for Apache to store >credentials. > >https://fedorahosted.org/freeipa/ticket/4973 >--- > freeipa.spec.in | 4 ++++ > init/systemd/httpd.service | 4 ++++ > 2 files changed, 8 insertions(+) > create mode 100644 init/systemd/httpd.service > >diff --git a/freeipa.spec.in b/freeipa.spec.in >index 608242b5adbc43efbbf0ae30a6d7a933bebc1084..664162fe918f03049c27f70c9e7f852a11c50a8c 100644 >--- a/freeipa.spec.in >+++ b/freeipa.spec.in >@@ -12,6 +12,7 @@ > %endif > > %global plugin_dir %{_libdir}/dirsrv/plugins >+%global etc_systemd_dir %{_sysconfdir}/systemd/system > %global gettext_domain ipa > %if 0%{?rhel} > %global platform_module rhel >@@ -470,8 +471,10 @@ touch %{buildroot}%{_libdir}/krb5/plugins/libkrb5/winbind_krb5_locator.so > > # NOTE: systemd specific section > mkdir -p %{buildroot}%{_unitdir} >+mkdir -p %{buildroot}%{etc_systemd_dir} > install -m 644 init/systemd/ipa.service %{buildroot}%{_unitdir}/ipa.service > install -m 644 init/systemd/ipa_memcached.service %{buildroot}%{_unitdir}/ipa_memcached.service >+install -m 644 init/systemd/httpd.service %{buildroot}%{etc_systemd_dir}/httpd.service > # END > mkdir -p %{buildroot}/%{_localstatedir}/lib/ipa/backup > %endif # ONLY_CLIENT >@@ -691,6 +694,7 @@ fi > %attr(644,root,root) %{_unitdir}/ipa-dnskeysyncd.service > %attr(644,root,root) %{_unitdir}/ipa-ods-exporter.socket > %attr(644,root,root) %{_unitdir}/ipa-ods-exporter.service >+%attr(644,root,root) %{etc_systemd_dir}/httpd.service There is a minor issue: a lack of Requires: /etc/systemd/system which is needed because of /etc/systemd/system directory owned by a different package. We require systemd-units which is provided by systemd package as well so it is sort of mitigated by that but it would good to be explicit in the require. And yes, you can require the directory because systemd provides it: $ rpm -q --whatprovides /etc/systemd/system systemd-219-13.fc22.x86_64 Otherwise, ACK. -- / Alexander Bokovoy From lkrispen at redhat.com Tue May 12 06:33:16 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 12 May 2015 08:33:16 +0200 Subject: [Freeipa-devel] [PATCH] manage replication topology in the shared tree In-Reply-To: <55362FDC.7090104@redhat.com> References: <552B84C5.80300@redhat.com> <55362C43.4020406@redhat.com> <55362FDC.7090104@redhat.com> Message-ID: <55519EAC.9000204@redhat.com> Hi, I did split the patches, for easier review and to share work on it. The attachment contains 4 patches: - the ds plugin part as submitted for review - the changes to the ds plugin part done after review (not complete yet) - the ipa framework part (including Petr's improvements) - the install related part Regards, Ludwig On 04/21/2015 01:09 PM, Petr Vobornik wrote: > On 04/21/2015 12:53 PM, Petr Vobornik wrote: >> On 04/13/2015 10:56 AM, Ludwig Krispenz wrote: >>> Hi, >>> >>> in the attachment you find the latest state of the "topology >>> plugin", it >>> implements what is defined in the design page: >>> http://www.freeipa.org/page/V4/Manage_replication_topology (which is >>> also waiting for a reviewer) >>> >>> It contains the plugin itself and a core of ipa commands to manage a >>> topology. to be really applicable, some work outside is required, eg >>> the >>> management of the domain level and a decision where the binddn group >>> should be maintained. >>> >>> Thanks, >>> Ludwig >>> >>> >> >> I've looked at the python part, mostly because I want to start with POC >> of Web UI for topology. >> >> topology.py is clearly still a work in progress. I've reflected >> following comments into a patch to speed things up. >> >> What's in the patch: >> >> 1. git am complains about trailing whitespaces >> >> 2. pep8 check produces quite a lot of issues. New code should be almost >> with any (`E501 line too long` is not a hard rule) >> `git diff HEAD~1 -U0 | pep8 --diff` >> >> 3. some typos >> >> 4. A lot of unused imports >> >> 5. Option name --sname for 'Segment identifier' is not very friendly. I >> don't see any examples of command options in the design notes. >> >> 6. NO_UPG_MAGIC - leftover from other plugin? >> >> 7. suffix object has labels from segment >> >> 8. IPA framework has a support for nested object. Key is setting >> `parent_object = 'topologysuffix'` in topologysegment object. >> >> 9. repl_agmt_attrs could be in topologysegment takes_params. >> >> 10. missing various CRUD commands like topologysuffix-find and >> topologysuffix-show commands. >> >> Whats missing, not fixed: >> 1. last 2 lines of VERSION file are not updated >> >> 2. Mixed terminology. Somewhere is used suffix and somewhere replication >> area or just area. >> >> 3. Validation >> - suffix should check for dn >> - existence of both ends of a segment >> >> 4. print of segments in suffix-show needs to be improved or removed >> >> To discuss: >> a) Do params in topologysegment have to have a maxlength set? >> >> b) Terminology has to be united. Segments are nested in suffix but >> sometimes are called areas and suffix is 'the suffix'. User might be >> confused. E.g. shouldn't the object be named a topologyarea instead of >> topologysuffix? >> >> c) I've added all missing CRUD commands. Are there any which we don't >> want there, or want to restrict them. E.g. I can imagine that deleting a >> suffix should be prevented if it contains any segments (or it has to be >> forced (--force option)) >> >> d) Do we want to print segments in suffix-show? >> >> e) Mainly for Honza: I've added --show-segments option to suffix-show >> which defaults to True. I don't like the behavior of CLI, which asks to >> confirm the value all the time. My intention was to have it there by >> default, but also allow to disable it by --show-segments=False. I don't >> want to add it as Flag (--hide-segments) since it restricts versatility. >> I would like to see an optional flag which would be filled by default >> value if not explicitly defined and CLI would not ask for the option >> value. >> >> > > Also it would be better to split the work into more patches. E.g. DS > plugin, installation, python plugin. So ds plugin review could be > separated from the python part. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-lkrispen-0003-plugin-part-of-topology-management.patch Type: text/x-patch Size: 144983 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-lkrispen-0004-required-changes-from-review-1.patch Type: text/x-patch Size: 18826 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-lkrispen-0006-topology-management-ipa-commands.patch Type: text/x-patch Size: 17089 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-lkrispen-0005-install-part-of-topology-plugin.patch Type: text/x-patch Size: 10950 bytes Desc: not available URL: From mbabinsk at redhat.com Tue May 12 08:05:22 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 12 May 2015 10:05:22 +0200 Subject: [Freeipa-devel] [PATCH 0031] provide a dedicated ccache file to httpd In-Reply-To: <20150512055020.GH5152@redhat.com> References: <554117FB.7070203@redhat.com> <5541B88A.4080506@redhat.com> <20150430062325.GG11785@redhat.com> <554732C2.3030707@redhat.com> <20150512055020.GH5152@redhat.com> Message-ID: <5551B442.3040605@redhat.com> On 05/12/2015 07:50 AM, Alexander Bokovoy wrote: > On Mon, 04 May 2015, Martin Babinsky wrote: >> On 04/30/2015 08:23 AM, Alexander Bokovoy wrote: >>> On Thu, 30 Apr 2015, Jan Cholasta wrote: >>>> Hi, >>>> >>>> Dne 29.4.2015 v 19:42 Martin Babinsky napsal(a): >>>>> The attached patch is a merge of PATCHES 0031-0032 incorporating >>>>> Simo's >>>>> and Martin's suggestions (see e.g. >>>>> https://www.redhat.com/archives/freeipa-devel/2015-April/msg00327.html >>>>> for reference). >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4973 >>>> >>>> IMHO we should set the environment variable in >>>> /etc/systemd/system/httpd.service, instead of providing a new service >>>> file, because we are just changing configuration, not creating a new >>>> concurrent httpd instance, as is the case with ipa-memcached, and also >>>> not using alternative httpd implementation which masks the current >>>> one, as is the case with bind-pkcs11. It would simplify the whole >>>> thing significantly and it's even recommended in httpd.service to do >>> I agree. >>> >>>> so: >>>> >>>> # For example, to pass additional options (for instance, -D >>>> definitions) to the >>>> # httpd binary at startup, you need to create a file named >>>> # "/etc/systemd/system/httpd.service" containing: >>>> # .include /lib/systemd/system/httpd.service >>>> # [Service] >>>> # Environment=OPTIONS=-DMY_DEFINE >>>> >>>> (BTW I wonder why /etc/sysconfig/httpd support was removed from httpd >>>> in Fedora >>>> (), >>>> >>>> it seems like a better place to customize environment variables, >>>> rather than having to create a modified service file...) >>> We had discussion with Joe Orton (httpd maintainer) a while ago and his >>> arguments were following: >>> ---- >>> Hi guys, we made that change to adopt what is considered "best practice" >>> for systemd. The change is not in RHEL7, only Fedora >= 20. >>> >>> I would not say we are strongly wedded to that change, but the use case >>> you provide seems very weak. /etc/sysconfig/httpd is intended to be >>> user-configurable and if users do "rm -f /etc/sysconfig/httpd" then >>> Fedora packages should keep working correctly. Can we find a more >>> robust way to achieve the same results? Why is it required that the >>> environment variable is set globally within /usr/sbin/httpd? >>> >>> ... [and later in dicussion] >>> >>> I'd argue that in this case you should not be using httpd.service as-is; >>> instead it would be correct to create an "httpd-ipa.service" unit file >>> or similar, which can ".include" the system httpd.service, and sets up >>> the appropriate Environment= (or EnvironmentFile=) directly. >>> >>> Also, if the intent is to purely to change mod_auth_kerb's interaction >>> with libkrb5 is there no way to do this via the libkrb API - or >>> mod_auth_kerb's existing use thereof? >>> >>> The use of /etc/sysconfig/httpd has historically been a mild PITA and >>> I'm not seeing a compelling reason to revert the decision to kill it >>> here. >>> ---- >>> >>>> Anyway, I would prefer if we set it in a way that works on non-systemd >>>> distros as well. Can't we just set "GssapiCredStore >>>> ccache:FILE:/var/run/httpd/krbcache/krb5ccache" in >>>> /etc/httpd/conf.d/ipa.conf? >>> It is not just mod_auth_gssapi, it is needed for users of the >>> credentials obtained by mod_auth_gssapi. mod_auth_gssapi only sets >>> KRB5CCNAME value when there is delegation of credentials in use and >>> there is something to delegate. >>> >>> >> >> Ok, attaching updated patches. After the discussion with Martin^1 we >> decided to play it safe and put KRB5CCNAME into >> /etc/systemd/system/httpd.service. >> >> -- >> Martin^3 Babinsky > >> From 6042f4ce093890394da4f6e625d5cc745b285c35 Mon Sep 17 00:00:00 2001 >> From: Martin Babinsky >> Date: Tue, 28 Apr 2015 16:24:02 +0200 >> Subject: [PATCH] provide dedicated ccache file for httpd >> >> httpd service stores Kerberos credentials in kernel keyring which gets >> destroyed and recreated during service install/upgrade, causing >> problems when >> the process is run under SELinux context other than 'unconfined_t'. >> This patch >> enables HTTPInstance to set up a dedicated CCache file for Apache to >> store >> credentials. >> >> https://fedorahosted.org/freeipa/ticket/4973 >> --- >> freeipa.spec.in | 4 ++++ >> init/systemd/httpd.service | 4 ++++ >> 2 files changed, 8 insertions(+) >> create mode 100644 init/systemd/httpd.service >> >> diff --git a/freeipa.spec.in b/freeipa.spec.in >> index >> 608242b5adbc43efbbf0ae30a6d7a933bebc1084..664162fe918f03049c27f70c9e7f852a11c50a8c >> 100644 >> --- a/freeipa.spec.in >> +++ b/freeipa.spec.in >> @@ -12,6 +12,7 @@ >> %endif >> >> %global plugin_dir %{_libdir}/dirsrv/plugins >> +%global etc_systemd_dir %{_sysconfdir}/systemd/system >> %global gettext_domain ipa >> %if 0%{?rhel} >> %global platform_module rhel >> @@ -470,8 +471,10 @@ touch >> %{buildroot}%{_libdir}/krb5/plugins/libkrb5/winbind_krb5_locator.so >> >> # NOTE: systemd specific section >> mkdir -p %{buildroot}%{_unitdir} >> +mkdir -p %{buildroot}%{etc_systemd_dir} >> install -m 644 init/systemd/ipa.service >> %{buildroot}%{_unitdir}/ipa.service >> install -m 644 init/systemd/ipa_memcached.service >> %{buildroot}%{_unitdir}/ipa_memcached.service >> +install -m 644 init/systemd/httpd.service >> %{buildroot}%{etc_systemd_dir}/httpd.service >> # END >> mkdir -p %{buildroot}/%{_localstatedir}/lib/ipa/backup >> %endif # ONLY_CLIENT >> @@ -691,6 +694,7 @@ fi >> %attr(644,root,root) %{_unitdir}/ipa-dnskeysyncd.service >> %attr(644,root,root) %{_unitdir}/ipa-ods-exporter.socket >> %attr(644,root,root) %{_unitdir}/ipa-ods-exporter.service >> +%attr(644,root,root) %{etc_systemd_dir}/httpd.service > There is a minor issue: a lack of > > Requires: /etc/systemd/system > > which is needed because of /etc/systemd/system directory owned by a > different package. We require systemd-units which is provided by systemd > package as well so it is sort of mitigated by that but it would > good to be explicit in the require. And yes, you can require the > directory because systemd provides it: > > $ rpm -q --whatprovides /etc/systemd/system > systemd-219-13.fc22.x86_64 > > Otherwise, ACK. > thank for review Alexander, attaching updated patch. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0031.3-provide-dedicated-ccache-file-for-httpd.patch Type: text/x-patch Size: 2607 bytes Desc: not available URL: From pvoborni at redhat.com Tue May 12 08:54:33 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 12 May 2015 10:54:33 +0200 Subject: [Freeipa-devel] [PATCH] 819-820 jQuery.ordered_map: faster creation In-Reply-To: <55507ABF.2020900@redhat.com> References: <5531195C.4020105@redhat.com> <55507ABF.2020900@redhat.com> Message-ID: <5551BFC9.7080206@redhat.com> On 05/11/2015 11:47 AM, Martin Babinsky wrote: > On 04/17/2015 04:31 PM, Petr Vobornik wrote: >> Improve performance of Web UI with very large user groups or any other >> usage which adds a lot of values into jQuery.ordered_map. >> >> > ACK > master: * 68f04643d6022707e8ccac9f8b817542d9022119 jQuery.ordered_map: faster creation * 60997b58b88fd5e82663857f94ced7544d0220cc jQuery.ordered_map: remove map attribute -- Petr Vobornik From abokovoy at redhat.com Tue May 12 09:22:36 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 12 May 2015 12:22:36 +0300 Subject: [Freeipa-devel] [PATCH 0031] provide a dedicated ccache file to httpd In-Reply-To: <5551B442.3040605@redhat.com> References: <554117FB.7070203@redhat.com> <5541B88A.4080506@redhat.com> <20150430062325.GG11785@redhat.com> <554732C2.3030707@redhat.com> <20150512055020.GH5152@redhat.com> <5551B442.3040605@redhat.com> Message-ID: <20150512092236.GL5152@redhat.com> On Tue, 12 May 2015, Martin Babinsky wrote: >>> %attr(644,root,root) %{_unitdir}/ipa-ods-exporter.service >>> +%attr(644,root,root) %{etc_systemd_dir}/httpd.service >> There is a minor issue: a lack of >> >> Requires: /etc/systemd/system >> >> which is needed because of /etc/systemd/system directory owned by a >> different package. We require systemd-units which is provided by systemd >> package as well so it is sort of mitigated by that but it would >> good to be explicit in the require. And yes, you can require the >> directory because systemd provides it: >> >> $ rpm -q --whatprovides /etc/systemd/system >> systemd-219-13.fc22.x86_64 >> >> Otherwise, ACK. >> > thank for review Alexander, attaching updated patch. ACK -- / Alexander Bokovoy From mbabinsk at redhat.com Tue May 12 10:30:45 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 12 May 2015 12:30:45 +0200 Subject: [Freeipa-devel] [PATCH] 825 webui-ci: fix type error in host_tasks inicializations In-Reply-To: <5549FD05.6010203@redhat.com> References: <5549FD05.6010203@redhat.com> Message-ID: <5551D655.4000206@redhat.com> On 05/06/2015 01:37 PM, Petr Vobornik wrote: > host_tasks initializations were not modified along with pytest migration > > ACK -- Martin^3 Babinsky From pvoborni at redhat.com Tue May 12 10:42:34 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 12 May 2015 12:42:34 +0200 Subject: [Freeipa-devel] [PATCH] 814-818 migrate-ds: optimize adding users to default group In-Reply-To: <554B9A4F.3080500@redhat.com> References: <5527AC09.7060707@redhat.com> <554233E4.5040608@redhat.com> <55488687.9070407@redhat.com> <554A2A13.7030005@redhat.com> <554B49D3.5090901@redhat.com> <554B9A4F.3080500@redhat.com> Message-ID: <5551D91A.1070803@redhat.com> On 05/07/2015 07:01 PM, Martin Basti wrote: > On 07/05/15 13:17, Petr Vobornik wrote: >> On 05/06/2015 04:49 PM, Martin Basti wrote: >>> On 05/05/15 10:59, Petr Vobornik wrote: >>>> On 04/30/2015 03:53 PM, Martin Basti wrote: >>>>> On 10/04/15 12:55, Petr Vobornik wrote: >>>>>> The essential patch is 814. >>>>>> snip >> > As we personally talked with Honza, and he agreed with param > modification, then > ACK for all patches. > Pushed to master: master: * 2c1bca3b0f19f69471c993867113d13cbc54636a migrate-ds: optimize adding users to default group * fda96988444c8c01115f0e992abe1b71192998d5 migrate-ds: skip default group option * a6ca9800fa8b48b9fa71dc54cc036a17d35b6197 migrate-ds: remove unused def_group_gid context property * c3d99a28a0bfed2198712c98830c2011fd6be874 migrate-ds: optimize gid checks by utilizing dictionary nature of set * 3b0e81ce062e63a3ca45df1cd997196cc340f565 migrate-ds: log migrated group members only on debug level * 91b39acd6bca1a1054220291f4b4a0a4118e829c cli: differentiate Flag a Bool when autofill is set -- Petr Vobornik From pvoborni at redhat.com Tue May 12 10:48:19 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 12 May 2015 12:48:19 +0200 Subject: [Freeipa-devel] [PATCH] 825 webui-ci: fix type error in host_tasks inicializations In-Reply-To: <5551D655.4000206@redhat.com> References: <5549FD05.6010203@redhat.com> <5551D655.4000206@redhat.com> Message-ID: <5551DA73.1040907@redhat.com> On 05/12/2015 12:30 PM, Martin Babinsky wrote: > On 05/06/2015 01:37 PM, Petr Vobornik wrote: >> host_tasks initializations were not modified along with pytest migration >> >> > ACK > Pushed to master: 5fadee969cae3b66b986fb9e28fdbf3bb5ec2f60 -- Petr Vobornik From pvoborni at redhat.com Tue May 12 10:51:54 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 12 May 2015 12:51:54 +0200 Subject: [Freeipa-devel] [PATCH 0238] Server Upgrade: fix broken memberUid index In-Reply-To: <554B5101.6010605@redhat.com> References: <5549F958.1040508@redhat.com> <5549F9A9.50107@redhat.com> <554B5101.6010605@redhat.com> Message-ID: <5551DB4A.1030200@redhat.com> On 05/07/2015 01:48 PM, Martin Babinsky wrote: > On 05/06/2015 01:23 PM, Martin Basti wrote: >> On 06/05/15 13:22, Martin Basti wrote: >>> https://fedorahosted.org/freeipa/ticket/5007 >>> >>> Patch attached. >>> >>> >>> >> Requires patch mbasti-231-4 >> >> -- >> Martin Basti >> > ACK > Pushed to master: 57fba7a56f88c517b3ebb03842f1cc18bc129ebb -- Petr Vobornik From edewata at redhat.com Tue May 12 10:52:07 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 12 May 2015 05:52:07 -0500 Subject: [Freeipa-devel] [PATCH] Password vault In-Reply-To: <553498D1.1020901@redhat.com> References: <54E1AF55.3060409@redhat.com> <54EBEB55.6010306@redhat.com> <54F96B22.9050507@redhat.com> <55004D5D.6060300@redhat.com> <550FE5EB.1070606@redhat.com> <551E0AE1.8040500@redhat.com> <553498D1.1020901@redhat.com> Message-ID: <5551DB57.6060504@redhat.com> Please take a look at the attached patch (#353-9). It obsoletes all previous patches. See comments below. On 4/20/2015 1:12 AM, Jan Cholasta wrote: >> I'm planning to merge the vault and vault container object and use the >> vault type attribute to distinguish between the two. See more discussion >> about that below. > > OK. The vault container plugin has been removed instead of merged (see explanation below). Internally the vaults are still stored in built-in containers in the DS, but there won't be an interface to manage them. The following containers are available for use: private, shared, and services, but they are flat, not hierarchical. >>>>> 3) The container_vault config option should be renamed to >>>>> container_vaultcontainer, as it is used in the vaultcontainer plugin, >>>>> not the vault plugin. >>>> >>>> It was named container_vault because it defines the DN for of the >>>> subtree that contains all vault-related entries. I moved the base_dn >>>> variable from vaultcontainer object to the vault object for clarity. >>> >>> That does not make much sense to me. Vault objects are contained in >>> their respective vaultcontainer objects, not directly in cn=vaults. >> >> The cn=vaults itself is actually a vault container (i.e. >> ipaVaultContainer). Theoretically you could store a vault in any >> container including cn=vaults, but we just don't want people to use it >> that way. >> >> I think this is consistent with other plugins. For example, the >> container_user points to cn=users, which is an nsContainer. There is no >> concept of 'user container' other than the cn=users itself. But even if >> there is one, the container_user will still be stored in the user class. > > In fact it is not consistent with other plugins. All entries managed by > the user plugin are stored *directly* under cn=users. Entries managed by > the vault plugin are not stored directly under cn=vaults, but rather > anywhere in the cn=vaults subtree and their DN is derived from the DN of > the parent vault container. For such objects, we don't set > .container_dn and don't have container_ constant, but > rather define them as child objects of their container objects. > >> When the vault & vaultcontainer is merged, this will no longer be an >> issue. > > OK. The vaults are still stored in the cn=vaults subtree, but now the containers will use nsContainer instead of ipaVaultContainer. The container_vault variable still defines the root container DN, i.e. cn=vaults. >>>>> 4) The vault object should be child of the vaultcontainer object. >>>>> >>>>> Not only is this correct from the object model perspective, but it >>>>> would >>>>> also make all the container_id hacks go away. >>>> >>>> It's a bit difficult because it will affect how the container & vault >>>> ID's are represented on the CLI. >>> >>> Yes, but the API should be done right (without hacks) first. You can >>> tune the CLI after that if you want. >> >> I think the current framework is rather limiting. It's kind of hard to >> build an interface that looks exactly what you want then add the >> implementation later to match the interface because many things are >> interrelated. In this particular case the object hierarchy on the server >> side would affect how the vault ID will be represented on the client >> side. > > It indeed is limiting and that's a good thing. We don't want people to > be able to create any crazy interfaces they can imagine, inconsistent > with everything else in IPA. So the vault container plugin was removed because the current framework cannot support the hierarchical structure described in the vault design without overriding the default parameter handling (which was referred to as 'hacks', although it was actually suggested by the previous reviewer). Adding the missing functionality will require modifications to the base framework classes. Such changes should only be done after thoroughly evaluating the impact on the existing plugins, probably in a future release. >>>> In the design the container ID would be a single value like this: >>>> >>>> $ ipa vault-add /services/server.example.com/HTTP >>>> >>>> And if the vault ID is relative (without initial slash), it will be >>>> appended to the user's private container (i.e. /users//): >>>> >>>> $ ipa vault-add PrivateVault >>>> >>>> The implementation is not complete yet. Currently it accepts this >>>> format: >>>> >>>> $ ipa vault-add [--container ] >>>> >>>> and I'm still planning to add this: >>>> >>>> $ ipa vault-add >> >> This is actually now done in the latest patch. Internally the ID is >> still split into name & parent ID. >> >>>> If the vault must be a child of vaultcontainer, and the vaultcontainer >>>> must be a child of a vaultcontainer, does it mean the vault ID would >>>> have to be split into separate arguments like this? >>>> >>>> $ ipa vaultcontainer-add services server.example.com HTTP >>>> >>>> If that's the case we'd lose the ability to specify a relative vault >>>> ID. >>> >>> Yes, that's the case. >>> >>> But I don't think relative IDs should be a problem, we can do this: >>> >>> $ ipa vaultcontainer-add a b c # absolute >>> $ ipa vaultcontainer-add . c # relative >> >> I think a "." will be confusing because there's no concept of "current >> vaultcontainer" like "current directory". >> >>> or this: >>> >>> $ ipa vaultcontainer-add '' a b c # absolute >>> $ ipa vaultcontainer-add c # relative >> >> An empty string is also confusing and can be problematic to distinguish >> with missing argument. > > I didn't mean empty string specifically, it could have been any special > value. > >>> or this: >>> >>> $ ipa vaultcontainer-add a b c # absolute >>> $ ipa vaultcontainer-add c --relative # relative >>> >>> or this: >>> >>> $ ipa vaultcontainer-add a b c --absolute # absolute >>> $ ipa vaultcontainer-add c # relative >> >> Per discussion in the IPA-CS meeting, we'd rather keep the "/" for vault >> ID delimiters because the spaces will be confusing to users, but we'll >> not use absolute ID anymore. > > I'm sorry if I gave you the impression that this is up for discussion, > but it is not. You either follow the convention without doing ugly hacks > or your patch will not be accepted. > > It won't be confusing to users, because they are used to the convention. Since the vault container plugin is removed, the hierarchical vault ID no longer needed, so this point is irrelevant now. >> It's not implemented yet, but here is the plan. By default the vault >> will be created in the user's private container: >> >> $ ipa vault-add PrivateVault >> >> For shared vaults, instead of specifying an absolute ID we can specify a >> --shared option: >> >> $ ipa vault-add --shared projects/IPA >> >> Same thing with service vaults: >> >> $ ipa vault-add --service server.example.com/LDAP >> >> To access a vault in another user's private container: >> >> $ ipa vault-show --user testuser PrivateVault > > Fine by me, as long as you follow the convention. The vault is now accessed using the name and the container: * private vault: ipa vault-show * shared vault: ipa vault-show --shared * service vault: ipa vault-show --host >>>>> 16) You do way too much stuff in vault_add.forward(). Only code that >>>>> must be done on the client needs to be there, i.e. handling of the >>>>> "data", "text" and "in" options. >>>>> >>>>> The vault_archive call must be in vault_add.execute(), otherwise a) we >>>>> will be making 2 RPC calls from the client and b) it won't be >>>>> called at >>>>> all when api.env.in_server is True. >>>> >>>> This is done by design. The vault_add.forward() generates the salt and >>>> the keys. The vault_archive.forward() will encrypt the data. These >>>> operations have to be done on the client side to secure the >>>> transport of >>>> the data from the client through the server and finally to KRA. This >>>> mechanism prevents the server from looking at the unencrypted data. >>> >>> OK, but that does not justify that it's broken in server-side API. It >>> can and should be done so that it works the same way on both client and >>> server. >>> >>> I think the best solution would be to split the command into two >>> commands, server-side vault_archive_raw to archive already encrypted >>> data, and client-side vault_archive to encrypt data and archive them >>> with vault_archive_raw in its .execute(). Same thing for vault_retrieve. >> >> Actually I think it's better to just merge the add and archive, reducing >> the number of RPC calls. The vault_archive now will support two types of >> operations: >> >> (a) Archive data into a new vault (it will create the vault just before >> archiving the data): >> >> $ ipa vault-archive testvault --create --in data ... >> >> (b) Archive data into an existing vault: >> >> $ ipa vault-archive testvault --in data ... >> >> The vault_add is now just a wrapper for the vault_archive(a). > > If that's just an implementation detail, OK. > > If it's possible to modify existing vault objects using vault-add or > create new objects using vault-archive, then NACK. > >>> BTW, I also think it would be better if there were 2 separate sets of >>> commands for binary and textual data >>> (vault_{archive,retrieve}_{data,text}) rather than trying to handle >>> everything in vault_{archive,retrieve}. >> >> I don't think we want to provide a separate command of every possible >> data type & operation combination. Users would get confused. The archive >> & retrieve commands should be able to handle all current & future data >> types with options. > > A command with two sets of mutually exclusive options is really two > commands in disguise, which is a good sign it should be divided into two > actual commands. > > Who are you to say users would get confused? I say they would be more > confused by a command with a plethora of mutually exclusive "options". > > What other possible data types are there? > >>>> The add & archive combination was added for convenience, not for >>>> optimization. This way you would be able to archive data into a new >>>> vault using a single command. Without this, you'd have to execute two >>>> separate commands: add & archive, which will result in 2 RPC calls >>>> anyway. >>> >>> I think I would prefer if it was separate, as that would be consistent >>> with other plugins (e.g. for objects with members, we don't allow adding >>> members directly in -add, you have to use -add-member after -add). >> >> The vault data is similar to group description, not group members. When >> creating a group we can supply the description. If not specified it will >> be blank. Archiving vault data is similar to updating the group >> description. > > It's similar to group members because there are separate commands to > manipulate them. > > You have to choose one of: > > a) vault data is settable using vault-add and vault-mod and gettable > using vault-mod, vault-show and vault-find > > b) vault data is settable using vault-archive and gettable using > vault-retrieve > > Anything in between is not permitted. > >> Vault secrets on the other hand is similar to group members. You will >> see that in the other patch. All archival/retrieval stuff will be addressed in a separate patch after the current patch (i.e. the basic structure & interface) is finalized. >>>>> 18) Why are vaultcontainer objects automatically created in >>>>> vault_find? >>>>> >>>>> This is just plain wrong and has to be removed, now. >>>> >>>> The code was supposed to create the user's private container like in >>>> #17, but the behavior has been changed. If the container being searched >>>> is the user's private container, it will ignore the container not found >>>> error and return zero results as if the private container already >>>> exists. For other containers the container must already exist. For this >>>> to work I had to add a handle_not_found() into LDAPSearch so the >>>> plugins >>>> can customize the proper search response for the missing private >>>> container. >>> >>> No ad-hoc refactoring please. If you want to refactor anything, it >>> should be first designed properly and put in a separate patch. >>> >>> Anyway, what should actually happen here is that if parent object is not >>> found, its object plugin's handle_not_found is called, i.e. something >>> like this: >>> >>> parent = self.obj.parent_object >>> if parent: >>> self.api.Object[parent].handle_not_found(*args[:-1]) >>> else: >>> raise errors.NotFound( >>> reason=self.obj.container_not_found_msg % { >>> 'container': self.obj.container_dn, >>> } >>> ) >> >> It will not work because vault doesn't have a parent object. I'm adding >> handle_not_found() into LDAPCreate and LDAPSearch in the first patch. > > NACK, this change exists for the sole reason of supporting your hacks. > Follow IPA convetions and this change won't be necessary. This is no longer relevant. >>>>> 21) vault_archive is not a retrieve operation, it should be based on >>>>> LDAPUpdate instead of LDAPRetrieve. Or Command actually, since it does >>>>> not do anything with LDAP. The same applies to vault_retrieve. >>>> >>>> The vault_archive does not actually modify the LDAP entry because it >>>> stores the data in KRA. It is actually an LDAPRetrieve operation >>>> because >>>> it needs to get the vault info before it can perform the archival >>>> operation. Same thing with vault_retrieve. >>> >>> It is not a LDAPRetrieve operation, because it has different semantics. >>> Please use Command as base class and either use ldap2 for direct LDAP or >>> call vault_show instead of hacking around LDAPRetrieve. >> >> It's been changed to inherit from LDAPQuery instead. > > NACK, it's not a LDAPQuery operation, because it has different > semantics. There is more to a command than executing code, so you should > use a correct base class. > >>>>> 22) vault_archive will break with binary data that is not UTF-8 >>>>> encoded >>>>> text. >>>>> >>>>> This is where it occurs: >>>>> >>>>> + vault_data[u'data'] = unicode(data) >>>>> >>>>> Generally, don't use unicode() on str values and str() on unicode >>>>> values >>>>> directly, always use .decode() and .encode(). >> >> The unicode(s, encoding) is actually equivalent to s.decode(encoding), >> so the following code will not solve the problem: >> >> vault_data[u'data'] = data.decode() >> >> As you said, decode() will only work if the data being decoded actually >> follows the encoding rules (i.e. already UTF-8 encoded). >> >>>> It needs to be a Unicode because json.dumps() doesn't work with binary >>>> data. Fixed by adding base-64 encoding. >> >> The base-64 encoding is necessary to convert random binaries into ASCII >> so it can be decoded into Unicode. Here is the current code: >> >> vault_data[u'data'] = unicode(base64.b64encode(data)) >> >> which is equivalent to: >> >> vault_data[u'data'] = base64.b64encode(data).decode() > > If you read a little bit further, you would get to the point, which is > certainly not calling .decode() without arguments, but *always > explicitly specify the encoding*. > >>> If something str needs to be unicode, you should use .decode() to >>> explicitly specify the encoding, instead of relying on unicode() to pick >>> the correct one. >> >> Since we know this is ASCII data we can now specify UTF-8 encoding. >> >> vault_data[u'data'] = base64.b64encode(data).decode('utf-8') >> >> But for anything that comes from user input (e.g. filenames, passwords), >> it's better to use the default encoding because that can be configured >> by the user. > > You are confusing user's configured encoding with Python's default > encoding. Default encoding in Python isn't derived from user's > localization settings. > > Anyway, anything that comes from user input is already decoded using > user's configured encoding when it enters the framework so I don't know > why are you even bringing it up here. > >>> Anyway, I think a better solution than base64 would be to use the >>> "raw_unicode_escape" encoding: >> >> As explained above, base-64 encoding is necessary because random >> binaries don't follow any encoding rules. I'd rather not use >> raw_unicode_escape because it's not really a text data. > > The result of decoding binary data using raw_unicode_escape is perfectly > valid unicode data which doesn't eat 33% more space like base64 encoded > binary does, hence my suggestion. > > Anyway, it turns out when encoded in JSON, raw_unicode_escape string > generally takes more space than base64 encoded string because of JSON > escaping, so base64 is indeed better. > >> Here's how it's >> now implemented: >> >>> if data: >>> data = data.decode('raw_unicode_escape') >> >> Input data is already in binaries, no conversion needed. >> >>> elif text: >>> data = text >> >> Input text will be converted to binaries with default encoding: >> >> data = text.encode() > > See what the default encoding actually is and why you shouldn't rely on > it above. > >>> elif input_file: >>> with open(input_file, 'rb') as f: >>> data = f.read() >>> data = data.decode('raw_unicode_escape') >> >> Input contains binary data, no conversion needed. >> >>> else: >>> data = u'' >> >> If not specified, the data will be empty string: >> >> data = '' >> >> The data needs to be converted into binaries so it can be encrypted >> before transport (depending on the vault type): >> >> data = self.obj.encrypt(data, ...) >> >>> vault_data[u'data'] = data >> >> Then for transport the data is base-64 encoded first, then converted >> into Unicode: >> >> vault_data[u'data'] = base64.b64encode(data).decode('utf-8') Same thing, all archival/retrieval stuff will be dealt with separately later. >>>>> 26) Instead of the delete_entry refactoring in baseldap and >>>>> vaultcontainer_add, you can put this in vaultcontainer_add's >>>>> pre_callback: >>>>> >>>>> try: >>>>> ldap.get_entries(dn, scope=ldap.SCOPE_ONELEVEL, >>>>> attrs_list=[]) >>>>> except errors.NotFound: >>>>> pass >>>>> else: >>>>> if not options.get('force', False): >>>>> raise errors.NotAllowedOnNonLeaf() >>>> >>>> I suppose you meant vaultcontainer_del. Fixed, but this will >>>> generate an >>>> additional search for each delete. >>>> >>>> I'm leaving the changes baseldap because it may be useful later and it >>>> doesn't change the behavior of the current code. >>> >>> Again, no ad-hoc refactoring please. >> >> The refactoring has also been moved into a separate patch. Just a note, >> I still don't think a plugin should do a search and maybe generate a >> NotAllowedOnLeaf exception on each delete operation. The exception >> should have been generated automatically by the DS. But we can discuss >> that separately. > > NACK, turns out there is a better (and preferable) solution I didn't > remember before, you can use exception callback in vaultcontainer_del: > > def exc_callback(self, keys, options, exc, call_func, *call_args, > **call_kwargs): > if call_func.func_name == 'delete_entry': > if isinstance(exc, errors.NotAllowedOnLeaf): > if not options.get('force', False): > raise errors.DatabaseError(...) > raise exc This is irrelevant too. >>>>> 28) The vault and vaultcontainer plugins seem to be pretty similar, I >>>>> think it would make sense to put common stuff in a base class and >>>>> inherit vault and vaultcontainer from that. >>>> >>>> I plan to refactor the common code later. Right now the focus is to get >>>> the functionality working correctly first. >>> >>> Please do it now, "later" usually means "never". It shouldn't be too >>> hard and I can give you a hand with it if you want. >> >> As mentioned above, I'm considering merging the vault & vault container >> classes, so no need to refactor the common code out of these classes. >> This will be delivered as a separate patch later. > > OK. Now irrelevant too. -- Endi S. Dewata -------------- next part -------------- >From dd39abebe083cc265b2eb6674cd602253993dd8f Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Tue, 21 Oct 2014 10:57:08 -0400 Subject: [PATCH] Added vault plugin. A new plugin has been added to manage vaults. Test scripts have also been added to verify the functionality. https://fedorahosted.org/freeipa/ticket/3872 --- API.txt | 69 ++++++ install/share/60basev3.ldif | 1 + install/updates/40-vault.update | 19 ++ install/updates/Makefile.am | 1 + ipa-client/man/default.conf.5 | 1 + ipalib/constants.py | 1 + ipalib/plugins/vault.py | 320 ++++++++++++++++++++++++++++ ipatests/test_xmlrpc/test_vault_plugin.py | 338 ++++++++++++++++++++++++++++++ 8 files changed, 750 insertions(+) create mode 100644 install/updates/40-vault.update create mode 100644 ipalib/plugins/vault.py create mode 100644 ipatests/test_xmlrpc/test_vault_plugin.py diff --git a/API.txt b/API.txt index f747765d7f9c87761fed0277cd59d1bc3fbd57e9..adb1116569a22b04a9ee6ad567166dfb3aca99ef 100644 --- a/API.txt +++ b/API.txt @@ -4562,6 +4562,75 @@ option: Str('version?', exclude='webui') output: Output('result', , None) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) +command: vault_add +args: 1,8,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[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: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) +option: Str('host?') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: Flag('shared?', autofill=True, default=False) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault_del +args: 1,4,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=True, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Flag('continue', autofill=True, cli_name='continue', default=False) +option: Str('host?') +option: Flag('shared?', autofill=True, default=False) +option: Str('version?', exclude='webui') +output: Output('result', , None) +output: Output('summary', (, ), None) +output: ListOfPrimaryKeys('value', None, None) +command: vault_find +args: 1,10,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='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=False) +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, query=True, required=False) +option: Str('host?') +option: Flag('pkey_only?', autofill=True, default=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('shared?', autofill=True, default=False) +option: Int('sizelimit?', autofill=False, minvalue=0) +option: Int('timelimit?', autofill=False, minvalue=0) +option: Str('version?', exclude='webui') +output: Output('count', , None) +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('truncated', , None) +command: vault_mod +args: 1,10,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('delattr*', cli_name='delattr', exclude='webui') +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) +option: Str('host?') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: Flag('shared?', autofill=True, default=False) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault_show +args: 1,6,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('host?') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Flag('shared?', autofill=True, default=False) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) capability: messages 2.52 capability: optional_uid_params 2.54 capability: permissions2 2.69 diff --git a/install/share/60basev3.ldif b/install/share/60basev3.ldif index 4efb1fe8ba8a91d3a8b920d39d217124066728c0..929b25d5ff739e0275f7b0cdb2e2cac6d026f083 100644 --- a/install/share/60basev3.ldif +++ b/install/share/60basev3.ldif @@ -77,3 +77,4 @@ objectClasses: (2.16.840.1.113730.3.8.12.24 NAME 'ipaPublicKeyObject' DESC 'Wrap objectClasses: (2.16.840.1.113730.3.8.12.25 NAME 'ipaPrivateKeyObject' DESC 'Wrapped private keys' SUP top AUXILIARY MUST ( ipaPrivateKey $ ipaWrappingKey $ ipaWrappingMech ) X-ORIGIN 'IPA v4.1' ) objectClasses: (2.16.840.1.113730.3.8.12.26 NAME 'ipaSecretKeyObject' DESC 'Wrapped secret keys' SUP top AUXILIARY MUST ( ipaSecretKey $ ipaWrappingKey $ ipaWrappingMech ) X-ORIGIN 'IPA v4.1' ) objectClasses: (2.16.840.1.113730.3.8.12.34 NAME 'ipaSecretKeyRefObject' DESC 'Indirect storage for encoded key material' SUP top AUXILIARY MUST ( ipaSecretKeyRef ) X-ORIGIN 'IPA v4.1' ) +objectClasses: (2.16.840.1.113730.3.8.18.1.1 NAME 'ipaVault' DESC 'IPA vault' SUP top STRUCTURAL MUST ( cn ) MAY ( description ) X-ORIGIN 'IPA v4.2' ) diff --git a/install/updates/40-vault.update b/install/updates/40-vault.update new file mode 100644 index 0000000000000000000000000000000000000000..5a6b8c6a022fa56e5a5bc05369ce143d39644092 --- /dev/null +++ b/install/updates/40-vault.update @@ -0,0 +1,19 @@ +dn: cn=vaults,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: cn: vaults + +dn: cn=services,cn=vaults,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: cn: services + +dn: cn=shared,cn=vaults,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: cn: shared + +dn: cn=users,cn=vaults,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: cn: users diff --git a/install/updates/Makefile.am b/install/updates/Makefile.am index 0d63d9ea8d85f1add5f036e7a39f89543586d33b..66f6b9d37971f8b8501d73fc6ddca21b6686ff4b 100644 --- a/install/updates/Makefile.am +++ b/install/updates/Makefile.am @@ -33,6 +33,7 @@ app_DATA = \ 40-dns.update \ 40-automember.update \ 40-otp.update \ + 40-vault.update \ 45-roles.update \ 50-7_bit_check.update \ 50-dogtag10-migration.update \ diff --git a/ipa-client/man/default.conf.5 b/ipa-client/man/default.conf.5 index dbc8a5b4647439de4de7c01152d098eb0561e236..0973f1a07179ad64daa326a02803cdc9ba1870aa 100644 --- a/ipa-client/man/default.conf.5 +++ b/ipa-client/man/default.conf.5 @@ -221,6 +221,7 @@ The following define the containers for the IPA server. Containers define where container_sudocmdgroup: cn=sudocmdgroups,cn=sudo container_sudorule: cn=sudorules,cn=sudo container_user: cn=users,cn=accounts + container_vault: cn=vaults container_virtual: cn=virtual operations,cn=etc .SH "FILES" diff --git a/ipalib/constants.py b/ipalib/constants.py index f1e14702ffdf5a3bd23a62b1fdd2ee3cd95d84f8..195938a355d1b24c02aa0a5833c1725c76e85c76 100644 --- a/ipalib/constants.py +++ b/ipalib/constants.py @@ -99,6 +99,7 @@ DEFAULT_CONFIG = ( ('container_hbacservice', DN(('cn', 'hbacservices'), ('cn', 'hbac'))), ('container_hbacservicegroup', DN(('cn', 'hbacservicegroups'), ('cn', 'hbac'))), ('container_dns', DN(('cn', 'dns'))), + ('container_vault', DN(('cn', 'vaults'))), ('container_virtual', DN(('cn', 'virtual operations'), ('cn', 'etc'))), ('container_sudorule', DN(('cn', 'sudorules'), ('cn', 'sudo'))), ('container_sudocmd', DN(('cn', 'sudocmds'), ('cn', 'sudo'))), diff --git a/ipalib/plugins/vault.py b/ipalib/plugins/vault.py new file mode 100644 index 0000000000000000000000000000000000000000..020e3045fce76210ecbacc8c967d3bdff29d9209 --- /dev/null +++ b/ipalib/plugins/vault.py @@ -0,0 +1,320 @@ +# Authors: +# Endi S. Dewata +# +# Copyright (C) 2015 Red Hat +# see file 'COPYING' for use and warranty information +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation, either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see . + +from ipalib import api, errors +from ipalib import Str, Flag +from ipalib import output +from ipalib.plugable import Registry +from ipalib.plugins.baseldap import LDAPObject, LDAPCreate, LDAPDelete,\ + LDAPSearch, LDAPUpdate, LDAPRetrieve +from ipalib.request import context +from ipalib.plugins.user import split_principal +from ipalib import _, ngettext +from ipapython.dn import DN + +__doc__ = _(""" +Vaults +""") + _(""" +Manage vaults. +""") + _(""" +EXAMPLES: +""") + _(""" + List private vaults: + ipa vault-find +""") + _(""" + List shared vaults: + ipa vault-find --shared +""") + _(""" + List service vaults: + ipa vault-find --host +""") + _(""" + Add a private vault: + ipa vault-add +""") + _(""" + Add a shared vault: + ipa vault-add --shared +""") + _(""" + Add a service vault: + ipa vault-add --host +""") + _(""" + Show a private vault: + ipa vault-show +""") + _(""" + Show a shared vault: + ipa vault-show --shared +""") + _(""" + Show a service vault: + ipa vault-show --host +""") + _(""" + Modify a private vault: + ipa vault-mod --desc +""") + _(""" + Modify a shared vault: + ipa vault-mod --shared --desc +""") + _(""" + Modify a service vault: + ipa vault-mod --host --desc +""") + _(""" + Delete a private vault: + ipa vault-del +""") + _(""" + Delete a shared vault: + ipa vault-del --shared +""") + _(""" + Delete a service vault: + ipa vault-del --host +""") + +register = Registry() + + + at register() +class vault(LDAPObject): + __doc__ = _(""" + Vault object. + """) + + base_dn = DN(api.env.container_vault, api.env.basedn) + + object_name = _('vault') + object_name_plural = _('vaults') + + object_class = ['ipaVault'] + default_attributes = [ + 'cn', + 'description', + ] + search_display_attributes = [ + 'cn', + 'description', + ] + + label = _('Vaults') + label_singular = _('Vault') + + takes_params = ( + Str( + 'cn', + cli_name='vault_name', + label=_('Vault name'), + primary_key=True, + pattern='^[a-zA-Z0-9_.-]+$', + pattern_errmsg='may only include letters, numbers, _, ., and -', + maxlength=255, + ), + Str( + 'description?', + cli_name='desc', + label=_('Description'), + doc=_('Vault description'), + ), + ) + + def get_dn(self, *args, **options): + """ + Generates vault DN from parameters. + """ + + vault_name = args[0] + + host = options.get('host') + shared = options.get('shared') + + dn = self.base_dn + + if host and shared: + raise errors.MutuallyExclusiveError( + reason=_('Host and shared options ' + + 'cannot be specified simultaneously')) + + elif host: + dn = DN(('cn', host), ('cn', 'services'), dn) + + elif shared: + dn = DN(('cn', 'shared'), dn) + + else: + principal = getattr(context, 'principal') + (username, realm) = split_principal(principal) + dn = DN(('cn', username), ('cn', 'users'), dn) + + if vault_name: + dn = DN(('cn', vault_name), dn) + + return dn + + def create_container(self, dn): + """ + Creates vault container and its parents. + """ + + rdn = dn[0] + entry = self.backend.make_entry( + dn, + { + 'objectclass': ['nsContainer'], + 'cn': rdn['cn'], + }) + + # if entry can be added, return + try: + self.backend.add_entry(entry) + return + + except errors.NotFound: + pass + + # otherwise, create parent entry first + parent_dn = DN(*dn[1:]) + self.create_container(parent_dn) + + # then create the entry itself again + self.backend.add_entry(entry) + + + at register() +class vault_add(LDAPCreate): + __doc__ = _('Create a new vault.') + + takes_options = LDAPCreate.takes_options + ( + Str( + 'host?', + doc=_('Service hostname'), + ), + Flag( + 'shared?', + doc=_('Shared vault'), + ), + ) + + has_output = output.standard_entry + + msg_summary = _('Added vault "%(value)s"') + + def pre_callback( + self, ldap, dn, entry_attrs, attrs_list, + *keys, **options): + assert isinstance(dn, DN) + + try: + parent_dn = DN(*dn[1:]) + self.obj.create_container(parent_dn) + + except errors.DuplicateEntry, e: + pass + + return dn + + + at register() +class vault_del(LDAPDelete): + __doc__ = _('Delete a vault.') + + takes_options = LDAPDelete.takes_options + ( + Str( + 'host?', + doc=_('Service hostname'), + ), + Flag( + 'shared?', + doc=_('Shared vault'), + ), + ) + + msg_summary = _('Deleted vault "%(value)s"') + + + at register() +class vault_find(LDAPSearch): + __doc__ = _('Search for vaults.') + + takes_options = LDAPSearch.takes_options + ( + Str( + 'host?', + doc=_('Service hostname'), + ), + Flag( + 'shared?', + doc=_('Shared vault'), + ), + ) + + msg_summary = ngettext( + '%(count)d vault matched', + '%(count)d vaults matched', + 0, + ) + + def pre_callback( + self, ldap, filter, attrs_list, base_dn, scope, + *args, **options): + + assert isinstance(base_dn, DN) + + base_dn = self.obj.get_dn(*args, **options) + + return (filter, base_dn, scope) + + def handle_not_found(self, *args, **options): + + host = options.get('host') + shared = options.get('shared') + + # if private container has not been created, ignore + if not host and not shared: + return + + # otherwise, raise an error + raise errors.NotFound( + reason=_('Container does not exist') + ) + + + at register() +class vault_mod(LDAPUpdate): + __doc__ = _('Modify a vault.') + + takes_options = LDAPUpdate.takes_options + ( + Str( + 'host?', + doc=_('Service hostname'), + ), + Flag( + 'shared?', + doc=_('Shared vault'), + ), + ) + + msg_summary = _('Modified vault "%(value)s"') + + + at register() +class vault_show(LDAPRetrieve): + __doc__ = _('Display information about a vault.') + + takes_options = LDAPRetrieve.takes_options + ( + Str( + 'host?', + doc=_('Service hostname'), + ), + Flag( + 'shared?', + doc=_('Shared vault'), + ), + ) diff --git a/ipatests/test_xmlrpc/test_vault_plugin.py b/ipatests/test_xmlrpc/test_vault_plugin.py new file mode 100644 index 0000000000000000000000000000000000000000..4bc1a930377957a7a822b8809b475e14b7facd74 --- /dev/null +++ b/ipatests/test_xmlrpc/test_vault_plugin.py @@ -0,0 +1,338 @@ +# Authors: +# Endi S. Dewata +# +# Copyright (C) 2015 Red Hat +# see file 'COPYING' for use and warranty information +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation, either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see . + +""" +Test the `ipalib/plugins/vault.py` module. +""" + +from ipalib import api, errors +from xmlrpc_test import Declarative, fuzzy_string + +test_vault = u'test_vault' +hostname = u'server.example.com' + + +class test_vault_plugin(Declarative): + + cleanup_commands = [ + ('vault_del', [test_vault], {'continue': True}), + ('vault_del', [test_vault], {'shared': True, 'continue': True}), + ('vault_del', [test_vault], {'host': hostname, 'continue': True}), + ] + + tests = [ + + { + 'desc': 'Create private vault', + 'command': ( + 'vault_add', + [test_vault], + {}, + ), + 'expected': { + 'value': test_vault, + 'summary': 'Added vault "%s"' % test_vault, + 'result': { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,%s' + % (test_vault, api.env.basedn), + 'objectclass': [u'top', u'ipaVault'], + 'cn': [test_vault], + }, + }, + }, + + { + 'desc': 'Find private vaults', + 'command': ( + 'vault_find', + [], + {}, + ), + 'expected': { + 'count': 1, + 'truncated': False, + 'summary': u'1 vault matched', + 'result': [ + { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,%s' + % (test_vault, api.env.basedn), + 'cn': [test_vault], + }, + ], + }, + }, + + { + 'desc': 'Show private vault', + 'command': ( + 'vault_show', + [test_vault], + {}, + ), + 'expected': { + 'value': test_vault, + 'summary': None, + 'result': { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,%s' + % (test_vault, api.env.basedn), + 'cn': [test_vault], + }, + }, + }, + + { + 'desc': 'Modify private vault', + 'command': ( + 'vault_mod', + [test_vault], + { + 'description': u'Test vault', + }, + ), + 'expected': { + 'value': test_vault, + 'summary': u'Modified vault "%s"' % test_vault, + 'result': { + 'cn': [test_vault], + 'description': [u'Test vault'], + }, + }, + }, + + { + 'desc': 'Delete private vault', + 'command': ( + 'vault_del', + [test_vault], + {}, + ), + 'expected': { + 'value': [test_vault], + 'summary': u'Deleted vault "%s"' % test_vault, + 'result': { + 'failed': (), + }, + }, + }, + + { + 'desc': 'Create shared vault', + 'command': ( + 'vault_add', + [test_vault], + { + 'shared': True + }, + ), + 'expected': { + 'value': test_vault, + 'summary': u'Added vault "%s"' % test_vault, + 'result': { + 'dn': u'cn=%s,cn=shared,cn=vaults,%s' + % (test_vault, api.env.basedn), + 'objectclass': [u'top', u'ipaVault'], + 'cn': [test_vault], + }, + }, + }, + + { + 'desc': 'Find shared vaults', + 'command': ( + 'vault_find', + [], + { + 'shared': True + }, + ), + 'expected': { + 'count': 1, + 'truncated': False, + 'summary': u'1 vault matched', + 'result': [ + { + 'dn': u'cn=%s,cn=shared,cn=vaults,%s' + % (test_vault, api.env.basedn), + 'cn': [test_vault], + }, + ], + }, + }, + + { + 'desc': 'Show shared vault', + 'command': ( + 'vault_show', + [test_vault], + { + 'shared': True + }, + ), + 'expected': { + 'value': test_vault, + 'summary': None, + 'result': { + 'dn': u'cn=%s,cn=shared,cn=vaults,%s' + % (test_vault, api.env.basedn), + 'cn': [test_vault], + }, + }, + }, + + { + 'desc': 'Modify shared vault', + 'command': ( + 'vault_mod', + [test_vault], + { + 'shared': True, + 'description': u'Test vault', + }, + ), + 'expected': { + 'value': test_vault, + 'summary': u'Modified vault "%s"' % test_vault, + 'result': { + 'cn': [test_vault], + 'description': [u'Test vault'], + }, + }, + }, + + { + 'desc': 'Delete shared vault', + 'command': ( + 'vault_del', + [test_vault], + { + 'shared': True + }, + ), + 'expected': { + 'value': [test_vault], + 'summary': u'Deleted vault "%s"' % test_vault, + 'result': { + 'failed': (), + }, + }, + }, + + { + 'desc': 'Create service vault', + 'command': ( + 'vault_add', + [test_vault], + { + 'host': hostname, + }, + ), + 'expected': { + 'value': test_vault, + 'summary': u'Added vault "%s"' % test_vault, + 'result': { + 'dn': u'cn=%s,cn=%s,cn=services,cn=vaults,%s' + % (test_vault, hostname, api.env.basedn), + 'objectclass': [u'top', u'ipaVault'], + 'cn': [test_vault], + }, + }, + }, + + { + 'desc': 'Find service vaults', + 'command': ( + 'vault_find', + [], + { + 'host': hostname, + }, + ), + 'expected': { + 'count': 1, + 'truncated': False, + 'summary': u'1 vault matched', + 'result': [ + { + 'dn': u'cn=%s,cn=%s,cn=services,cn=vaults,%s' + % (test_vault, hostname, api.env.basedn), + 'cn': [test_vault], + }, + ], + }, + }, + + { + 'desc': 'Show service vault', + 'command': ( + 'vault_show', + [test_vault], + { + 'host': hostname, + }, + ), + 'expected': { + 'value': test_vault, + 'summary': None, + 'result': { + 'dn': u'cn=%s,cn=%s,cn=services,cn=vaults,%s' + % (test_vault, hostname, api.env.basedn), + 'cn': [test_vault], + }, + }, + }, + + { + 'desc': 'Modify service vault', + 'command': ( + 'vault_mod', + [test_vault], + { + 'host': hostname, + 'description': u'Test vault', + }, + ), + 'expected': { + 'value': test_vault, + 'summary': u'Modified vault "%s"' % test_vault, + 'result': { + 'cn': [test_vault], + 'description': [u'Test vault'], + }, + }, + }, + + { + 'desc': 'Delete service vault', + 'command': ( + 'vault_del', + [test_vault], + { + 'host': hostname, + }, + ), + 'expected': { + 'value': [test_vault], + 'summary': u'Deleted vault "%s"' % test_vault, + 'result': { + 'failed': (), + }, + }, + }, + + ] -- 1.9.3 From pvoborni at redhat.com Tue May 12 11:02:22 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 12 May 2015 13:02:22 +0200 Subject: [Freeipa-devel] [PATCH 0031] provide a dedicated ccache file to httpd In-Reply-To: <20150512092236.GL5152@redhat.com> References: <554117FB.7070203@redhat.com> <5541B88A.4080506@redhat.com> <20150430062325.GG11785@redhat.com> <554732C2.3030707@redhat.com> <20150512055020.GH5152@redhat.com> <5551B442.3040605@redhat.com> <20150512092236.GL5152@redhat.com> Message-ID: <5551DDBE.6080509@redhat.com> On 05/12/2015 11:22 AM, Alexander Bokovoy wrote: > On Tue, 12 May 2015, Martin Babinsky wrote: >>>> %attr(644,root,root) %{_unitdir}/ipa-ods-exporter.service >>>> +%attr(644,root,root) %{etc_systemd_dir}/httpd.service >>> There is a minor issue: a lack of >>> >>> Requires: /etc/systemd/system >>> >>> which is needed because of /etc/systemd/system directory owned by a >>> different package. We require systemd-units which is provided by systemd >>> package as well so it is sort of mitigated by that but it would >>> good to be explicit in the require. And yes, you can require the >>> directory because systemd provides it: >>> >>> $ rpm -q --whatprovides /etc/systemd/system >>> systemd-219-13.fc22.x86_64 >>> >>> Otherwise, ACK. >>> >> thank for review Alexander, attaching updated patch. > ACK Pushed to master: 9a1a409d63e30dcb939b672d352fc4aa7ba690fe -- Petr Vobornik From dkupka at redhat.com Tue May 12 11:53:03 2015 From: dkupka at redhat.com (David Kupka) Date: Tue, 12 May 2015 13:53:03 +0200 Subject: [Freeipa-devel] [PATCH] 0048 Remove unused enable() method from DogtagInstance. Message-ID: <5551E99F.80003@redhat.com> DogtagInstance.enable() overrides Service.enable() and does nothing usefulll. Also removing it solves bug discovered recently in uninstall procedure. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0048-Remove-unused-enable-method-from-DogtagInstance.patch Type: text/x-patch Size: 1354 bytes Desc: not available URL: From pvoborni at redhat.com Tue May 12 11:57:40 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 12 May 2015 13:57:40 +0200 Subject: [Freeipa-devel] [PATCH] 801-806 webui-ci: otptoken tests In-Reply-To: <5550919E.9090802@redhat.com> References: <54E5F888.2000402@redhat.com> <554B4E9F.1070806@redhat.com> <5550919E.9090802@redhat.com> Message-ID: <5551EAB4.2000803@redhat.com> On 05/11/2015 01:25 PM, Milan Kubik wrote: > On 05/07/2015 01:38 PM, Petr Vobornik wrote: >> On 02/19/2015 03:51 PM, Petr Vobornik wrote: >>> https://fedorahosted.org/freeipa/ticket/4307 >>> >>> For ipa-4-1 apply: >>> - patch 800 (different thread) >>> - patches 801-806 >>> >>> For master apply: >>> - patch 800 (different thread) >>> - patch 807 (different thread) >>> - patch 801-master >>> - patches 802-806 >>> >>> Patch 801 allows to use ipalib rpc client in Web UI test suite. >>> Patches 802-805 are various ui_driver fixes to allow stuff in patch 806. >>> >>> == [PATCH] 806 webui-ci: otptoken tests == >>> >>> Basic otptoken Web UI CI coverage. >>> >>> tests: >>> * crud for otptokens as admin >>> * crud for normal users >>> * checks fields of adder dialog for both token types and user role >>> (admin/user) >>> * token actions as admin (enable, disable, delete) >>> * token actions as normal user (delete) >>> * login as normal user with hotp and totp token >>> * sync token hotp and totp token as normal user and then login >>> >>> https://fedorahosted.org/freeipa/ticket/4307 >>> >>> == [PATCH] 805 webui-ci: allow custom names for disable/enable >>> actions == >>> >>> Not all disable and enable actions are called 'disable' and 'enable'. >>> >>> == [PATCH] 804 webui-ci: allow to update pkey in post-add in basic-crud >>> tests == >>> >>> == [PATCH] 803 webui-ci: add post_add_action == >>> >>> post add action allows to fill autogenerated values, e.g. a pkey of new >>> otptoken. >>> >>> This value can be then used in other subsequent test which would depend >>> on it - like crud tests. >>> >>> == [PATCH] 802 webui-ci: fix negative visibility check == >>> >>> Allow to define, that element doesn't have to be present on a page for >>> negative visible checks. >>> >>> E.g. if element is added only if it's displayed and is removed >>> otherwise. >>> >>> == [PATCH] 801 webui-ci: support direct IPA API calls == >>> >>> Add IPA API support to ui_driver. It leverages new ipalib RPC client's >>> forms based authentication. It then allows to call an IPA API while >>> the machine is not an IPA client nor is kerberized. >>> >>> api's environment values are taken from test configuration and >>> therefore duplication in ~/.ipa/default.conf is not required. >>> >>> Since the machine doesn't have to be IPA client, it then also doesn't >>> have nss database with IPA's CA certificate. Therefore on each API >>> initialization a new NSS database is created with a CA certificate >>> downloaded from IPA. This db is deleted in tearDown phase. >>> >>> Usage: >>> >>> 1. as admin one can immediately call rpc commands, api will be >>> initialized upon first request and is available under self.api >>> (assuming self is ui_driver): >>> self.api.Command.user_del(USER_ID, **{'continue': True}) >>> >>> 2. to reconnect as other user: >>> self.reconnect_api(USER_ID, USER_PW) >>> >>> 3. reconnect back as admin: >>> self.reconnect_api() >>> >> >> Patch #803 needed rebase. >> >> > Hi, thanks for the patches. > > Please, fix pep8 complaints in 803, 805 and 806. $ git diff HEAD~6 -U0 | pep8 --diff returns 20x E501 line too long IMO, it's better this way for better code readability. > Also, change the header in 806 to the shorter version, please. Fixed, patches were regenerated. > > # > # Copyright (C) 2015 FreeIPA Contributors see COPYING for license > # > > Patches 801, 802 and 804 look good to me. > The test cases in 806 look good to me as well. > > Milan > -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0806-2-webui-ci-otptoken-tests.patch Type: text/x-patch Size: 14323 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0805-2-webui-ci-allow-custom-names-for-disable-enable-actio.patch Type: text/x-patch Size: 1705 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0804-2-webui-ci-allow-to-update-pkey-in-post-add-in-basic-c.patch Type: text/x-patch Size: 1504 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0803-2-webui-ci-add-post_add_action.patch Type: text/x-patch Size: 2136 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0802-2-webui-ci-fix-negative-visibility-check.patch Type: text/x-patch Size: 1556 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0801-2-webui-ci-support-direct-IPA-API-calls.patch Type: text/x-patch Size: 6003 bytes Desc: not available URL: From mbasti at redhat.com Tue May 12 12:16:41 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 12 May 2015 14:16:41 +0200 Subject: [Freeipa-devel] [PATCH] 0048 Remove unused enable() method from DogtagInstance. In-Reply-To: <5551E99F.80003@redhat.com> References: <5551E99F.80003@redhat.com> Message-ID: <5551EF29.7000501@redhat.com> 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 -- Martin Basti From tbordaz at redhat.com Tue May 12 12:17:02 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 12 May 2015 14:17:02 +0200 Subject: [Freeipa-devel] [PATCH] 0005 User life cycle: del/mod/find/show stageuser commands In-Reply-To: <554869C3.2040509@redhat.com> References: <552F964E.2060304@redhat.com> <553F437D.5080103@redhat.com> <553F44B7.6040100@redhat.com> <553F476E.8080502@redhat.com> <553F9BCE.6010000@redhat.com> <554869C3.2040509@redhat.com> Message-ID: <5551EF3E.1060503@redhat.com> On 05/05/2015 08:57 AM, Jan Cholasta wrote: > Hi, > > Dne 28.4.2015 v 16:40 thierry bordaz napsal(a): >> On 04/28/2015 10:40 AM, David Kupka wrote: >>> On 04/28/2015 10:28 AM, thierry bordaz wrote: >>>> On 04/28/2015 10:23 AM, David Kupka wrote: >>>>> On 04/16/2015 01:00 PM, thierry bordaz wrote: >>>>>> Hello, >>>>>> >>>>>> Here is the next patch for User life cycle that introduces >>>>>> del/mod/find and show stageuser plugin commands. >>>>>> >>>>>> * 0000-User Life Cycle (create containers and scoping DS plugins): >>>>>> *pushed* >>>>>> * 0001-User-Life-Cycle-Exclude-subtree-for-ipaUniqueID-gene.patch: >>>>>> *pushed* >>>>>> * 0002-User-life-cycle-stageuser-add-verb.patch: *pushed* >>>>>> * 0007-User-life-cycle-allows-MODRDN-from-ldap2.patch: *pushed* >>>>>> * 0003-User-life-cycle-new-stageuser-commands-del-mod-find-*under >>>>>> review *(this one)** >>>>>> * 0004-User-life-cycle-new-stageuser-commands-activate.patch >>>>>> * 0005-User-life-cycle-new-stageuser-commands-activate-prov.patch >>>>>> * 0006-User-life-cycle-user-del-supports-permanently-preser.patch >>>>>> * 0008-User-life-cycle-user-find-support-finding-delete-use.patch >>>>>> * 0009-User-life-cycle-support-of-user-undel.patch >>>>>> * 0010-User-life-cycle-DNA-DS-plugin-should-exclude-provisi.patch >>>>>> * 0011-User-life-cycle-lockout-provisioning-stage-and-delet.patch >>>>>> * 0012-User-life-cycle-Create-stage-Admin-provisioning-acco.patch >>>>>> * 0013-User-life-cycle-Stage-Admin-permission-priviledge.patch >>>>>> >>>>>> Thanks >>>>>> thierry >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Hi Thierry, >>>>> thanks for the patch, the code looks good to me but there is probably >>>>> a bug in ACIs. >>>>> After creating a stage user and setting password for him I can kinit >>>>> as the stage user. I'm unable to login to the IPA client and id >>>>> command for this stage user responds "no such user" but I can kinit >>>>> and invoke ipa commands. >>>>> >>>>> Steps: >>>>> 0. build freeipa with your patch >>>>> 1. # ipa-server-install >>>>> 2. $ kinit admin >>>>> 3. $ ipa stageuser-add suser0 --first Stage --last User --password >>>>> 4. $ kdestroy >>>>> 5. $ kinit suser0 >>>>> 6. $ ipa user-find >>>>> >>>>> Actual: >>>>> Prints out list of ipa users. >>>>> >>>>> Expected: >>>>> kinit fails with "suser0 at ... not found in Kerberos database" >>>>> >>>> Hi David, >>>> >>>> Thank you so much for having looked at this patch :-) >>>> You are right. The Staging users (as well as the Delete users) are not >>>> lockout in that patch. >>>> The patch >>>> 0011-User-life-cycle-lockout-provisioning-stage-and-delet.patch will >>>> take care of this. >>>> >>>> Do you prefer that I merged the two patches right now ? >>>> >>>> thanks >>>> thierry >>>> >>> >>> Hi Thierry, >>> no, it is not necessary to merge the patches it's ok to have it >>> separated. I'm not sure if the patch should be pushed now or rather >>> wait and push it together with the others. >>> I'm looking forward to next ULC patches from you. >>> >> >> >> Hi David, >> >> Here are all the available patches. >> I also attach a test script that is a kind of regression tests that I am >> using. >> >> Thanks again >> thierry >> >> > > Some issues I have found during a quick read of the patches: > > > Patch 0005: > > 1) This does nothing and can be safely removed: > > + def pre_callback(self, ldap, dn, *keys, **options): > + assert isinstance(dn, DN) > + return dn > > > 2) stageuser_{mod,find,show} have a lot of code that seems to be > copy-pasted from user_{mod,find,show}. I would prefer if the code was > shared instead of copy-pasted, preferably in baseuser_{mod,find,show}. > > > Patch 0006: > > 1) These do nothing and can be safely removed: > > + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, > **options): > + assert isinstance(dn, DN) > + return dn > + > + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): > + assert isinstance(dn, DN) > + return dn > > > 2) You should use output.standard_entry for has_output, as you are > only returning one entry. Or you could add support for activating > multiple users at once. > > > 3) IMO the "time to build the new entry" and "add the active entry" > parts should be done by calling user-add, so that the (active) user > creation routine is the same. > > > 4) Please use a single line to separate method definitions in classes. > > > Patch 008: > > 1) I guess you forgot to remove these: > > + self.log.error("====> user-add pre_callback 1 %s " % dn) > > + self.log.error("====> user-add pre_callback %s " % dn) > > > 2) > > + takes_options = LDAPDelete.takes_options + ( > > This should be "baseuser_del.takes_options + ...". > > > Honza > Hello, This is the set of revisited patches for ULC. Here are the changes done versus the previous patches Patch 0005: Refactoring stageuser+user => baseuser Patch 0006: Lock stage/delete users, add activated user into ipausers, stageuser-activate process a single entry Patch 0007 Refactoring stageuser+user => baseuser, GID number lost during activation Patch 0008 user take_options from baseuser_del rather than LDAPDelete Patch 0009 Refactoring stageuser+user => baseuser, remove debug traces Patch 0010 Refactoring stageuser+user => baseuser,, add undelete user into ipausers Patch 0011 (previous patch 0011 was merged in Patch 0006: lockout stage/delete users) Change due to CSV Patch 0012 Change due to CSV, permission tests It does not take into account your request Honza to use 'user-add' command when activating a user. I will work on that now and submit an other patch later for that. Thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbordaz-0013-User-life-cycle-Add-Stage-User-Provisioning-permissi.patch Type: text/x-patch Size: 5606 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbordaz-0012-1-User-life-cycle-Stage-user-Administrators-permission.patch Type: text/x-patch Size: 30415 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbordaz-0011-1-User-life-cycle-DNA-DS-plugin-should-exclude-provisi.patch Type: text/x-patch Size: 987 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbordaz-0010-1-User-life-cycle-support-of-user-undel.patch Type: text/x-patch Size: 4502 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbordaz-0009-1-User-life-cycle-user-find-support-finding-delete-use.patch Type: text/x-patch Size: 4608 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbordaz-0008-1-User-life-cycle-user-del-supports-permanently-preser.patch Type: text/x-patch Size: 9203 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbordaz-0007-1-User-life-cycle-new-stageuser-commands-activate-prov.patch Type: text/x-patch Size: 6710 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbordaz-0006-1-User-life-cycle-new-stageuser-commands-activate.patch Type: text/x-patch Size: 17812 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbordaz-0005-1-User-life-cycle-new-stageuser-commands-del-mod-find-.patch Type: text/x-patch Size: 29803 bytes Desc: not available URL: From mbasti at redhat.com Tue May 12 12:44:37 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 12 May 2015 14:44:37 +0200 Subject: [Freeipa-devel] [PATCHES 0239-0243] Server Upgrade: minor fixes Message-ID: <5551F5B5.6010702@redhat.com> https://fedorahosted.org/freeipa/ticket/4904 Patches attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0239-Server-Upgrade-Do-not-start-DS-if-it-was-stopped-bef.patch Type: text/x-patch Size: 1726 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0240-Server-Upgrade-raise-RuntimeError-instead-exit.patch Type: text/x-patch Size: 1092 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0241-Server-Upgrade-do-not-allow-to-run-upgradeinstace-al.patch Type: text/x-patch Size: 1224 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0242-Server-Upgrade-handle-errors-better.patch Type: text/x-patch Size: 6238 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0243-Server-Upgrade-ipa-ldap-updater-will-not-do-overall-.patch Type: text/x-patch Size: 5131 bytes Desc: not available URL: From abokovoy at redhat.com Tue May 12 12:46:15 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 12 May 2015 15:46:15 +0300 Subject: [Freeipa-devel] [PATCH] 0178 Fix AD trusts in Fedora 22 In-Reply-To: <20150512053707.GF5152@redhat.com> References: <20150508130753.GA4748@onega.vda.li> <20150512053707.GF5152@redhat.com> Message-ID: <20150512124615.GN5152@redhat.com> On Tue, 12 May 2015, Alexander Bokovoy wrote: >On Fri, 08 May 2015, Alexander Bokovoy wrote: >>Hi, >> >>attached patch fixes issues with Samba 4.2 in Fedora 22. >> >>See commit message for the details. Note that you'll >>also need Samba fixes from https://bugzilla.redhat.com/show_bug.cgi?id=1219832 >>to test the patch. >> >>Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1219834 >An update is available in Bodhi: >https://admin.fedoraproject.org/updates/samba-4.2.1-8.fc22,freeipa-4.1.4-3.fc22 > >Please test and support. Attached please find an update of the patch 0178. I've found one typo which was missed in the original version due to exception handling. I'll update bodhi request when builds are ready. -- / Alexander Bokovoy -------------- next part -------------- From 28fccac07760764acc86f9c91850481ef2c1e1ae Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 8 May 2015 12:09:13 +0000 Subject: [PATCH 2/3] ipaserver/dcerpc: Ensure LSA pipe has session key before using it With Samba 4.2 there is a bug that prevents Samba to consider Kerberos credentials used by IPA httpd process when talking to smbd. As result, LSA RPC connection is seen as anonymous by Samba client code and we cannot derive session key to use for encrypting trust secrets before transmitting them. Additionally, rewrite of the SMB protocol support in Samba caused previously working logic of choosing DCE RPC binding string to fail. We need to try a different set of priorities until they fail or succeed. Requires Samba fixes from https://bugzilla.redhat.com/show_bug.cgi?id=1219832 Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1219834 --- ipaserver/dcerpc.py | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index e342c49..44689cc 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -89,6 +89,10 @@ dcerpc_error_codes = { -1073741811: # NT_STATUS_INVALID_PARAMETER errors.RemoteRetrieveError( reason=_('AD domain controller complains about communication sequence. It may mean unsynchronized time on both sides, for example')), + -1073741776: # NT_STATUS_INVALID_PARAMETER_MIX, we simply will skip the binding + access_denied_error, + -1073741772: # NT_STATUS_OBJECT_NAME_NOT_FOUND + errors.RemoteRetrieveError(reason=_('CIFS server configuration does not allow access to \\\\pipe\\lsarpc')), } dcerpc_error_messages = { @@ -728,16 +732,20 @@ class TrustDomainInstance(object): return attempts = 0 + session_attempts = 0 bindings = self.__gen_lsa_bindings(remote_host) for binding in bindings: try: self._pipe = self.__gen_lsa_connection(binding) - if self._pipe: + if self._pipe and self._pipe.session_key: break except errors.ACIError, e: attempts = attempts + 1 + except RuntimeError, e: + # When session key is not available, we just skip this binding + session_attempts = session_attempts + 1 - if self._pipe is None and attempts == len(bindings): + if self._pipe is None and (attempts + session_attempts) == len(bindings): raise errors.ACIError( info=_('CIFS server %(host)s denied your credentials') % dict(host=remote_host)) @@ -745,6 +753,7 @@ class TrustDomainInstance(object): raise errors.RemoteRetrieveError( reason=_('Cannot establish LSA connection to %(host)s. Is CIFS server running?') % dict(host=remote_host)) self.binding = binding + self.session_key = self._pipe.session_key def __gen_lsa_bindings(self, remote_host): """ @@ -753,11 +762,11 @@ class TrustDomainInstance(object): Generate all we can use. init_lsa_pipe() will try them one by one until there is one working. - We try NCACN_NP before NCACN_IP_TCP and signed sessions before unsigned. + We try NCACN_NP before NCACN_IP_TCP and use SMB2 before SMB1 or defaults. """ transports = (u'ncacn_np', u'ncacn_ip_tcp') - options = ( u',', u'') - binding_template=lambda x,y,z: u'%s:%s[%s]' % (x, y, z) + options = ( u'smb2', u'smb1', u'') + binding_template=lambda x,y,z: u'%s:%s[%s,print]' % (x, y, z) return [binding_template(t, remote_host, o) for t in transports for o in options] def retrieve_anonymously(self, remote_host, discover_srv=False, search_pdc=False): -- 2.4.0 From mbasti at redhat.com Tue May 12 12:51:41 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 12 May 2015 14:51:41 +0200 Subject: [Freeipa-devel] [PATCH 0244] DNSSEC: fix traceback in ipa-dnskeysyncd during shutdown phase Message-ID: <5551F75D.6040106@redhat.com> https://fedorahosted.org/freeipa/ticket/4657 Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0244-DNSSEC-fix-traceback-during-shutdown-phase.patch Type: text/x-patch Size: 1857 bytes Desc: not available URL: From abokovoy at redhat.com Tue May 12 14:03:52 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 12 May 2015 17:03:52 +0300 Subject: [Freeipa-devel] [PATCH] 0178 Fix AD trusts in Fedora 22 In-Reply-To: <20150512124615.GN5152@redhat.com> References: <20150508130753.GA4748@onega.vda.li> <20150512053707.GF5152@redhat.com> <20150512124615.GN5152@redhat.com> Message-ID: <20150512140352.GO5152@redhat.com> On Tue, 12 May 2015, Alexander Bokovoy wrote: >On Tue, 12 May 2015, Alexander Bokovoy wrote: >>On Fri, 08 May 2015, Alexander Bokovoy wrote: >>>Hi, >>> >>>attached patch fixes issues with Samba 4.2 in Fedora 22. >>> >>>See commit message for the details. Note that you'll >>>also need Samba fixes from https://bugzilla.redhat.com/show_bug.cgi?id=1219832 >>>to test the patch. >>> >>>Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1219834 >>An update is available in Bodhi: >>https://admin.fedoraproject.org/updates/samba-4.2.1-8.fc22,freeipa-4.1.4-3.fc22 >> >>Please test and support. >Attached please find an update of the patch 0178. I've found one typo >which was missed in the original version due to exception handling. > >I'll update bodhi request when builds are ready. Updated bodhi request: https://admin.fedoraproject.org/updates/samba-4.2.1-8.fc22,freeipa-4.1.4-4.fc22 Please test! -- / Alexander Bokovoy From dkupka at redhat.com Tue May 12 14:54:48 2015 From: dkupka at redhat.com (David Kupka) Date: Tue, 12 May 2015 16:54:48 +0200 Subject: [Freeipa-devel] [PATCH] 0048 Remove unused enable() method from DogtagInstance. In-Reply-To: <5551EF29.7000501@redhat.com> References: <5551E99F.80003@redhat.com> <5551EF29.7000501@redhat.com> Message-ID: <55521438.8060503@redhat.com> 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. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0048.1-Rename-DogtagInstance-method-enable-to-_backup_state.patch Type: text/x-patch Size: 2073 bytes Desc: not available URL: From tbordaz at redhat.com Tue May 12 15:05:29 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 12 May 2015 17:05:29 +0200 Subject: [Freeipa-devel] [PATCH] 0005 User life cycle: del/mod/find/show stageuser commands In-Reply-To: <5551EF3E.1060503@redhat.com> References: <552F964E.2060304@redhat.com> <553F437D.5080103@redhat.com> <553F44B7.6040100@redhat.com> <553F476E.8080502@redhat.com> <553F9BCE.6010000@redhat.com> <554869C3.2040509@redhat.com> <5551EF3E.1060503@redhat.com> Message-ID: <555216B9.1070106@redhat.com> On 05/12/2015 02:17 PM, thierry bordaz wrote: > On 05/05/2015 08:57 AM, Jan Cholasta wrote: >> Hi, >> >> Dne 28.4.2015 v 16:40 thierry bordaz napsal(a): >>> On 04/28/2015 10:40 AM, David Kupka wrote: >>>> On 04/28/2015 10:28 AM, thierry bordaz wrote: >>>>> On 04/28/2015 10:23 AM, David Kupka wrote: >>>>>> On 04/16/2015 01:00 PM, thierry bordaz wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Here is the next patch for User life cycle that introduces >>>>>>> del/mod/find and show stageuser plugin commands. >>>>>>> >>>>>>> * 0000-User Life Cycle (create containers and scoping DS >>>>>>> plugins): >>>>>>> *pushed* >>>>>>> * >>>>>>> 0001-User-Life-Cycle-Exclude-subtree-for-ipaUniqueID-gene.patch: >>>>>>> *pushed* >>>>>>> * 0002-User-life-cycle-stageuser-add-verb.patch: *pushed* >>>>>>> * 0007-User-life-cycle-allows-MODRDN-from-ldap2.patch: *pushed* >>>>>>> * 0003-User-life-cycle-new-stageuser-commands-del-mod-find-*under >>>>>>> review *(this one)** >>>>>>> * 0004-User-life-cycle-new-stageuser-commands-activate.patch >>>>>>> * 0005-User-life-cycle-new-stageuser-commands-activate-prov.patch >>>>>>> * 0006-User-life-cycle-user-del-supports-permanently-preser.patch >>>>>>> * 0008-User-life-cycle-user-find-support-finding-delete-use.patch >>>>>>> * 0009-User-life-cycle-support-of-user-undel.patch >>>>>>> * 0010-User-life-cycle-DNA-DS-plugin-should-exclude-provisi.patch >>>>>>> * 0011-User-life-cycle-lockout-provisioning-stage-and-delet.patch >>>>>>> * 0012-User-life-cycle-Create-stage-Admin-provisioning-acco.patch >>>>>>> * 0013-User-life-cycle-Stage-Admin-permission-priviledge.patch >>>>>>> >>>>>>> Thanks >>>>>>> thierry >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Hi Thierry, >>>>>> thanks for the patch, the code looks good to me but there is >>>>>> probably >>>>>> a bug in ACIs. >>>>>> After creating a stage user and setting password for him I can kinit >>>>>> as the stage user. I'm unable to login to the IPA client and id >>>>>> command for this stage user responds "no such user" but I can kinit >>>>>> and invoke ipa commands. >>>>>> >>>>>> Steps: >>>>>> 0. build freeipa with your patch >>>>>> 1. # ipa-server-install >>>>>> 2. $ kinit admin >>>>>> 3. $ ipa stageuser-add suser0 --first Stage --last User --password >>>>>> 4. $ kdestroy >>>>>> 5. $ kinit suser0 >>>>>> 6. $ ipa user-find >>>>>> >>>>>> Actual: >>>>>> Prints out list of ipa users. >>>>>> >>>>>> Expected: >>>>>> kinit fails with "suser0 at ... not found in Kerberos database" >>>>>> >>>>> Hi David, >>>>> >>>>> Thank you so much for having looked at this patch :-) >>>>> You are right. The Staging users (as well as the Delete users) are >>>>> not >>>>> lockout in that patch. >>>>> The patch >>>>> 0011-User-life-cycle-lockout-provisioning-stage-and-delet.patch will >>>>> take care of this. >>>>> >>>>> Do you prefer that I merged the two patches right now ? >>>>> >>>>> thanks >>>>> thierry >>>>> >>>> >>>> Hi Thierry, >>>> no, it is not necessary to merge the patches it's ok to have it >>>> separated. I'm not sure if the patch should be pushed now or rather >>>> wait and push it together with the others. >>>> I'm looking forward to next ULC patches from you. >>>> >>> >>> >>> Hi David, >>> >>> Here are all the available patches. >>> I also attach a test script that is a kind of regression tests that >>> I am >>> using. >>> >>> Thanks again >>> thierry >>> >>> >> >> Some issues I have found during a quick read of the patches: >> >> >> Patch 0005: >> >> 1) This does nothing and can be safely removed: >> >> + def pre_callback(self, ldap, dn, *keys, **options): >> + assert isinstance(dn, DN) >> + return dn >> >> >> 2) stageuser_{mod,find,show} have a lot of code that seems to be >> copy-pasted from user_{mod,find,show}. I would prefer if the code was >> shared instead of copy-pasted, preferably in baseuser_{mod,find,show}. >> >> >> Patch 0006: >> >> 1) These do nothing and can be safely removed: >> >> + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, >> **options): >> + assert isinstance(dn, DN) >> + return dn >> + >> + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): >> + assert isinstance(dn, DN) >> + return dn >> >> >> 2) You should use output.standard_entry for has_output, as you are >> only returning one entry. Or you could add support for activating >> multiple users at once. >> >> >> 3) IMO the "time to build the new entry" and "add the active entry" >> parts should be done by calling user-add, so that the (active) user >> creation routine is the same. >> >> >> 4) Please use a single line to separate method definitions in classes. >> >> >> Patch 008: >> >> 1) I guess you forgot to remove these: >> >> + self.log.error("====> user-add pre_callback 1 %s " % dn) >> >> + self.log.error("====> user-add pre_callback %s " % dn) >> >> >> 2) >> >> + takes_options = LDAPDelete.takes_options + ( >> >> This should be "baseuser_del.takes_options + ...". >> >> >> Honza >> > > Hello, > > This is the set of revisited patches for ULC. Here are the changes > done versus the previous patches > > Patch 0005: > > Refactoring stageuser+user => baseuser > > > Patch 0006: > > Lock stage/delete users, add activated user into ipausers, > stageuser-activate process a single entry > > > Patch 0007 > > Refactoring stageuser+user => baseuser, GID number lost > during activation > > Patch 0008 > > user take_options from baseuser_del rather than LDAPDelete > > Patch 0009 > > Refactoring stageuser+user => baseuser, remove debug traces > > Patch 0010 > > Refactoring stageuser+user => baseuser,, add undelete user > into ipausers > > Patch 0011 (previous patch 0011 was merged in Patch 0006: > lockout stage/delete users) > > Change due to CSV > > Patch 0012 > > Change due to CSV, permission tests > > It does not take into account your request Honza to use 'user-add' > command when activating a user. > I will work on that now and submit an other patch later for that. > > Thanks > thierry > > > > > IPA_API_VERSION_MINOR was invalid in the first patch 0005. I am sorry for that. Here is the next set of patches. Only patch 0005 differs from my previous email thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbordaz-0013-User-life-cycle-Add-Stage-User-Provisioning-permissi.patch Type: text/x-patch Size: 5606 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbordaz-0012-1-User-life-cycle-Stage-user-Administrators-permission.patch Type: text/x-patch Size: 30415 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbordaz-0011-1-User-life-cycle-DNA-DS-plugin-should-exclude-provisi.patch Type: text/x-patch Size: 987 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbordaz-0010-1-User-life-cycle-support-of-user-undel.patch Type: text/x-patch Size: 4502 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbordaz-0009-1-User-life-cycle-user-find-support-finding-delete-use.patch Type: text/x-patch Size: 4608 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbordaz-0008-1-User-life-cycle-user-del-supports-permanently-preser.patch Type: text/x-patch Size: 9203 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbordaz-0007-1-User-life-cycle-new-stageuser-commands-activate-prov.patch Type: text/x-patch Size: 6710 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbordaz-0006-1-User-life-cycle-new-stageuser-commands-activate.patch Type: text/x-patch Size: 17812 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbordaz-0005-2-User-life-cycle-new-stageuser-commands-del-mod-find-.patch Type: text/x-patch Size: 29824 bytes Desc: not available URL: From pvoborni at redhat.com Tue May 12 15:58:57 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 12 May 2015 17:58:57 +0200 Subject: [Freeipa-devel] [PATCH] 829 webui: option to not create user private group Message-ID: <55522341.7090601@redhat.com> Web UI was not able to create a user without a private group. New field added to user adder dialog to allow that. https://fedorahosted.org/freeipa/ticket/4986 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0829-webui-option-to-not-create-user-private-group.patch Type: text/x-patch Size: 2848 bytes Desc: not available URL: From mbasti at redhat.com Tue May 12 16:23:33 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 12 May 2015 18:23:33 +0200 Subject: [Freeipa-devel] [PATCH 0245] Fix uniqueness plugins vol. 2 Message-ID: <55522905.505@redhat.com> 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. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0245-Server-Upgrade-Fix-uniqueness-plugins.patch Type: text/x-patch Size: 6470 bytes Desc: not available URL: From abokovoy at redhat.com Tue May 12 16:47:12 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 12 May 2015 19:47:12 +0300 Subject: [Freeipa-devel] [PATCH 0031] provide a dedicated ccache file to httpd In-Reply-To: <5551DDBE.6080509@redhat.com> References: <554117FB.7070203@redhat.com> <5541B88A.4080506@redhat.com> <20150430062325.GG11785@redhat.com> <554732C2.3030707@redhat.com> <20150512055020.GH5152@redhat.com> <5551B442.3040605@redhat.com> <20150512092236.GL5152@redhat.com> <5551DDBE.6080509@redhat.com> Message-ID: <20150512164712.GP5152@redhat.com> On Tue, 12 May 2015, Petr Vobornik wrote: >On 05/12/2015 11:22 AM, Alexander Bokovoy wrote: >>On Tue, 12 May 2015, Martin Babinsky wrote: >>>>>%attr(644,root,root) %{_unitdir}/ipa-ods-exporter.service >>>>>+%attr(644,root,root) %{etc_systemd_dir}/httpd.service >>>>There is a minor issue: a lack of >>>> >>>>Requires: /etc/systemd/system >>>> >>>>which is needed because of /etc/systemd/system directory owned by a >>>>different package. We require systemd-units which is provided by systemd >>>>package as well so it is sort of mitigated by that but it would >>>>good to be explicit in the require. And yes, you can require the >>>>directory because systemd provides it: >>>> >>>>$ rpm -q --whatprovides /etc/systemd/system >>>>systemd-219-13.fc22.x86_64 >>>> >>>>Otherwise, ACK. >>>> >>>thank for review Alexander, attaching updated patch. >>ACK > >Pushed to master: 9a1a409d63e30dcb939b672d352fc4aa7ba690fe We also need a tmpfiles config changes because otherwise /var/run/httpd/krbcache does not exist. Patch attached. -- / Alexander Bokovoy -------------- next part -------------- From b13986cf0815c6e90d313fb8a4ab5f739901222a Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 12 May 2015 16:45:01 +0000 Subject: [PATCH] Make sure new httpd kerberos cache directory is created --- init/systemd/ipa.conf.tmpfiles | 1 + 1 file changed, 1 insertion(+) diff --git a/init/systemd/ipa.conf.tmpfiles b/init/systemd/ipa.conf.tmpfiles index b4503cc..276a1dc 100644 --- a/init/systemd/ipa.conf.tmpfiles +++ b/init/systemd/ipa.conf.tmpfiles @@ -1,3 +1,4 @@ d /var/run/ipa_memcached 0700 apache apache d /var/run/ipa 0700 root root d /var/run/httpd/clientcaches 0700 apache apache +d /var/run/httpd/krbcache 0700 apache apache -- 2.4.0 From mbasti at redhat.com Tue May 12 19:03:27 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 12 May 2015 21:03:27 +0200 Subject: [Freeipa-devel] [PATCH 0245] Fix uniqueness plugins vol. 2 In-Reply-To: <55522905.505@redhat.com> References: <55522905.505@redhat.com> Message-ID: <55524E7F.7050403@redhat.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0245.2-Server-Upgrade-Fix-uniqueness-plugins.patch Type: text/x-patch Size: 6474 bytes Desc: not available URL: From jcholast at redhat.com Wed May 13 08:06:04 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 13 May 2015 10:06:04 +0200 Subject: [Freeipa-devel] [PATCHES 0001-0005] Profile management commands In-Reply-To: <5548816D.6050304@redhat.com> References: <20150504133641.GQ16379@dhcp-40-8.bne.redhat.com> <55479FE1.1020005@redhat.com> <20150505062934.GU16379@dhcp-40-8.bne.redhat.com> <5548816D.6050304@redhat.com> Message-ID: <555305EC.5020001@redhat.com> 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. >>> 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. >>> Other issues: >>> 1) >>> I do not see modifications in API.txt file >>> >>> 2) >>> We use new shorter license header >>> # >>> # Copyright (C) 2015 FreeIPA Contributors see COPYING for license >>> # >>> >>> 3) >>> +from ipalib.plugins.baseldap import \ >>> + LDAPObject, LDAPSearch, LDAPCreate, LDAPDelete, LDAPUpdate, >>> LDAPRetrieve >>> >>> please use 'import ( modules, .. )' instead of '\' >>> >>> 4) >>> + if method == 'POST' \ >>> + and 'content-type' not in (str(k).lower() for k in >>> headers.viewkeys()): >>> >>> again, please use if ( ... ): instead \ >>> >>> 5) >>> +import ipalib.errors as errors >>> in dogtag.py >>> >>> Can you use from ipalib import errors, instead? >>> >>> 6) >>> + def __exit__(self, exc_type, exc_value, traceback): >>> + """Log out of the REST API""" >>> + # TODO logout >>> + self.cookie = None >>> >>> This is forgotten, or will be this fixed later? >>> >>> 7) >>> + if not explanation: print resp_body # NOCOMMIT >>> >> These are all fixed for the next patchset. >> >> Thanks! >> Fraser >> 8) You can do: Str('cn', primary_key=True, cli_name='id', label=_('Profile ID'), doc=_('Profile ID for referring to this profile'), pattern='^[a-zA-Z]\w*$', pattern_errmsg=_('invalid Profile ID'), ), instead of: profile_id_pattern = re.compile('^[a-zA-Z]\w*$') def validate_profile_id(ugettext, value): """Ensure profile ID matches form required by CA.""" if profile_id_pattern.match(value) is None: return _('invalid Profile ID') else: return None ... Str('cn', validate_profile_id, primary_key=True, cli_name='id', label=_('Profile ID'), doc=_('Profile ID for referring to this profile'), ), 9) Please don't invent new attributes (ipaCertProfileSummary) when you can use existing ones (description). 10) All the commands should call ipalib.plugins.cert.ca_enabled_check(). 11) I think the File parameter of certprofile_import should be called just 'file'. 12) IMO the profile backend should be merged in to the ra backend. I don't see a need to have these two separate. Honza -- Jan Cholasta From mbasti at redhat.com Wed May 13 08:36:51 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 13 May 2015 10:36:51 +0200 Subject: [Freeipa-devel] [PATCHES 0001-0005] Profile management commands In-Reply-To: <555305EC.5020001@redhat.com> References: <20150504133641.GQ16379@dhcp-40-8.bne.redhat.com> <55479FE1.1020005@redhat.com> <20150505062934.GU16379@dhcp-40-8.bne.redhat.com> <5548816D.6050304@redhat.com> <555305EC.5020001@redhat.com> Message-ID: <55530D23.5040702@redhat.com> 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. > >>>> 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. Martin^2 > >>>> Other issues: >>>> 1) >>>> I do not see modifications in API.txt file >>>> >>>> 2) >>>> We use new shorter license header >>>> # >>>> # Copyright (C) 2015 FreeIPA Contributors see COPYING for license >>>> # >>>> >>>> 3) >>>> +from ipalib.plugins.baseldap import \ >>>> + LDAPObject, LDAPSearch, LDAPCreate, LDAPDelete, LDAPUpdate, >>>> LDAPRetrieve >>>> >>>> please use 'import ( modules, .. )' instead of '\' >>>> >>>> 4) >>>> + if method == 'POST' \ >>>> + and 'content-type' not in (str(k).lower() for k in >>>> headers.viewkeys()): >>>> >>>> again, please use if ( ... ): instead \ >>>> >>>> 5) >>>> +import ipalib.errors as errors >>>> in dogtag.py >>>> >>>> Can you use from ipalib import errors, instead? >>>> >>>> 6) >>>> + def __exit__(self, exc_type, exc_value, traceback): >>>> + """Log out of the REST API""" >>>> + # TODO logout >>>> + self.cookie = None >>>> >>>> This is forgotten, or will be this fixed later? >>>> >>>> 7) >>>> + if not explanation: print resp_body # NOCOMMIT >>>> >>> These are all fixed for the next patchset. >>> >>> Thanks! >>> Fraser >>> > > 8) You can do: > > Str('cn', > primary_key=True, > cli_name='id', > label=_('Profile ID'), > doc=_('Profile ID for referring to this profile'), > pattern='^[a-zA-Z]\w*$', > pattern_errmsg=_('invalid Profile ID'), > ), > > instead of: > > profile_id_pattern = re.compile('^[a-zA-Z]\w*$') > > def validate_profile_id(ugettext, value): > """Ensure profile ID matches form required by CA.""" > if profile_id_pattern.match(value) is None: > return _('invalid Profile ID') > else: > return None > > ... > > Str('cn', validate_profile_id, > primary_key=True, > cli_name='id', > label=_('Profile ID'), > doc=_('Profile ID for referring to this profile'), > ), > > 9) Please don't invent new attributes (ipaCertProfileSummary) when you > can use existing ones (description). > > > 10) All the commands should call ipalib.plugins.cert.ca_enabled_check(). > > > 11) I think the File parameter of certprofile_import should be called > just 'file'. > > > 12) IMO the profile backend should be merged in to the ra backend. I > don't see a need to have these two separate. > > > Honza > -- Martin Basti From jcholast at redhat.com Wed May 13 08:39:55 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 13 May 2015 10:39:55 +0200 Subject: [Freeipa-devel] [PATCHES 0001-0005] Profile management commands In-Reply-To: <55530D23.5040702@redhat.com> References: <20150504133641.GQ16379@dhcp-40-8.bne.redhat.com> <55479FE1.1020005@redhat.com> <20150505062934.GU16379@dhcp-40-8.bne.redhat.com> <5548816D.6050304@redhat.com> <555305EC.5020001@redhat.com> <55530D23.5040702@redhat.com> Message-ID: <55530DDB.9000101@redhat.com> 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. >> >>>>> 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. > > Martin^2 >> >>>>> Other issues: >>>>> 1) >>>>> I do not see modifications in API.txt file >>>>> >>>>> 2) >>>>> We use new shorter license header >>>>> # >>>>> # Copyright (C) 2015 FreeIPA Contributors see COPYING for license >>>>> # >>>>> >>>>> 3) >>>>> +from ipalib.plugins.baseldap import \ >>>>> + LDAPObject, LDAPSearch, LDAPCreate, LDAPDelete, LDAPUpdate, >>>>> LDAPRetrieve >>>>> >>>>> please use 'import ( modules, .. )' instead of '\' >>>>> >>>>> 4) >>>>> + if method == 'POST' \ >>>>> + and 'content-type' not in (str(k).lower() for k in >>>>> headers.viewkeys()): >>>>> >>>>> again, please use if ( ... ): instead \ >>>>> >>>>> 5) >>>>> +import ipalib.errors as errors >>>>> in dogtag.py >>>>> >>>>> Can you use from ipalib import errors, instead? >>>>> >>>>> 6) >>>>> + def __exit__(self, exc_type, exc_value, traceback): >>>>> + """Log out of the REST API""" >>>>> + # TODO logout >>>>> + self.cookie = None >>>>> >>>>> This is forgotten, or will be this fixed later? >>>>> >>>>> 7) >>>>> + if not explanation: print resp_body # NOCOMMIT >>>>> >>>> These are all fixed for the next patchset. >>>> >>>> Thanks! >>>> Fraser >>>> >> >> 8) You can do: >> >> Str('cn', >> primary_key=True, >> cli_name='id', >> label=_('Profile ID'), >> doc=_('Profile ID for referring to this profile'), >> pattern='^[a-zA-Z]\w*$', >> pattern_errmsg=_('invalid Profile ID'), >> ), >> >> instead of: >> >> profile_id_pattern = re.compile('^[a-zA-Z]\w*$') >> >> def validate_profile_id(ugettext, value): >> """Ensure profile ID matches form required by CA.""" >> if profile_id_pattern.match(value) is None: >> return _('invalid Profile ID') >> else: >> return None >> >> ... >> >> Str('cn', validate_profile_id, >> primary_key=True, >> cli_name='id', >> label=_('Profile ID'), >> doc=_('Profile ID for referring to this profile'), >> ), >> >> 9) Please don't invent new attributes (ipaCertProfileSummary) when you >> can use existing ones (description). >> >> >> 10) All the commands should call ipalib.plugins.cert.ca_enabled_check(). >> >> >> 11) I think the File parameter of certprofile_import should be called >> just 'file'. >> >> >> 12) IMO the profile backend should be merged in to the ra backend. I >> don't see a need to have these two separate. >> >> >> Honza >> > > -- Jan Cholasta From jcholast at redhat.com Wed May 13 09:09:37 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 13 May 2015 11:09:37 +0200 Subject: [Freeipa-devel] [PATCH] Password vault In-Reply-To: <5551DB57.6060504@redhat.com> References: <54E1AF55.3060409@redhat.com> <54EBEB55.6010306@redhat.com> <54F96B22.9050507@redhat.com> <55004D5D.6060300@redhat.com> <550FE5EB.1070606@redhat.com> <551E0AE1.8040500@redhat.com> <553498D1.1020901@redhat.com> <5551DB57.6060504@redhat.com> Message-ID: <555314D1.6070304@redhat.com> Dne 12.5.2015 v 12:52 Endi Sukma Dewata napsal(a): > Please take a look at the attached patch (#353-9). It obsoletes all > previous patches. See comments below. > > On 4/20/2015 1:12 AM, Jan Cholasta wrote: >>> I'm planning to merge the vault and vault container object and use the >>> vault type attribute to distinguish between the two. See more discussion >>> about that below. >> >> OK. > > The vault container plugin has been removed instead of merged (see > explanation below). Internally the vaults are still stored in built-in > containers in the DS, but there won't be an interface to manage them. > The following containers are available for use: private, shared, and > services, but they are flat, not hierarchical. To speed up the review, I have amended your patch with code and coding style fixes (attached), please review my changes. Question: Services in IPA are identified by Kerberos principal. Why are service vaults identified by hostname alone? -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Added-vault-plugin.patch Type: text/x-patch Size: 27177 bytes Desc: not available URL: From ftweedal at redhat.com Wed May 13 09:41:53 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 13 May 2015 19:41:53 +1000 Subject: [Freeipa-devel] [PATCHES 0001-0005] Profile management commands In-Reply-To: <555305EC.5020001@redhat.com> References: <20150504133641.GQ16379@dhcp-40-8.bne.redhat.com> <55479FE1.1020005@redhat.com> <20150505062934.GU16379@dhcp-40-8.bne.redhat.com> <5548816D.6050304@redhat.com> <555305EC.5020001@redhat.com> Message-ID: <20150513094152.GJ12806@dhcp-40-8.bne.redhat.com> Hi Jan, thanks for review. Comments inline. On Wed, May 13, 2015 at 10:06:04AM +0200, 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. > > >>>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. > > >>>Other issues: > >>>1) > >>>I do not see modifications in API.txt file > >>> > >>>2) > >>>We use new shorter license header > >>># > >>># Copyright (C) 2015 FreeIPA Contributors see COPYING for license > >>># > >>> > >>>3) > >>>+from ipalib.plugins.baseldap import \ > >>>+ LDAPObject, LDAPSearch, LDAPCreate, LDAPDelete, LDAPUpdate, > >>>LDAPRetrieve > >>> > >>>please use 'import ( modules, .. )' instead of '\' > >>> > >>>4) > >>>+ if method == 'POST' \ > >>>+ and 'content-type' not in (str(k).lower() for k in > >>>headers.viewkeys()): > >>> > >>>again, please use if ( ... ): instead \ > >>> > >>>5) > >>>+import ipalib.errors as errors > >>>in dogtag.py > >>> > >>>Can you use from ipalib import errors, instead? > >>> > >>>6) > >>>+ def __exit__(self, exc_type, exc_value, traceback): > >>>+ """Log out of the REST API""" > >>>+ # TODO logout > >>>+ self.cookie = None > >>> > >>>This is forgotten, or will be this fixed later? > >>> > >>>7) > >>>+ if not explanation: print resp_body # NOCOMMIT > >>> > >>These are all fixed for the next patchset. > >> > >>Thanks! > >>Fraser > >> > > 8) You can do: > > Str('cn', > primary_key=True, > cli_name='id', > label=_('Profile ID'), > doc=_('Profile ID for referring to this profile'), > pattern='^[a-zA-Z]\w*$', > pattern_errmsg=_('invalid Profile ID'), > ), > That is nice, I did not see this! > instead of: > > profile_id_pattern = re.compile('^[a-zA-Z]\w*$') > > def validate_profile_id(ugettext, value): > """Ensure profile ID matches form required by CA.""" > if profile_id_pattern.match(value) is None: > return _('invalid Profile ID') > else: > return None > > ... > > Str('cn', validate_profile_id, > primary_key=True, > cli_name='id', > label=_('Profile ID'), > doc=_('Profile ID for referring to this profile'), > ), > > 9) Please don't invent new attributes (ipaCertProfileSummary) when you can > use existing ones (description). > OK. > > 10) All the commands should call ipalib.plugins.cert.ca_enabled_check(). > OK. > > 11) I think the File parameter of certprofile_import should be called just > 'file'. > OK. > > 12) IMO the profile backend should be merged in to the ra backend. I don't > see a need to have these two separate. > I wasn't sure, so I wrote them separately. I don't mind to make it part of ra, but because the code is working and having it separate makes it slightly easier to work on while developing these features, I will do this refactor later. Thanks, Fraser > > Honza > > -- > Jan Cholasta From mbasti at redhat.com Wed May 13 10:07:51 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 13 May 2015 12:07:51 +0200 Subject: [Freeipa-devel] [PATCH] 0048 Remove unused enable() method from DogtagInstance. In-Reply-To: <55521438.8060503@redhat.com> References: <5551E99F.80003@redhat.com> <5551EF29.7000501@redhat.com> <55521438.8060503@redhat.com> Message-ID: <55532277.5010703@redhat.com> 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. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka+mbasti-0048.2-Do-not-store-state-if-CA-is-enabled.patch Type: text/x-patch Size: 2822 bytes Desc: not available URL: From mbabinsk at redhat.com Wed May 13 10:56:55 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 13 May 2015 12:56:55 +0200 Subject: [Freeipa-devel] [PATCH 0245] Fix uniqueness plugins vol. 2 In-Reply-To: <55524E7F.7050403@redhat.com> References: <55522905.505@redhat.com> <55524E7F.7050403@redhat.com> Message-ID: <55532DF7.20003@redhat.com> 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 -- Martin^3 Babinsky From mbasti at redhat.com Wed May 13 11:08:20 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 13 May 2015 13:08:20 +0200 Subject: [Freeipa-devel] [PATCH] 829 webui: option to not create user private group In-Reply-To: <55522341.7090601@redhat.com> References: <55522341.7090601@redhat.com> Message-ID: <555330A4.1060106@redhat.com> On 12/05/15 17:58, Petr Vobornik wrote: > Web UI was not able to create a user without a private group. > > New field added to user adder dialog to allow that. > > https://fedorahosted.org/freeipa/ticket/4986 > > ACK -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Wed May 13 11:19:49 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 13 May 2015 13:19:49 +0200 Subject: [Freeipa-devel] [PATCHES 0001-0005] Profile management commands In-Reply-To: <20150513094152.GJ12806@dhcp-40-8.bne.redhat.com> References: <20150504133641.GQ16379@dhcp-40-8.bne.redhat.com> <55479FE1.1020005@redhat.com> <20150505062934.GU16379@dhcp-40-8.bne.redhat.com> <5548816D.6050304@redhat.com> <555305EC.5020001@redhat.com> <20150513094152.GJ12806@dhcp-40-8.bne.redhat.com> Message-ID: <55533355.8000107@redhat.com> Dne 13.5.2015 v 11:41 Fraser Tweedale napsal(a): > Hi Jan, thanks for review. Comments inline. > > On Wed, May 13, 2015 at 10:06:04AM +0200, Jan Cholasta wrote: >> 12) IMO the profile backend should be merged in to the ra backend. I don't >> see a need to have these two separate. >> > I wasn't sure, so I wrote them separately. I don't mind to make it > part of ra, but because the code is working and having it separate > makes it slightly easier to work on while developing these features, > I will do this refactor later. OK. For now, can you at least rename it to something more descriptive, like ra_certprofile? -- Jan Cholasta From mbabinsk at redhat.com Wed May 13 11:28:44 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 13 May 2015 13:28:44 +0200 Subject: [Freeipa-devel] [PATCH 0031] provide a dedicated ccache file to httpd In-Reply-To: <20150512164712.GP5152@redhat.com> References: <554117FB.7070203@redhat.com> <5541B88A.4080506@redhat.com> <20150430062325.GG11785@redhat.com> <554732C2.3030707@redhat.com> <20150512055020.GH5152@redhat.com> <5551B442.3040605@redhat.com> <20150512092236.GL5152@redhat.com> <5551DDBE.6080509@redhat.com> <20150512164712.GP5152@redhat.com> Message-ID: <5553356C.5040401@redhat.com> On 05/12/2015 06:47 PM, Alexander Bokovoy wrote: > On Tue, 12 May 2015, Petr Vobornik wrote: >> On 05/12/2015 11:22 AM, Alexander Bokovoy wrote: >>> On Tue, 12 May 2015, Martin Babinsky wrote: >>>>>> %attr(644,root,root) %{_unitdir}/ipa-ods-exporter.service >>>>>> +%attr(644,root,root) %{etc_systemd_dir}/httpd.service >>>>> There is a minor issue: a lack of >>>>> >>>>> Requires: /etc/systemd/system >>>>> >>>>> which is needed because of /etc/systemd/system directory owned by a >>>>> different package. We require systemd-units which is provided by >>>>> systemd >>>>> package as well so it is sort of mitigated by that but it would >>>>> good to be explicit in the require. And yes, you can require the >>>>> directory because systemd provides it: >>>>> >>>>> $ rpm -q --whatprovides /etc/systemd/system >>>>> systemd-219-13.fc22.x86_64 >>>>> >>>>> Otherwise, ACK. >>>>> >>>> thank for review Alexander, attaching updated patch. >>> ACK >> >> Pushed to master: 9a1a409d63e30dcb939b672d352fc4aa7ba690fe > We also need a tmpfiles config changes because otherwise > /var/run/httpd/krbcache does not exist. > > Patch attached. > > ACK -- Martin^3 Babinsky From amessina at messinet.com Wed May 13 11:44:05 2015 From: amessina at messinet.com (Anthony Messina) Date: Wed, 13 May 2015 06:44:05 -0500 Subject: [Freeipa-devel] [PATCH 0031] provide a dedicated ccache file to httpd In-Reply-To: <5553356C.5040401@redhat.com> References: <554117FB.7070203@redhat.com> <20150512164712.GP5152@redhat.com> <5553356C.5040401@redhat.com> Message-ID: <5702598.vrmxWhKAdU@linux-ws1.messinet.com> On Wednesday, May 13, 2015 01:28:44 PM Martin Babinsky wrote: > On 05/12/2015 06:47 PM, Alexander Bokovoy wrote: > > On Tue, 12 May 2015, Petr Vobornik wrote: > >> On 05/12/2015 11:22 AM, Alexander Bokovoy wrote: > >>> On Tue, 12 May 2015, Martin Babinsky wrote: > >>>>>> %attr(644,root,root) %{_unitdir}/ipa-ods-exporter.service > >>>>>> +%attr(644,root,root) %{etc_systemd_dir}/httpd.service > >>>>> > >>>>> There is a minor issue: a lack of > >>>>> > >>>>> Requires: /etc/systemd/system > >>>>> > >>>>> which is needed because of /etc/systemd/system directory owned by a > >>>>> different package. We require systemd-units which is provided by > >>>>> systemd > >>>>> package as well so it is sort of mitigated by that but it would > >>>>> good to be explicit in the require. And yes, you can require the > >>>>> directory because systemd provides it: > >>>>> > >>>>> $ rpm -q --whatprovides /etc/systemd/system > >>>>> systemd-219-13.fc22.x86_64 > >>>>> > >>>>> Otherwise, ACK. > >>>> > >>>> thank for review Alexander, attaching updated patch. > >>> > >>> ACK > >> > >> Pushed to master: 9a1a409d63e30dcb939b672d352fc4aa7ba690fe > > > > We also need a tmpfiles config changes because otherwise > > /var/run/httpd/krbcache does not exist. > > > > Patch attached. > > ACK I'm not sure it matters, but mod_auth_kerb already sets up /var/run/httpd/krbcache via /lib/tmpfiles.d/httpd-krbcache.conf: d /var/run/httpd/krbcache 0700 apache apache -- Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From mbasti at redhat.com Wed May 13 11:46:07 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 13 May 2015 13:46:07 +0200 Subject: [Freeipa-devel] [PATCH 0246] Don't use proxy to check CA status during install/upgrade Message-ID: <5553397F.4010503@redhat.com> https://fedorahosted.org/freeipa/ticket/4994 Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0246-Dont-use-the-proxy-to-check-CA-status.patch Type: text/x-patch Size: 1947 bytes Desc: not available URL: From abokovoy at redhat.com Wed May 13 11:58:40 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 13 May 2015 14:58:40 +0300 Subject: [Freeipa-devel] [PATCH 0031] provide a dedicated ccache file to httpd In-Reply-To: <5702598.vrmxWhKAdU@linux-ws1.messinet.com> References: <554117FB.7070203@redhat.com> <20150512164712.GP5152@redhat.com> <5553356C.5040401@redhat.com> <5702598.vrmxWhKAdU@linux-ws1.messinet.com> Message-ID: <20150513115840.GR5152@redhat.com> On Wed, 13 May 2015, Anthony Messina wrote: >On Wednesday, May 13, 2015 01:28:44 PM Martin Babinsky wrote: >> On 05/12/2015 06:47 PM, Alexander Bokovoy wrote: >> > On Tue, 12 May 2015, Petr Vobornik wrote: >> >> On 05/12/2015 11:22 AM, Alexander Bokovoy wrote: >> >>> On Tue, 12 May 2015, Martin Babinsky wrote: >> >>>>>> %attr(644,root,root) %{_unitdir}/ipa-ods-exporter.service >> >>>>>> +%attr(644,root,root) %{etc_systemd_dir}/httpd.service >> >>>>> >> >>>>> There is a minor issue: a lack of >> >>>>> >> >>>>> Requires: /etc/systemd/system >> >>>>> >> >>>>> which is needed because of /etc/systemd/system directory owned by a >> >>>>> different package. We require systemd-units which is provided by >> >>>>> systemd >> >>>>> package as well so it is sort of mitigated by that but it would >> >>>>> good to be explicit in the require. And yes, you can require the >> >>>>> directory because systemd provides it: >> >>>>> >> >>>>> $ rpm -q --whatprovides /etc/systemd/system >> >>>>> systemd-219-13.fc22.x86_64 >> >>>>> >> >>>>> Otherwise, ACK. >> >>>> >> >>>> thank for review Alexander, attaching updated patch. >> >>> >> >>> ACK >> >> >> >> Pushed to master: 9a1a409d63e30dcb939b672d352fc4aa7ba690fe >> > >> > We also need a tmpfiles config changes because otherwise >> > /var/run/httpd/krbcache does not exist. >> > >> > Patch attached. >> >> ACK > >I'm not sure it matters, but mod_auth_kerb already sets up >/var/run/httpd/krbcache via /lib/tmpfiles.d/httpd-krbcache.conf: >d /var/run/httpd/krbcache 0700 apache apache We don't use mod_auth_kerb in Fedora 22 anymore, and mod_auth_gssapi doesn't bring the same configuration in, so installing git master will fail to operate due to missing directory. -- / Alexander Bokovoy From lryznaro at redhat.com Wed May 13 12:57:53 2015 From: lryznaro at redhat.com (Lenka Ryznarova) Date: Wed, 13 May 2015 14:57:53 +0200 Subject: [Freeipa-devel] [TEST PLAN] User lifecycle plugin Message-ID: <1431521873.3392.6.camel@dhcp130-146.brq.redhat.com> 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 From dkupka at redhat.com Wed May 13 13:22:21 2015 From: dkupka at redhat.com (David Kupka) Date: Wed, 13 May 2015 15:22:21 +0200 Subject: [Freeipa-devel] [PATCHES 0239-0243] Server Upgrade: minor fixes In-Reply-To: <5551F5B5.6010702@redhat.com> References: <5551F5B5.6010702@redhat.com> Message-ID: <5553500D.2080606@redhat.com> On 05/12/2015 02:44 PM, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/4904 > > Patches attached. > Works for me, ACK. -- David Kupka From dkupka at redhat.com Wed May 13 15:44:41 2015 From: dkupka at redhat.com (David Kupka) Date: Wed, 13 May 2015 17:44:41 +0200 Subject: [Freeipa-devel] [TEST PLAN] User lifecycle plugin In-Reply-To: <1431521873.3392.6.camel@dhcp130-146.brq.redhat.com> References: <1431521873.3392.6.camel@dhcp130-146.brq.redhat.com> Message-ID: <55537169.4000308@redhat.com> 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 " 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. -- David Kupka From mbasti at redhat.com Wed May 13 15:54:47 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 13 May 2015 17:54:47 +0200 Subject: [Freeipa-devel] [TEST PLAN] User lifecycle plugin In-Reply-To: <55537169.4000308@redhat.com> References: <1431521873.3392.6.camel@dhcp130-146.brq.redhat.com> <55537169.4000308@redhat.com> Message-ID: <555373C7.2070007@redhat.com> 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 > " 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. -- Martin Basti From amessina at messinet.com Wed May 13 22:31:03 2015 From: amessina at messinet.com (Anthony Messina) Date: Wed, 13 May 2015 17:31:03 -0500 Subject: [Freeipa-devel] [PATCH 0031] provide a dedicated ccache file to httpd In-Reply-To: <20150513115840.GR5152@redhat.com> References: <554117FB.7070203@redhat.com> <5702598.vrmxWhKAdU@linux-ws1.messinet.com> <20150513115840.GR5152@redhat.com> Message-ID: <2477302.rMD8Q48xWP@linux-ws1.messinet.com> On Wednesday, May 13, 2015 02:58:40 PM Alexander Bokovoy wrote: > On Wed, 13 May 2015, Anthony Messina wrote: > >On Wednesday, May 13, 2015 01:28:44 PM Martin Babinsky wrote: > >> On 05/12/2015 06:47 PM, Alexander Bokovoy wrote: > >> > On Tue, 12 May 2015, Petr Vobornik wrote: > >> >> On 05/12/2015 11:22 AM, Alexander Bokovoy wrote: > >> >>> On Tue, 12 May 2015, Martin Babinsky wrote: > >> >>>>>> %attr(644,root,root) %{_unitdir}/ipa-ods-exporter.service > >> >>>>>> +%attr(644,root,root) %{etc_systemd_dir}/httpd.service > >> >>>>> > >> >>>>> There is a minor issue: a lack of > >> >>>>> > >> >>>>> Requires: /etc/systemd/system > >> >>>>> > >> >>>>> which is needed because of /etc/systemd/system directory owned by a > >> >>>>> different package. We require systemd-units which is provided by > >> >>>>> systemd > >> >>>>> package as well so it is sort of mitigated by that but it would > >> >>>>> good to be explicit in the require. And yes, you can require the > >> >>>>> directory because systemd provides it: > >> >>>>> > >> >>>>> $ rpm -q --whatprovides /etc/systemd/system > >> >>>>> systemd-219-13.fc22.x86_64 > >> >>>>> > >> >>>>> Otherwise, ACK. > >> >>>> > >> >>>> thank for review Alexander, attaching updated patch. > >> >>> > >> >>> ACK > >> >> > >> >> Pushed to master: 9a1a409d63e30dcb939b672d352fc4aa7ba690fe > >> > > >> > We also need a tmpfiles config changes because otherwise > >> > /var/run/httpd/krbcache does not exist. > >> > > >> > Patch attached. > >> > >> ACK > > > >I'm not sure it matters, but mod_auth_kerb already sets up > >/var/run/httpd/krbcache via /lib/tmpfiles.d/httpd-krbcache.conf: > >d /var/run/httpd/krbcache 0700 apache apache > > We don't use mod_auth_kerb in Fedora 22 anymore, and mod_auth_gssapi > doesn't bring the same configuration in, so installing git master will > fail to operate due to missing directory. True, though mod_auth_gssapi has (at least for this user) uses beyond FreeIPA. Perhaps Simo would be willing to include the tmpfiles.d snippet in the "upstream" mod_auth_gssapi RPMs. -A -- Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From ftweedal at redhat.com Thu May 14 01:58:40 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 14 May 2015 11:58:40 +1000 Subject: [Freeipa-devel] [PATCHES 0001-0005] Profile management commands In-Reply-To: <55533355.8000107@redhat.com> References: <20150504133641.GQ16379@dhcp-40-8.bne.redhat.com> <55479FE1.1020005@redhat.com> <20150505062934.GU16379@dhcp-40-8.bne.redhat.com> <5548816D.6050304@redhat.com> <555305EC.5020001@redhat.com> <20150513094152.GJ12806@dhcp-40-8.bne.redhat.com> <55533355.8000107@redhat.com> Message-ID: <20150514015840.GK12806@dhcp-40-8.bne.redhat.com> On Wed, May 13, 2015 at 01:19:49PM +0200, Jan Cholasta wrote: > Dne 13.5.2015 v 11:41 Fraser Tweedale napsal(a): > >Hi Jan, thanks for review. Comments inline. > > > >On Wed, May 13, 2015 at 10:06:04AM +0200, Jan Cholasta wrote: > >>12) IMO the profile backend should be merged in to the ra backend. I don't > >>see a need to have these two separate. > >> > >I wasn't sure, so I wrote them separately. I don't mind to make it > >part of ra, but because the code is working and having it separate > >makes it slightly easier to work on while developing these features, > >I will do this refactor later. > > OK. For now, can you at least rename it to something more descriptive, like > ra_certprofile? > No problem; updated name in next patchset. > -- > Jan Cholasta From edewata at redhat.com Thu May 14 03:01:41 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 13 May 2015 22:01:41 -0500 Subject: [Freeipa-devel] [PATCH] Password vault In-Reply-To: <555314D1.6070304@redhat.com> References: <54E1AF55.3060409@redhat.com> <54EBEB55.6010306@redhat.com> <54F96B22.9050507@redhat.com> <55004D5D.6060300@redhat.com> <550FE5EB.1070606@redhat.com> <551E0AE1.8040500@redhat.com> <553498D1.1020901@redhat.com> <5551DB57.6060504@redhat.com> <555314D1.6070304@redhat.com> Message-ID: <55541015.3040206@redhat.com> On 5/13/2015 4:09 AM, Jan Cholasta wrote: > Dne 12.5.2015 v 12:52 Endi Sukma Dewata napsal(a): >> Please take a look at the attached patch (#353-9). It obsoletes all >> previous patches. See comments below. >> >> On 4/20/2015 1:12 AM, Jan Cholasta wrote: >>>> I'm planning to merge the vault and vault container object and use the >>>> vault type attribute to distinguish between the two. See more >>>> discussion >>>> about that below. >>> >>> OK. >> >> The vault container plugin has been removed instead of merged (see >> explanation below). Internally the vaults are still stored in built-in >> containers in the DS, but there won't be an interface to manage them. >> The following containers are available for use: private, shared, and >> services, but they are flat, not hierarchical. > > To speed up the review, I have amended your patch with code and coding > style fixes (attached), please review my changes. > > 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: /@. The vault is stored in cn=, cn=, cn=services, cn=vaults, . 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 $ ipa vault-add --host Are there other service principal formats that we need to support? Do we need to support services of different realms? Some comments about your changes: 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, , so the rdn will become cn=vaults and container_dn will become . When combined with the subcontainer (private/shared/service) it will produce an invalid DN. 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 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 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=, cn=users, cn=vaults). The entry cn=, cn=, 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. 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) 6. The loop in create_container() is incorrect. Suppose we're creating a container cn=A, cn=B, and the parent container cn=B, 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. while dn.endswith(container_dn): entry = self.backend.make_entry( dn, objectclass=['nsContainer'], cn=[dn[0]['cn']], ) try: self.backend.add_entry(entry) except errors.DuplicateEntry: break dn = DN(*dn[1:]) 7. The host and shared parameters are no longer available in vault-show and vault-del commands. The unit tests are failing because of that. Why do these commands not automatically inherit all parameters from the class? -- Endi S. Dewata From abokovoy at redhat.com Thu May 14 05:12:28 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 14 May 2015 08:12:28 +0300 Subject: [Freeipa-devel] [PATCH 0031] provide a dedicated ccache file to httpd In-Reply-To: <2477302.rMD8Q48xWP@linux-ws1.messinet.com> References: <554117FB.7070203@redhat.com> <5702598.vrmxWhKAdU@linux-ws1.messinet.com> <20150513115840.GR5152@redhat.com> <2477302.rMD8Q48xWP@linux-ws1.messinet.com> Message-ID: <20150514051228.GU5152@redhat.com> On Wed, 13 May 2015, Anthony Messina wrote: >On Wednesday, May 13, 2015 02:58:40 PM Alexander Bokovoy wrote: >> On Wed, 13 May 2015, Anthony Messina wrote: >> >On Wednesday, May 13, 2015 01:28:44 PM Martin Babinsky wrote: >> >> On 05/12/2015 06:47 PM, Alexander Bokovoy wrote: >> >> > On Tue, 12 May 2015, Petr Vobornik wrote: >> >> >> On 05/12/2015 11:22 AM, Alexander Bokovoy wrote: >> >> >>> On Tue, 12 May 2015, Martin Babinsky wrote: >> >> >>>>>> %attr(644,root,root) %{_unitdir}/ipa-ods-exporter.service >> >> >>>>>> +%attr(644,root,root) %{etc_systemd_dir}/httpd.service >> >> >>>>> >> >> >>>>> There is a minor issue: a lack of >> >> >>>>> >> >> >>>>> Requires: /etc/systemd/system >> >> >>>>> >> >> >>>>> which is needed because of /etc/systemd/system directory owned by a >> >> >>>>> different package. We require systemd-units which is provided by >> >> >>>>> systemd >> >> >>>>> package as well so it is sort of mitigated by that but it would >> >> >>>>> good to be explicit in the require. And yes, you can require the >> >> >>>>> directory because systemd provides it: >> >> >>>>> >> >> >>>>> $ rpm -q --whatprovides /etc/systemd/system >> >> >>>>> systemd-219-13.fc22.x86_64 >> >> >>>>> >> >> >>>>> Otherwise, ACK. >> >> >>>> >> >> >>>> thank for review Alexander, attaching updated patch. >> >> >>> >> >> >>> ACK >> >> >> >> >> >> Pushed to master: 9a1a409d63e30dcb939b672d352fc4aa7ba690fe >> >> > >> >> > We also need a tmpfiles config changes because otherwise >> >> > /var/run/httpd/krbcache does not exist. >> >> > >> >> > Patch attached. >> >> >> >> ACK >> > >> >I'm not sure it matters, but mod_auth_kerb already sets up >> >/var/run/httpd/krbcache via /lib/tmpfiles.d/httpd-krbcache.conf: >> >d /var/run/httpd/krbcache 0700 apache apache >> >> We don't use mod_auth_kerb in Fedora 22 anymore, and mod_auth_gssapi >> doesn't bring the same configuration in, so installing git master will >> fail to operate due to missing directory. > >True, though mod_auth_gssapi has (at least for this user) uses beyond FreeIPA. >Perhaps Simo would be willing to include the tmpfiles.d snippet in the >"upstream" mod_auth_gssapi RPMs. -A This is configuration specific to FreeIPA httpd service unit -- a default httpd service unit in Fedora doesn't change Kerberos ccache path and therefore uses kernel keyring for it where any file system path is not required. -- / Alexander Bokovoy From tbabej at redhat.com Thu May 14 09:00:46 2015 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 14 May 2015 11:00:46 +0200 Subject: [Freeipa-devel] [PATCH 0325] Add Domain Level feature Message-ID: <5554643E.4030600@redhat.com> Hi, this patch implements the domain level feature. https://fedorahosted.org/freeipa/ticket/5018 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0325-Add-Domain-Level-feature.patch Type: text/x-patch Size: 15409 bytes Desc: not available URL: From jcholast at redhat.com Thu May 14 09:48:28 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 14 May 2015 11:48:28 +0200 Subject: [Freeipa-devel] [PATCH 0325] Add Domain Level feature In-Reply-To: <5554643E.4030600@redhat.com> References: <5554643E.4030600@redhat.com> Message-ID: <55546F6C.4060108@redhat.com> 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. 2) I though we agreed to call the command domainlevel-set instead of domainlevel-raise: . 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): domainlevel_output = ( output.Output('result', int) ) @register() class domainlevel-get(Command): has_output = domainlevel_output def execute(self, *args, **options): ldap = self.api.Backend.ldap2 dn = ... entry = ldap.get_entry(dn, ['ipaDomainLevel']) return {'result': entry.single_value['ipaDomainLevel']} @register() class domainlevel-set(Command): has_output = domainlevel_output takes_args = ( Int('value'), ) def execute(self, *args, **options): ldap = self.api.Backend.ldap2 value = args[0] ... validate value ... dn = ... entry = ldap.get_entry(dn, ['ipaDomainLevel']) entry.single_value['ipaDomainLevel'] = value ldap.update_entry(entry) return {'result': value} Honza -- Jan Cholasta From mbasti at redhat.com Thu May 14 13:16:15 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 14 May 2015 15:16:15 +0200 Subject: [Freeipa-devel] [PATCH 0247] Modularization of the DNS subsytem installer Message-ID: <5554A01F.5040506@redhat.com> Required for new installers. Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0247-DNS-install-extract-DNS-installer-into-one-module.patch Type: text/x-patch Size: 28002 bytes Desc: not available URL: From mkubik at redhat.com Thu May 14 13:19:49 2015 From: mkubik at redhat.com (Milan Kubik) Date: Thu, 14 May 2015 15:19:49 +0200 Subject: [Freeipa-devel] [QE] Place for test data Message-ID: <5554A0F5.3080204@redhat.com> Hi list, while drafting the test cases I have realized I don't know how to approach $SUBJ. Is there any agreed on place or 'best practices' for the data that is needed for the testing? What I need for the test is to have a text file/s and pass them as arguments to the command. It is not feasible to have the data with the test source code in one file. One possible scenario is: ./test_abc.py ./data/test_abc_xyz_1.txt ./data/test_abc_xyz_2.xml etc. (emphasis on directory) or a place dedicated for data of all of the tests such as: ipatests/test_xmlrpc/test_abc.py ipatests/data/some/path/to/data.txt or droping the data files along the test source. For me the first option looks more sane (less maintenance. separated from the code, though). A note from mkosek: mkosek at balmora [ ~/freeipa ]$ find -type d -name "data" ./install/ui/test/data ./ipatests/test_ipaserver/data OTOH, test_pkcs10 has its CSRs in the directory with the test, test_install is similar to pkcs10. Can I get your thoughts on this, please? Thanks, Milan From mbasti at redhat.com Thu May 14 15:09:14 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 14 May 2015 17:09:14 +0200 Subject: [Freeipa-devel] [PATCH 0248] DNSSEC: Fix: Do not recreate kasp.db if already exists Message-ID: <5554BA9A.8050202@redhat.com> https://fedorahosted.org/freeipa/ticket/4657 Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0248-DNSSEC-FIX-Do-not-re-create-kasp.db-if-already-exist.patch Type: text/x-patch Size: 995 bytes Desc: not available URL: From mbasti at redhat.com Thu May 14 15:23:23 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 14 May 2015 17:23:23 +0200 Subject: [Freeipa-devel] [PATCH 0249] DNSSEC: update kasp configuration template Message-ID: <5554BDEB.8070704@redhat.com> https://fedorahosted.org/freeipa/ticket/4657 Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0249-DNSSEC-update-opendnssec-kasp-configuration.patch Type: text/x-patch Size: 3163 bytes Desc: not available URL: From dkupka at redhat.com Thu May 14 15:41:35 2015 From: dkupka at redhat.com (David Kupka) Date: Thu, 14 May 2015 17:41:35 +0200 Subject: [Freeipa-devel] [PATCH] 0048 Remove unused enable() method from DogtagInstance. In-Reply-To: <55532277.5010703@redhat.com> References: <5551E99F.80003@redhat.com> <5551EF29.7000501@redhat.com> <55521438.8060503@redhat.com> <55532277.5010703@redhat.com> Message-ID: <5554C22F.5090307@redhat.com> 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. -- David Kupka From jcholast at redhat.com Thu May 14 18:42:54 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 14 May 2015 20:42:54 +0200 Subject: [Freeipa-devel] [PATCH] Password vault In-Reply-To: <55541015.3040206@redhat.com> References: <54E1AF55.3060409@redhat.com> <54EBEB55.6010306@redhat.com> <54F96B22.9050507@redhat.com> <55004D5D.6060300@redhat.com> <550FE5EB.1070606@redhat.com> <551E0AE1.8040500@redhat.com> <553498D1.1020901@redhat.com> <5551DB57.6060504@redhat.com> <555314D1.6070304@redhat.com> <55541015.3040206@redhat.com> Message-ID: <5554ECAE.8030908@redhat.com> Dne 14.5.2015 v 05:01 Endi Sukma Dewata napsal(a): > On 5/13/2015 4:09 AM, Jan Cholasta wrote: >> Dne 12.5.2015 v 12:52 Endi Sukma Dewata napsal(a): >>> Please take a look at the attached patch (#353-9). It obsoletes all >>> previous patches. See comments below. >>> >>> On 4/20/2015 1:12 AM, Jan Cholasta wrote: >>>>> I'm planning to merge the vault and vault container object and use the >>>>> vault type attribute to distinguish between the two. See more >>>>> discussion >>>>> about that below. >>>> >>>> OK. >>> >>> The vault container plugin has been removed instead of merged (see >>> explanation below). Internally the vaults are still stored in built-in >>> containers in the DS, but there won't be an interface to manage them. >>> The following containers are available for use: private, shared, and >>> services, but they are flat, not hierarchical. >> >> To speed up the review, I have amended your patch with code and coding >> style fixes (attached), please review my changes. >> >> 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: /@. > The vault is stored in cn=, cn=, cn=services, cn=vaults, > . 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 > $ ipa vault-add --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. > Do we > need to support services of different realms? That depends. Do we want to support vaults for users and services from AD trusts? > > Some comments about your changes: > > 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, , so the rdn will > become cn=vaults and container_dn will become . 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. > > 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. > > 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. > > 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=, > cn=users, cn=vaults). The entry cn=, cn=, 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? > > 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. > > 6. The loop in create_container() is incorrect. Suppose we're creating a > container cn=A, cn=B, and the parent container cn=B, > 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. > > while dn.endswith(container_dn): > entry = self.backend.make_entry( > dn, > objectclass=['nsContainer'], > cn=[dn[0]['cn']], > ) > > try: > self.backend.add_entry(entry) > except errors.DuplicateEntry: > break > > dn = DN(*dn[1:]) Right, fixed. > > 7. The host and shared parameters are no longer available in vault-show > and vault-del commands. The unit tests are failing because of that. Why > do these commands not automatically inherit all parameters from the class? > The parameters of Object plugins represent attributes of the object, so they are all provided in commands which allow setting values of the attributes (-add and -mod). Other commands need to only know which object to look up, so they provide only the primary key, which is supposed to uniquely identify the object. The issue with vaults is that they are in fact identified by (vault_name, host, shared) tuple, but the primary_key is just vault_name. Fixed by reverting to your original approach. Updated patch attached. Also attached is a modified patch, which implements hierarchical vault container objects. It is very hacky, but functional and self-contained. You can use it if you want. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Added-vault-plugin.patch Type: text/x-patch Size: 27426 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Added-vault-and-vaultcontainer-plugins.patch Type: text/x-patch Size: 35618 bytes Desc: not available URL: From edewata at redhat.com Fri May 15 00:17:14 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 14 May 2015 19:17:14 -0500 Subject: [Freeipa-devel] [PATCH] Password vault In-Reply-To: <5554ECAE.8030908@redhat.com> References: <54E1AF55.3060409@redhat.com> <54EBEB55.6010306@redhat.com> <54F96B22.9050507@redhat.com> <55004D5D.6060300@redhat.com> <550FE5EB.1070606@redhat.com> <551E0AE1.8040500@redhat.com> <553498D1.1020901@redhat.com> <5551DB57.6060504@redhat.com> <555314D1.6070304@redhat.com> <55541015.3040206@redhat.com> <5554ECAE.8030908@redhat.com> Message-ID: <55553B0A.10800@redhat.com> 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: /@. >> The vault is stored in cn=, cn=, cn=services, cn=vaults, >> . 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 >> $ ipa vault-add --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 / $ ipa vault-add SharedVault --shared $ ipa vault-add UsersVault --user $ ipa vault-add HostVault --host Basically we'll need a new parameter for each new container. For the initial implementation we only need the first 2 or 3. >> Do we >> need to support services of different realms? > > That depends. Do we want to support vaults for users and services from > AD trusts? It wasn't mentioned in the design doc either, but probably in the future we can support external vaults too: $ ipa vault-add ExternalVault --principal cn=vaults + cn=external + cn=/@ + cn= + cn= + cn=@ + cn= + cn= >> 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, , so the rdn will >> become cn=vaults and container_dn will become . 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. >> 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. >> 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. >> 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=, >> cn=users, cn=vaults). The entry cn=, cn=, 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. >> 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? The original code seems to be working fine with ipalib.api. 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? >> 6. The loop in create_container() is incorrect. Suppose we're creating a >> container cn=A, cn=B, and the parent container cn=B, >> 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. >> 7. The host and shared parameters are no longer available in vault-show >> and vault-del commands. The unit tests are failing because of that. Why >> do these commands not automatically inherit all parameters from the >> class? > > The parameters of Object plugins represent attributes of the object, so > they are all provided in commands which allow setting values of the > attributes (-add and -mod). Other commands need to only know which > object to look up, so they provide only the primary key, which is > supposed to uniquely identify the object. > > The issue with vaults is that they are in fact identified by > (vault_name, host, shared) tuple, but the primary_key is just > vault_name. Fixed by reverting to your original approach. OK. As discussed above, the vault may need to be identified by even more parameters, e.g. service, user, principal. > Updated patch attached. 8. There's a new PEP8 error: .../ipalib/plugins/vault.py:98:1: E302 expected 2 blank lines, found 1 9. The API.txt needs to be regenerated. > Also attached is a modified patch, which implements hierarchical vault > container objects. It is very hacky, but functional and self-contained. > You can use it if you want. Let's circle back to this after we get the essential vault functionality checked in. The latest plan was to merge vaultcontainer into vault. -- Endi S. Dewata From lkrispen at redhat.com Fri May 15 07:22:47 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 15 May 2015 09:22:47 +0200 Subject: [Freeipa-devel] [PATCH 0325] Add Domain Level feature In-Reply-To: <55546F6C.4060108@redhat.com> References: <5554643E.4030600@redhat.com> <55546F6C.4060108@redhat.com> Message-ID: <55559EC7.9080404@redhat.com> 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. yes, the design states that the domainlevel supported by a server should be stored in the cn=fqdn entry, but this is only informational, saying what level a server could handle and the selected level used has to be set and stored and the design doc says this has to be in: "Selected Domain level shall be stored in cn=DomainLevel,cn=etc,SUFFIX" Tomas, I don't see the handling of the global doamin level entry Ludwig > > > 2) I though we agreed to call the command domainlevel-set instead of > domainlevel-raise: > . > > > 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): > > domainlevel_output = ( > output.Output('result', int) > ) > > @register() > class domainlevel-get(Command): > has_output = domainlevel_output > > def execute(self, *args, **options): > ldap = self.api.Backend.ldap2 > > dn = ... > entry = ldap.get_entry(dn, ['ipaDomainLevel']) > > return {'result': entry.single_value['ipaDomainLevel']} > > @register() > class domainlevel-set(Command): > has_output = domainlevel_output > > takes_args = ( > Int('value'), > ) > > def execute(self, *args, **options): > ldap = self.api.Backend.ldap2 > > value = args[0] > ... validate value ... > > dn = ... > entry = ldap.get_entry(dn, ['ipaDomainLevel']) > entry.single_value['ipaDomainLevel'] = value > ldap.update_entry(entry) > > return {'result': value} > > > Honza > From lkrispen at redhat.com Fri May 15 08:17:30 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 15 May 2015 10:17:30 +0200 Subject: [Freeipa-devel] [PATCH 0325] Add Domain Level feature In-Reply-To: <55559EC7.9080404@redhat.com> References: <5554643E.4030600@redhat.com> <55546F6C.4060108@redhat.com> <55559EC7.9080404@redhat.com> Message-ID: <5555AB9A.4070000@redhat.com> On 05/15/2015 09:22 AM, Ludwig Krispenz wrote: > > 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. > yes, the design states that the domainlevel supported by a server > should be stored in the cn=fqdn entry, > > but this is only informational, saying what level a server could > handle and the selected level used has to be set and stored and the > design doc says this has to be in: > > "Selected Domain level shall be stored in cn=DomainLevel,cn=etc,SUFFIX" > > Tomas, > I don't see the handling of the global doamin level entry ok, it is there, you called it "cn= Domain Level" (with space), I used "cn=DomainLevel" - so wouldn't find it, we need to agree an a naming or a way to detect the entry I will probably change to search for "objectclass=ipaDomainLevelConfig" > > Ludwig >> >> >> 2) I though we agreed to call the command domainlevel-set instead of >> domainlevel-raise: >> . >> >> >> 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): >> >> domainlevel_output = ( >> output.Output('result', int) >> ) >> >> @register() >> class domainlevel-get(Command): >> has_output = domainlevel_output >> >> def execute(self, *args, **options): >> ldap = self.api.Backend.ldap2 >> >> dn = ... >> entry = ldap.get_entry(dn, ['ipaDomainLevel']) >> >> return {'result': entry.single_value['ipaDomainLevel']} >> >> @register() >> class domainlevel-set(Command): >> has_output = domainlevel_output >> >> takes_args = ( >> Int('value'), >> ) >> >> def execute(self, *args, **options): >> ldap = self.api.Backend.ldap2 >> >> value = args[0] >> ... validate value ... >> >> dn = ... >> entry = ldap.get_entry(dn, ['ipaDomainLevel']) >> entry.single_value['ipaDomainLevel'] = value >> ldap.update_entry(entry) >> >> return {'result': value} >> >> >> Honza >> > From ftweedal at redhat.com Fri May 15 08:24:20 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 15 May 2015 18:24:20 +1000 Subject: [Freeipa-devel] [PATCHES 0001-0007] Profile management In-Reply-To: <55530DDB.9000101@redhat.com> References: <20150504133641.GQ16379@dhcp-40-8.bne.redhat.com> <55479FE1.1020005@redhat.com> <20150505062934.GU16379@dhcp-40-8.bne.redhat.com> <5548816D.6050304@redhat.com> <555305EC.5020001@redhat.com> <55530D23.5040702@redhat.com> <55530DDB.9000101@redhat.com> Message-ID: <20150515082420.GR12806@dhcp-40-8.bne.redhat.com> 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. > >>>>>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. > > > >Martin^2 > >> > >>>>>Other issues: > >>>>>1) > >>>>>I do not see modifications in API.txt file > >>>>> > >>>>>2) > >>>>>We use new shorter license header > >>>>># > >>>>># Copyright (C) 2015 FreeIPA Contributors see COPYING for license > >>>>># > >>>>> > >>>>>3) > >>>>>+from ipalib.plugins.baseldap import \ > >>>>>+ LDAPObject, LDAPSearch, LDAPCreate, LDAPDelete, LDAPUpdate, > >>>>>LDAPRetrieve > >>>>> > >>>>>please use 'import ( modules, .. )' instead of '\' > >>>>> > >>>>>4) > >>>>>+ if method == 'POST' \ > >>>>>+ and 'content-type' not in (str(k).lower() for k in > >>>>>headers.viewkeys()): > >>>>> > >>>>>again, please use if ( ... ): instead \ > >>>>> > >>>>>5) > >>>>>+import ipalib.errors as errors > >>>>>in dogtag.py > >>>>> > >>>>>Can you use from ipalib import errors, instead? > >>>>> > >>>>>6) > >>>>>+ def __exit__(self, exc_type, exc_value, traceback): > >>>>>+ """Log out of the REST API""" > >>>>>+ # TODO logout > >>>>>+ self.cookie = None > >>>>> > >>>>>This is forgotten, or will be this fixed later? > >>>>> > >>>>>7) > >>>>>+ if not explanation: print resp_body # NOCOMMIT > >>>>> > >>>>These are all fixed for the next patchset. > >>>> > >>>>Thanks! > >>>>Fraser > >>>> > >> > >>8) You can do: > >> > >> Str('cn', > >> primary_key=True, > >> cli_name='id', > >> label=_('Profile ID'), > >> doc=_('Profile ID for referring to this profile'), > >> pattern='^[a-zA-Z]\w*$', > >> pattern_errmsg=_('invalid Profile ID'), > >> ), > >> > >>instead of: > >> > >> profile_id_pattern = re.compile('^[a-zA-Z]\w*$') > >> > >> def validate_profile_id(ugettext, value): > >> """Ensure profile ID matches form required by CA.""" > >> if profile_id_pattern.match(value) is None: > >> return _('invalid Profile ID') > >> else: > >> return None > >> > >> ... > >> > >> Str('cn', validate_profile_id, > >> primary_key=True, > >> cli_name='id', > >> label=_('Profile ID'), > >> doc=_('Profile ID for referring to this profile'), > >> ), > >> This is nice, but I have kept the separate method so that the cert-request command can use the same routine for validating the profile id (this will be in a subsequent patch). > >>9) Please don't invent new attributes (ipaCertProfileSummary) when you > >>can use existing ones (description). > >> > >> > >>10) All the commands should call ipalib.plugins.cert.ca_enabled_check(). > >> > >> > >>11) I think the File parameter of certprofile_import should be called > >>just 'file'. > >> 9, 10, 11 were addressed for this patchset. > >> > >>12) IMO the profile backend should be merged in to the ra backend. I > >>don't see a need to have these two separate. > >> > >> > >>Honza > >> > > > > > > > -- > Jan Cholasta -------------- next part -------------- >From 1b54e1572f4744aa0ce1b0bcb5c658a21e4b2fa7 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 20 Apr 2015 23:20:19 -0400 Subject: [PATCH 1/7] Install CA with LDAP profiles backend Install the Dogtag CA to use the LDAPProfileSubsystem instead of the default (file-based) ProfileSubsystem. Part of: https://fedorahosted.org/freeipa/ticket/4560 --- ipaserver/install/cainstance.py | 1 + 1 file changed, 1 insertion(+) diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index 8ccfd1a822fab557dc1b6bf6d0e7de3ef495efbb..7241494749480375b548c7fb8930b3f93d728e79 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -505,6 +505,7 @@ class CAInstance(DogtagInstance): config.set("CA", "pki_restart_configured_instance", "False") config.set("CA", "pki_backup_keys", "True") config.set("CA", "pki_backup_password", self.admin_password) + config.set("CA", "pki_profiles_in_ldap", "True") # Client security database config.set("CA", "pki_client_database_dir", self.agent_db) -- 2.1.0 -------------- next part -------------- >From c9dac576a9a73878286d09967bb54bbc0e3555a5 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Tue, 21 Apr 2015 02:24:10 -0400 Subject: [PATCH 2/7] Add schema for certificate profiles The certprofile object class is used to track IPA-managed certificate profiles in Dogtag and store IPA-specific settings. Part of: https://fedorahosted.org/freeipa/ticket/57 --- install/share/60certificate-profiles.ldif | 3 +++ install/share/Makefile.am | 1 + install/share/bootstrap-template.ldif | 6 ++++++ ipaserver/install/dsinstance.py | 1 + 4 files changed, 11 insertions(+) create mode 100644 install/share/60certificate-profiles.ldif diff --git a/install/share/60certificate-profiles.ldif b/install/share/60certificate-profiles.ldif new file mode 100644 index 0000000000000000000000000000000000000000..dcf4680589c98dad165141b1e13946c161a6abd7 --- /dev/null +++ b/install/share/60certificate-profiles.ldif @@ -0,0 +1,3 @@ +dn: cn=schema +attributeTypes: (2.16.840.1.113730.3.8.19.1.1 NAME 'ipaCertProfileStoreIssued' DESC 'Store certificates issued using this profile' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA v4.2' ) +objectClasses: (2.16.840.1.113730.3.8.19.2.1 NAME 'ipaCertProfile' SUP top STRUCTURAL MUST ( cn $ description $ ipaCertProfileStoreIssued ) X-ORIGIN 'IPA v4.2' ) diff --git a/install/share/Makefile.am b/install/share/Makefile.am index ca6128e2911ab5c0a773dd553f8e67eab944f120..2cae5279079cdd3e0d793667f4d1bf4e44757b9e 100644 --- a/install/share/Makefile.am +++ b/install/share/Makefile.am @@ -16,6 +16,7 @@ app_DATA = \ 60basev3.ldif \ 60ipadns.ldif \ 60ipapk11.ldif \ + 60certificate-profiles.ldif \ 61kerberos-ipav3.ldif \ 65ipacertstore.ldif \ 65ipasudo.ldif \ diff --git a/install/share/bootstrap-template.ldif b/install/share/bootstrap-template.ldif index 06b82aa4ae74e7766d0c09a63aa75fa222e7ab7d..1d74842ed544678dd080e34e1eef88983852f1d2 100644 --- a/install/share/bootstrap-template.ldif +++ b/install/share/bootstrap-template.ldif @@ -429,3 +429,9 @@ cn: ${REALM}_id_range ipaBaseID: $IDSTART ipaIDRangeSize: $IDRANGE_SIZE ipaRangeType: ipa-local + +dn: cn=certprofiles,cn=etc,$SUFFIX +changetype: add +objectClass: nsContainer +objectClass: top +cn: certprofiles diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py index 8a76e773f0a464529331d9e2e459c9cc5ea0522e..b562792f72e6821925911902fd49e0829e461559 100644 --- a/ipaserver/install/dsinstance.py +++ b/ipaserver/install/dsinstance.py @@ -55,6 +55,7 @@ IPA_SCHEMA_FILES = ("60kerberos.ldif", "60basev3.ldif", "60ipapk11.ldif", "60ipadns.ldif", + "60certificate-profiles.ldif", "61kerberos-ipav3.ldif", "65ipacertstore.ldif", "65ipasudo.ldif", -- 2.1.0 -------------- next part -------------- >From 1b3f4a3a030f2d71f3e2c3d69d70f7258c4f6a52 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Wed, 29 Apr 2015 06:07:58 -0400 Subject: [PATCH 3/7] ipa-pki-proxy: provide access to profiles REST API Part of: https://fedorahosted.org/freeipa/ticket/57 --- install/conf/ipa-pki-proxy.conf | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/install/conf/ipa-pki-proxy.conf b/install/conf/ipa-pki-proxy.conf index 5d21156848f3b5ddf14c42d92a26a30a9f94af36..366ca15a1868758547f9f1d3334fddba38793083 100644 --- a/install/conf/ipa-pki-proxy.conf +++ b/install/conf/ipa-pki-proxy.conf @@ -1,4 +1,4 @@ -# VERSION 5 - DO NOT REMOVE THIS LINE +# VERSION 6 - DO NOT REMOVE THIS LINE ProxyRequests Off @@ -11,7 +11,7 @@ ProxyRequests Off # matches for admin port and installer - + NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate NSSVerifyClient none ProxyPassMatch ajp://localhost:$DOGTAG_PORT @@ -26,5 +26,13 @@ ProxyRequests Off ProxyPassReverse ajp://localhost:$DOGTAG_PORT +# matches for REST API + + NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate + NSSVerifyClient require + ProxyPassMatch ajp://localhost:$DOGTAG_PORT + ProxyPassReverse ajp://localhost:$DOGTAG_PORT + + # Only enable this on servers that are not generating a CRL ${CLONE}RewriteRule ^/ipa/crl/MasterCRL.bin https://$FQDN/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL [L,R=301,NC] -- 2.1.0 -------------- next part -------------- >From fb2b7ef098b34dff4abec8f50b44c8f9cebd8812 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Thu, 30 Apr 2015 23:50:41 -0400 Subject: [PATCH 4/7] Add ACL to allow CA agent to modify profiles Part of: https://fedorahosted.org/freeipa/ticket/57 --- install/tools/ipa-upgradeconfig | 33 +++++++++++++++++++++++++++++++++ ipaserver/install/cainstance.py | 14 ++++++++++++++ 2 files changed, 47 insertions(+) diff --git a/install/tools/ipa-upgradeconfig b/install/tools/ipa-upgradeconfig index 8159ce244b873962df36409b884bc3ee70621f2f..d439e5336e16a2e79c8cf2e957f019a1ffc0ce4b 100755 --- a/install/tools/ipa-upgradeconfig +++ b/install/tools/ipa-upgradeconfig @@ -31,6 +31,7 @@ import pwd import fileinput import ConfigParser import grp +import ldap from ipalib import api import SSSDConfig @@ -40,6 +41,7 @@ from ipaplatform import services from ipaplatform.tasks import tasks from ipapython import ipautil, sysrestore, version, certdb from ipapython.config import IPAOptionParser +from ipapython.dn import DN from ipapython.ipa_log_manager import * from ipapython import certmonger from ipapython import dogtag @@ -322,6 +324,36 @@ def setup_firefox_extension(fstore): http.setup_firefox_extension(realm, domain) +def ca_configure_profiles_acl(ca): + root_logger.info('[Authorizing RA Agent to modify profiles]') + + if not ca.is_configured(): + root_logger.info('CA is not configured') + return False + + upgrade_state_args = ('dogtag', 'agent_allow_profile_modify') + if sysupgrade.get_upgrade_state(*upgrade_state_args): + return False + + if not api.Backend.ldap2.isconnected(): + try: + api.Backend.ldap2.connect(autobind=True) + except ipalib.errors.PublicError, e: + root_logger.error("Cannot connect to LDAP: %s", e) + return + + dn = DN(('cn', 'aclResources'), ('o', 'ipaca')) + modlist = [(ldap.MOD_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' + ])] + api.Backend.ldap2.conn.modify_s(str(dn), modlist) + + sysupgrade.set_upgrade_state(*upgrade_state_args + (True,)) + return True + + def upgrade_ipa_profile(ca, domain, fqdn): """ Update the IPA Profile provided by dogtag @@ -1420,6 +1452,7 @@ def main(): upgrade_ipa_profile(ca, api.env.domain, fqdn), certificate_renewal_update(ca), ca_enable_pkix(ca), + ca_configure_profiles_acl(ca), ]) if ca_restart: diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index 7241494749480375b548c7fb8930b3f93d728e79..81fd8a47d3cebe0659d5b3158928f578c0a75059 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -471,6 +471,7 @@ class CAInstance(DogtagInstance): self.step("requesting RA certificate from CA", self.__request_ra_certificate) self.step("issuing RA agent certificate", self.__issue_ra_cert) self.step("adding RA agent as a trusted user", self.__configure_ra) + self.step("authorizing RA to modify profiles", self.__configure_profiles_acl) self.step("configure certmonger for renewals", self.configure_certmonger_renewal) self.step("configure certificate renewals", self.configure_renewal) if not self.clone: @@ -942,6 +943,19 @@ class CAInstance(DogtagInstance): conn.unbind() + def __configure_profiles_acl(self): + """Allow the Certificate Manager Agents group to modify profiles.""" + dn = DN(('cn', 'aclResources'), self.basedn) + modlist = [(ldap.MOD_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' + ])] + conn = ipaldap.IPAdmin(self.fqdn, self.ds_port) + conn.do_simple_bind(DN(('cn', 'Directory Manager')), self.dm_password) + conn.modify_s(dn, modlist) + conn.unbind() + def __run_certutil(self, args, database=None, pwd_file=None, stdin=None): if not database: database = self.ra_agent_db -- 2.1.0 -------------- next part -------------- >From bc8fb17fa5e76e0d15d740764e26752f7eab644f Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Thu, 30 Apr 2015 04:55:29 -0400 Subject: [PATCH 5/7] Add certprofile plugin Add the 'certprofile' plugin which defines the commands for managing certificate profiles and associated permissions. Also update Dogtag network code in 'ipapython.dogtag' to support headers and arbitrary request bodies, to facilitate use of the Dogtag profiles REST API. Part of: https://fedorahosted.org/freeipa/ticket/57 --- ACI.txt | 8 ++ API.txt | 62 +++++++++ install/updates/40-certprofile.update | 4 + install/updates/40-delegation.update | 8 ++ install/updates/Makefile.am | 1 + ipalib/constants.py | 1 + ipalib/plugins/certprofile.py | 253 ++++++++++++++++++++++++++++++++++ ipapython/dogtag.py | 29 ++-- ipaserver/plugins/dogtag.py | 176 ++++++++++++++++++++++- 9 files changed, 529 insertions(+), 13 deletions(-) create mode 100644 install/updates/40-certprofile.update create mode 100644 ipalib/plugins/certprofile.py diff --git a/ACI.txt b/ACI.txt index 933b57cb93e833981867953b516a67484f13dca3..9fa283afff80135280a884923d70404924cf8fa9 100644 --- a/ACI.txt +++ b/ACI.txt @@ -22,6 +22,14 @@ dn: cn=automount,dc=ipa,dc=example aci: (targetattr = "automountmapname || description")(targetfilter = "(objectclass=automountmap)")(version 3.0;acl "permission:System: Modify Automount Maps";allow (write) groupdn = "ldap:///cn=System: Modify Automount Maps,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: cn=automount,dc=ipa,dc=example aci: (targetfilter = "(objectclass=automountmap)")(version 3.0;acl "permission:System: Remove Automount Maps";allow (delete) groupdn = "ldap:///cn=System: Remove Automount Maps,cn=permissions,cn=pbac,dc=ipa,dc=example";) +dn: cn=certprofiles,cn=etc,dc=ipa,dc=example +aci: (targetfilter = "(objectclass=ipacertprofile)")(version 3.0;acl "permission:System: Delete Certificate Profile";allow (delete) groupdn = "ldap:///cn=System: Delete Certificate Profile,cn=permissions,cn=pbac,dc=ipa,dc=example";) +dn: cn=certprofiles,cn=etc,dc=ipa,dc=example +aci: (targetfilter = "(objectclass=ipacertprofile)")(version 3.0;acl "permission:System: Import Certificate Profile";allow (add) groupdn = "ldap:///cn=System: Import Certificate Profile,cn=permissions,cn=pbac,dc=ipa,dc=example";) +dn: cn=certprofiles,cn=etc,dc=ipa,dc=example +aci: (targetattr = "cn || description || ipacertprofilestoreissued")(targetfilter = "(objectclass=ipacertprofile)")(version 3.0;acl "permission:System: Modify Certificate Profile";allow (write) groupdn = "ldap:///cn=System: Modify Certificate Profile,cn=permissions,cn=pbac,dc=ipa,dc=example";) +dn: cn=certprofiles,cn=etc,dc=ipa,dc=example +aci: (targetattr = "cn || createtimestamp || description || entryusn || ipacertprofilestoreissued || modifytimestamp || objectclass")(targetfilter = "(objectclass=ipacertprofile)")(version 3.0;acl "permission:System: Read Certificate Profiles";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=ipaconfig,cn=etc,dc=ipa,dc=example aci: (targetattr = "cn || createtimestamp || entryusn || ipacertificatesubjectbase || ipaconfigstring || ipacustomfields || ipadefaultemaildomain || ipadefaultloginshell || ipadefaultprimarygroup || ipagroupobjectclasses || ipagroupsearchfields || ipahomesrootdir || ipakrbauthzdata || ipamaxusernamelength || ipamigrationenabled || ipapwdexpadvnotify || ipasearchrecordslimit || ipasearchtimelimit || ipaselinuxusermapdefault || ipaselinuxusermaporder || ipauserauthtype || ipauserobjectclasses || ipausersearchfields || modifytimestamp || objectclass")(targetfilter = "(objectclass=ipaguiconfig)")(version 3.0;acl "permission:System: Read Global Configuration";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=costemplates,cn=accounts,dc=ipa,dc=example diff --git a/API.txt b/API.txt index f747765d7f9c87761fed0277cd59d1bc3fbd57e9..1efab43b48ca304a197d7ba5f0b01d44e7f500ff 100644 --- a/API.txt +++ b/API.txt @@ -509,6 +509,68 @@ args: 1,1,1 arg: Str('request_id') option: Str('version?', exclude='webui') output: Output('result', None, None) +command: certprofile_del +args: 1,2,3 +arg: Str('cn', attribute=True, cli_name='id', multivalue=True, 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', , None) +output: Output('summary', (, ), None) +output: ListOfPrimaryKeys('value', None, None) +command: certprofile_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='id', multivalue=False, primary_key=True, query=True, required=False) +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, query=True, required=False) +option: Bool('ipacertprofilestoreissued', attribute=True, autofill=False, cli_name='store', default=True, multivalue=False, query=True, required=False) +option: Flag('pkey_only?', autofill=True, default=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Int('sizelimit?', autofill=False, minvalue=0) +option: Int('timelimit?', autofill=False, minvalue=0) +option: Str('version?', exclude='webui') +output: Output('count', , None) +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('truncated', , None) +command: certprofile_import +args: 1,6,3 +arg: Str('cn', attribute=True, cli_name='id', multivalue=False, primary_key=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=True) +option: File('file', cli_name='file') +option: Bool('ipacertprofilestoreissued', attribute=True, cli_name='store', default=True, multivalue=False, required=True) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: certprofile_mod +args: 1,10,3 +arg: Str('cn', attribute=True, cli_name='id', multivalue=False, primary_key=True, query=True, required=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('delattr*', cli_name='delattr', exclude='webui') +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) +option: Bool('ipacertprofilestoreissued', attribute=True, autofill=False, cli_name='store', default=True, multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('rename', cli_name='rename', multivalue=False, primary_key=True, required=False) +option: Flag('rights', autofill=True, default=False) +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: certprofile_show +args: 1,4,3 +arg: Str('cn', attribute=True, cli_name='id', multivalue=False, primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) command: compat_is_enabled args: 0,1,1 option: Str('version?', exclude='webui') diff --git a/install/updates/40-certprofile.update b/install/updates/40-certprofile.update new file mode 100644 index 0000000000000000000000000000000000000000..e6c25cdf3d90aae1d4c3ff031a1ed94f975a8a99 --- /dev/null +++ b/install/updates/40-certprofile.update @@ -0,0 +1,4 @@ +dn: cn=certprofiles,cn=etc,$SUFFIX +default: objectClass: nsContainer +default: objectClass: top +default: cn: certprofiles diff --git a/install/updates/40-delegation.update b/install/updates/40-delegation.update index 32af498190a23ddfd202a5cad75409f60a70d78b..fd474bcd12c935e1485959c5763d6773d31c8bd7 100644 --- a/install/updates/40-delegation.update +++ b/install/updates/40-delegation.update @@ -237,3 +237,11 @@ default:ipapermissiontype: SYSTEM dn: cn=config add:aci: '(version 3.0;acl "permission:Add Configuration Sub-Entries";allow (add) groupdn = "ldap:///cn=Add Configuration Sub-Entries,cn=permissions,cn=pbac,$SUFFIX";)' + +# CA Administrators +dn: cn=CA Administrator,cn=privileges,cn=pbac,$SUFFIX +default:objectClass: nestedgroup +default:objectClass: groupofnames +default:objectClass: top +default:cn: CA Administrator +default:description: CA Administrator diff --git a/install/updates/Makefile.am b/install/updates/Makefile.am index 0d63d9ea8d85f1add5f036e7a39f89543586d33b..cd44f08d4cd736ee19caf8ec1b8df604c9c2fa9d 100644 --- a/install/updates/Makefile.am +++ b/install/updates/Makefile.am @@ -32,6 +32,7 @@ app_DATA = \ 40-replication.update \ 40-dns.update \ 40-automember.update \ + 40-certprofile.update \ 40-otp.update \ 45-roles.update \ 50-7_bit_check.update \ diff --git a/ipalib/constants.py b/ipalib/constants.py index f1e14702ffdf5a3bd23a62b1fdd2ee3cd95d84f8..02ba78e4b024c32b602c74e123ce305fbf247b8f 100644 --- a/ipalib/constants.py +++ b/ipalib/constants.py @@ -116,6 +116,7 @@ DEFAULT_CONFIG = ( ('container_otp', DN(('cn', 'otp'))), ('container_radiusproxy', DN(('cn', 'radiusproxy'))), ('container_views', DN(('cn', 'views'), ('cn', 'accounts'))), + ('container_certprofile', DN(('cn', 'certprofiles'), ('cn', 'etc'))), # Ports, hosts, and URIs: ('xmlrpc_uri', 'http://localhost:8888/ipa/xml'), diff --git a/ipalib/plugins/certprofile.py b/ipalib/plugins/certprofile.py new file mode 100644 index 0000000000000000000000000000000000000000..a9918451baa2a264ada41ba4efc39f2bdbd11501 --- /dev/null +++ b/ipalib/plugins/certprofile.py @@ -0,0 +1,253 @@ +# +# Copyright (C) 2015 FreeIPA Contributors see COPYING for license +# + +import re + +from ipalib import api, Bool, File, Str +from ipalib import output +from ipalib.plugable import Registry +from ipalib.plugins.virtual import VirtualCommand +from ipalib.plugins.baseldap import ( + LDAPObject, LDAPSearch, LDAPCreate, + LDAPDelete, LDAPUpdate, LDAPRetrieve) +from ipalib import ngettext +from ipalib.text import _ + +from ipalib import errors + + +__doc__ = _(""" +Manage Certificate Profiles + +Certificate Profiles are used by Certificate Authority (CA) in the signing of +certificates to determine if a Certificate Signing Request (CSR) is acceptable, +and if so what features and extensions will be present on the certificate. + +The Certificate Profile format is the property-list format understood by the +Dogtag or Red Hat Certificate System CA. + +PROFILE ID SYNTAX: + +A Profile ID is a string without spaces or punctuation starting with a letter +and followed by a sequence of letters, digits or underscore ("_"). + +EXAMPLES: + + Import a profile that will not store issued certificates: + ipa certprofile-import ShortLivedUserCert \\ + --file UserCert.profile --summary "User Certificates" \\ + --store=false + + Delete a certificate profile: + ipa certprofile-del ShortLivedUserCert + + Show information about a profile: + ipa certprofile-show ShortLivedUserCert + + Search for profiles that do not store certificates: + ipa certprofile-find --store=false + +""") + + +register = Registry() + + +def ca_enabled_check(): + """Raise NotFound if CA is not enabled. + + This function is defined in multiple plugins to avoid circular imports + (cert depends on certprofile, so we cannot import cert here). + + """ + if not api.Command.ca_is_enabled()['result']: + raise errors.NotFound(reason=_('CA is not configured')) + + +profile_id_pattern = re.compile('^[a-zA-Z]\w*$') + + +def validate_profile_id(ugettext, value): + """Ensure profile ID matches form required by CA.""" + if profile_id_pattern.match(value) is None: + return _('invalid Profile ID') + else: + return None + + + at register() +class certprofile(LDAPObject): + """ + Certificate Profile object. + """ + container_dn = api.env.container_certprofile + object_name = _('Certificate Profile') + object_name_plural = _('Certificate Profiles') + object_class = ['ipacertprofile'] + default_attributes = [ + 'cn', 'description', 'ipacertprofilestoreissued' + ] + search_attributes = [ + 'cn', 'description', 'ipacertprofilestoreissued' + ] + rdn_is_primary_key = True + label = _('Certificate Profiles') + label_singular = _('Certificate Profile') + + takes_params = ( + Str('cn', validate_profile_id, + primary_key=True, + cli_name='id', + label=_('Profile ID'), + doc=_('Profile ID for referring to this profile'), + ), + Str('description', + required=True, + cli_name='desc', + label=_('Profile description'), + doc=_('Brief description of this profile'), + ), + Bool('ipacertprofilestoreissued', + default=True, + cli_name='store', + label=_('Store issued certificates'), + doc=_('Whether to store certs issued using this profile'), + ), + ) + + permission_filter_objectclasses = ['ipacertprofile'] + managed_permissions = { + 'System: Read Certificate Profiles': { + 'replaces_global_anonymous_aci': True, + 'ipapermbindruletype': 'all', + 'ipapermright': {'read', 'search', 'compare'}, + 'ipapermdefaultattr': { + 'cn', + 'description', + 'ipacertprofilestoreissued', + 'objectclass', + }, + }, + 'System: Import Certificate Profile': { + 'ipapermright': {'add'}, + 'replaces': [ + '(target = "ldap:///cn=*,cn=certprofiles,cn=etc,$SUFFIX")(version 3.0;acl "permission:Import Certificate Profile";allow (add) groupdn = "ldap:///cn=Import Certificate Profile,cn=permissions,cn=pbac,$SUFFIX";)', + ], + 'default_privileges': {'CA Administrator'}, + }, + 'System: Delete Certificate Profile': { + 'ipapermright': {'delete'}, + 'replaces': [ + '(target = "ldap:///cn=*,cn=certprofiles,cn=etc,$SUFFIX")(version 3.0;acl "permission:Delete Certificate Profile";allow (delete) groupdn = "ldap:///cn=Delete Certificate Profile,cn=permissions,cn=pbac,$SUFFIX";)', + ], + 'default_privileges': {'CA Administrator'}, + }, + 'System: Modify Certificate Profile': { + 'ipapermright': {'write'}, + 'ipapermdefaultattr': { + 'cn', + 'description', + 'ipacertprofilestoreissued', + }, + 'replaces': [ + '(targetattr = "cn || description || ipacertprofilestoreissued")(target = "ldap:///cn=*,cn=certprofiles,cn=etc,$SUFFIX")(version 3.0;acl "permission:Modify Certificate Profile";allow (write) groupdn = "ldap:///cn=Modify Certificate Profile,cn=permissions,cn=pbac,$SUFFIX";)', + ], + 'default_privileges': {'CA Administrator'}, + }, + } + + + + at register() +class certprofile_find(LDAPSearch): + __doc__ = _("Search for Certificate Profiles.") + msg_summary = ngettext( + '%(count)d profile matched', '%(count)d profiles matched', 0 + ) + + def execute(self, *args, **kwargs): + ca_enabled_check() + return super(certprofile_find, self).execute(self, *args, **kwargs) + + + at register() +class certprofile_show(LDAPRetrieve): + __doc__ = _("Display the properties of a Certificate Profile.") + + def execute(self, *args, **kwargs): + ca_enabled_check() + return super(certprofile_show, self).execute(self, *args, **kwargs) + + + at register() +class certprofile_import(LDAPCreate): + __doc__ = _("Import a Certificate Profile.") + msg_summary = _('Imported profile "%(value)s"') + takes_options = ( + File('file', + label=_('Filename'), + cli_name='file', + flags=('virtual_attribute',), + ), + ) + + PROFILE_ID_PATTERN = re.compile('^profileId=(\w+)', re.MULTILINE) + + def pre_callback(self, ldap, dn, entry, entry_attrs, *keys, **options): + ca_enabled_check() + + match = self.PROFILE_ID_PATTERN.search(options['file']) + if match is None: + raise errors.ValidationError(name='file', + error=_("Profile ID is not present in profile data")) + elif keys[0] != match.group(1): + raise errors.ValidationError(name='file', + error=_("Profile ID '%(cli_value)s' does not match profile data '%(file_value)s'") + % {'cli_value': keys[0], 'file_value': match.group(1)} + ) + return dn + + + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + """Import the profile into Dogtag and enable it. + + If the operation succeeds, update the LDAP entry to 'enabled'. + If the operation fails, remove the LDAP entry. + """ + try: + with self.api.Backend.ra_certprofile as profile_api: + profile_api.create_profile(options['file']) + profile_api.enable_profile(keys[0]) + except: + # something went wrong ; delete entry + ldap.delete_entry(dn) + raise + + return dn + + + at register() +class certprofile_del(LDAPDelete): + __doc__ = _("Delete a Certificate Profile.") + msg_summary = _('Deleted profile "%(value)s"') + + def execute(self, *args, **kwargs): + ca_enabled_check() + return super(certprofile_del, self).execute(self, *args, **kwargs) + + def post_callback(self, ldap, dn, *keys, **options): + with self.api.Backend.ra_certprofile as profile_api: + profile_api.disable_profile(keys[0]) + profile_api.delete_profile(keys[0]) + return dn + + + at register() +class certprofile_mod(LDAPUpdate): + __doc__ = _("Modify Certificate Profile configuration.") + msg_summary = _('Modified Certificate Profile "%(value)s') + + def execute(self, *args, **kwargs): + ca_enabled_check() + return super(certprofile_mod, self).execute(self, *args, **kwargs) diff --git a/ipapython/dogtag.py b/ipapython/dogtag.py index c74b8736a4b15f7bf081206b52b9876a8c4928af..11311cf7b55d7b84e9434a698dbfd60b0eb142a1 100644 --- a/ipapython/dogtag.py +++ b/ipapython/dogtag.py @@ -233,9 +233,12 @@ def ca_status(ca_host=None, use_proxy=True): return _parse_ca_status(body) -def https_request(host, port, url, secdir, password, nickname, **kw): +def https_request(host, port, url, secdir, password, nickname, + method='POST', headers=None, body=None, **kw): """ + :param method: HTTP request method (defalut: 'POST') :param url: The path (not complete URL!) to post to. + :param body: The request body (encodes kw if None) :param kw: Keyword arguments to encode into POST body. :return: (http_status, http_reason_phrase, http_headers, http_body) as (integer, unicode, dict, str) @@ -254,9 +257,11 @@ def https_request(host, port, url, secdir, password, nickname, **kw): nickname, password, nss.get_default_certdb()) return conn - body = urlencode(kw) + if body is None: + body = urlencode(kw) return _httplib_request( - 'https', host, port, url, connection_factory, body) + 'https', host, port, url, connection_factory, body, + method=method, headers=headers) def http_request(host, port, url, **kw): @@ -288,11 +293,13 @@ def unauthenticated_https_request(host, port, url, **kw): def _httplib_request( - protocol, host, port, path, connection_factory, request_body): + protocol, host, port, path, connection_factory, request_body, + method='POST', headers=None): """ :param request_body: Request body :param connection_factory: Connection class to use. Will be called with the host and port arguments. + :param method: HTTP request method (default: 'POST') Perform a HTTP(s) request. """ @@ -301,13 +308,17 @@ def _httplib_request( uri = '%s://%s%s' % (protocol, ipautil.format_netloc(host, port), path) root_logger.debug('request %r', uri) root_logger.debug('request body %r', request_body) + + headers = headers or {} + if ( + method == 'POST' + and 'content-type' not in (str(k).lower() for k in headers.viewkeys()) + ): + headers['content-type'] = 'application/x-www-form-urlencoded' + try: conn = connection_factory(host, port) - conn.request( - 'POST', uri, - body=request_body, - headers={'Content-type': 'application/x-www-form-urlencoded'}, - ) + conn.request(method, uri, body=request_body, headers=headers) res = conn.getresponse() http_status = res.status diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py index 52bdb0d4245594785e718c63242e27cee0e59322..9654123b16d8e417398d49bf1305fd41880bc3a7 100644 --- a/ipaserver/plugins/dogtag.py +++ b/ipaserver/plugins/dogtag.py @@ -4,8 +4,9 @@ # Jason Gerard DeRose # Rob Crittenden # John Dennis +# Fraser Tweedale # -# Copyright (C) 2014 Red Hat +# Copyright (C) 2014, 2015 Red Hat # see file 'COPYING' for use and warranty information # # This program is free software; you can redistribute it and/or modify @@ -238,17 +239,21 @@ digits and nothing else follows. ''' import datetime +import json from lxml import etree +import os import tempfile import time import urllib2 +import pki from pki.client import PKIConnection import pki.crypto as cryptoutil from pki.kra import KRAClient from ipalib import Backend from ipapython.dn import DN +import ipapython.cookie import ipapython.dogtag from ipapython import ipautil from ipaserver.install.certs import CertDB @@ -1262,13 +1267,12 @@ def select_any_master(ldap2, service='CA'): #------------------------------------------------------------------------------- -from ipalib import api, SkipPluginModule +from ipalib import api, errors, SkipPluginModule if api.env.ra_plugin != 'dogtag': # In this case, abort loading this plugin module... raise SkipPluginModule(reason='dogtag not selected as RA plugin') import os, random from ipaserver.plugins import rabase -from ipalib.errors import CertificateOperationError from ipalib.constants import TYPE_ERROR from ipalib.util import cachedproperty from ipapython import dogtag @@ -1318,7 +1322,7 @@ class ra(rabase.rabase): err_msg = u'%s (%s)' % (err_msg, detail) self.error('%s.%s(): %s', self.fullname, func_name, err_msg) - raise CertificateOperationError(error=err_msg) + raise errors.CertificateOperationError(error=err_msg) @cachedproperty def ca_host(self): @@ -1923,3 +1927,167 @@ class kra(Backend): return KRAClient(connection, crypto) api.register(kra) + + +class RestClient(Backend): + """Simple Dogtag REST client to be subclassed by other backends. + + This class is a context manager. Authenticated calls must be + executed in a ``with`` suite:: + + class ra_certprofile(RestClient): + path = 'profile' + ... + + api.register(ra_certprofile) + + with api.Backend.ra_certprofile as profile_api: + # REST client is now logged in + profile_api.create_profile(...) + + """ + path = None + + @staticmethod + def _parse_dogtag_error(body): + try: + return pki.PKIException.from_json(json.loads(body)) + except: + return None + + def __init__(self): + if api.env.in_tree: + self.sec_dir = api.env.dot_ipa + os.sep + 'alias' + self.pwd_file = self.sec_dir + os.sep + '.pwd' + else: + self.sec_dir = paths.HTTPD_ALIAS_DIR + self.pwd_file = paths.ALIAS_PWDFILE_TXT + self.noise_file = self.sec_dir + os.sep + '.noise' + self.ipa_key_size = "2048" + self.ipa_certificate_nickname = "ipaCert" + self.ca_certificate_nickname = "caCert" + try: + f = open(self.pwd_file, "r") + self.password = f.readline().strip() + f.close() + except IOError: + self.password = '' + super(RestClient, self).__init__() + + # session cookie + self.cookie = None + + @cachedproperty + def ca_host(self): + """ + :return: host + as str + + Select our CA host. + """ + ldap2 = self.api.Backend.ldap2 + if host_has_service(api.env.ca_host, ldap2, "CA"): + return api.env.ca_host + if api.env.host != api.env.ca_host: + if host_has_service(api.env.host, ldap2, "CA"): + return api.env.host + host = select_any_master(ldap2) + if host: + return host + else: + return api.env.ca_host + + def __enter__(self): + """Log into the REST API""" + if self.cookie is not None: + return + status, status_text, resp_headers, resp_body = dogtag.https_request( + self.ca_host, self.env.ca_agent_port, '/ca/rest/account/login', + self.sec_dir, self.password, self.ipa_certificate_nickname, + method='GET' + ) + cookies = ipapython.cookie.Cookie.parse(resp_headers.get('set-cookie', '')) + if status != 200 or len(cookies) == 0: + raise errors.RemoteRetrieveError(reason=_('Failed to authenticate to CA REST API')) + self.cookie = str(cookies[0]) + return self + + def __exit__(self, exc_type, exc_value, traceback): + """Log out of the REST API""" + dogtag.https_request( + self.ca_host, self.env.ca_agent_port, '/ca/rest/account/logout', + self.sec_dir, self.password, self.ipa_certificate_nickname, + method='GET' + ) + self.cookie = None + + def _ssldo(self, method, path, headers=None, body=None): + """ + :param url: The URL to post to. + :param kw: Keyword arguments to encode into POST body. + :return: (http_status, http_reason_phrase, http_headers, http_body) + as (integer, unicode, dict, str) + + Perform an HTTPS request + """ + if self.cookie is None: + raise errors.RemoteRetrieveError( + reason=_("REST API is not logged in.")) + + headers = headers or {} + headers['Cookie'] = self.cookie + + resource = os.path.join('/ca/rest', self.path, path) + + # perform main request + status, status_text, resp_headers, resp_body = dogtag.https_request( + self.ca_host, self.env.ca_agent_port, resource, + self.sec_dir, self.password, self.ipa_certificate_nickname, + method=method, headers=headers, body=body + ) + if status < 200 or status >= 300: + explanation = self._parse_dogtag_error(resp_body) or '' + raise errors.RemoteRetrieveError( + reason=_('Non-2xx response from CA REST API: %(status)d %(status_text)s. %(explanation)s') + % {'status': status, 'status_text': status_text, 'explanation': explanation} + ) + return (status, status_text, resp_headers, resp_body) + + +class ra_certprofile(RestClient): + """ + Profile management backend plugin. + """ + path = 'profiles' + + def create_profile(self, profile_data): + """ + Import the profile into Dogtag + """ + self._ssldo('POST', 'raw', + headers={ + 'Content-type': 'application/xml', + 'Accept': 'application/json', + }, + body=profile_data + ) + + def enable_profile(self, profile_id): + """ + Enable the profile in Dogtag + """ + self._ssldo('POST', profile_id + '?action=enable') + + def disable_profile(self, profile_id): + """ + Enable the profile in Dogtag + """ + self._ssldo('POST', profile_id + '?action=disable') + + def delete_profile(self, profile_id): + """ + Delete the profile from Dogtag + """ + self._ssldo('DELETE', profile_id, headers={'Accept': 'application/json'}) + +api.register(ra_certprofile) -- 2.1.0 -------------- next part -------------- >From 7b398804189db9d991443ba7d24db6aa04a8cf52 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 11 May 2015 23:38:41 -0400 Subject: [PATCH 6/7] Enable LDAP-based profiles in CA on upgrade Part of: https://fedorahosted.org/freeipa/ticket/4560 --- install/tools/ipa-upgradeconfig | 44 +++++++++++++++++++++++++++++++++++++---- 1 file changed, 40 insertions(+), 4 deletions(-) diff --git a/install/tools/ipa-upgradeconfig b/install/tools/ipa-upgradeconfig index d439e5336e16a2e79c8cf2e957f019a1ffc0ce4b..c6c602dc6b4582c24e4ca751ab2f91f8e683dffa 100755 --- a/install/tools/ipa-upgradeconfig +++ b/install/tools/ipa-upgradeconfig @@ -327,10 +327,6 @@ def setup_firefox_extension(fstore): def ca_configure_profiles_acl(ca): root_logger.info('[Authorizing RA Agent to modify profiles]') - if not ca.is_configured(): - root_logger.info('CA is not configured') - return False - upgrade_state_args = ('dogtag', 'agent_allow_profile_modify') if sysupgrade.get_upgrade_state(*upgrade_state_args): return False @@ -354,6 +350,45 @@ def ca_configure_profiles_acl(ca): return True +def ca_enable_ldap_profile_subsystem(ca): + root_logger.info('[Ensuring CA is using LDAPProfileSubsystem]') + if not ca.is_configured(): + root_logger.info('CA is not configured') + return False + + caconfig = dogtag.configured_constants() + + needs_update = False + directive = None + try: + for i in range(15): + directive = "subsystem.{}.class".format(i) + value = installutils.get_directive( + caconfig.CS_CFG_PATH, + directive, + separator='=') + if value == 'ProfileSubsystem': + needs_update = True + break + except OSError, e: + root_logger.error('Cannot read CA configuration file "%s": %s', + caconfig.CS_CFG_PATH, e) + return False + + if needs_update: + installutils.set_directive( + caconfig.CS_CFG_PATH, + directive, + 'LDAPProfileSubsystem', + quotes=False, + separator='=') + + # TODO import file-based profiles into Dogtag + # More code needed on Dogtag side for this. + + return needs_update + + def upgrade_ipa_profile(ca, domain, fqdn): """ Update the IPA Profile provided by dogtag @@ -1453,6 +1488,7 @@ def main(): certificate_renewal_update(ca), ca_enable_pkix(ca), ca_configure_profiles_acl(ca), + ca_enable_ldap_profile_subsystem(ca), ]) if ca_restart: -- 2.1.0 -------------- next part -------------- >From 57af38f582493ba72df40c668000580c7db6c48a Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 11 May 2015 21:17:48 -0400 Subject: [PATCH 7/7] Import included profiles during install or upgrade Add a default service profile template as part of FreeIPA and format and import it as part of installation or upgrade process. Also remove the code that modifies the old (file-based) `caIPAserviceCert' profile. Fixes https://fedorahosted.org/freeipa/ticket/4002 --- freeipa.spec.in | 2 + install/configure.ac | 1 + install/share/Makefile.am | 1 + install/share/profiles/DefaultService.cfg | 109 +++++++++++++++ install/share/profiles/Makefile.am | 14 ++ install/tools/ipa-server-install | 16 ++- install/tools/ipa-upgradeconfig | 49 ++++--- ipapython/dogtag.py | 5 + ipaserver/install/cainstance.py | 216 ++++-------------------------- ipaserver/plugins/dogtag.py | 14 +- 10 files changed, 207 insertions(+), 220 deletions(-) create mode 100644 install/share/profiles/DefaultService.cfg create mode 100644 install/share/profiles/Makefile.am diff --git a/freeipa.spec.in b/freeipa.spec.in index 608242b5adbc43efbbf0ae30a6d7a933bebc1084..2ebd0072389c51d23717edc678d69b4ef895d874 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -709,6 +709,8 @@ fi %dir %{_usr}/share/ipa/advise %dir %{_usr}/share/ipa/advise/legacy %{_usr}/share/ipa/advise/legacy/*.template +%dir %{_usr}/share/ipa/profiles +%{_usr}/share/ipa/profiles/*.cfg %dir %{_usr}/share/ipa/ffextension %{_usr}/share/ipa/ffextension/bootstrap.js %{_usr}/share/ipa/ffextension/install.rdf diff --git a/install/configure.ac b/install/configure.ac index 2e48aa5cc67b30f2582de987a12d4e7043256679..57f4219b66bbe1dadaed3e89c3e84b1c8240399e 100644 --- a/install/configure.ac +++ b/install/configure.ac @@ -88,6 +88,7 @@ AC_CONFIG_FILES([ share/Makefile share/advise/Makefile share/advise/legacy/Makefile + share/profiles/Makefile ui/Makefile ui/css/Makefile ui/src/Makefile diff --git a/install/share/Makefile.am b/install/share/Makefile.am index 2cae5279079cdd3e0d793667f4d1bf4e44757b9e..1ff2278ebf395057fccc4f0650b7726374cc1cc8 100644 --- a/install/share/Makefile.am +++ b/install/share/Makefile.am @@ -2,6 +2,7 @@ NULL = SUBDIRS = \ advise \ + profiles \ $(NULL) appdir = $(IPA_DATA_DIR) diff --git a/install/share/profiles/DefaultService.cfg b/install/share/profiles/DefaultService.cfg new file mode 100644 index 0000000000000000000000000000000000000000..d70fc9867d8af3f49dd6dfebcefdf772772bd100 --- /dev/null +++ b/install/share/profiles/DefaultService.cfg @@ -0,0 +1,109 @@ +profileId=DefaultService +classId=caEnrollImpl +desc=This certificate profile is for enrolling server certificates with IPA-RA agent authentication. +visible=false +enable=true +enableBy=admin +auth.instance_id=raCertAuth +name=IPA-RA Agent-Authenticated Server Certificate Enrollment +input.list=i1,i2 +input.i1.class_id=certReqInputImpl +input.i2.class_id=submitterInfoInputImpl +output.list=o1 +output.o1.class_id=certOutputImpl +policyset.list=serverCertSet +policyset.serverCertSet.list=1,2,3,4,5,6,7,8,9,10,11 +policyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl +policyset.serverCertSet.1.constraint.name=Subject Name Constraint +policyset.serverCertSet.1.constraint.params.pattern=CN=[^,]+,.+ +policyset.serverCertSet.1.constraint.params.accept=true +policyset.serverCertSet.1.default.class_id=subjectNameDefaultImpl +policyset.serverCertSet.1.default.name=Subject Name Default +policyset.serverCertSet.1.default.params.name=CN=$$request.req_subject_name.cn$$, $SUBJECT_DN_O +policyset.serverCertSet.2.constraint.class_id=validityConstraintImpl +policyset.serverCertSet.2.constraint.name=Validity Constraint +policyset.serverCertSet.2.constraint.params.range=740 +policyset.serverCertSet.2.constraint.params.notBeforeCheck=false +policyset.serverCertSet.2.constraint.params.notAfterCheck=false +policyset.serverCertSet.2.default.class_id=validityDefaultImpl +policyset.serverCertSet.2.default.name=Validity Default +policyset.serverCertSet.2.default.params.range=731 +policyset.serverCertSet.2.default.params.startTime=0 +policyset.serverCertSet.3.constraint.class_id=keyConstraintImpl +policyset.serverCertSet.3.constraint.name=Key Constraint +policyset.serverCertSet.3.constraint.params.keyType=RSA +policyset.serverCertSet.3.constraint.params.keyParameters=1024,2048,3072,4096 +policyset.serverCertSet.3.default.class_id=userKeyDefaultImpl +policyset.serverCertSet.3.default.name=Key Default +policyset.serverCertSet.4.constraint.class_id=noConstraintImpl +policyset.serverCertSet.4.constraint.name=No Constraint +policyset.serverCertSet.4.default.class_id=authorityKeyIdentifierExtDefaultImpl +policyset.serverCertSet.4.default.name=Authority Key Identifier Default +policyset.serverCertSet.5.constraint.class_id=noConstraintImpl +policyset.serverCertSet.5.constraint.name=No Constraint +policyset.serverCertSet.5.default.class_id=authInfoAccessExtDefaultImpl +policyset.serverCertSet.5.default.name=AIA Extension Default +policyset.serverCertSet.5.default.params.authInfoAccessADEnable_0=true +policyset.serverCertSet.5.default.params.authInfoAccessADLocationType_0=URIName +policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0=http://$IPA_CA_RECORD.$DOMAIN/ca/ocsp +policyset.serverCertSet.5.default.params.authInfoAccessADMethod_0=1.3.6.1.5.5.7.48.1 +policyset.serverCertSet.5.default.params.authInfoAccessCritical=false +policyset.serverCertSet.5.default.params.authInfoAccessNumADs=1 +policyset.serverCertSet.6.constraint.class_id=keyUsageExtConstraintImpl +policyset.serverCertSet.6.constraint.name=Key Usage Extension Constraint +policyset.serverCertSet.6.constraint.params.keyUsageCritical=true +policyset.serverCertSet.6.constraint.params.keyUsageDigitalSignature=true +policyset.serverCertSet.6.constraint.params.keyUsageNonRepudiation=true +policyset.serverCertSet.6.constraint.params.keyUsageDataEncipherment=true +policyset.serverCertSet.6.constraint.params.keyUsageKeyEncipherment=true +policyset.serverCertSet.6.constraint.params.keyUsageKeyAgreement=false +policyset.serverCertSet.6.constraint.params.keyUsageKeyCertSign=false +policyset.serverCertSet.6.constraint.params.keyUsageCrlSign=false +policyset.serverCertSet.6.constraint.params.keyUsageEncipherOnly=false +policyset.serverCertSet.6.constraint.params.keyUsageDecipherOnly=false +policyset.serverCertSet.6.default.class_id=keyUsageExtDefaultImpl +policyset.serverCertSet.6.default.name=Key Usage Default +policyset.serverCertSet.6.default.params.keyUsageCritical=true +policyset.serverCertSet.6.default.params.keyUsageDigitalSignature=true +policyset.serverCertSet.6.default.params.keyUsageNonRepudiation=true +policyset.serverCertSet.6.default.params.keyUsageDataEncipherment=true +policyset.serverCertSet.6.default.params.keyUsageKeyEncipherment=true +policyset.serverCertSet.6.default.params.keyUsageKeyAgreement=false +policyset.serverCertSet.6.default.params.keyUsageKeyCertSign=false +policyset.serverCertSet.6.default.params.keyUsageCrlSign=false +policyset.serverCertSet.6.default.params.keyUsageEncipherOnly=false +policyset.serverCertSet.6.default.params.keyUsageDecipherOnly=false +policyset.serverCertSet.7.constraint.class_id=noConstraintImpl +policyset.serverCertSet.7.constraint.name=No Constraint +policyset.serverCertSet.7.default.class_id=extendedKeyUsageExtDefaultImpl +policyset.serverCertSet.7.default.name=Extended Key Usage Extension Default +policyset.serverCertSet.7.default.params.exKeyUsageCritical=false +policyset.serverCertSet.7.default.params.exKeyUsageOIDs=1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 +policyset.serverCertSet.8.constraint.class_id=signingAlgConstraintImpl +policyset.serverCertSet.8.constraint.name=No Constraint +policyset.serverCertSet.8.constraint.params.signingAlgsAllowed=SHA1withRSA,SHA256withRSA,SHA512withRSA,MD5withRSA,MD2withRSA,SHA1withDSA,SHA1withEC,SHA256withEC,SHA384withEC,SHA512withEC +policyset.serverCertSet.8.default.class_id=signingAlgDefaultImpl +policyset.serverCertSet.8.default.name=Signing Alg +policyset.serverCertSet.8.default.params.signingAlg=- +policyset.serverCertSet.9.constraint.class_id=noConstraintImpl +policyset.serverCertSet.9.constraint.name=No Constraint +policyset.serverCertSet.9.default.class_id=crlDistributionPointsExtDefaultImpl +policyset.serverCertSet.9.default.name=CRL Distribution Points Extension Default +policyset.serverCertSet.9.default.params.crlDistPointsCritical=false +policyset.serverCertSet.9.default.params.crlDistPointsNum=1 +policyset.serverCertSet.9.default.params.crlDistPointsEnable_0=true +policyset.serverCertSet.9.default.params.crlDistPointsIssuerName_0=$CRL_ISSUER +policyset.serverCertSet.9.default.params.crlDistPointsIssuerType_0=DirectoryName +policyset.serverCertSet.9.default.params.crlDistPointsPointName_0=http://$IPA_CA_RECORD.$DOMAIN/ipa/crl/MasterCRL.bin +policyset.serverCertSet.9.default.params.crlDistPointsPointType_0=URIName +policyset.serverCertSet.9.default.params.crlDistPointsReasons_0= +policyset.serverCertSet.10.constraint.class_id=noConstraintImpl +policyset.serverCertSet.10.constraint.name=No Constraint +policyset.serverCertSet.10.default.class_id=subjectKeyIdentifierExtDefaultImpl +policyset.serverCertSet.10.default.name=Subject Key Identifier Extension Default +policyset.serverCertSet.10.default.params.critical=false +policyset.serverCertSet.11.constraint.class_id=noConstraintImpl +policyset.serverCertSet.11.constraint.name=No Constraint +policyset.serverCertSet.11.default.class_id=userExtensionDefaultImpl +policyset.serverCertSet.11.default.name=User Supplied Extension Default +policyset.serverCertSet.11.default.params.userExtOID=2.5.29.17 diff --git a/install/share/profiles/Makefile.am b/install/share/profiles/Makefile.am new file mode 100644 index 0000000000000000000000000000000000000000..8c6b3114a346b3d96d94e75ad330c5f0bbaf7322 --- /dev/null +++ b/install/share/profiles/Makefile.am @@ -0,0 +1,14 @@ +NULL = + +appdir = $(IPA_DATA_DIR)/profiles +app_DATA = \ + DefaultService.cfg \ + $(NULL) + +EXTRA_DIST = \ + $(app_DATA) \ + $(NULL) + +MAINTAINERCLEANFILES = \ + *~ \ + Makefile.in diff --git a/install/tools/ipa-server-install b/install/tools/ipa-server-install index 56a43770d95387762bce09634bd1056ba7f20576..cb2a2e531e45e5faeadaf808107ffe22e336e670 100755 --- a/install/tools/ipa-server-install +++ b/install/tools/ipa-server-install @@ -1151,6 +1151,9 @@ def main(): os.chmod(target_fname, 0644) api.bootstrap(**cfg) + if setup_ca: + # ensure profile backend is available + import ipaserver.plugins.dogtag api.finalize() if not options.unattended: @@ -1164,6 +1167,9 @@ def main(): % (host_name, system_hostname)) # configure /etc/sysconfig/network to contain the custom hostname tasks.backup_and_replace_hostname(fstore, sstore, host_name) + # update `api.env.ca_host` to correct hostname + # https://fedorahosted.org/freeipa/ticket/4936 + api.env.ca_host = host_name # Create DS user/group if it doesn't exist yet dsinstance.create_ds_user() @@ -1312,6 +1318,12 @@ def main(): service.print_msg("Restarting the certificate server") ca.restart(dogtag.configured_constants().PKI_INSTANCE_NAME) + service.print_msg("Importing certificate profiles") + api.Backend.ra_certprofile._read_password() + if not api.Backend.ldap2.isconnected(): + api.Backend.ldap2.connect(autobind=True) + ca.import_included_profiles() + # Create a BIND instance bind = bindinstance.BindInstance(fstore, dm_password) bind.setup(host_name, ip_addresses, realm_name, domain_name, dns_forwarders, @@ -1319,7 +1331,9 @@ def main(): ca_configured=setup_ca, no_dnssec_validation=options.no_dnssec_validation) if options.setup_dns: - api.Backend.ldap2.connect(bind_dn=DN(('cn', 'Directory Manager')), bind_pw=dm_password) + if not api.Backend.ldap2.isconnected(): + api.Backend.ldap2.connect( + bind_dn=DN(('cn', 'Directory Manager')), bind_pw=dm_password) bind.create_instance() dnskeysyncd = dnskeysyncinstance.DNSKeySyncInstance(fstore, dm_password) diff --git a/install/tools/ipa-upgradeconfig b/install/tools/ipa-upgradeconfig index c6c602dc6b4582c24e4ca751ab2f91f8e683dffa..9e794060e4a520499c3c4c3c548eec7a5b551379 100755 --- a/install/tools/ipa-upgradeconfig +++ b/install/tools/ipa-upgradeconfig @@ -389,32 +389,34 @@ def ca_enable_ldap_profile_subsystem(ca): return needs_update -def upgrade_ipa_profile(ca, domain, fqdn): +def ca_import_included_profiles(ca): + root_logger.info('[Ensuring presence of included profiles]') + + if not ca.is_configured(): + root_logger.info('CA is not configured') + return False + + if not api.Backend.ldap2.isconnected(): + try: + api.Backend.ldap2.connect(autobind=True) + except ipalib.errors.PublicError, e: + root_logger.error("Cannot connect to LDAP: %s", e) + return + ca.import_included_profiles() + + +def upgrade_ca_audit_cert_validity(ca): """ - Update the IPA Profile provided by dogtag + Update the Dogtag audit signing certificate. Returns True if restart is needed, False otherwise. """ - root_logger.info('[Verifying that CA service certificate profile is updated]') + root_logger.info('[Verifying that CA audit signing cert has 2 year validity]') if ca.is_configured(): - ski = ca.enable_subject_key_identifier() - if ski: - root_logger.debug('Subject Key Identifier updated.') - else: - root_logger.debug('Subject Key Identifier already set.') - san = ca.enable_subject_alternative_name() - if san: - root_logger.debug('Subject Alternative Name updated.') - else: - root_logger.debug('Subject Alternative Name already set.') - audit = ca.set_audit_renewal() - uri = ca.set_crl_ocsp_extensions(domain, fqdn) - if audit or ski or san or uri: - return True + return ca.set_audit_renewal() else: root_logger.info('CA is not configured') - - return False + return False def named_remove_deprecated_options(): @@ -1337,6 +1339,7 @@ def main(): fstore = sysrestore.FileStore(paths.SYSRESTORE) api.bootstrap(context='restart', in_server=True) + import ipaserver.plugins.dogtag # ensure profile backend gets loaded api.finalize() fqdn = find_hostname() @@ -1484,7 +1487,7 @@ def main(): ca_restart = any([ ca_restart, - upgrade_ipa_profile(ca, api.env.domain, fqdn), + upgrade_ca_audit_cert_validity(ca), certificate_renewal_update(ca), ca_enable_pkix(ca), ca_configure_profiles_acl(ca), @@ -1498,6 +1501,12 @@ def main(): except ipautil.CalledProcessError, e: root_logger.error("Failed to restart %s: %s", ca.service_name, e) + # This step MUST be done after ca_enable_ldap_profile_subsystem and + # ca_configure_profiles_acl, and the consequent restart, but does not + # itself require a restart. + # + ca_import_included_profiles(ca) + set_sssd_domain_option('ipa_server_mode', 'True') if __name__ == '__main__': diff --git a/ipapython/dogtag.py b/ipapython/dogtag.py index 11311cf7b55d7b84e9434a698dbfd60b0eb142a1..e0091ba8747dff3a488b9908f057ae15c6b4bedc 100644 --- a/ipapython/dogtag.py +++ b/ipapython/dogtag.py @@ -42,6 +42,11 @@ from ipapython.ipa_log_manager import * # the configured version. +INCLUDED_PROFILES = { + # ( profile_id , description , store_issued) + (u'DefaultService', u'Standard profile for network services', True), + } + class Dogtag10Constants(object): DOGTAG_VERSION = 10 UNSECURE_PORT = 8080 diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index 81fd8a47d3cebe0659d5b3158928f578c0a75059..94c01de75ef8c3a4193c39cf8bcbe02dddda860e 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -459,10 +459,6 @@ class CAInstance(DogtagInstance): self.step("importing CA chain to RA certificate database", self.__import_ca_chain) self.step("fixing RA database permissions", self.fix_ra_perms) self.step("setting up signing cert profile", self.__setup_sign_profile) - self.step("set certificate subject base", self.__set_subject_in_config) - self.step("enabling Subject Key Identifier", self.enable_subject_key_identifier) - self.step("enabling Subject Alternative Name", self.enable_subject_alternative_name) - self.step("enabling CRL and OCSP extensions for certificates", self.__set_crl_ocsp_extensions) self.step("setting audit signing renewal to 2 years", self.set_audit_renewal) self.step("configuring certificate server to start on boot", self.enable) @@ -1136,94 +1132,6 @@ class CAInstance(DogtagInstance): return publishdir - def __set_crl_ocsp_extensions(self): - self.set_crl_ocsp_extensions(self.domain, self.fqdn) - - def set_crl_ocsp_extensions(self, domain, fqdn): - """ - Configure CRL and OCSP extensions in default IPA certificate profile - if not done already. - """ - changed = False - - # OCSP extension - ocsp_url = 'http://%s.%s/ca/ocsp' % (IPA_CA_RECORD, ipautil.format_netloc(domain)) - - ocsp_location_0 = installutils.get_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0', - separator='=') - - if ocsp_location_0 != ocsp_url: - # Set the first OCSP URI - installutils.set_directive(self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0', - ocsp_url, quotes=False, separator='=') - changed = True - - ocsp_profile_count = installutils.get_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.5.default.params.authInfoAccessNumADs', - separator='=') - - if ocsp_profile_count != '1': - installutils.set_directive(self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.5.default.params.authInfoAccessNumADs', - '1', quotes=False, separator='=') - changed = True - - - # CRL extension - crl_url = 'http://%s.%s/ipa/crl/MasterCRL.bin'% (IPA_CA_RECORD, ipautil.format_netloc(domain)) - - crl_point_0 = installutils.get_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.9.default.params.crlDistPointsPointName_0', - separator='=') - - if crl_point_0 != crl_url: - installutils.set_directive(self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.9.default.params.crlDistPointsIssuerName_0', - 'CN=Certificate Authority,o=ipaca', quotes=False, separator='=') - installutils.set_directive(self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.9.default.params.crlDistPointsIssuerType_0', - 'DirectoryName', quotes=False, separator='=') - installutils.set_directive(self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.9.default.params.crlDistPointsPointName_0', - crl_url, quotes=False, separator='=') - changed = True - - crl_profile_count = installutils.get_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.9.default.params.crlDistPointsNum', - separator='=') - - if crl_profile_count != '1': - installutils.set_directive(self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.9.default.params.crlDistPointsNum', - '1', quotes=False, separator='=') - changed = True - - # CRL extension is not enabled by default - setlist = installutils.get_directive(self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.list', separator='=') - new_set_list = None - - if setlist == '1,2,3,4,5,6,7,8': - new_set_list = '1,2,3,4,5,6,7,8,9' - elif setlist == '1,2,3,4,5,6,7,8,10': - new_set_list = '1,2,3,4,5,6,7,8,9,10' - elif setlist == '1,2,3,4,5,6,7,8,10,11': - new_set_list = '1,2,3,4,5,6,7,8,9,10,11' - - if new_set_list: - installutils.set_directive(self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.list', - new_set_list, quotes=False, separator='=') - changed = True - - return changed - def __enable_crl_publish(self): """ @@ -1278,13 +1186,6 @@ class CAInstance(DogtagInstance): installutils.set_directive(caconfig, 'ca.crl.MasterCRL.enableCRLUpdates', 'false', quotes=False, separator='=') installutils.set_directive(caconfig, 'ca.listenToCloneModifications', 'false', quotes=False, separator='=') - def __set_subject_in_config(self): - # dogtag ships with an IPA-specific profile that forces a subject - # format. We need to update that template with our base subject - if installutils.update_file(self.dogtag_constants.IPA_SERVICE_PROFILE, - 'OU=pki-ipa, O=IPA', str(self.subject_base)): - print "Updating subject_base in CA template failed" - def uninstall(self): enabled = self.restore_state("enabled") @@ -1421,100 +1322,6 @@ class CAInstance(DogtagInstance): services.knownservices.certmonger.stop() - def enable_subject_key_identifier(self): - """ - See if Subject Key Identifier is set in the profile and if not, add it. - """ - setlist = installutils.get_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.list', separator='=') - - # this is the default setting from pki-ca/pki-tomcat. Don't touch it - # if a user has manually modified it. - if setlist == '1,2,3,4,5,6,7,8' or setlist == '1,2,3,4,5,6,7,8,9': - setlist += ',10' - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.list', - setlist, - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.10.constraint.class_id', - 'noConstraintImpl', - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.10.constraint.name', - 'No Constraint', - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.10.default.class_id', - 'subjectKeyIdentifierExtDefaultImpl', - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.10.default.name', - 'Subject Key Identifier Extension Default', - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.10.default.params.critical', - 'false', - quotes=False, separator='=') - return True - - # No update was done - return False - - def enable_subject_alternative_name(self): - """ - See if Subject Alternative Name is set in the profile and if not, add - it. - """ - setlist = installutils.get_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.list', separator='=') - - # this is the default setting from pki-ca/pki-tomcat. Don't touch it - # if a user has manually modified it. - if setlist == '1,2,3,4,5,6,7,8,10' or setlist == '1,2,3,4,5,6,7,8,9,10': - setlist += ',11' - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.list', - setlist, - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.11.constraint.class_id', - 'noConstraintImpl', - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.11.constraint.name', - 'No Constraint', - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.11.default.class_id', - 'userExtensionDefaultImpl', - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.11.default.name', - 'User Supplied Extension Default', - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.11.default.params.userExtOID', - '2.5.29.17', - quotes=False, separator='=') - return True - - # No update was done - return False def set_audit_renewal(self): """ @@ -1600,6 +1407,29 @@ class CAInstance(DogtagInstance): master_entry['ipaConfigString'].append('caRenewalMaster') self.admin_conn.update_entry(master_entry) + def import_included_profiles(self): + sub_dict = dict( + DOMAIN=ipautil.format_netloc(api.env.domain), + IPA_CA_RECORD=IPA_CA_RECORD, + CRL_ISSUER='CN=Certificate Authority,o=ipaca', + SUBJECT_DN_O=str(DN(('O', api.env.realm))), + ) + + for (profile_id, desc, store_issued) in dogtag.INCLUDED_PROFILES: + try: + show_ret = api.Command['certprofile_show'](profile_id) + continue # the profile is present + except errors.NotFound: + # profile not found; add it + profile_data = ipautil.template_file( + '/usr/share/ipa/profiles/{}.cfg'.format(profile_id), sub_dict) + api.Command['certprofile_import']( + profile_id, + file=profile_data.decode('utf-8'), + description=desc, + ipacertprofilestoreissued=store_issued, + ) + root_logger.info("Imported profile '%s'", profile_id) @staticmethod def update_cert_config(nickname, cert, dogtag_constants=None): diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py index 9654123b16d8e417398d49bf1305fd41880bc3a7..880b319d68728a40f4479626d5a7c2b8c56ced02 100644 --- a/ipaserver/plugins/dogtag.py +++ b/ipaserver/plugins/dogtag.py @@ -1966,17 +1966,19 @@ class RestClient(Backend): self.ipa_key_size = "2048" self.ipa_certificate_nickname = "ipaCert" self.ca_certificate_nickname = "caCert" - try: - f = open(self.pwd_file, "r") - self.password = f.readline().strip() - f.close() - except IOError: - self.password = '' + self._read_password() super(RestClient, self).__init__() # session cookie self.cookie = None + def _read_password(self): + try: + with open(self.pwd_file) as f: + self.password = f.readline().strip() + except IOError: + self.password = '' + @cachedproperty def ca_host(self): """ -- 2.1.0 From pvoborni at redhat.com Fri May 15 08:59:57 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 15 May 2015 10:59:57 +0200 Subject: [Freeipa-devel] [PATCH] 832-850 Stage Users Web UI and its prerequisites Message-ID: <5555B58D.8010804@redhat.com> 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 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0850-webui-stageusers-display-page-elements-based-on-user.patch Type: text/x-patch Size: 4949 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0849-webui-update-stageuser-user-pages-based-on-action-in.patch Type: text/x-patch Size: 2414 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0848-webui-extend-user-deleter-dialog-with-permanent-and-.patch Type: text/x-patch Size: 2394 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0847-webui-stageuser-plugin.patch Type: text/x-patch Size: 19359 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0846-webui-facet-policies-for-all-facets.patch Type: text/x-patch Size: 4101 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0845-webui-allow-to-hide-facet-tabs-or-sidebar.patch Type: text/x-patch Size: 2629 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0844-webui-allow-to-replace-facet-tabs-with-sidebar.patch Type: text/x-patch Size: 5585 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0843-webui-facet-groups-widget.patch Type: text/x-patch Size: 11864 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0842-webui-custom-facet-groups-in-a-facet.patch Type: text/x-patch Size: 4384 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0841-webui-metadata-validator-min-and-max-value-overrides.patch Type: text/x-patch Size: 2580 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0840-webui-navigation-unique-names-on-entity-facet-menu-i.patch Type: text/x-patch Size: 2315 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0839-webui-navigation-do-not-remember-selected-childs-of-.patch Type: text/x-patch Size: 3339 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0838-webui-prefer-entity-fallback-in-menu-item-select.patch Type: text/x-patch Size: 1880 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0837-webui-entity-menu-items-navigate-to-main-entity-face.patch Type: text/x-patch Size: 901 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0836-webui-entity-facets-in-facet-registry.patch Type: text/x-patch Size: 7784 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0835-webui-register-construction-spec-based-on-existing-s.patch Type: text/x-patch Size: 5537 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0834-webui-declare-search-command-options-in-search-facet.patch Type: text/x-patch Size: 2072 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0833-webui-rename-IPA.user_-to-IPA.user.patch Type: text/x-patch Size: 1889 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0832-webui-update-patternfly-to-v1.1.4.patch Type: text/x-patch Size: 340851 bytes Desc: not available URL: From pvoborni at redhat.com Fri May 15 09:01:51 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 15 May 2015 11:01:51 +0200 Subject: [Freeipa-devel] [PATCH] 830 webui: fix empty table border in Firefox Message-ID: <5555B5FF.1040801@redhat.com> Firefox suffers from: https://bugzilla.mozilla.org/show_bug.cgi?id=409254 This is a workaround to fix it. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0830-webui-fix-empty-table-border-in-Firefox.patch Type: text/x-patch Size: 908 bytes Desc: not available URL: From pvoborni at redhat.com Fri May 15 09:02:53 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 15 May 2015 11:02:53 +0200 Subject: [Freeipa-devel] [PATCH] 831 webui: better error reporting Message-ID: <5555B63D.9040404@redhat.com> Helps in development and debugging. - ActionDropdownWidget - report error if required action is missing - report build errors to console -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0831-webui-better-error-reporting.patch Type: text/x-patch Size: 3549 bytes Desc: not available URL: From pspacek at redhat.com Fri May 15 09:37:19 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 15 May 2015 11:37:19 +0200 Subject: [Freeipa-devel] [PATCH 0339-0363] Implement meta-database Message-ID: <5555BE4F.9020609@redhat.com> Hello, this patch set adds meta-database which is one of prerequisites for other work. These changes should not be user-visible. You might compile the plugin with CFLAGS="-DMETADB_DEBUG" and check contect of /tmp/metadb.db after BIND shutdown. Please see https://fedorahosted.org/bind-dyndb-ldap/ticket/151 https://fedorahosted.org/bind-dyndb-ldap/wiki/Design/MetaDB for further information and let me know if you can help you somehow. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0339-Add-LDAP-UUID-meta-database-name-mapping-function.patch Type: text/x-patch Size: 4106 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0340-Add-basic-infratructure-for-generic-meta-database.patch Type: text/x-patch Size: 9751 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0341-Add-static-compile-time-assert-macro.patch Type: text/x-patch Size: 2122 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0342-Add-basic-infratructure-for-LDAP-meta-database.patch Type: text/x-patch Size: 2738 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0343-Add-functions-for-populating-LDAP-meta-database.patch Type: text/x-patch Size: 4849 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0344-Add-meta-LDAP-database-to-LDAP-instance.patch Type: text/x-patch Size: 1545 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0345-Add-LDAP-UUID-to-LDAP-entry-structure.patch Type: text/x-patch Size: 3170 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0346-Store-object-class-generation-number-and-DNS-names-i.patch Type: text/x-patch Size: 2735 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0347-Move-typedefs-to-types.h-to-avoid-cross-include-prob.patch Type: text/x-patch Size: 5886 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0348-Add-functions-for-reading-from-generic-meta-database.patch Type: text/x-patch Size: 2479 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0349-Add-functions-for-reading-from-meta-LDAP-database.patch Type: text/x-patch Size: 3933 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0350-Use-information-from-metaDB-for-LDAP-object-deletion.patch Type: text/x-patch Size: 5269 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0351-Rename-ldap_entry_create-to-ldap_entry_parse.patch Type: text/x-patch Size: 2365 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0352-Replace-ldap_entry_parseclass-by-LDAP-entry-struct-m.patch Type: text/x-patch Size: 7877 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0353-Add-pre-parsed-DNS-names-to-LDAP-entry-structure.patch Type: text/x-patch Size: 4182 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0354-Adapt-update_record-to-use-pre-parsed-DNS-names-in-L.patch Type: text/x-patch Size: 3493 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0355-Adapt-ldap_parse_fwd_zoneentry-to-use-pre-parsed-DNS.patch Type: text/x-patch Size: 2516 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0356-Adapt-update_zone-to-use-pre-parsed-DNS-names-in-LDA.patch Type: text/x-patch Size: 2493 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0357-Adapt-ldap_parse_master_zoneentry-to-use-pre-parsed-.patch Type: text/x-patch Size: 5202 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0358-Adapt-ldap_sync_search_entry-to-use-pre-parsed-DNS-n.patch Type: text/x-patch Size: 2119 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0359-Adapt-syncrepl_update-to-use-pre-parsed-DNS-names-an.patch Type: text/x-patch Size: 6569 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0360-Add-function-for-node-deletion-from-generic-meta-dat.patch Type: text/x-patch Size: 2388 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0361-Add-ability-to-open-existing-metaDB-node-for-writing.patch Type: text/x-patch Size: 2818 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0362-Add-function-for-node-deletion-to-meta-LDAP-database.patch Type: text/x-patch Size: 1768 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0363-Delete-metadata-about-objects-deleted-from-LDAP.patch Type: text/x-patch Size: 3391 bytes Desc: not available URL: From pspacek at redhat.com Fri May 15 09:44:26 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 15 May 2015 11:44:26 +0200 Subject: [Freeipa-devel] [PATCH 0364] Remove unused files rdlist.c and rdlist.h Message-ID: <5555BFFA.2050207@redhat.com> 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. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0364-Remove-unused-files-rdlist.c-and-rdlist.h.patch Type: text/x-patch Size: 11087 bytes Desc: not available URL: From pspacek at redhat.com Fri May 15 10:10:34 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 15 May 2015 12:10:34 +0200 Subject: [Freeipa-devel] [PATCH 0248] DNSSEC: Fix: Do not recreate kasp.db if already exists In-Reply-To: <5554BA9A.8050202@redhat.com> References: <5554BA9A.8050202@redhat.com> Message-ID: <5555C61A.6090507@redhat.com> 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. -- Petr^2 Spacek From jcholast at redhat.com Fri May 15 10:25:37 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 15 May 2015 12:25:37 +0200 Subject: [Freeipa-devel] [PATCH 0246] Don't use proxy to check CA status during install/upgrade In-Reply-To: <5553397F.4010503@redhat.com> References: <5553397F.4010503@redhat.com> Message-ID: <5555C9A1.6030908@redhat.com> Hi, Dne 13.5.2015 v 13:46 Martin Basti napsal(a): > https://fedorahosted.org/freeipa/ticket/4994 > > Patch attached. Thanks, ACK. Pushed to master: 3c86b0ef3e684d45301ae2c2452932ea4f279f08 Honza -- Jan Cholasta From pvoborni at redhat.com Fri May 15 10:34:27 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 15 May 2015 12:34:27 +0200 Subject: [Freeipa-devel] [PATCH] 832-850 Stage Users Web UI and its prerequisites In-Reply-To: <5555B58D.8010804@redhat.com> References: <5555B58D.8010804@redhat.com> Message-ID: <5555CBB3.1060003@redhat.com> 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. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0847-1-webui-stageuser-plugin.patch Type: text/x-patch Size: 19360 bytes Desc: not available URL: From pspacek at redhat.com Fri May 15 11:12:45 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 15 May 2015 13:12:45 +0200 Subject: [Freeipa-devel] [PATCH 0249] DNSSEC: update kasp configuration template: increase key size & lifetime In-Reply-To: <5554BDEB.8070704@redhat.com> References: <5554BDEB.8070704@redhat.com> Message-ID: <5555D4AD.10404@redhat.com> 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 :-) -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0249-pspacek-2-DNSSEC-update-opendnssec-kasp-configuration.patch Type: text/x-patch Size: 3270 bytes Desc: not available URL: From mkosek at redhat.com Fri May 15 11:32:40 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 15 May 2015 13:32:40 +0200 Subject: [Freeipa-devel] Wiki: automatic bookkeeping of Design documents In-Reply-To: <5549B900.3060607@redhat.com> References: <5549B900.3060607@redhat.com> Message-ID: <5555D958.7080801@redhat.com> On 05/06/2015 08:47 AM, Martin Kosek wrote: > Hello all, > > Knowing the sorrow and unmaintained state of the pages collecting links to our > designs [1][2], I think we need to execute the second half of my evil plan for > Design Document management. > > We have the Feature design box (see top right corner, e.g. in [3]), so we can > easily automatically generate mediawiki categories. The first I implemented in > the template are "FreeIPA $VERSION Design" when target version is filled (and > design is thus accepted for a release) and "FreeIPA Design Proposal" for > others. We can be creative with other categories in future, if needed. > > But even these 2 and a DynamicPageList plugin allowed me to create > automatically generated design lists, in [4]. I had to update the box in many > designs, however. > > Makes sense? If yes, I would update these pages. Of course, this requires > developers to maintain the Feature box properly, but I think it's worth it. > > > [1] http://www.freeipa.org/page/V4_Proposals > [2] http://www.freeipa.org/page/V4_Designs > [3] http://www.freeipa.org/page/V4/User_Certificates > [4] http://www.freeipa.org/page/Talk:V4_Designs > Thanks everyone for commenting. Seeing the positive feedback, I did the changes and updated the Code Contribution policy and the pages themselves: http://www.freeipa.org/page/Contribute/Code http://www.freeipa.org/page/V4_Designs http://www.freeipa.org/page/V4_Proposals Enjoy! Martin From mbasti at redhat.com Fri May 15 11:33:01 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 15 May 2015 13:33:01 +0200 Subject: [Freeipa-devel] [PATCH 0249] DNSSEC: update kasp configuration template: increase key size & lifetime In-Reply-To: <5555D4AD.10404@redhat.com> References: <5554BDEB.8070704@redhat.com> <5555D4AD.10404@redhat.com> Message-ID: <5555D96D.5030300@redhat.com> 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 -- Martin Basti From pvoborni at redhat.com Fri May 15 11:50:23 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 15 May 2015 13:50:23 +0200 Subject: [Freeipa-devel] [PATCH] 822 webui: topology plugin In-Reply-To: <55365A0B.1030305@redhat.com> References: <55365A0B.1030305@redhat.com> Message-ID: <5555DD7F.10000@redhat.com> On 04/21/2015 04:09 PM, Petr Vobornik wrote: > First iteration of Topology plugin Web UI. > > It reflects current state of topology plugin python part which is > implemented in "[PATCH] manage replication topology in the shared tree" > and my wip patch. > > I expect that the server API part will change a bit therefore this will > as well. > > Graphical visualization/management (ticket 4286) will be implemented in > separate patch. > > https://fedorahosted.org/freeipa/ticket/4997 > http://www.freeipa.org/page/V4/Manage_replication_topology > > New version attached. It requires stage user web ui patches in order to apply (I expect that user life cycle backend will be pushed sooner than topology) Changes: - Left host and Right host fields are now host comboboxes - Connectivity are radio buttons with "both, left-right, right-left, none" options - segment name is not a required field in its adder dialog IMHO "Attributes to strip", "Attributes to replicate", "Attributes for total update", "Initialize replica", "Session timeout", "Replication agreement enabled" fields should not be just free-form textboxes, but they should be more specific, e.g. a checkbox for "Replication agreement enabled" or integer for "Session timeout", but that should be modified first in the backend python plugin. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0822-1-webui-topology-plugin.patch Type: text/x-patch Size: 10004 bytes Desc: not available URL: From mbasti at redhat.com Fri May 15 12:27:41 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 15 May 2015 14:27:41 +0200 Subject: [Freeipa-devel] [PATCHES 0001-0007] Profile management In-Reply-To: <20150515082420.GR12806@dhcp-40-8.bne.redhat.com> References: <20150504133641.GQ16379@dhcp-40-8.bne.redhat.com> <55479FE1.1020005@redhat.com> <20150505062934.GU16379@dhcp-40-8.bne.redhat.com> <5548816D.6050304@redhat.com> <555305EC.5020001@redhat.com> <55530D23.5040702@redhat.com> <55530DDB.9000101@redhat.com> <20150515082420.GR12806@dhcp-40-8.bne.redhat.com> Message-ID: <5555E63D.4050808@redhat.com> 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. > >>>>>>> 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. > >>> Martin^2 >>>>>>> Other issues: >>>>>>> 1) >>>>>>> I do not see modifications in API.txt file >>>>>>> >>>>>>> 2) >>>>>>> We use new shorter license header >>>>>>> # >>>>>>> # Copyright (C) 2015 FreeIPA Contributors see COPYING for license >>>>>>> # >>>>>>> >>>>>>> 3) >>>>>>> +from ipalib.plugins.baseldap import \ >>>>>>> + LDAPObject, LDAPSearch, LDAPCreate, LDAPDelete, LDAPUpdate, >>>>>>> LDAPRetrieve >>>>>>> >>>>>>> please use 'import ( modules, .. )' instead of '\' >>>>>>> >>>>>>> 4) >>>>>>> + if method == 'POST' \ >>>>>>> + and 'content-type' not in (str(k).lower() for k in >>>>>>> headers.viewkeys()): >>>>>>> >>>>>>> again, please use if ( ... ): instead \ >>>>>>> >>>>>>> 5) >>>>>>> +import ipalib.errors as errors >>>>>>> in dogtag.py >>>>>>> >>>>>>> Can you use from ipalib import errors, instead? >>>>>>> >>>>>>> 6) >>>>>>> + def __exit__(self, exc_type, exc_value, traceback): >>>>>>> + """Log out of the REST API""" >>>>>>> + # TODO logout >>>>>>> + self.cookie = None >>>>>>> >>>>>>> This is forgotten, or will be this fixed later? >>>>>>> >>>>>>> 7) >>>>>>> + if not explanation: print resp_body # NOCOMMIT >>>>>>> >>>>>> These are all fixed for the next patchset. >>>>>> >>>>>> Thanks! >>>>>> Fraser >>>>>> >>>> 8) You can do: >>>> >>>> Str('cn', >>>> primary_key=True, >>>> cli_name='id', >>>> label=_('Profile ID'), >>>> doc=_('Profile ID for referring to this profile'), >>>> pattern='^[a-zA-Z]\w*$', >>>> pattern_errmsg=_('invalid Profile ID'), >>>> ), >>>> >>>> instead of: >>>> >>>> profile_id_pattern = re.compile('^[a-zA-Z]\w*$') >>>> >>>> def validate_profile_id(ugettext, value): >>>> """Ensure profile ID matches form required by CA.""" >>>> if profile_id_pattern.match(value) is None: >>>> return _('invalid Profile ID') >>>> else: >>>> return None >>>> >>>> ... >>>> >>>> Str('cn', validate_profile_id, >>>> primary_key=True, >>>> cli_name='id', >>>> label=_('Profile ID'), >>>> doc=_('Profile ID for referring to this profile'), >>>> ), >>>> > This is nice, but I have kept the separate method so that the > cert-request command can use the same routine for validating the > profile id (this will be in a subsequent patch). > >>>> 9) Please don't invent new attributes (ipaCertProfileSummary) when you >>>> can use existing ones (description). >>>> >>>> >>>> 10) All the commands should call ipalib.plugins.cert.ca_enabled_check(). >>>> >>>> >>>> 11) I think the File parameter of certprofile_import should be called >>>> just 'file'. >>>> > 9, 10, 11 were addressed for this patchset. > >>>> 12) IMO the profile backend should be merged in to the ra backend. I >>>> don't see a need to have these two separate. >>>> >>>> >>>> Honza >>>> >>> >> >> -- >> Jan Cholasta Thank you. I did part of review, again I have not idea about the dogtag magic there, so I might be completely wrong. Martin^2 Patches need rebase. Patch 0001: 1) I'm not sure if this is added during upgrade + config.set("CA", "pki_profiles_in_ldap", "True") Patch 0002: LGTM (upgrade solved in 0005) Patch 0003: I have no idea. Patch 0004: 1) Can you please let it in old school way, for better readability sysupgrade.get_upgrade_state(*upgrade_state_args): sysupgrade.get_upgrade_state('dogtag', 'agent_allow_profile_modify') sysupgrade.set_upgrade_state('dogtag', 'agent_allow_profile_modify' ,True) 2) + conn = ipaldap.IPAdmin(self.fqdn, self.ds_port) + conn.do_simple_bind(DN(('cn', 'Directory Manager')), self.dm_password) + conn.modify_s(dn, modlist) + conn.unbind() IMO You can use: self.ldap_connect() self.admin_conn.modify_s() Patch 0005: LGTM Patch 0006: LGTM Patch 0007: 0) I cannot apply patch error: invalid object 100755 c6c602dc6b4582c24e4ca751ab2f91f8e683dffa for 'install/tools/ipa-upgradeconfig' fatal: git-write-tree: error building trees Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0007 Import included profiles during install or upgrade 1) + # update `api.env.ca_host` to correct hostname + # https://fedorahosted.org/freeipa/ticket/4936 + api.env.ca_host = host_name This is something what was already fixed, maybe rebase error? 2) + if setup_ca: + # ensure profile backend is available + import ipaserver.plugins.dogtag Must be this import in ipa-server-install? Respectively why is this import required, isn't it initialized by api.finalize()? 3) + service.print_msg("Importing certificate profiles") + api.Backend.ra_certprofile._read_password() + if not api.Backend.ldap2.isconnected(): + api.Backend.ldap2.connect(autobind=True) + ca.import_included_profiles() Why this must be in ipa-server-install? Why is that not in cainstance? 4) I'm not sure if these functions can be removed: Honza please take look, if it is safe - def upgrade_ipa_profile(ca, domain, fqdn) - self.step("set certificate subject base", self.__set_subject_in_config) - self.step("enabling Subject Key Identifier", self.enable_subject_key_identifier) - self.step("enabling Subject Alternative Name", self.enable_subject_alternative_name) - self.step("enabling CRL and OCSP extensions for certificates", self.__set_crl_ocsp_extensions) 5) '/usr/share/ipa/profiles/{}.cfg'.format(profile_id), sub_dict) os.path.join(paths.USR_SHARE_IPA_DIR, 'profiles', ) please use paths from ipaplatform.paths module. Maybe rather create new path in ipaplatform/base/paths USR_SHARE_IPA_PROFILES_DIR = "/usr/share/ipa/profiles" Nitpicks: In several patches: + except ipalib.errors.PublicError, e: please us except ipalib.errors.PublicError as e -- Martin Basti From thozza at redhat.com Fri May 15 13:48:56 2015 From: thozza at redhat.com (Tomas Hozza) Date: Fri, 15 May 2015 15:48:56 +0200 Subject: [Freeipa-devel] [PATCH 0322-0337] Fix mysterious failures in PTR record synchronization In-Reply-To: <5548E0AB.8090600@redhat.com> References: <5548E0AB.8090600@redhat.com> Message-ID: <5555F948.9070603@redhat.com> On 05/05/2015 05:24 PM, Petr Spacek wrote: > Hello, > > Attached patch set is the best fix for > https://fedorahosted.org/bind-dyndb-ldap/ticket/155 > I was able to write. > > This patch set should fix vast majority of race conditions. Unfortunately it > cannot be 100 % reliable without support for LDAP transactions. > > For convenience you can download the whole tree from > https://github.com/pspacek/bind-dyndb-ldap/commits/t155.syncptr > HEAD = da2552632f6ce67f1bb9d9b3cdd3e0a8e06ce9ea > > Enjoy. > Hi. There is one unused variable after patch 325 Move SOA serial update functions to zone.c. - it looks like you forgot to remove: https://github.com/pspacek/bind-dyndb-ldap/blob/d616021d6665ebab97035efb687a88a4a139f636/src/ldap_helper.c#L3892 https://github.com/pspacek/bind-dyndb-ldap/blob/d616021d6665ebab97035efb687a88a4a139f636/src/ldap_helper.c#L4037 https://github.com/pspacek/bind-dyndb-ldap/blob/d616021d6665ebab97035efb687a88a4a139f636/src/ldap_helper.c#L4038 Other than that, patches look good. I tested them and reviewed from https://github.com/pspacek/bind-dyndb-ldap/commits/t155.syncptr ACK with the fix for unused variable. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com From thozza at redhat.com Fri May 15 13:50:26 2015 From: thozza at redhat.com (Tomas Hozza) Date: Fri, 15 May 2015 15:50:26 +0200 Subject: [Freeipa-devel] [PATCH 0338] Add includes to zone.c to improve compatibility with BIND 9.9.4 In-Reply-To: <554B60C9.2030403@redhat.com> References: <554B60C9.2030403@redhat.com> Message-ID: <5555F9A2.40306@redhat.com> On 05/07/2015 02:55 PM, Petr Spacek wrote: > Hello, > > This is minor improvement for patch set related to ticket #155. > > Add includes to zone.c to improve compatibility with BIND 9.9.4. > Hi. I tested and reviewed the patch from https://github.com/pspacek/bind-dyndb-ldap/commits/t155.syncptr ACK. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com From mbabinsk at redhat.com Fri May 15 14:16:38 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 15 May 2015 16:16:38 +0200 Subject: [Freeipa-devel] [PATCHES 0033-0034] fix recent bugs introduced by letting httpd use file-based ccache Message-ID: <5555FFC6.3090507@redhat.com> 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. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0033-move-IPA-related-http-runtime-directories-to-common-.patch Type: text/x-patch Size: 3887 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0034-explicitly-destroy-httpd-service-ccache-file-during-.patch Type: text/x-patch Size: 2083 bytes Desc: not available URL: From jcholast at redhat.com Fri May 15 14:25:43 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 15 May 2015 16:25:43 +0200 Subject: [Freeipa-devel] [PATCHES 0033-0034] fix recent bugs introduced by letting httpd use file-based ccache In-Reply-To: <5555FFC6.3090507@redhat.com> References: <5555FFC6.3090507@redhat.com> Message-ID: <555601E7.1060408@redhat.com> 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. -- Jan Cholasta From jcholast at redhat.com Fri May 15 14:30:39 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 15 May 2015 16:30:39 +0200 Subject: [Freeipa-devel] [PATCH 426] baseldap: Fix possible crash in LDAPObject.handle_duplicate_entry Message-ID: <5556030F.4020009@redhat.com> Hi, the attached patch fixes a bug I have discovered while reviewing the vault patches. Pushed to master under the one-liner rule: dc668b1b6a75472ea79a6af4dbcd8c6a2c5a0384 Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-426-baseldap-Fix-possible-crash-in-LDAPObject.handle_dup.patch Type: text/x-patch Size: 798 bytes Desc: not available URL: From pspacek at redhat.com Fri May 15 14:36:48 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 15 May 2015 16:36:48 +0200 Subject: [Freeipa-devel] [PATCH 0322-0337] Fix mysterious failures in PTR record synchronization In-Reply-To: <5555F948.9070603@redhat.com> References: <5548E0AB.8090600@redhat.com> <5555F948.9070603@redhat.com> Message-ID: <55560480.8050709@redhat.com> On 15.5.2015 15:48, Tomas Hozza wrote: > On 05/05/2015 05:24 PM, Petr Spacek wrote: >> Hello, >> >> Attached patch set is the best fix for >> https://fedorahosted.org/bind-dyndb-ldap/ticket/155 >> I was able to write. >> >> This patch set should fix vast majority of race conditions. Unfortunately it >> cannot be 100 % reliable without support for LDAP transactions. >> >> For convenience you can download the whole tree from >> https://github.com/pspacek/bind-dyndb-ldap/commits/t155.syncptr >> HEAD = da2552632f6ce67f1bb9d9b3cdd3e0a8e06ce9ea >> >> Enjoy. >> > > Hi. > > There is one unused variable after patch 325 > Move SOA serial update functions to zone.c. > > - it looks like you forgot to remove: > https://github.com/pspacek/bind-dyndb-ldap/blob/d616021d6665ebab97035efb687a88a4a139f636/src/ldap_helper.c#L3892 > https://github.com/pspacek/bind-dyndb-ldap/blob/d616021d6665ebab97035efb687a88a4a139f636/src/ldap_helper.c#L4037 > https://github.com/pspacek/bind-dyndb-ldap/blob/d616021d6665ebab97035efb687a88a4a139f636/src/ldap_helper.c#L4038 > > Other than that, patches look good. I tested them and reviewed from > https://github.com/pspacek/bind-dyndb-ldap/commits/t155.syncptr > > ACK with the fix for unused variable. Fixed version was pushed to master branch: e36125eb594b0c71f6afe02bfc34de4cf4c19b94 SyncPTR: Read PTR record values from RBTDB instead of LDAP. 86ad1dd8363c55c579f29e2da0bf87aedc7fcc80 Split SyncPTR code into separate module. d430ca6ba685cf629f72466b1a17e8ed36a346a7 Move journal maintenance functions to zone.c. f24c80ac80b6f8eae2324123e79c73e0a72492f5 Move SOA serial update functions to zone.c. 7dee381afc752f8611ad7d91cb309b721b0097bd Move helper functions for diff manipulation to zone.c. a38479f9739f59fedb8c264c768b7d3044b3692c Move DEFAULT_TTL to header ldap_entry.h. 0aa9c851a71a68efa5342d6b492429d1d96a820b Return ISC_R_SUCCESS from rdataset_to_diff() to be consistent. caf4c85b2892b49e567e4464824d4bae5d73929e SyncPTR: Use database API for modifications to prevent race conditions. 4a6f694a5898bdcb90ca758e4521e5afa9c1759b Zone SOA serial functions now accept NULL output parameter new_serial. c42005a3b219879043b59c70372eaddbd3e9e72a SyncPTR: Bump SOA serial immediatelly during PTR synchronization. 56ec3b86a63709d6218852c69fce1dbda72e834b SyncPTR: Record PTR synchronization into zone journal to allow IXFR. e3b090403b7c9529b84647e0a31e03574dcb08b6 SyncPTR: Do update asynchronously to prevent race conditions. b56f558435fb608237cef0cf51595d1ccc09be67 Remove unused structure ldap_qresult. 1a36c36b69d490e48c1f04cfe85c064202989a3b SyncPTR: Improve logging. 41fabef959bd2ed08194c507271e41a26cdac8f4 SyncPTR: Do not return SERVFAIL if reverse zone does not exist. e35f51a752e06d500984faff934267d734e365aa SyncPTR: New PTR records inherit TTL value from respective A/AAAA records. 1e8a8461c2a27e37046a47f22c7203ff1aa5d6ba Add includes to zone.c to improve compatibility with BIND 9.9.4. Thank you! -- Petr^2 Spacek From pspacek at redhat.com Fri May 15 14:37:36 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 15 May 2015 16:37:36 +0200 Subject: [Freeipa-devel] [PATCH 0338] Add includes to zone.c to improve compatibility with BIND 9.9.4 In-Reply-To: <5555F9A2.40306@redhat.com> References: <554B60C9.2030403@redhat.com> <5555F9A2.40306@redhat.com> Message-ID: <555604B0.5050904@redhat.com> On 15.5.2015 15:50, Tomas Hozza wrote: > On 05/07/2015 02:55 PM, Petr Spacek wrote: >> Hello, >> >> This is minor improvement for patch set related to ticket #155. >> >> Add includes to zone.c to improve compatibility with BIND 9.9.4. >> > > Hi. > > I tested and reviewed the patch from > https://github.com/pspacek/bind-dyndb-ldap/commits/t155.syncptr > > ACK. Pushed to master: 1e8a8461c2a27e37046a47f22c7203ff1aa5d6ba Add includes to zone.c to improve compatibility with BIND 9.9.4. -- Petr^2 Spacek From mbabinsk at redhat.com Fri May 15 14:41:38 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 15 May 2015 16:41:38 +0200 Subject: [Freeipa-devel] [PATCHES 0033-0034] fix recent bugs introduced by letting httpd use file-based ccache In-Reply-To: <555601E7.1060408@redhat.com> References: <5555FFC6.3090507@redhat.com> <555601E7.1060408@redhat.com> Message-ID: <555605A2.8000704@redhat.com> 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. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0033.1-move-IPA-related-http-runtime-directories-to-common-.patch Type: text/x-patch Size: 4039 bytes Desc: not available URL: From mbasti at redhat.com Fri May 15 14:44:06 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 15 May 2015 16:44:06 +0200 Subject: [Freeipa-devel] [PATCH 0247] Modularization of the DNS subsytem installer In-Reply-To: <5554A01F.5040506@redhat.com> References: <5554A01F.5040506@redhat.com> Message-ID: <55560636.8020408@redhat.com> On 14/05/15 15:16, Martin Basti wrote: > Required for new installers. > > Patch attached. > > > Updated patch attached. -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0247.2-DNS-install-extract-DNS-installer-into-one-module.patch Type: text/x-patch Size: 31180 bytes Desc: not available URL: From dkupka at redhat.com Fri May 15 14:44:59 2015 From: dkupka at redhat.com (David Kupka) Date: Fri, 15 May 2015 10:44:59 -0400 (EDT) Subject: [Freeipa-devel] [PATCH] 0005 User life cycle: del/mod/find/show stageuser commands In-Reply-To: <555216B9.1070106@redhat.com> References: <552F964E.2060304@redhat.com> <553F437D.5080103@redhat.com> <553F44B7.6040100@redhat.com> <553F476E.8080502@redhat.com> <553F9BCE.6010000@redhat.com> <554869C3.2040509@redhat.com> <5551EF3E.1060503@redhat.com> <555216B9.1070106@redhat.com> Message-ID: <205373726.22060212.1431701099532.JavaMail.zimbra@redhat.com> Hello Thierry, thanks for the patch set. Overall functionality of ULC feature looks good to me and is definitely "alpha ready". I found following issues but don't insist on fixing it right now: 1) When stageuser-activate fails due to already existent active/deleted user. DN is show instead of user name that's used in other commands (user-add, stageuser-add). $ ipa user-add tuser --first Test --last User $ ipa stageuser-add tuser --first Test --last User $ ipa stageuser-activate tuser ipa: ERROR: Active user uid=tuser,cn=users,cn=accounts,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com already exists 2) According to the design there should be '--only-delete' and '--also-delete' options for user-find command instead there is '--preserved' option. Honza proposed adding virtual boolean attribute 'deleted' to user entry and filter on it. The 'deleted' attribute would be useful also in user-show where is no way to tell if the displayed user is active or deleted. (Except running with --all and looking on the dn). 3) uidNumber and gidNumber can't be set back to '-1' once set to other value. This would be useful when admin changes its mind and want IPA to assign them. IIUC, there should be no validation in cn=staged user container. All validation should be done during stageuser-activate. 4) Support for deleted -> stage workflow is still missing. But I'm unsure if we agreed to finish it now or later. 5) Twice deleting user with '--preserve' deletes him permanently. $ ipa user-add tuser --first Test --last User $ ipa user-del tuser --preserve $ ipa user-del tuser --preserve $ ipa user-find --preserved ------------------------ 0 (delete) users matched ------------------------ ---------------------------- Number of entries returned 0 ---------------------------- David ----- Original Message ----- From: "thierry bordaz" To: "Jan Cholasta" , "David Kupka" Cc: "freeipa-devel" Sent: Tuesday, May 12, 2015 5:05:29 PM Subject: Re: [Freeipa-devel] [PATCH] 0005 User life cycle: del/mod/find/show stageuser commands On 05/12/2015 02:17 PM, thierry bordaz wrote: > On 05/05/2015 08:57 AM, Jan Cholasta wrote: >> Hi, >> >> Dne 28.4.2015 v 16:40 thierry bordaz napsal(a): >>> On 04/28/2015 10:40 AM, David Kupka wrote: >>>> On 04/28/2015 10:28 AM, thierry bordaz wrote: >>>>> On 04/28/2015 10:23 AM, David Kupka wrote: >>>>>> On 04/16/2015 01:00 PM, thierry bordaz wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Here is the next patch for User life cycle that introduces >>>>>>> del/mod/find and show stageuser plugin commands. >>>>>>> >>>>>>> * 0000-User Life Cycle (create containers and scoping DS >>>>>>> plugins): >>>>>>> *pushed* >>>>>>> * >>>>>>> 0001-User-Life-Cycle-Exclude-subtree-for-ipaUniqueID-gene.patch: >>>>>>> *pushed* >>>>>>> * 0002-User-life-cycle-stageuser-add-verb.patch: *pushed* >>>>>>> * 0007-User-life-cycle-allows-MODRDN-from-ldap2.patch: *pushed* >>>>>>> * 0003-User-life-cycle-new-stageuser-commands-del-mod-find-*under >>>>>>> review *(this one)** >>>>>>> * 0004-User-life-cycle-new-stageuser-commands-activate.patch >>>>>>> * 0005-User-life-cycle-new-stageuser-commands-activate-prov.patch >>>>>>> * 0006-User-life-cycle-user-del-supports-permanently-preser.patch >>>>>>> * 0008-User-life-cycle-user-find-support-finding-delete-use.patch >>>>>>> * 0009-User-life-cycle-support-of-user-undel.patch >>>>>>> * 0010-User-life-cycle-DNA-DS-plugin-should-exclude-provisi.patch >>>>>>> * 0011-User-life-cycle-lockout-provisioning-stage-and-delet.patch >>>>>>> * 0012-User-life-cycle-Create-stage-Admin-provisioning-acco.patch >>>>>>> * 0013-User-life-cycle-Stage-Admin-permission-priviledge.patch >>>>>>> >>>>>>> Thanks >>>>>>> thierry >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Hi Thierry, >>>>>> thanks for the patch, the code looks good to me but there is >>>>>> probably >>>>>> a bug in ACIs. >>>>>> After creating a stage user and setting password for him I can kinit >>>>>> as the stage user. I'm unable to login to the IPA client and id >>>>>> command for this stage user responds "no such user" but I can kinit >>>>>> and invoke ipa commands. >>>>>> >>>>>> Steps: >>>>>> 0. build freeipa with your patch >>>>>> 1. # ipa-server-install >>>>>> 2. $ kinit admin >>>>>> 3. $ ipa stageuser-add suser0 --first Stage --last User --password >>>>>> 4. $ kdestroy >>>>>> 5. $ kinit suser0 >>>>>> 6. $ ipa user-find >>>>>> >>>>>> Actual: >>>>>> Prints out list of ipa users. >>>>>> >>>>>> Expected: >>>>>> kinit fails with "suser0 at ... not found in Kerberos database" >>>>>> >>>>> Hi David, >>>>> >>>>> Thank you so much for having looked at this patch :-) >>>>> You are right. The Staging users (as well as the Delete users) are >>>>> not >>>>> lockout in that patch. >>>>> The patch >>>>> 0011-User-life-cycle-lockout-provisioning-stage-and-delet.patch will >>>>> take care of this. >>>>> >>>>> Do you prefer that I merged the two patches right now ? >>>>> >>>>> thanks >>>>> thierry >>>>> >>>> >>>> Hi Thierry, >>>> no, it is not necessary to merge the patches it's ok to have it >>>> separated. I'm not sure if the patch should be pushed now or rather >>>> wait and push it together with the others. >>>> I'm looking forward to next ULC patches from you. >>>> >>> >>> >>> Hi David, >>> >>> Here are all the available patches. >>> I also attach a test script that is a kind of regression tests that >>> I am >>> using. >>> >>> Thanks again >>> thierry >>> >>> >> >> Some issues I have found during a quick read of the patches: >> >> >> Patch 0005: >> >> 1) This does nothing and can be safely removed: >> >> + def pre_callback(self, ldap, dn, *keys, **options): >> + assert isinstance(dn, DN) >> + return dn >> >> >> 2) stageuser_{mod,find,show} have a lot of code that seems to be >> copy-pasted from user_{mod,find,show}. I would prefer if the code was >> shared instead of copy-pasted, preferably in baseuser_{mod,find,show}. >> >> >> Patch 0006: >> >> 1) These do nothing and can be safely removed: >> >> + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, >> **options): >> + assert isinstance(dn, DN) >> + return dn >> + >> + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): >> + assert isinstance(dn, DN) >> + return dn >> >> >> 2) You should use output.standard_entry for has_output, as you are >> only returning one entry. Or you could add support for activating >> multiple users at once. >> >> >> 3) IMO the "time to build the new entry" and "add the active entry" >> parts should be done by calling user-add, so that the (active) user >> creation routine is the same. >> >> >> 4) Please use a single line to separate method definitions in classes. >> >> >> Patch 008: >> >> 1) I guess you forgot to remove these: >> >> + self.log.error("====> user-add pre_callback 1 %s " % dn) >> >> + self.log.error("====> user-add pre_callback %s " % dn) >> >> >> 2) >> >> + takes_options = LDAPDelete.takes_options + ( >> >> This should be "baseuser_del.takes_options + ...". >> >> >> Honza >> > > Hello, > > This is the set of revisited patches for ULC. Here are the changes > done versus the previous patches > > Patch 0005: > > Refactoring stageuser+user => baseuser > > > Patch 0006: > > Lock stage/delete users, add activated user into ipausers, > stageuser-activate process a single entry > > > Patch 0007 > > Refactoring stageuser+user => baseuser, GID number lost > during activation > > Patch 0008 > > user take_options from baseuser_del rather than LDAPDelete > > Patch 0009 > > Refactoring stageuser+user => baseuser, remove debug traces > > Patch 0010 > > Refactoring stageuser+user => baseuser,, add undelete user > into ipausers > > Patch 0011 (previous patch 0011 was merged in Patch 0006: > lockout stage/delete users) > > Change due to CSV > > Patch 0012 > > Change due to CSV, permission tests > > It does not take into account your request Honza to use 'user-add' > command when activating a user. > I will work on that now and submit an other patch later for that. > > Thanks > thierry > > > > > IPA_API_VERSION_MINOR was invalid in the first patch 0005. I am sorry for that. Here is the next set of patches. Only patch 0005 differs from my previous email thanks thierry From mkubik at redhat.com Fri May 15 14:50:37 2015 From: mkubik at redhat.com (Milan Kubik) Date: Fri, 15 May 2015 16:50:37 +0200 Subject: [Freeipa-devel] [PATCH] 801-806 webui-ci: otptoken tests In-Reply-To: <5551EAB4.2000803@redhat.com> References: <54E5F888.2000402@redhat.com> <554B4E9F.1070806@redhat.com> <5550919E.9090802@redhat.com> <5551EAB4.2000803@redhat.com> Message-ID: <555607BD.3000704@redhat.com> On 05/12/2015 01:57 PM, Petr Vobornik wrote: > On 05/11/2015 01:25 PM, Milan Kubik wrote: >> On 05/07/2015 01:38 PM, Petr Vobornik wrote: >>> On 02/19/2015 03:51 PM, Petr Vobornik wrote: >>>> https://fedorahosted.org/freeipa/ticket/4307 >>>> >>>> For ipa-4-1 apply: >>>> - patch 800 (different thread) >>>> - patches 801-806 >>>> >>>> For master apply: >>>> - patch 800 (different thread) >>>> - patch 807 (different thread) >>>> - patch 801-master >>>> - patches 802-806 >>>> >>>> Patch 801 allows to use ipalib rpc client in Web UI test suite. >>>> Patches 802-805 are various ui_driver fixes to allow stuff in patch >>>> 806. >>>> >>>> == [PATCH] 806 webui-ci: otptoken tests == >>>> >>>> Basic otptoken Web UI CI coverage. >>>> >>>> tests: >>>> * crud for otptokens as admin >>>> * crud for normal users >>>> * checks fields of adder dialog for both token types and user role >>>> (admin/user) >>>> * token actions as admin (enable, disable, delete) >>>> * token actions as normal user (delete) >>>> * login as normal user with hotp and totp token >>>> * sync token hotp and totp token as normal user and then login >>>> >>>> https://fedorahosted.org/freeipa/ticket/4307 >>>> >>>> == [PATCH] 805 webui-ci: allow custom names for disable/enable >>>> actions == >>>> >>>> Not all disable and enable actions are called 'disable' and 'enable'. >>>> >>>> == [PATCH] 804 webui-ci: allow to update pkey in post-add in >>>> basic-crud >>>> tests == >>>> >>>> == [PATCH] 803 webui-ci: add post_add_action == >>>> >>>> post add action allows to fill autogenerated values, e.g. a pkey of >>>> new >>>> otptoken. >>>> >>>> This value can be then used in other subsequent test which would >>>> depend >>>> on it - like crud tests. >>>> >>>> == [PATCH] 802 webui-ci: fix negative visibility check == >>>> >>>> Allow to define, that element doesn't have to be present on a page for >>>> negative visible checks. >>>> >>>> E.g. if element is added only if it's displayed and is removed >>>> otherwise. >>>> >>>> == [PATCH] 801 webui-ci: support direct IPA API calls == >>>> >>>> Add IPA API support to ui_driver. It leverages new ipalib RPC client's >>>> forms based authentication. It then allows to call an IPA API while >>>> the machine is not an IPA client nor is kerberized. >>>> >>>> api's environment values are taken from test configuration and >>>> therefore duplication in ~/.ipa/default.conf is not required. >>>> >>>> Since the machine doesn't have to be IPA client, it then also doesn't >>>> have nss database with IPA's CA certificate. Therefore on each API >>>> initialization a new NSS database is created with a CA certificate >>>> downloaded from IPA. This db is deleted in tearDown phase. >>>> >>>> Usage: >>>> >>>> 1. as admin one can immediately call rpc commands, api will be >>>> initialized upon first request and is available under self.api >>>> (assuming self is ui_driver): >>>> self.api.Command.user_del(USER_ID, **{'continue': True}) >>>> >>>> 2. to reconnect as other user: >>>> self.reconnect_api(USER_ID, USER_PW) >>>> >>>> 3. reconnect back as admin: >>>> self.reconnect_api() >>>> >>> >>> Patch #803 needed rebase. >>> >>> >> Hi, thanks for the patches. >> >> Please, fix pep8 complaints in 803, 805 and 806. > > > $ git diff HEAD~6 -U0 | pep8 --diff > > returns 20x E501 line too long > > IMO, it's better this way for better code readability. > > >> Also, change the header in 806 to the shorter version, please. > > Fixed, patches were regenerated. > >> >> # >> # Copyright (C) 2015 FreeIPA Contributors see COPYING for license >> # >> >> Patches 801, 802 and 804 look good to me. >> The test cases in 806 look good to me as well. >> >> Milan >> I have reviewed the pep8 complaints closely and yes, readability would suffer a little. I don't like the line 317 after patch 806. Fix it at your discretion. Otherwise ACK. Thanks, Milan From dkupka at redhat.com Fri May 15 15:38:01 2015 From: dkupka at redhat.com (David Kupka) Date: Fri, 15 May 2015 17:38:01 +0200 Subject: [Freeipa-devel] [PATCH] 832-850 Stage Users Web UI and its prerequisites In-Reply-To: <5555CBB3.1060003@redhat.com> References: <5555B58D.8010804@redhat.com> <5555CBB3.1060003@redhat.com> Message-ID: <555612D9.3020306@redhat.com> 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. -- David Kupka From pspacek at redhat.com Fri May 15 16:11:57 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 15 May 2015 18:11:57 +0200 Subject: [Freeipa-devel] [PATCHES 0233-0234] DNSSEC: forwarders validation In-Reply-To: <554B8F01.9010501@redhat.com> References: <553A3D88.6080200@redhat.com> <55423032.9080505@redhat.com> <5548BED1.1060806@redhat.com> <554A1539.3040002@redhat.com> <554B0D69.5040008@redhat.com> <554B3C19.9080002@redhat.com> <554B8F01.9010501@redhat.com> Message-ID: <55561ACD.6070306@redhat.com> On 7.5.2015 18:12, Martin Basti wrote: > On 07/05/15 12:19, Petr Spacek wrote: >> On 7.5.2015 08:59, David Kupka wrote: >>> On 05/06/2015 03:20 PM, Martin Basti wrote: >>>> On 05/05/15 15:00, Martin Basti wrote: >>>>> On 30/04/15 15:37, David Kupka wrote: >>>>>> On 04/24/2015 02:56 PM, Martin Basti wrote: >>>>>>> Patches attached. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Hi, >>>>>> thanks for patches. >>>>>> >>>>>> 1. You changed message in DNSServerNotRespondingWarning class but not >>>>>> the test in ipatest/test_xmlrpc/test_dns_plugin.py >>>>>> >>>>>> nitpick. Please spell 'edns' correctly. I've seen several instances >>>>>> of 'ends'. >>>>>> >>>>> Thank you, >>>>> >>>>> updated patches attached: >>>>> * new error messages >>>>> * logging to debug log server output if exception was raised >>>>> * fixed test >>>>> * fixed spelling >>>>> >>>>> >>>>> >>>> Fixed tests (again) >>>> >>>> Updated patches attached >>>> >>> The code looks good to me and tests are no longer broken. (I would prefer >>> better fix of the tests but given that the priorities are different now it can >>> wait.) >>> >>> Petr, can you please confirm that the patch set works for you? >> Sorry, NACK: >> >> $ ipa dnsforwardzone-add ptr.test. --forwarder=10.34.47.236 >> Server will check DNS forwarder(s). >> This may take some time, please wait ... >> ipa: ERROR: an internal error has occurred >> >> # /var/log/httpd/error_log >> ipa: ERROR: non-public: AssertionError: >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 350, in >> wsgi_execute >> result = self.Command[name](*args, **options) >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 443, in >> __call__ >> ret = self.run(*args, **options) >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 760, in run >> return self.execute(*args, **options) >> File "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 4444, in >> execute >> **options) >> File "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 4405, in >> _warning_if_forwarders_do_not_work >> log=self.log) >> File "/usr/lib/python2.7/site-packages/ipalib/util.py", line 715, in >> validate_dnssec_zone_forwarder_step2 >> timeout=timeout) >> File "/usr/lib/python2.7/site-packages/ipalib/util.py", line 610, in >> _resolve_record >> assert isinstance(nameserver_ip, basestring) >> AssertionError >> ipa: INFO: [jsonserver_session] admin at IPA.EXAMPLE: dnsforwardzone_add(> name ptr.test.>, idnsforwarders=(u'10.34.47.236',), all=False, raw=False, >> version=u'2.116'): AssertionError >> >> This is constantly reproducible in my vm-090.abc. Let me know if you want to >> take a look. >> >> >> I'm attaching little response.patch which improves compatibility with older >> python-dns packages. This patch allows IPA to work while error messages are >> simply not as nice as they could be with latest python-dns :-) >> >> check_fwd_msg.patch is a little nitpick, just to make sure everyone >> understands the message. >> >> BTW why some messages in check_forwarders() are printed using 'print' and >> others using logger? I would prefer to use logger for everything to make sure >> that logs contain all the information, including warnings. >> >> Thank you for your time! >> > Thank you, fixed. > > I added missing except block after forwarders validation step2. I confirm that this works but I just discovered another deficiency. Setup: - DNSSEC validation is enabled on IPA server - forwarders uses fake TLD, e.g. 'test.' - remote DNS server is responding, supports EDNS0 and so on $ ipa dnsforwardzone-add ptr.test. --forwarder=10.34.47.236 Server will check DNS forwarder(s). This may take some time, please wait ... ipa: WARNING: DNS server 10.34.78.90: query 'ptr.test. SOA': The DNS query name does not exist: ptr.test.. Huh? Let's check named log: forward zone 'ptr.test': loaded validating ./SOA: got insecure response; parent indicates it should be secure Sometimes I get SERVFAIL from IPA server, too. Unfortunately this check was the main reason for writing this patchset so we need to improve it. Maybe validate_dnssec_zone_forwarder_step2() could special-case NXDOMAIN and print the DNSSEC-validation-failed error, too? The problem is that it could trigger some false positives because NXDOMAIN may simply be caused by a delay somewhere. Any ideas? By the way, this is also weird: $ ipa dnsforwardzone-add ptr.test. --forwarder=10.34.47.236 Server will check DNS forwarder(s). This may take some time, please wait ... ipa: ERROR: DNS forward zone with name "ptr.test." already exists Is it actually doing the check even if the forward zone exists already? (This is just nitpick, not a blocker!) -- Petr^2 Spacek From mkosek at redhat.com Mon May 18 07:49:51 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 18 May 2015 09:49:51 +0200 Subject: [Freeipa-devel] [PATCH] 0005 User life cycle: del/mod/find/show stageuser commands In-Reply-To: <205373726.22060212.1431701099532.JavaMail.zimbra@redhat.com> References: <552F964E.2060304@redhat.com> <553F437D.5080103@redhat.com> <553F44B7.6040100@redhat.com> <553F476E.8080502@redhat.com> <553F9BCE.6010000@redhat.com> <554869C3.2040509@redhat.com> <5551EF3E.1060503@redhat.com> <555216B9.1070106@redhat.com> <205373726.22060212.1431701099532.JavaMail.zimbra@redhat.com> Message-ID: <5559999F.2070507@redhat.com> On 05/15/2015 04:44 PM, David Kupka wrote: > Hello Thierry, > thanks for the patch set. Overall functionality of ULC feature looks good to > me and is definitely "alpha ready". > > I found following issues but don't insist on fixing it right now: Given we are now only fixing bugs and not doing big structural changes, I would rather like to push what we have and then work on fixing the bugs that are critical for the feature. Some may be before Alpha, some after Alpha or even 4.2.1 or later versions - depending on the impact. > 1) When stageuser-activate fails due to already existent active/deleted user. > DN is show instead of user name that's used in other commands (user-add, > stageuser-add). > $ ipa user-add tuser --first Test --last User > $ ipa stageuser-add tuser --first Test --last User > $ ipa stageuser-activate tuser > ipa: ERROR: Active user > uid=tuser,cn=users,cn=accounts,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com > already exists Please file ticket, can be fixed in 4.2.1 or later IMO. > > 2) According to the design there should be '--only-delete' and '--also-delete' > options for user-find command instead there is '--preserved' option. > Honza proposed adding virtual boolean attribute 'deleted' to user entry and > filter on it. > The 'deleted' attribute would be useful also in user-show where is no way to > tell if the displayed user is active or deleted. (Except running with --all > and looking on the dn). Please file ticket as well. As I talked to David, it is now difficult to distinguish between active and deleted users, user-show USER shows the user regardless if the user is active or deleted. This is something we should discuss, what is the ideal behavior. Please include this question in the ticket. > 3) uidNumber and gidNumber can't be set back to '-1' once set to other value. > This would be useful when admin changes its mind and want IPA to assign them. > IIUC, there should be no validation in cn=staged user container. All > validation should be done during stageuser-activate. We may want with filing a ticket unless there is a real demand for this. > 4) Support for deleted -> stage workflow is still missing. But I'm unsure if we > agreed to finish it now or later. We wanted to do it also, but based on Thierry's availability, it can be done post-Alpha or even 4.2.1. > 5) Twice deleting user with '--preserve' deletes him permanently. > $ ipa user-add tuser --first Test --last User > $ ipa user-del tuser --preserve > $ ipa user-del tuser --preserve > $ ipa user-find --preserved > ------------------------ > 0 (delete) users matched > ------------------------ > ---------------------------- > Number of entries returned 0 > ---------------------------- This looks as something we may want to fix before GA. Pushed to master: 273fd057a3be797a05d6c7f34fd619d3dfa09c37 When the UI (on review) is also pushed, we will have the base ULC functionality here and we can close the main RFE. Thanks everyone! Martin From tbordaz at redhat.com Mon May 18 08:33:33 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Mon, 18 May 2015 10:33:33 +0200 Subject: [Freeipa-devel] [PATCH] 0005 User life cycle: del/mod/find/show stageuser commands In-Reply-To: <205373726.22060212.1431701099532.JavaMail.zimbra@redhat.com> References: <552F964E.2060304@redhat.com> <553F437D.5080103@redhat.com> <553F44B7.6040100@redhat.com> <553F476E.8080502@redhat.com> <553F9BCE.6010000@redhat.com> <554869C3.2040509@redhat.com> <5551EF3E.1060503@redhat.com> <555216B9.1070106@redhat.com> <205373726.22060212.1431701099532.JavaMail.zimbra@redhat.com> Message-ID: <5559A3DD.7030002@redhat.com> On 05/15/2015 04:44 PM, David Kupka wrote: > Hello Thierry, > thanks for the patch set. Overall functionality of ULC feature looks good to > me and is definitely "alpha ready". > > I found following issues but don't insist on fixing it right now: > > 1) When stageuser-activate fails due to already existent active/deleted user. > DN is show instead of user name that's used in other commands (user-add, > stageuser-add). > $ ipa user-add tuser --first Test --last User > $ ipa stageuser-add tuser --first Test --last User > $ ipa stageuser-activate tuser > ipa: ERROR: Active user > uid=tuser,cn=users,cn=accounts,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com > already exists Hi David, Jan, Thanks you so much for all those tests and feedback. I agree, some minor bugs can be fixed separatly from this main patches. You are right, It should return the user ID not the DN. > > 2) According to the design there should be '--only-delete' and '--also-delete' > options for user-find command instead there is '--preserved' option. > Honza proposed adding virtual boolean attribute 'deleted' to user entry and > filter on it. > The 'deleted' attribute would be useful also in user-show where is no way to > tell if the displayed user is active or deleted. (Except running with --all > and looking on the dn). Yes a bit late to resynch the design. The final option is 'preserved' for user-find and 'preserve' for user-del. '--only-delete' or 'also-delete' are old name that I need to replace in the design. About the 'deleted' attribute, do you think adding a DS cos virtual attribute ? > > 3) uidNumber and gidNumber can't be set back to '-1' once set to other value. > This would be useful when admin changes its mind and want IPA to assign them. > IIUC, there should be no validation in cn=staged user container. All > validation should be done during stageuser-activate. Yes that comes from user plugin that enforce the number to be >0. That is a good point giving the ability to reset uidNumber/gidNumber. I will check if it is possible, how (give a value or an option to reset), and also if it would not create other issue. > > 4) Support for deleted -> stage workflow is still missing. But I'm unsure if we > agreed to finish it now or later. Yes thanks > > 5) Twice deleting user with '--preserve' deletes him permanently. > $ ipa user-add tuser --first Test --last User > $ ipa user-del tuser --preserve > $ ipa user-del tuser --preserve > $ ipa user-find --preserved > ------------------------ > 0 (delete) users matched > ------------------------ > ---------------------------- > Number of entries returned 0 > ---------------------------- Deleting a deleted (preserved) entry, should permanently remove the entry. Now if the second time the preserve option is present, it makes sense to not delete it. thanks theirry > > David > > ----- Original Message ----- > From: "thierry bordaz" > To: "Jan Cholasta" , "David Kupka" > Cc: "freeipa-devel" > Sent: Tuesday, May 12, 2015 5:05:29 PM > Subject: Re: [Freeipa-devel] [PATCH] 0005 User life cycle: del/mod/find/show stageuser commands > > On 05/12/2015 02:17 PM, thierry bordaz wrote: >> On 05/05/2015 08:57 AM, Jan Cholasta wrote: >>> Hi, >>> >>> Dne 28.4.2015 v 16:40 thierry bordaz napsal(a): >>>> On 04/28/2015 10:40 AM, David Kupka wrote: >>>>> On 04/28/2015 10:28 AM, thierry bordaz wrote: >>>>>> On 04/28/2015 10:23 AM, David Kupka wrote: >>>>>>> On 04/16/2015 01:00 PM, thierry bordaz wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Here is the next patch for User life cycle that introduces >>>>>>>> del/mod/find and show stageuser plugin commands. >>>>>>>> >>>>>>>> * 0000-User Life Cycle (create containers and scoping DS >>>>>>>> plugins): >>>>>>>> *pushed* >>>>>>>> * >>>>>>>> 0001-User-Life-Cycle-Exclude-subtree-for-ipaUniqueID-gene.patch: >>>>>>>> *pushed* >>>>>>>> * 0002-User-life-cycle-stageuser-add-verb.patch: *pushed* >>>>>>>> * 0007-User-life-cycle-allows-MODRDN-from-ldap2.patch: *pushed* >>>>>>>> * 0003-User-life-cycle-new-stageuser-commands-del-mod-find-*under >>>>>>>> review *(this one)** >>>>>>>> * 0004-User-life-cycle-new-stageuser-commands-activate.patch >>>>>>>> * 0005-User-life-cycle-new-stageuser-commands-activate-prov.patch >>>>>>>> * 0006-User-life-cycle-user-del-supports-permanently-preser.patch >>>>>>>> * 0008-User-life-cycle-user-find-support-finding-delete-use.patch >>>>>>>> * 0009-User-life-cycle-support-of-user-undel.patch >>>>>>>> * 0010-User-life-cycle-DNA-DS-plugin-should-exclude-provisi.patch >>>>>>>> * 0011-User-life-cycle-lockout-provisioning-stage-and-delet.patch >>>>>>>> * 0012-User-life-cycle-Create-stage-Admin-provisioning-acco.patch >>>>>>>> * 0013-User-life-cycle-Stage-Admin-permission-priviledge.patch >>>>>>>> >>>>>>>> Thanks >>>>>>>> thierry >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Hi Thierry, >>>>>>> thanks for the patch, the code looks good to me but there is >>>>>>> probably >>>>>>> a bug in ACIs. >>>>>>> After creating a stage user and setting password for him I can kinit >>>>>>> as the stage user. I'm unable to login to the IPA client and id >>>>>>> command for this stage user responds "no such user" but I can kinit >>>>>>> and invoke ipa commands. >>>>>>> >>>>>>> Steps: >>>>>>> 0. build freeipa with your patch >>>>>>> 1. # ipa-server-install >>>>>>> 2. $ kinit admin >>>>>>> 3. $ ipa stageuser-add suser0 --first Stage --last User --password >>>>>>> 4. $ kdestroy >>>>>>> 5. $ kinit suser0 >>>>>>> 6. $ ipa user-find >>>>>>> >>>>>>> Actual: >>>>>>> Prints out list of ipa users. >>>>>>> >>>>>>> Expected: >>>>>>> kinit fails with "suser0 at ... not found in Kerberos database" >>>>>>> >>>>>> Hi David, >>>>>> >>>>>> Thank you so much for having looked at this patch :-) >>>>>> You are right. The Staging users (as well as the Delete users) are >>>>>> not >>>>>> lockout in that patch. >>>>>> The patch >>>>>> 0011-User-life-cycle-lockout-provisioning-stage-and-delet.patch will >>>>>> take care of this. >>>>>> >>>>>> Do you prefer that I merged the two patches right now ? >>>>>> >>>>>> thanks >>>>>> thierry >>>>>> >>>>> Hi Thierry, >>>>> no, it is not necessary to merge the patches it's ok to have it >>>>> separated. I'm not sure if the patch should be pushed now or rather >>>>> wait and push it together with the others. >>>>> I'm looking forward to next ULC patches from you. >>>>> >>>> >>>> Hi David, >>>> >>>> Here are all the available patches. >>>> I also attach a test script that is a kind of regression tests that >>>> I am >>>> using. >>>> >>>> Thanks again >>>> thierry >>>> >>>> >>> Some issues I have found during a quick read of the patches: >>> >>> >>> Patch 0005: >>> >>> 1) This does nothing and can be safely removed: >>> >>> + def pre_callback(self, ldap, dn, *keys, **options): >>> + assert isinstance(dn, DN) >>> + return dn >>> >>> >>> 2) stageuser_{mod,find,show} have a lot of code that seems to be >>> copy-pasted from user_{mod,find,show}. I would prefer if the code was >>> shared instead of copy-pasted, preferably in baseuser_{mod,find,show}. >>> >>> >>> Patch 0006: >>> >>> 1) These do nothing and can be safely removed: >>> >>> + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, >>> **options): >>> + assert isinstance(dn, DN) >>> + return dn >>> + >>> + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): >>> + assert isinstance(dn, DN) >>> + return dn >>> >>> >>> 2) You should use output.standard_entry for has_output, as you are >>> only returning one entry. Or you could add support for activating >>> multiple users at once. >>> >>> >>> 3) IMO the "time to build the new entry" and "add the active entry" >>> parts should be done by calling user-add, so that the (active) user >>> creation routine is the same. >>> >>> >>> 4) Please use a single line to separate method definitions in classes. >>> >>> >>> Patch 008: >>> >>> 1) I guess you forgot to remove these: >>> >>> + self.log.error("====> user-add pre_callback 1 %s " % dn) >>> >>> + self.log.error("====> user-add pre_callback %s " % dn) >>> >>> >>> 2) >>> >>> + takes_options = LDAPDelete.takes_options + ( >>> >>> This should be "baseuser_del.takes_options + ...". >>> >>> >>> Honza >>> >> Hello, >> >> This is the set of revisited patches for ULC. Here are the changes >> done versus the previous patches >> >> Patch 0005: >> >> Refactoring stageuser+user => baseuser >> >> >> Patch 0006: >> >> Lock stage/delete users, add activated user into ipausers, >> stageuser-activate process a single entry >> >> >> Patch 0007 >> >> Refactoring stageuser+user => baseuser, GID number lost >> during activation >> >> Patch 0008 >> >> user take_options from baseuser_del rather than LDAPDelete >> >> Patch 0009 >> >> Refactoring stageuser+user => baseuser, remove debug traces >> >> Patch 0010 >> >> Refactoring stageuser+user => baseuser,, add undelete user >> into ipausers >> >> Patch 0011 (previous patch 0011 was merged in Patch 0006: >> lockout stage/delete users) >> >> Change due to CSV >> >> Patch 0012 >> >> Change due to CSV, permission tests >> >> It does not take into account your request Honza to use 'user-add' >> command when activating a user. >> I will work on that now and submit an other patch later for that. >> >> Thanks >> thierry >> >> >> >> >> > IPA_API_VERSION_MINOR was invalid in the first patch 0005. I am sorry > for that. > > Here is the next set of patches. Only patch 0005 differs from my > previous email > > thanks > thierry From mkosek at redhat.com Mon May 18 09:51:41 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 18 May 2015 11:51:41 +0200 Subject: [Freeipa-devel] Revoking user/service/host certificates Message-ID: <5559B62D.4030106@redhat.com> Hi Fraser (and list), Recently, we have proposed 2 new policies for treating user/host/service certificates based on the per-profile policy: a) If certificate is stored in userCertificate attribute b) If the certificate is stored and object deleted/disabled, if the certificate should be also revoked Details in: http://www.freeipa.org/page/V4/User_Certificates#Configuration a) is straightforward. However, I was not thinking more about case b). When object is deleted/disabled, how will framework tell what is the profile to check the policy? Will it ask Dogtag via some API call? Or will the profile me stored in the certificate itself, just like MS CA does for some certificates? Thanks. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From mbasti at redhat.com Mon May 18 11:48:33 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 18 May 2015 13:48:33 +0200 Subject: [Freeipa-devel] [PATCHES 0233-0234] DNSSEC: forwarders validation In-Reply-To: <55561ACD.6070306@redhat.com> References: <553A3D88.6080200@redhat.com> <55423032.9080505@redhat.com> <5548BED1.1060806@redhat.com> <554A1539.3040002@redhat.com> <554B0D69.5040008@redhat.com> <554B3C19.9080002@redhat.com> <554B8F01.9010501@redhat.com> <55561ACD.6070306@redhat.com> Message-ID: <5559D191.4070406@redhat.com> On 15/05/15 18:11, Petr Spacek wrote: > On 7.5.2015 18:12, Martin Basti wrote: >> On 07/05/15 12:19, Petr Spacek wrote: >>> On 7.5.2015 08:59, David Kupka wrote: >>>> On 05/06/2015 03:20 PM, Martin Basti wrote: >>>>> On 05/05/15 15:00, Martin Basti wrote: >>>>>> On 30/04/15 15:37, David Kupka wrote: >>>>>>> On 04/24/2015 02:56 PM, Martin Basti wrote: >>>>>>>> Patches attached. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Hi, >>>>>>> thanks for patches. >>>>>>> >>>>>>> 1. You changed message in DNSServerNotRespondingWarning class but not >>>>>>> the test in ipatest/test_xmlrpc/test_dns_plugin.py >>>>>>> >>>>>>> nitpick. Please spell 'edns' correctly. I've seen several instances >>>>>>> of 'ends'. >>>>>>> >>>>>> Thank you, >>>>>> >>>>>> updated patches attached: >>>>>> * new error messages >>>>>> * logging to debug log server output if exception was raised >>>>>> * fixed test >>>>>> * fixed spelling >>>>>> >>>>>> >>>>>> >>>>> Fixed tests (again) >>>>> >>>>> Updated patches attached >>>>> >>>> The code looks good to me and tests are no longer broken. (I would prefer >>>> better fix of the tests but given that the priorities are different now it can >>>> wait.) >>>> >>>> Petr, can you please confirm that the patch set works for you? >>> Sorry, NACK: >>> >>> $ ipa dnsforwardzone-add ptr.test. --forwarder=10.34.47.236 >>> Server will check DNS forwarder(s). >>> This may take some time, please wait ... >>> ipa: ERROR: an internal error has occurred >>> >>> # /var/log/httpd/error_log >>> ipa: ERROR: non-public: AssertionError: >>> Traceback (most recent call last): >>> File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 350, in >>> wsgi_execute >>> result = self.Command[name](*args, **options) >>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 443, in >>> __call__ >>> ret = self.run(*args, **options) >>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 760, in run >>> return self.execute(*args, **options) >>> File "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 4444, in >>> execute >>> **options) >>> File "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 4405, in >>> _warning_if_forwarders_do_not_work >>> log=self.log) >>> File "/usr/lib/python2.7/site-packages/ipalib/util.py", line 715, in >>> validate_dnssec_zone_forwarder_step2 >>> timeout=timeout) >>> File "/usr/lib/python2.7/site-packages/ipalib/util.py", line 610, in >>> _resolve_record >>> assert isinstance(nameserver_ip, basestring) >>> AssertionError >>> ipa: INFO: [jsonserver_session] admin at IPA.EXAMPLE: dnsforwardzone_add(>> name ptr.test.>, idnsforwarders=(u'10.34.47.236',), all=False, raw=False, >>> version=u'2.116'): AssertionError >>> >>> This is constantly reproducible in my vm-090.abc. Let me know if you want to >>> take a look. >>> >>> >>> I'm attaching little response.patch which improves compatibility with older >>> python-dns packages. This patch allows IPA to work while error messages are >>> simply not as nice as they could be with latest python-dns :-) >>> >>> check_fwd_msg.patch is a little nitpick, just to make sure everyone >>> understands the message. >>> >>> BTW why some messages in check_forwarders() are printed using 'print' and >>> others using logger? I would prefer to use logger for everything to make sure >>> that logs contain all the information, including warnings. >>> >>> Thank you for your time! >>> >> Thank you, fixed. >> >> I added missing except block after forwarders validation step2. > I confirm that this works but I just discovered another deficiency. > > Setup: > - DNSSEC validation is enabled on IPA server > - forwarders uses fake TLD, e.g. 'test.' > - remote DNS server is responding, supports EDNS0 and so on > > $ ipa dnsforwardzone-add ptr.test. --forwarder=10.34.47.236 > Server will check DNS forwarder(s). > This may take some time, please wait ... > ipa: WARNING: DNS server 10.34.78.90: query 'ptr.test. SOA': The DNS query > name does not exist: ptr.test.. > > Huh? Let's check named log: > forward zone 'ptr.test': loaded > validating ./SOA: got insecure response; parent indicates it should be secure > > Sometimes I get SERVFAIL from IPA server, too. > > > Unfortunately this check was the main reason for writing this patchset so we > need to improve it. > > Maybe validate_dnssec_zone_forwarder_step2() could special-case NXDOMAIN and > print the DNSSEC-validation-failed error, too? The problem is that it could > trigger some false positives because NXDOMAIN may simply be caused by a delay > somewhere. > > Any ideas? I add catch block for NXDOMAIN > > By the way, this is also weird: > > $ ipa dnsforwardzone-add ptr.test. --forwarder=10.34.47.236 > Server will check DNS forwarder(s). > This may take some time, please wait ... > ipa: ERROR: DNS forward zone with name "ptr.test." already exists > > Is it actually doing the check even if the forward zone exists already? (This > is just nitpick, not a blocker!) > The first part is written by IPA client, it is not response from server. It is just written when user use --forwarder option. Updated patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0233.5-DNSSEC-Improve-global-forwarders-validation.patch Type: text/x-patch Size: 16323 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0234.5-DNSSEC-validate-forward-zone-forwarders.patch Type: text/x-patch Size: 17608 bytes Desc: not available URL: From lkrispen at redhat.com Mon May 18 12:51:33 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Mon, 18 May 2015 14:51:33 +0200 Subject: [Freeipa-devel] ipa wiki formatting Message-ID: <5559E055.8050408@redhat.com> Hi, for our docs on the wiki there is a table of contents, which is created from the section headers an the sections in the table of contents are automatically numbered, eg 1. first chapter 1.1 subchapter 1.2 next sub 2. second but in the body of the document these numbers are not there by default, so when scrolling thru a larger document the level of a chapter is lost. There are two options to change this - change your user profile to keep the numbering in the document body - change the site profile, so that the numbering is always preserverd (can probably induvidually turne off again). Does anyone oppose to change the default ? Ludwig From pspacek at redhat.com Mon May 18 12:53:16 2015 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 18 May 2015 14:53:16 +0200 Subject: [Freeipa-devel] [PATCH 0365-0366] Fix nits from static code analysis Message-ID: <5559E0BC.2090400@redhat.com> Hello, fixes were pushed to master: 98808c79ff3ce96f7ddb80525d4b1968826276c7 be242e95cd25b117d3e90e583103911128a33dab -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0365-Remove-dead-code-from-sync_ptr_validate.patch Type: text/x-patch Size: 1001 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0366-Silence-warning-about-dead-assignment.patch Type: text/x-patch Size: 839 bytes Desc: not available URL: From ftweedal at redhat.com Mon May 18 13:36:09 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 18 May 2015 23:36:09 +1000 Subject: [Freeipa-devel] Revoking user/service/host certificates In-Reply-To: <5559B62D.4030106@redhat.com> References: <5559B62D.4030106@redhat.com> Message-ID: <20150518133609.GY12806@dhcp-40-8.bne.redhat.com> On Mon, May 18, 2015 at 11:51:41AM +0200, Martin Kosek wrote: > Hi Fraser (and list), > > Recently, we have proposed 2 new policies for treating user/host/service > certificates based on the per-profile policy: > > a) If certificate is stored in userCertificate attribute > b) If the certificate is stored and object deleted/disabled, if the certificate > should be also revoked > > Details in: > http://www.freeipa.org/page/V4/User_Certificates#Configuration > > a) is straightforward. However, I was not thinking more about case b). When > object is deleted/disabled, how will framework tell what is the profile to > check the policy? > > Will it ask Dogtag via some API call? Or will the profile me stored in the > certificate itself, just like MS CA does for some certificates? > That information is stored in Dogtag, but I don't think there's currently a straightforward way to get at it. Having it stored in Dogtag (only) would necessitate first contacting Dogtag and looking up the profile for each certificate to find out whether we should revoke or not. I do not think we should implement anything that relies on the MS "certificate template" extension (in case it is not wanted, or even causes problems for some application). But let us take a step back - is there a situation where for one profile (for which ipaCertProfileStoreIssued == True) we would want to automatically revoke when principal deleted, and for another profile not revoke? Or would it be better as a global setting or a {user,host,service}-del option? We would also need to work out a revocationReason; we could use "unspecified" to start with, but can we / should be provide something richer? Cheers, Fraser > Thanks. > > -- > Martin Kosek > Supervisor, Software Engineering - Identity Management Team > Red Hat Inc. From pvoborni at redhat.com Mon May 18 13:40:53 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 18 May 2015 15:40:53 +0200 Subject: [Freeipa-devel] [PATCH] 851-852 webui: datetime widget with datepicker Message-ID: <5559EBE5.3060502@redhat.com> 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 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0852-webui-datetime-widget-with-datepicker.patch Type: text/x-patch Size: 10449 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0851-webui-add-boostrap-datepicker-files.patch Type: text/x-patch Size: 64408 bytes Desc: not available URL: From mkosek at redhat.com Mon May 18 14:13:03 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 18 May 2015 16:13:03 +0200 Subject: [Freeipa-devel] Revoking user/service/host certificates In-Reply-To: <20150518133609.GY12806@dhcp-40-8.bne.redhat.com> References: <5559B62D.4030106@redhat.com> <20150518133609.GY12806@dhcp-40-8.bne.redhat.com> Message-ID: <5559F36F.9070103@redhat.com> On 05/18/2015 03:36 PM, Fraser Tweedale wrote: > On Mon, May 18, 2015 at 11:51:41AM +0200, Martin Kosek wrote: >> Hi Fraser (and list), >> >> Recently, we have proposed 2 new policies for treating user/host/service >> certificates based on the per-profile policy: >> >> a) If certificate is stored in userCertificate attribute >> b) If the certificate is stored and object deleted/disabled, if the certificate >> should be also revoked >> >> Details in: >> http://www.freeipa.org/page/V4/User_Certificates#Configuration >> >> a) is straightforward. However, I was not thinking more about case b). When >> object is deleted/disabled, how will framework tell what is the profile to >> check the policy? >> >> Will it ask Dogtag via some API call? Or will the profile me stored in the >> certificate itself, just like MS CA does for some certificates? >> > That information is stored in Dogtag, but I don't think there's > currently a straightforward way to get at it. Having it stored in > Dogtag (only) would necessitate first contacting Dogtag and looking > up the profile for each certificate to find out whether we should > revoke or not. > > I do not think we should implement anything that relies on the MS > "certificate template" extension (in case it is not wanted, or even > causes problems for some application). I see. > But let us take a step back - is there a situation where for one > profile (for which ipaCertProfileStoreIssued == True) we would want > to automatically revoke when principal deleted, and for another > profile not revoke? Or would it be better as a global setting or a > {user,host,service}-del option? An option would definitely be a good start, if we do not go with the per-profile setting. Simo/Rob/others, what is your opinion here, given there is a big difficulty in implementing per-profile policy for revoking the certificate? Should we instead have a global configuration that would say A) Revoke all certificates in userCertificate attribute (i.e. long term certificates) B) Do not revoke them and have the option to force a change to the behavior? > We would also need to work out a revocationReason; we could use > "unspecified" to start with, but can we / should be provide > something richer? Right now, when service or host is disabled/deleted, we use revocation reason * 4 - superseded Martin > > Cheers, > Fraser > >> Thanks. >> >> -- >> Martin Kosek >> Supervisor, Software Engineering - Identity Management Team >> Red Hat Inc. From mkosek at redhat.com Mon May 18 14:37:14 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 18 May 2015 16:37:14 +0200 Subject: [Freeipa-devel] ipa wiki formatting In-Reply-To: <5559E055.8050408@redhat.com> References: <5559E055.8050408@redhat.com> Message-ID: <5559F91A.7030904@redhat.com> On 05/18/2015 02:51 PM, Ludwig Krispenz wrote: > Hi, > > for our docs on the wiki there is a table of contents, which is created from > the section headers an the sections in the table of contents are automatically > numbered, eg > > 1. first chapter > 1.1 subchapter > 1.2 next sub > 2. second > > but in the body of the document these numbers are not there by default, so when > scrolling thru a larger document the level of a chapter is lost. > There are two options to change this > - change your user profile to keep the numbering in the document body > - change the site profile, so that the numbering is always preserverd (can > probably induvidually turne off again). > > Does anyone oppose to change the default ? I am not sure this is the right question - as no answers would mean we want to do this rather drastic change :-) This is the respective information from Mediawiki side: http://www.mediawiki.org/wiki/Manual:Table_of_contents#Auto-numbering I am personally cautious about just changing the default as this is not a way what big wiki sites use and I was also afraid it would change not only design pages, but also our title page for example, as it uses sections too. From lslebodn at redhat.com Mon May 18 15:10:18 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 18 May 2015 17:10:18 +0200 Subject: [Freeipa-devel] [PATCH 0364] Remove unused files rdlist.c and rdlist.h In-Reply-To: <5555BFFA.2050207@redhat.com> References: <5555BFFA.2050207@redhat.com> Message-ID: <20150518151018.GE16916@mail.corp.redhat.com> 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. >From 274f5ea92866c50c77c59f6dabc64c3bdf162ace Mon Sep 17 00:00:00 2001 >From: Petr Spacek >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 Date: Wed Aug 14 14:41:17 2013 +0200 Use RBTDB instead of internal LDAP cache. make distcheck passed. ACK LS From pspacek at redhat.com Mon May 18 15:31:30 2015 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 18 May 2015 17:31:30 +0200 Subject: [Freeipa-devel] [PATCH 0367] Support unknown record types (RFC 3597) Message-ID: <555A05D2.7000408@redhat.com> Hello, This patch is unrelated to metaDB but it should be merged before alpha, too. Thank you for review! Support unknown record types (RFC 3597). Fallback to generic LDAP attribute "UnknownRecord;TYP256" if attempt to add specific attribute like "URIRecord" failed with LDAP_OBJECT_CLASS_VIOLATION and always delete both attributes like "URIRecord" and "UnknownRecord;TYPE256". https://fedorahosted.org/bind-dyndb-ldap/ticket/157 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0367-Support-unknown-record-types-RFC-3597.patch Type: text/x-patch Size: 15144 bytes Desc: not available URL: From lkrispen at redhat.com Mon May 18 16:05:48 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Mon, 18 May 2015 18:05:48 +0200 Subject: [Freeipa-devel] Fwd: Re: ipa topology command In-Reply-To: <555A09BA.4030908@redhat.com> References: <555A09BA.4030908@redhat.com> Message-ID: <555A0DDC.1080505@redhat.com> Hi, I started this discussion with Petr, but he thinks it should be better discussed here. Ludwig -------- Original Message -------- Subject: Re: ipa topology command Date: Mon, 18 May 2015 17:48:10 +0200 From: Petr Vobornik To: Ludwig Krispenz On 05/18/2015 04:25 PM, Ludwig Krispenz wrote: > Hi, > > when testing I noticed an incompleteness in the topologysegment-mod > function. > A segment can be onedirectional or bidirectional, and with > topologysegment-mod one should be able to modify params of the > corresponding replication agreement(s). In the design I had a concept of > attributename[;left | ;right ] to apply the change to one or both > directions. In the plugin this is implemented, but in the ipa comand it > isn't. I thought it wouldn't matter since in ipa we want to have > replication agreements identical. > But there is one important exception: init ( nsds5beginreplicarefresh ), > which should always be onedirectional. > > Do you have an idea how to simply chnage this ? > > Thanks, > Ludwig This should be probably discussed on the devel list, feel free to resend it there. I'm not sure if I understand the issue correctly. But will try. Subtypes are not widely used in ipalib yet so there might be some dragons. I general an attribute with known subtypes should be handled as multiple distinct attributes(params in ipalib), e.g.,: nsds5beginreplicarefresh;left nsds5beginreplicarefresh;right The main question is for which attributes we should support specifying both direction. Wrt init: I actually didn't know what the attribute was for but after reading [1] I think that this attribute shouldn't be handled as a free-form string attribute because it starts an operation and then displays its status until it finishes. If the plugin updates the attribute with the initialization state then IMHO these are the step we should take (details could be different): 1. create both attributes: Str( 'nsds5beginreplicarefresh;left', cli_name='init-left', label='Left node initialization', doc='Status of initialization of left node', flags=['no_create', 'no_update', 'no_search'], ), Str( 'nsds5beginreplicarefresh;right', cli_name='init-right', label='Right node initialization', doc='Status of initialization of right node', flags=['no_create', 'no_update', 'no_search'], ), The attribute was made read-only so it can't be modified using segment-mod but segment-show would show its status. 2. Create: ipa topologysegment-init SEGMENT 'left'|'right' It would set 'start' to: nsds5beginreplicarefresh;left or nsds5beginreplicarefresh;right This would start the initialization process of the chosen node. 3. Create: ipa topologysegment-stop-init SEGMENT 'left'|'right' It would set 'stop' to: nsds5beginreplicarefresh;left or nsds5beginreplicarefresh;right This would stop the initialization process of the chosen node. An alternative could be `ipa topologysegment-init SEGMENT 'left'|'right' --stop` 4. Examine other nsds5* attributes if they require similar change or a change in accepted values (eg, int for nsds5replicatimeout, on|off for nsds5replicaenabled, ...) Btw, what about nsDS5ReplicaLastInitStart|Status|End attrs, is there a plan to support them by the plugin and management UI? For the alpha, we could go just with bare params and mod command enabled and then add the separate commands later. [1] https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#Replication_Attributes_under_cnReplicationAgreementName_cnreplica_cnsuffixName_cnmapping_tree_cnconfig-nsDS5BeginReplicaRefresh -- Petr Vobornik -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkrispen at redhat.com Mon May 18 16:21:30 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Mon, 18 May 2015 18:21:30 +0200 Subject: [Freeipa-devel] Fwd: Re: ipa topology command In-Reply-To: <555A0DDC.1080505@redhat.com> References: <555A09BA.4030908@redhat.com> <555A0DDC.1080505@redhat.com> Message-ID: <555A118A.9080309@redhat.com> On 05/18/2015 06:05 PM, Ludwig Krispenz wrote: > Hi, > I started this discussion with Petr, but he thinks it should be better > discussed here. > Ludwig > -------- Original Message -------- > Subject: Re: ipa topology command > Date: Mon, 18 May 2015 17:48:10 +0200 > From: Petr Vobornik > To: Ludwig Krispenz > > > > On 05/18/2015 04:25 PM, Ludwig Krispenz wrote: > > Hi, > > > > when testing I noticed an incompleteness in the topologysegment-mod > > function. > > A segment can be onedirectional or bidirectional, and with > > topologysegment-mod one should be able to modify params of the > > corresponding replication agreement(s). In the design I had a concept of > > attributename[;left | ;right ] to apply the change to one or both > > directions. In the plugin this is implemented, but in the ipa comand it > > isn't. I thought it wouldn't matter since in ipa we want to have > > replication agreements identical. > > But there is one important exception: init ( nsds5beginreplicarefresh ), > > which should always be onedirectional. > > > > Do you have an idea how to simply chnage this ? > > > > Thanks, > > Ludwig > > This should be probably discussed on the devel list, feel free to resend > it there. > > I'm not sure if I understand the issue correctly. But will try. > > Subtypes are not widely used in ipalib yet so there might be some > dragons. I general an attribute with known subtypes should be handled as > multiple distinct attributes(params in ipalib), e.g.,: > nsds5beginreplicarefresh;left > nsds5beginreplicarefresh;right ok, for this special attribute it would make sense since initializatiion (refresh should be only in one direction), same is probably true for 'enable'. for other manage attrs, attributename: value should apply to both directions (in a bidirectional segment) attributename;left: value or attributename;right: value should override the settings for one direction, at the moment I don't see a valid use case, but since a bidirectional segment handles two replication agreements, I did at least provide the possibility. But except nsds5beginreplicarefresh I don't think we need to provide this in the first versioj of the ipa command. > > The main question is for which attributes we should support specifying > both direction. > > Wrt init: > I actually didn't know what the attribute was for but after reading [1] > I think that this attribute shouldn't be handled as a free-form string > attribute because it starts an operation and then displays its status > until it finishes. it just updates the attribute of the segment, the modification is replicated to all other servers and the master whom it concerns will start an online init, no automatic monitoring provided. If you want this, we need to extend what status information is mainained in the shared tree. > If the plugin updates the attribute with the > initialization state then IMHO these are the step we should take > (details could be different): > 1. create both attributes: > > Str( > 'nsds5beginreplicarefresh;left', > cli_name='init-left', > label='Left node initialization', > doc='Status of initialization of left node', > flags=['no_create', 'no_update', 'no_search'], > ), > > Str( > 'nsds5beginreplicarefresh;right', > cli_name='init-right', > label='Right node initialization', > doc='Status of initialization of right node', > flags=['no_create', 'no_update', 'no_search'], > ), yes that would do it, maybe init-fromleft or init-from-right would be clearer > > The attribute was made read-only so it can't be modified using > segment-mod but segment-show would show its status. what do you mean by was made read-only ? > > 2. Create: ipa topologysegment-init SEGMENT 'left'|'right' > > It would set 'start' to: > nsds5beginreplicarefresh;left or nsds5beginreplicarefresh;right > > This would start the initialization process of the chosen node. > > 3. Create: ipa topologysegment-stop-init SEGMENT 'left'|'right' > > It would set 'stop' to: > nsds5beginreplicarefresh;left or nsds5beginreplicarefresh;right > > This would stop the initialization process of the chosen node. > > An alternative could be `ipa topologysegment-init SEGMENT 'left'|'right' > --stop` > > > 4. Examine other nsds5* attributes if they require similar change or a > change in accepted values (eg, int for nsds5replicatimeout, on|off for > nsds5replicaenabled, ...) > > Btw, what about nsDS5ReplicaLastInitStart|Status|End attrs, is there a > plan to support them by the plugin and management UI? > > For the alpha, we could go just with bare params and mod command enabled > and then add the separate commands later. > > [1] > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#Replication_Attributes_under_cnReplicationAgreementName_cnreplica_cnsuffixName_cnmapping_tree_cnconfig-nsDS5BeginReplicaRefresh > -- > Petr Vobornik > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Mon May 18 16:37:17 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 18 May 2015 18:37:17 +0200 Subject: [Freeipa-devel] Fwd: Re: ipa topology command In-Reply-To: <555A118A.9080309@redhat.com> References: <555A09BA.4030908@redhat.com> <555A0DDC.1080505@redhat.com> <555A118A.9080309@redhat.com> Message-ID: <555A153D.9060208@redhat.com> On 05/18/2015 06:21 PM, Ludwig Krispenz wrote: > > On 05/18/2015 06:05 PM, Ludwig Krispenz wrote: >> Hi, >> I started this discussion with Petr, but he thinks it should be better >> discussed here. >> Ludwig >> -------- Original Message -------- >> Subject: Re: ipa topology command >> Date: Mon, 18 May 2015 17:48:10 +0200 >> From: Petr Vobornik >> To: Ludwig Krispenz >> >> >> >> On 05/18/2015 04:25 PM, Ludwig Krispenz wrote: >> > Hi, >> > >> > when testing I noticed an incompleteness in the topologysegment-mod >> > function. >> > A segment can be onedirectional or bidirectional, and with >> > topologysegment-mod one should be able to modify params of the >> > corresponding replication agreement(s). In the design I had a >> concept of >> > attributename[;left | ;right ] to apply the change to one or both >> > directions. In the plugin this is implemented, but in the ipa comand it >> > isn't. I thought it wouldn't matter since in ipa we want to have >> > replication agreements identical. >> > But there is one important exception: init ( >> nsds5beginreplicarefresh ), >> > which should always be onedirectional. >> > >> > Do you have an idea how to simply chnage this ? >> > >> > Thanks, >> > Ludwig >> >> I'm not sure if I understand the issue correctly. But will try. >> >> Subtypes are not widely used in ipalib yet so there might be some >> dragons. I general an attribute with known subtypes should be handled as >> multiple distinct attributes(params in ipalib), e.g.,: >> nsds5beginreplicarefresh;left >> nsds5beginreplicarefresh;right > ok, for this special attribute it would make sense since initializatiion > (refresh should be only in one direction), same is probably true for > 'enable'. > for other manage attrs, > attributename: value should apply to both directions (in a bidirectional > segment) > attributename;left: value > or > attributename;right: value > > should override the settings for one direction, at the moment I don't > see a valid use case, but since a bidirectional segment handles two > replication agreements, I did at least provide the possibility. > But except nsds5beginreplicarefresh I don't think we need to provide > this in the first versioj of the ipa command. >> >> The main question is for which attributes we should support specifying >> both direction. >> >> Wrt init: >> I actually didn't know what the attribute was for but after reading [1] >> I think that this attribute shouldn't be handled as a free-form string >> attribute because it starts an operation and then displays its status >> until it finishes. > it just updates the attribute of the segment, the modification is > replicated to all other servers and the master whom it concerns will > start an online init, Does "stop" work as well? > no automatic monitoring provided. If you want this, we need to extend > what status information is mainained in the shared tree. Since there is no update of state of the init process and the fact that the attr is cleared when target replica gets the info ('start?'|'stop'), I think that there is no value in having it as a param(ie output of -show command) because it will be almost always empty and therefore no useful information would be displayed to a user. >> If the plugin updates the attribute with the >> initialization state then IMHO these are the step we should take >> (details could be different): >> 1. create both attributes: >> >> Str( >> 'nsds5beginreplicarefresh;left', >> cli_name='init-left', >> label='Left node initialization', >> doc='Status of initialization of left node', >> flags=['no_create', 'no_update', 'no_search'], >> ), >> >> Str( >> 'nsds5beginreplicarefresh;right', >> cli_name='init-right', >> label='Right node initialization', >> doc='Status of initialization of right node', >> flags=['no_create', 'no_update', 'no_search'], >> ), > yes that would do it, maybe init-fromleft or init-from-right would be > clearer >> >> The attribute was made read-only so it can't be modified using >> segment-mod but segment-show would show its status. > what do you mean by was made read-only ? That it won't be listed as an option of topologysegment-mod command and therefore user is forced to use the init command (if I don't count --setattr option). >> >> 2. Create: ipa topologysegment-init SEGMENT 'left'|'right' >> >> It would set 'start' to: >> nsds5beginreplicarefresh;left or nsds5beginreplicarefresh;right >> >> This would start the initialization process of the chosen node. >> >> 3. Create: ipa topologysegment-stop-init SEGMENT 'left'|'right' >> >> It would set 'stop' to: >> nsds5beginreplicarefresh;left or nsds5beginreplicarefresh;right >> >> This would stop the initialization process of the chosen node. >> >> An alternative could be `ipa topologysegment-init SEGMENT 'left'|'right' >> --stop` >> >> >> 4. Examine other nsds5* attributes if they require similar change or a >> change in accepted values (eg, int for nsds5replicatimeout, on|off for >> nsds5replicaenabled, ...) >> >> Btw, what about nsDS5ReplicaLastInitStart|Status|End attrs, is there a >> plan to support them by the plugin and management UI? >> >> For the alpha, we could go just with bare params and mod command enabled >> and then add the separate commands later. >> >> [1] >> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#Replication_Attributes_under_cnReplicationAgreementName_cnreplica_cnsuffixName_cnmapping_tree_cnconfig-nsDS5BeginReplicaRefresh >> -- Petr Vobornik From lkrispen at redhat.com Mon May 18 18:10:01 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Mon, 18 May 2015 20:10:01 +0200 Subject: [Freeipa-devel] Fwd: Re: ipa topology command In-Reply-To: <555A153D.9060208@redhat.com> References: <555A09BA.4030908@redhat.com> <555A0DDC.1080505@redhat.com> <555A118A.9080309@redhat.com> <555A153D.9060208@redhat.com> Message-ID: <555A2AF9.6080905@redhat.com> On 05/18/2015 06:37 PM, Petr Vobornik wrote: > On 05/18/2015 06:21 PM, Ludwig Krispenz wrote: >> >> On 05/18/2015 06:05 PM, Ludwig Krispenz wrote: >>> Hi, >>> I started this discussion with Petr, but he thinks it should be better >>> discussed here. >>> Ludwig >>> -------- Original Message -------- >>> Subject: Re: ipa topology command >>> Date: Mon, 18 May 2015 17:48:10 +0200 >>> From: Petr Vobornik >>> To: Ludwig Krispenz >>> >>> >>> >>> On 05/18/2015 04:25 PM, Ludwig Krispenz wrote: >>> > Hi, >>> > >>> > when testing I noticed an incompleteness in the topologysegment-mod >>> > function. >>> > A segment can be onedirectional or bidirectional, and with >>> > topologysegment-mod one should be able to modify params of the >>> > corresponding replication agreement(s). In the design I had a >>> concept of >>> > attributename[;left | ;right ] to apply the change to one or both >>> > directions. In the plugin this is implemented, but in the ipa >>> comand it >>> > isn't. I thought it wouldn't matter since in ipa we want to have >>> > replication agreements identical. >>> > But there is one important exception: init ( >>> nsds5beginreplicarefresh ), >>> > which should always be onedirectional. >>> > >>> > Do you have an idea how to simply chnage this ? >>> > >>> > Thanks, >>> > Ludwig >>> >>> I'm not sure if I understand the issue correctly. But will try. >>> >>> Subtypes are not widely used in ipalib yet so there might be some >>> dragons. I general an attribute with known subtypes should be >>> handled as >>> multiple distinct attributes(params in ipalib), e.g.,: >>> nsds5beginreplicarefresh;left >>> nsds5beginreplicarefresh;right >> ok, for this special attribute it would make sense since initializatiion >> (refresh should be only in one direction), same is probably true for >> 'enable'. >> for other manage attrs, >> attributename: value should apply to both directions (in a bidirectional >> segment) >> attributename;left: value >> or >> attributename;right: value >> >> should override the settings for one direction, at the moment I don't >> see a valid use case, but since a bidirectional segment handles two >> replication agreements, I did at least provide the possibility. >> But except nsds5beginreplicarefresh I don't think we need to provide >> this in the first versioj of the ipa command. >>> >>> The main question is for which attributes we should support specifying >>> both direction. >>> >>> Wrt init: >>> I actually didn't know what the attribute was for but after reading [1] >>> I think that this attribute shouldn't be handled as a free-form string >>> attribute because it starts an operation and then displays its status >>> until it finishes. >> it just updates the attribute of the segment, the modification is >> replicated to all other servers and the master whom it concerns will >> start an online init, > > Does "stop" work as well? nsds5beginreplicarefresh accepts also "stop" and "cancel", but this has some different meaning, not stopping the online initialization. I would only care about "start", and this is needed. > >> no automatic monitoring provided. If you want this, we need to extend >> what status information is mainained in the shared tree. > > Since there is no update of state of the init process and the fact > that the attr is cleared when target replica gets the info > ('start?'|'stop'), I think that there is no value in having it as a > param(ie output of -show command) because it will be almost always > empty and therefore no useful information would be displayed to a user. it is no need to show it in the show command, but ist should be visible as an option in the topologysegment-mod command, maybe even without accepting a value, using init-left-right or init-right-left and automatically providing "start" as value. > >>> If the plugin updates the attribute with the >>> initialization state then IMHO these are the step we should take >>> (details could be different): >>> 1. create both attributes: >>> >>> Str( >>> 'nsds5beginreplicarefresh;left', >>> cli_name='init-left', >>> label='Left node initialization', >>> doc='Status of initialization of left node', >>> flags=['no_create', 'no_update', 'no_search'], >>> ), >>> >>> Str( >>> 'nsds5beginreplicarefresh;right', >>> cli_name='init-right', >>> label='Right node initialization', >>> doc='Status of initialization of right node', >>> flags=['no_create', 'no_update', 'no_search'], >>> ), >> yes that would do it, maybe init-fromleft or init-from-right would be >> clearer >>> >>> The attribute was made read-only so it can't be modified using >>> segment-mod but segment-show would show its status. >> what do you mean by was made read-only ? > > That it won't be listed as an option of topologysegment-mod command > and therefore user is forced to use the init command which init command do you refer to ? > (if I don't count --setattr option). > >>> >>> 2. Create: ipa topologysegment-init SEGMENT 'left'|'right' >>> >>> It would set 'start' to: >>> nsds5beginreplicarefresh;left or nsds5beginreplicarefresh;right >>> >>> This would start the initialization process of the chosen node. >>> >>> 3. Create: ipa topologysegment-stop-init SEGMENT 'left'|'right' >>> >>> It would set 'stop' to: >>> nsds5beginreplicarefresh;left or nsds5beginreplicarefresh;right >>> >>> This would stop the initialization process of the chosen node. >>> >>> An alternative could be `ipa topologysegment-init SEGMENT >>> 'left'|'right' >>> --stop` >>> >>> >>> 4. Examine other nsds5* attributes if they require similar change or a >>> change in accepted values (eg, int for nsds5replicatimeout, on|off for >>> nsds5replicaenabled, ...) >>> >>> Btw, what about nsDS5ReplicaLastInitStart|Status|End attrs, is there a >>> plan to support them by the plugin and management UI? >>> >>> For the alpha, we could go just with bare params and mod command >>> enabled >>> and then add the separate commands later. >>> >>> [1] >>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#Replication_Attributes_under_cnReplicationAgreementName_cnreplica_cnsuffixName_cnmapping_tree_cnconfig-nsDS5BeginReplicaRefresh >>> >>> From edewata at redhat.com Mon May 18 19:17:35 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 18 May 2015 14:17:35 -0500 Subject: [Freeipa-devel] [PATCH] Password vault In-Reply-To: <55553B0A.10800@redhat.com> References: <54E1AF55.3060409@redhat.com> <54EBEB55.6010306@redhat.com> <54F96B22.9050507@redhat.com> <55004D5D.6060300@redhat.com> <550FE5EB.1070606@redhat.com> <551E0AE1.8040500@redhat.com> <553498D1.1020901@redhat.com> <5551DB57.6060504@redhat.com> <555314D1.6070304@redhat.com> <55541015.3040206@redhat.com> <5554ECAE.8030908@redhat.com> <55553B0A.10800@redhat.com> Message-ID: <555A3ACF.3000305@redhat.com> 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: /@. >>> The vault is stored in cn=, cn=, cn=services, cn=vaults, >>> . 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 >>> $ ipa vault-add --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 / > $ ipa vault-add SharedVault --shared > $ ipa vault-add UsersVault --user > $ ipa vault-add HostVault --host > > 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=. Host vaults can be added later once we define the use case. >>> 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, , so the rdn will >>> become cn=vaults and container_dn will become . 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. >>> 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. >>> 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. >>> 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=, >>> cn=users, cn=vaults). The entry cn=, cn=, 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. The code has been changed to use the service name as the container: cn=vaults + cn=services + cn= + cn= + cn= >>> 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? The original code seems to > be working fine with ipalib.api. > > 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? 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) >>> 6. The loop in create_container() is incorrect. Suppose we're creating a >>> container cn=A, cn=B, and the parent container cn=B, >>> 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. This change is not included. The original code and the tests work just fine. > 8. There's a new PEP8 error: > > .../ipalib/plugins/vault.py:98:1: E302 expected 2 blank lines, found 1 The new patch doesn't have this issue. > 9. The API.txt needs to be regenerated. The API.txt and VERSION file have been updated. -- Endi S. Dewata -------------- next part -------------- >From 00a5b0444e8d3c33c5236ae1d23fedde29135427 Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Tue, 21 Oct 2014 10:57:08 -0400 Subject: [PATCH] Added vault plugin. A new plugin has been added to manage vaults. Test scripts have also been added to verify the functionality. https://fedorahosted.org/freeipa/ticket/3872 --- API.txt | 74 +++++ VERSION | 4 +- install/share/60basev3.ldif | 1 + install/updates/40-vault.update | 19 ++ install/updates/Makefile.am | 1 + ipa-client/man/default.conf.5 | 1 + ipalib/constants.py | 1 + ipalib/plugins/vault.py | 307 +++++++++++++++++++++ ipatests/test_xmlrpc/test_vault_plugin.py | 445 ++++++++++++++++++++++++++++++ 9 files changed, 851 insertions(+), 2 deletions(-) create mode 100644 install/updates/40-vault.update create mode 100644 ipalib/plugins/vault.py create mode 100644 ipatests/test_xmlrpc/test_vault_plugin.py diff --git a/API.txt b/API.txt index 0808f3c64595495c8a9e60da5cbd689d5cdc6224..38deafefa57942bf242f989d79b1e93ee2c2013e 100644 --- a/API.txt +++ b/API.txt @@ -4717,6 +4717,80 @@ option: Str('version?', exclude='webui') output: Output('result', , None) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) +command: vault_add +args: 1,9,3 +arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[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: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('service?') +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: Flag('shared?', autofill=True, default=False) +option: Str('user?') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault_del +args: 1,5,3 +arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=True, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Flag('continue', autofill=True, cli_name='continue', default=False) +option: Str('service?') +option: Flag('shared?', autofill=True, default=False) +option: Str('user?') +option: Str('version?', exclude='webui') +output: Output('result', , None) +output: Output('summary', (, ), None) +output: ListOfPrimaryKeys('value', None, None) +command: vault_find +args: 1,11,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='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=False) +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, query=True, required=False) +option: Flag('pkey_only?', autofill=True, default=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('service?') +option: Flag('shared?', autofill=True, default=False) +option: Int('sizelimit?', autofill=False, minvalue=0) +option: Int('timelimit?', autofill=False, minvalue=0) +option: Str('user?') +option: Str('version?', exclude='webui') +output: Output('count', , None) +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('truncated', , None) +command: vault_mod +args: 1,11,3 +arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('delattr*', cli_name='delattr', exclude='webui') +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('service?') +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: Flag('shared?', autofill=True, default=False) +option: Str('user?') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault_show +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[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('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('service?') +option: Flag('shared?', autofill=True, default=False) +option: Str('user?') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) capability: messages 2.52 capability: optional_uid_params 2.54 capability: permissions2 2.69 diff --git a/VERSION b/VERSION index c207558504e645dec73d105189d4b862877b4e26..33e7bebe4c673279ae92395a2575dc11e9fd4956 100644 --- a/VERSION +++ b/VERSION @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 # # ######################################################## IPA_API_VERSION_MAJOR=2 -IPA_API_VERSION_MINOR=118 -# Last change: tbordaz - Add stageuser_find, stageuser_mod, stageuser_del, stageuser_show +IPA_API_VERSION_MINOR=119 +# Last change: edewata - Added vault plugin diff --git a/install/share/60basev3.ldif b/install/share/60basev3.ldif index eb1c1298b9de3295695745ba3311bb772dec70e9..33f4804e30ff1b3814ecf295bb41f07e2a8cd12f 100644 --- a/install/share/60basev3.ldif +++ b/install/share/60basev3.ldif @@ -79,3 +79,4 @@ objectClasses: (2.16.840.1.113730.3.8.12.24 NAME 'ipaPublicKeyObject' DESC 'Wrap objectClasses: (2.16.840.1.113730.3.8.12.25 NAME 'ipaPrivateKeyObject' DESC 'Wrapped private keys' SUP top AUXILIARY MUST ( ipaPrivateKey $ ipaWrappingKey $ ipaWrappingMech ) X-ORIGIN 'IPA v4.1' ) objectClasses: (2.16.840.1.113730.3.8.12.26 NAME 'ipaSecretKeyObject' DESC 'Wrapped secret keys' SUP top AUXILIARY MUST ( ipaSecretKey $ ipaWrappingKey $ ipaWrappingMech ) X-ORIGIN 'IPA v4.1' ) objectClasses: (2.16.840.1.113730.3.8.12.34 NAME 'ipaSecretKeyRefObject' DESC 'Indirect storage for encoded key material' SUP top AUXILIARY MUST ( ipaSecretKeyRef ) X-ORIGIN 'IPA v4.1' ) +objectClasses: (2.16.840.1.113730.3.8.18.1.1 NAME 'ipaVault' DESC 'IPA vault' SUP top STRUCTURAL MUST ( cn ) MAY ( description ) X-ORIGIN 'IPA v4.2' ) diff --git a/install/updates/40-vault.update b/install/updates/40-vault.update new file mode 100644 index 0000000000000000000000000000000000000000..5a6b8c6a022fa56e5a5bc05369ce143d39644092 --- /dev/null +++ b/install/updates/40-vault.update @@ -0,0 +1,19 @@ +dn: cn=vaults,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: cn: vaults + +dn: cn=services,cn=vaults,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: cn: services + +dn: cn=shared,cn=vaults,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: cn: shared + +dn: cn=users,cn=vaults,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: cn: users diff --git a/install/updates/Makefile.am b/install/updates/Makefile.am index 0d63d9ea8d85f1add5f036e7a39f89543586d33b..66f6b9d37971f8b8501d73fc6ddca21b6686ff4b 100644 --- a/install/updates/Makefile.am +++ b/install/updates/Makefile.am @@ -33,6 +33,7 @@ app_DATA = \ 40-dns.update \ 40-automember.update \ 40-otp.update \ + 40-vault.update \ 45-roles.update \ 50-7_bit_check.update \ 50-dogtag10-migration.update \ diff --git a/ipa-client/man/default.conf.5 b/ipa-client/man/default.conf.5 index dbc8a5b4647439de4de7c01152d098eb0561e236..0973f1a07179ad64daa326a02803cdc9ba1870aa 100644 --- a/ipa-client/man/default.conf.5 +++ b/ipa-client/man/default.conf.5 @@ -221,6 +221,7 @@ The following define the containers for the IPA server. Containers define where container_sudocmdgroup: cn=sudocmdgroups,cn=sudo container_sudorule: cn=sudorules,cn=sudo container_user: cn=users,cn=accounts + container_vault: cn=vaults container_virtual: cn=virtual operations,cn=etc .SH "FILES" diff --git a/ipalib/constants.py b/ipalib/constants.py index f1e14702ffdf5a3bd23a62b1fdd2ee3cd95d84f8..195938a355d1b24c02aa0a5833c1725c76e85c76 100644 --- a/ipalib/constants.py +++ b/ipalib/constants.py @@ -99,6 +99,7 @@ DEFAULT_CONFIG = ( ('container_hbacservice', DN(('cn', 'hbacservices'), ('cn', 'hbac'))), ('container_hbacservicegroup', DN(('cn', 'hbacservicegroups'), ('cn', 'hbac'))), ('container_dns', DN(('cn', 'dns'))), + ('container_vault', DN(('cn', 'vaults'))), ('container_virtual', DN(('cn', 'virtual operations'), ('cn', 'etc'))), ('container_sudorule', DN(('cn', 'sudorules'), ('cn', 'sudo'))), ('container_sudocmd', DN(('cn', 'sudocmds'), ('cn', 'sudo'))), diff --git a/ipalib/plugins/vault.py b/ipalib/plugins/vault.py new file mode 100644 index 0000000000000000000000000000000000000000..598ed645a30f12bceecf6ca9be32bbbb320863f5 --- /dev/null +++ b/ipalib/plugins/vault.py @@ -0,0 +1,307 @@ +# Authors: +# Endi S. Dewata +# +# Copyright (C) 2015 Red Hat +# see file 'COPYING' for use and warranty information +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation, either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see . + +from ipalib import api, errors +from ipalib import Str, Flag +from ipalib import output +from ipalib.plugable import Registry +from ipalib.plugins.baseldap import LDAPObject, LDAPCreate, LDAPDelete,\ + LDAPSearch, LDAPUpdate, LDAPRetrieve +from ipalib.request import context +from ipalib.plugins.user import split_principal +from ipalib import _, ngettext +from ipapython.dn import DN + +__doc__ = _(""" +Vaults +""") + _(""" +Manage vaults. +""") + _(""" +EXAMPLES: +""") + _(""" + List private vaults: + ipa vault-find +""") + _(""" + List service vaults: + ipa vault-find --service +""") + _(""" + List shared vaults: + ipa vault-find --shared +""") + _(""" + List user vaults: + ipa vault-find --user +""") + _(""" + Add a private vault: + ipa vault-add +""") + _(""" + Add a service vault: + ipa vault-add --service +""") + _(""" + Add a shared vault: + ipa vault-add --shared +""") + _(""" + Add a user vault: + ipa vault-add --user +""") + _(""" + Show a private vault: + ipa vault-show +""") + _(""" + Show a service vault: + ipa vault-show --service +""") + _(""" + Show a shared vault: + ipa vault-show --shared +""") + _(""" + Show a user vault: + ipa vault-show --user +""") + _(""" + Modify a private vault: + ipa vault-mod --desc +""") + _(""" + Modify a service vault: + ipa vault-mod --service --desc +""") + _(""" + Modify a shared vault: + ipa vault-mod --shared --desc +""") + _(""" + Modify a user vault: + ipa vault-mod --user --desc +""") + _(""" + Delete a private vault: + ipa vault-del +""") + _(""" + Delete a service vault: + ipa vault-del --service +""") + _(""" + Delete a shared vault: + ipa vault-del --shared +""") + _(""" + Delete a user vault: + ipa vault-del --user +""") + +register = Registry() + + +vault_options = ( + Str( + 'service?', + doc=_('Service name'), + ), + Flag( + 'shared?', + doc=_('Shared vault'), + ), + Str( + 'user?', + doc=_('Username'), + ), +) + + + at register() +class vault(LDAPObject): + __doc__ = _(""" + Vault object. + """) + + container_dn = api.env.container_vault + base_dn = DN(container_dn, api.env.basedn) + + object_name = _('vault') + object_name_plural = _('vaults') + + object_class = ['ipaVault'] + default_attributes = [ + 'cn', + 'description', + ] + + label = _('Vaults') + label_singular = _('Vault') + + takes_params = ( + Str( + 'cn', + cli_name='name', + label=_('Vault name'), + primary_key=True, + pattern='^[a-zA-Z0-9_.-]+$', + pattern_errmsg='may only include letters, numbers, _, ., and -', + maxlength=255, + ), + Str( + 'description?', + cli_name='desc', + label=_('Description'), + doc=_('Vault description'), + ), + ) + + def get_dn(self, *keys, **options): + """ + Generates vault DN from parameters. + """ + + service = options.get('service') + shared = options.get('shared') + user = options.get('user') + + count = 0 + if service: + count += 1 + + if shared: + count += 1 + + if user: + count += 1 + + if count > 1: + raise errors.MutuallyExclusiveError( + reason=_('Service, shared, and user options ' + + 'cannot be specified simultaneously')) + + dn = super(vault, self).get_dn(*keys, **options) + assert dn.endswith(self.base_dn) + rdns = DN(*dn[:-len(self.base_dn)]) + + if not count: + principal = getattr(context, 'principal') + (name, realm) = split_principal(principal) + if '/' in name: + service = name + else: + user = name + + if service: + parent_dn = DN(('cn', service), ('cn', 'services'), self.base_dn) + elif shared: + parent_dn = DN(('cn', 'shared'), self.base_dn) + else: + parent_dn = DN(('cn', user), ('cn', 'users'), self.base_dn) + + return DN(rdns, parent_dn) + + def create_container(self, dn): + """ + Creates vault container and its parents. + """ + + assert dn.endswith(self.base_dn) + + rdn = dn[0] + entry = self.backend.make_entry( + dn, + { + 'objectclass': ['nsContainer'], + 'cn': rdn['cn'], + }) + + # if entry can be added, return + try: + self.backend.add_entry(entry) + return + + except errors.NotFound: + pass + + # otherwise, create parent entry first + parent_dn = DN(*dn[1:]) + self.create_container(parent_dn) + + # then create the entry itself again + self.backend.add_entry(entry) + + + at register() +class vault_add(LDAPCreate): + __doc__ = _('Create a new vault.') + + takes_options = LDAPCreate.takes_options + vault_options + + msg_summary = _('Added vault "%(value)s"') + + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, + **options): + assert isinstance(dn, DN) + + try: + parent_dn = DN(*dn[1:]) + self.obj.create_container(parent_dn) + except errors.DuplicateEntry, e: + pass + + return dn + + + at register() +class vault_del(LDAPDelete): + __doc__ = _('Delete a vault.') + + takes_options = LDAPDelete.takes_options + vault_options + + msg_summary = _('Deleted vault "%(value)s"') + + + at register() +class vault_find(LDAPSearch): + __doc__ = _('Search for vaults.') + + takes_options = LDAPSearch.takes_options + vault_options + + msg_summary = ngettext( + '%(count)d vault matched', + '%(count)d vaults matched', + 0, + ) + + def pre_callback(self, ldap, filter, attrs_list, base_dn, scope, *args, + **options): + assert isinstance(base_dn, DN) + + base_dn = self.obj.get_dn(*args, **options) + + return (filter, base_dn, scope) + + def exc_callback(self, args, options, exc, call_func, *call_args, + **call_kwargs): + if call_func.__name__ == 'find_entries': + if isinstance(exc, errors.NotFound): + # ignore missing containers since they will be created + # automatically on vault creation. + raise errors.EmptyResult(reason=str(exc)) + + raise exc + + + at register() +class vault_mod(LDAPUpdate): + __doc__ = _('Modify a vault.') + + takes_options = LDAPUpdate.takes_options + vault_options + + msg_summary = _('Modified vault "%(value)s"') + + + at register() +class vault_show(LDAPRetrieve): + __doc__ = _('Display information about a vault.') + + takes_options = LDAPRetrieve.takes_options + vault_options diff --git a/ipatests/test_xmlrpc/test_vault_plugin.py b/ipatests/test_xmlrpc/test_vault_plugin.py new file mode 100644 index 0000000000000000000000000000000000000000..44d397c583928d98ec252899398ae6c3a83c207c --- /dev/null +++ b/ipatests/test_xmlrpc/test_vault_plugin.py @@ -0,0 +1,445 @@ +# Authors: +# Endi S. Dewata +# +# Copyright (C) 2015 Red Hat +# see file 'COPYING' for use and warranty information +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation, either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see . + +""" +Test the `ipalib/plugins/vault.py` module. +""" + +from ipalib import api, errors +from xmlrpc_test import Declarative, fuzzy_string + +vault_name = u'test_vault' +service_name = u'HTTP/server.example.com' +user_name = u'testuser' + + +class test_vault_plugin(Declarative): + + cleanup_commands = [ + ('vault_del', [vault_name], {'continue': True}), + ('vault_del', [vault_name], { + 'service': service_name, + 'continue': True + }), + ('vault_del', [vault_name], {'shared': True, 'continue': True}), + ('vault_del', [vault_name], {'user': user_name, 'continue': True}), + ] + + tests = [ + + { + 'desc': 'Create private vault', + 'command': ( + 'vault_add', + [vault_name], + {}, + ), + 'expected': { + 'value': vault_name, + 'summary': 'Added vault "%s"' % vault_name, + 'result': { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,%s' + % (vault_name, api.env.basedn), + 'objectclass': [u'top', u'ipaVault'], + 'cn': [vault_name], + }, + }, + }, + + { + 'desc': 'Find private vaults', + 'command': ( + 'vault_find', + [], + {}, + ), + 'expected': { + 'count': 1, + 'truncated': False, + 'summary': u'1 vault matched', + 'result': [ + { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,%s' + % (vault_name, api.env.basedn), + 'cn': [vault_name], + }, + ], + }, + }, + + { + 'desc': 'Show private vault', + 'command': ( + 'vault_show', + [vault_name], + {}, + ), + 'expected': { + 'value': vault_name, + 'summary': None, + 'result': { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,%s' + % (vault_name, api.env.basedn), + 'cn': [vault_name], + }, + }, + }, + + { + 'desc': 'Modify private vault', + 'command': ( + 'vault_mod', + [vault_name], + { + 'description': u'Test vault', + }, + ), + 'expected': { + 'value': vault_name, + 'summary': u'Modified vault "%s"' % vault_name, + 'result': { + 'cn': [vault_name], + 'description': [u'Test vault'], + }, + }, + }, + + { + 'desc': 'Delete private vault', + 'command': ( + 'vault_del', + [vault_name], + {}, + ), + 'expected': { + 'value': [vault_name], + 'summary': u'Deleted vault "%s"' % vault_name, + 'result': { + 'failed': (), + }, + }, + }, + + { + 'desc': 'Create service vault', + 'command': ( + 'vault_add', + [vault_name], + { + 'service': service_name, + }, + ), + 'expected': { + 'value': vault_name, + 'summary': u'Added vault "%s"' % vault_name, + 'result': { + 'dn': u'cn=%s,cn=%s,cn=services,cn=vaults,%s' + % (vault_name, service_name, api.env.basedn), + 'objectclass': [u'top', u'ipaVault'], + 'cn': [vault_name], + }, + }, + }, + + { + 'desc': 'Find service vaults', + 'command': ( + 'vault_find', + [], + { + 'service': service_name, + }, + ), + 'expected': { + 'count': 1, + 'truncated': False, + 'summary': u'1 vault matched', + 'result': [ + { + 'dn': u'cn=%s,cn=%s,cn=services,cn=vaults,%s' + % (vault_name, service_name, api.env.basedn), + 'cn': [vault_name], + }, + ], + }, + }, + + { + 'desc': 'Show service vault', + 'command': ( + 'vault_show', + [vault_name], + { + 'service': service_name, + }, + ), + 'expected': { + 'value': vault_name, + 'summary': None, + 'result': { + 'dn': u'cn=%s,cn=%s,cn=services,cn=vaults,%s' + % (vault_name, service_name, api.env.basedn), + 'cn': [vault_name], + }, + }, + }, + + { + 'desc': 'Modify service vault', + 'command': ( + 'vault_mod', + [vault_name], + { + 'service': service_name, + 'description': u'Test vault', + }, + ), + 'expected': { + 'value': vault_name, + 'summary': u'Modified vault "%s"' % vault_name, + 'result': { + 'cn': [vault_name], + 'description': [u'Test vault'], + }, + }, + }, + + { + 'desc': 'Delete service vault', + 'command': ( + 'vault_del', + [vault_name], + { + 'service': service_name, + }, + ), + 'expected': { + 'value': [vault_name], + 'summary': u'Deleted vault "%s"' % vault_name, + 'result': { + 'failed': (), + }, + }, + }, + + { + 'desc': 'Create shared vault', + 'command': ( + 'vault_add', + [vault_name], + { + 'shared': True + }, + ), + 'expected': { + 'value': vault_name, + 'summary': u'Added vault "%s"' % vault_name, + 'result': { + 'dn': u'cn=%s,cn=shared,cn=vaults,%s' + % (vault_name, api.env.basedn), + 'objectclass': [u'top', u'ipaVault'], + 'cn': [vault_name], + }, + }, + }, + + { + 'desc': 'Find shared vaults', + 'command': ( + 'vault_find', + [], + { + 'shared': True + }, + ), + 'expected': { + 'count': 1, + 'truncated': False, + 'summary': u'1 vault matched', + 'result': [ + { + 'dn': u'cn=%s,cn=shared,cn=vaults,%s' + % (vault_name, api.env.basedn), + 'cn': [vault_name], + }, + ], + }, + }, + + { + 'desc': 'Show shared vault', + 'command': ( + 'vault_show', + [vault_name], + { + 'shared': True + }, + ), + 'expected': { + 'value': vault_name, + 'summary': None, + 'result': { + 'dn': u'cn=%s,cn=shared,cn=vaults,%s' + % (vault_name, api.env.basedn), + 'cn': [vault_name], + }, + }, + }, + + { + 'desc': 'Modify shared vault', + 'command': ( + 'vault_mod', + [vault_name], + { + 'shared': True, + 'description': u'Test vault', + }, + ), + 'expected': { + 'value': vault_name, + 'summary': u'Modified vault "%s"' % vault_name, + 'result': { + 'cn': [vault_name], + 'description': [u'Test vault'], + }, + }, + }, + + { + 'desc': 'Delete shared vault', + 'command': ( + 'vault_del', + [vault_name], + { + 'shared': True + }, + ), + 'expected': { + 'value': [vault_name], + 'summary': u'Deleted vault "%s"' % vault_name, + 'result': { + 'failed': (), + }, + }, + }, + + { + 'desc': 'Create user vault', + 'command': ( + 'vault_add', + [vault_name], + { + 'user': user_name, + }, + ), + 'expected': { + 'value': vault_name, + 'summary': u'Added vault "%s"' % vault_name, + 'result': { + 'dn': u'cn=%s,cn=%s,cn=users,cn=vaults,%s' + % (vault_name, user_name, api.env.basedn), + 'objectclass': [u'top', u'ipaVault'], + 'cn': [vault_name], + }, + }, + }, + + { + 'desc': 'Find user vaults', + 'command': ( + 'vault_find', + [], + { + 'user': user_name, + }, + ), + 'expected': { + 'count': 1, + 'truncated': False, + 'summary': u'1 vault matched', + 'result': [ + { + 'dn': u'cn=%s,cn=%s,cn=users,cn=vaults,%s' + % (vault_name, user_name, api.env.basedn), + 'cn': [vault_name], + }, + ], + }, + }, + + { + 'desc': 'Show user vault', + 'command': ( + 'vault_show', + [vault_name], + { + 'user': user_name, + }, + ), + 'expected': { + 'value': vault_name, + 'summary': None, + 'result': { + 'dn': u'cn=%s,cn=%s,cn=users,cn=vaults,%s' + % (vault_name, user_name, api.env.basedn), + 'cn': [vault_name], + }, + }, + }, + + { + 'desc': 'Modify user vault', + 'command': ( + 'vault_mod', + [vault_name], + { + 'user': user_name, + 'description': u'Test vault', + }, + ), + 'expected': { + 'value': vault_name, + 'summary': u'Modified vault "%s"' % vault_name, + 'result': { + 'cn': [vault_name], + 'description': [u'Test vault'], + }, + }, + }, + + { + 'desc': 'Delete user vault', + 'command': ( + 'vault_del', + [vault_name], + { + 'user': user_name, + }, + ), + 'expected': { + 'value': [vault_name], + 'summary': u'Deleted vault "%s"' % vault_name, + 'result': { + 'failed': (), + }, + }, + }, + + ] -- 1.9.3 From pspacek at redhat.com Tue May 19 06:03:02 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 19 May 2015 08:03:02 +0200 Subject: [Freeipa-devel] [PATCH 0364] Remove unused files rdlist.c and rdlist.h In-Reply-To: <20150518151018.GE16916@mail.corp.redhat.com> References: <5555BFFA.2050207@redhat.com> <20150518151018.GE16916@mail.corp.redhat.com> Message-ID: <555AD216.50402@redhat.com> 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 >> 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 > 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 From jcholast at redhat.com Tue May 19 08:27:24 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 19 May 2015 10:27:24 +0200 Subject: [Freeipa-devel] [PATCH] Password vault In-Reply-To: <555A3ACF.3000305@redhat.com> References: <54E1AF55.3060409@redhat.com> <54EBEB55.6010306@redhat.com> <54F96B22.9050507@redhat.com> <55004D5D.6060300@redhat.com> <550FE5EB.1070606@redhat.com> <551E0AE1.8040500@redhat.com> <553498D1.1020901@redhat.com> <5551DB57.6060504@redhat.com> <555314D1.6070304@redhat.com> <55541015.3040206@redhat.com> <5554ECAE.8030908@redhat.com> <55553B0A.10800@redhat.com> <555A3ACF.3000305@redhat.com> Message-ID: <555AF3EC.1060100@redhat.com> 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: /@. >>>> The vault is stored in cn=, cn=, cn=services, cn=vaults, >>>> . 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 >>>> $ ipa vault-add --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 / >> $ ipa vault-add SharedVault --shared >> $ ipa vault-add UsersVault --user >> $ ipa vault-add HostVault --host >> >> 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=. > > 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, , so the rdn will >>>> become cn=vaults and container_dn will become . 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=, >>>> cn=users, cn=vaults). The entry cn=, cn=, 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 code has been changed to use the service name as the container: > > cn=vaults > + cn=services > + cn= > + cn= > + cn= OK. > >>>> 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.) > > 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. > >>>> 6. The loop in create_container() is incorrect. Suppose we're >>>> creating a >>>> container cn=A, cn=B, and the parent container cn=B, >>>> 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 without recursion, like my code does: + def create_container(self, dn): + """ + Creates vault container and its parents. + """ + + container_dn = DN(self.container_dn, self.api.env.basedn) + assert dn.endswith(container_dn) + + dns = [] + while dn.endswith(container_dn): + dns.insert(0, dn) + dn = DN(*dn[1:]) + + for dn in dns: + entry = self.backend.make_entry( + dn, + objectclass=['nsContainer'], + cn=[dn[0]['cn']], + ) + + try: + self.backend.add_entry(entry) + except errors.DuplicateEntry: + pass > >> 8. There's a new PEP8 error: >> >> .../ipalib/plugins/vault.py:98:1: E302 expected 2 blank lines, found 1 > > The new patch doesn't have this issue. OK. > >> 9. The API.txt needs to be regenerated. > > The API.txt and VERSION file have been updated. > OK. -- Jan Cholasta From jcholast at redhat.com Tue May 19 08:52:49 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 19 May 2015 10:52:49 +0200 Subject: [Freeipa-devel] [PATCHES 0001-0007] Profile management In-Reply-To: <5555E63D.4050808@redhat.com> References: <20150504133641.GQ16379@dhcp-40-8.bne.redhat.com> <55479FE1.1020005@redhat.com> <20150505062934.GU16379@dhcp-40-8.bne.redhat.com> <5548816D.6050304@redhat.com> <555305EC.5020001@redhat.com> <55530D23.5040702@redhat.com> <55530DDB.9000101@redhat.com> <20150515082420.GR12806@dhcp-40-8.bne.redhat.com> <5555E63D.4050808@redhat.com> Message-ID: <555AF9E1.1010606@redhat.com> 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 shorter license header >>>>>>>> # >>>>>>>> # Copyright (C) 2015 FreeIPA Contributors see COPYING for license >>>>>>>> # >>>>>>>> >>>>>>>> 3) >>>>>>>> +from ipalib.plugins.baseldap import \ >>>>>>>> + LDAPObject, LDAPSearch, LDAPCreate, LDAPDelete, LDAPUpdate, >>>>>>>> LDAPRetrieve >>>>>>>> >>>>>>>> please use 'import ( modules, .. )' instead of '\' >>>>>>>> >>>>>>>> 4) >>>>>>>> + if method == 'POST' \ >>>>>>>> + and 'content-type' not in (str(k).lower() for k in >>>>>>>> headers.viewkeys()): >>>>>>>> >>>>>>>> again, please use if ( ... ): instead \ >>>>>>>> >>>>>>>> 5) >>>>>>>> +import ipalib.errors as errors >>>>>>>> in dogtag.py >>>>>>>> >>>>>>>> Can you use from ipalib import errors, instead? >>>>>>>> >>>>>>>> 6) >>>>>>>> + def __exit__(self, exc_type, exc_value, traceback): >>>>>>>> + """Log out of the REST API""" >>>>>>>> + # TODO logout >>>>>>>> + self.cookie = None >>>>>>>> >>>>>>>> This is forgotten, or will be this fixed later? >>>>>>>> >>>>>>>> 7) >>>>>>>> + if not explanation: print resp_body # NOCOMMIT >>>>>>>> >>>>>>> These are all fixed for the next patchset. >>>>>>> >>>>>>> Thanks! >>>>>>> Fraser >>>>>>> >>>>> 8) You can do: >>>>> >>>>> Str('cn', >>>>> primary_key=True, >>>>> cli_name='id', >>>>> label=_('Profile ID'), >>>>> doc=_('Profile ID for referring to this profile'), >>>>> pattern='^[a-zA-Z]\w*$', >>>>> pattern_errmsg=_('invalid Profile ID'), >>>>> ), >>>>> >>>>> instead of: >>>>> >>>>> profile_id_pattern = re.compile('^[a-zA-Z]\w*$') >>>>> >>>>> def validate_profile_id(ugettext, value): >>>>> """Ensure profile ID matches form required by CA.""" >>>>> if profile_id_pattern.match(value) is None: >>>>> return _('invalid Profile ID') >>>>> else: >>>>> return None >>>>> >>>>> ... >>>>> >>>>> Str('cn', validate_profile_id, >>>>> primary_key=True, >>>>> cli_name='id', >>>>> label=_('Profile ID'), >>>>> doc=_('Profile ID for referring to this profile'), >>>>> ), >>>>> >> This is nice, but I have kept the separate method so that the >> cert-request command can use the same routine for validating the >> profile id (this will be in a subsequent patch). >> >>>>> 9) Please don't invent new attributes (ipaCertProfileSummary) when you >>>>> can use existing ones (description). >>>>> >>>>> >>>>> 10) All the commands should call >>>>> ipalib.plugins.cert.ca_enabled_check(). >>>>> >>>>> >>>>> 11) I think the File parameter of certprofile_import should be called >>>>> just 'file'. >>>>> >> 9, 10, 11 were addressed for this patchset. >> >>>>> 12) IMO the profile backend should be merged in to the ra backend. I >>>>> don't see a need to have these two separate. >>>>> >>>>> >>>>> Honza >>>>> >>>> >>> >>> -- >>> Jan Cholasta > Thank you. > > I did part of review, again I have not idea about the dogtag magic > there, so I might be completely wrong. > Martin^2 > > Patches need rebase. > > Patch 0001: > 1) > I'm not sure if this is added during upgrade > + config.set("CA", "pki_profiles_in_ldap", "True") > > Patch 0002: > LGTM (upgrade solved in 0005) > > Patch 0003: > I have no idea. > > Patch 0004: > 1) > Can you please let it in old school way, for better readability > sysupgrade.get_upgrade_state(*upgrade_state_args): > > sysupgrade.get_upgrade_state('dogtag', 'agent_allow_profile_modify') > sysupgrade.set_upgrade_state('dogtag', 'agent_allow_profile_modify' ,True) > > 2) > + conn = ipaldap.IPAdmin(self.fqdn, self.ds_port) > + conn.do_simple_bind(DN(('cn', 'Directory Manager')), > self.dm_password) > + conn.modify_s(dn, modlist) > + conn.unbind() > > IMO You can use: > self.ldap_connect() > self.admin_conn.modify_s() > > Patch 0005: > LGTM > > Patch 0006: > LGTM > > Patch 0007: > 0) > I cannot apply patch > > error: invalid object 100755 c6c602dc6b4582c24e4ca751ab2f91f8e683dffa > for 'install/tools/ipa-upgradeconfig' > fatal: git-write-tree: error building trees > Repository lacks necessary blobs to fall back on 3-way merge. > Cannot fall back to three-way merge. > Patch failed at 0007 Import included profiles during install or upgrade > > > 1) > + # update `api.env.ca_host` to correct hostname > + # https://fedorahosted.org/freeipa/ticket/4936 > + api.env.ca_host = host_name > This is something what was already fixed, maybe rebase error? > > 2) > + if setup_ca: > + # ensure profile backend is available > + import ipaserver.plugins.dogtag > Must be this import in ipa-server-install? > Respectively why is this import required, isn't it initialized by > api.finalize()? +1, what are you trying to accomplish here? > > 3) > + service.print_msg("Importing certificate profiles") > + api.Backend.ra_certprofile._read_password() > + if not api.Backend.ldap2.isconnected(): > + api.Backend.ldap2.connect(autobind=True) > + ca.import_included_profiles() > > Why this must be in ipa-server-install? > Why is that not in cainstance? +1 > > 4) > I'm not sure if these functions can be removed: > Honza please take look, if it is safe > > - def upgrade_ipa_profile(ca, domain, fqdn) > > - self.step("set certificate subject base", > self.__set_subject_in_config) > - self.step("enabling Subject Key Identifier", > self.enable_subject_key_identifier) > - self.step("enabling Subject Alternative Name", > self.enable_subject_alternative_name) > - self.step("enabling CRL and OCSP extensions for > certificates", self.__set_crl_ocsp_extensions) > > 5) > '/usr/share/ipa/profiles/{}.cfg'.format(profile_id), sub_dict) > > os.path.join(paths.USR_SHARE_IPA_DIR, 'profiles', ) > please use paths from ipaplatform.paths module. > Maybe rather create new path in ipaplatform/base/paths > USR_SHARE_IPA_PROFILES_DIR = "/usr/share/ipa/profiles" > > Nitpicks: > In several patches: > + except ipalib.errors.PublicError, e: > please us except ipalib.errors.PublicError as e > 6) IPA currently uses the caIPAServiceCert profile. Why don't you import this profile and instead create a new DefaultService profile? -- Jan Cholasta From mbabinsk at redhat.com Tue May 19 11:17:42 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 19 May 2015 13:17:42 +0200 Subject: [Freeipa-devel] [PATCH 0035] do not check for directory manager password during KRA uninstall Message-ID: <555B1BD6.6040406@redhat.com> https://fedorahosted.org/freeipa/ticket/5028 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0035-do-not-check-for-directory-manager-password-during-K.patch Type: text/x-patch Size: 2502 bytes Desc: not available URL: From ftweedal at redhat.com Tue May 19 11:50:27 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 19 May 2015 21:50:27 +1000 Subject: [Freeipa-devel] [PATCHES 0001-0007] Profile management In-Reply-To: <555AF9E1.1010606@redhat.com> References: <20150504133641.GQ16379@dhcp-40-8.bne.redhat.com> <55479FE1.1020005@redhat.com> <20150505062934.GU16379@dhcp-40-8.bne.redhat.com> <5548816D.6050304@redhat.com> <555305EC.5020001@redhat.com> <55530D23.5040702@redhat.com> <55530DDB.9000101@redhat.com> <20150515082420.GR12806@dhcp-40-8.bne.redhat.com> <5555E63D.4050808@redhat.com> <555AF9E1.1010606@redhat.com> Message-ID: <20150519115027.GA12806@dhcp-40-8.bne.redhat.com> 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 for install > and upgrade, instead of duplicating the code. > I will unify the logic in next patch set. > You shouldn't use the deprecated modify_s method of IPAdmin. > > This is not very nice: > > + sysupgrade.set_upgrade_state(*upgrade_state_args + (True,)) > Ok, I will repeat the arguments for get_upgrade_state and set_upgrade_state. > >> > >>>>Martin^2 > >>>>>>>>Other issues: > >>>>>>>>1) > >>>>>>>>I do not see modifications in API.txt file > >>>>>>>> > >>>>>>>>2) > >>>>>>>>We use new shorter license header > >>>>>>>># > >>>>>>>># Copyright (C) 2015 FreeIPA Contributors see COPYING for license > >>>>>>>># > >>>>>>>> > >>>>>>>>3) > >>>>>>>>+from ipalib.plugins.baseldap import \ > >>>>>>>>+ LDAPObject, LDAPSearch, LDAPCreate, LDAPDelete, LDAPUpdate, > >>>>>>>>LDAPRetrieve > >>>>>>>> > >>>>>>>>please use 'import ( modules, .. )' instead of '\' > >>>>>>>> > >>>>>>>>4) > >>>>>>>>+ if method == 'POST' \ > >>>>>>>>+ and 'content-type' not in (str(k).lower() for k in > >>>>>>>>headers.viewkeys()): > >>>>>>>> > >>>>>>>>again, please use if ( ... ): instead \ > >>>>>>>> > >>>>>>>>5) > >>>>>>>>+import ipalib.errors as errors > >>>>>>>>in dogtag.py > >>>>>>>> > >>>>>>>>Can you use from ipalib import errors, instead? > >>>>>>>> > >>>>>>>>6) > >>>>>>>>+ def __exit__(self, exc_type, exc_value, traceback): > >>>>>>>>+ """Log out of the REST API""" > >>>>>>>>+ # TODO logout > >>>>>>>>+ self.cookie = None > >>>>>>>> > >>>>>>>>This is forgotten, or will be this fixed later? > >>>>>>>> > >>>>>>>>7) > >>>>>>>>+ if not explanation: print resp_body # NOCOMMIT > >>>>>>>> > >>>>>>>These are all fixed for the next patchset. > >>>>>>> > >>>>>>>Thanks! > >>>>>>>Fraser > >>>>>>> > >>>>>8) You can do: > >>>>> > >>>>> Str('cn', > >>>>> primary_key=True, > >>>>> cli_name='id', > >>>>> label=_('Profile ID'), > >>>>> doc=_('Profile ID for referring to this profile'), > >>>>> pattern='^[a-zA-Z]\w*$', > >>>>> pattern_errmsg=_('invalid Profile ID'), > >>>>> ), > >>>>> > >>>>>instead of: > >>>>> > >>>>> profile_id_pattern = re.compile('^[a-zA-Z]\w*$') > >>>>> > >>>>> def validate_profile_id(ugettext, value): > >>>>> """Ensure profile ID matches form required by CA.""" > >>>>> if profile_id_pattern.match(value) is None: > >>>>> return _('invalid Profile ID') > >>>>> else: > >>>>> return None > >>>>> > >>>>> ... > >>>>> > >>>>> Str('cn', validate_profile_id, > >>>>> primary_key=True, > >>>>> cli_name='id', > >>>>> label=_('Profile ID'), > >>>>> doc=_('Profile ID for referring to this profile'), > >>>>> ), > >>>>> > >>This is nice, but I have kept the separate method so that the > >>cert-request command can use the same routine for validating the > >>profile id (this will be in a subsequent patch). > >> > >>>>>9) Please don't invent new attributes (ipaCertProfileSummary) when you > >>>>>can use existing ones (description). > >>>>> > >>>>> > >>>>>10) All the commands should call > >>>>>ipalib.plugins.cert.ca_enabled_check(). > >>>>> > >>>>> > >>>>>11) I think the File parameter of certprofile_import should be called > >>>>>just 'file'. > >>>>> > >>9, 10, 11 were addressed for this patchset. > >> > >>>>>12) IMO the profile backend should be merged in to the ra backend. I > >>>>>don't see a need to have these two separate. > >>>>> > >>>>> > >>>>>Honza > >>>>> > >>>> > >>> > >>>-- > >>>Jan Cholasta > >Thank you. > > > >I did part of review, again I have not idea about the dogtag magic > >there, so I might be completely wrong. > >Martin^2 > > > >Patches need rebase. > > > >Patch 0001: > >1) > >I'm not sure if this is added during upgrade > >+ config.set("CA", "pki_profiles_in_ldap", "True") > > > >Patch 0002: > >LGTM (upgrade solved in 0005) > > > >Patch 0003: > >I have no idea. > > > >Patch 0004: > >1) > >Can you please let it in old school way, for better readability > >sysupgrade.get_upgrade_state(*upgrade_state_args): > > > >sysupgrade.get_upgrade_state('dogtag', 'agent_allow_profile_modify') > >sysupgrade.set_upgrade_state('dogtag', 'agent_allow_profile_modify' ,True) > > > >2) > >+ conn = ipaldap.IPAdmin(self.fqdn, self.ds_port) > >+ conn.do_simple_bind(DN(('cn', 'Directory Manager')), > >self.dm_password) > >+ conn.modify_s(dn, modlist) > >+ conn.unbind() > > > >IMO You can use: > >self.ldap_connect() > >self.admin_conn.modify_s() > > > >Patch 0005: > >LGTM > > > >Patch 0006: > >LGTM > > > >Patch 0007: > >0) > > I cannot apply patch > > > >error: invalid object 100755 c6c602dc6b4582c24e4ca751ab2f91f8e683dffa > >for 'install/tools/ipa-upgradeconfig' > >fatal: git-write-tree: error building trees > >Repository lacks necessary blobs to fall back on 3-way merge. > >Cannot fall back to three-way merge. > >Patch failed at 0007 Import included profiles during install or upgrade > > > > > >1) > >+ # update `api.env.ca_host` to correct hostname > >+ # https://fedorahosted.org/freeipa/ticket/4936 > >+ api.env.ca_host = host_name > >This is something what was already fixed, maybe rebase error? > > > >2) > >+ if setup_ca: > >+ # ensure profile backend is available > >+ import ipaserver.plugins.dogtag > >Must be this import in ipa-server-install? > >Respectively why is this import required, isn't it initialized by > >api.finalize()? > > +1, what are you trying to accomplish here? > Moving the `import ipaserver.plugins.dogtag` any earlier - even to the line before `api.bootstrap(**cfg)` - fails with: AttributeError: 'Env' object has no attribute 'ra_plugin' at ipaserver/plugins/dogtag.py:1271 if api.env.ra_plugin != 'dogtag': ... Not importing it prior to `api.finalize()` causes the Backend not be loaded: AttributeError: 'NameSpace' object has no attribute 'ra_certprofile' at /sbin/ipa-server-install:1323, in main: api.Backend.ra_certprofile._read_password() I am not familiar with the plugin loading so I am probably missing something - if anyone knows how to handle this > > > >3) > >+ service.print_msg("Importing certificate profiles") > >+ api.Backend.ra_certprofile._read_password() > >+ if not api.Backend.ldap2.isconnected(): > >+ api.Backend.ldap2.connect(autobind=True) > >+ ca.import_included_profiles() > > > >Why this must be in ipa-server-install? > >Why is that not in cainstance? > > +1 > I should be able to move it back there. > > > >4) > >I'm not sure if these functions can be removed: > >Honza please take look, if it is safe > > > >- def upgrade_ipa_profile(ca, domain, fqdn) > > > >- self.step("set certificate subject base", > >self.__set_subject_in_config) > >- self.step("enabling Subject Key Identifier", > >self.enable_subject_key_identifier) > >- self.step("enabling Subject Alternative Name", > >self.enable_subject_alternative_name) > >- self.step("enabling CRL and OCSP extensions for > >certificates", self.__set_crl_ocsp_extensions) > > > >5) > >'/usr/share/ipa/profiles/{}.cfg'.format(profile_id), sub_dict) > > > >os.path.join(paths.USR_SHARE_IPA_DIR, 'profiles', ) > >please use paths from ipaplatform.paths module. > >Maybe rather create new path in ipaplatform/base/paths > >USR_SHARE_IPA_PROFILES_DIR = "/usr/share/ipa/profiles" > > > >Nitpicks: > >In several patches: > >+ except ipalib.errors.PublicError, e: > >please us except ipalib.errors.PublicError as e > > > > 6) IPA currently uses the caIPAServiceCert profile. Why don't you import > this profile and instead create a new DefaultService profile? > DefaultService is exactly this profile - but now IPA owns it, not Dogtag (https://fedorahosted.org/freeipa/ticket/4002). I called it `DefaultService' because users will now be seeing and typing profile IDs, and I thought `caIPAserviceCert' was a bit unfriendly. Happy to change it back to `caIPAserviceCert' if that is the consensus. Thanks for your reviews! Fraser > -- > Jan Cholasta From lkrispen at redhat.com Tue May 19 12:16:24 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 19 May 2015 14:16:24 +0200 Subject: [Freeipa-devel] [PATCH] manage replication topology in the shared tree In-Reply-To: <55519EAC.9000204@redhat.com> References: <552B84C5.80300@redhat.com> <55362C43.4020406@redhat.com> <55362FDC.7090104@redhat.com> <55519EAC.9000204@redhat.com> Message-ID: <555B2998.9020608@redhat.com> Hi, here is the latest patch for the plugin part, trying to address all problems found in the review Regards, Ludwig PS if you want you can get a separate diff top the last version On 05/12/2015 08:33 AM, Ludwig Krispenz wrote: > Hi, > > I did split the patches, for easier review and to share work on it. > The attachment contains 4 patches: > - the ds plugin part as submitted for review > - the changes to the ds plugin part done after review (not complete yet) > - the ipa framework part (including Petr's improvements) > - the install related part > > Regards, > Ludwig > > On 04/21/2015 01:09 PM, Petr Vobornik wrote: >> On 04/21/2015 12:53 PM, Petr Vobornik wrote: >>> On 04/13/2015 10:56 AM, Ludwig Krispenz wrote: >>>> Hi, >>>> >>>> in the attachment you find the latest state of the "topology >>>> plugin", it >>>> implements what is defined in the design page: >>>> http://www.freeipa.org/page/V4/Manage_replication_topology (which is >>>> also waiting for a reviewer) >>>> >>>> It contains the plugin itself and a core of ipa commands to manage a >>>> topology. to be really applicable, some work outside is required, >>>> eg the >>>> management of the domain level and a decision where the binddn group >>>> should be maintained. >>>> >>>> Thanks, >>>> Ludwig >>>> >>>> >>> >>> I've looked at the python part, mostly because I want to start with POC >>> of Web UI for topology. >>> >>> topology.py is clearly still a work in progress. I've reflected >>> following comments into a patch to speed things up. >>> >>> What's in the patch: >>> >>> 1. git am complains about trailing whitespaces >>> >>> 2. pep8 check produces quite a lot of issues. New code should be almost >>> with any (`E501 line too long` is not a hard rule) >>> `git diff HEAD~1 -U0 | pep8 --diff` >>> >>> 3. some typos >>> >>> 4. A lot of unused imports >>> >>> 5. Option name --sname for 'Segment identifier' is not very friendly. I >>> don't see any examples of command options in the design notes. >>> >>> 6. NO_UPG_MAGIC - leftover from other plugin? >>> >>> 7. suffix object has labels from segment >>> >>> 8. IPA framework has a support for nested object. Key is setting >>> `parent_object = 'topologysuffix'` in topologysegment object. >>> >>> 9. repl_agmt_attrs could be in topologysegment takes_params. >>> >>> 10. missing various CRUD commands like topologysuffix-find and >>> topologysuffix-show commands. >>> >>> Whats missing, not fixed: >>> 1. last 2 lines of VERSION file are not updated >>> >>> 2. Mixed terminology. Somewhere is used suffix and somewhere >>> replication >>> area or just area. >>> >>> 3. Validation >>> - suffix should check for dn >>> - existence of both ends of a segment >>> >>> 4. print of segments in suffix-show needs to be improved or removed >>> >>> To discuss: >>> a) Do params in topologysegment have to have a maxlength set? >>> >>> b) Terminology has to be united. Segments are nested in suffix but >>> sometimes are called areas and suffix is 'the suffix'. User might be >>> confused. E.g. shouldn't the object be named a topologyarea instead of >>> topologysuffix? >>> >>> c) I've added all missing CRUD commands. Are there any which we don't >>> want there, or want to restrict them. E.g. I can imagine that >>> deleting a >>> suffix should be prevented if it contains any segments (or it has to be >>> forced (--force option)) >>> >>> d) Do we want to print segments in suffix-show? >>> >>> e) Mainly for Honza: I've added --show-segments option to suffix-show >>> which defaults to True. I don't like the behavior of CLI, which asks to >>> confirm the value all the time. My intention was to have it there by >>> default, but also allow to disable it by --show-segments=False. I don't >>> want to add it as Flag (--hide-segments) since it restricts >>> versatility. >>> I would like to see an optional flag which would be filled by default >>> value if not explicitly defined and CLI would not ask for the option >>> value. >>> >>> >> >> Also it would be better to split the work into more patches. E.g. DS >> plugin, installation, python plugin. So ds plugin review could be >> separated from the python part. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-lkrispen-0003-plugin-part-manage-replication-topology-in-the-shaer.patch Type: text/x-patch Size: 151693 bytes Desc: not available URL: From dkupka at redhat.com Tue May 19 12:31:34 2015 From: dkupka at redhat.com (David Kupka) Date: Tue, 19 May 2015 14:31:34 +0200 Subject: [Freeipa-devel] [PATCHES 0033-0034] fix recent bugs introduced by letting httpd use file-based ccache In-Reply-To: <555605A2.8000704@redhat.com> References: <5555FFC6.3090507@redhat.com> <555601E7.1060408@redhat.com> <555605A2.8000704@redhat.com> Message-ID: <555B2D26.40908@redhat.com> 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 From jcholast at redhat.com Tue May 19 12:43:30 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 19 May 2015 14:43:30 +0200 Subject: [Freeipa-devel] [PATCHES 0239-0243] Server Upgrade: minor fixes In-Reply-To: <5553500D.2080606@redhat.com> References: <5551F5B5.6010702@redhat.com> <5553500D.2080606@redhat.com> Message-ID: <555B2FF2.70704@redhat.com> 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 From jcholast at redhat.com Tue May 19 12:46:08 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 19 May 2015 14:46:08 +0200 Subject: [Freeipa-devel] [PATCH 0245] Fix uniqueness plugins vol. 2 In-Reply-To: <55532DF7.20003@redhat.com> References: <55522905.505@redhat.com> <55524E7F.7050403@redhat.com> <55532DF7.20003@redhat.com> Message-ID: <555B3090.1060100@redhat.com> 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 From jcholast at redhat.com Tue May 19 12:48:22 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 19 May 2015 14:48:22 +0200 Subject: [Freeipa-devel] [PATCH 0248] DNSSEC: Fix: Do not recreate kasp.db if already exists In-Reply-To: <5555C61A.6090507@redhat.com> References: <5554BA9A.8050202@redhat.com> <5555C61A.6090507@redhat.com> Message-ID: <555B3116.2090404@redhat.com> 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 From jcholast at redhat.com Tue May 19 12:51:29 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 19 May 2015 14:51:29 +0200 Subject: [Freeipa-devel] [PATCH 0249] DNSSEC: update kasp configuration template: increase key size & lifetime In-Reply-To: <5555D96D.5030300@redhat.com> References: <5554BDEB.8070704@redhat.com> <5555D4AD.10404@redhat.com> <5555D96D.5030300@redhat.com> Message-ID: <555B31D1.9000409@redhat.com> 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 From jcholast at redhat.com Tue May 19 12:54:30 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 19 May 2015 14:54:30 +0200 Subject: [Freeipa-devel] [PATCH] 0048 Remove unused enable() method from DogtagInstance. In-Reply-To: <5554C22F.5090307@redhat.com> References: <5551E99F.80003@redhat.com> <5551EF29.7000501@redhat.com> <55521438.8060503@redhat.com> <55532277.5010703@redhat.com> <5554C22F.5090307@redhat.com> Message-ID: <555B3286.4060004@redhat.com> 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 From jcholast at redhat.com Tue May 19 12:59:40 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 19 May 2015 14:59:40 +0200 Subject: [Freeipa-devel] [PATCHES 0033-0034] fix recent bugs introduced by letting httpd use file-based ccache In-Reply-To: <555B2D26.40908@redhat.com> References: <5555FFC6.3090507@redhat.com> <555601E7.1060408@redhat.com> <555605A2.8000704@redhat.com> <555B2D26.40908@redhat.com> Message-ID: <555B33BC.9030308@redhat.com> 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 From tbabej at redhat.com Tue May 19 13:22:19 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 19 May 2015 15:22:19 +0200 Subject: [Freeipa-devel] [PATCH 0325] Add Domain Level feature In-Reply-To: <55546F6C.4060108@redhat.com> References: <5554643E.4030600@redhat.com> <55546F6C.4060108@redhat.com> Message-ID: <555B390B.6000907@redhat.com> 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: > . 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0325-2-Add-Domain-Level-feature.patch Type: text/x-patch Size: 15059 bytes Desc: not available URL: From mkosek at redhat.com Tue May 19 13:36:33 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 19 May 2015 15:36:33 +0200 Subject: [Freeipa-devel] [PATCH 0325] Add Domain Level feature In-Reply-To: <555B390B.6000907@redhat.com> References: <5554643E.4030600@redhat.com> <55546F6C.4060108@redhat.com> <555B390B.6000907@redhat.com> Message-ID: <555B3C61.7080508@redhat.com> 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. From jcholast at redhat.com Tue May 19 13:40:15 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 19 May 2015 15:40:15 +0200 Subject: [Freeipa-devel] [PATCH 0325] Add Domain Level feature In-Reply-To: <555B390B.6000907@redhat.com> References: <5554643E.4030600@redhat.com> <55546F6C.4060108@redhat.com> <555B390B.6000907@redhat.com> Message-ID: <555B3D3F.9010204@redhat.com> 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: >> . > > 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 From lkrispen at redhat.com Tue May 19 13:49:27 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 19 May 2015 15:49:27 +0200 Subject: [Freeipa-devel] [PATCH 0325] Add Domain Level feature In-Reply-To: <555B3C61.7080508@redhat.com> References: <5554643E.4030600@redhat.com> <55546F6C.4060108@redhat.com> <555B390B.6000907@redhat.com> <555B3C61.7080508@redhat.com> Message-ID: <555B3F67.3040604@redhat.com> 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 From mkosek at redhat.com Tue May 19 13:51:58 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 19 May 2015 15:51:58 +0200 Subject: [Freeipa-devel] [PATCH 0325] Add Domain Level feature In-Reply-To: <555B3F67.3040604@redhat.com> References: <5554643E.4030600@redhat.com> <55546F6C.4060108@redhat.com> <555B390B.6000907@redhat.com> <555B3C61.7080508@redhat.com> <555B3F67.3040604@redhat.com> Message-ID: <555B3FFE.5040806@redhat.com> 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 :-) From tbabej at redhat.com Tue May 19 13:56:34 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 19 May 2015 15:56:34 +0200 Subject: [Freeipa-devel] [PATCH 0325] Add Domain Level feature In-Reply-To: <555B3FFE.5040806@redhat.com> References: <5554643E.4030600@redhat.com> <55546F6C.4060108@redhat.com> <555B390B.6000907@redhat.com> <555B3C61.7080508@redhat.com> <555B3F67.3040604@redhat.com> <555B3FFE.5040806@redhat.com> Message-ID: <555B4112.202@redhat.com> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0325-3-Add-Domain-Level-feature.patch Type: text/x-patch Size: 15082 bytes Desc: not available URL: From mkosek at redhat.com Tue May 19 13:59:36 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 19 May 2015 15:59:36 +0200 Subject: [Freeipa-devel] [PATCH 0325] Add Domain Level feature In-Reply-To: <555B4112.202@redhat.com> References: <5554643E.4030600@redhat.com> <55546F6C.4060108@redhat.com> <555B390B.6000907@redhat.com> <555B3C61.7080508@redhat.com> <555B3F67.3040604@redhat.com> <555B3FFE.5040806@redhat.com> <555B4112.202@redhat.com> Message-ID: <555B41C8.7070503@redhat.com> 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 ... From tbabej at redhat.com Tue May 19 14:07:55 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 19 May 2015 16:07:55 +0200 Subject: [Freeipa-devel] [PATCH 0325] Add Domain Level feature In-Reply-To: <555B41C8.7070503@redhat.com> References: <5554643E.4030600@redhat.com> <55546F6C.4060108@redhat.com> <555B390B.6000907@redhat.com> <555B3C61.7080508@redhat.com> <555B3F67.3040604@redhat.com> <555B3FFE.5040806@redhat.com> <555B4112.202@redhat.com> <555B41C8.7070503@redhat.com> Message-ID: <555B43BB.90404@redhat.com> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0325-4-Add-Domain-Level-feature.patch Type: text/x-patch Size: 15083 bytes Desc: not available URL: From mbabinsk at redhat.com Tue May 19 14:19:42 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 19 May 2015 16:19:42 +0200 Subject: [Freeipa-devel] [PATCH 0035] do not check for directory manager password during KRA uninstall In-Reply-To: <555B1BD6.6040406@redhat.com> References: <555B1BD6.6040406@redhat.com> Message-ID: <555B467E.2000202@redhat.com> On 05/19/2015 01:17 PM, Martin Babinsky wrote: > https://fedorahosted.org/freeipa/ticket/5028 > > > updated patch attached -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0035.1-do-not-check-for-directory-manager-password-during-K.patch Type: text/x-patch Size: 3174 bytes Desc: not available URL: From rcritten at redhat.com Tue May 19 14:20:06 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 19 May 2015 10:20:06 -0400 Subject: [Freeipa-devel] [PATCH] 1112 Add service constraint delegation plugin Message-ID: <555B4696.2070502@redhat.com> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1112-Add-plugin-to-manage-service-constraints.patch Type: text/x-diff Size: 42219 bytes Desc: not available URL: From jcholast at redhat.com Tue May 19 14:22:20 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 19 May 2015 16:22:20 +0200 Subject: [Freeipa-devel] [PATCH 0247] Modularization of the DNS subsytem installer In-Reply-To: <55560636.8020408@redhat.com> References: <5554A01F.5040506@redhat.com> <55560636.8020408@redhat.com> Message-ID: <555B471C.9000007@redhat.com> 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 From edewata at redhat.com Tue May 19 14:40:00 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 19 May 2015 09:40:00 -0500 Subject: [Freeipa-devel] [PATCH] Password vault In-Reply-To: <555AF3EC.1060100@redhat.com> References: <54E1AF55.3060409@redhat.com> <54EBEB55.6010306@redhat.com> <54F96B22.9050507@redhat.com> <55004D5D.6060300@redhat.com> <550FE5EB.1070606@redhat.com> <551E0AE1.8040500@redhat.com> <553498D1.1020901@redhat.com> <5551DB57.6060504@redhat.com> <555314D1.6070304@redhat.com> <55541015.3040206@redhat.com> <5554ECAE.8030908@redhat.com> <55553B0A.10800@redhat.com> <555A3ACF.3000305@redhat.com> <555AF3EC.1060100@redhat.com> Message-ID: <555B4B40.1060702@redhat.com> 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=. >> >> 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=, >>>>> cn=users, cn=vaults). The entry cn=, cn=, 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/@, 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, and the parent container cn=B, >>>>> 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 without recursion, like my code does: > > + def create_container(self, dn): > + """ > + Creates vault container and its parents. > + """ > + > + container_dn = DN(self.container_dn, self.api.env.basedn) > + assert dn.endswith(container_dn) > + > + dns = [] > + while dn.endswith(container_dn): > + dns.insert(0, dn) > + dn = DN(*dn[1:]) > + > + for dn in dns: > + entry = self.backend.make_entry( > + dn, > + objectclass=['nsContainer'], > + cn=[dn[0]['cn']], > + ) > + > + try: > + self.backend.add_entry(entry) > + except errors.DuplicateEntry: > + pass There is an obvious inefficiency here: all containers in the path (including the built-in ones) will be re-added on every vault-add operation. I don't see anything wrong with recursions, especially if it works more efficiently since only the immediate parent will be re-added. So for example, with the loop every time you add a private vault you're guaranteed to have three failed LDAP Add operations whereas with the recursion there's only one failed operation. Do you still want to use the loop? -- Endi S. Dewata From mbasti at redhat.com Tue May 19 14:41:11 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 19 May 2015 16:41:11 +0200 Subject: [Freeipa-devel] [PATCH 0035] do not check for directory manager password during KRA uninstall In-Reply-To: <555B467E.2000202@redhat.com> References: <555B1BD6.6040406@redhat.com> <555B467E.2000202@redhat.com> Message-ID: <555B4B87.1070406@redhat.com> 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 From ofayans at redhat.com Tue May 19 15:21:04 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 19 May 2015 17:21:04 +0200 Subject: [Freeipa-devel] [UPSTREAM_FAILURES] Latest changes affect freeipa builds and client configuration Message-ID: <555B54E0.7090004@redhat.com> 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. 2. Today the master branch fails to build at all with the following exception: cd install; if [ ! -e Makefile ]; then ../autogen.sh --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir=/usr/lib; fi ./make-lint =============================================================================== Errors were found during the static code check. If you are certain that any of the reported errors are false positives, please mark them in the source code according to the pylint documentation. =============================================================================== ************* Module ipa-server-install install/tools/ipa-server-install:955: [E1103(maybe-no-member), main] Instance of 'bool' has no 'lower' member (but some types could not be inferred)) install/tools/ipa-server-install:955: [E1103(maybe-no-member), main] Instance of 'int' has no 'lower' member (but some types could not be inferred)) Makefile:119: recipe for target 'lint' failed Just wanted to inform you. -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: 18052015.tar.gz Type: application/gzip Size: 151990 bytes Desc: not available URL: From tbordaz at redhat.com Tue May 19 15:34:46 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 19 May 2015 17:34:46 +0200 Subject: [Freeipa-devel] [PATCH] 832-850 Stage Users Web UI and its prerequisites In-Reply-To: <555612D9.3020306@redhat.com> References: <5555B58D.8010804@redhat.com> <5555CBB3.1060003@redhat.com> <555612D9.3020306@redhat.com> Message-ID: <555B5816.3070304@redhat.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Tue May 19 15:42:15 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 19 May 2015 17:42:15 +0200 Subject: [Freeipa-devel] [UPSTREAM_FAILURES] Latest changes affect freeipa builds and client configuration In-Reply-To: <555B54E0.7090004@redhat.com> References: <555B54E0.7090004@redhat.com> Message-ID: <555B59D7.6020509@redhat.com> 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 From tbordaz at redhat.com Tue May 19 15:54:01 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 19 May 2015 17:54:01 +0200 Subject: [Freeipa-devel] [TEST PLAN] User lifecycle plugin In-Reply-To: <555373C7.2070007@redhat.com> References: <1431521873.3392.6.camel@dhcp130-146.brq.redhat.com> <55537169.4000308@redhat.com> <555373C7.2070007@redhat.com> Message-ID: <555B5C99.1070409@redhat.com> 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 >> " 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue May 19 15:55:00 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 19 May 2015 17:55:00 +0200 Subject: [Freeipa-devel] [PATCH 0035] do not check for directory manager password during KRA uninstall In-Reply-To: <555B4B87.1070406@redhat.com> References: <555B1BD6.6040406@redhat.com> <555B467E.2000202@redhat.com> <555B4B87.1070406@redhat.com> Message-ID: <555B5CD4.7050001@redhat.com> 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 From mbabinsk at redhat.com Tue May 19 16:01:33 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 19 May 2015 18:01:33 +0200 Subject: [Freeipa-devel] [PATCH] 851-852 webui: datetime widget with datepicker In-Reply-To: <5559EBE5.3060502@redhat.com> References: <5559EBE5.3060502@redhat.com> Message-ID: <555B5E5D.1060103@redhat.com> 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 From mbabinsk at redhat.com Tue May 19 16:01:57 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 19 May 2015 18:01:57 +0200 Subject: [Freeipa-devel] [PATCH] 830 webui: fix empty table border in Firefox In-Reply-To: <5555B5FF.1040801@redhat.com> References: <5555B5FF.1040801@redhat.com> Message-ID: <555B5E75.7030801@redhat.com> 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 From mbasti at redhat.com Tue May 19 16:35:37 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 19 May 2015 18:35:37 +0200 Subject: [Freeipa-devel] [UPSTREAM_FAILURES] Latest changes affect freeipa builds and client configuration In-Reply-To: <555B54E0.7090004@redhat.com> References: <555B54E0.7090004@redhat.com> Message-ID: <555B6659.1020906@redhat.com> On 19/05/15 17:21, 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. > > 2. Today the master branch fails to build at all with the following > exception: > > cd install; if [ ! -e Makefile ]; then ../autogen.sh --prefix=/usr > --sysconfdir=/etc --localstatedir=/var --libdir=/usr/lib; fi > ./make-lint > > =============================================================================== > Errors were found during the static code check. > > If you are certain that any of the reported errors are false positives, > please > mark them in the source code according to the pylint documentation. > =============================================================================== > > ************* Module ipa-server-install > install/tools/ipa-server-install:955: [E1103(maybe-no-member), main] > Instance of 'bool' has no 'lower' member (but some types could not be > inferred)) > install/tools/ipa-server-install:955: [E1103(maybe-no-member), main] > Instance of 'int' has no 'lower' member (but some types could not be > inferred)) > Makefile:119: recipe for target 'lint' failed > > Just wanted to inform you. > > This lint warning are only on F21. Now I just successfully build master on F22. I will send a patch to fix F21. -- Martin Basti From mbasti at redhat.com Tue May 19 16:56:54 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 19 May 2015 18:56:54 +0200 Subject: [Freeipa-devel] [PATCH 0250] Pylint: fix false positive warning Message-ID: <555B6B56.9020604@redhat.com> Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0250-Pylint-fix-false-positive-warning-for-domain.patch Type: text/x-patch Size: 867 bytes Desc: not available URL: From pvoborni at redhat.com Tue May 19 17:15:53 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 19 May 2015 19:15:53 +0200 Subject: [Freeipa-devel] [PATCH 0250] Pylint: fix false positive warning In-Reply-To: <555B6B56.9020604@redhat.com> References: <555B6B56.9020604@redhat.com> Message-ID: <555B6FC9.3060508@redhat.com> On 05/19/2015 06:56 PM, Martin Basti wrote: > Patch attached. > ACK Pushed to master: ab69a0b1a74e639d23ba8e684d402eaf7582c67c -- Petr Vobornik From pvoborni at redhat.com Tue May 19 17:22:01 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 19 May 2015 19:22:01 +0200 Subject: [Freeipa-devel] [PATCH] 832-850 Stage Users Web UI and its prerequisites In-Reply-To: <555B5816.3070304@redhat.com> References: <5555B58D.8010804@redhat.com> <5555CBB3.1060003@redhat.com> <555612D9.3020306@redhat.com> <555B5816.3070304@redhat.com> Message-ID: <555B7139.4090706@redhat.com> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0853-webui-prefer-search-facet-s-deleter-dialog.patch Type: text/x-patch Size: 2130 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0850-1-webui-stageusers-display-page-elements-based-on-user.patch Type: text/x-patch Size: 14425 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0849-1-webui-update-stageuser-user-pages-based-on-action-in.patch Type: text/x-patch Size: 2414 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0848-1-webui-extend-user-deleter-dialog-with-permanent-and-.patch Type: text/x-patch Size: 2567 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0847-2-webui-stageuser-plugin.patch Type: text/x-patch Size: 19362 bytes Desc: not available URL: From mbabinsk at redhat.com Tue May 19 18:14:04 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 19 May 2015 20:14:04 +0200 Subject: [Freeipa-devel] [PATCH 0035] do not check for directory manager password during KRA uninstall In-Reply-To: <555B5CD4.7050001@redhat.com> References: <555B1BD6.6040406@redhat.com> <555B467E.2000202@redhat.com> <555B4B87.1070406@redhat.com> <555B5CD4.7050001@redhat.com> Message-ID: <555B7D6C.2050805@redhat.com> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0035.2-do-not-check-for-directory-manager-password-during-K.patch Type: text/x-patch Size: 3176 bytes Desc: not available URL: From mbabinsk at redhat.com Tue May 19 18:23:44 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 19 May 2015 20:23:44 +0200 Subject: [Freeipa-devel] [PATCH 0036] merge KRA installation machinery to a single module Message-ID: <555B7FB0.6030809@redhat.com> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0036-merge-KRA-installation-machinery-to-a-single-module.patch Type: text/x-patch Size: 15585 bytes Desc: not available URL: From rcritten at redhat.com Tue May 19 20:46:13 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 19 May 2015 16:46:13 -0400 Subject: [Freeipa-devel] [PATCH] 1112 Add service constraint delegation plugin In-Reply-To: <555B4696.2070502@redhat.com> References: <555B4696.2070502@redhat.com> Message-ID: <555BA115.5070408@redhat.com> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1112-2-Add-plugin-to-manage-service-constraints.patch Type: text/x-diff Size: 42219 bytes Desc: not available URL: From ftweedal at redhat.com Wed May 20 02:52:06 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 20 May 2015 12:52:06 +1000 Subject: [Freeipa-devel] [UPSTREAM_FAILURES] Latest changes affect freeipa builds and client configuration In-Reply-To: <555B59D7.6020509@redhat.com> References: <555B54E0.7090004@redhat.com> <555B59D7.6020509@redhat.com> Message-ID: <20150520025206.GD12806@dhcp-40-8.bne.redhat.com> 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 From ftweedal at redhat.com Wed May 20 05:31:12 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 20 May 2015 15:31:12 +1000 Subject: [Freeipa-devel] IPAUpgrade.create_instance causing ipa-server-install failure Message-ID: <20150520053112.GE12806@dhcp-40-8.bne.redhat.com> 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 at 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 at 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 '/usr/lib/python2.7/site-packages/ipalib/plugins/otpconfig.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/otptoken.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/otptoken_yubikey.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/passwd.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/permission.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/ping.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/pkinit.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/privilege.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/pwpolicy.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/radiusproxy.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/realmdomains.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/role.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/rpcclient.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/selfservice.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/selinuxusermap.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/service.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/stageuser.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmd.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmdgroup.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/sudorule.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/trust.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/user.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/virtual.py' 2015-05-20T03:50:41Z DEBUG importing all plugin modules in '/usr/lib/python2.7/site-packages/ipaserver/install/plugins'... 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/adtrust.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/ca_renewal_master.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/fix_replica_agreements.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/rename_managed.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_idranges.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_managed_permissions.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_pacs.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_passsync.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_referint.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_services.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_uniqueness.py' 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/upload_cacrt.py' 2015-05-20T03:50:41Z ERROR Upgrade failed with cannot connect to 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': 2015-05-20T03:50:41Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 304, in __upgrade ld = ldapupdate.LDAPUpdate(dm_password='', ldapi=True) File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 314, in __init__ self.create_connection() File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 862, in create_connection autobind=self.ldapi) File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 66, in connect conn = self.create_connection(*args, **kw) File "/usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py", line 188, in create_connection client_controls=clientctrls) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1074, in external_bind '', auth_tokens, server_controls, client_controls) File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ self.gen.throw(type, value, traceback) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 976, in error_handler error=info) NetworkError: cannot connect to 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': 2015-05-20T03:50:41Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 388, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 378, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 315, in __upgrade raise RuntimeError(e) RuntimeError: cannot connect to 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': 2015-05-20T03:50:41Z DEBUG [error] RuntimeError: cannot connect to 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': 2015-05-20T03:50:41Z DEBUG [cleanup]: stopping directory server 2015-05-20T03:50:41Z DEBUG Starting external process 2015-05-20T03:50:41Z DEBUG args='/bin/systemctl' 'stop' 'dirsrv at IPA-LOCAL.service' 2015-05-20T03:50:41Z DEBUG Process finished, return code=0 2015-05-20T03:50:41Z DEBUG stdout= 2015-05-20T03:50:41Z DEBUG stderr= 2015-05-20T03:50:41Z DEBUG duration: 0 seconds 2015-05-20T03:50:41Z DEBUG [cleanup]: restoring configuration 2015-05-20T03:50:41Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2015-05-20T03:50:41Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2015-05-20T03:50:41Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2015-05-20T03:50:41Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2015-05-20T03:50:41Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2015-05-20T03:50:41Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2015-05-20T03:50:41Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2015-05-20T03:50:41Z DEBUG duration: 0 seconds 2015-05-20T03:50:41Z DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 733, in run_script return_value = main_function() File "/sbin/ipa-server-install", line 1263, in main ds.apply_updates() File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 513, in apply_updates raise RuntimeError("Update failed: %s" % e) 2015-05-20T03:50:41Z DEBUG The ipa-server-install command failed, exception: RuntimeError: Update failed: cannot connect to 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': From jcholast at redhat.com Wed May 20 05:40:44 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 20 May 2015 07:40:44 +0200 Subject: [Freeipa-devel] [PATCHES 0001-0007] Profile management In-Reply-To: <20150519115027.GA12806@dhcp-40-8.bne.redhat.com> References: <20150504133641.GQ16379@dhcp-40-8.bne.redhat.com> <55479FE1.1020005@redhat.com> <20150505062934.GU16379@dhcp-40-8.bne.redhat.com> <5548816D.6050304@redhat.com> <555305EC.5020001@redhat.com> <55530D23.5040702@redhat.com> <55530DDB.9000101@redhat.com> <20150515082420.GR12806@dhcp-40-8.bne.redhat.com> <5555E63D.4050808@redhat.com> <555AF9E1.1010606@redhat.com> <20150519115027.GA12806@dhcp-40-8.bne.redhat.com> Message-ID: <555C1E5C.2080707@redhat.com> 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 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. >> > I will unify the logic in next patch set. > >> You shouldn't use the deprecated modify_s method of IPAdmin. >> >> This is not very nice: >> >> + sysupgrade.set_upgrade_state(*upgrade_state_args + (True,)) >> > Ok, I will repeat the arguments for get_upgrade_state and > set_upgrade_state. Thanks. What you did is perfectly valid Python, but let's keep the code readable. > >>>> >>>>>> Martin^2 >>>>>>>>>> Other issues: >>>>>>>>>> 1) >>>>>>>>>> I do not see modifications in API.txt file >>>>>>>>>> >>>>>>>>>> 2) >>>>>>>>>> We use new shorter license header >>>>>>>>>> # >>>>>>>>>> # Copyright (C) 2015 FreeIPA Contributors see COPYING for license >>>>>>>>>> # >>>>>>>>>> >>>>>>>>>> 3) >>>>>>>>>> +from ipalib.plugins.baseldap import \ >>>>>>>>>> + LDAPObject, LDAPSearch, LDAPCreate, LDAPDelete, LDAPUpdate, >>>>>>>>>> LDAPRetrieve >>>>>>>>>> >>>>>>>>>> please use 'import ( modules, .. )' instead of '\' >>>>>>>>>> >>>>>>>>>> 4) >>>>>>>>>> + if method == 'POST' \ >>>>>>>>>> + and 'content-type' not in (str(k).lower() for k in >>>>>>>>>> headers.viewkeys()): >>>>>>>>>> >>>>>>>>>> again, please use if ( ... ): instead \ >>>>>>>>>> >>>>>>>>>> 5) >>>>>>>>>> +import ipalib.errors as errors >>>>>>>>>> in dogtag.py >>>>>>>>>> >>>>>>>>>> Can you use from ipalib import errors, instead? >>>>>>>>>> >>>>>>>>>> 6) >>>>>>>>>> + def __exit__(self, exc_type, exc_value, traceback): >>>>>>>>>> + """Log out of the REST API""" >>>>>>>>>> + # TODO logout >>>>>>>>>> + self.cookie = None >>>>>>>>>> >>>>>>>>>> This is forgotten, or will be this fixed later? >>>>>>>>>> >>>>>>>>>> 7) >>>>>>>>>> + if not explanation: print resp_body # NOCOMMIT >>>>>>>>>> >>>>>>>>> These are all fixed for the next patchset. >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> Fraser >>>>>>>>> >>>>>>> 8) You can do: >>>>>>> >>>>>>> Str('cn', >>>>>>> primary_key=True, >>>>>>> cli_name='id', >>>>>>> label=_('Profile ID'), >>>>>>> doc=_('Profile ID for referring to this profile'), >>>>>>> pattern='^[a-zA-Z]\w*$', >>>>>>> pattern_errmsg=_('invalid Profile ID'), >>>>>>> ), >>>>>>> >>>>>>> instead of: >>>>>>> >>>>>>> profile_id_pattern = re.compile('^[a-zA-Z]\w*$') >>>>>>> >>>>>>> def validate_profile_id(ugettext, value): >>>>>>> """Ensure profile ID matches form required by CA.""" >>>>>>> if profile_id_pattern.match(value) is None: >>>>>>> return _('invalid Profile ID') >>>>>>> else: >>>>>>> return None >>>>>>> >>>>>>> ... >>>>>>> >>>>>>> Str('cn', validate_profile_id, >>>>>>> primary_key=True, >>>>>>> cli_name='id', >>>>>>> label=_('Profile ID'), >>>>>>> doc=_('Profile ID for referring to this profile'), >>>>>>> ), >>>>>>> >>>> This is nice, but I have kept the separate method so that the >>>> cert-request command can use the same routine for validating the >>>> profile id (this will be in a subsequent patch). >>>> >>>>>>> 9) Please don't invent new attributes (ipaCertProfileSummary) when you >>>>>>> can use existing ones (description). >>>>>>> >>>>>>> >>>>>>> 10) All the commands should call >>>>>>> ipalib.plugins.cert.ca_enabled_check(). >>>>>>> >>>>>>> >>>>>>> 11) I think the File parameter of certprofile_import should be called >>>>>>> just 'file'. >>>>>>> >>>> 9, 10, 11 were addressed for this patchset. >>>> >>>>>>> 12) IMO the profile backend should be merged in to the ra backend. I >>>>>>> don't see a need to have these two separate. >>>>>>> >>>>>>> >>>>>>> Honza >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> Jan Cholasta >>> Thank you. >>> >>> I did part of review, again I have not idea about the dogtag magic >>> there, so I might be completely wrong. >>> Martin^2 >>> >>> Patches need rebase. >>> >>> Patch 0001: >>> 1) >>> I'm not sure if this is added during upgrade >>> + config.set("CA", "pki_profiles_in_ldap", "True") >>> >>> Patch 0002: >>> LGTM (upgrade solved in 0005) >>> >>> Patch 0003: >>> I have no idea. >>> >>> Patch 0004: >>> 1) >>> Can you please let it in old school way, for better readability >>> sysupgrade.get_upgrade_state(*upgrade_state_args): >>> >>> sysupgrade.get_upgrade_state('dogtag', 'agent_allow_profile_modify') >>> sysupgrade.set_upgrade_state('dogtag', 'agent_allow_profile_modify' ,True) >>> >>> 2) >>> + conn = ipaldap.IPAdmin(self.fqdn, self.ds_port) >>> + conn.do_simple_bind(DN(('cn', 'Directory Manager')), >>> self.dm_password) >>> + conn.modify_s(dn, modlist) >>> + conn.unbind() >>> >>> IMO You can use: >>> self.ldap_connect() >>> self.admin_conn.modify_s() >>> >>> Patch 0005: >>> LGTM >>> >>> Patch 0006: >>> LGTM >>> >>> Patch 0007: >>> 0) >>> I cannot apply patch >>> >>> error: invalid object 100755 c6c602dc6b4582c24e4ca751ab2f91f8e683dffa >>> for 'install/tools/ipa-upgradeconfig' >>> fatal: git-write-tree: error building trees >>> Repository lacks necessary blobs to fall back on 3-way merge. >>> Cannot fall back to three-way merge. >>> Patch failed at 0007 Import included profiles during install or upgrade >>> >>> >>> 1) >>> + # update `api.env.ca_host` to correct hostname >>> + # https://fedorahosted.org/freeipa/ticket/4936 >>> + api.env.ca_host = host_name >>> This is something what was already fixed, maybe rebase error? >>> >>> 2) >>> + if setup_ca: >>> + # ensure profile backend is available >>> + import ipaserver.plugins.dogtag >>> Must be this import in ipa-server-install? >>> Respectively why is this import required, isn't it initialized by >>> api.finalize()? >> >> +1, what are you trying to accomplish here? >> > Moving the `import ipaserver.plugins.dogtag` any earlier - even to > the line before `api.bootstrap(**cfg)` - fails with: > > AttributeError: 'Env' object has no attribute 'ra_plugin' > > at ipaserver/plugins/dogtag.py:1271 > > if api.env.ra_plugin != 'dogtag': > ... > > Not importing it prior to `api.finalize()` causes the Backend not be > loaded: > > AttributeError: 'NameSpace' object has no attribute 'ra_certprofile' > > at /sbin/ipa-server-install:1323, in main: > > api.Backend.ra_certprofile._read_password() > > I am not familiar with the plugin loading so I am probably missing > something - if anyone knows how to handle this This is because ipaserver plugins aren't automatically loaded in installers. I guess we can change that, as we alredy use ldap2 anyway. The code responsible for this is API.bootstrap() in ipalib/__init__.py. > >>> >>> 3) >>> + service.print_msg("Importing certificate profiles") >>> + api.Backend.ra_certprofile._read_password() >>> + if not api.Backend.ldap2.isconnected(): >>> + api.Backend.ldap2.connect(autobind=True) >>> + ca.import_included_profiles() >>> >>> Why this must be in ipa-server-install? >>> Why is that not in cainstance? >> >> +1 >> > I should be able to move it back there. > >>> >>> 4) >>> I'm not sure if these functions can be removed: >>> Honza please take look, if it is safe >>> >>> - def upgrade_ipa_profile(ca, domain, fqdn) >>> >>> - self.step("set certificate subject base", >>> self.__set_subject_in_config) >>> - self.step("enabling Subject Key Identifier", >>> self.enable_subject_key_identifier) >>> - self.step("enabling Subject Alternative Name", >>> self.enable_subject_alternative_name) >>> - self.step("enabling CRL and OCSP extensions for >>> certificates", self.__set_crl_ocsp_extensions) >>> >>> 5) >>> '/usr/share/ipa/profiles/{}.cfg'.format(profile_id), sub_dict) >>> >>> os.path.join(paths.USR_SHARE_IPA_DIR, 'profiles', ) >>> please use paths from ipaplatform.paths module. >>> Maybe rather create new path in ipaplatform/base/paths >>> USR_SHARE_IPA_PROFILES_DIR = "/usr/share/ipa/profiles" >>> >>> Nitpicks: >>> In several patches: >>> + except ipalib.errors.PublicError, e: >>> please us except ipalib.errors.PublicError as e >>> >> >> 6) IPA currently uses the caIPAServiceCert profile. Why don't you import >> this profile and instead create a new DefaultService profile? >> > DefaultService is exactly this profile - but now IPA owns it, not > Dogtag (https://fedorahosted.org/freeipa/ticket/4002). I called it > `DefaultService' because users will now be seeing and typing profile > IDs, and I thought `caIPAserviceCert' was a bit unfriendly. > > Happy to change it back to `caIPAserviceCert' if that is the > consensus. I would prefer if the name stayed the same, for backward compatibility. On upgrade you should import the original profile instead of the new one bundled with IPA, so that if the admins did some manual modifications, they won't lose them. > > Thanks for your reviews! > Fraser > >> -- >> Jan Cholasta -- Jan Cholasta From ftweedal at redhat.com Wed May 20 05:56:36 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 20 May 2015 15:56:36 +1000 Subject: [Freeipa-devel] [PATCHES 0001-0007] Profile management In-Reply-To: <555C1E5C.2080707@redhat.com> References: <20150505062934.GU16379@dhcp-40-8.bne.redhat.com> <5548816D.6050304@redhat.com> <555305EC.5020001@redhat.com> <55530D23.5040702@redhat.com> <55530DDB.9000101@redhat.com> <20150515082420.GR12806@dhcp-40-8.bne.redhat.com> <5555E63D.4050808@redhat.com> <555AF9E1.1010606@redhat.com> <20150519115027.GA12806@dhcp-40-8.bne.redhat.com> <555C1E5C.2080707@redhat.com> Message-ID: <20150520055636.GF12806@dhcp-40-8.bne.redhat.com> 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 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. > >> > >I will unify the logic in next patch set. > > > >>You shouldn't use the deprecated modify_s method of IPAdmin. > >> > >>This is not very nice: > >> > >>+ sysupgrade.set_upgrade_state(*upgrade_state_args + (True,)) > >> > >Ok, I will repeat the arguments for get_upgrade_state and > >set_upgrade_state. > > Thanks. What you did is perfectly valid Python, but let's keep the code > readable. > I am a very DRY person :) > > > >>>> > >>>>>>Martin^2 > >>>>>>>>>>Other issues: > >>>>>>>>>>1) > >>>>>>>>>>I do not see modifications in API.txt file > >>>>>>>>>> > >>>>>>>>>>2) > >>>>>>>>>>We use new shorter license header > >>>>>>>>>># > >>>>>>>>>># Copyright (C) 2015 FreeIPA Contributors see COPYING for license > >>>>>>>>>># > >>>>>>>>>> > >>>>>>>>>>3) > >>>>>>>>>>+from ipalib.plugins.baseldap import \ > >>>>>>>>>>+ LDAPObject, LDAPSearch, LDAPCreate, LDAPDelete, LDAPUpdate, > >>>>>>>>>>LDAPRetrieve > >>>>>>>>>> > >>>>>>>>>>please use 'import ( modules, .. )' instead of '\' > >>>>>>>>>> > >>>>>>>>>>4) > >>>>>>>>>>+ if method == 'POST' \ > >>>>>>>>>>+ and 'content-type' not in (str(k).lower() for k in > >>>>>>>>>>headers.viewkeys()): > >>>>>>>>>> > >>>>>>>>>>again, please use if ( ... ): instead \ > >>>>>>>>>> > >>>>>>>>>>5) > >>>>>>>>>>+import ipalib.errors as errors > >>>>>>>>>>in dogtag.py > >>>>>>>>>> > >>>>>>>>>>Can you use from ipalib import errors, instead? > >>>>>>>>>> > >>>>>>>>>>6) > >>>>>>>>>>+ def __exit__(self, exc_type, exc_value, traceback): > >>>>>>>>>>+ """Log out of the REST API""" > >>>>>>>>>>+ # TODO logout > >>>>>>>>>>+ self.cookie = None > >>>>>>>>>> > >>>>>>>>>>This is forgotten, or will be this fixed later? > >>>>>>>>>> > >>>>>>>>>>7) > >>>>>>>>>>+ if not explanation: print resp_body # NOCOMMIT > >>>>>>>>>> > >>>>>>>>>These are all fixed for the next patchset. > >>>>>>>>> > >>>>>>>>>Thanks! > >>>>>>>>>Fraser > >>>>>>>>> > >>>>>>>8) You can do: > >>>>>>> > >>>>>>> Str('cn', > >>>>>>> primary_key=True, > >>>>>>> cli_name='id', > >>>>>>> label=_('Profile ID'), > >>>>>>> doc=_('Profile ID for referring to this profile'), > >>>>>>> pattern='^[a-zA-Z]\w*$', > >>>>>>> pattern_errmsg=_('invalid Profile ID'), > >>>>>>> ), > >>>>>>> > >>>>>>>instead of: > >>>>>>> > >>>>>>> profile_id_pattern = re.compile('^[a-zA-Z]\w*$') > >>>>>>> > >>>>>>> def validate_profile_id(ugettext, value): > >>>>>>> """Ensure profile ID matches form required by CA.""" > >>>>>>> if profile_id_pattern.match(value) is None: > >>>>>>> return _('invalid Profile ID') > >>>>>>> else: > >>>>>>> return None > >>>>>>> > >>>>>>> ... > >>>>>>> > >>>>>>> Str('cn', validate_profile_id, > >>>>>>> primary_key=True, > >>>>>>> cli_name='id', > >>>>>>> label=_('Profile ID'), > >>>>>>> doc=_('Profile ID for referring to this profile'), > >>>>>>> ), > >>>>>>> > >>>>This is nice, but I have kept the separate method so that the > >>>>cert-request command can use the same routine for validating the > >>>>profile id (this will be in a subsequent patch). > >>>> > >>>>>>>9) Please don't invent new attributes (ipaCertProfileSummary) when you > >>>>>>>can use existing ones (description). > >>>>>>> > >>>>>>> > >>>>>>>10) All the commands should call > >>>>>>>ipalib.plugins.cert.ca_enabled_check(). > >>>>>>> > >>>>>>> > >>>>>>>11) I think the File parameter of certprofile_import should be called > >>>>>>>just 'file'. > >>>>>>> > >>>>9, 10, 11 were addressed for this patchset. > >>>> > >>>>>>>12) IMO the profile backend should be merged in to the ra backend. I > >>>>>>>don't see a need to have these two separate. > >>>>>>> > >>>>>>> > >>>>>>>Honza > >>>>>>> > >>>>>> > >>>>> > >>>>>-- > >>>>>Jan Cholasta > >>>Thank you. > >>> > >>>I did part of review, again I have not idea about the dogtag magic > >>>there, so I might be completely wrong. > >>>Martin^2 > >>> > >>>Patches need rebase. > >>> > >>>Patch 0001: > >>>1) > >>>I'm not sure if this is added during upgrade > >>>+ config.set("CA", "pki_profiles_in_ldap", "True") > >>> > >>>Patch 0002: > >>>LGTM (upgrade solved in 0005) > >>> > >>>Patch 0003: > >>>I have no idea. > >>> > >>>Patch 0004: > >>>1) > >>>Can you please let it in old school way, for better readability > >>>sysupgrade.get_upgrade_state(*upgrade_state_args): > >>> > >>>sysupgrade.get_upgrade_state('dogtag', 'agent_allow_profile_modify') > >>>sysupgrade.set_upgrade_state('dogtag', 'agent_allow_profile_modify' ,True) > >>> > >>>2) > >>>+ conn = ipaldap.IPAdmin(self.fqdn, self.ds_port) > >>>+ conn.do_simple_bind(DN(('cn', 'Directory Manager')), > >>>self.dm_password) > >>>+ conn.modify_s(dn, modlist) > >>>+ conn.unbind() > >>> > >>>IMO You can use: > >>>self.ldap_connect() > >>>self.admin_conn.modify_s() > >>> > >>>Patch 0005: > >>>LGTM > >>> > >>>Patch 0006: > >>>LGTM > >>> > >>>Patch 0007: > >>>0) > >>> I cannot apply patch > >>> > >>>error: invalid object 100755 c6c602dc6b4582c24e4ca751ab2f91f8e683dffa > >>>for 'install/tools/ipa-upgradeconfig' > >>>fatal: git-write-tree: error building trees > >>>Repository lacks necessary blobs to fall back on 3-way merge. > >>>Cannot fall back to three-way merge. > >>>Patch failed at 0007 Import included profiles during install or upgrade > >>> > >>> > >>>1) > >>>+ # update `api.env.ca_host` to correct hostname > >>>+ # https://fedorahosted.org/freeipa/ticket/4936 > >>>+ api.env.ca_host = host_name > >>>This is something what was already fixed, maybe rebase error? > >>> > >>>2) > >>>+ if setup_ca: > >>>+ # ensure profile backend is available > >>>+ import ipaserver.plugins.dogtag > >>>Must be this import in ipa-server-install? > >>>Respectively why is this import required, isn't it initialized by > >>>api.finalize()? > >> > >>+1, what are you trying to accomplish here? > >> > >Moving the `import ipaserver.plugins.dogtag` any earlier - even to > >the line before `api.bootstrap(**cfg)` - fails with: > > > > AttributeError: 'Env' object has no attribute 'ra_plugin' > > > >at ipaserver/plugins/dogtag.py:1271 > > > > if api.env.ra_plugin != 'dogtag': > > ... > > > >Not importing it prior to `api.finalize()` causes the Backend not be > >loaded: > > > > AttributeError: 'NameSpace' object has no attribute 'ra_certprofile' > > > >at /sbin/ipa-server-install:1323, in main: > > > > api.Backend.ra_certprofile._read_password() > > > >I am not familiar with the plugin loading so I am probably missing > >something - if anyone knows how to handle this > > This is because ipaserver plugins aren't automatically loaded in installers. > I guess we can change that, as we alredy use ldap2 anyway. > > The code responsible for this is API.bootstrap() in ipalib/__init__.py. > Thanks, I will look into how we can do this better. > > > >>> > >>>3) > >>>+ service.print_msg("Importing certificate profiles") > >>>+ api.Backend.ra_certprofile._read_password() > >>>+ if not api.Backend.ldap2.isconnected(): > >>>+ api.Backend.ldap2.connect(autobind=True) > >>>+ ca.import_included_profiles() > >>> > >>>Why this must be in ipa-server-install? > >>>Why is that not in cainstance? > >> > >>+1 > >> > >I should be able to move it back there. > > > >>> > >>>4) > >>>I'm not sure if these functions can be removed: > >>>Honza please take look, if it is safe > >>> > >>>- def upgrade_ipa_profile(ca, domain, fqdn) > >>> > >>>- self.step("set certificate subject base", > >>>self.__set_subject_in_config) > >>>- self.step("enabling Subject Key Identifier", > >>>self.enable_subject_key_identifier) > >>>- self.step("enabling Subject Alternative Name", > >>>self.enable_subject_alternative_name) > >>>- self.step("enabling CRL and OCSP extensions for > >>>certificates", self.__set_crl_ocsp_extensions) > >>> > >>>5) > >>>'/usr/share/ipa/profiles/{}.cfg'.format(profile_id), sub_dict) > >>> > >>>os.path.join(paths.USR_SHARE_IPA_DIR, 'profiles', ) > >>>please use paths from ipaplatform.paths module. > >>>Maybe rather create new path in ipaplatform/base/paths > >>>USR_SHARE_IPA_PROFILES_DIR = "/usr/share/ipa/profiles" > >>> > >>>Nitpicks: > >>>In several patches: > >>>+ except ipalib.errors.PublicError, e: > >>>please us except ipalib.errors.PublicError as e > >>> > >> > >>6) IPA currently uses the caIPAServiceCert profile. Why don't you import > >>this profile and instead create a new DefaultService profile? > >> > >DefaultService is exactly this profile - but now IPA owns it, not > >Dogtag (https://fedorahosted.org/freeipa/ticket/4002). I called it > >`DefaultService' because users will now be seeing and typing profile > >IDs, and I thought `caIPAserviceCert' was a bit unfriendly. > > > >Happy to change it back to `caIPAserviceCert' if that is the > >consensus. > > I would prefer if the name stayed the same, for backward compatibility. > > On upgrade you should import the original profile instead of the new one > bundled with IPA, so that if the admins did some manual modifications, they > won't lose them. > I agree on the point of importing the original profile (changed or unchanged). On backward compatibility, I'm not sure what the issue is. The name `caIPAserviceCert' was AFAIK not exposed through IPA. It was available for direct use in Dogtag but did anyone actually do that or is referencing it by the same name something we need to continue to support? Thanks, Fraser > > > >Thanks for your reviews! > >Fraser > > > >>-- > >>Jan Cholasta > > > -- > Jan Cholasta From jcholast at redhat.com Wed May 20 06:53:03 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 20 May 2015 08:53:03 +0200 Subject: [Freeipa-devel] [PATCH] Password vault In-Reply-To: <555B4B40.1060702@redhat.com> References: <54E1AF55.3060409@redhat.com> <54EBEB55.6010306@redhat.com> <54F96B22.9050507@redhat.com> <55004D5D.6060300@redhat.com> <550FE5EB.1070606@redhat.com> <551E0AE1.8040500@redhat.com> <553498D1.1020901@redhat.com> <5551DB57.6060504@redhat.com> <555314D1.6070304@redhat.com> <55541015.3040206@redhat.com> <5554ECAE.8030908@redhat.com> <55553B0A.10800@redhat.com> <555A3ACF.3000305@redhat.com> <555AF3EC.1060100@redhat.com> <555B4B40.1060702@redhat.com> Message-ID: <555C2F4F.4080406@redhat.com> Dne 19.5.2015 v 16:40 Endi Sukma Dewata napsal(a): > 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=. >>> >>> 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? Yes. > >>>>>> 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=, >>>>>> cn=users, cn=vaults). The entry cn=, cn=, 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/@, 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. The reason is consistency. Private vaults should be available for all identities, because anything else would be an arbitrary limitation (which is not elegant). If private vaults were available for all identities, we would need a container for host vaults. I'm not saying the container has to be added now, but there should at least be a check to reject requests when the authenticated identity is a host (i.e. context.principal.startswith('host/')). > >>>>>> 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? I don't think there is a ticket for this particular issue. > >>> 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. Thanks for understanding. > >>>>>> 6. The loop in create_container() is incorrect. Suppose we're >>>>>> creating a >>>>>> container cn=A, cn=B, and the parent container cn=B, >>>>>> >>>>>> 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 without recursion, like my code does: >> >> + def create_container(self, dn): >> + """ >> + Creates vault container and its parents. >> + """ >> + >> + container_dn = DN(self.container_dn, self.api.env.basedn) >> + assert dn.endswith(container_dn) >> + >> + dns = [] >> + while dn.endswith(container_dn): >> + dns.insert(0, dn) >> + dn = DN(*dn[1:]) >> + >> + for dn in dns: >> + entry = self.backend.make_entry( >> + dn, >> + objectclass=['nsContainer'], >> + cn=[dn[0]['cn']], >> + ) >> + >> + try: >> + self.backend.add_entry(entry) >> + except errors.DuplicateEntry: >> + pass > > There is an obvious inefficiency here: all containers in the path > (including the built-in ones) will be re-added on every vault-add > operation. > > I don't see anything wrong with recursions, especially if it works more > efficiently since only the immediate parent will be re-added. I tend to stick to the "don't use recursion in production code" rule, epsecially in simple cases like this one. > > So for example, with the loop every time you add a private vault you're > guaranteed to have three failed LDAP Add operations whereas with the > recursion there's only one failed operation. This is not about loop vs. recursion, this is about the used approach. Your code can be easily transformed into a loop while keeping the same approach: entries = [] while dn: assert dn.endswith(self.base_dn) rdn = dn[0] entry = self.backend.make_entry( dn, { 'objectclass': ['nsContainer'], 'cn': rdn['cn'], }) # if entry can be added, return try: self.backend.add_entry(entry) break except errors.NotFound: pass # otherwise, create parent entry first dn = DN(*dn[1:]) entries.insert(0, entry) for entry in entries: # then create the entry itself again self.backend.add_entry(entry) > > Do you still want to use the loop? Yes please. -- Jan Cholasta From jcholast at redhat.com Wed May 20 07:00:14 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 20 May 2015 09:00:14 +0200 Subject: [Freeipa-devel] [PATCHES 0001-0007] Profile management In-Reply-To: <20150520055636.GF12806@dhcp-40-8.bne.redhat.com> References: <20150505062934.GU16379@dhcp-40-8.bne.redhat.com> <5548816D.6050304@redhat.com> <555305EC.5020001@redhat.com> <55530D23.5040702@redhat.com> <55530DDB.9000101@redhat.com> <20150515082420.GR12806@dhcp-40-8.bne.redhat.com> <5555E63D.4050808@redhat.com> <555AF9E1.1010606@redhat.com> <20150519115027.GA12806@dhcp-40-8.bne.redhat.com> <555C1E5C.2080707@redhat.com> <20150520055636.GF12806@dhcp-40-8.bne.redhat.com> Message-ID: <555C30FE.4030707@redhat.com> Dne 20.5.2015 v 07:56 Fraser Tweedale napsal(a): > 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 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. >>>> >>> I will unify the logic in next patch set. >>> >>>> You shouldn't use the deprecated modify_s method of IPAdmin. >>>> >>>> This is not very nice: >>>> >>>> + sysupgrade.set_upgrade_state(*upgrade_state_args + (True,)) >>>> >>> Ok, I will repeat the arguments for get_upgrade_state and >>> set_upgrade_state. >> >> Thanks. What you did is perfectly valid Python, but let's keep the code >> readable. >> > I am a very DRY person :) > >>> >>>>>> >>>>>>>> Martin^2 >>>>>>>>>>>> Other issues: >>>>>>>>>>>> 1) >>>>>>>>>>>> I do not see modifications in API.txt file >>>>>>>>>>>> >>>>>>>>>>>> 2) >>>>>>>>>>>> We use new shorter license header >>>>>>>>>>>> # >>>>>>>>>>>> # Copyright (C) 2015 FreeIPA Contributors see COPYING for license >>>>>>>>>>>> # >>>>>>>>>>>> >>>>>>>>>>>> 3) >>>>>>>>>>>> +from ipalib.plugins.baseldap import \ >>>>>>>>>>>> + LDAPObject, LDAPSearch, LDAPCreate, LDAPDelete, LDAPUpdate, >>>>>>>>>>>> LDAPRetrieve >>>>>>>>>>>> >>>>>>>>>>>> please use 'import ( modules, .. )' instead of '\' >>>>>>>>>>>> >>>>>>>>>>>> 4) >>>>>>>>>>>> + if method == 'POST' \ >>>>>>>>>>>> + and 'content-type' not in (str(k).lower() for k in >>>>>>>>>>>> headers.viewkeys()): >>>>>>>>>>>> >>>>>>>>>>>> again, please use if ( ... ): instead \ >>>>>>>>>>>> >>>>>>>>>>>> 5) >>>>>>>>>>>> +import ipalib.errors as errors >>>>>>>>>>>> in dogtag.py >>>>>>>>>>>> >>>>>>>>>>>> Can you use from ipalib import errors, instead? >>>>>>>>>>>> >>>>>>>>>>>> 6) >>>>>>>>>>>> + def __exit__(self, exc_type, exc_value, traceback): >>>>>>>>>>>> + """Log out of the REST API""" >>>>>>>>>>>> + # TODO logout >>>>>>>>>>>> + self.cookie = None >>>>>>>>>>>> >>>>>>>>>>>> This is forgotten, or will be this fixed later? >>>>>>>>>>>> >>>>>>>>>>>> 7) >>>>>>>>>>>> + if not explanation: print resp_body # NOCOMMIT >>>>>>>>>>>> >>>>>>>>>>> These are all fixed for the next patchset. >>>>>>>>>>> >>>>>>>>>>> Thanks! >>>>>>>>>>> Fraser >>>>>>>>>>> >>>>>>>>> 8) You can do: >>>>>>>>> >>>>>>>>> Str('cn', >>>>>>>>> primary_key=True, >>>>>>>>> cli_name='id', >>>>>>>>> label=_('Profile ID'), >>>>>>>>> doc=_('Profile ID for referring to this profile'), >>>>>>>>> pattern='^[a-zA-Z]\w*$', >>>>>>>>> pattern_errmsg=_('invalid Profile ID'), >>>>>>>>> ), >>>>>>>>> >>>>>>>>> instead of: >>>>>>>>> >>>>>>>>> profile_id_pattern = re.compile('^[a-zA-Z]\w*$') >>>>>>>>> >>>>>>>>> def validate_profile_id(ugettext, value): >>>>>>>>> """Ensure profile ID matches form required by CA.""" >>>>>>>>> if profile_id_pattern.match(value) is None: >>>>>>>>> return _('invalid Profile ID') >>>>>>>>> else: >>>>>>>>> return None >>>>>>>>> >>>>>>>>> ... >>>>>>>>> >>>>>>>>> Str('cn', validate_profile_id, >>>>>>>>> primary_key=True, >>>>>>>>> cli_name='id', >>>>>>>>> label=_('Profile ID'), >>>>>>>>> doc=_('Profile ID for referring to this profile'), >>>>>>>>> ), >>>>>>>>> >>>>>> This is nice, but I have kept the separate method so that the >>>>>> cert-request command can use the same routine for validating the >>>>>> profile id (this will be in a subsequent patch). >>>>>> >>>>>>>>> 9) Please don't invent new attributes (ipaCertProfileSummary) when you >>>>>>>>> can use existing ones (description). >>>>>>>>> >>>>>>>>> >>>>>>>>> 10) All the commands should call >>>>>>>>> ipalib.plugins.cert.ca_enabled_check(). >>>>>>>>> >>>>>>>>> >>>>>>>>> 11) I think the File parameter of certprofile_import should be called >>>>>>>>> just 'file'. >>>>>>>>> >>>>>> 9, 10, 11 were addressed for this patchset. >>>>>> >>>>>>>>> 12) IMO the profile backend should be merged in to the ra backend. I >>>>>>>>> don't see a need to have these two separate. >>>>>>>>> >>>>>>>>> >>>>>>>>> Honza >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Jan Cholasta >>>>> Thank you. >>>>> >>>>> I did part of review, again I have not idea about the dogtag magic >>>>> there, so I might be completely wrong. >>>>> Martin^2 >>>>> >>>>> Patches need rebase. >>>>> >>>>> Patch 0001: >>>>> 1) >>>>> I'm not sure if this is added during upgrade >>>>> + config.set("CA", "pki_profiles_in_ldap", "True") >>>>> >>>>> Patch 0002: >>>>> LGTM (upgrade solved in 0005) >>>>> >>>>> Patch 0003: >>>>> I have no idea. >>>>> >>>>> Patch 0004: >>>>> 1) >>>>> Can you please let it in old school way, for better readability >>>>> sysupgrade.get_upgrade_state(*upgrade_state_args): >>>>> >>>>> sysupgrade.get_upgrade_state('dogtag', 'agent_allow_profile_modify') >>>>> sysupgrade.set_upgrade_state('dogtag', 'agent_allow_profile_modify' ,True) >>>>> >>>>> 2) >>>>> + conn = ipaldap.IPAdmin(self.fqdn, self.ds_port) >>>>> + conn.do_simple_bind(DN(('cn', 'Directory Manager')), >>>>> self.dm_password) >>>>> + conn.modify_s(dn, modlist) >>>>> + conn.unbind() >>>>> >>>>> IMO You can use: >>>>> self.ldap_connect() >>>>> self.admin_conn.modify_s() >>>>> >>>>> Patch 0005: >>>>> LGTM >>>>> >>>>> Patch 0006: >>>>> LGTM >>>>> >>>>> Patch 0007: >>>>> 0) >>>>> I cannot apply patch >>>>> >>>>> error: invalid object 100755 c6c602dc6b4582c24e4ca751ab2f91f8e683dffa >>>>> for 'install/tools/ipa-upgradeconfig' >>>>> fatal: git-write-tree: error building trees >>>>> Repository lacks necessary blobs to fall back on 3-way merge. >>>>> Cannot fall back to three-way merge. >>>>> Patch failed at 0007 Import included profiles during install or upgrade >>>>> >>>>> >>>>> 1) >>>>> + # update `api.env.ca_host` to correct hostname >>>>> + # https://fedorahosted.org/freeipa/ticket/4936 >>>>> + api.env.ca_host = host_name >>>>> This is something what was already fixed, maybe rebase error? >>>>> >>>>> 2) >>>>> + if setup_ca: >>>>> + # ensure profile backend is available >>>>> + import ipaserver.plugins.dogtag >>>>> Must be this import in ipa-server-install? >>>>> Respectively why is this import required, isn't it initialized by >>>>> api.finalize()? >>>> >>>> +1, what are you trying to accomplish here? >>>> >>> Moving the `import ipaserver.plugins.dogtag` any earlier - even to >>> the line before `api.bootstrap(**cfg)` - fails with: >>> >>> AttributeError: 'Env' object has no attribute 'ra_plugin' >>> >>> at ipaserver/plugins/dogtag.py:1271 >>> >>> if api.env.ra_plugin != 'dogtag': >>> ... >>> >>> Not importing it prior to `api.finalize()` causes the Backend not be >>> loaded: >>> >>> AttributeError: 'NameSpace' object has no attribute 'ra_certprofile' >>> >>> at /sbin/ipa-server-install:1323, in main: >>> >>> api.Backend.ra_certprofile._read_password() >>> >>> I am not familiar with the plugin loading so I am probably missing >>> something - if anyone knows how to handle this >> >> This is because ipaserver plugins aren't automatically loaded in installers. >> I guess we can change that, as we alredy use ldap2 anyway. >> >> The code responsible for this is API.bootstrap() in ipalib/__init__.py. >> > Thanks, I will look into how we can do this better. > >>> >>>>> >>>>> 3) >>>>> + service.print_msg("Importing certificate profiles") >>>>> + api.Backend.ra_certprofile._read_password() >>>>> + if not api.Backend.ldap2.isconnected(): >>>>> + api.Backend.ldap2.connect(autobind=True) >>>>> + ca.import_included_profiles() >>>>> >>>>> Why this must be in ipa-server-install? >>>>> Why is that not in cainstance? >>>> >>>> +1 >>>> >>> I should be able to move it back there. >>> >>>>> >>>>> 4) >>>>> I'm not sure if these functions can be removed: >>>>> Honza please take look, if it is safe >>>>> >>>>> - def upgrade_ipa_profile(ca, domain, fqdn) >>>>> >>>>> - self.step("set certificate subject base", >>>>> self.__set_subject_in_config) >>>>> - self.step("enabling Subject Key Identifier", >>>>> self.enable_subject_key_identifier) >>>>> - self.step("enabling Subject Alternative Name", >>>>> self.enable_subject_alternative_name) >>>>> - self.step("enabling CRL and OCSP extensions for >>>>> certificates", self.__set_crl_ocsp_extensions) >>>>> >>>>> 5) >>>>> '/usr/share/ipa/profiles/{}.cfg'.format(profile_id), sub_dict) >>>>> >>>>> os.path.join(paths.USR_SHARE_IPA_DIR, 'profiles', ) >>>>> please use paths from ipaplatform.paths module. >>>>> Maybe rather create new path in ipaplatform/base/paths >>>>> USR_SHARE_IPA_PROFILES_DIR = "/usr/share/ipa/profiles" >>>>> >>>>> Nitpicks: >>>>> In several patches: >>>>> + except ipalib.errors.PublicError, e: >>>>> please us except ipalib.errors.PublicError as e >>>>> >>>> >>>> 6) IPA currently uses the caIPAServiceCert profile. Why don't you import >>>> this profile and instead create a new DefaultService profile? >>>> >>> DefaultService is exactly this profile - but now IPA owns it, not >>> Dogtag (https://fedorahosted.org/freeipa/ticket/4002). I called it >>> `DefaultService' because users will now be seeing and typing profile >>> IDs, and I thought `caIPAserviceCert' was a bit unfriendly. >>> >>> Happy to change it back to `caIPAserviceCert' if that is the >>> consensus. >> >> I would prefer if the name stayed the same, for backward compatibility. >> >> On upgrade you should import the original profile instead of the new one >> bundled with IPA, so that if the admins did some manual modifications, they >> won't lose them. >> > I agree on the point of importing the original profile (changed or > unchanged). > > On backward compatibility, I'm not sure what the issue is. The name > `caIPAserviceCert' was AFAIK not exposed through IPA. > > It was available for direct use in Dogtag but did anyone actually do > that or is referencing it by the same name something we need to > continue to support? Well, I'm not sure, so I would rather stay on the safe side and not change the name. > > Thanks, > Fraser > >>> >>> Thanks for your reviews! >>> Fraser >>> >>>> -- >>>> Jan Cholasta >> >> >> -- >> Jan Cholasta -- Jan Cholasta From pspacek at redhat.com Wed May 20 07:06:47 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 20 May 2015 09:06:47 +0200 Subject: [Freeipa-devel] [PATCH 0368-0371] Support LDAP MODRDN for ordinary DNS records Message-ID: <555C3287.3080108@redhat.com> Hello, this patchset implements support for MODRDN for ordinary records. As noted in ticket https://fedorahosted.org/bind-dyndb-ldap/ticket/123, we agreed yesterday that renaming zones is out of scope and seems unnecessarily complex. This patch set depends on 'metadb' branch. It is also available from: https://github.com/pspacek/bind-dyndb-ldap/tree/modrdn Thank you for your time! -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0368-Support-LDAP-MODRDN-for-ordinary-DNS-records.patch Type: text/x-patch Size: 8754 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0369-Add-memory-context-to-ldap_entry_t.patch Type: text/x-patch Size: 5402 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0370-Remove-dangling-declarations-for-ldap_entrylist_.patch Type: text/x-patch Size: 1338 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0371-Remove-dependency-on-entry-dn-to-avoid-problems-with.patch Type: text/x-patch Size: 30620 bytes Desc: not available URL: From ofayans at redhat.com Wed May 20 08:08:29 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 20 May 2015 10:08:29 +0200 Subject: [Freeipa-devel] [UPSTREAM_FAILURES] Latest changes affect freeipa builds and client configuration In-Reply-To: <555B59D7.6020509@redhat.com> References: <555B54E0.7090004@redhat.com> <555B59D7.6020509@redhat.com> Message-ID: <555C40FD.4040904@redhat.com> Hi Martin, Thank you! On 05/19/2015 05:42 PM, 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 > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From ofayans at redhat.com Wed May 20 08:13:19 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 20 May 2015 10:13:19 +0200 Subject: [Freeipa-devel] [UPSTREAM_FAILURES] Latest changes affect freeipa builds and client configuration In-Reply-To: <555B6659.1020906@redhat.com> References: <555B54E0.7090004@redhat.com> <555B6659.1020906@redhat.com> Message-ID: <555C421F.7060208@redhat.com> Hi Martin, On 05/19/2015 06:35 PM, Martin Basti wrote: > On 19/05/15 17:21, 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. >> >> 2. Today the master branch fails to build at all with the following >> exception: >> >> cd install; if [ ! -e Makefile ]; then ../autogen.sh --prefix=/usr >> --sysconfdir=/etc --localstatedir=/var --libdir=/usr/lib; fi >> ./make-lint >> >> =============================================================================== >> >> Errors were found during the static code check. >> >> If you are certain that any of the reported errors are false positives, >> please >> mark them in the source code according to the pylint documentation. >> =============================================================================== >> >> >> ************* Module ipa-server-install >> install/tools/ipa-server-install:955: [E1103(maybe-no-member), main] >> Instance of 'bool' has no 'lower' member (but some types could not be >> inferred)) >> install/tools/ipa-server-install:955: [E1103(maybe-no-member), main] >> Instance of 'int' has no 'lower' member (but some types could not be >> inferred)) >> Makefile:119: recipe for target 'lint' failed >> >> Just wanted to inform you. >> >> > This lint warning are only on F21. > Now I just successfully build master on F22. > I will send a patch to fix F21. > > Should I also check f20? Is there a convention as on which versions of fedora the code should be able to build successfully? The same for run: currently we have only f21 slaves for upstream tests. Should we probably run a limited subset of tests on some other platforms? -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mkosek at redhat.com Wed May 20 08:38:46 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 20 May 2015 10:38:46 +0200 Subject: [Freeipa-devel] [TEST PLAN] User lifecycle plugin In-Reply-To: <555B5C99.1070409@redhat.com> References: <1431521873.3392.6.camel@dhcp130-146.brq.redhat.com> <55537169.4000308@redhat.com> <555373C7.2070007@redhat.com> <555B5C99.1070409@redhat.com> Message-ID: <555C4816.9040308@redhat.com> On 05/19/2015 05:54 PM, thierry bordaz wrote: > 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 >>> " 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 +1 for above > * Run the tests as a stageadm (member of 'User administrator') I would not push on this for version 1, IIRC we still miss the infrastructure to easily run tests like this. But +1 for the intent. > * 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) I quickly checked the test case, I think it misses some of the basic test cases: - Add user, add him as a member of a custom group. Delete/preserve the user, check that he is no longer a member of that custom group - Add staged user via LDAP directly as this is the primary use case. Then try to activate it. The user may have different/minimal formats (more minimal than with stageuser-add), see design for examples. From pvoborni at redhat.com Wed May 20 08:53:17 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 20 May 2015 10:53:17 +0200 Subject: [Freeipa-devel] [UPSTREAM_FAILURES] Latest changes affect freeipa builds and client configuration In-Reply-To: <555C421F.7060208@redhat.com> References: <555B54E0.7090004@redhat.com> <555B6659.1020906@redhat.com> <555C421F.7060208@redhat.com> Message-ID: <555C4B7D.4090309@redhat.com> On 05/20/2015 10:13 AM, Oleg Fayans wrote: > Hi Martin, > > On 05/19/2015 06:35 PM, Martin Basti wrote: >> On 19/05/15 17:21, 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. >>> >>> 2. Today the master branch fails to build at all with the following >>> exception: >>> >>> cd install; if [ ! -e Makefile ]; then ../autogen.sh --prefix=/usr >>> --sysconfdir=/etc --localstatedir=/var --libdir=/usr/lib; fi >>> ./make-lint >>> >>> =============================================================================== >>> >>> Errors were found during the static code check. >>> >>> If you are certain that any of the reported errors are false positives, >>> please >>> mark them in the source code according to the pylint documentation. >>> =============================================================================== >>> >>> >>> ************* Module ipa-server-install >>> install/tools/ipa-server-install:955: [E1103(maybe-no-member), main] >>> Instance of 'bool' has no 'lower' member (but some types could not be >>> inferred)) >>> install/tools/ipa-server-install:955: [E1103(maybe-no-member), main] >>> Instance of 'int' has no 'lower' member (but some types could not be >>> inferred)) >>> Makefile:119: recipe for target 'lint' failed >>> >>> Just wanted to inform you. >>> >>> >> This lint warning are only on F21. >> Now I just successfully build master on F22. >> I will send a patch to fix F21. >> >> > Should I also check f20? Is there a convention as on which versions of > fedora the code should be able to build successfully? The same for run: > currently we have only f21 slaves for upstream tests. Should we probably > run a limited subset of tests on some other platforms? > I don't think f20 is necessary. It will be eol soon. The convention is fedora versions with provided COPR repos. It would be good to run master builds on F21 and F22. current fedora version - git branch table is something like: master f21, f22. 4-1 f20, f21, f22 -- Petr Vobornik From tbordaz at redhat.com Wed May 20 09:02:01 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 20 May 2015 11:02:01 +0200 Subject: [Freeipa-devel] [TEST PLAN] User lifecycle plugin In-Reply-To: <555C4816.9040308@redhat.com> References: <1431521873.3392.6.camel@dhcp130-146.brq.redhat.com> <55537169.4000308@redhat.com> <555373C7.2070007@redhat.com> <555B5C99.1070409@redhat.com> <555C4816.9040308@redhat.com> Message-ID: <555C4D89.8080504@redhat.com> On 05/20/2015 10:38 AM, Martin Kosek wrote: > On 05/19/2015 05:54 PM, thierry bordaz wrote: >> 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 >>>> " 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 > +1 for above > >> * Run the tests as a stageadm (member of 'User administrator') > I would not push on this for version 1, IIRC we still miss the infrastructure > to easily run tests like this. But +1 for the intent. If test infrastructure require 'admin', no problem. But I usually simply do the following commands before running the ULC CLI tests. (echo "hello";echo "hello") | ipa user-add --first=stage --last=administrator stageadm --password ipa role-add-member "User Administrator" --users=stageadm (echo "hello";echo "Secret123";echo "Secret123") | kinit stageadm > >> * 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) > I quickly checked the test case, I think it misses some of the basic test cases: > - Add user, add him as a member of a custom group. Delete/preserve the user, > check that he is no longer a member of that custom group > - Add staged user via LDAP directly as this is the primary use case. Then try > to activate it. The user may have different/minimal formats (more minimal than > with stageuser-add), see design for examples. +1 Yes I forgot the DS plugins (uniqueness, ref. int., memberof). uniqueness is scoping Active/Delete user (uid and ipaUniqueID). referential integrity scopes Active user for (member, manager, managedby, secretary, uniquemember...), so preserving a user should update those attributes. memberof scopes Active user, so preserving a user should update its memberof values From jcholast at redhat.com Wed May 20 09:26:32 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 20 May 2015 11:26:32 +0200 Subject: [Freeipa-devel] [PATCH] 0005 User life cycle: del/mod/find/show stageuser commands In-Reply-To: <5559A3DD.7030002@redhat.com> References: <552F964E.2060304@redhat.com> <553F437D.5080103@redhat.com> <553F44B7.6040100@redhat.com> <553F476E.8080502@redhat.com> <553F9BCE.6010000@redhat.com> <554869C3.2040509@redhat.com> <5551EF3E.1060503@redhat.com> <555216B9.1070106@redhat.com> <205373726.22060212.1431701099532.JavaMail.zimbra@redhat.com> <5559A3DD.7030002@redhat.com> Message-ID: <555C5348.2030202@redhat.com> Dne 18.5.2015 v 10:33 thierry bordaz napsal(a): > On 05/15/2015 04:44 PM, David Kupka wrote: >> Hello Thierry, >> thanks for the patch set. Overall functionality of ULC feature looks >> good to >> me and is definitely "alpha ready". >> >> I found following issues but don't insist on fixing it right now: >> >> 1) When stageuser-activate fails due to already existent >> active/deleted user. >> DN is show instead of user name that's used in other commands (user-add, >> stageuser-add). >> $ ipa user-add tuser --first Test --last User >> $ ipa stageuser-add tuser --first Test --last User >> $ ipa stageuser-activate tuser >> ipa: ERROR: Active user >> uid=tuser,cn=users,cn=accounts,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com >> >> already exists > > Hi David, Jan, > > Thanks you so much for all those tests and feedback. I agree, some minor > bugs can be fixed separatly from this main patches. > > You are right, It should return the user ID not the DN. > >> >> 2) According to the design there should be '--only-delete' and >> '--also-delete' >> options for user-find command instead there is '--preserved' option. >> Honza proposed adding virtual boolean attribute 'deleted' to user >> entry and >> filter on it. >> The 'deleted' attribute would be useful also in user-show where is no >> way to >> tell if the displayed user is active or deleted. (Except running with >> --all >> and looking on the dn). > > Yes a bit late to resynch the design. > The final option is 'preserved' for user-find and 'preserve' for > user-del. '--only-delete' or 'also-delete' are old name that I need to > replace in the design. > > About the 'deleted' attribute, do you think adding a DS cos virtual > attribute ? See the attached patch. > >> >> 3) uidNumber and gidNumber can't be set back to '-1' once set to other >> value. >> This would be useful when admin changes its mind and want IPA to >> assign them. >> IIUC, there should be no validation in cn=staged user container. All >> validation should be done during stageuser-activate. > > Yes that comes from user plugin that enforce the number to be >0. > That is a good point giving the ability to reset uidNumber/gidNumber. > I will check if it is possible, how (give a value or an option to > reset), and also if it would not create other issue. >> >> 4) Support for deleted -> stage workflow is still missing. But I'm >> unsure if we >> agreed to finish it now or later. > > Yes thanks >> >> 5) Twice deleting user with '--preserve' deletes him permanently. >> $ ipa user-add tuser --first Test --last User >> $ ipa user-del tuser --preserve >> $ ipa user-del tuser --preserve >> $ ipa user-find --preserved >> ------------------------ >> 0 (delete) users matched >> ------------------------ >> ---------------------------- >> Number of entries returned 0 >> ---------------------------- > > Deleting a deleted (preserved) entry, should permanently remove the entry. > Now if the second time the preserve option is present, it makes sense to > not delete it. BTW: I might be stating the obvious here, but it would be better to use one boolean parameter rather than two mutually exclusive flags in user-del. > > > thanks > theirry -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-427-User-life-cycle-provide-preserved-user-virtual-attri.patch Type: text/x-patch Size: 7551 bytes Desc: not available URL: From mbasti at redhat.com Wed May 20 10:32:20 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 20 May 2015 12:32:20 +0200 Subject: [Freeipa-devel] IPAUpgrade.create_instance causing ipa-server-install failure In-Reply-To: <20150520053112.GE12806@dhcp-40-8.bne.redhat.com> References: <20150520053112.GE12806@dhcp-40-8.bne.redhat.com> Message-ID: <555C62B4.4020702@redhat.com> On 20/05/15 07:31, Fraser Tweedale wrote: > 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 at 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 at 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 '/usr/lib/python2.7/site-packages/ipalib/plugins/otpconfig.py' > 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/otptoken.py' > 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/otptoken_yubikey.py' > 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/passwd.py' > 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/permission.py' > 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/ping.py' > 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/pkinit.py' > 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/privilege.py' > 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/pwpolicy.py' > 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/radiusproxy.py' > 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/realmdomains.py' > 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/role.py' > 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/rpcclient.py' > 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/selfservice.py' > 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/selinuxusermap.py' > 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/service.py' > 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/stageuser.py' > 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmd.py' > 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmdgroup.py' > 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/sudorule.py' > 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/trust.py' > 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/user.py' > 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/virtual.py' > 2015-05-20T03:50:41Z DEBUG importing all plugin modules in '/usr/lib/python2.7/site-packages/ipaserver/install/plugins'... > 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/adtrust.py' > 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/ca_renewal_master.py' > 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py' > 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/fix_replica_agreements.py' > 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/rename_managed.py' > 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_idranges.py' > 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_managed_permissions.py' > 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_pacs.py' > 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_passsync.py' > 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_referint.py' > 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_services.py' > 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_uniqueness.py' > 2015-05-20T03:50:41Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/upload_cacrt.py' > 2015-05-20T03:50:41Z ERROR Upgrade failed with cannot connect to 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': > 2015-05-20T03:50:41Z DEBUG Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 304, in __upgrade > ld = ldapupdate.LDAPUpdate(dm_password='', ldapi=True) > File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 314, in __init__ > self.create_connection() > File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 862, in create_connection > autobind=self.ldapi) > File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 66, in connect > conn = self.create_connection(*args, **kw) > File "/usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py", line 188, in create_connection > client_controls=clientctrls) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1074, in external_bind > '', auth_tokens, server_controls, client_controls) > File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ > self.gen.throw(type, value, traceback) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 976, in error_handler > error=info) > NetworkError: cannot connect to 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': > > 2015-05-20T03:50:41Z DEBUG Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 388, in start_creation > run_step(full_msg, method) > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 378, in run_step > method() > File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 315, in __upgrade > raise RuntimeError(e) > RuntimeError: cannot connect to 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': > > 2015-05-20T03:50:41Z DEBUG [error] RuntimeError: cannot connect to 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': > 2015-05-20T03:50:41Z DEBUG [cleanup]: stopping directory server > 2015-05-20T03:50:41Z DEBUG Starting external process > 2015-05-20T03:50:41Z DEBUG args='/bin/systemctl' 'stop' 'dirsrv at IPA-LOCAL.service' > 2015-05-20T03:50:41Z DEBUG Process finished, return code=0 > 2015-05-20T03:50:41Z DEBUG stdout= > 2015-05-20T03:50:41Z DEBUG stderr= > 2015-05-20T03:50:41Z DEBUG duration: 0 seconds > 2015-05-20T03:50:41Z DEBUG [cleanup]: restoring configuration > 2015-05-20T03:50:41Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-05-20T03:50:41Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-05-20T03:50:41Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-05-20T03:50:41Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-05-20T03:50:41Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-05-20T03:50:41Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-05-20T03:50:41Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-05-20T03:50:41Z DEBUG duration: 0 seconds > 2015-05-20T03:50:41Z DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 733, in run_script > return_value = main_function() > > File "/sbin/ipa-server-install", line 1263, in main > ds.apply_updates() > > File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 513, in apply_updates > raise RuntimeError("Update failed: %s" % e) > > 2015-05-20T03:50:41Z DEBUG The ipa-server-install command failed, exception: RuntimeError: Update failed: cannot connect to 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': > Thank you for this, I'm not able to reproduce this, but I will dig into and try to find where the issue is. Martin^2 -- Martin Basti From ftweedal at redhat.com Wed May 20 10:46:55 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 20 May 2015 20:46:55 +1000 Subject: [Freeipa-devel] [PATCHES 0001-0007] Profile management In-Reply-To: <555AF9E1.1010606@redhat.com> References: <20150504133641.GQ16379@dhcp-40-8.bne.redhat.com> <55479FE1.1020005@redhat.com> <20150505062934.GU16379@dhcp-40-8.bne.redhat.com> <5548816D.6050304@redhat.com> <555305EC.5020001@redhat.com> <55530D23.5040702@redhat.com> <55530DDB.9000101@redhat.com> <20150515082420.GR12806@dhcp-40-8.bne.redhat.com> <5555E63D.4050808@redhat.com> <555AF9E1.1010606@redhat.com> Message-ID: <20150520104655.GG12806@dhcp-40-8.bne.redhat.com> 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. > > >> > >>>>>>>>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 shorter license header > >>>>>>>># > >>>>>>>># Copyright (C) 2015 FreeIPA Contributors see COPYING for license > >>>>>>>># > >>>>>>>> > >>>>>>>>3) > >>>>>>>>+from ipalib.plugins.baseldap import \ > >>>>>>>>+ LDAPObject, LDAPSearch, LDAPCreate, LDAPDelete, LDAPUpdate, > >>>>>>>>LDAPRetrieve > >>>>>>>> > >>>>>>>>please use 'import ( modules, .. )' instead of '\' > >>>>>>>> > >>>>>>>>4) > >>>>>>>>+ if method == 'POST' \ > >>>>>>>>+ and 'content-type' not in (str(k).lower() for k in > >>>>>>>>headers.viewkeys()): > >>>>>>>> > >>>>>>>>again, please use if ( ... ): instead \ > >>>>>>>> > >>>>>>>>5) > >>>>>>>>+import ipalib.errors as errors > >>>>>>>>in dogtag.py > >>>>>>>> > >>>>>>>>Can you use from ipalib import errors, instead? > >>>>>>>> > >>>>>>>>6) > >>>>>>>>+ def __exit__(self, exc_type, exc_value, traceback): > >>>>>>>>+ """Log out of the REST API""" > >>>>>>>>+ # TODO logout > >>>>>>>>+ self.cookie = None > >>>>>>>> > >>>>>>>>This is forgotten, or will be this fixed later? > >>>>>>>> > >>>>>>>>7) > >>>>>>>>+ if not explanation: print resp_body # NOCOMMIT > >>>>>>>> > >>>>>>>These are all fixed for the next patchset. > >>>>>>> > >>>>>>>Thanks! > >>>>>>>Fraser > >>>>>>> > >>>>>8) You can do: > >>>>> > >>>>> Str('cn', > >>>>> primary_key=True, > >>>>> cli_name='id', > >>>>> label=_('Profile ID'), > >>>>> doc=_('Profile ID for referring to this profile'), > >>>>> pattern='^[a-zA-Z]\w*$', > >>>>> pattern_errmsg=_('invalid Profile ID'), > >>>>> ), > >>>>> > >>>>>instead of: > >>>>> > >>>>> profile_id_pattern = re.compile('^[a-zA-Z]\w*$') > >>>>> > >>>>> def validate_profile_id(ugettext, value): > >>>>> """Ensure profile ID matches form required by CA.""" > >>>>> if profile_id_pattern.match(value) is None: > >>>>> return _('invalid Profile ID') > >>>>> else: > >>>>> return None > >>>>> > >>>>> ... > >>>>> > >>>>> Str('cn', validate_profile_id, > >>>>> primary_key=True, > >>>>> cli_name='id', > >>>>> label=_('Profile ID'), > >>>>> doc=_('Profile ID for referring to this profile'), > >>>>> ), > >>>>> > >>This is nice, but I have kept the separate method so that the > >>cert-request command can use the same routine for validating the > >>profile id (this will be in a subsequent patch). > >> > >>>>>9) Please don't invent new attributes (ipaCertProfileSummary) when you > >>>>>can use existing ones (description). > >>>>> > >>>>> > >>>>>10) All the commands should call > >>>>>ipalib.plugins.cert.ca_enabled_check(). > >>>>> > >>>>> > >>>>>11) I think the File parameter of certprofile_import should be called > >>>>>just 'file'. > >>>>> > >>9, 10, 11 were addressed for this patchset. > >> > >>>>>12) IMO the profile backend should be merged in to the ra backend. I > >>>>>don't see a need to have these two separate. > >>>>> > >>>>> > >>>>>Honza > >>>>> > >>>> > >>> > >>>-- > >>>Jan Cholasta > >Thank you. > > > >I did part of review, again I have not idea about the dogtag magic > >there, so I might be completely wrong. > >Martin^2 > > > >Patches need rebase. > > > >Patch 0001: > >1) > >I'm not sure if this is added during upgrade > >+ config.set("CA", "pki_profiles_in_ldap", "True") > > > >Patch 0002: > >LGTM (upgrade solved in 0005) > > > >Patch 0003: > >I have no idea. > > > >Patch 0004: > >1) > >Can you please let it in old school way, for better readability > >sysupgrade.get_upgrade_state(*upgrade_state_args): > > > >sysupgrade.get_upgrade_state('dogtag', 'agent_allow_profile_modify') > >sysupgrade.set_upgrade_state('dogtag', 'agent_allow_profile_modify' ,True) > > > >2) > >+ conn = ipaldap.IPAdmin(self.fqdn, self.ds_port) > >+ conn.do_simple_bind(DN(('cn', 'Directory Manager')), > >self.dm_password) > >+ conn.modify_s(dn, modlist) > >+ conn.unbind() > > > >IMO You can use: > >self.ldap_connect() > >self.admin_conn.modify_s() > > > >Patch 0005: > >LGTM > > > >Patch 0006: > >LGTM > > > >Patch 0007: > >0) > > I cannot apply patch > > > >error: invalid object 100755 c6c602dc6b4582c24e4ca751ab2f91f8e683dffa > >for 'install/tools/ipa-upgradeconfig' > >fatal: git-write-tree: error building trees > >Repository lacks necessary blobs to fall back on 3-way merge. > >Cannot fall back to three-way merge. > >Patch failed at 0007 Import included profiles during install or upgrade > > > > > >1) > >+ # update `api.env.ca_host` to correct hostname > >+ # https://fedorahosted.org/freeipa/ticket/4936 > >+ api.env.ca_host = host_name > >This is something what was already fixed, maybe rebase error? > > > >2) > >+ if setup_ca: > >+ # ensure profile backend is available > >+ import ipaserver.plugins.dogtag > >Must be this import in ipa-server-install? > >Respectively why is this import required, isn't it initialized by > >api.finalize()? > > +1, what are you trying to accomplish here? > > > > >3) > >+ service.print_msg("Importing certificate profiles") > >+ api.Backend.ra_certprofile._read_password() > >+ if not api.Backend.ldap2.isconnected(): > >+ api.Backend.ldap2.connect(autobind=True) > >+ ca.import_included_profiles() > > > >Why this must be in ipa-server-install? > >Why is that not in cainstance? > > +1 > As well as importing profiles into Dogtag, this uses the IPA framework to add corresponding certprofile objects in the IPA database. Hence it must be done after applying LDAP updates. > > > >4) > >I'm not sure if these functions can be removed: > >Honza please take look, if it is safe > > > >- def upgrade_ipa_profile(ca, domain, fqdn) > > > >- self.step("set certificate subject base", > >self.__set_subject_in_config) > >- self.step("enabling Subject Key Identifier", > >self.enable_subject_key_identifier) > >- self.step("enabling Subject Alternative Name", > >self.enable_subject_alternative_name) > >- self.step("enabling CRL and OCSP extensions for > >certificates", self.__set_crl_ocsp_extensions) > > > >5) > >'/usr/share/ipa/profiles/{}.cfg'.format(profile_id), sub_dict) > > > >os.path.join(paths.USR_SHARE_IPA_DIR, 'profiles', ) > >please use paths from ipaplatform.paths module. > >Maybe rather create new path in ipaplatform/base/paths > >USR_SHARE_IPA_PROFILES_DIR = "/usr/share/ipa/profiles" > > > >Nitpicks: > >In several patches: > >+ except ipalib.errors.PublicError, e: > >please us except ipalib.errors.PublicError as e > > > > 6) IPA currently uses the caIPAServiceCert profile. Why don't you import > this profile and instead create a new DefaultService profile? > > -- > Jan Cholasta From pvoborni at redhat.com Wed May 20 12:08:54 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 20 May 2015 14:08:54 +0200 Subject: [Freeipa-devel] [PATCH] 832-850 Stage Users Web UI and its prerequisites In-Reply-To: <555B7139.4090706@redhat.com> References: <5555B58D.8010804@redhat.com> <5555CBB3.1060003@redhat.com> <555612D9.3020306@redhat.com> <555B5816.3070304@redhat.com> <555B7139.4090706@redhat.com> Message-ID: <555C7956.4010605@redhat.com> On 05/19/2015 07:22 PM, Petr Vobornik wrote: > 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/ > Was agreed offline that just functionality review was OK for this patch set. Green light for the push was given on IRC. Pushed to master: * a4c0f780b727cc92a9b6fa21e42906a80f4f7d42 webui: update patternfly to v1.1.4 * 69bc4f4955c8ee0bdbeea5ca340a003c128e9a58 webui: rename IPA.user_* to IPA.user.* * c352616ac9fbb1685adcbe8834143b24f6e8b5d4 webui: declare search command options in search facet * de374a0d3a1147a650b63bb5c267a857fba015dd webui: register construction spec based on existing spec * ae62bd6914dcdd24667dc1ff149413d9a7adc017 webui: entity facets in facet registry * 2be8eeb04f08cb51a25651794a2f356a2a7b499e webui: entity menu items navigate to main entity facet * 6bcb90ef36f7400e9f1eb197421134d5650c39fe webui: prefer entity fallback in menu item select * 8f6013952061099fff4ec9b8784fc1ee91828c4e webui: navigation: do not remember selected childs of menu item * 6a2b486e500b62abe7ef14e4f34c945726f3256b webui: navigation: unique names on entity facet menu items * 17aafc36b4c94cffa8427c8f4b2aef2292bba40d webui: metadata validator min and max value overrides * 3c2a8b408ec1af284af0ebe218832f3fab85c008 webui: custom facet groups in a facet * 435f9331c633296d72160de1e25bbdc77a81c75e webui: facet groups widget * 8d8b56d135ad05fbfee35fb88618ce8c5498fd68 webui: allow to replace facet tabs with sidebar * cae2df274a9ba92a4fc8db0259811c1755c648e6 webui: allow to hide facet tabs or sidebar * bf7ee6eeecd71ffeb4740a440fd237a6fac4793f webui: facet policies for all facets * 14525598f97f57d165682247ef7f5cf63f810be5 webui: stageuser plugin * 64e87d5e34f646f0de5b0b310ccaf02cbb119a2b webui: extend user deleter dialog with --permanent and --preserve options * 52647285f6d286c079090b5bff21f5e423076897 webui: update stageuser/user pages based on action in diffrent user search page * 99d282d38d0c847ebb544140edd49d6572f06cb0 webui: stageusers, display page elements based on user state * 7ddcff3ef71a1d4254d291bdab99075f2cd8f205 webui: prefer search facet's deleter dialog -- Petr Vobornik From pvoborni at redhat.com Wed May 20 12:17:05 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 20 May 2015 14:17:05 +0200 Subject: [Freeipa-devel] [PATCH] 830 webui: fix empty table border in Firefox In-Reply-To: <555B5E75.7030801@redhat.com> References: <5555B5FF.1040801@redhat.com> <555B5E75.7030801@redhat.com> Message-ID: <555C7B41.30901@redhat.com> On 05/19/2015 06:01 PM, Martin Babinsky wrote: > 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 > Pushed to master: 9b5655607d1a777006721f12fc61de122e3ea4d6 -- Petr Vobornik From pvoborni at redhat.com Wed May 20 12:19:33 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 20 May 2015 14:19:33 +0200 Subject: [Freeipa-devel] [PATCH] 829 webui: option to not create user private group In-Reply-To: <555330A4.1060106@redhat.com> References: <55522341.7090601@redhat.com> <555330A4.1060106@redhat.com> Message-ID: <555C7BD5.9020407@redhat.com> On 05/13/2015 01:08 PM, Martin Basti wrote: > On 12/05/15 17:58, Petr Vobornik wrote: >> Web UI was not able to create a user without a private group. >> >> New field added to user adder dialog to allow that. >> >> https://fedorahosted.org/freeipa/ticket/4986 >> >> > ACK > Pushed to master: 2361ac11ad15dcdceb1dd82ade66b7562b537a0a -- Petr Vobornik From pvoborni at redhat.com Wed May 20 12:36:46 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 20 May 2015 14:36:46 +0200 Subject: [Freeipa-devel] [PATCH] 851-852 webui: datetime widget with datepicker In-Reply-To: <555B5E5D.1060103@redhat.com> References: <5559EBE5.3060502@redhat.com> <555B5E5D.1060103@redhat.com> Message-ID: <555C7FDE.5070700@redhat.com> On 05/19/2015 06:01 PM, Martin Babinsky wrote: > 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. This feature[1] was enabled. > > Otherwise ACK. > pushed to master: * 9e3320403ae1bb34bbc2a96add188294ccfeb997 webui: add boostrap-datepicker files * 80251e772bf48219abc77b507c4cab6d0127c7b6 webui: datetime widget with datepicker [1] http://bootstrap-datepicker.readthedocs.org/en/latest/options.html#todayhighlight -- Petr Vobornik From ofayans at redhat.com Wed May 20 12:52:34 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 20 May 2015 14:52:34 +0200 Subject: [Freeipa-devel] [PATCH] manage replication topology in the shared tree In-Reply-To: <555B2998.9020608@redhat.com> References: <552B84C5.80300@redhat.com> <55362C43.4020406@redhat.com> <55362FDC.7090104@redhat.com> <55519EAC.9000204@redhat.com> <555B2998.9020608@redhat.com> Message-ID: <555C8392.7010908@redhat.com> Is this patch to be applied on top of the vanilla upstream tree, or does it require your previous patches applied before? On 05/19/2015 02:16 PM, Ludwig Krispenz wrote: > Hi, > > here is the latest patch for the plugin part, trying to address all > problems found in the review > > Regards, > Ludwig > PS if you want you can get a separate diff top the last version > > > On 05/12/2015 08:33 AM, Ludwig Krispenz wrote: >> Hi, >> >> I did split the patches, for easier review and to share work on it. >> The attachment contains 4 patches: >> - the ds plugin part as submitted for review >> - the changes to the ds plugin part done after review (not complete >> yet) >> - the ipa framework part (including Petr's improvements) >> - the install related part >> >> Regards, >> Ludwig >> >> On 04/21/2015 01:09 PM, Petr Vobornik wrote: >>> On 04/21/2015 12:53 PM, Petr Vobornik wrote: >>>> On 04/13/2015 10:56 AM, Ludwig Krispenz wrote: >>>>> Hi, >>>>> >>>>> in the attachment you find the latest state of the "topology >>>>> plugin", it >>>>> implements what is defined in the design page: >>>>> http://www.freeipa.org/page/V4/Manage_replication_topology (which is >>>>> also waiting for a reviewer) >>>>> >>>>> It contains the plugin itself and a core of ipa commands to manage a >>>>> topology. to be really applicable, some work outside is required, >>>>> eg the >>>>> management of the domain level and a decision where the binddn group >>>>> should be maintained. >>>>> >>>>> Thanks, >>>>> Ludwig >>>>> >>>>> >>>> >>>> I've looked at the python part, mostly because I want to start with >>>> POC >>>> of Web UI for topology. >>>> >>>> topology.py is clearly still a work in progress. I've reflected >>>> following comments into a patch to speed things up. >>>> >>>> What's in the patch: >>>> >>>> 1. git am complains about trailing whitespaces >>>> >>>> 2. pep8 check produces quite a lot of issues. New code should be >>>> almost >>>> with any (`E501 line too long` is not a hard rule) >>>> `git diff HEAD~1 -U0 | pep8 --diff` >>>> >>>> 3. some typos >>>> >>>> 4. A lot of unused imports >>>> >>>> 5. Option name --sname for 'Segment identifier' is not very >>>> friendly. I >>>> don't see any examples of command options in the design notes. >>>> >>>> 6. NO_UPG_MAGIC - leftover from other plugin? >>>> >>>> 7. suffix object has labels from segment >>>> >>>> 8. IPA framework has a support for nested object. Key is setting >>>> `parent_object = 'topologysuffix'` in topologysegment object. >>>> >>>> 9. repl_agmt_attrs could be in topologysegment takes_params. >>>> >>>> 10. missing various CRUD commands like topologysuffix-find and >>>> topologysuffix-show commands. >>>> >>>> Whats missing, not fixed: >>>> 1. last 2 lines of VERSION file are not updated >>>> >>>> 2. Mixed terminology. Somewhere is used suffix and somewhere >>>> replication >>>> area or just area. >>>> >>>> 3. Validation >>>> - suffix should check for dn >>>> - existence of both ends of a segment >>>> >>>> 4. print of segments in suffix-show needs to be improved or removed >>>> >>>> To discuss: >>>> a) Do params in topologysegment have to have a maxlength set? >>>> >>>> b) Terminology has to be united. Segments are nested in suffix but >>>> sometimes are called areas and suffix is 'the suffix'. User might be >>>> confused. E.g. shouldn't the object be named a topologyarea instead of >>>> topologysuffix? >>>> >>>> c) I've added all missing CRUD commands. Are there any which we don't >>>> want there, or want to restrict them. E.g. I can imagine that >>>> deleting a >>>> suffix should be prevented if it contains any segments (or it has >>>> to be >>>> forced (--force option)) >>>> >>>> d) Do we want to print segments in suffix-show? >>>> >>>> e) Mainly for Honza: I've added --show-segments option to suffix-show >>>> which defaults to True. I don't like the behavior of CLI, which >>>> asks to >>>> confirm the value all the time. My intention was to have it there by >>>> default, but also allow to disable it by --show-segments=False. I >>>> don't >>>> want to add it as Flag (--hide-segments) since it restricts >>>> versatility. >>>> I would like to see an optional flag which would be filled by default >>>> value if not explicitly defined and CLI would not ask for the >>>> option value. >>>> >>>> >>> >>> Also it would be better to split the work into more patches. E.g. DS >>> plugin, installation, python plugin. So ds plugin review could be >>> separated from the python part. >> >> >> > > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkrispen at redhat.com Wed May 20 12:58:26 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 20 May 2015 14:58:26 +0200 Subject: [Freeipa-devel] [PATCH] manage replication topology in the shared tree In-Reply-To: <555C8392.7010908@redhat.com> References: <552B84C5.80300@redhat.com> <55362C43.4020406@redhat.com> <55362FDC.7090104@redhat.com> <55519EAC.9000204@redhat.com> <555B2998.9020608@redhat.com> <555C8392.7010908@redhat.com> Message-ID: <555C84F2.7030500@redhat.com> On 05/20/2015 02:52 PM, Oleg Fayans wrote: > Is this patch to be applied on top of the vanilla upstream tree, or > does it require your previous patches applied before? it requires the install (0005) and ipa-command (0006) patch as well, submitted on 05/12 > > On 05/19/2015 02:16 PM, Ludwig Krispenz wrote: >> Hi, >> >> here is the latest patch for the plugin part, trying to address all >> problems found in the review >> >> Regards, >> Ludwig >> PS if you want you can get a separate diff top the last version >> >> >> On 05/12/2015 08:33 AM, Ludwig Krispenz wrote: >>> Hi, >>> >>> I did split the patches, for easier review and to share work on it. >>> The attachment contains 4 patches: >>> - the ds plugin part as submitted for review >>> - the changes to the ds plugin part done after review (not complete >>> yet) >>> - the ipa framework part (including Petr's improvements) >>> - the install related part >>> >>> Regards, >>> Ludwig >>> >>> On 04/21/2015 01:09 PM, Petr Vobornik wrote: >>>> On 04/21/2015 12:53 PM, Petr Vobornik wrote: >>>>> On 04/13/2015 10:56 AM, Ludwig Krispenz wrote: >>>>>> Hi, >>>>>> >>>>>> in the attachment you find the latest state of the "topology >>>>>> plugin", it >>>>>> implements what is defined in the design page: >>>>>> http://www.freeipa.org/page/V4/Manage_replication_topology (which is >>>>>> also waiting for a reviewer) >>>>>> >>>>>> It contains the plugin itself and a core of ipa commands to >>>>>> manage a >>>>>> topology. to be really applicable, some work outside is required, >>>>>> eg the >>>>>> management of the domain level and a decision where the binddn group >>>>>> should be maintained. >>>>>> >>>>>> Thanks, >>>>>> Ludwig >>>>>> >>>>>> >>>>> >>>>> I've looked at the python part, mostly because I want to start >>>>> with POC >>>>> of Web UI for topology. >>>>> >>>>> topology.py is clearly still a work in progress. I've reflected >>>>> following comments into a patch to speed things up. >>>>> >>>>> What's in the patch: >>>>> >>>>> 1. git am complains about trailing whitespaces >>>>> >>>>> 2. pep8 check produces quite a lot of issues. New code should be >>>>> almost >>>>> with any (`E501 line too long` is not a hard rule) >>>>> `git diff HEAD~1 -U0 | pep8 --diff` >>>>> >>>>> 3. some typos >>>>> >>>>> 4. A lot of unused imports >>>>> >>>>> 5. Option name --sname for 'Segment identifier' is not very >>>>> friendly. I >>>>> don't see any examples of command options in the design notes. >>>>> >>>>> 6. NO_UPG_MAGIC - leftover from other plugin? >>>>> >>>>> 7. suffix object has labels from segment >>>>> >>>>> 8. IPA framework has a support for nested object. Key is setting >>>>> `parent_object = 'topologysuffix'` in topologysegment object. >>>>> >>>>> 9. repl_agmt_attrs could be in topologysegment takes_params. >>>>> >>>>> 10. missing various CRUD commands like topologysuffix-find and >>>>> topologysuffix-show commands. >>>>> >>>>> Whats missing, not fixed: >>>>> 1. last 2 lines of VERSION file are not updated >>>>> >>>>> 2. Mixed terminology. Somewhere is used suffix and somewhere >>>>> replication >>>>> area or just area. >>>>> >>>>> 3. Validation >>>>> - suffix should check for dn >>>>> - existence of both ends of a segment >>>>> >>>>> 4. print of segments in suffix-show needs to be improved or removed >>>>> >>>>> To discuss: >>>>> a) Do params in topologysegment have to have a maxlength set? >>>>> >>>>> b) Terminology has to be united. Segments are nested in suffix but >>>>> sometimes are called areas and suffix is 'the suffix'. User might be >>>>> confused. E.g. shouldn't the object be named a topologyarea >>>>> instead of >>>>> topologysuffix? >>>>> >>>>> c) I've added all missing CRUD commands. Are there any which we don't >>>>> want there, or want to restrict them. E.g. I can imagine that >>>>> deleting a >>>>> suffix should be prevented if it contains any segments (or it has >>>>> to be >>>>> forced (--force option)) >>>>> >>>>> d) Do we want to print segments in suffix-show? >>>>> >>>>> e) Mainly for Honza: I've added --show-segments option to suffix-show >>>>> which defaults to True. I don't like the behavior of CLI, which >>>>> asks to >>>>> confirm the value all the time. My intention was to have it there by >>>>> default, but also allow to disable it by --show-segments=False. I >>>>> don't >>>>> want to add it as Flag (--hide-segments) since it restricts >>>>> versatility. >>>>> I would like to see an optional flag which would be filled by default >>>>> value if not explicitly defined and CLI would not ask for the >>>>> option value. >>>>> >>>>> >>>> >>>> Also it would be better to split the work into more patches. E.g. >>>> DS plugin, installation, python plugin. So ds plugin review could >>>> be separated from the python part. >>> >>> >>> >> >> >> > > -- > Oleg Fayans > Quality Engineer > FreeIPA team > RedHat. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed May 20 13:03:47 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 20 May 2015 15:03:47 +0200 Subject: [Freeipa-devel] [PATCH 0251] Fix uniqueness: exclude compat tree from uid uniquness plugin Message-ID: <555C8633.6090508@redhat.com> Enforcing uniqueness for uid attribute prevent to move users to delete users subtree. Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0251-Uid-uniqueness-fix-exclude-compat-tree-from-uniquene.patch Type: text/x-patch Size: 1474 bytes Desc: not available URL: From pvoborni at redhat.com Wed May 20 13:07:01 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 20 May 2015 15:07:01 +0200 Subject: [Freeipa-devel] [PATCH] manage replication topology in the shared tree In-Reply-To: <555C84F2.7030500@redhat.com> References: <552B84C5.80300@redhat.com> <55362C43.4020406@redhat.com> <55362FDC.7090104@redhat.com> <55519EAC.9000204@redhat.com> <555B2998.9020608@redhat.com> <555C8392.7010908@redhat.com> <555C84F2.7030500@redhat.com> Message-ID: <555C86F5.2080708@redhat.com> On 05/20/2015 02:58 PM, Ludwig Krispenz wrote: > > On 05/20/2015 02:52 PM, Oleg Fayans wrote: >> Is this patch to be applied on top of the vanilla upstream tree, or >> does it require your previous patches applied before? > it requires the install (0005) and ipa-command (0006) patch as well, > submitted on 05/12 Patch 0005 can't be applied on top of the new patch 3. Both patches contains adding of 70topology.ldif. Also please clear all trailing whitespaces from patch 3. $ git am freeipa-lkrispen-0003-plugin-part-manage-replication-topology-in-the-shaer.patch Applying: plugin part - manage replication topology in the shaerd tree /home/somebody/freeipa/.git/rebase-apply/patch:607: trailing whitespace. /home/somebody/freeipa/.git/rebase-apply/patch:740: trailing whitespace. * find the attrtype and return the corresponding /home/somebody/freeipa/.git/rebase-apply/patch:742: trailing whitespace. */ /home/somebody/freeipa/.git/rebase-apply/patch:745: trailing whitespace. /* attr is handling specific direction, /home/somebody/freeipa/.git/rebase-apply/patch:772: trailing whitespace. /* two static data structures to hold the warning: squelched 125 whitespace errors warning: 130 lines add whitespace errors. > >> >> On 05/19/2015 02:16 PM, Ludwig Krispenz wrote: >>> Hi, >>> >>> here is the latest patch for the plugin part, trying to address all >>> problems found in the review >>> >>> Regards, >>> Ludwig >>> PS if you want you can get a separate diff top the last version >>> >>> >>> On 05/12/2015 08:33 AM, Ludwig Krispenz wrote: >>>> Hi, >>>> >>>> I did split the patches, for easier review and to share work on it. >>>> The attachment contains 4 patches: >>>> - the ds plugin part as submitted for review >>>> - the changes to the ds plugin part done after review (not complete >>>> yet) >>>> - the ipa framework part (including Petr's improvements) >>>> - the install related part >>>> >>>> Regards, >>>> Ludwig >>>> >>>> On 04/21/2015 01:09 PM, Petr Vobornik wrote: >>>>> On 04/21/2015 12:53 PM, Petr Vobornik wrote: >>>>>> On 04/13/2015 10:56 AM, Ludwig Krispenz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> in the attachment you find the latest state of the "topology >>>>>>> plugin", it >>>>>>> implements what is defined in the design page: >>>>>>> http://www.freeipa.org/page/V4/Manage_replication_topology (which is >>>>>>> also waiting for a reviewer) >>>>>>> >>>>>>> It contains the plugin itself and a core of ipa commands to >>>>>>> manage a >>>>>>> topology. to be really applicable, some work outside is required, >>>>>>> eg the >>>>>>> management of the domain level and a decision where the binddn group >>>>>>> should be maintained. >>>>>>> >>>>>>> Thanks, >>>>>>> Ludwig >>>>>>> >>>>>>> >>>>>> >>>>>> I've looked at the python part, mostly because I want to start >>>>>> with POC >>>>>> of Web UI for topology. >>>>>> >>>>>> topology.py is clearly still a work in progress. I've reflected >>>>>> following comments into a patch to speed things up. >>>>>> >>>>>> What's in the patch: >>>>>> >>>>>> 1. git am complains about trailing whitespaces >>>>>> >>>>>> 2. pep8 check produces quite a lot of issues. New code should be >>>>>> almost >>>>>> with any (`E501 line too long` is not a hard rule) >>>>>> `git diff HEAD~1 -U0 | pep8 --diff` >>>>>> >>>>>> 3. some typos >>>>>> >>>>>> 4. A lot of unused imports >>>>>> >>>>>> 5. Option name --sname for 'Segment identifier' is not very >>>>>> friendly. I >>>>>> don't see any examples of command options in the design notes. >>>>>> >>>>>> 6. NO_UPG_MAGIC - leftover from other plugin? >>>>>> >>>>>> 7. suffix object has labels from segment >>>>>> >>>>>> 8. IPA framework has a support for nested object. Key is setting >>>>>> `parent_object = 'topologysuffix'` in topologysegment object. >>>>>> >>>>>> 9. repl_agmt_attrs could be in topologysegment takes_params. >>>>>> >>>>>> 10. missing various CRUD commands like topologysuffix-find and >>>>>> topologysuffix-show commands. >>>>>> >>>>>> Whats missing, not fixed: >>>>>> 1. last 2 lines of VERSION file are not updated >>>>>> >>>>>> 2. Mixed terminology. Somewhere is used suffix and somewhere >>>>>> replication >>>>>> area or just area. >>>>>> >>>>>> 3. Validation >>>>>> - suffix should check for dn >>>>>> - existence of both ends of a segment >>>>>> >>>>>> 4. print of segments in suffix-show needs to be improved or removed >>>>>> >>>>>> To discuss: >>>>>> a) Do params in topologysegment have to have a maxlength set? >>>>>> >>>>>> b) Terminology has to be united. Segments are nested in suffix but >>>>>> sometimes are called areas and suffix is 'the suffix'. User might be >>>>>> confused. E.g. shouldn't the object be named a topologyarea >>>>>> instead of >>>>>> topologysuffix? >>>>>> >>>>>> c) I've added all missing CRUD commands. Are there any which we don't >>>>>> want there, or want to restrict them. E.g. I can imagine that >>>>>> deleting a >>>>>> suffix should be prevented if it contains any segments (or it has >>>>>> to be >>>>>> forced (--force option)) >>>>>> >>>>>> d) Do we want to print segments in suffix-show? >>>>>> >>>>>> e) Mainly for Honza: I've added --show-segments option to suffix-show >>>>>> which defaults to True. I don't like the behavior of CLI, which >>>>>> asks to >>>>>> confirm the value all the time. My intention was to have it there by >>>>>> default, but also allow to disable it by --show-segments=False. I >>>>>> don't >>>>>> want to add it as Flag (--hide-segments) since it restricts >>>>>> versatility. >>>>>> I would like to see an optional flag which would be filled by default >>>>>> value if not explicitly defined and CLI would not ask for the >>>>>> option value. >>>>>> >>>>>> >>>>> >>>>> Also it would be better to split the work into more patches. E.g. >>>>> DS plugin, installation, python plugin. So ds plugin review could >>>>> be separated from the python part. >>>> >>>> >>>> >>> >>> >>> >> >> -- >> Oleg Fayans >> Quality Engineer >> FreeIPA team >> RedHat. > > > > -- Petr Vobornik From mbasti at redhat.com Wed May 20 13:07:26 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 20 May 2015 15:07:26 +0200 Subject: [Freeipa-devel] [PATCH 0035] do not check for directory manager password during KRA uninstall In-Reply-To: <555B7D6C.2050805@redhat.com> References: <555B1BD6.6040406@redhat.com> <555B467E.2000202@redhat.com> <555B4B87.1070406@redhat.com> <555B5CD4.7050001@redhat.com> <555B7D6C.2050805@redhat.com> Message-ID: <555C870E.7070700@redhat.com> On 19/05/15 20:14, Martin Babinsky wrote: > 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. > ACK -- Martin Basti From jcholast at redhat.com Wed May 20 13:13:49 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 20 May 2015 15:13:49 +0200 Subject: [Freeipa-devel] [PATCH 0035] do not check for directory manager password during KRA uninstall In-Reply-To: <555C870E.7070700@redhat.com> References: <555B1BD6.6040406@redhat.com> <555B467E.2000202@redhat.com> <555B4B87.1070406@redhat.com> <555B5CD4.7050001@redhat.com> <555B7D6C.2050805@redhat.com> <555C870E.7070700@redhat.com> Message-ID: <555C888D.9030906@redhat.com> Dne 20.5.2015 v 15:07 Martin Basti napsal(a): > On 19/05/15 20:14, Martin Babinsky wrote: >> 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. >> > ACK > Pushed to master: 9d8ac395c00e48c95f8fdccbc05d43dd144f82ad -- Jan Cholasta From lkrispen at redhat.com Wed May 20 13:40:07 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 20 May 2015 15:40:07 +0200 Subject: [Freeipa-devel] [PATCH] manage replication topology in the shared tree In-Reply-To: <555C86F5.2080708@redhat.com> References: <552B84C5.80300@redhat.com> <55362C43.4020406@redhat.com> <55362FDC.7090104@redhat.com> <55519EAC.9000204@redhat.com> <555B2998.9020608@redhat.com> <555C8392.7010908@redhat.com> <555C84F2.7030500@redhat.com> <555C86F5.2080708@redhat.com> Message-ID: <555C8EB7.5030800@redhat.com> On 05/20/2015 03:07 PM, Petr Vobornik wrote: > On 05/20/2015 02:58 PM, Ludwig Krispenz wrote: >> >> On 05/20/2015 02:52 PM, Oleg Fayans wrote: >>> Is this patch to be applied on top of the vanilla upstream tree, or >>> does it require your previous patches applied before? >> it requires the install (0005) and ipa-command (0006) patch as well, >> submitted on 05/12 > > Patch 0005 can't be applied on top of the new patch 3. Both patches > contains adding of 70topology.ldif. ok, this was my mistake when splitting the original patch, it should only be in the plugin part the trailing spaces in most cases are leftovers from the request to make lines shorter, I will fix it for a new version > > Also please clear all trailing whitespaces from patch 3. > > $ git am > freeipa-lkrispen-0003-plugin-part-manage-replication-topology-in-the-shaer.patch > Applying: plugin part - manage replication topology in the shaerd tree > /home/somebody/freeipa/.git/rebase-apply/patch:607: trailing whitespace. > /home/somebody/freeipa/.git/rebase-apply/patch:740: trailing whitespace. > * find the attrtype and return the corresponding > /home/somebody/freeipa/.git/rebase-apply/patch:742: trailing whitespace. > */ > /home/somebody/freeipa/.git/rebase-apply/patch:745: trailing whitespace. > /* attr is handling specific direction, > /home/somebody/freeipa/.git/rebase-apply/patch:772: trailing whitespace. > /* two static data structures to hold the > warning: squelched 125 whitespace errors > warning: 130 lines add whitespace errors. > > >> >>> >>> On 05/19/2015 02:16 PM, Ludwig Krispenz wrote: >>>> Hi, >>>> >>>> here is the latest patch for the plugin part, trying to address all >>>> problems found in the review >>>> >>>> Regards, >>>> Ludwig >>>> PS if you want you can get a separate diff top the last version >>>> >>>> >>>> On 05/12/2015 08:33 AM, Ludwig Krispenz wrote: >>>>> Hi, >>>>> >>>>> I did split the patches, for easier review and to share work on it. >>>>> The attachment contains 4 patches: >>>>> - the ds plugin part as submitted for review >>>>> - the changes to the ds plugin part done after review (not complete >>>>> yet) >>>>> - the ipa framework part (including Petr's improvements) >>>>> - the install related part >>>>> >>>>> Regards, >>>>> Ludwig >>>>> >>>>> On 04/21/2015 01:09 PM, Petr Vobornik wrote: >>>>>> On 04/21/2015 12:53 PM, Petr Vobornik wrote: >>>>>>> On 04/13/2015 10:56 AM, Ludwig Krispenz wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> in the attachment you find the latest state of the "topology >>>>>>>> plugin", it >>>>>>>> implements what is defined in the design page: >>>>>>>> http://www.freeipa.org/page/V4/Manage_replication_topology >>>>>>>> (which is >>>>>>>> also waiting for a reviewer) >>>>>>>> >>>>>>>> It contains the plugin itself and a core of ipa commands to >>>>>>>> manage a >>>>>>>> topology. to be really applicable, some work outside is required, >>>>>>>> eg the >>>>>>>> management of the domain level and a decision where the binddn >>>>>>>> group >>>>>>>> should be maintained. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Ludwig >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> I've looked at the python part, mostly because I want to start >>>>>>> with POC >>>>>>> of Web UI for topology. >>>>>>> >>>>>>> topology.py is clearly still a work in progress. I've reflected >>>>>>> following comments into a patch to speed things up. >>>>>>> >>>>>>> What's in the patch: >>>>>>> >>>>>>> 1. git am complains about trailing whitespaces >>>>>>> >>>>>>> 2. pep8 check produces quite a lot of issues. New code should be >>>>>>> almost >>>>>>> with any (`E501 line too long` is not a hard rule) >>>>>>> `git diff HEAD~1 -U0 | pep8 --diff` >>>>>>> >>>>>>> 3. some typos >>>>>>> >>>>>>> 4. A lot of unused imports >>>>>>> >>>>>>> 5. Option name --sname for 'Segment identifier' is not very >>>>>>> friendly. I >>>>>>> don't see any examples of command options in the design notes. >>>>>>> >>>>>>> 6. NO_UPG_MAGIC - leftover from other plugin? >>>>>>> >>>>>>> 7. suffix object has labels from segment >>>>>>> >>>>>>> 8. IPA framework has a support for nested object. Key is setting >>>>>>> `parent_object = 'topologysuffix'` in topologysegment object. >>>>>>> >>>>>>> 9. repl_agmt_attrs could be in topologysegment takes_params. >>>>>>> >>>>>>> 10. missing various CRUD commands like topologysuffix-find and >>>>>>> topologysuffix-show commands. >>>>>>> >>>>>>> Whats missing, not fixed: >>>>>>> 1. last 2 lines of VERSION file are not updated >>>>>>> >>>>>>> 2. Mixed terminology. Somewhere is used suffix and somewhere >>>>>>> replication >>>>>>> area or just area. >>>>>>> >>>>>>> 3. Validation >>>>>>> - suffix should check for dn >>>>>>> - existence of both ends of a segment >>>>>>> >>>>>>> 4. print of segments in suffix-show needs to be improved or removed >>>>>>> >>>>>>> To discuss: >>>>>>> a) Do params in topologysegment have to have a maxlength set? >>>>>>> >>>>>>> b) Terminology has to be united. Segments are nested in suffix but >>>>>>> sometimes are called areas and suffix is 'the suffix'. User >>>>>>> might be >>>>>>> confused. E.g. shouldn't the object be named a topologyarea >>>>>>> instead of >>>>>>> topologysuffix? >>>>>>> >>>>>>> c) I've added all missing CRUD commands. Are there any which we >>>>>>> don't >>>>>>> want there, or want to restrict them. E.g. I can imagine that >>>>>>> deleting a >>>>>>> suffix should be prevented if it contains any segments (or it has >>>>>>> to be >>>>>>> forced (--force option)) >>>>>>> >>>>>>> d) Do we want to print segments in suffix-show? >>>>>>> >>>>>>> e) Mainly for Honza: I've added --show-segments option to >>>>>>> suffix-show >>>>>>> which defaults to True. I don't like the behavior of CLI, which >>>>>>> asks to >>>>>>> confirm the value all the time. My intention was to have it >>>>>>> there by >>>>>>> default, but also allow to disable it by --show-segments=False. I >>>>>>> don't >>>>>>> want to add it as Flag (--hide-segments) since it restricts >>>>>>> versatility. >>>>>>> I would like to see an optional flag which would be filled by >>>>>>> default >>>>>>> value if not explicitly defined and CLI would not ask for the >>>>>>> option value. >>>>>>> >>>>>>> >>>>>> >>>>>> Also it would be better to split the work into more patches. E.g. >>>>>> DS plugin, installation, python plugin. So ds plugin review could >>>>>> be separated from the python part. >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> -- >>> Oleg Fayans >>> Quality Engineer >>> FreeIPA team >>> RedHat. >> >> >> >> > > From pvoborni at redhat.com Wed May 20 13:57:34 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 20 May 2015 15:57:34 +0200 Subject: [Freeipa-devel] [PATCH] 854 git ignore ipaplatform/__init__.py Message-ID: <555C92CE.1070603@redhat.com> This file is generated in `make version-update` added in 9f049ca14403f3696d54d186e6b1b15181f055df -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0854-git-ignore-ipaplatform-__init__.py.patch Type: text/x-patch Size: 748 bytes Desc: not available URL: From jcholast at redhat.com Wed May 20 14:28:11 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 20 May 2015 16:28:11 +0200 Subject: [Freeipa-devel] [PATCH 428] client-install: Fix kinits with non-default Kerberos config file Message-ID: <555C99FB.2030308@redhat.com> Hi, the attached patch fixes a bug introduced in the fix for (reopened). Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-428-client-install-Fix-kinits-with-non-default-Kerberos-.patch Type: text/x-patch Size: 4596 bytes Desc: not available URL: From ftweedal at redhat.com Wed May 20 14:41:06 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 21 May 2015 00:41:06 +1000 Subject: [Freeipa-devel] [PATCHES 0001-0011 v3] Profile management In-Reply-To: <555C30FE.4030707@redhat.com> References: <555305EC.5020001@redhat.com> <55530D23.5040702@redhat.com> <55530DDB.9000101@redhat.com> <20150515082420.GR12806@dhcp-40-8.bne.redhat.com> <5555E63D.4050808@redhat.com> <555AF9E1.1010606@redhat.com> <20150519115027.GA12806@dhcp-40-8.bne.redhat.com> <555C1E5C.2080707@redhat.com> <20150520055636.GF12806@dhcp-40-8.bne.redhat.com> <555C30FE.4030707@redhat.com> Message-ID: <20150520144106.GH12806@dhcp-40-8.bne.redhat.com> Hi Honza, Martin et al, Latest patches attached. On top of previous patches (most review matters addressed**) patches 0008..0011 add support for profiles and user certificates to `ipa cert-request'. ** those that were not are being tracked at [1]; please add anything I missed. Some points to note: - usercertificate is not yet a multi-valued attribute for users, hosts and services. QUESTION - we do want to allow multiple certificates for all principal types, not just users? Or have I got that wrong. - "DN and SAN match principal" checks are not implemented for users yet. - ACL was added to allow user principals to request their own certificates, however, this will be further subject to CA/profile ACLs which are to come. - Pursuant to [2] revocation logic was removed from `cert-request' [1] http://idm.etherpad.corp.redhat.com/rhel72-cert-mgmt-progress [2] http://www.freeipa.org/page/V4/User_Certificates#Revocation_of_the_Certificates Thanks, Fraser -------------- next part -------------- >From 07599bb290fdd23990c978489bc3b08d493caed6 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 20 Apr 2015 23:20:19 -0400 Subject: [PATCH 01/11] Install CA with LDAP profiles backend Install the Dogtag CA to use the LDAPProfileSubsystem instead of the default (file-based) ProfileSubsystem. Part of: https://fedorahosted.org/freeipa/ticket/4560 --- ipaserver/install/cainstance.py | 1 + 1 file changed, 1 insertion(+) diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index 5133940687204b615eec56b6a89542ddd5617539..030c9f12daba4b38b748da8940e38d3cf2109788 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -503,6 +503,7 @@ class CAInstance(DogtagInstance): config.set("CA", "pki_restart_configured_instance", "False") config.set("CA", "pki_backup_keys", "True") config.set("CA", "pki_backup_password", self.admin_password) + config.set("CA", "pki_profiles_in_ldap", "True") # Client security database config.set("CA", "pki_client_database_dir", self.agent_db) -- 2.1.0 -------------- next part -------------- >From c1fafbce7b077c6981381b727f1dc9571ccf2f19 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Tue, 21 Apr 2015 02:24:10 -0400 Subject: [PATCH 02/11] Add schema for certificate profiles The certprofile object class is used to track IPA-managed certificate profiles in Dogtag and store IPA-specific settings. Part of: https://fedorahosted.org/freeipa/ticket/57 --- install/share/60certificate-profiles.ldif | 3 +++ install/share/Makefile.am | 1 + install/share/bootstrap-template.ldif | 12 ++++++++++++ ipaserver/install/dsinstance.py | 1 + 4 files changed, 17 insertions(+) create mode 100644 install/share/60certificate-profiles.ldif diff --git a/install/share/60certificate-profiles.ldif b/install/share/60certificate-profiles.ldif new file mode 100644 index 0000000000000000000000000000000000000000..dcf4680589c98dad165141b1e13946c161a6abd7 --- /dev/null +++ b/install/share/60certificate-profiles.ldif @@ -0,0 +1,3 @@ +dn: cn=schema +attributeTypes: (2.16.840.1.113730.3.8.19.1.1 NAME 'ipaCertProfileStoreIssued' DESC 'Store certificates issued using this profile' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA v4.2' ) +objectClasses: (2.16.840.1.113730.3.8.19.2.1 NAME 'ipaCertProfile' SUP top STRUCTURAL MUST ( cn $ description $ ipaCertProfileStoreIssued ) X-ORIGIN 'IPA v4.2' ) diff --git a/install/share/Makefile.am b/install/share/Makefile.am index ca6128e2911ab5c0a773dd553f8e67eab944f120..2cae5279079cdd3e0d793667f4d1bf4e44757b9e 100644 --- a/install/share/Makefile.am +++ b/install/share/Makefile.am @@ -16,6 +16,7 @@ app_DATA = \ 60basev3.ldif \ 60ipadns.ldif \ 60ipapk11.ldif \ + 60certificate-profiles.ldif \ 61kerberos-ipav3.ldif \ 65ipacertstore.ldif \ 65ipasudo.ldif \ diff --git a/install/share/bootstrap-template.ldif b/install/share/bootstrap-template.ldif index 06b82aa4ae74e7766d0c09a63aa75fa222e7ab7d..c5d4bad8b80640881f4631e4873a12c82b0ea48a 100644 --- a/install/share/bootstrap-template.ldif +++ b/install/share/bootstrap-template.ldif @@ -429,3 +429,15 @@ cn: ${REALM}_id_range ipaBaseID: $IDSTART ipaIDRangeSize: $IDRANGE_SIZE ipaRangeType: ipa-local + +dn: cn=ca,$SUFFIX +changetype: add +objectClass: nsContainer +objectClass: top +cn: ca + +dn: cn=certprofiles,cn=ca,$SUFFIX +changetype: add +objectClass: nsContainer +objectClass: top +cn: certprofiles diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py index f1d24e49d1b184efde1c8d18ff37d0e329037ccc..210992fc41127de29d41b889e33a312613ae28da 100644 --- a/ipaserver/install/dsinstance.py +++ b/ipaserver/install/dsinstance.py @@ -56,6 +56,7 @@ IPA_SCHEMA_FILES = ("60kerberos.ldif", "60basev3.ldif", "60ipapk11.ldif", "60ipadns.ldif", + "60certificate-profiles.ldif", "61kerberos-ipav3.ldif", "65ipacertstore.ldif", "65ipasudo.ldif", -- 2.1.0 -------------- next part -------------- >From fc1dfcd7f8a9241c81ac97164a6e5699da74aa1b Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Wed, 29 Apr 2015 06:07:58 -0400 Subject: [PATCH 03/11] ipa-pki-proxy: provide access to profiles REST API Part of: https://fedorahosted.org/freeipa/ticket/57 --- install/conf/ipa-pki-proxy.conf | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/install/conf/ipa-pki-proxy.conf b/install/conf/ipa-pki-proxy.conf index 5d21156848f3b5ddf14c42d92a26a30a9f94af36..366ca15a1868758547f9f1d3334fddba38793083 100644 --- a/install/conf/ipa-pki-proxy.conf +++ b/install/conf/ipa-pki-proxy.conf @@ -1,4 +1,4 @@ -# VERSION 5 - DO NOT REMOVE THIS LINE +# VERSION 6 - DO NOT REMOVE THIS LINE ProxyRequests Off @@ -11,7 +11,7 @@ ProxyRequests Off # matches for admin port and installer - + NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate NSSVerifyClient none ProxyPassMatch ajp://localhost:$DOGTAG_PORT @@ -26,5 +26,13 @@ ProxyRequests Off ProxyPassReverse ajp://localhost:$DOGTAG_PORT +# matches for REST API + + NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate + NSSVerifyClient require + ProxyPassMatch ajp://localhost:$DOGTAG_PORT + ProxyPassReverse ajp://localhost:$DOGTAG_PORT + + # Only enable this on servers that are not generating a CRL ${CLONE}RewriteRule ^/ipa/crl/MasterCRL.bin https://$FQDN/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL [L,R=301,NC] -- 2.1.0 -------------- next part -------------- >From ae5f5dae49ad891864bbdcbc5c2d9f592521fe74 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Thu, 30 Apr 2015 23:50:41 -0400 Subject: [PATCH 04/11] Add ACL to allow CA agent to modify profiles Part of: https://fedorahosted.org/freeipa/ticket/57 --- install/tools/ipa-upgradeconfig | 19 +++++++++++++++++++ ipaserver/install/cainstance.py | 26 ++++++++++++++++++++++++++ 2 files changed, 45 insertions(+) diff --git a/install/tools/ipa-upgradeconfig b/install/tools/ipa-upgradeconfig index dfef1e0aa8b1507b7aa4907e9b688ce99253b87c..92c4934874f12c7017329bdcb67ac9a888f6e389 100755 --- a/install/tools/ipa-upgradeconfig +++ b/install/tools/ipa-upgradeconfig @@ -31,6 +31,7 @@ import pwd import fileinput import ConfigParser import grp +import ldap from ipalib import api import SSSDConfig @@ -40,6 +41,7 @@ from ipaplatform import services from ipaplatform.tasks import tasks from ipapython import ipautil, sysrestore, version, certdb from ipapython.config import IPAOptionParser +from ipapython.dn import DN from ipapython.ipa_log_manager import * from ipapython import certmonger from ipapython import dogtag @@ -322,6 +324,22 @@ def setup_firefox_extension(fstore): http.setup_firefox_extension(realm, domain) +def ca_configure_profiles_acl(ca): + root_logger.info('[Authorizing RA Agent to modify profiles]') + + if not ca.is_configured(): + root_logger.info('CA is not configured') + return False + + if sysupgrade.get_upgrade_state('dogtag', 'agent_allow_profile_modify'): + return False + + cainstance.configure_profiles_acl() + + sysupgrade.set_upgrade_state('dogtag', 'agent_allow_profile_modifiy', True) + return True + + def upgrade_ipa_profile(ca, domain, fqdn): """ Update the IPA Profile provided by dogtag @@ -1420,6 +1438,7 @@ def main(): upgrade_ipa_profile(ca, api.env.domain, fqdn), certificate_renewal_update(ca), ca_enable_pkix(ca), + ca_configure_profiles_acl(ca), ]) if ca_restart: diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index 030c9f12daba4b38b748da8940e38d3cf2109788..d85210e02a6b4a5e664d57965299d775836ae5c5 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -469,6 +469,7 @@ class CAInstance(DogtagInstance): self.step("requesting RA certificate from CA", self.__request_ra_certificate) self.step("issuing RA agent certificate", self.__issue_ra_cert) self.step("adding RA agent as a trusted user", self.__configure_ra) + self.step("authorizing RA to modify profiles", self.__configure_profiles_acl) self.step("configure certmonger for renewals", self.configure_certmonger_renewal) self.step("configure certificate renewals", self.configure_renewal) if not self.clone: @@ -940,6 +941,10 @@ class CAInstance(DogtagInstance): conn.unbind() + def __configure_profiles_acl(self): + """Allow the Certificate Manager Agents group to modify profiles.""" + configure_profiles_acl() + def __run_certutil(self, args, database=None, pwd_file=None, stdin=None): if not database: database = self.ra_agent_db @@ -1825,6 +1830,27 @@ def update_people_entry(dercert): return True +def configure_profiles_acl(): + server_id = installutils.realm_to_serverid(api.env.realm) + dogtag_uri = 'ldapi://%%2fvar%%2frun%%2fslapd-%s.socket' % server_id + updated = False + + dn = DN(('cn', 'aclResources'), ('o', 'ipaca')) + rule = ( + 'certServer.profile.configuration:read,modify:allow (read,modify) ' + 'group="Certificate Manager Agents":' + 'Certificate Manager agents may modify (create/update/delete) and read profiles' + ) + modlist = [(ldap.MOD_ADD, 'resourceACLS', [rule])] + + conn = ldap2.ldap2(shared_instance=False, ldap_uri=dogtag_uri) + if not conn.isconnected(): + conn.connect(autobind=True) + rules = conn.get_entry(dn).get('resourceACLS', []) + if rule not in rules: + conn.conn.modify_s(str(dn), modlist) + conn.disconnect() + if __name__ == "__main__": standard_logging_setup("install.log") ds = dsinstance.DsInstance() -- 2.1.0 -------------- next part -------------- >From 7302ce777669ab4300c3919abe91565dd3cd1641 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Thu, 30 Apr 2015 04:55:29 -0400 Subject: [PATCH 05/11] Add certprofile plugin Add the 'certprofile' plugin which defines the commands for managing certificate profiles and associated permissions. Also update Dogtag network code in 'ipapython.dogtag' to support headers and arbitrary request bodies, to facilitate use of the Dogtag profiles REST API. Part of: https://fedorahosted.org/freeipa/ticket/57 --- ACI.txt | 8 ++ API.txt | 62 +++++++++ install/updates/40-certprofile.update | 9 ++ install/updates/40-delegation.update | 8 ++ install/updates/Makefile.am | 1 + ipalib/constants.py | 1 + ipalib/plugins/certprofile.py | 253 ++++++++++++++++++++++++++++++++++ ipapython/dogtag.py | 29 ++-- ipaserver/plugins/dogtag.py | 176 ++++++++++++++++++++++- 9 files changed, 534 insertions(+), 13 deletions(-) create mode 100644 install/updates/40-certprofile.update create mode 100644 ipalib/plugins/certprofile.py diff --git a/ACI.txt b/ACI.txt index bf539892910f14ebc3fbee88a72d2b57c0d1327b..870a343f0e59fa2075b53e881c224d4965984d08 100644 --- a/ACI.txt +++ b/ACI.txt @@ -22,6 +22,14 @@ dn: cn=automount,dc=ipa,dc=example aci: (targetattr = "automountmapname || description")(targetfilter = "(objectclass=automountmap)")(version 3.0;acl "permission:System: Modify Automount Maps";allow (write) groupdn = "ldap:///cn=System: Modify Automount Maps,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: cn=automount,dc=ipa,dc=example aci: (targetfilter = "(objectclass=automountmap)")(version 3.0;acl "permission:System: Remove Automount Maps";allow (delete) groupdn = "ldap:///cn=System: Remove Automount Maps,cn=permissions,cn=pbac,dc=ipa,dc=example";) +dn: cn=certprofiles,cn=ca,dc=ipa,dc=example +aci: (targetfilter = "(objectclass=ipacertprofile)")(version 3.0;acl "permission:System: Delete Certificate Profile";allow (delete) groupdn = "ldap:///cn=System: Delete Certificate Profile,cn=permissions,cn=pbac,dc=ipa,dc=example";) +dn: cn=certprofiles,cn=ca,dc=ipa,dc=example +aci: (targetfilter = "(objectclass=ipacertprofile)")(version 3.0;acl "permission:System: Import Certificate Profile";allow (add) groupdn = "ldap:///cn=System: Import Certificate Profile,cn=permissions,cn=pbac,dc=ipa,dc=example";) +dn: cn=certprofiles,cn=ca,dc=ipa,dc=example +aci: (targetattr = "cn || description || ipacertprofilestoreissued")(targetfilter = "(objectclass=ipacertprofile)")(version 3.0;acl "permission:System: Modify Certificate Profile";allow (write) groupdn = "ldap:///cn=System: Modify Certificate Profile,cn=permissions,cn=pbac,dc=ipa,dc=example";) +dn: cn=certprofiles,cn=ca,dc=ipa,dc=example +aci: (targetattr = "cn || createtimestamp || description || entryusn || ipacertprofilestoreissued || modifytimestamp || objectclass")(targetfilter = "(objectclass=ipacertprofile)")(version 3.0;acl "permission:System: Read Certificate Profiles";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=ipaconfig,cn=etc,dc=ipa,dc=example aci: (targetattr = "cn || createtimestamp || entryusn || ipacertificatesubjectbase || ipaconfigstring || ipacustomfields || ipadefaultemaildomain || ipadefaultloginshell || ipadefaultprimarygroup || ipagroupobjectclasses || ipagroupsearchfields || ipahomesrootdir || ipakrbauthzdata || ipamaxusernamelength || ipamigrationenabled || ipapwdexpadvnotify || ipasearchrecordslimit || ipasearchtimelimit || ipaselinuxusermapdefault || ipaselinuxusermaporder || ipauserauthtype || ipauserobjectclasses || ipausersearchfields || modifytimestamp || objectclass")(targetfilter = "(objectclass=ipaguiconfig)")(version 3.0;acl "permission:System: Read Global Configuration";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=costemplates,cn=accounts,dc=ipa,dc=example diff --git a/API.txt b/API.txt index 0808f3c64595495c8a9e60da5cbd689d5cdc6224..55d2baccaaf7a6cd891aa872935c01c76781c273 100644 --- a/API.txt +++ b/API.txt @@ -509,6 +509,68 @@ args: 1,1,1 arg: Str('request_id') option: Str('version?', exclude='webui') output: Output('result', None, None) +command: certprofile_del +args: 1,2,3 +arg: Str('cn', attribute=True, cli_name='id', multivalue=True, 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', , None) +output: Output('summary', (, ), None) +output: ListOfPrimaryKeys('value', None, None) +command: certprofile_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='id', multivalue=False, primary_key=True, query=True, required=False) +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, query=True, required=False) +option: Bool('ipacertprofilestoreissued', attribute=True, autofill=False, cli_name='store', default=True, multivalue=False, query=True, required=False) +option: Flag('pkey_only?', autofill=True, default=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Int('sizelimit?', autofill=False, minvalue=0) +option: Int('timelimit?', autofill=False, minvalue=0) +option: Str('version?', exclude='webui') +output: Output('count', , None) +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('truncated', , None) +command: certprofile_import +args: 1,6,3 +arg: Str('cn', attribute=True, cli_name='id', multivalue=False, primary_key=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=True) +option: File('file', cli_name='file') +option: Bool('ipacertprofilestoreissued', attribute=True, cli_name='store', default=True, multivalue=False, required=True) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: certprofile_mod +args: 1,10,3 +arg: Str('cn', attribute=True, cli_name='id', multivalue=False, primary_key=True, query=True, required=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('delattr*', cli_name='delattr', exclude='webui') +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) +option: Bool('ipacertprofilestoreissued', attribute=True, autofill=False, cli_name='store', default=True, multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('rename', cli_name='rename', multivalue=False, primary_key=True, required=False) +option: Flag('rights', autofill=True, default=False) +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: certprofile_show +args: 1,4,3 +arg: Str('cn', attribute=True, cli_name='id', multivalue=False, primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) command: compat_is_enabled args: 0,1,1 option: Str('version?', exclude='webui') diff --git a/install/updates/40-certprofile.update b/install/updates/40-certprofile.update new file mode 100644 index 0000000000000000000000000000000000000000..6b0a81d0ff6d69dabe82138227d105fc780ee17d --- /dev/null +++ b/install/updates/40-certprofile.update @@ -0,0 +1,9 @@ +dn: cn=ca,$SUFFIX +default: objectClass: nsContainer +default: objectClass: top +default: cn: ca + +dn: cn=certprofiles,cn=ca,$SUFFIX +default: objectClass: nsContainer +default: objectClass: top +default: cn: certprofiles diff --git a/install/updates/40-delegation.update b/install/updates/40-delegation.update index 975929bd70400b2f9cf407d6faedb246003d7f58..bc0736c5b6c07747586a56c2cbde9596c7522d1c 100644 --- a/install/updates/40-delegation.update +++ b/install/updates/40-delegation.update @@ -237,3 +237,11 @@ default:ipapermissiontype: SYSTEM dn: cn=config add:aci: (version 3.0;acl "permission:Add Configuration Sub-Entries";allow (add) groupdn = "ldap:///cn=Add Configuration Sub-Entries,cn=permissions,cn=pbac,$SUFFIX";) + +# CA Administrators +dn: cn=CA Administrator,cn=privileges,cn=pbac,$SUFFIX +default:objectClass: nestedgroup +default:objectClass: groupofnames +default:objectClass: top +default:cn: CA Administrator +default:description: CA Administrator diff --git a/install/updates/Makefile.am b/install/updates/Makefile.am index 0d63d9ea8d85f1add5f036e7a39f89543586d33b..cd44f08d4cd736ee19caf8ec1b8df604c9c2fa9d 100644 --- a/install/updates/Makefile.am +++ b/install/updates/Makefile.am @@ -32,6 +32,7 @@ app_DATA = \ 40-replication.update \ 40-dns.update \ 40-automember.update \ + 40-certprofile.update \ 40-otp.update \ 45-roles.update \ 50-7_bit_check.update \ diff --git a/ipalib/constants.py b/ipalib/constants.py index f1e14702ffdf5a3bd23a62b1fdd2ee3cd95d84f8..3722ab1999938ad021b8789645368633eac7f08b 100644 --- a/ipalib/constants.py +++ b/ipalib/constants.py @@ -116,6 +116,7 @@ DEFAULT_CONFIG = ( ('container_otp', DN(('cn', 'otp'))), ('container_radiusproxy', DN(('cn', 'radiusproxy'))), ('container_views', DN(('cn', 'views'), ('cn', 'accounts'))), + ('container_certprofile', DN(('cn', 'certprofiles'), ('cn', 'ca'))), # Ports, hosts, and URIs: ('xmlrpc_uri', 'http://localhost:8888/ipa/xml'), diff --git a/ipalib/plugins/certprofile.py b/ipalib/plugins/certprofile.py new file mode 100644 index 0000000000000000000000000000000000000000..3d9e807445f55b5406640a268ab0d50ddedc896d --- /dev/null +++ b/ipalib/plugins/certprofile.py @@ -0,0 +1,253 @@ +# +# Copyright (C) 2015 FreeIPA Contributors see COPYING for license +# + +import re + +from ipalib import api, Bool, File, Str +from ipalib import output +from ipalib.plugable import Registry +from ipalib.plugins.virtual import VirtualCommand +from ipalib.plugins.baseldap import ( + LDAPObject, LDAPSearch, LDAPCreate, + LDAPDelete, LDAPUpdate, LDAPRetrieve) +from ipalib import ngettext +from ipalib.text import _ + +from ipalib import errors + + +__doc__ = _(""" +Manage Certificate Profiles + +Certificate Profiles are used by Certificate Authority (CA) in the signing of +certificates to determine if a Certificate Signing Request (CSR) is acceptable, +and if so what features and extensions will be present on the certificate. + +The Certificate Profile format is the property-list format understood by the +Dogtag or Red Hat Certificate System CA. + +PROFILE ID SYNTAX: + +A Profile ID is a string without spaces or punctuation starting with a letter +and followed by a sequence of letters, digits or underscore ("_"). + +EXAMPLES: + + Import a profile that will not store issued certificates: + ipa certprofile-import ShortLivedUserCert \\ + --file UserCert.profile --summary "User Certificates" \\ + --store=false + + Delete a certificate profile: + ipa certprofile-del ShortLivedUserCert + + Show information about a profile: + ipa certprofile-show ShortLivedUserCert + + Search for profiles that do not store certificates: + ipa certprofile-find --store=false + +""") + + +register = Registry() + + +def ca_enabled_check(): + """Raise NotFound if CA is not enabled. + + This function is defined in multiple plugins to avoid circular imports + (cert depends on certprofile, so we cannot import cert here). + + """ + if not api.Command.ca_is_enabled()['result']: + raise errors.NotFound(reason=_('CA is not configured')) + + +profile_id_pattern = re.compile('^[a-zA-Z]\w*$') + + +def validate_profile_id(ugettext, value): + """Ensure profile ID matches form required by CA.""" + if profile_id_pattern.match(value) is None: + return _('invalid Profile ID') + else: + return None + + + at register() +class certprofile(LDAPObject): + """ + Certificate Profile object. + """ + container_dn = api.env.container_certprofile + object_name = _('Certificate Profile') + object_name_plural = _('Certificate Profiles') + object_class = ['ipacertprofile'] + default_attributes = [ + 'cn', 'description', 'ipacertprofilestoreissued' + ] + search_attributes = [ + 'cn', 'description', 'ipacertprofilestoreissued' + ] + rdn_is_primary_key = True + label = _('Certificate Profiles') + label_singular = _('Certificate Profile') + + takes_params = ( + Str('cn', validate_profile_id, + primary_key=True, + cli_name='id', + label=_('Profile ID'), + doc=_('Profile ID for referring to this profile'), + ), + Str('description', + required=True, + cli_name='desc', + label=_('Profile description'), + doc=_('Brief description of this profile'), + ), + Bool('ipacertprofilestoreissued', + default=True, + cli_name='store', + label=_('Store issued certificates'), + doc=_('Whether to store certs issued using this profile'), + ), + ) + + permission_filter_objectclasses = ['ipacertprofile'] + managed_permissions = { + 'System: Read Certificate Profiles': { + 'replaces_global_anonymous_aci': True, + 'ipapermbindruletype': 'all', + 'ipapermright': {'read', 'search', 'compare'}, + 'ipapermdefaultattr': { + 'cn', + 'description', + 'ipacertprofilestoreissued', + 'objectclass', + }, + }, + 'System: Import Certificate Profile': { + 'ipapermright': {'add'}, + 'replaces': [ + '(target = "ldap:///cn=*,cn=certprofiles,cn=ca,$SUFFIX")(version 3.0;acl "permission:Import Certificate Profile";allow (add) groupdn = "ldap:///cn=Import Certificate Profile,cn=permissions,cn=pbac,$SUFFIX";)', + ], + 'default_privileges': {'CA Administrator'}, + }, + 'System: Delete Certificate Profile': { + 'ipapermright': {'delete'}, + 'replaces': [ + '(target = "ldap:///cn=*,cn=certprofiles,cn=ca,$SUFFIX")(version 3.0;acl "permission:Delete Certificate Profile";allow (delete) groupdn = "ldap:///cn=Delete Certificate Profile,cn=permissions,cn=pbac,$SUFFIX";)', + ], + 'default_privileges': {'CA Administrator'}, + }, + 'System: Modify Certificate Profile': { + 'ipapermright': {'write'}, + 'ipapermdefaultattr': { + 'cn', + 'description', + 'ipacertprofilestoreissued', + }, + 'replaces': [ + '(targetattr = "cn || description || ipacertprofilestoreissued")(target = "ldap:///cn=*,cn=certprofiles,cn=ca,$SUFFIX")(version 3.0;acl "permission:Modify Certificate Profile";allow (write) groupdn = "ldap:///cn=Modify Certificate Profile,cn=permissions,cn=pbac,$SUFFIX";)', + ], + 'default_privileges': {'CA Administrator'}, + }, + } + + + + at register() +class certprofile_find(LDAPSearch): + __doc__ = _("Search for Certificate Profiles.") + msg_summary = ngettext( + '%(count)d profile matched', '%(count)d profiles matched', 0 + ) + + def execute(self, *args, **kwargs): + ca_enabled_check() + return super(certprofile_find, self).execute(self, *args, **kwargs) + + + at register() +class certprofile_show(LDAPRetrieve): + __doc__ = _("Display the properties of a Certificate Profile.") + + def execute(self, *args, **kwargs): + ca_enabled_check() + return super(certprofile_show, self).execute(self, *args, **kwargs) + + + at register() +class certprofile_import(LDAPCreate): + __doc__ = _("Import a Certificate Profile.") + msg_summary = _('Imported profile "%(value)s"') + takes_options = ( + File('file', + label=_('Filename'), + cli_name='file', + flags=('virtual_attribute',), + ), + ) + + PROFILE_ID_PATTERN = re.compile('^profileId=(\w+)', re.MULTILINE) + + def pre_callback(self, ldap, dn, entry, entry_attrs, *keys, **options): + ca_enabled_check() + + match = self.PROFILE_ID_PATTERN.search(options['file']) + if match is None: + raise errors.ValidationError(name='file', + error=_("Profile ID is not present in profile data")) + elif keys[0] != match.group(1): + raise errors.ValidationError(name='file', + error=_("Profile ID '%(cli_value)s' does not match profile data '%(file_value)s'") + % {'cli_value': keys[0], 'file_value': match.group(1)} + ) + return dn + + + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + """Import the profile into Dogtag and enable it. + + If the operation succeeds, update the LDAP entry to 'enabled'. + If the operation fails, remove the LDAP entry. + """ + try: + with self.api.Backend.ra_certprofile as profile_api: + profile_api.create_profile(options['file']) + profile_api.enable_profile(keys[0]) + except: + # something went wrong ; delete entry + ldap.delete_entry(dn) + raise + + return dn + + + at register() +class certprofile_del(LDAPDelete): + __doc__ = _("Delete a Certificate Profile.") + msg_summary = _('Deleted profile "%(value)s"') + + def execute(self, *args, **kwargs): + ca_enabled_check() + return super(certprofile_del, self).execute(self, *args, **kwargs) + + def post_callback(self, ldap, dn, *keys, **options): + with self.api.Backend.ra_certprofile as profile_api: + profile_api.disable_profile(keys[0]) + profile_api.delete_profile(keys[0]) + return dn + + + at register() +class certprofile_mod(LDAPUpdate): + __doc__ = _("Modify Certificate Profile configuration.") + msg_summary = _('Modified Certificate Profile "%(value)s') + + def execute(self, *args, **kwargs): + ca_enabled_check() + return super(certprofile_mod, self).execute(self, *args, **kwargs) diff --git a/ipapython/dogtag.py b/ipapython/dogtag.py index c74b8736a4b15f7bf081206b52b9876a8c4928af..11311cf7b55d7b84e9434a698dbfd60b0eb142a1 100644 --- a/ipapython/dogtag.py +++ b/ipapython/dogtag.py @@ -233,9 +233,12 @@ def ca_status(ca_host=None, use_proxy=True): return _parse_ca_status(body) -def https_request(host, port, url, secdir, password, nickname, **kw): +def https_request(host, port, url, secdir, password, nickname, + method='POST', headers=None, body=None, **kw): """ + :param method: HTTP request method (defalut: 'POST') :param url: The path (not complete URL!) to post to. + :param body: The request body (encodes kw if None) :param kw: Keyword arguments to encode into POST body. :return: (http_status, http_reason_phrase, http_headers, http_body) as (integer, unicode, dict, str) @@ -254,9 +257,11 @@ def https_request(host, port, url, secdir, password, nickname, **kw): nickname, password, nss.get_default_certdb()) return conn - body = urlencode(kw) + if body is None: + body = urlencode(kw) return _httplib_request( - 'https', host, port, url, connection_factory, body) + 'https', host, port, url, connection_factory, body, + method=method, headers=headers) def http_request(host, port, url, **kw): @@ -288,11 +293,13 @@ def unauthenticated_https_request(host, port, url, **kw): def _httplib_request( - protocol, host, port, path, connection_factory, request_body): + protocol, host, port, path, connection_factory, request_body, + method='POST', headers=None): """ :param request_body: Request body :param connection_factory: Connection class to use. Will be called with the host and port arguments. + :param method: HTTP request method (default: 'POST') Perform a HTTP(s) request. """ @@ -301,13 +308,17 @@ def _httplib_request( uri = '%s://%s%s' % (protocol, ipautil.format_netloc(host, port), path) root_logger.debug('request %r', uri) root_logger.debug('request body %r', request_body) + + headers = headers or {} + if ( + method == 'POST' + and 'content-type' not in (str(k).lower() for k in headers.viewkeys()) + ): + headers['content-type'] = 'application/x-www-form-urlencoded' + try: conn = connection_factory(host, port) - conn.request( - 'POST', uri, - body=request_body, - headers={'Content-type': 'application/x-www-form-urlencoded'}, - ) + conn.request(method, uri, body=request_body, headers=headers) res = conn.getresponse() http_status = res.status diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py index 52bdb0d4245594785e718c63242e27cee0e59322..9654123b16d8e417398d49bf1305fd41880bc3a7 100644 --- a/ipaserver/plugins/dogtag.py +++ b/ipaserver/plugins/dogtag.py @@ -4,8 +4,9 @@ # Jason Gerard DeRose # Rob Crittenden # John Dennis +# Fraser Tweedale # -# Copyright (C) 2014 Red Hat +# Copyright (C) 2014, 2015 Red Hat # see file 'COPYING' for use and warranty information # # This program is free software; you can redistribute it and/or modify @@ -238,17 +239,21 @@ digits and nothing else follows. ''' import datetime +import json from lxml import etree +import os import tempfile import time import urllib2 +import pki from pki.client import PKIConnection import pki.crypto as cryptoutil from pki.kra import KRAClient from ipalib import Backend from ipapython.dn import DN +import ipapython.cookie import ipapython.dogtag from ipapython import ipautil from ipaserver.install.certs import CertDB @@ -1262,13 +1267,12 @@ def select_any_master(ldap2, service='CA'): #------------------------------------------------------------------------------- -from ipalib import api, SkipPluginModule +from ipalib import api, errors, SkipPluginModule if api.env.ra_plugin != 'dogtag': # In this case, abort loading this plugin module... raise SkipPluginModule(reason='dogtag not selected as RA plugin') import os, random from ipaserver.plugins import rabase -from ipalib.errors import CertificateOperationError from ipalib.constants import TYPE_ERROR from ipalib.util import cachedproperty from ipapython import dogtag @@ -1318,7 +1322,7 @@ class ra(rabase.rabase): err_msg = u'%s (%s)' % (err_msg, detail) self.error('%s.%s(): %s', self.fullname, func_name, err_msg) - raise CertificateOperationError(error=err_msg) + raise errors.CertificateOperationError(error=err_msg) @cachedproperty def ca_host(self): @@ -1923,3 +1927,167 @@ class kra(Backend): return KRAClient(connection, crypto) api.register(kra) + + +class RestClient(Backend): + """Simple Dogtag REST client to be subclassed by other backends. + + This class is a context manager. Authenticated calls must be + executed in a ``with`` suite:: + + class ra_certprofile(RestClient): + path = 'profile' + ... + + api.register(ra_certprofile) + + with api.Backend.ra_certprofile as profile_api: + # REST client is now logged in + profile_api.create_profile(...) + + """ + path = None + + @staticmethod + def _parse_dogtag_error(body): + try: + return pki.PKIException.from_json(json.loads(body)) + except: + return None + + def __init__(self): + if api.env.in_tree: + self.sec_dir = api.env.dot_ipa + os.sep + 'alias' + self.pwd_file = self.sec_dir + os.sep + '.pwd' + else: + self.sec_dir = paths.HTTPD_ALIAS_DIR + self.pwd_file = paths.ALIAS_PWDFILE_TXT + self.noise_file = self.sec_dir + os.sep + '.noise' + self.ipa_key_size = "2048" + self.ipa_certificate_nickname = "ipaCert" + self.ca_certificate_nickname = "caCert" + try: + f = open(self.pwd_file, "r") + self.password = f.readline().strip() + f.close() + except IOError: + self.password = '' + super(RestClient, self).__init__() + + # session cookie + self.cookie = None + + @cachedproperty + def ca_host(self): + """ + :return: host + as str + + Select our CA host. + """ + ldap2 = self.api.Backend.ldap2 + if host_has_service(api.env.ca_host, ldap2, "CA"): + return api.env.ca_host + if api.env.host != api.env.ca_host: + if host_has_service(api.env.host, ldap2, "CA"): + return api.env.host + host = select_any_master(ldap2) + if host: + return host + else: + return api.env.ca_host + + def __enter__(self): + """Log into the REST API""" + if self.cookie is not None: + return + status, status_text, resp_headers, resp_body = dogtag.https_request( + self.ca_host, self.env.ca_agent_port, '/ca/rest/account/login', + self.sec_dir, self.password, self.ipa_certificate_nickname, + method='GET' + ) + cookies = ipapython.cookie.Cookie.parse(resp_headers.get('set-cookie', '')) + if status != 200 or len(cookies) == 0: + raise errors.RemoteRetrieveError(reason=_('Failed to authenticate to CA REST API')) + self.cookie = str(cookies[0]) + return self + + def __exit__(self, exc_type, exc_value, traceback): + """Log out of the REST API""" + dogtag.https_request( + self.ca_host, self.env.ca_agent_port, '/ca/rest/account/logout', + self.sec_dir, self.password, self.ipa_certificate_nickname, + method='GET' + ) + self.cookie = None + + def _ssldo(self, method, path, headers=None, body=None): + """ + :param url: The URL to post to. + :param kw: Keyword arguments to encode into POST body. + :return: (http_status, http_reason_phrase, http_headers, http_body) + as (integer, unicode, dict, str) + + Perform an HTTPS request + """ + if self.cookie is None: + raise errors.RemoteRetrieveError( + reason=_("REST API is not logged in.")) + + headers = headers or {} + headers['Cookie'] = self.cookie + + resource = os.path.join('/ca/rest', self.path, path) + + # perform main request + status, status_text, resp_headers, resp_body = dogtag.https_request( + self.ca_host, self.env.ca_agent_port, resource, + self.sec_dir, self.password, self.ipa_certificate_nickname, + method=method, headers=headers, body=body + ) + if status < 200 or status >= 300: + explanation = self._parse_dogtag_error(resp_body) or '' + raise errors.RemoteRetrieveError( + reason=_('Non-2xx response from CA REST API: %(status)d %(status_text)s. %(explanation)s') + % {'status': status, 'status_text': status_text, 'explanation': explanation} + ) + return (status, status_text, resp_headers, resp_body) + + +class ra_certprofile(RestClient): + """ + Profile management backend plugin. + """ + path = 'profiles' + + def create_profile(self, profile_data): + """ + Import the profile into Dogtag + """ + self._ssldo('POST', 'raw', + headers={ + 'Content-type': 'application/xml', + 'Accept': 'application/json', + }, + body=profile_data + ) + + def enable_profile(self, profile_id): + """ + Enable the profile in Dogtag + """ + self._ssldo('POST', profile_id + '?action=enable') + + def disable_profile(self, profile_id): + """ + Enable the profile in Dogtag + """ + self._ssldo('POST', profile_id + '?action=disable') + + def delete_profile(self, profile_id): + """ + Delete the profile from Dogtag + """ + self._ssldo('DELETE', profile_id, headers={'Accept': 'application/json'}) + +api.register(ra_certprofile) -- 2.1.0 -------------- next part -------------- >From 3c9a29566e49b01f7017ef861daf1ca1967f59a7 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 11 May 2015 23:38:41 -0400 Subject: [PATCH 06/11] Enable LDAP-based profiles in CA on upgrade Part of: https://fedorahosted.org/freeipa/ticket/4560 --- install/tools/ipa-upgradeconfig | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/install/tools/ipa-upgradeconfig b/install/tools/ipa-upgradeconfig index 92c4934874f12c7017329bdcb67ac9a888f6e389..246118fd451fbf57754049258aeaa1895eb11e5e 100755 --- a/install/tools/ipa-upgradeconfig +++ b/install/tools/ipa-upgradeconfig @@ -340,6 +340,45 @@ def ca_configure_profiles_acl(ca): return True +def ca_enable_ldap_profile_subsystem(ca): + root_logger.info('[Ensuring CA is using LDAPProfileSubsystem]') + if not ca.is_configured(): + root_logger.info('CA is not configured') + return False + + caconfig = dogtag.configured_constants() + + needs_update = False + directive = None + try: + for i in range(15): + directive = "subsystem.{}.class".format(i) + value = installutils.get_directive( + caconfig.CS_CFG_PATH, + directive, + separator='=') + if value == 'ProfileSubsystem': + needs_update = True + break + except OSError, e: + root_logger.error('Cannot read CA configuration file "%s": %s', + caconfig.CS_CFG_PATH, e) + return False + + if needs_update: + installutils.set_directive( + caconfig.CS_CFG_PATH, + directive, + 'LDAPProfileSubsystem', + quotes=False, + separator='=') + + # TODO import file-based profiles into Dogtag + # More code needed on Dogtag side for this. + + return needs_update + + def upgrade_ipa_profile(ca, domain, fqdn): """ Update the IPA Profile provided by dogtag @@ -1439,6 +1478,7 @@ def main(): certificate_renewal_update(ca), ca_enable_pkix(ca), ca_configure_profiles_acl(ca), + ca_enable_ldap_profile_subsystem(ca), ]) if ca_restart: -- 2.1.0 -------------- next part -------------- >From 27ac261f1c67e150855ea1e94d5893138772364b Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 11 May 2015 21:17:48 -0400 Subject: [PATCH 07/11] Import included profiles during install or upgrade Add a default service profile template as part of FreeIPA and format and import it as part of installation or upgrade process. Also remove the code that modifies the old (file-based) `caIPAserviceCert' profile. Fixes https://fedorahosted.org/freeipa/ticket/4002 --- freeipa.spec.in | 2 + install/configure.ac | 1 + install/share/Makefile.am | 1 + install/share/profiles/DefaultService.cfg | 109 +++++++++++++++ install/share/profiles/Makefile.am | 14 ++ install/tools/ipa-server-install | 9 ++ install/tools/ipa-upgradeconfig | 49 ++++--- ipapython/dogtag.py | 5 + ipaserver/install/cainstance.py | 216 ++++-------------------------- ipaserver/plugins/dogtag.py | 14 +- 10 files changed, 201 insertions(+), 219 deletions(-) create mode 100644 install/share/profiles/DefaultService.cfg create mode 100644 install/share/profiles/Makefile.am diff --git a/freeipa.spec.in b/freeipa.spec.in index b14acee638d10d1e153e1f6765ab5902060cb169..6f5479240ba16a8a32ca2924437b4a2e7f37adc4 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -718,6 +718,8 @@ fi %dir %{_usr}/share/ipa/advise %dir %{_usr}/share/ipa/advise/legacy %{_usr}/share/ipa/advise/legacy/*.template +%dir %{_usr}/share/ipa/profiles +%{_usr}/share/ipa/profiles/*.cfg %dir %{_usr}/share/ipa/ffextension %{_usr}/share/ipa/ffextension/bootstrap.js %{_usr}/share/ipa/ffextension/install.rdf diff --git a/install/configure.ac b/install/configure.ac index 2e48aa5cc67b30f2582de987a12d4e7043256679..57f4219b66bbe1dadaed3e89c3e84b1c8240399e 100644 --- a/install/configure.ac +++ b/install/configure.ac @@ -88,6 +88,7 @@ AC_CONFIG_FILES([ share/Makefile share/advise/Makefile share/advise/legacy/Makefile + share/profiles/Makefile ui/Makefile ui/css/Makefile ui/src/Makefile diff --git a/install/share/Makefile.am b/install/share/Makefile.am index 2cae5279079cdd3e0d793667f4d1bf4e44757b9e..1ff2278ebf395057fccc4f0650b7726374cc1cc8 100644 --- a/install/share/Makefile.am +++ b/install/share/Makefile.am @@ -2,6 +2,7 @@ NULL = SUBDIRS = \ advise \ + profiles \ $(NULL) appdir = $(IPA_DATA_DIR) diff --git a/install/share/profiles/DefaultService.cfg b/install/share/profiles/DefaultService.cfg new file mode 100644 index 0000000000000000000000000000000000000000..d70fc9867d8af3f49dd6dfebcefdf772772bd100 --- /dev/null +++ b/install/share/profiles/DefaultService.cfg @@ -0,0 +1,109 @@ +profileId=DefaultService +classId=caEnrollImpl +desc=This certificate profile is for enrolling server certificates with IPA-RA agent authentication. +visible=false +enable=true +enableBy=admin +auth.instance_id=raCertAuth +name=IPA-RA Agent-Authenticated Server Certificate Enrollment +input.list=i1,i2 +input.i1.class_id=certReqInputImpl +input.i2.class_id=submitterInfoInputImpl +output.list=o1 +output.o1.class_id=certOutputImpl +policyset.list=serverCertSet +policyset.serverCertSet.list=1,2,3,4,5,6,7,8,9,10,11 +policyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl +policyset.serverCertSet.1.constraint.name=Subject Name Constraint +policyset.serverCertSet.1.constraint.params.pattern=CN=[^,]+,.+ +policyset.serverCertSet.1.constraint.params.accept=true +policyset.serverCertSet.1.default.class_id=subjectNameDefaultImpl +policyset.serverCertSet.1.default.name=Subject Name Default +policyset.serverCertSet.1.default.params.name=CN=$$request.req_subject_name.cn$$, $SUBJECT_DN_O +policyset.serverCertSet.2.constraint.class_id=validityConstraintImpl +policyset.serverCertSet.2.constraint.name=Validity Constraint +policyset.serverCertSet.2.constraint.params.range=740 +policyset.serverCertSet.2.constraint.params.notBeforeCheck=false +policyset.serverCertSet.2.constraint.params.notAfterCheck=false +policyset.serverCertSet.2.default.class_id=validityDefaultImpl +policyset.serverCertSet.2.default.name=Validity Default +policyset.serverCertSet.2.default.params.range=731 +policyset.serverCertSet.2.default.params.startTime=0 +policyset.serverCertSet.3.constraint.class_id=keyConstraintImpl +policyset.serverCertSet.3.constraint.name=Key Constraint +policyset.serverCertSet.3.constraint.params.keyType=RSA +policyset.serverCertSet.3.constraint.params.keyParameters=1024,2048,3072,4096 +policyset.serverCertSet.3.default.class_id=userKeyDefaultImpl +policyset.serverCertSet.3.default.name=Key Default +policyset.serverCertSet.4.constraint.class_id=noConstraintImpl +policyset.serverCertSet.4.constraint.name=No Constraint +policyset.serverCertSet.4.default.class_id=authorityKeyIdentifierExtDefaultImpl +policyset.serverCertSet.4.default.name=Authority Key Identifier Default +policyset.serverCertSet.5.constraint.class_id=noConstraintImpl +policyset.serverCertSet.5.constraint.name=No Constraint +policyset.serverCertSet.5.default.class_id=authInfoAccessExtDefaultImpl +policyset.serverCertSet.5.default.name=AIA Extension Default +policyset.serverCertSet.5.default.params.authInfoAccessADEnable_0=true +policyset.serverCertSet.5.default.params.authInfoAccessADLocationType_0=URIName +policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0=http://$IPA_CA_RECORD.$DOMAIN/ca/ocsp +policyset.serverCertSet.5.default.params.authInfoAccessADMethod_0=1.3.6.1.5.5.7.48.1 +policyset.serverCertSet.5.default.params.authInfoAccessCritical=false +policyset.serverCertSet.5.default.params.authInfoAccessNumADs=1 +policyset.serverCertSet.6.constraint.class_id=keyUsageExtConstraintImpl +policyset.serverCertSet.6.constraint.name=Key Usage Extension Constraint +policyset.serverCertSet.6.constraint.params.keyUsageCritical=true +policyset.serverCertSet.6.constraint.params.keyUsageDigitalSignature=true +policyset.serverCertSet.6.constraint.params.keyUsageNonRepudiation=true +policyset.serverCertSet.6.constraint.params.keyUsageDataEncipherment=true +policyset.serverCertSet.6.constraint.params.keyUsageKeyEncipherment=true +policyset.serverCertSet.6.constraint.params.keyUsageKeyAgreement=false +policyset.serverCertSet.6.constraint.params.keyUsageKeyCertSign=false +policyset.serverCertSet.6.constraint.params.keyUsageCrlSign=false +policyset.serverCertSet.6.constraint.params.keyUsageEncipherOnly=false +policyset.serverCertSet.6.constraint.params.keyUsageDecipherOnly=false +policyset.serverCertSet.6.default.class_id=keyUsageExtDefaultImpl +policyset.serverCertSet.6.default.name=Key Usage Default +policyset.serverCertSet.6.default.params.keyUsageCritical=true +policyset.serverCertSet.6.default.params.keyUsageDigitalSignature=true +policyset.serverCertSet.6.default.params.keyUsageNonRepudiation=true +policyset.serverCertSet.6.default.params.keyUsageDataEncipherment=true +policyset.serverCertSet.6.default.params.keyUsageKeyEncipherment=true +policyset.serverCertSet.6.default.params.keyUsageKeyAgreement=false +policyset.serverCertSet.6.default.params.keyUsageKeyCertSign=false +policyset.serverCertSet.6.default.params.keyUsageCrlSign=false +policyset.serverCertSet.6.default.params.keyUsageEncipherOnly=false +policyset.serverCertSet.6.default.params.keyUsageDecipherOnly=false +policyset.serverCertSet.7.constraint.class_id=noConstraintImpl +policyset.serverCertSet.7.constraint.name=No Constraint +policyset.serverCertSet.7.default.class_id=extendedKeyUsageExtDefaultImpl +policyset.serverCertSet.7.default.name=Extended Key Usage Extension Default +policyset.serverCertSet.7.default.params.exKeyUsageCritical=false +policyset.serverCertSet.7.default.params.exKeyUsageOIDs=1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 +policyset.serverCertSet.8.constraint.class_id=signingAlgConstraintImpl +policyset.serverCertSet.8.constraint.name=No Constraint +policyset.serverCertSet.8.constraint.params.signingAlgsAllowed=SHA1withRSA,SHA256withRSA,SHA512withRSA,MD5withRSA,MD2withRSA,SHA1withDSA,SHA1withEC,SHA256withEC,SHA384withEC,SHA512withEC +policyset.serverCertSet.8.default.class_id=signingAlgDefaultImpl +policyset.serverCertSet.8.default.name=Signing Alg +policyset.serverCertSet.8.default.params.signingAlg=- +policyset.serverCertSet.9.constraint.class_id=noConstraintImpl +policyset.serverCertSet.9.constraint.name=No Constraint +policyset.serverCertSet.9.default.class_id=crlDistributionPointsExtDefaultImpl +policyset.serverCertSet.9.default.name=CRL Distribution Points Extension Default +policyset.serverCertSet.9.default.params.crlDistPointsCritical=false +policyset.serverCertSet.9.default.params.crlDistPointsNum=1 +policyset.serverCertSet.9.default.params.crlDistPointsEnable_0=true +policyset.serverCertSet.9.default.params.crlDistPointsIssuerName_0=$CRL_ISSUER +policyset.serverCertSet.9.default.params.crlDistPointsIssuerType_0=DirectoryName +policyset.serverCertSet.9.default.params.crlDistPointsPointName_0=http://$IPA_CA_RECORD.$DOMAIN/ipa/crl/MasterCRL.bin +policyset.serverCertSet.9.default.params.crlDistPointsPointType_0=URIName +policyset.serverCertSet.9.default.params.crlDistPointsReasons_0= +policyset.serverCertSet.10.constraint.class_id=noConstraintImpl +policyset.serverCertSet.10.constraint.name=No Constraint +policyset.serverCertSet.10.default.class_id=subjectKeyIdentifierExtDefaultImpl +policyset.serverCertSet.10.default.name=Subject Key Identifier Extension Default +policyset.serverCertSet.10.default.params.critical=false +policyset.serverCertSet.11.constraint.class_id=noConstraintImpl +policyset.serverCertSet.11.constraint.name=No Constraint +policyset.serverCertSet.11.default.class_id=userExtensionDefaultImpl +policyset.serverCertSet.11.default.name=User Supplied Extension Default +policyset.serverCertSet.11.default.params.userExtOID=2.5.29.17 diff --git a/install/share/profiles/Makefile.am b/install/share/profiles/Makefile.am new file mode 100644 index 0000000000000000000000000000000000000000..8c6b3114a346b3d96d94e75ad330c5f0bbaf7322 --- /dev/null +++ b/install/share/profiles/Makefile.am @@ -0,0 +1,14 @@ +NULL = + +appdir = $(IPA_DATA_DIR)/profiles +app_DATA = \ + DefaultService.cfg \ + $(NULL) + +EXTRA_DIST = \ + $(app_DATA) \ + $(NULL) + +MAINTAINERCLEANFILES = \ + *~ \ + Makefile.in diff --git a/install/tools/ipa-server-install b/install/tools/ipa-server-install index cb6e1abe2016c0f8cefc35b1d685373f05b3ef89..7a7743e17c0f3ad9215dfc9d985d0ff021e57277 100755 --- a/install/tools/ipa-server-install +++ b/install/tools/ipa-server-install @@ -1124,6 +1124,9 @@ def main(): api.env.ca_host = host_name api.bootstrap(**cfg) + if setup_ca: + # ensure profile backend is available + import ipaserver.plugins.dogtag api.finalize() # Create DS user/group if it doesn't exist yet @@ -1273,6 +1276,12 @@ def main(): service.print_msg("Restarting the certificate server") ca.restart(dogtag.configured_constants().PKI_INSTANCE_NAME) + service.print_msg("Importing certificate profiles") + api.Backend.ra_certprofile._read_password() + if not api.Backend.ldap2.isconnected(): + api.Backend.ldap2.connect(autobind=True) + ca.import_included_profiles() + if options.setup_dns: api.Backend.ldap2.connect(autobind=True) dns_installer.install(False, False, options) diff --git a/install/tools/ipa-upgradeconfig b/install/tools/ipa-upgradeconfig index 246118fd451fbf57754049258aeaa1895eb11e5e..24cdf466ceff3885b779b7de88681c087792c99e 100755 --- a/install/tools/ipa-upgradeconfig +++ b/install/tools/ipa-upgradeconfig @@ -379,32 +379,34 @@ def ca_enable_ldap_profile_subsystem(ca): return needs_update -def upgrade_ipa_profile(ca, domain, fqdn): +def ca_import_included_profiles(ca): + root_logger.info('[Ensuring presence of included profiles]') + + if not ca.is_configured(): + root_logger.info('CA is not configured') + return False + + if not api.Backend.ldap2.isconnected(): + try: + api.Backend.ldap2.connect(autobind=True) + except ipalib.errors.PublicError, e: + root_logger.error("Cannot connect to LDAP: %s", e) + return + ca.import_included_profiles() + + +def upgrade_ca_audit_cert_validity(ca): """ - Update the IPA Profile provided by dogtag + Update the Dogtag audit signing certificate. Returns True if restart is needed, False otherwise. """ - root_logger.info('[Verifying that CA service certificate profile is updated]') + root_logger.info('[Verifying that CA audit signing cert has 2 year validity]') if ca.is_configured(): - ski = ca.enable_subject_key_identifier() - if ski: - root_logger.debug('Subject Key Identifier updated.') - else: - root_logger.debug('Subject Key Identifier already set.') - san = ca.enable_subject_alternative_name() - if san: - root_logger.debug('Subject Alternative Name updated.') - else: - root_logger.debug('Subject Alternative Name already set.') - audit = ca.set_audit_renewal() - uri = ca.set_crl_ocsp_extensions(domain, fqdn) - if audit or ski or san or uri: - return True + return ca.set_audit_renewal() else: root_logger.info('CA is not configured') - - return False + return False def named_remove_deprecated_options(): @@ -1327,6 +1329,7 @@ def main(): fstore = sysrestore.FileStore(paths.SYSRESTORE) api.bootstrap(context='restart', in_server=True) + import ipaserver.plugins.dogtag # ensure profile backend gets loaded api.finalize() fqdn = find_hostname() @@ -1474,7 +1477,7 @@ def main(): ca_restart = any([ ca_restart, - upgrade_ipa_profile(ca, api.env.domain, fqdn), + upgrade_ca_audit_cert_validity(ca), certificate_renewal_update(ca), ca_enable_pkix(ca), ca_configure_profiles_acl(ca), @@ -1488,6 +1491,12 @@ def main(): except ipautil.CalledProcessError, e: root_logger.error("Failed to restart %s: %s", ca.service_name, e) + # This step MUST be done after ca_enable_ldap_profile_subsystem and + # ca_configure_profiles_acl, and the consequent restart, but does not + # itself require a restart. + # + ca_import_included_profiles(ca) + set_sssd_domain_option('ipa_server_mode', 'True') if __name__ == '__main__': diff --git a/ipapython/dogtag.py b/ipapython/dogtag.py index 11311cf7b55d7b84e9434a698dbfd60b0eb142a1..e0091ba8747dff3a488b9908f057ae15c6b4bedc 100644 --- a/ipapython/dogtag.py +++ b/ipapython/dogtag.py @@ -42,6 +42,11 @@ from ipapython.ipa_log_manager import * # the configured version. +INCLUDED_PROFILES = { + # ( profile_id , description , store_issued) + (u'DefaultService', u'Standard profile for network services', True), + } + class Dogtag10Constants(object): DOGTAG_VERSION = 10 UNSECURE_PORT = 8080 diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index d85210e02a6b4a5e664d57965299d775836ae5c5..7fc1572604a09cc1c6bc28f7a068b5b2d49a6a12 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -459,10 +459,6 @@ class CAInstance(DogtagInstance): self.step("importing CA chain to RA certificate database", self.__import_ca_chain) self.step("fixing RA database permissions", self.fix_ra_perms) self.step("setting up signing cert profile", self.__setup_sign_profile) - self.step("set certificate subject base", self.__set_subject_in_config) - self.step("enabling Subject Key Identifier", self.enable_subject_key_identifier) - self.step("enabling Subject Alternative Name", self.enable_subject_alternative_name) - self.step("enabling CRL and OCSP extensions for certificates", self.__set_crl_ocsp_extensions) self.step("setting audit signing renewal to 2 years", self.set_audit_renewal) if not self.clone: self.step("restarting certificate server", self.restart_instance) @@ -1125,94 +1121,6 @@ class CAInstance(DogtagInstance): return publishdir - def __set_crl_ocsp_extensions(self): - self.set_crl_ocsp_extensions(self.domain, self.fqdn) - - def set_crl_ocsp_extensions(self, domain, fqdn): - """ - Configure CRL and OCSP extensions in default IPA certificate profile - if not done already. - """ - changed = False - - # OCSP extension - ocsp_url = 'http://%s.%s/ca/ocsp' % (IPA_CA_RECORD, ipautil.format_netloc(domain)) - - ocsp_location_0 = installutils.get_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0', - separator='=') - - if ocsp_location_0 != ocsp_url: - # Set the first OCSP URI - installutils.set_directive(self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0', - ocsp_url, quotes=False, separator='=') - changed = True - - ocsp_profile_count = installutils.get_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.5.default.params.authInfoAccessNumADs', - separator='=') - - if ocsp_profile_count != '1': - installutils.set_directive(self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.5.default.params.authInfoAccessNumADs', - '1', quotes=False, separator='=') - changed = True - - - # CRL extension - crl_url = 'http://%s.%s/ipa/crl/MasterCRL.bin'% (IPA_CA_RECORD, ipautil.format_netloc(domain)) - - crl_point_0 = installutils.get_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.9.default.params.crlDistPointsPointName_0', - separator='=') - - if crl_point_0 != crl_url: - installutils.set_directive(self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.9.default.params.crlDistPointsIssuerName_0', - 'CN=Certificate Authority,o=ipaca', quotes=False, separator='=') - installutils.set_directive(self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.9.default.params.crlDistPointsIssuerType_0', - 'DirectoryName', quotes=False, separator='=') - installutils.set_directive(self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.9.default.params.crlDistPointsPointName_0', - crl_url, quotes=False, separator='=') - changed = True - - crl_profile_count = installutils.get_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.9.default.params.crlDistPointsNum', - separator='=') - - if crl_profile_count != '1': - installutils.set_directive(self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.9.default.params.crlDistPointsNum', - '1', quotes=False, separator='=') - changed = True - - # CRL extension is not enabled by default - setlist = installutils.get_directive(self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.list', separator='=') - new_set_list = None - - if setlist == '1,2,3,4,5,6,7,8': - new_set_list = '1,2,3,4,5,6,7,8,9' - elif setlist == '1,2,3,4,5,6,7,8,10': - new_set_list = '1,2,3,4,5,6,7,8,9,10' - elif setlist == '1,2,3,4,5,6,7,8,10,11': - new_set_list = '1,2,3,4,5,6,7,8,9,10,11' - - if new_set_list: - installutils.set_directive(self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.list', - new_set_list, quotes=False, separator='=') - changed = True - - return changed - def __enable_crl_publish(self): """ @@ -1267,13 +1175,6 @@ class CAInstance(DogtagInstance): installutils.set_directive(caconfig, 'ca.crl.MasterCRL.enableCRLUpdates', 'false', quotes=False, separator='=') installutils.set_directive(caconfig, 'ca.listenToCloneModifications', 'false', quotes=False, separator='=') - def __set_subject_in_config(self): - # dogtag ships with an IPA-specific profile that forces a subject - # format. We need to update that template with our base subject - if installutils.update_file(self.dogtag_constants.IPA_SERVICE_PROFILE, - 'OU=pki-ipa, O=IPA', str(self.subject_base)): - print "Updating subject_base in CA template failed" - def uninstall(self): # just eat state self.restore_state("enabled") @@ -1407,100 +1308,6 @@ class CAInstance(DogtagInstance): services.knownservices.certmonger.stop() - def enable_subject_key_identifier(self): - """ - See if Subject Key Identifier is set in the profile and if not, add it. - """ - setlist = installutils.get_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.list', separator='=') - - # this is the default setting from pki-ca/pki-tomcat. Don't touch it - # if a user has manually modified it. - if setlist == '1,2,3,4,5,6,7,8' or setlist == '1,2,3,4,5,6,7,8,9': - setlist += ',10' - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.list', - setlist, - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.10.constraint.class_id', - 'noConstraintImpl', - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.10.constraint.name', - 'No Constraint', - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.10.default.class_id', - 'subjectKeyIdentifierExtDefaultImpl', - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.10.default.name', - 'Subject Key Identifier Extension Default', - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.10.default.params.critical', - 'false', - quotes=False, separator='=') - return True - - # No update was done - return False - - def enable_subject_alternative_name(self): - """ - See if Subject Alternative Name is set in the profile and if not, add - it. - """ - setlist = installutils.get_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.list', separator='=') - - # this is the default setting from pki-ca/pki-tomcat. Don't touch it - # if a user has manually modified it. - if setlist == '1,2,3,4,5,6,7,8,10' or setlist == '1,2,3,4,5,6,7,8,9,10': - setlist += ',11' - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.list', - setlist, - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.11.constraint.class_id', - 'noConstraintImpl', - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.11.constraint.name', - 'No Constraint', - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.11.default.class_id', - 'userExtensionDefaultImpl', - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.11.default.name', - 'User Supplied Extension Default', - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.11.default.params.userExtOID', - '2.5.29.17', - quotes=False, separator='=') - return True - - # No update was done - return False def set_audit_renewal(self): """ @@ -1586,6 +1393,29 @@ class CAInstance(DogtagInstance): master_entry['ipaConfigString'].append('caRenewalMaster') self.admin_conn.update_entry(master_entry) + def import_included_profiles(self): + sub_dict = dict( + DOMAIN=ipautil.format_netloc(api.env.domain), + IPA_CA_RECORD=IPA_CA_RECORD, + CRL_ISSUER='CN=Certificate Authority,o=ipaca', + SUBJECT_DN_O=str(DN(('O', api.env.realm))), + ) + + for (profile_id, desc, store_issued) in dogtag.INCLUDED_PROFILES: + try: + show_ret = api.Command['certprofile_show'](profile_id) + continue # the profile is present + except errors.NotFound: + # profile not found; add it + profile_data = ipautil.template_file( + '/usr/share/ipa/profiles/{}.cfg'.format(profile_id), sub_dict) + api.Command['certprofile_import']( + profile_id, + file=profile_data.decode('utf-8'), + description=desc, + ipacertprofilestoreissued=store_issued, + ) + root_logger.info("Imported profile '%s'", profile_id) @staticmethod def update_cert_config(nickname, cert, dogtag_constants=None): diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py index 9654123b16d8e417398d49bf1305fd41880bc3a7..880b319d68728a40f4479626d5a7c2b8c56ced02 100644 --- a/ipaserver/plugins/dogtag.py +++ b/ipaserver/plugins/dogtag.py @@ -1966,17 +1966,19 @@ class RestClient(Backend): self.ipa_key_size = "2048" self.ipa_certificate_nickname = "ipaCert" self.ca_certificate_nickname = "caCert" - try: - f = open(self.pwd_file, "r") - self.password = f.readline().strip() - f.close() - except IOError: - self.password = '' + self._read_password() super(RestClient, self).__init__() # session cookie self.cookie = None + def _read_password(self): + try: + with open(self.pwd_file) as f: + self.password = f.readline().strip() + except IOError: + self.password = '' + @cachedproperty def ca_host(self): """ -- 2.1.0 -------------- next part -------------- >From 28e8d503b7d5f13a40ca177f15a69696042a996f Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Thu, 7 May 2015 21:26:24 -0400 Subject: [PATCH 08/11] Add generic split_any_principal method There exist methods to split user or service/host principals, but there is no method to split any kind of principal and allow the caller to decide what to do. Generalize ``ipalib.plugins.service.split_principal`` to return a service of ``None`` if the principal is a user principal, rename it ``split_any_principal`` and reimplement ``split_principal`` to preserve existing behaviour. Part of: https://fedorahosted.org/freeipa/ticket/4938 --- ipalib/plugins/service.py | 27 +++++++++++++++++++-------- 1 file changed, 19 insertions(+), 8 deletions(-) diff --git a/ipalib/plugins/service.py b/ipalib/plugins/service.py index b37dc7b4bf56b69df204fd29e9487f1390197bbe..5af320286bab98535e1f7118840afc4d525be401 100644 --- a/ipalib/plugins/service.py +++ b/ipalib/plugins/service.py @@ -185,19 +185,24 @@ _ticket_flags_map = { _ticket_flags_default = _ticket_flags_map['ipakrbrequirespreauth'] -def split_principal(principal): +def split_any_principal(principal): service = hostname = realm = None # Break down the principal into its component parts, which may or # may not include the realm. sp = principal.split('/') - if len(sp) != 2: - raise errors.MalformedServicePrincipal(reason=_('missing service')) + name_and_realm = None + if len(sp) > 2: + raise errors.MalformedServicePrincipal(reason=_('unable to determine service')) + elif len(sp) == 2: + service = sp[0] + if len(service) == 0: + raise errors.MalformedServicePrincipal(reason=_('blank service')) + name_and_realm = sp[1] + else: + name_and_realm = sp[0] - service = sp[0] - if len(service) == 0: - raise errors.MalformedServicePrincipal(reason=_('blank service')) - sr = sp[1].split('@') + sr = name_and_realm.split('@') if len(sr) > 2: raise errors.MalformedServicePrincipal( reason=_('unable to determine realm')) @@ -212,7 +217,13 @@ def split_principal(principal): realm = api.env.realm # Note that realm may be None. - return (service, hostname, realm) + return service, hostname, realm + +def split_principal(principal): + service, name, realm = split_any_principal(principal) + if service is None: + raise errors.MalformedServicePrincipal(reason=_('missing service')) + return service, name, realm def validate_principal(ugettext, principal): (service, hostname, principal) = split_principal(principal) -- 2.1.0 -------------- next part -------------- >From 8c3267f2d1026835ace648c0a66566ed1a5dda06 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Fri, 8 May 2015 02:23:24 -0400 Subject: [PATCH 09/11] Add profile_id parameter to 'request_certificate' Add the profile_id parameter to the 'request_certificate' function and update call sites. Also remove multiple occurrences of the default profile ID 'caIPAserviceCert'. Part of: https://fedorahosted.org/freeipa/ticket/57 --- API.txt | 3 ++- checks/check-ra.py | 2 +- ipalib/plugins/cert.py | 2 +- ipapython/dogtag.py | 6 ++++-- ipaserver/install/certs.py | 2 +- ipaserver/plugins/dogtag.py | 7 +++++-- ipaserver/plugins/rabase.py | 3 ++- 7 files changed, 16 insertions(+), 9 deletions(-) diff --git a/API.txt b/API.txt index 55d2baccaaf7a6cd891aa872935c01c76781c273..93ef2cdae533ad5564685bb21c8857a807dc8e08 100644 --- a/API.txt +++ b/API.txt @@ -485,10 +485,11 @@ arg: Str('serial_number') option: Str('version?', exclude='webui') output: Output('result', None, None) command: cert_request -args: 1,4,1 +args: 1,5,1 arg: File('csr', cli_name='csr_file') option: Flag('add', autofill=True, default=False) option: Str('principal') +option: Str('profile_id') option: Str('request_type', autofill=True, default=u'pkcs10') option: Str('version?', exclude='webui') output: Output('result', , None) diff --git a/checks/check-ra.py b/checks/check-ra.py index a1df50ba4a4ad7fc0b6d2118e40977b1da6edf65..28929545ab7f0a63e47a3829c53cf08d784c9524 100755 --- a/checks/check-ra.py +++ b/checks/check-ra.py @@ -90,7 +90,7 @@ def assert_equal(trial, reference): api.log.info('******** Testing ra.request_certificate() ********') -request_result = ra.request_certificate(csr) +request_result = ra.request_certificate(csr, ra.DEFAULT_PROFILE) if verbose: print "request_result=\n%s" % request_result assert_equal(request_result, {'subject' : subject, diff --git a/ipalib/plugins/cert.py b/ipalib/plugins/cert.py index 7e2c77622b3627e9e57bbcb69291f723ecf509bf..e4cb6dc0aa8b89368806b08674aae277b3653e8f 100644 --- a/ipalib/plugins/cert.py +++ b/ipalib/plugins/cert.py @@ -436,7 +436,7 @@ class cert_request(VirtualCommand): # Request the certificate result = self.Backend.ra.request_certificate( - csr, request_type=request_type) + csr, 'caIPAserviceCert', request_type=request_type) cert = x509.load_certificate(result['certificate']) result['issuer'] = unicode(cert.issuer) result['valid_not_before'] = unicode(cert.valid_not_before_str) diff --git a/ipapython/dogtag.py b/ipapython/dogtag.py index e0091ba8747dff3a488b9908f057ae15c6b4bedc..6476d7e5813967cb1b812dc8a01eb3a0fae96d4e 100644 --- a/ipapython/dogtag.py +++ b/ipapython/dogtag.py @@ -47,6 +47,8 @@ INCLUDED_PROFILES = { (u'DefaultService', u'Standard profile for network services', True), } +DEFAULT_PROFILE = 'caIPAserviceCert' + class Dogtag10Constants(object): DOGTAG_VERSION = 10 UNSECURE_PORT = 8080 @@ -76,7 +78,7 @@ class Dogtag10Constants(object): RACERT_LINE_SEP = '\n' - IPA_SERVICE_PROFILE = '%s/caIPAserviceCert.cfg' % SERVICE_PROFILE_DIR + IPA_SERVICE_PROFILE = '%s/%s.cfg' % (SERVICE_PROFILE_DIR, DEFAULT_PROFILE) SIGN_PROFILE = '%s/caJarSigningCert.cfg' % SERVICE_PROFILE_DIR SHARED_DB = True DS_USER = "dirsrv" @@ -115,7 +117,7 @@ class Dogtag9Constants(object): EE_CLIENT_AUTH_PORT = 9446 TOMCAT_SERVER_PORT = 9701 - IPA_SERVICE_PROFILE = '%s/caIPAserviceCert.cfg' % SERVICE_PROFILE_DIR + IPA_SERVICE_PROFILE = '%s/%s.cfg' % (SERVICE_PROFILE_DIR, DEFAULT_PROFILE) SIGN_PROFILE = '%s/caJarSigningCert.cfg' % SERVICE_PROFILE_DIR SHARED_DB = False DS_USER = "pkisrv" diff --git a/ipaserver/install/certs.py b/ipaserver/install/certs.py index bc7dccf805386e9fa84b58d2ff9346085e1b93b1..564332e6fde0698a23884922c5018fab59da7e4d 100644 --- a/ipaserver/install/certs.py +++ b/ipaserver/install/certs.py @@ -386,7 +386,7 @@ class CertDB(object): # We just want the CSR bits, make sure there is nothing else csr = pkcs10.strip_header(csr) - params = {'profileId': 'caIPAserviceCert', + params = {'profileId': dogtag.DEFAULT_PROFILE, 'cert_request_type': 'pkcs10', 'requestor_name': 'IPA Installer', 'cert_request': csr, diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py index 880b319d68728a40f4479626d5a7c2b8c56ced02..e6668bb43b994863a14fdd347635753422ed9388 100644 --- a/ipaserver/plugins/dogtag.py +++ b/ipaserver/plugins/dogtag.py @@ -1284,6 +1284,8 @@ class ra(rabase.rabase): """ Request Authority backend plugin. """ + DEFAULT_PROFILE = dogtag.DEFAULT_PROFILE + def __init__(self): if api.env.in_tree: self.sec_dir = api.env.dot_ipa + os.sep + 'alias' @@ -1541,9 +1543,10 @@ class ra(rabase.rabase): return cmd_result - def request_certificate(self, csr, request_type='pkcs10'): + def request_certificate(self, csr, profile_id, request_type='pkcs10'): """ :param csr: The certificate signing request. + :param profile_id: The profile to use for the request. :param request_type: The request type (defaults to ``'pkcs10'``). Submit certificate signing request. @@ -1575,7 +1578,7 @@ class ra(rabase.rabase): http_status, http_reason_phrase, http_headers, http_body = \ self._sslget('/ca/eeca/ca/profileSubmitSSLClient', self.env.ca_ee_port, - profileId='caIPAserviceCert', + profileId=profile_id, cert_request_type=request_type, cert_request=csr, xml='true') diff --git a/ipaserver/plugins/rabase.py b/ipaserver/plugins/rabase.py index e14969970ef5b402d06b766f895200c6eb4fc76f..cf4426235b02866a3f565c51c52c44aabbdc1153 100644 --- a/ipaserver/plugins/rabase.py +++ b/ipaserver/plugins/rabase.py @@ -67,11 +67,12 @@ class rabase(Backend): """ raise errors.NotImplementedError(name='%s.get_certificate' % self.name) - def request_certificate(self, csr, request_type='pkcs10'): + def request_certificate(self, csr, profile_id, request_type='pkcs10'): """ Submit certificate signing request. :param csr: The certificate signing request. + :param profile_id: Profile to use for this request. :param request_type: The request type (defaults to ``'pkcs10'``). """ raise errors.NotImplementedError(name='%s.request_certificate' % self.name) -- 2.1.0 -------------- next part -------------- >From 9bf0edfbb1e5458e92c76309c58fade50b9fc0d0 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 18 May 2015 22:11:52 -0400 Subject: [PATCH 10/11] Add usercertificate attribute to user plugin --- ACI.txt | 2 +- API.txt | 18 ++++++++++++------ install/share/default-aci.ldif | 1 + install/updates/20-aci.update | 4 ++++ ipalib/plugins/baseuser.py | 10 ++++++++-- ipalib/plugins/user.py | 4 ++-- 6 files changed, 28 insertions(+), 11 deletions(-) diff --git a/ACI.txt b/ACI.txt index 870a343f0e59fa2075b53e881c224d4965984d08..279d15d6dcf2a465a07ec27a67b15bf452da6c81 100644 --- a/ACI.txt +++ b/ACI.txt @@ -281,7 +281,7 @@ aci: (targetattr = "krbprincipalkey || passwordhistory || sambalmpassword || sam dn: cn=users,cn=accounts,dc=ipa,dc=example aci: (targetattr = "ipasshpubkey")(targetfilter = "(objectclass=posixaccount)")(version 3.0;acl "permission:System: Manage User SSH Public Keys";allow (write) groupdn = "ldap:///cn=System: Manage User SSH Public Keys,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: cn=users,cn=accounts,dc=ipa,dc=example -aci: (targetattr = "businesscategory || carlicense || cn || description || displayname || employeetype || facsimiletelephonenumber || gecos || givenname || homephone || inetuserhttpurl || initials || l || labeleduri || loginshell || manager || mepmanagedentry || mobile || objectclass || ou || pager || postalcode || preferredlanguage || roomnumber || secretary || seealso || sn || st || street || telephonenumber || title || userclass")(targetfilter = "(objectclass=posixaccount)")(version 3.0;acl "permission:System: Modify Users";allow (write) groupdn = "ldap:///cn=System: Modify Users,cn=permissions,cn=pbac,dc=ipa,dc=example";) +aci: (targetattr = "businesscategory || carlicense || cn || description || displayname || employeetype || facsimiletelephonenumber || gecos || givenname || homephone || inetuserhttpurl || initials || l || labeleduri || loginshell || manager || mepmanagedentry || mobile || objectclass || ou || pager || postalcode || preferredlanguage || roomnumber || secretary || seealso || sn || st || street || telephonenumber || title || usercertificate || userclass")(targetfilter = "(objectclass=posixaccount)")(version 3.0;acl "permission:System: Modify Users";allow (write) groupdn = "ldap:///cn=System: Modify Users,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: cn=UPG Definition,cn=Definitions,cn=Managed Entries,cn=etc,dc=ipa,dc=example aci: (targetattr = "*")(target = "ldap:///cn=UPG Definition,cn=Definitions,cn=Managed Entries,cn=etc,dc=ipa,dc=example")(version 3.0;acl "permission:System: Read UPG Definition";allow (compare,read,search) groupdn = "ldap:///cn=System: Read UPG Definition,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: cn=users,cn=accounts,dc=ipa,dc=example diff --git a/API.txt b/API.txt index 93ef2cdae533ad5564685bb21c8857a807dc8e08..a1ff2afbd1d29087c4295bf9b58b596f73279c27 100644 --- a/API.txt +++ b/API.txt @@ -3772,7 +3772,7 @@ output: Entry('result', , Gettext('A dictionary representing an LDA output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: stageuser_add -args: 1,43,3 +args: 1,44,3 arg: Str('uid', attribute=True, cli_name='login', 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') @@ -3814,6 +3814,7 @@ option: Str('street', attribute=True, cli_name='street', multivalue=False, requi option: Str('telephonenumber', attribute=True, cli_name='phone', multivalue=True, required=False) option: Str('title', attribute=True, cli_name='title', multivalue=False, required=False) option: Int('uidnumber', attribute=True, cli_name='uid', minvalue=1, multivalue=False, required=False) +option: Bytes('usercertificate', attribute=True, cli_name='certificate', multivalue=False, required=False) option: Str('userclass', attribute=True, cli_name='class', multivalue=True, required=False) option: Password('userpassword', attribute=True, cli_name='password', exclude='webui', multivalue=False, required=False) option: Str('version?', exclude='webui') @@ -3829,7 +3830,7 @@ output: Output('result', , None) output: Output('summary', (, ), None) output: ListOfPrimaryKeys('value', None, None) command: stageuser_find -args: 1,52,4 +args: 1,53,4 arg: Str('criteria?', noextrawhitespace=False) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('carlicense', attribute=True, autofill=False, cli_name='carlicense', multivalue=True, query=True, required=False) @@ -3880,6 +3881,7 @@ option: Int('timelimit?', autofill=False, minvalue=0) option: Str('title', attribute=True, autofill=False, cli_name='title', multivalue=False, query=True, required=False) option: Str('uid', attribute=True, autofill=False, cli_name='login', 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: Int('uidnumber', attribute=True, autofill=False, cli_name='uid', minvalue=1, multivalue=False, query=True, required=False) +option: Bytes('usercertificate', attribute=True, autofill=False, cli_name='certificate', multivalue=False, query=True, required=False) option: Str('userclass', attribute=True, autofill=False, cli_name='class', multivalue=True, query=True, required=False) option: Password('userpassword', attribute=True, autofill=False, cli_name='password', exclude='webui', multivalue=False, query=True, required=False) option: Str('version?', exclude='webui') @@ -3888,7 +3890,7 @@ output: ListOfEntries('result', (, ), Gettext('A list output: Output('summary', (, ), None) output: Output('truncated', , None) command: stageuser_mod -args: 1,44,3 +args: 1,45,3 arg: Str('uid', attribute=True, cli_name='login', 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: Str('addattr*', cli_name='addattr', exclude='webui') option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') @@ -3931,6 +3933,7 @@ option: Str('street', attribute=True, autofill=False, cli_name='street', multiva option: Str('telephonenumber', attribute=True, autofill=False, cli_name='phone', multivalue=True, required=False) option: Str('title', attribute=True, autofill=False, cli_name='title', multivalue=False, required=False) option: Int('uidnumber', attribute=True, autofill=False, cli_name='uid', minvalue=1, multivalue=False, required=False) +option: Bytes('usercertificate', attribute=True, autofill=False, cli_name='certificate', multivalue=False, required=False) option: Str('userclass', attribute=True, autofill=False, cli_name='class', multivalue=True, required=False) option: Password('userpassword', attribute=True, autofill=False, cli_name='password', exclude='webui', multivalue=False, required=False) option: Str('version?', exclude='webui') @@ -4558,7 +4561,7 @@ output: Entry('result', , Gettext('A dictionary representing an LDA output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: user_add -args: 1,44,3 +args: 1,45,3 arg: Str('uid', attribute=True, cli_name='login', 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') @@ -4601,6 +4604,7 @@ option: Str('street', attribute=True, cli_name='street', multivalue=False, requi option: Str('telephonenumber', attribute=True, cli_name='phone', multivalue=True, required=False) option: Str('title', attribute=True, cli_name='title', multivalue=False, required=False) option: Int('uidnumber', attribute=True, cli_name='uid', minvalue=1, multivalue=False, required=False) +option: Bytes('usercertificate', attribute=True, cli_name='certificate', multivalue=False, required=False) option: Str('userclass', attribute=True, cli_name='class', multivalue=True, required=False) option: Password('userpassword', attribute=True, cli_name='password', exclude='webui', multivalue=False, required=False) option: Str('version?', exclude='webui') @@ -4632,7 +4636,7 @@ output: Output('result', , None) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: user_find -args: 1,55,4 +args: 1,56,4 arg: Str('criteria?', noextrawhitespace=False) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('carlicense', attribute=True, autofill=False, cli_name='carlicense', multivalue=True, query=True, required=False) @@ -4685,6 +4689,7 @@ option: Int('timelimit?', autofill=False, minvalue=0) option: Str('title', attribute=True, autofill=False, cli_name='title', multivalue=False, query=True, required=False) option: Str('uid', attribute=True, autofill=False, cli_name='login', 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: Int('uidnumber', attribute=True, autofill=False, cli_name='uid', minvalue=1, multivalue=False, query=True, required=False) +option: Bytes('usercertificate', attribute=True, autofill=False, cli_name='certificate', multivalue=False, query=True, required=False) option: Str('userclass', attribute=True, autofill=False, cli_name='class', multivalue=True, query=True, required=False) option: Password('userpassword', attribute=True, autofill=False, cli_name='password', exclude='webui', multivalue=False, query=True, required=False) option: Str('version?', exclude='webui') @@ -4694,7 +4699,7 @@ output: ListOfEntries('result', (, ), Gettext('A list output: Output('summary', (, ), None) output: Output('truncated', , None) command: user_mod -args: 1,45,3 +args: 1,46,3 arg: Str('uid', attribute=True, cli_name='login', 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: Str('addattr*', cli_name='addattr', exclude='webui') option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') @@ -4738,6 +4743,7 @@ option: Str('street', attribute=True, autofill=False, cli_name='street', multiva option: Str('telephonenumber', attribute=True, autofill=False, cli_name='phone', multivalue=True, required=False) option: Str('title', attribute=True, autofill=False, cli_name='title', multivalue=False, required=False) option: Int('uidnumber', attribute=True, autofill=False, cli_name='uid', minvalue=1, multivalue=False, required=False) +option: Bytes('usercertificate', attribute=True, autofill=False, cli_name='certificate', multivalue=False, required=False) option: Str('userclass', attribute=True, autofill=False, cli_name='class', multivalue=True, required=False) option: Password('userpassword', attribute=True, autofill=False, cli_name='password', exclude='webui', multivalue=False, required=False) option: Str('version?', exclude='webui') diff --git a/install/share/default-aci.ldif b/install/share/default-aci.ldif index af7eedb0b92375f893a61ad1fb6e2d7b176389f9..7b174e774aae3ea012a431fe4a2535fb4230e402 100644 --- a/install/share/default-aci.ldif +++ b/install/share/default-aci.ldif @@ -10,6 +10,7 @@ changetype: modify add: aci aci: (targetattr = "givenname || sn || cn || displayname || title || initials || loginshell || gecos || homephone || mobile || pager || facsimiletelephonenumber || telephonenumber || street || roomnumber || l || st || postalcode || manager || secretary || description || carlicense || labeleduri || inetuserhttpurl || seealso || employeetype || businesscategory || ou")(version 3.0;acl "selfservice:User Self service";allow (write) userdn = "ldap:///self";) aci: (targetattr = "ipasshpubkey")(version 3.0;acl "selfservice:Users can manage their own SSH public keys";allow (write) userdn = "ldap:///self";) +aci: (targetattr = "usercertificate")(version 3.0;acl "selfservice:Users can manage their own X.509 certificates";allow (write) userdn = "ldap:///self";) dn: cn=etc,$SUFFIX changetype: modify diff --git a/install/updates/20-aci.update b/install/updates/20-aci.update index fde3afeee59e4d4dc0bd6a9c0eb24ab255c4e637..8964876b0f07c664e4855baa3971a2c774073f09 100644 --- a/install/updates/20-aci.update +++ b/install/updates/20-aci.update @@ -79,3 +79,7 @@ add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; acl "Group add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; acl "Entities are allowed to rekey themselves"; allow(write) userdn="ldap:///self";) add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; acl "Admins are allowed to rekey any entity"; allow(write) groupdn = "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";) add:aci: (targetfilter="(|(objectclass=ipaHost)(objectclass=ipaService))")(targetattr="ipaProtectedOperation;write_keys")(version 3.0; acl "Entities are allowed to rekey managed entries"; allow(write) userattr="managedby#USERDN";) + +# User certificates +dn: $SUFFIX +add:aci:(targetattr = "ipasshpubkey")(version 3.0;acl "selfservice:Users can manage their own X.509 certificates";allow (write) userdn = "ldap:///self";) diff --git a/ipalib/plugins/baseuser.py b/ipalib/plugins/baseuser.py index a1be29d83550a0412ed37cfde47ac74c6ca478fd..5004cbc12f0eaecfffa0d14e8367a5c5ca4a70fd 100644 --- a/ipalib/plugins/baseuser.py +++ b/ipalib/plugins/baseuser.py @@ -23,10 +23,11 @@ import posixpath import os from ipalib import api, errors -from ipalib import Flag, Int, Password, Str, Bool, StrEnum, DateTime +from ipalib import Flag, Int, Password, Str, Bool, StrEnum, DateTime, Bytes from ipalib.plugable import Registry from ipalib.plugins.baseldap import DN, LDAPObject, \ LDAPCreate, LDAPUpdate, LDAPSearch, LDAPDelete, LDAPRetrieve +from ipalib.plugins.service import validate_certificate from ipalib.plugins import baseldap from ipalib.request import context from ipalib import _, ngettext @@ -188,7 +189,7 @@ class baseuser(LDAPObject): 'telephonenumber', 'title', 'memberof', 'nsaccountlock', 'memberofindirect', 'ipauserauthtype', 'userclass', 'ipatokenradiusconfiglink', 'ipatokenradiususername', - 'krbprincipalexpiration' + 'krbprincipalexpiration', 'usercertificate', ] search_display_attributes = [ 'uid', 'givenname', 'sn', 'homedirectory', 'loginshell', @@ -383,6 +384,11 @@ class baseuser(LDAPObject): + '(\s*,\s*[a-zA-Z]{1,8}(-[a-zA-Z]{1,8})?(;q\=((0(\.[0-9]{0,3})?)|(1(\.0{0,3})?)))?)*)|(\*))$', pattern_errmsg='must match RFC 2068 - 14.4, e.g., "da, en-gb;q=0.8, en;q=0.7"', ), + Bytes('usercertificate?', validate_certificate, + cli_name='certificate', + label=_('Certificate'), + doc=_('Base-64 encoded server certificate'), + ), ) def normalize_and_validate_email(self, email, config=None): diff --git a/ipalib/plugins/user.py b/ipalib/plugins/user.py index 54d47bb01450ec462577e552315e3d680b7648c3..e0004a5b01bf48887ca1bc429d8b37342e1c9cc0 100644 --- a/ipalib/plugins/user.py +++ b/ipalib/plugins/user.py @@ -267,10 +267,10 @@ class user(baseuser): 'mepmanagedentry', 'mobile', 'objectclass', 'ou', 'pager', 'postalcode', 'roomnumber', 'secretary', 'seealso', 'sn', 'st', 'street', 'telephonenumber', 'title', 'userclass', - 'preferredlanguage', + 'preferredlanguage', 'usercertificate', }, 'replaces': [ - '(targetattr = "givenname || sn || cn || displayname || title || initials || loginshell || gecos || homephone || mobile || pager || facsimiletelephonenumber || telephonenumber || street || roomnumber || l || st || postalcode || manager || secretary || description || carlicense || labeleduri || inetuserhttpurl || seealso || employeetype || businesscategory || ou || mepmanagedentry || objectclass")(target = "ldap:///uid=*,cn=users,cn=accounts,$SUFFIX")(version 3.0;acl "permission:Modify Users";allow (write) groupdn = "ldap:///cn=Modify Users,cn=permissions,cn=pbac,$SUFFIX";)', + '(targetattr = "givenname || sn || cn || displayname || title || initials || loginshell || gecos || homephone || mobile || pager || facsimiletelephonenumber || telephonenumber || street || roomnumber || l || st || postalcode || manager || secretary || description || carlicense || labeleduri || inetuserhttpurl || seealso || employeetype || businesscategory || usercertificate || ou || mepmanagedentry || objectclass")(target = "ldap:///uid=*,cn=users,cn=accounts,$SUFFIX")(version 3.0;acl "permission:Modify Users";allow (write) groupdn = "ldap:///cn=Modify Users,cn=permissions,cn=pbac,$SUFFIX";)', ], 'default_privileges': { 'User Administrators', -- 2.1.0 -------------- next part -------------- >From a877bad933cfb7454e670a684ce976194946f4c6 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Thu, 14 May 2015 01:45:16 -0400 Subject: [PATCH 11/11] Update cert-request to support user certs and profiles Part of: https://fedorahosted.org/freeipa/ticket/57 Part of: https://fedorahosted.org/freeipa/ticket/4938 --- ipalib/pkcs10.py | 1 + ipalib/plugins/cert.py | 174 ++++++++++++++++++++++++++----------------------- 2 files changed, 94 insertions(+), 81 deletions(-) diff --git a/ipalib/pkcs10.py b/ipalib/pkcs10.py index f35e200a2c1b47e2a2c8cffcf9b723f398fe3221..6299dfea43b7a3f4104f0b0ec78c4f105d9daf62 100644 --- a/ipalib/pkcs10.py +++ b/ipalib/pkcs10.py @@ -30,6 +30,7 @@ PEM = 0 DER = 1 SAN_DNSNAME = 'DNS name' +SAN_RFC822NAME = 'RFC822 Name' SAN_OTHERNAME_UPN = 'Other Name (OID.1.3.6.1.4.1.311.20.2.3)' SAN_OTHERNAME_KRB5PRINCIPALNAME = 'Other Name (OID.1.3.6.1.5.2.2)' diff --git a/ipalib/plugins/cert.py b/ipalib/plugins/cert.py index e4cb6dc0aa8b89368806b08674aae277b3653e8f..8fe5b9daf88870647067db37e6e3929cbc11626e 100644 --- a/ipalib/plugins/cert.py +++ b/ipalib/plugins/cert.py @@ -31,7 +31,8 @@ from ipalib import ngettext from ipalib.plugable import Registry from ipalib.plugins.virtual import * from ipalib.plugins.baseldap import pkey_to_value -from ipalib.plugins.service import split_principal +from ipalib.plugins.service import split_any_principal +from ipalib.plugins.certprofile import validate_profile_id import base64 import traceback from ipalib.text import _ @@ -122,6 +123,8 @@ http://www.ietf.org/rfc/rfc5280.txt """) +USER, HOST, SERVICE = range(3) + register = Registry() def validate_pkidate(ugettext, value): @@ -232,7 +235,7 @@ class cert_request(VirtualCommand): takes_options = ( Str('principal', label=_('Principal'), - doc=_('Service principal for this certificate (e.g. HTTP/test.example.com)'), + doc=_('Principal for this certificate (e.g. HTTP/test.example.com)'), ), Str('request_type', default=u'pkcs10', @@ -243,6 +246,10 @@ class cert_request(VirtualCommand): default=False, autofill=True ), + Str('profile_id', validate_profile_id, + label=_("Profile ID"), + doc=_("Certificate Profile to use"), + ) ) has_output_params = ( @@ -294,10 +301,9 @@ class cert_request(VirtualCommand): ca_enabled_check() ldap = self.api.Backend.ldap2 - principal = kw.get('principal') add = kw.get('add') request_type = kw.get('request_type') - service = None + profile_id = kw.get('profile_id', self.Backend.ra.DEFAULT_PROFILE) """ Access control is partially handled by the ACI titled @@ -310,9 +316,20 @@ class cert_request(VirtualCommand): taskgroup (directly or indirectly via role membership). """ - bind_principal = getattr(context, 'principal') - # Can this user request certs? - if not bind_principal.startswith('host/'): + principal = split_any_principal(kw.get('principal')) + servicename, principal_name, realm = principal + if servicename is None: + principal_type = USER + elif servicename == 'host': + principal_type = HOST + else: + principal_type = SERVICE + + bind_principal = split_any_principal(getattr(context, 'principal')) + bind_service, _, _ = bind_principal + + if bind_principal != principal: + # Can the bound principal request certs for another principal? self.check_access() try: @@ -323,57 +340,54 @@ class cert_request(VirtualCommand): raise errors.CertificateOperationError( error=_("Failure decoding Certificate Signing Request: %s") % e) - if not bind_principal.startswith('host/'): + # host principals may bypass allowed ext check + if bind_service != 'host': for ext in extensions: operation = self._allowed_extensions.get(ext) if operation: self.check_access(operation) - # Ensure that the hostname in the CSR matches the principal - subject_host = subject.common_name #pylint: disable=E1101 - if not subject_host: + + # Ensure that the DN in the CSR matches the principal + cn = subject.common_name #pylint: disable=E1101 + if not cn: raise errors.ValidationError(name='csr', - error=_("No hostname was found in subject of request.")) + error=_("No Common Name was found in subject of request.")) - (servicename, hostname, realm) = split_principal(principal) - if subject_host.lower() != hostname.lower(): - raise errors.ACIError( - info=_("hostname in subject of request '%(subject_host)s' " - "does not match principal hostname '%(hostname)s'") % dict( - subject_host=subject_host, hostname=hostname)) + if principal_type in (SERVICE, HOST): + if cn.lower() != principal_name.lower(): + raise errors.ACIError( + info=_("hostname in subject of request '%(cn)s' " + "does not match principal hostname '%(hostname)s'") + % dict(cn=cn, hostname=principal_name)) + elif principal_type == USER: + pass # TODO require cn / emailAddress to match user for ext in extensions: if ext not in self._allowed_extensions: raise errors.ValidationError( name='csr', error=_("extension %s is forbidden") % ext) - for name_type, name in subjectaltname: - if name_type not in (pkcs10.SAN_DNSNAME, - pkcs10.SAN_OTHERNAME_KRB5PRINCIPALNAME, - pkcs10.SAN_OTHERNAME_UPN): - raise errors.ValidationError( - name='csr', - error=_("subject alt name type %s is forbidden") % - name_type) - dn = None - service = None + principal_obj = None # See if the service exists and punt if it doesn't and we aren't # going to add it try: - if servicename != 'host': - service = api.Command['service_show'](principal, all=True) - else: - service = api.Command['host_show'](hostname, all=True) - except errors.NotFound, e: - if not add: - raise errors.NotFound(reason=_("The service principal for " - "this request doesn't exist.")) - service = api.Command['service_add'](principal, force=True) - service = service['result'] - dn = service['dn'] + if principal_type == SERVICE: + principal_obj = api.Command['service_show'](principal, all=True) + elif principal_type == HOST: + principal_obj = api.Command['host_show'](principal_name, all=True) + elif principal_type == USER: + principal_obj = api.Command['user_show'](principal_name, all=True) + except errors.NotFound as e: + if principal_type != SERVICE or not add: + raise errors.NotFound( + reason=_("The principal for this request doesn't exist.")) + principal_obj = api.Command['service_add'](principal, force=True) + principal_obj = principal_obj['result'] + dn = principal_obj['dn'] - # We got this far so the service entry exists, can we write it? + # We got this far so the principal entry exists, can we write it? if not ldap.can_write(dn, "usercertificate"): raise errors.ACIError(info=_("Insufficient 'write' privilege " "to the 'userCertificate' attribute of entry '%s'.") % dn) @@ -382,13 +396,20 @@ class cert_request(VirtualCommand): for name_type, name in subjectaltname: if name_type == pkcs10.SAN_DNSNAME: name = unicode(name) + alt_principal_obj = None try: - if servicename == 'host': - altservice = api.Command['host_show'](name, all=True) - else: + if principal_type == HOST: + alt_principal_obj = api.Command['host_show'](name, all=True) + elif principal_type == SERVICE: altprincipal = '%s/%s@%s' % (servicename, name, realm) - altservice = api.Command['service_show']( + alt_principal_obj = api.Command['service_show']( altprincipal, all=True) + elif principal_type == USER: + raise errors.ValidationError( + name='csr', + error=_("subject alt name type %s is forbidden " + "for user principals") % name_type + ) except errors.NotFound: # We don't want to issue any certificates referencing # machines we don't know about. Nothing is stored in this @@ -396,47 +417,35 @@ class cert_request(VirtualCommand): raise errors.NotFound(reason=_('The service principal for ' 'subject alt name %s in certificate request does not ' 'exist') % name) - altdn = altservice['result']['dn'] - if not ldap.can_write(altdn, "usercertificate"): - raise errors.ACIError(info=_( - "Insufficient privilege to create a certificate with " - "subject alt name '%s'.") % name) + if alt_principal_obj is not None: + altdn = alt_principal_obj['result']['dn'] + if not ldap.can_write(altdn, "usercertificate"): + raise errors.ACIError(info=_( + "Insufficient privilege to create a certificate " + "with subject alt name '%s'.") % name) elif name_type in (pkcs10.SAN_OTHERNAME_KRB5PRINCIPALNAME, pkcs10.SAN_OTHERNAME_UPN): if name != principal: raise errors.ACIError( info=_("Principal '%s' in subject alt name does not " - "match requested service principal") % name) + "match requested principal") % name) + elif name_type == pkcs10.SAN_RFC822NAME: + if principal_type == USER: + pass # TODO require match to user email address + else: + raise errors.ValidationError( + name='csr', + error=_("subject alt name type %s is forbidden " + "for non-user principals") % name_type + ) else: raise errors.ACIError( info=_("Subject alt name type %s is forbidden") % name_type) - if 'usercertificate' in service: - serial = x509.get_serial_number(service['usercertificate'][0], datatype=x509.DER) - # revoke the certificate and remove it from the service - # entry before proceeding. First we retrieve the certificate to - # see if it is already revoked, if not then we revoke it. - try: - result = api.Command['cert_show'](unicode(serial))['result'] - if 'revocation_reason' not in result: - try: - api.Command['cert_revoke'](unicode(serial), revocation_reason=4) - except errors.NotImplementedError: - # some CA's might not implement revoke - pass - except errors.NotImplementedError: - # some CA's might not implement get - pass - if not principal.startswith('host/'): - api.Command['service_mod'](principal, usercertificate=None) - else: - hostname = get_host_from_principal(principal) - api.Command['host_mod'](hostname, usercertificate=None) - # Request the certificate result = self.Backend.ra.request_certificate( - csr, 'caIPAserviceCert', request_type=request_type) + csr, profile_id, request_type=request_type) cert = x509.load_certificate(result['certificate']) result['issuer'] = unicode(cert.issuer) result['valid_not_before'] = unicode(cert.valid_not_before_str) @@ -444,15 +453,18 @@ class cert_request(VirtualCommand): result['md5_fingerprint'] = unicode(nss.data_to_hex(nss.md5_digest(cert.der_data), 64)[0]) result['sha1_fingerprint'] = unicode(nss.data_to_hex(nss.sha1_digest(cert.der_data), 64)[0]) - # Success? Then add it to the service entry. - if 'certificate' in result: - if not principal.startswith('host/'): - skw = {"usercertificate": str(result.get('certificate'))} + # Success? Then add it to the principal's entry + # (unless the profile tells us not to) + profile = api.Command['certprofile_show'](profile_id) + profile_store_issued = profile['result']['ipacertprofilestoreissued'] + if profile_store_issued and 'certificate' in result: + skw = {"usercertificate": str(result.get('certificate'))} + if principal_type == SERVICE: api.Command['service_mod'](principal, **skw) - else: - hostname = get_host_from_principal(principal) - skw = {"usercertificate": str(result.get('certificate'))} - api.Command['host_mod'](hostname, **skw) + elif principal_type == HOST: + api.Command['host_mod'](principal_name, **skw) + elif principal_type == USER: + api.Command['user_mod'](principal_name, **skw) return dict( result=result -- 2.1.0 From jcholast at redhat.com Wed May 20 15:27:35 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 20 May 2015 17:27:35 +0200 Subject: [Freeipa-devel] [PATCH 429] replica-install: Allow install on top of already configured client Message-ID: <555CA7E7.6050808@redhat.com> Hi, the attached patch implements the initial bits for . Test by running ipa-client-install and then ipa-replica-install on the same host. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-429-replica-install-Allow-install-on-top-of-already-conf.patch Type: text/x-patch Size: 11700 bytes Desc: not available URL: From lkrispen at redhat.com Wed May 20 15:40:11 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 20 May 2015 17:40:11 +0200 Subject: [Freeipa-devel] [PATCH] manage replication topology in the shared tree In-Reply-To: <555C8EB7.5030800@redhat.com> References: <552B84C5.80300@redhat.com> <55362C43.4020406@redhat.com> <55362FDC.7090104@redhat.com> <55519EAC.9000204@redhat.com> <555B2998.9020608@redhat.com> <555C8392.7010908@redhat.com> <555C84F2.7030500@redhat.com> <555C86F5.2080708@redhat.com> <555C8EB7.5030800@redhat.com> Message-ID: <555CAADB.1030306@redhat.com> please find new versions of patches 0003 and 0005 for the topology plugin. the ds plugin patch includes - changes to match domain level patch - remove trailing white spaces - use proper oids for topology schema the install patch - has the 70topology.ldif removed both patches can now be applied On 05/20/2015 03:40 PM, Ludwig Krispenz wrote: > > On 05/20/2015 03:07 PM, Petr Vobornik wrote: >> On 05/20/2015 02:58 PM, Ludwig Krispenz wrote: >>> >>> On 05/20/2015 02:52 PM, Oleg Fayans wrote: >>>> Is this patch to be applied on top of the vanilla upstream tree, or >>>> does it require your previous patches applied before? >>> it requires the install (0005) and ipa-command (0006) patch as well, >>> submitted on 05/12 >> >> Patch 0005 can't be applied on top of the new patch 3. Both patches >> contains adding of 70topology.ldif. > ok, this was my mistake when splitting the original patch, it should > only be in the plugin part > the trailing spaces in most cases are leftovers from the request to > make lines shorter, I will fix it for a new version >> >> Also please clear all trailing whitespaces from patch 3. >> >> $ git am >> freeipa-lkrispen-0003-plugin-part-manage-replication-topology-in-the-shaer.patch >> Applying: plugin part - manage replication topology in the shaerd tree >> /home/somebody/freeipa/.git/rebase-apply/patch:607: trailing whitespace. >> /home/somebody/freeipa/.git/rebase-apply/patch:740: trailing whitespace. >> * find the attrtype and return the corresponding >> /home/somebody/freeipa/.git/rebase-apply/patch:742: trailing whitespace. >> */ >> /home/somebody/freeipa/.git/rebase-apply/patch:745: trailing whitespace. >> /* attr is handling specific direction, >> /home/somebody/freeipa/.git/rebase-apply/patch:772: trailing whitespace. >> /* two static data structures to hold the >> warning: squelched 125 whitespace errors >> warning: 130 lines add whitespace errors. >> >> >>> >>>> >>>> On 05/19/2015 02:16 PM, Ludwig Krispenz wrote: >>>>> Hi, >>>>> >>>>> here is the latest patch for the plugin part, trying to address all >>>>> problems found in the review >>>>> >>>>> Regards, >>>>> Ludwig >>>>> PS if you want you can get a separate diff top the last version >>>>> >>>>> >>>>> On 05/12/2015 08:33 AM, Ludwig Krispenz wrote: >>>>>> Hi, >>>>>> >>>>>> I did split the patches, for easier review and to share work on it. >>>>>> The attachment contains 4 patches: >>>>>> - the ds plugin part as submitted for review >>>>>> - the changes to the ds plugin part done after review (not complete >>>>>> yet) >>>>>> - the ipa framework part (including Petr's improvements) >>>>>> - the install related part >>>>>> >>>>>> Regards, >>>>>> Ludwig >>>>>> >>>>>> On 04/21/2015 01:09 PM, Petr Vobornik wrote: >>>>>>> On 04/21/2015 12:53 PM, Petr Vobornik wrote: >>>>>>>> On 04/13/2015 10:56 AM, Ludwig Krispenz wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> in the attachment you find the latest state of the "topology >>>>>>>>> plugin", it >>>>>>>>> implements what is defined in the design page: >>>>>>>>> http://www.freeipa.org/page/V4/Manage_replication_topology >>>>>>>>> (which is >>>>>>>>> also waiting for a reviewer) >>>>>>>>> >>>>>>>>> It contains the plugin itself and a core of ipa commands to >>>>>>>>> manage a >>>>>>>>> topology. to be really applicable, some work outside is required, >>>>>>>>> eg the >>>>>>>>> management of the domain level and a decision where the binddn >>>>>>>>> group >>>>>>>>> should be maintained. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Ludwig >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> I've looked at the python part, mostly because I want to start >>>>>>>> with POC >>>>>>>> of Web UI for topology. >>>>>>>> >>>>>>>> topology.py is clearly still a work in progress. I've reflected >>>>>>>> following comments into a patch to speed things up. >>>>>>>> >>>>>>>> What's in the patch: >>>>>>>> >>>>>>>> 1. git am complains about trailing whitespaces >>>>>>>> >>>>>>>> 2. pep8 check produces quite a lot of issues. New code should be >>>>>>>> almost >>>>>>>> with any (`E501 line too long` is not a hard rule) >>>>>>>> `git diff HEAD~1 -U0 | pep8 --diff` >>>>>>>> >>>>>>>> 3. some typos >>>>>>>> >>>>>>>> 4. A lot of unused imports >>>>>>>> >>>>>>>> 5. Option name --sname for 'Segment identifier' is not very >>>>>>>> friendly. I >>>>>>>> don't see any examples of command options in the design notes. >>>>>>>> >>>>>>>> 6. NO_UPG_MAGIC - leftover from other plugin? >>>>>>>> >>>>>>>> 7. suffix object has labels from segment >>>>>>>> >>>>>>>> 8. IPA framework has a support for nested object. Key is setting >>>>>>>> `parent_object = 'topologysuffix'` in topologysegment object. >>>>>>>> >>>>>>>> 9. repl_agmt_attrs could be in topologysegment takes_params. >>>>>>>> >>>>>>>> 10. missing various CRUD commands like topologysuffix-find and >>>>>>>> topologysuffix-show commands. >>>>>>>> >>>>>>>> Whats missing, not fixed: >>>>>>>> 1. last 2 lines of VERSION file are not updated >>>>>>>> >>>>>>>> 2. Mixed terminology. Somewhere is used suffix and somewhere >>>>>>>> replication >>>>>>>> area or just area. >>>>>>>> >>>>>>>> 3. Validation >>>>>>>> - suffix should check for dn >>>>>>>> - existence of both ends of a segment >>>>>>>> >>>>>>>> 4. print of segments in suffix-show needs to be improved or >>>>>>>> removed >>>>>>>> >>>>>>>> To discuss: >>>>>>>> a) Do params in topologysegment have to have a maxlength set? >>>>>>>> >>>>>>>> b) Terminology has to be united. Segments are nested in suffix but >>>>>>>> sometimes are called areas and suffix is 'the suffix'. User >>>>>>>> might be >>>>>>>> confused. E.g. shouldn't the object be named a topologyarea >>>>>>>> instead of >>>>>>>> topologysuffix? >>>>>>>> >>>>>>>> c) I've added all missing CRUD commands. Are there any which we >>>>>>>> don't >>>>>>>> want there, or want to restrict them. E.g. I can imagine that >>>>>>>> deleting a >>>>>>>> suffix should be prevented if it contains any segments (or it has >>>>>>>> to be >>>>>>>> forced (--force option)) >>>>>>>> >>>>>>>> d) Do we want to print segments in suffix-show? >>>>>>>> >>>>>>>> e) Mainly for Honza: I've added --show-segments option to >>>>>>>> suffix-show >>>>>>>> which defaults to True. I don't like the behavior of CLI, which >>>>>>>> asks to >>>>>>>> confirm the value all the time. My intention was to have it >>>>>>>> there by >>>>>>>> default, but also allow to disable it by --show-segments=False. I >>>>>>>> don't >>>>>>>> want to add it as Flag (--hide-segments) since it restricts >>>>>>>> versatility. >>>>>>>> I would like to see an optional flag which would be filled by >>>>>>>> default >>>>>>>> value if not explicitly defined and CLI would not ask for the >>>>>>>> option value. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Also it would be better to split the work into more patches. E.g. >>>>>>> DS plugin, installation, python plugin. So ds plugin review could >>>>>>> be separated from the python part. >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> -- >>>> Oleg Fayans >>>> Quality Engineer >>>> FreeIPA team >>>> RedHat. >>> >>> >>> >>> >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-lkrispen-0005-install-part-manage-topology-in-shared-tree.patch Type: text/x-patch Size: 7678 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-lkrispen-0003-ds-plugin-manage-replication-topology-in-the-shared-.patch Type: text/x-patch Size: 151390 bytes Desc: not available URL: From mbabinsk at redhat.com Wed May 20 15:54:53 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 20 May 2015 17:54:53 +0200 Subject: [Freeipa-devel] [PATCH 428] client-install: Fix kinits with non-default Kerberos config file In-Reply-To: <555C99FB.2030308@redhat.com> References: <555C99FB.2030308@redhat.com> Message-ID: <555CAE4D.6010107@redhat.com> On 05/20/2015 04:28 PM, Jan Cholasta wrote: > Hi, > > the attached patch fixes a bug introduced in the fix for > (reopened). > > Honza > Works for me, ACK. -- Martin^3 Babinsky From mbasti at redhat.com Wed May 20 16:00:44 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 20 May 2015 18:00:44 +0200 Subject: [Freeipa-devel] [PATCHES 0252-0253] DNSSEC: allow to move DNSSEC key master to another IPA server Message-ID: <555CAFAC.2050803@redhat.com> This patch allows to disable DNSSEC key master on IPA server, or replace current DNSSEC key master with another IPA server. Only for master branch. https://fedorahosted.org/freeipa/ticket/4657 Patches attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0253-DNSSEC-update-message.patch Type: text/x-patch Size: 1032 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0252-DNSSEC-allow-to-disable-replace-DNSSEC-key-master.patch Type: text/x-patch Size: 20151 bytes Desc: not available URL: From rcritten at redhat.com Wed May 20 16:02:19 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 20 May 2015 12:02:19 -0400 Subject: [Freeipa-devel] [PATCH] 1112 Add service constraint delegation plugin In-Reply-To: <555BA115.5070408@redhat.com> References: <555B4696.2070502@redhat.com> <555BA115.5070408@redhat.com> Message-ID: <555CB00B.3080309@redhat.com> Rob Crittenden wrote: > 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. I must be getting rustly. Forgot to include ACIs. Added now. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1112-3-Add-plugin-to-manage-service-constraints.patch Type: text/x-diff Size: 46351 bytes Desc: not available URL: From jcholast at redhat.com Thu May 21 07:42:53 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 21 May 2015 09:42:53 +0200 Subject: [Freeipa-devel] [PATCH 428] client-install: Fix kinits with non-default Kerberos config file In-Reply-To: <555CAE4D.6010107@redhat.com> References: <555C99FB.2030308@redhat.com> <555CAE4D.6010107@redhat.com> Message-ID: <555D8C7D.70208@redhat.com> Dne 20.5.2015 v 17:54 Martin Babinsky napsal(a): > On 05/20/2015 04:28 PM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes a bug introduced in the fix for >> (reopened). >> >> Honza >> > Works for me, ACK. > Thanks. Pushed to: master: 454e8691cf7d64696fb8602d6e1ce5241f00f328 ipa-4-1: f6f94aec890bc48fd6268a054c0f6416aa8ee7d4 -- Jan Cholasta From mbabinsk at redhat.com Thu May 21 07:55:51 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 21 May 2015 09:55:51 +0200 Subject: [Freeipa-devel] [PATCH] 854 git ignore ipaplatform/__init__.py In-Reply-To: <555C92CE.1070603@redhat.com> References: <555C92CE.1070603@redhat.com> Message-ID: <555D8F87.4090803@redhat.com> On 05/20/2015 03:57 PM, Petr Vobornik wrote: > This file is generated in `make version-update` > > added in 9f049ca14403f3696d54d186e6b1b15181f055df > > Yay no more warnings about untracked file! ACK -- Martin^3 Babinsky From tbordaz at redhat.com Thu May 21 08:14:05 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 21 May 2015 10:14:05 +0200 Subject: [Freeipa-devel] [PATCH 0251] Fix uniqueness: exclude compat tree from uid uniquness plugin In-Reply-To: <555C8633.6090508@redhat.com> References: <555C8633.6090508@redhat.com> Message-ID: <555D93CD.6030403@redhat.com> On 05/20/2015 03:03 PM, Martin Basti wrote: > Enforcing uniqueness for uid attribute prevent to move users to delete > users subtree. > > Patch attached. > > > Hello Martin, The fix looks good. Don't we need to do the same in install/share/unique-attributes.ldif for fresh install ? thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Thu May 21 08:16:11 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 21 May 2015 10:16:11 +0200 Subject: [Freeipa-devel] [PATCH 0036] merge KRA installation machinery to a single module In-Reply-To: <555B7FB0.6030809@redhat.com> References: <555B7FB0.6030809@redhat.com> Message-ID: <555D944B.1050001@redhat.com> On 05/19/2015 08:23 PM, Martin Babinsky wrote: > 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. > > > Attaching rebased patch that should apply cleanly on current master without prerequisites. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0036.1-merge-KRA-installation-machinery-to-a-single-module.patch Type: text/x-patch Size: 14752 bytes Desc: not available URL: From mbasti at redhat.com Thu May 21 08:53:43 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 21 May 2015 10:53:43 +0200 Subject: [Freeipa-devel] [PATCH 0251] Fix uniqueness: exclude compat tree from uid uniquness plugin In-Reply-To: <555D93CD.6030403@redhat.com> References: <555C8633.6090508@redhat.com> <555D93CD.6030403@redhat.com> Message-ID: <555D9D17.7020503@redhat.com> On 21/05/15 10:14, thierry bordaz wrote: > On 05/20/2015 03:03 PM, Martin Basti wrote: >> Enforcing uniqueness for uid attribute prevent to move users to >> delete users subtree. >> >> Patch attached. >> >> >> > Hello Martin, > > The fix looks good. Don't we need to do the same in > install/share/unique-attributes.ldif for fresh install ? > > thanks > thierry Thanks for review. I don think so. In 10-uniqueness.update files, there are specified default values, which will be used for new installations. I would like to keep configuration of plugin just at one place. Martin^2 -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbordaz at redhat.com Thu May 21 08:59:54 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 21 May 2015 10:59:54 +0200 Subject: [Freeipa-devel] [PATCH 0251] Fix uniqueness: exclude compat tree from uid uniquness plugin In-Reply-To: <555D9D17.7020503@redhat.com> References: <555C8633.6090508@redhat.com> <555D93CD.6030403@redhat.com> <555D9D17.7020503@redhat.com> Message-ID: <555D9E8A.5040201@redhat.com> On 05/21/2015 10:53 AM, Martin Basti wrote: > On 21/05/15 10:14, thierry bordaz wrote: >> On 05/20/2015 03:03 PM, Martin Basti wrote: >>> Enforcing uniqueness for uid attribute prevent to move users to >>> delete users subtree. >>> >>> Patch attached. >>> >>> >>> >> Hello Martin, >> >> The fix looks good. Don't we need to do the same in >> install/share/unique-attributes.ldif for fresh install ? >> >> thanks >> thierry > Thanks for review. > > I don think so. > > In 10-uniqueness.update files, there are specified default values, > which will be used for new installations. > I would like to keep configuration of plugin just at one place. Yes that is a good idea. Does that mean that eventually files like unique-attributes.ldif will disappear ? thanks thierry > > Martin^2 > > -- > Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu May 21 09:06:48 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 21 May 2015 11:06:48 +0200 Subject: [Freeipa-devel] [PATCH 0251] Fix uniqueness: exclude compat tree from uid uniquness plugin In-Reply-To: <555D9E8A.5040201@redhat.com> References: <555C8633.6090508@redhat.com> <555D93CD.6030403@redhat.com> <555D9D17.7020503@redhat.com> <555D9E8A.5040201@redhat.com> Message-ID: <555DA028.7000405@redhat.com> On 21/05/15 10:59, thierry bordaz wrote: > On 05/21/2015 10:53 AM, Martin Basti wrote: >> On 21/05/15 10:14, thierry bordaz wrote: >>> On 05/20/2015 03:03 PM, Martin Basti wrote: >>>> Enforcing uniqueness for uid attribute prevent to move users to >>>> delete users subtree. >>>> >>>> Patch attached. >>>> >>>> >>>> >>> Hello Martin, >>> >>> The fix looks good. Don't we need to do the same in >>> install/share/unique-attributes.ldif for fresh install ? >>> >>> thanks >>> thierry >> Thanks for review. >> >> I don think so. >> >> In 10-uniqueness.update files, there are specified default values, >> which will be used for new installations. >> I would like to keep configuration of plugin just at one place. > Yes that is a good idea. Does that mean that eventually files like > unique-attributes.ldif will disappear ? Maybe in future. So is this patch ACKed? > > thanks > thierry >> >> Martin^2 >> >> -- >> Martin Basti > -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbordaz at redhat.com Thu May 21 09:07:53 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 21 May 2015 11:07:53 +0200 Subject: [Freeipa-devel] [PATCH 0251] Fix uniqueness: exclude compat tree from uid uniquness plugin In-Reply-To: <555DA028.7000405@redhat.com> References: <555C8633.6090508@redhat.com> <555D93CD.6030403@redhat.com> <555D9D17.7020503@redhat.com> <555D9E8A.5040201@redhat.com> <555DA028.7000405@redhat.com> Message-ID: <555DA069.6010802@redhat.com> On 05/21/2015 11:06 AM, Martin Basti wrote: > On 21/05/15 10:59, thierry bordaz wrote: >> On 05/21/2015 10:53 AM, Martin Basti wrote: >>> On 21/05/15 10:14, thierry bordaz wrote: >>>> On 05/20/2015 03:03 PM, Martin Basti wrote: >>>>> Enforcing uniqueness for uid attribute prevent to move users to >>>>> delete users subtree. >>>>> >>>>> Patch attached. >>>>> >>>>> >>>>> >>>> Hello Martin, >>>> >>>> The fix looks good. Don't we need to do the same in >>>> install/share/unique-attributes.ldif for fresh install ? >>>> >>>> thanks >>>> thierry >>> Thanks for review. >>> >>> I don think so. >>> >>> In 10-uniqueness.update files, there are specified default values, >>> which will be used for new installations. >>> I would like to keep configuration of plugin just at one place. >> Yes that is a good idea. Does that mean that eventually files like >> unique-attributes.ldif will disappear ? > Maybe in future. > > So is this patch ACKed? Sorry, yes the fix is good. ACK >> >> thanks >> thierry >>> >>> Martin^2 >>> >>> -- >>> Martin Basti >> > > > -- > Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Thu May 21 10:31:56 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 21 May 2015 12:31:56 +0200 Subject: [Freeipa-devel] [PATCH 0372-0375] Fix doc/schema to be compatible with OpenLDAP Message-ID: <555DB41C.5050008@redhat.com> Hello, I need to use the schema with OpenLDAP server and apparently OpenLDAP can't handle the original line ordering. Pushed to master: 2a65d0b2962bbeec4f769e9724d0d22879e24193 Turn doc/schema into a valid LDIF file. e86c94b63e62fefef96fbec6377bf43a0e246d84 Add COSINE schema attributes to doc/schema. e16a59471c5e9c88d4baee225c38c7dcd8159573 Fix doc/schema ordering to be compatible with OpenLDAP. e8444906881f4ba5d707fa2a611f1a8187142d00 Rename doc/schema to doc/schema.ldif. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0372-Turn-doc-schema-into-a-valid-LDIF-file.patch Type: text/x-patch Size: 22171 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0373-Add-COSINE-schema-attributes-to-doc-schema.patch Type: text/x-patch Size: 2463 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0374-Fix-doc-schema-ordering-to-be-compatible-with-OpenLD.patch Type: text/x-patch Size: 14637 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0375-Rename-doc-schema-to-doc-schema.ldif.patch Type: text/x-patch Size: 771 bytes Desc: not available URL: From pspacek at redhat.com Thu May 21 10:42:28 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 21 May 2015 12:42:28 +0200 Subject: [Freeipa-devel] [PATCH 0376] Add schema for unknown record types Message-ID: <555DB694.4090808@redhat.com> Hello, Add schema for unknown record types. This patch complements my previous patch 367. The change was pushed to https://github.com/pspacek/bind-dyndb-ldap/tree/unknown_record_types , too. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0376-Add-schema-for-unknown-record-types.patch Type: text/x-patch Size: 1446 bytes Desc: not available URL: From tbordaz at redhat.com Thu May 21 10:55:54 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 21 May 2015 12:55:54 +0200 Subject: [Freeipa-devel] [PATCH] manage replication topology in the shared tree In-Reply-To: <555CAADB.1030306@redhat.com> References: <552B84C5.80300@redhat.com> <55362C43.4020406@redhat.com> <55362FDC.7090104@redhat.com> <55519EAC.9000204@redhat.com> <555B2998.9020608@redhat.com> <555C8392.7010908@redhat.com> <555C84F2.7030500@redhat.com> <555C86F5.2080708@redhat.com> <555C8EB7.5030800@redhat.com> <555CAADB.1030306@redhat.com> Message-ID: <555DB9BA.6090001@redhat.com> On 05/20/2015 05:40 PM, Ludwig Krispenz wrote: > please find new versions of patches 0003 and 0005 for the topology > plugin. > > the ds plugin patch includes > - changes to match domain level patch > - remove trailing white spaces > - use proper oids for topology schema > > the install patch > - has the 70topology.ldif removed Hello Ludwig, I failed to do 'git am patch-0003', it returned a strange "Patch format detection failed.". However I was able to do 'git apply' and to review it. I focus on the points discussed during previous reviews. The patch is looking good to me. ACK thanks thierry > > both patches can now be applied > > On 05/20/2015 03:40 PM, Ludwig Krispenz wrote: >> >> On 05/20/2015 03:07 PM, Petr Vobornik wrote: >>> On 05/20/2015 02:58 PM, Ludwig Krispenz wrote: >>>> >>>> On 05/20/2015 02:52 PM, Oleg Fayans wrote: >>>>> Is this patch to be applied on top of the vanilla upstream tree, or >>>>> does it require your previous patches applied before? >>>> it requires the install (0005) and ipa-command (0006) patch as well, >>>> submitted on 05/12 >>> >>> Patch 0005 can't be applied on top of the new patch 3. Both patches >>> contains adding of 70topology.ldif. >> ok, this was my mistake when splitting the original patch, it should >> only be in the plugin part >> the trailing spaces in most cases are leftovers from the request to >> make lines shorter, I will fix it for a new version >>> >>> Also please clear all trailing whitespaces from patch 3. >>> >>> $ git am >>> freeipa-lkrispen-0003-plugin-part-manage-replication-topology-in-the-shaer.patch >>> Applying: plugin part - manage replication topology in the shaerd tree >>> /home/somebody/freeipa/.git/rebase-apply/patch:607: trailing >>> whitespace. >>> /home/somebody/freeipa/.git/rebase-apply/patch:740: trailing >>> whitespace. >>> * find the attrtype and return the corresponding >>> /home/somebody/freeipa/.git/rebase-apply/patch:742: trailing >>> whitespace. >>> */ >>> /home/somebody/freeipa/.git/rebase-apply/patch:745: trailing >>> whitespace. >>> /* attr is handling specific direction, >>> /home/somebody/freeipa/.git/rebase-apply/patch:772: trailing >>> whitespace. >>> /* two static data structures to hold the >>> warning: squelched 125 whitespace errors >>> warning: 130 lines add whitespace errors. >>> >>> >>>> >>>>> >>>>> On 05/19/2015 02:16 PM, Ludwig Krispenz wrote: >>>>>> Hi, >>>>>> >>>>>> here is the latest patch for the plugin part, trying to address all >>>>>> problems found in the review >>>>>> >>>>>> Regards, >>>>>> Ludwig >>>>>> PS if you want you can get a separate diff top the last version >>>>>> >>>>>> >>>>>> On 05/12/2015 08:33 AM, Ludwig Krispenz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I did split the patches, for easier review and to share work on it. >>>>>>> The attachment contains 4 patches: >>>>>>> - the ds plugin part as submitted for review >>>>>>> - the changes to the ds plugin part done after review (not complete >>>>>>> yet) >>>>>>> - the ipa framework part (including Petr's improvements) >>>>>>> - the install related part >>>>>>> >>>>>>> Regards, >>>>>>> Ludwig >>>>>>> >>>>>>> On 04/21/2015 01:09 PM, Petr Vobornik wrote: >>>>>>>> On 04/21/2015 12:53 PM, Petr Vobornik wrote: >>>>>>>>> On 04/13/2015 10:56 AM, Ludwig Krispenz wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> in the attachment you find the latest state of the "topology >>>>>>>>>> plugin", it >>>>>>>>>> implements what is defined in the design page: >>>>>>>>>> http://www.freeipa.org/page/V4/Manage_replication_topology >>>>>>>>>> (which is >>>>>>>>>> also waiting for a reviewer) >>>>>>>>>> >>>>>>>>>> It contains the plugin itself and a core of ipa commands to >>>>>>>>>> manage a >>>>>>>>>> topology. to be really applicable, some work outside is >>>>>>>>>> required, >>>>>>>>>> eg the >>>>>>>>>> management of the domain level and a decision where the >>>>>>>>>> binddn group >>>>>>>>>> should be maintained. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Ludwig >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> I've looked at the python part, mostly because I want to start >>>>>>>>> with POC >>>>>>>>> of Web UI for topology. >>>>>>>>> >>>>>>>>> topology.py is clearly still a work in progress. I've reflected >>>>>>>>> following comments into a patch to speed things up. >>>>>>>>> >>>>>>>>> What's in the patch: >>>>>>>>> >>>>>>>>> 1. git am complains about trailing whitespaces >>>>>>>>> >>>>>>>>> 2. pep8 check produces quite a lot of issues. New code should be >>>>>>>>> almost >>>>>>>>> with any (`E501 line too long` is not a hard rule) >>>>>>>>> `git diff HEAD~1 -U0 | pep8 --diff` >>>>>>>>> >>>>>>>>> 3. some typos >>>>>>>>> >>>>>>>>> 4. A lot of unused imports >>>>>>>>> >>>>>>>>> 5. Option name --sname for 'Segment identifier' is not very >>>>>>>>> friendly. I >>>>>>>>> don't see any examples of command options in the design notes. >>>>>>>>> >>>>>>>>> 6. NO_UPG_MAGIC - leftover from other plugin? >>>>>>>>> >>>>>>>>> 7. suffix object has labels from segment >>>>>>>>> >>>>>>>>> 8. IPA framework has a support for nested object. Key is setting >>>>>>>>> `parent_object = 'topologysuffix'` in topologysegment object. >>>>>>>>> >>>>>>>>> 9. repl_agmt_attrs could be in topologysegment takes_params. >>>>>>>>> >>>>>>>>> 10. missing various CRUD commands like topologysuffix-find and >>>>>>>>> topologysuffix-show commands. >>>>>>>>> >>>>>>>>> Whats missing, not fixed: >>>>>>>>> 1. last 2 lines of VERSION file are not updated >>>>>>>>> >>>>>>>>> 2. Mixed terminology. Somewhere is used suffix and somewhere >>>>>>>>> replication >>>>>>>>> area or just area. >>>>>>>>> >>>>>>>>> 3. Validation >>>>>>>>> - suffix should check for dn >>>>>>>>> - existence of both ends of a segment >>>>>>>>> >>>>>>>>> 4. print of segments in suffix-show needs to be improved or >>>>>>>>> removed >>>>>>>>> >>>>>>>>> To discuss: >>>>>>>>> a) Do params in topologysegment have to have a maxlength set? >>>>>>>>> >>>>>>>>> b) Terminology has to be united. Segments are nested in suffix >>>>>>>>> but >>>>>>>>> sometimes are called areas and suffix is 'the suffix'. User >>>>>>>>> might be >>>>>>>>> confused. E.g. shouldn't the object be named a topologyarea >>>>>>>>> instead of >>>>>>>>> topologysuffix? >>>>>>>>> >>>>>>>>> c) I've added all missing CRUD commands. Are there any which >>>>>>>>> we don't >>>>>>>>> want there, or want to restrict them. E.g. I can imagine that >>>>>>>>> deleting a >>>>>>>>> suffix should be prevented if it contains any segments (or it has >>>>>>>>> to be >>>>>>>>> forced (--force option)) >>>>>>>>> >>>>>>>>> d) Do we want to print segments in suffix-show? >>>>>>>>> >>>>>>>>> e) Mainly for Honza: I've added --show-segments option to >>>>>>>>> suffix-show >>>>>>>>> which defaults to True. I don't like the behavior of CLI, which >>>>>>>>> asks to >>>>>>>>> confirm the value all the time. My intention was to have it >>>>>>>>> there by >>>>>>>>> default, but also allow to disable it by --show-segments=False. I >>>>>>>>> don't >>>>>>>>> want to add it as Flag (--hide-segments) since it restricts >>>>>>>>> versatility. >>>>>>>>> I would like to see an optional flag which would be filled by >>>>>>>>> default >>>>>>>>> value if not explicitly defined and CLI would not ask for the >>>>>>>>> option value. >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Also it would be better to split the work into more patches. E.g. >>>>>>>> DS plugin, installation, python plugin. So ds plugin review could >>>>>>>> be separated from the python part. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Oleg Fayans >>>>> Quality Engineer >>>>> FreeIPA team >>>>> RedHat. >>>> >>>> >>>> >>>> >>> >>> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu May 21 11:38:43 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 21 May 2015 13:38:43 +0200 Subject: [Freeipa-devel] [PATCH 0254] Server Upgrade: Wait until DS is ready after restart Message-ID: <555DC3C3.30707@redhat.com> This patch should fix following traceback. 2015-05-20T03:50:41Z ERROR Upgrade failed with cannot connect to 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': 2015-05-20T03:50:41Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 304, in __upgrade ld = ldapupdate.LDAPUpdate(dm_password='', ldapi=True) File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 314, in __init__ self.create_connection() File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 862, in create_connection autobind=self.ldapi) File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 66, in connect conn = self.create_connection(*args, **kw) File "/usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py", line 188, in create_connection client_controls=clientctrls) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1074, in external_bind '', auth_tokens, server_controls, client_controls) File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ self.gen.throw(type, value, traceback) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 976, in error_handler error=info) NetworkError: cannot connect to 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': 2015-05-20T03:50:41Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 388, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 378, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 315, in __upgrade raise RuntimeError(e) RuntimeError: cannot connect to 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': Reason was the ipa-server-install tried to connect before DS was ready. The patch adds waiting until DS is ready. Patch attached. Fraser can you please check if this fix works? I can't reproduce it. Thank you, Martin^2. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0254-Server-Upgrade-wait-until-DS-is-ready.patch Type: text/x-patch Size: 2952 bytes Desc: not available URL: From mbasti at redhat.com Thu May 21 12:16:22 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 21 May 2015 14:16:22 +0200 Subject: [Freeipa-devel] [PATCHES 0001-0011 v3] Profile management In-Reply-To: <20150520144106.GH12806@dhcp-40-8.bne.redhat.com> References: <555305EC.5020001@redhat.com> <55530D23.5040702@redhat.com> <55530DDB.9000101@redhat.com> <20150515082420.GR12806@dhcp-40-8.bne.redhat.com> <5555E63D.4050808@redhat.com> <555AF9E1.1010606@redhat.com> <20150519115027.GA12806@dhcp-40-8.bne.redhat.com> <555C1E5C.2080707@redhat.com> <20150520055636.GF12806@dhcp-40-8.bne.redhat.com> <555C30FE.4030707@redhat.com> <20150520144106.GH12806@dhcp-40-8.bne.redhat.com> Message-ID: <555DCC96.2050001@redhat.com> On 20/05/15 16:41, Fraser Tweedale wrote: > Hi Honza, Martin et al, > > Latest patches attached. On top of previous patches (most review > matters addressed**) patches 0008..0011 add support for profiles and > user certificates to `ipa cert-request'. > > ** those that were not are being tracked at [1]; please add anything > I missed. > > Some points to note: > > - usercertificate is not yet a multi-valued attribute for users, > hosts and services. > > QUESTION - we do want to allow multiple certificates for all > principal types, not just users? Or have I got that wrong. > > - "DN and SAN match principal" checks are not implemented for users > yet. > > - ACL was added to allow user principals to request their own > certificates, however, this will be further subject to CA/profile > ACLs which are to come. > > - Pursuant to [2] revocation logic was removed from `cert-request' > > [1] http://idm.etherpad.corp.redhat.com/rhel72-cert-mgmt-progress > [2] http://www.freeipa.org/page/V4/User_Certificates#Revocation_of_the_Certificates > > Thanks, > Fraser I tried upgrade and: Updating managed permissions for certprofile Upgrade failed with targetattr "ipacertprofilestoreissued" does not exist in schema. Please add attributeTypes "ipacertprofilestoreissued" to schema if necessary. ACL Syntax Error(-5):(targetattr = \22cn || description || ipacertprofilestoreissued\22)(targetfilter = \22(objectclass=ipacertprofile)\22)(version 3.0;acl \22permission:System: Modify Certificate Profile\22;allow (write) groupdn = \22ldap:///cn=System: Modify Certificate Profile,cn=permissions,cn=pbac,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com\22;): Invalid syntax. [error] RuntimeError: targetattr "ipacertprofilestoreissued" does not exist in schema. Please add attributeTypes "ipacertprofilestoreissued" to schema if necessary. ACL Syntax Error(-5):(targetattr = \22cn || description || ipacertprofilestoreissued\22)(targetfilter = \22(objectclass=ipacertprofile)\22)(version 3.0;acl \22permission:System: Modify Certificate Profile\22;allow (write) groupdn = \22ldap:///cn=System: Modify Certificate Profile,cn=permissions,cn=pbac,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com\22;): Invalid syntax. [cleanup]: stopping directory server [cleanup]: restoring configuration I cannot find the "ipacertprofilestoreissued" in any IPA schema file. Did I miss something? -- Martin Basti From mbasti at redhat.com Thu May 21 12:31:45 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 21 May 2015 14:31:45 +0200 Subject: [Freeipa-devel] [PATCHES 0001-0011 v3] Profile management In-Reply-To: <555DCC96.2050001@redhat.com> References: <555305EC.5020001@redhat.com> <55530D23.5040702@redhat.com> <55530DDB.9000101@redhat.com> <20150515082420.GR12806@dhcp-40-8.bne.redhat.com> <5555E63D.4050808@redhat.com> <555AF9E1.1010606@redhat.com> <20150519115027.GA12806@dhcp-40-8.bne.redhat.com> <555C1E5C.2080707@redhat.com> <20150520055636.GF12806@dhcp-40-8.bne.redhat.com> <555C30FE.4030707@redhat.com> <20150520144106.GH12806@dhcp-40-8.bne.redhat.com> <555DCC96.2050001@redhat.com> Message-ID: <555DD031.8070302@redhat.com> On 21/05/15 14:16, Martin Basti wrote: > On 20/05/15 16:41, Fraser Tweedale wrote: >> Hi Honza, Martin et al, >> >> Latest patches attached. On top of previous patches (most review >> matters addressed**) patches 0008..0011 add support for profiles and >> user certificates to `ipa cert-request'. >> >> ** those that were not are being tracked at [1]; please add anything >> I missed. >> >> Some points to note: >> >> - usercertificate is not yet a multi-valued attribute for users, >> hosts and services. >> >> QUESTION - we do want to allow multiple certificates for all >> principal types, not just users? Or have I got that wrong. >> >> - "DN and SAN match principal" checks are not implemented for users >> yet. >> >> - ACL was added to allow user principals to request their own >> certificates, however, this will be further subject to CA/profile >> ACLs which are to come. >> >> - Pursuant to [2] revocation logic was removed from `cert-request' >> >> [1] http://idm.etherpad.corp.redhat.com/rhel72-cert-mgmt-progress >> [2] >> http://www.freeipa.org/page/V4/User_Certificates#Revocation_of_the_Certificates >> >> Thanks, >> Fraser > I tried upgrade and: > > Updating managed permissions for certprofile > Upgrade failed with targetattr "ipacertprofilestoreissued" does not > exist in schema. Please add attributeTypes "ipacertprofilestoreissued" > to schema if necessary. ACL Syntax Error(-5):(targetattr = \22cn || > description || ipacertprofilestoreissued\22)(targetfilter = > \22(objectclass=ipacertprofile)\22)(version 3.0;acl > \22permission:System: Modify Certificate Profile\22;allow (write) > groupdn = \22ldap:///cn=System: Modify Certificate > Profile,cn=permissions,cn=pbac,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com\22;): > Invalid syntax. > [error] RuntimeError: targetattr "ipacertprofilestoreissued" does > not exist in schema. Please add attributeTypes > "ipacertprofilestoreissued" to schema if necessary. ACL Syntax > Error(-5):(targetattr = \22cn || description || > ipacertprofilestoreissued\22)(targetfilter = > \22(objectclass=ipacertprofile)\22)(version 3.0;acl > \22permission:System: Modify Certificate Profile\22;allow (write) > groupdn = \22ldap:///cn=System: Modify Certificate > Profile,cn=permissions,cn=pbac,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com\22;): > Invalid syntax. > [cleanup]: stopping directory server > [cleanup]: restoring configuration > > I cannot find the "ipacertprofilestoreissued" in any IPA schema file. > > Did I miss something? > > Sorry, I found it, stupid me. I will investigate why upgrade failed then. -- Martin Basti From mkubik at redhat.com Thu May 21 12:36:14 2015 From: mkubik at redhat.com (Milan Kubik) Date: Thu, 21 May 2015 14:36:14 +0200 Subject: [Freeipa-devel] certprofiles -- problem with delete Message-ID: <555DD13E.5060503@redhat.com> Hi Fraser and list, I ran into this when I was tinkering with the commands. The ipa certprofile plugin[s] does not take the backend result into the picture right now. When I tried to delete the *default profile*, the entry from ipa suffix got deleted. However the command failed and the profile is still in the dogtag managed suffix. After I've done this to the installed instance, subsequent uninstall operation failed on some step involving dogtag. I suspect it is related. I haven't been able to reproduce this for now as at the moment there was no package with dogtag in the copr repo. Reproducer for this is attached. (This reproducer requires patches at least up to freeipa-ftweedal-0005-3-Add-certprofile-plugin.patch) It may be more complicated issue than it seems, though. If we delete the ipa managed entry before the dogtag operation and this one fails, it leaves us in an inconsistent state. If on the other hand we delete the ipa managed entry after dogtag call, it opens an possibility of failing to delete the entry in ipa, leading to inconsistency again. The solution to this would be a transaction. The problem here is that the transaction here would span through two integrated components (three actually, ipa, 389 and dogtag, in this context). Not an easy thing to do I assume. TL;DR: * certprofile-del deletes ipa managed entry and dogtag doesn't * how do we approach possibly irreversible changes in LDAPObject plugins when integrated component doesn't behave? Your thoughts on this? Thanks, Milan -------------- next part -------------- A non-text attachment was scrubbed... Name: delete_default_profile.sh Type: application/x-shellscript Size: 620 bytes Desc: not available URL: From mbasti at redhat.com Thu May 21 12:46:20 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 21 May 2015 14:46:20 +0200 Subject: [Freeipa-devel] [PATCHES 0001-0011 v3] Profile management In-Reply-To: <555DD031.8070302@redhat.com> References: <555305EC.5020001@redhat.com> <55530D23.5040702@redhat.com> <55530DDB.9000101@redhat.com> <20150515082420.GR12806@dhcp-40-8.bne.redhat.com> <5555E63D.4050808@redhat.com> <555AF9E1.1010606@redhat.com> <20150519115027.GA12806@dhcp-40-8.bne.redhat.com> <555C1E5C.2080707@redhat.com> <20150520055636.GF12806@dhcp-40-8.bne.redhat.com> <555C30FE.4030707@redhat.com> <20150520144106.GH12806@dhcp-40-8.bne.redhat.com> <555DCC96.2050001@redhat.com> <555DD031.8070302@redhat.com> Message-ID: <555DD39C.3070103@redhat.com> On 21/05/15 14:31, Martin Basti wrote: > On 21/05/15 14:16, Martin Basti wrote: >> On 20/05/15 16:41, Fraser Tweedale wrote: >>> Hi Honza, Martin et al, >>> >>> Latest patches attached. On top of previous patches (most review >>> matters addressed**) patches 0008..0011 add support for profiles and >>> user certificates to `ipa cert-request'. >>> >>> ** those that were not are being tracked at [1]; please add anything >>> I missed. >>> >>> Some points to note: >>> >>> - usercertificate is not yet a multi-valued attribute for users, >>> hosts and services. >>> >>> QUESTION - we do want to allow multiple certificates for all >>> principal types, not just users? Or have I got that wrong. >>> >>> - "DN and SAN match principal" checks are not implemented for users >>> yet. >>> >>> - ACL was added to allow user principals to request their own >>> certificates, however, this will be further subject to CA/profile >>> ACLs which are to come. >>> >>> - Pursuant to [2] revocation logic was removed from `cert-request' >>> >>> [1] http://idm.etherpad.corp.redhat.com/rhel72-cert-mgmt-progress >>> [2] >>> http://www.freeipa.org/page/V4/User_Certificates#Revocation_of_the_Certificates >>> >>> Thanks, >>> Fraser >> I tried upgrade and: >> >> Updating managed permissions for certprofile >> Upgrade failed with targetattr "ipacertprofilestoreissued" does not >> exist in schema. Please add attributeTypes >> "ipacertprofilestoreissued" to schema if necessary. ACL Syntax >> Error(-5):(targetattr = \22cn || description || >> ipacertprofilestoreissued\22)(targetfilter = >> \22(objectclass=ipacertprofile)\22)(version 3.0;acl >> \22permission:System: Modify Certificate Profile\22;allow (write) >> groupdn = \22ldap:///cn=System: Modify Certificate >> Profile,cn=permissions,cn=pbac,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com\22;): >> Invalid syntax. >> [error] RuntimeError: targetattr "ipacertprofilestoreissued" does >> not exist in schema. Please add attributeTypes >> "ipacertprofilestoreissued" to schema if necessary. ACL Syntax >> Error(-5):(targetattr = \22cn || description || >> ipacertprofilestoreissued\22)(targetfilter = >> \22(objectclass=ipacertprofile)\22)(version 3.0;acl >> \22permission:System: Modify Certificate Profile\22;allow (write) >> groupdn = \22ldap:///cn=System: Modify Certificate >> Profile,cn=permissions,cn=pbac,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com\22;): >> Invalid syntax. >> [cleanup]: stopping directory server >> [cleanup]: restoring configuration >> >> I cannot find the "ipacertprofilestoreissued" in any IPA schema file. >> >> Did I miss something? >> >> > Sorry, I found it, stupid me. > I will investigate why upgrade failed then. > Bug in ipa-server-upgrade, thank you to find this issue :-) -- Martin Basti From mbasti at redhat.com Thu May 21 12:49:03 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 21 May 2015 14:49:03 +0200 Subject: [Freeipa-devel] [PATCH 0255] Server Upgrade: Fix: executed schema upgrade Message-ID: <555DD43F.3060708@redhat.com> Accidentaly , schema upgrade hasn't beed executed by ipa-server-upgrade. https://fedorahosted.org/freeipa/ticket/4904 Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0255-Server-Upgrade-Fix-execute-schema-update.patch Type: text/x-patch Size: 1609 bytes Desc: not available URL: From ftweedal at redhat.com Thu May 21 13:10:26 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 21 May 2015 23:10:26 +1000 Subject: [Freeipa-devel] certprofiles -- problem with delete In-Reply-To: <555DD13E.5060503@redhat.com> References: <555DD13E.5060503@redhat.com> Message-ID: <20150521131026.GI12806@dhcp-40-8.bne.redhat.com> On Thu, May 21, 2015 at 02:36:14PM +0200, Milan Kubik wrote: > Hi Fraser and list, > > I ran into this when I was tinkering with the commands. > > The ipa certprofile plugin[s] does not take the backend result into the > picture right now. When I tried to delete the *default profile*, the entry > from ipa suffix got deleted. However the command failed > and the profile is still in the dogtag managed suffix. > After I've done this to the installed instance, subsequent uninstall > operation failed on some step involving dogtag. I suspect it is related. > I haven't been able to reproduce this for now as at the moment there > was no package with dogtag in the copr repo. > Reproducer for this is attached. (This reproducer requires patches at > least up to freeipa-ftweedal-0005-3-Add-certprofile-plugin.patch) > > It may be more complicated issue than it seems, though. > If we delete the ipa managed entry before the dogtag operation > and this one fails, it leaves us in an inconsistent state. > If on the other hand we delete the ipa managed entry after dogtag > call, it opens an possibility of failing to delete the entry in ipa, leading > to inconsistency again. > > The solution to this would be a transaction. The problem here is > that the transaction here would span through two integrated > components (three actually, ipa, 389 and dogtag, in this context). > Not an easy thing to do I assume. > > TL;DR: > > * certprofile-del deletes ipa managed entry and dogtag doesn't > * how do we approach possibly irreversible changes in LDAPObject > plugins when integrated component doesn't behave? > > Your thoughts on this? > Thanks for the report - certprofile-del was working at an earlier stage so I will track down the issue and fix. I have pondered the transaction requirements: I am managing it for certprofile-import by deleting the entry if the dogtag import fails. I suppose I can do a similar thing for certprofile del - keep a copy of the entry and re-add it if delete fails. Sound OK to you? Cheers, Fraser > > Thanks, > Milan From ftweedal at redhat.com Thu May 21 13:16:37 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 21 May 2015 23:16:37 +1000 Subject: [Freeipa-devel] [PATCH 0254] Server Upgrade: Wait until DS is ready after restart In-Reply-To: <555DC3C3.30707@redhat.com> References: <555DC3C3.30707@redhat.com> Message-ID: <20150521131637.GJ12806@dhcp-40-8.bne.redhat.com> On Thu, May 21, 2015 at 01:38:43PM +0200, Martin Basti wrote: > This patch should fix following traceback. > > 2015-05-20T03:50:41Z ERROR Upgrade failed with cannot connect to 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': > 2015-05-20T03:50:41Z DEBUG Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 304, in __upgrade > ld = ldapupdate.LDAPUpdate(dm_password='', ldapi=True) > File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 314, in __init__ > self.create_connection() > File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 862, in create_connection > autobind=self.ldapi) > File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 66, in connect > conn = self.create_connection(*args, **kw) > File "/usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py", line 188, in create_connection > client_controls=clientctrls) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1074, in external_bind > '', auth_tokens, server_controls, client_controls) > File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ > self.gen.throw(type, value, traceback) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 976, in error_handler > error=info) > NetworkError: cannot connect to 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': > > 2015-05-20T03:50:41Z DEBUG Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 388, in start_creation > run_step(full_msg, method) > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 378, in run_step > method() > File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 315, in __upgrade > raise RuntimeError(e) > RuntimeError: cannot connect to 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': > > Reason was the ipa-server-install tried to connect before DS was ready. > > The patch adds waiting until DS is ready. > > Patch attached. > > Fraser can you please check if this fix works? I can't reproduce it. > Thank you, Martin^2. > ACK; fixes the issue for me. One minor comment: > + def __start(self): > + super(IPAUpgrade, self).start() > > def __stop_instance(self): > """Stop only the main DS instance""" > @@ -187,7 +185,7 @@ class IPAUpgrade(service.Service): > self.step("saving configuration", self.__save_config) > self.step("disabling listeners", self.__disable_listeners) > self.step("enabling DS global lock", self.__enable_ds_global_write_lock) > - self.step("starting directory server", self.__start_nowait) > + self.step("starting directory server", self.__start) I think you can just say `self.start' and remove `__start' function. Cheers, Fraser From mkosek at redhat.com Thu May 21 13:20:30 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 21 May 2015 15:20:30 +0200 Subject: [Freeipa-devel] certprofiles -- problem with delete In-Reply-To: <20150521131026.GI12806@dhcp-40-8.bne.redhat.com> References: <555DD13E.5060503@redhat.com> <20150521131026.GI12806@dhcp-40-8.bne.redhat.com> Message-ID: <555DDB9E.20701@redhat.com> On 05/21/2015 03:10 PM, Fraser Tweedale wrote: > On Thu, May 21, 2015 at 02:36:14PM +0200, Milan Kubik wrote: >> Hi Fraser and list, >> >> I ran into this when I was tinkering with the commands. >> >> The ipa certprofile plugin[s] does not take the backend result into the >> picture right now. When I tried to delete the *default profile*, the entry >> from ipa suffix got deleted. However the command failed >> and the profile is still in the dogtag managed suffix. >> After I've done this to the installed instance, subsequent uninstall >> operation failed on some step involving dogtag. I suspect it is related. >> I haven't been able to reproduce this for now as at the moment there >> was no package with dogtag in the copr repo. >> Reproducer for this is attached. (This reproducer requires patches at >> least up to freeipa-ftweedal-0005-3-Add-certprofile-plugin.patch) >> >> It may be more complicated issue than it seems, though. >> If we delete the ipa managed entry before the dogtag operation >> and this one fails, it leaves us in an inconsistent state. >> If on the other hand we delete the ipa managed entry after dogtag >> call, it opens an possibility of failing to delete the entry in ipa, leading >> to inconsistency again. >> >> The solution to this would be a transaction. The problem here is >> that the transaction here would span through two integrated >> components (three actually, ipa, 389 and dogtag, in this context). >> Not an easy thing to do I assume. >> >> TL;DR: >> >> * certprofile-del deletes ipa managed entry and dogtag doesn't >> * how do we approach possibly irreversible changes in LDAPObject >> plugins when integrated component doesn't behave? >> >> Your thoughts on this? >> > Thanks for the report - certprofile-del was working at an earlier > stage so I will track down the issue and fix. > > I have pondered the transaction requirements: I am managing it for > certprofile-import by deleting the entry if the dogtag import fails. > I suppose I can do a similar thing for certprofile del - keep a copy > of the entry and re-add it if delete fails. Sound OK to you? Yeah, this is what we do in permission-mod post_callback for example. > > Cheers, > Fraser > >> >> Thanks, >> Milan > > From ftweedal at redhat.com Thu May 21 13:47:41 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 21 May 2015 23:47:41 +1000 Subject: [Freeipa-devel] certprofiles -- problem with delete In-Reply-To: <555DDB9E.20701@redhat.com> References: <555DD13E.5060503@redhat.com> <20150521131026.GI12806@dhcp-40-8.bne.redhat.com> <555DDB9E.20701@redhat.com> Message-ID: <20150521134741.GM12806@dhcp-40-8.bne.redhat.com> On Thu, May 21, 2015 at 03:20:30PM +0200, Martin Kosek wrote: > On 05/21/2015 03:10 PM, Fraser Tweedale wrote: > > On Thu, May 21, 2015 at 02:36:14PM +0200, Milan Kubik wrote: > >> Hi Fraser and list, > >> > >> I ran into this when I was tinkering with the commands. > >> > >> The ipa certprofile plugin[s] does not take the backend result into the > >> picture right now. When I tried to delete the *default profile*, the entry > >> from ipa suffix got deleted. However the command failed > >> and the profile is still in the dogtag managed suffix. > >> After I've done this to the installed instance, subsequent uninstall > >> operation failed on some step involving dogtag. I suspect it is related. > >> I haven't been able to reproduce this for now as at the moment there > >> was no package with dogtag in the copr repo. > >> Reproducer for this is attached. (This reproducer requires patches at > >> least up to freeipa-ftweedal-0005-3-Add-certprofile-plugin.patch) > >> > >> It may be more complicated issue than it seems, though. > >> If we delete the ipa managed entry before the dogtag operation > >> and this one fails, it leaves us in an inconsistent state. > >> If on the other hand we delete the ipa managed entry after dogtag > >> call, it opens an possibility of failing to delete the entry in ipa, leading > >> to inconsistency again. > >> > >> The solution to this would be a transaction. The problem here is > >> that the transaction here would span through two integrated > >> components (three actually, ipa, 389 and dogtag, in this context). > >> Not an easy thing to do I assume. > >> > >> TL;DR: > >> > >> * certprofile-del deletes ipa managed entry and dogtag doesn't > >> * how do we approach possibly irreversible changes in LDAPObject > >> plugins when integrated component doesn't behave? > >> > >> Your thoughts on this? > >> > > Thanks for the report - certprofile-del was working at an earlier > > stage so I will track down the issue and fix. > > > > I have pondered the transaction requirements: I am managing it for > > certprofile-import by deleting the entry if the dogtag import fails. > > I suppose I can do a similar thing for certprofile del - keep a copy > > of the entry and re-add it if delete fails. Sound OK to you? > > Yeah, this is what we do in permission-mod post_callback for example. > OK, it is settled; will address in next patchset. Thanks Martin. > > > > Cheers, > > Fraser > > > >> > >> Thanks, > >> Milan > > > > > From mhonek at redhat.com Thu May 21 13:49:49 2015 From: mhonek at redhat.com (Matus Honek) Date: Thu, 21 May 2015 09:49:49 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0368-0371] Support LDAP MODRDN for ordinary DNS records In-Reply-To: <555C3287.3080108@redhat.com> References: <555C3287.3080108@redhat.com> Message-ID: <1743455666.2566787.1432216189715.JavaMail.zimbra@redhat.com> Hello, patches seem to work all right. Thus ACK. Mat?? Hon?k ----- Original Message ----- From: "Petr Spacek" To: thozza at redhat.com, "Matus Honek" Cc: freeipa-devel at redhat.com Sent: Wednesday, May 20, 2015 9:06:47 AM Subject: [PATCH 0368-0371] Support LDAP MODRDN for ordinary DNS records Hello, this patchset implements support for MODRDN for ordinary records. As noted in ticket https://fedorahosted.org/bind-dyndb-ldap/ticket/123, we agreed yesterday that renaming zones is out of scope and seems unnecessarily complex. This patch set depends on 'metadb' branch. It is also available from: https://github.com/pspacek/bind-dyndb-ldap/tree/modrdn Thank you for your time! -- Petr^2 Spacek From pvoborni at redhat.com Thu May 21 14:14:49 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 21 May 2015 16:14:49 +0200 Subject: [Freeipa-devel] proposal: new API command to list IPA servers Message-ID: <555DE859.9070908@redhat.com> Hi all, proposal is to create following two commands: ipa server-find ipa server-show FQDN These commands will display a list of IPA servers stored in cn=masters,cn=ipa,cn=etc,$SUFFIX No mod and add commands atm. They could be added when needed. Installed service won't be shown as well.; Main reasons for adding them are: 1. let people know what they could enter in: ipa topologysegment-add SUFFIX --leftnode=NODE --rightnode=NODE 2. web ui needs this info to offer a list of IPA servers for the same task as in #1 3. it's convenient In Brno, we had an offline discussion about the object name and 'server' was a winner. Other discussed candidates were: topologynode, node, master, replica, topologyserver, managedserver. Server was chosen because: - IPA server is commonly used - works well with other terminology/commands, e.g. ipa-server-install - is not bound to topology (in comparison to replica or master) - is short - works well with future installation of server parts like CA through API Adding Rob and Simo to CC explicitly so they could object if they wish ;) -- Petr Vobornik From rcritten at redhat.com Thu May 21 14:29:10 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 21 May 2015 10:29:10 -0400 Subject: [Freeipa-devel] proposal: new API command to list IPA servers In-Reply-To: <555DE859.9070908@redhat.com> References: <555DE859.9070908@redhat.com> Message-ID: <555DEBB6.8050206@redhat.com> Petr Vobornik wrote: > Hi all, > > proposal is to create following two commands: > > ipa server-find > ipa server-show FQDN > > These commands will display a list of IPA servers stored in > cn=masters,cn=ipa,cn=etc,$SUFFIX > > No mod and add commands atm. They could be added when needed. Installed > service won't be shown as well.; > > Main reasons for adding them are: > > 1. let people know what they could enter in: > ipa topologysegment-add SUFFIX --leftnode=NODE --rightnode=NODE > 2. web ui needs this info to offer a list of IPA servers for the same > task as in #1 > 3. it's convenient > > In Brno, we had an offline discussion about the object name and 'server' > was a winner. Other discussed candidates were: topologynode, node, > master, replica, topologyserver, managedserver. Server was chosen because: > - IPA server is commonly used > - works well with other terminology/commands, e.g. ipa-server-install > - is not bound to topology (in comparison to replica or master) > - is short > - works well with future installation of server parts like CA through API > > Adding Rob and Simo to CC explicitly so they could object if they wish ;) Kudos for including the reasoning. I still lean more towards master but don't object too much to server given the reasoning. My only hesitation to server is that it is a rather generic term but it seems like a CLI user will quickly learn the difference between host and server so it should be ok. +1 rob From ftweedal at redhat.com Thu May 21 14:51:02 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 22 May 2015 00:51:02 +1000 Subject: [Freeipa-devel] [PATCH 0255] Server Upgrade: Fix: executed schema upgrade In-Reply-To: <555DD43F.3060708@redhat.com> References: <555DD43F.3060708@redhat.com> Message-ID: <20150521145102.GP12806@dhcp-40-8.bne.redhat.com> On Thu, May 21, 2015 at 02:49:03PM +0200, Martin Basti wrote: > Accidentaly , schema upgrade hasn't beed executed by ipa-server-upgrade. > > https://fedorahosted.org/freeipa/ticket/4904 > > Patch attached. > > -- > Martin Basti > ACK; the schema changes once again are applied during upgrade. Thanks, Fraser > From d6b1107aa9f952bf61dbdbaabdbab822d0dc69b5 Mon Sep 17 00:00:00 2001 > From: Martin Basti > Date: Thu, 21 May 2015 14:40:22 +0200 > Subject: [PATCH] Server Upgrade: Fix: execute schema update > > Accidentaly schema upgrade has not been executed. > > https://fedorahosted.org/freeipa/ticket/4904 > --- > ipaserver/install/ipa_server_upgrade.py | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/ipaserver/install/ipa_server_upgrade.py b/ipaserver/install/ipa_server_upgrade.py > index 7e85c0dca042614b3e591d87f8687314ae3981cb..6236e2ed033708189ad10c184fd8e57a0b34953b 100644 > --- a/ipaserver/install/ipa_server_upgrade.py > +++ b/ipaserver/install/ipa_server_upgrade.py > @@ -2,6 +2,7 @@ > # Copyright (C) 2015 FreeIPA Contributors see COPYING for license > # > > +import os > import sys > > import krbV > @@ -9,6 +10,7 @@ import krbV > from ipalib import api > from ipaplatform.paths import paths > from ipapython import admintool, ipautil > +from ipaserver.install import dsinstance > from ipaserver.install import installutils > from ipaserver.install.upgradeinstance import IPAUpgrade > from ipaserver.install.ldapupdate import BadSyntax > @@ -73,7 +75,9 @@ class ServerUpgrade(admintool.AdminTool): > "system") > > realm = krbV.default_context().default_realm > - data_upgrade = IPAUpgrade(realm) > + schema_files = [os.path.join(ipautil.SHARE_DIR, f) for f > + in dsinstance.ALL_SCHEMA_FILES] > + data_upgrade = IPAUpgrade(realm, schema_files=schema_files) > > try: > data_upgrade.create_instance() > -- > 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 From ftweedal at redhat.com Thu May 21 14:52:20 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 22 May 2015 00:52:20 +1000 Subject: [Freeipa-devel] [PATCHES 0001-0011 v3] Profile management In-Reply-To: <555DD39C.3070103@redhat.com> References: <5555E63D.4050808@redhat.com> <555AF9E1.1010606@redhat.com> <20150519115027.GA12806@dhcp-40-8.bne.redhat.com> <555C1E5C.2080707@redhat.com> <20150520055636.GF12806@dhcp-40-8.bne.redhat.com> <555C30FE.4030707@redhat.com> <20150520144106.GH12806@dhcp-40-8.bne.redhat.com> <555DCC96.2050001@redhat.com> <555DD031.8070302@redhat.com> <555DD39C.3070103@redhat.com> Message-ID: <20150521145220.GQ12806@dhcp-40-8.bne.redhat.com> On Thu, May 21, 2015 at 02:46:20PM +0200, Martin Basti wrote: > On 21/05/15 14:31, Martin Basti wrote: > >On 21/05/15 14:16, Martin Basti wrote: > >>On 20/05/15 16:41, Fraser Tweedale wrote: > >>>Hi Honza, Martin et al, > >>> > >>>Latest patches attached. On top of previous patches (most review > >>>matters addressed**) patches 0008..0011 add support for profiles and > >>>user certificates to `ipa cert-request'. > >>> > >>>** those that were not are being tracked at [1]; please add anything > >>> I missed. > >>> > >>>Some points to note: > >>> > >>>- usercertificate is not yet a multi-valued attribute for users, > >>> hosts and services. > >>> > >>> QUESTION - we do want to allow multiple certificates for all > >>> principal types, not just users? Or have I got that wrong. > >>> > >>>- "DN and SAN match principal" checks are not implemented for users > >>> yet. > >>> > >>>- ACL was added to allow user principals to request their own > >>> certificates, however, this will be further subject to CA/profile > >>> ACLs which are to come. > >>> > >>>- Pursuant to [2] revocation logic was removed from `cert-request' > >>> > >>>[1] http://idm.etherpad.corp.redhat.com/rhel72-cert-mgmt-progress > >>>[2] http://www.freeipa.org/page/V4/User_Certificates#Revocation_of_the_Certificates > >>> > >>>Thanks, > >>>Fraser > >>I tried upgrade and: > >> > >>Updating managed permissions for certprofile > >>Upgrade failed with targetattr "ipacertprofilestoreissued" does not > >>exist in schema. Please add attributeTypes "ipacertprofilestoreissued" > >>to schema if necessary. ACL Syntax Error(-5):(targetattr = \22cn || > >>description || ipacertprofilestoreissued\22)(targetfilter = > >>\22(objectclass=ipacertprofile)\22)(version 3.0;acl > >>\22permission:System: Modify Certificate Profile\22;allow (write) > >>groupdn = \22ldap:///cn=System: Modify Certificate Profile,cn=permissions,cn=pbac,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com\22;): > >>Invalid syntax. > >> [error] RuntimeError: targetattr "ipacertprofilestoreissued" does not > >>exist in schema. Please add attributeTypes "ipacertprofilestoreissued" > >>to schema if necessary. ACL Syntax Error(-5):(targetattr = \22cn || > >>description || ipacertprofilestoreissued\22)(targetfilter = > >>\22(objectclass=ipacertprofile)\22)(version 3.0;acl > >>\22permission:System: Modify Certificate Profile\22;allow (write) > >>groupdn = \22ldap:///cn=System: Modify Certificate Profile,cn=permissions,cn=pbac,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com\22;): > >>Invalid syntax. > >> [cleanup]: stopping directory server > >> [cleanup]: restoring configuration > >> > >>I cannot find the "ipacertprofilestoreissued" in any IPA schema file. > >> > >>Did I miss something? > >> > >> > >Sorry, I found it, stupid me. > >I will investigate why upgrade failed then. > > > > Bug in ipa-server-upgrade, thank you to find this issue :-) > And thanks for the fix! There are still some issues with upgrade; I will address in next patch set. > -- > Martin Basti > From mbasti at redhat.com Thu May 21 15:33:11 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 21 May 2015 17:33:11 +0200 Subject: [Freeipa-devel] [PATCHES 0001-0011 v3] Profile management In-Reply-To: <20150520144106.GH12806@dhcp-40-8.bne.redhat.com> References: <555305EC.5020001@redhat.com> <55530D23.5040702@redhat.com> <55530DDB.9000101@redhat.com> <20150515082420.GR12806@dhcp-40-8.bne.redhat.com> <5555E63D.4050808@redhat.com> <555AF9E1.1010606@redhat.com> <20150519115027.GA12806@dhcp-40-8.bne.redhat.com> <555C1E5C.2080707@redhat.com> <20150520055636.GF12806@dhcp-40-8.bne.redhat.com> <555C30FE.4030707@redhat.com> <20150520144106.GH12806@dhcp-40-8.bne.redhat.com> Message-ID: <555DFAB7.3080303@redhat.com> On 20/05/15 16:41, Fraser Tweedale wrote: > Hi Honza, Martin et al, > > Latest patches attached. On top of previous patches (most review > matters addressed**) patches 0008..0011 add support for profiles and > user certificates to `ipa cert-request'. > > ** those that were not are being tracked at [1]; please add anything > I missed. > > Some points to note: > > - usercertificate is not yet a multi-valued attribute for users, > hosts and services. > > QUESTION - we do want to allow multiple certificates for all > principal types, not just users? Or have I got that wrong. Changing schema can cause issues in future, we already burn ourselves several times. If you plan to have multi valued attribute in close future, could be better to have mutltivalued schema now, instead of make this change in future? > > - "DN and SAN match principal" checks are not implemented for users > yet. > > - ACL was added to allow user principals to request their own > certificates, however, this will be further subject to CA/profile > ACLs which are to come. > > - Pursuant to [2] revocation logic was removed from `cert-request' > > [1] http://idm.etherpad.corp.redhat.com/rhel72-cert-mgmt-progress > [2] http://www.freeipa.org/page/V4/User_Certificates#Revocation_of_the_Certificates > > Thanks, > Fraser > Thanks for updated patches: Please update required pki version in freeipa.spec.in Patch 0001: Again, will be this change done after upgrade, instead of new installation? config.set("CA", "pki_profiles_in_ldap", "True") I blame method 'ca_enable_ldap_profile_subsystem' in upgrade to do this, but I'm not sure. Patch 0005: 1) just nitpick: profile_id_pattern = re.compile('^[a-zA-Z]\w*$') PROFILE_ID_PATTERN = re.compile('^profileId=(\w+)', re.MULTILINE) In PROFILE_ID_PATTERN should be '^profileId=([a-zA-Z]\w*)' to be consistent Patch 0007: There are still modifications in ipa-server-isntall Patch 0010: 1) +aci: (targetattr = "usercertificate")(version 3.0;acl "selfservice:Users can manage their own X.509 certificates";allow (write) userdn = "ldap:///self";) This is not in any upgrade file 2) +# User certificates +dn: $SUFFIX +add:aci:(targetattr = "ipasshpubkey")(version 3.0;acl "selfservice:Users can manage their own X.509 certificates";allow (write) userdn = "ldap:///self";) Is this right? (ipasshpubkey) This ACI with different name is already there. 3) IMO this should not be there. 'replaces': [ - '(targetattr = "givenname || sn || cn || displayname || title || initials || loginshell || gecos || homephone || mobile || pager || facsimiletelephonenumber || telephonenumber || street || roomnumber || l || st || postalcode || manager || secretary || description || carlicense || labeleduri || inetuserhttpurl || seealso || employeetype || businesscategory || ou || mepmanagedentry || objectclass")(target = "ldap:///uid=*,cn=users,cn=accounts,$SUFFIX")(version 3.0;acl "permission:Modify Users";allow (write) groupdn = "ldap:///cn=Modify Users,cn=permissions,cn=pbac,$SUFFIX";)', + '(targetattr = "givenname || sn || cn || displayname || title || initials || loginshell || gecos || homephone || mobile || pager || facsimiletelephonenumber || telephonenumber || street || roomnumber || l || st || postalcode || manager || secretary || description || carlicense || labeleduri || inetuserhttpurl || seealso || employeetype || businesscategory || usercertificate || ou || mepmanagedentry || objectclass")(target = "ldap:///uid=*,cn=users,cn=accounts,$SUFFIX")(version 3.0;acl "permission:Modify Users";allow (write) groupdn = "ldap:///cn=Modify Users,cn=permissions,cn=pbac,$SUFFIX";)', ], this replace replaces permissions written in old style. New permission are updated automaticaly (AFAIK) PAtch 0011: Please dont use '_' in code, this is for ugettext and may cause an issue in future + bind_service, _, _ = bind_principal Martin^2 -- Martin Basti From edewata at redhat.com Thu May 21 15:45:04 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 21 May 2015 10:45:04 -0500 Subject: [Freeipa-devel] [PATCH] Password vault In-Reply-To: <555C2F4F.4080406@redhat.com> References: <54E1AF55.3060409@redhat.com> <54EBEB55.6010306@redhat.com> <54F96B22.9050507@redhat.com> <55004D5D.6060300@redhat.com> <550FE5EB.1070606@redhat.com> <551E0AE1.8040500@redhat.com> <553498D1.1020901@redhat.com> <5551DB57.6060504@redhat.com> <555314D1.6070304@redhat.com> <55541015.3040206@redhat.com> <5554ECAE.8030908@redhat.com> <55553B0A.10800@redhat.com> <555A3ACF.3000305@redhat.com> <555AF3EC.1060100@redhat.com> <555B4B40.1060702@redhat.com> <555C2F4F.4080406@redhat.com> Message-ID: <555DFD80.6020909@redhat.com> Please take a look at the new patch. On 5/20/2015 1:53 AM, Jan Cholasta wrote: >> I suppose you meant you're OK with not adding host vaults now? > > Yes. > >> 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/@, 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. > > The reason is consistency. Private vaults should be available for all > identities, because anything else would be an arbitrary limitation > (which is not elegant). If private vaults were available for all > identities, we would need a container for host vaults. I'm not saying > the container has to be added now, but there should at least be a check > to reject requests when the authenticated identity is a host (i.e. > context.principal.startswith('host/')). In the previous patch, since a host was considered a service it could have private vaults too. But anyway, I added the code to reject host principals as you requested. >>>>> 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? > > I don't think there is a ticket for this particular issue. Added TODOs in the code. >>>> 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. > > Thanks for understanding. Changed the code as requested. >> There is an obvious inefficiency here: all containers in the path >> (including the built-in ones) will be re-added on every vault-add >> operation. >> >> I don't see anything wrong with recursions, especially if it works more >> efficiently since only the immediate parent will be re-added. > > I tend to stick to the "don't use recursion in production code" rule, > epsecially in simple cases like this one. I think the rule is kind of misguided. Recursion might be considered bad if it goes very deep thus consuming so much stack space, which is not the case here given the short and flat tree topology. Or, if it's unnecessary such as a tail-recursion, which is not the case here either. >> So for example, with the loop every time you add a private vault you're >> guaranteed to have three failed LDAP Add operations whereas with the >> recursion there's only one failed operation. > > This is not about loop vs. recursion, this is about the used approach. > Your code can be easily transformed into a loop while keeping the same > approach: > > entries = [] > > while dn: > assert dn.endswith(self.base_dn) > > rdn = dn[0] > entry = self.backend.make_entry( > dn, > { > 'objectclass': ['nsContainer'], > 'cn': rdn['cn'], > }) > > # if entry can be added, return > try: > self.backend.add_entry(entry) > break > > except errors.NotFound: > pass > > # otherwise, create parent entry first > dn = DN(*dn[1:]) > entries.insert(0, entry) > > for entry in entries: > # then create the entry itself again > self.backend.add_entry(entry) > >> >> Do you still want to use the loop? > > Yes please. This algorithm is recursive by nature (start at the bottom, but add the parent first). The above code basically emulates recursion with two loops and an explicit stack of entries, but the memory requirement is pretty much the same because it's still using a stack. With real recursion there is no loops and the stack is implicit, so the code is at least cleaner. If you really want to avoid recursion you probably should use an RDN iterator instead of a stack, but the code would be either even uglier or less efficient. Anyway, it's not a big deal, I included this change. -- Endi S. Dewata -------------- next part -------------- >From cc738ccba3cba23d83b9a6f459d4ea6bcf7c341d Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Tue, 21 Oct 2014 10:57:08 -0400 Subject: [PATCH] Added vault plugin. A new plugin has been added to manage vaults. Test scripts have also been added to verify the functionality. https://fedorahosted.org/freeipa/ticket/3872 --- API.txt | 74 +++++ VERSION | 4 +- install/share/60basev3.ldif | 1 + install/updates/40-vault.update | 19 ++ install/updates/Makefile.am | 1 + ipa-client/man/default.conf.5 | 1 + ipalib/constants.py | 1 + ipalib/plugins/vault.py | 321 +++++++++++++++++++++ ipatests/test_xmlrpc/test_vault_plugin.py | 445 ++++++++++++++++++++++++++++++ 9 files changed, 865 insertions(+), 2 deletions(-) create mode 100644 install/updates/40-vault.update create mode 100644 ipalib/plugins/vault.py create mode 100644 ipatests/test_xmlrpc/test_vault_plugin.py diff --git a/API.txt b/API.txt index 0808f3c64595495c8a9e60da5cbd689d5cdc6224..38deafefa57942bf242f989d79b1e93ee2c2013e 100644 --- a/API.txt +++ b/API.txt @@ -4717,6 +4717,80 @@ option: Str('version?', exclude='webui') output: Output('result', , None) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) +command: vault_add +args: 1,9,3 +arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[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: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('service?') +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: Flag('shared?', autofill=True, default=False) +option: Str('user?') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault_del +args: 1,5,3 +arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=True, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Flag('continue', autofill=True, cli_name='continue', default=False) +option: Str('service?') +option: Flag('shared?', autofill=True, default=False) +option: Str('user?') +option: Str('version?', exclude='webui') +output: Output('result', , None) +output: Output('summary', (, ), None) +output: ListOfPrimaryKeys('value', None, None) +command: vault_find +args: 1,11,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='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=False) +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, query=True, required=False) +option: Flag('pkey_only?', autofill=True, default=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('service?') +option: Flag('shared?', autofill=True, default=False) +option: Int('sizelimit?', autofill=False, minvalue=0) +option: Int('timelimit?', autofill=False, minvalue=0) +option: Str('user?') +option: Str('version?', exclude='webui') +output: Output('count', , None) +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('truncated', , None) +command: vault_mod +args: 1,11,3 +arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('delattr*', cli_name='delattr', exclude='webui') +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('service?') +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: Flag('shared?', autofill=True, default=False) +option: Str('user?') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault_show +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[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('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('service?') +option: Flag('shared?', autofill=True, default=False) +option: Str('user?') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) capability: messages 2.52 capability: optional_uid_params 2.54 capability: permissions2 2.69 diff --git a/VERSION b/VERSION index c207558504e645dec73d105189d4b862877b4e26..33e7bebe4c673279ae92395a2575dc11e9fd4956 100644 --- a/VERSION +++ b/VERSION @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 # # ######################################################## IPA_API_VERSION_MAJOR=2 -IPA_API_VERSION_MINOR=118 -# Last change: tbordaz - Add stageuser_find, stageuser_mod, stageuser_del, stageuser_show +IPA_API_VERSION_MINOR=119 +# Last change: edewata - Added vault plugin diff --git a/install/share/60basev3.ldif b/install/share/60basev3.ldif index eb1c1298b9de3295695745ba3311bb772dec70e9..33f4804e30ff1b3814ecf295bb41f07e2a8cd12f 100644 --- a/install/share/60basev3.ldif +++ b/install/share/60basev3.ldif @@ -79,3 +79,4 @@ objectClasses: (2.16.840.1.113730.3.8.12.24 NAME 'ipaPublicKeyObject' DESC 'Wrap objectClasses: (2.16.840.1.113730.3.8.12.25 NAME 'ipaPrivateKeyObject' DESC 'Wrapped private keys' SUP top AUXILIARY MUST ( ipaPrivateKey $ ipaWrappingKey $ ipaWrappingMech ) X-ORIGIN 'IPA v4.1' ) objectClasses: (2.16.840.1.113730.3.8.12.26 NAME 'ipaSecretKeyObject' DESC 'Wrapped secret keys' SUP top AUXILIARY MUST ( ipaSecretKey $ ipaWrappingKey $ ipaWrappingMech ) X-ORIGIN 'IPA v4.1' ) objectClasses: (2.16.840.1.113730.3.8.12.34 NAME 'ipaSecretKeyRefObject' DESC 'Indirect storage for encoded key material' SUP top AUXILIARY MUST ( ipaSecretKeyRef ) X-ORIGIN 'IPA v4.1' ) +objectClasses: (2.16.840.1.113730.3.8.18.1.1 NAME 'ipaVault' DESC 'IPA vault' SUP top STRUCTURAL MUST ( cn ) MAY ( description ) X-ORIGIN 'IPA v4.2' ) diff --git a/install/updates/40-vault.update b/install/updates/40-vault.update new file mode 100644 index 0000000000000000000000000000000000000000..5a6b8c6a022fa56e5a5bc05369ce143d39644092 --- /dev/null +++ b/install/updates/40-vault.update @@ -0,0 +1,19 @@ +dn: cn=vaults,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: cn: vaults + +dn: cn=services,cn=vaults,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: cn: services + +dn: cn=shared,cn=vaults,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: cn: shared + +dn: cn=users,cn=vaults,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: cn: users diff --git a/install/updates/Makefile.am b/install/updates/Makefile.am index 0d63d9ea8d85f1add5f036e7a39f89543586d33b..66f6b9d37971f8b8501d73fc6ddca21b6686ff4b 100644 --- a/install/updates/Makefile.am +++ b/install/updates/Makefile.am @@ -33,6 +33,7 @@ app_DATA = \ 40-dns.update \ 40-automember.update \ 40-otp.update \ + 40-vault.update \ 45-roles.update \ 50-7_bit_check.update \ 50-dogtag10-migration.update \ diff --git a/ipa-client/man/default.conf.5 b/ipa-client/man/default.conf.5 index dbc8a5b4647439de4de7c01152d098eb0561e236..0973f1a07179ad64daa326a02803cdc9ba1870aa 100644 --- a/ipa-client/man/default.conf.5 +++ b/ipa-client/man/default.conf.5 @@ -221,6 +221,7 @@ The following define the containers for the IPA server. Containers define where container_sudocmdgroup: cn=sudocmdgroups,cn=sudo container_sudorule: cn=sudorules,cn=sudo container_user: cn=users,cn=accounts + container_vault: cn=vaults container_virtual: cn=virtual operations,cn=etc .SH "FILES" diff --git a/ipalib/constants.py b/ipalib/constants.py index f1e14702ffdf5a3bd23a62b1fdd2ee3cd95d84f8..195938a355d1b24c02aa0a5833c1725c76e85c76 100644 --- a/ipalib/constants.py +++ b/ipalib/constants.py @@ -99,6 +99,7 @@ DEFAULT_CONFIG = ( ('container_hbacservice', DN(('cn', 'hbacservices'), ('cn', 'hbac'))), ('container_hbacservicegroup', DN(('cn', 'hbacservicegroups'), ('cn', 'hbac'))), ('container_dns', DN(('cn', 'dns'))), + ('container_vault', DN(('cn', 'vaults'))), ('container_virtual', DN(('cn', 'virtual operations'), ('cn', 'etc'))), ('container_sudorule', DN(('cn', 'sudorules'), ('cn', 'sudo'))), ('container_sudocmd', DN(('cn', 'sudocmds'), ('cn', 'sudo'))), diff --git a/ipalib/plugins/vault.py b/ipalib/plugins/vault.py new file mode 100644 index 0000000000000000000000000000000000000000..ebb9f9fd3cf3b5a7d6b44ac9e63e122e8f71aa1a --- /dev/null +++ b/ipalib/plugins/vault.py @@ -0,0 +1,321 @@ +# Authors: +# Endi S. Dewata +# +# Copyright (C) 2015 Red Hat +# see file 'COPYING' for use and warranty information +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation, either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see . + +from ipalib import api, errors +from ipalib import Str, Flag +from ipalib import output +from ipalib.plugable import Registry +from ipalib.plugins.baseldap import LDAPObject, LDAPCreate, LDAPDelete,\ + LDAPSearch, LDAPUpdate, LDAPRetrieve +from ipalib.request import context +from ipalib.plugins.user import split_principal +from ipalib import _, ngettext +from ipapython.dn import DN + +__doc__ = _(""" +Vaults +""") + _(""" +Manage vaults. +""") + _(""" +EXAMPLES: +""") + _(""" + List private vaults: + ipa vault-find +""") + _(""" + List service vaults: + ipa vault-find --service +""") + _(""" + List shared vaults: + ipa vault-find --shared +""") + _(""" + List user vaults: + ipa vault-find --user +""") + _(""" + Add a private vault: + ipa vault-add +""") + _(""" + Add a service vault: + ipa vault-add --service +""") + _(""" + Add a shared vault: + ipa vault-add --shared +""") + _(""" + Add a user vault: + ipa vault-add --user +""") + _(""" + Show a private vault: + ipa vault-show +""") + _(""" + Show a service vault: + ipa vault-show --service +""") + _(""" + Show a shared vault: + ipa vault-show --shared +""") + _(""" + Show a user vault: + ipa vault-show --user +""") + _(""" + Modify a private vault: + ipa vault-mod --desc +""") + _(""" + Modify a service vault: + ipa vault-mod --service --desc +""") + _(""" + Modify a shared vault: + ipa vault-mod --shared --desc +""") + _(""" + Modify a user vault: + ipa vault-mod --user --desc +""") + _(""" + Delete a private vault: + ipa vault-del +""") + _(""" + Delete a service vault: + ipa vault-del --service +""") + _(""" + Delete a shared vault: + ipa vault-del --shared +""") + _(""" + Delete a user vault: + ipa vault-del --user +""") + +register = Registry() + + +vault_options = ( + Str( + 'service?', + doc=_('Service name'), + ), + Flag( + 'shared?', + doc=_('Shared vault'), + ), + Str( + 'user?', + doc=_('Username'), + ), +) + + + at register() +class vault(LDAPObject): + __doc__ = _(""" + Vault object. + """) + + container_dn = api.env.container_vault + + object_name = _('vault') + object_name_plural = _('vaults') + + object_class = ['ipaVault'] + default_attributes = [ + 'cn', + 'description', + ] + + label = _('Vaults') + label_singular = _('Vault') + + takes_params = ( + Str( + 'cn', + cli_name='name', + label=_('Vault name'), + primary_key=True, + pattern='^[a-zA-Z0-9_.-]+$', + pattern_errmsg='may only include letters, numbers, _, ., and -', + maxlength=255, + ), + Str( + 'description?', + cli_name='desc', + label=_('Description'), + doc=_('Vault description'), + ), + ) + + def get_dn(self, *keys, **options): + """ + Generates vault DN from parameters. + """ + + service = options.get('service') + shared = options.get('shared') + user = options.get('user') + + count = 0 + if service: + count += 1 + + if shared: + count += 1 + + if user: + count += 1 + + if count > 1: + raise errors.MutuallyExclusiveError( + reason=_('Service, shared, and user options ' + + 'cannot be specified simultaneously')) + + # TODO: create container_dn after object initialization then reuse it + container_dn = DN(self.container_dn, self.api.env.basedn) + + dn = super(vault, self).get_dn(*keys, **options) + assert dn.endswith(container_dn) + rdns = DN(*dn[:-len(container_dn)]) + + if not count: + principal = getattr(context, 'principal') + + if principal.startswith('host/'): + raise errors.NotImplementedError( + reason=_('Host is not supported')) + + (name, realm) = split_principal(principal) + if '/' in name: + service = name + else: + user = name + + if service: + parent_dn = DN(('cn', service), ('cn', 'services'), container_dn) + elif shared: + parent_dn = DN(('cn', 'shared'), container_dn) + else: + parent_dn = DN(('cn', user), ('cn', 'users'), container_dn) + + return DN(rdns, parent_dn) + + def create_container(self, dn): + """ + Creates vault container and its parents. + """ + + # TODO: create container_dn after object initialization then reuse it + container_dn = DN(self.container_dn, self.api.env.basedn) + + entries = [] + + while dn: + assert dn.endswith(container_dn) + + rdn = dn[0] + entry = self.backend.make_entry( + dn, + { + 'objectclass': ['nsContainer'], + 'cn': rdn['cn'], + }) + + # if entry can be added, return + try: + self.backend.add_entry(entry) + break + + except errors.NotFound: + pass + + # otherwise, create parent entry first + dn = DN(*dn[1:]) + entries.insert(0, entry) + + # then create the entries again + for entry in entries: + self.backend.add_entry(entry) + + + at register() +class vault_add(LDAPCreate): + __doc__ = _('Create a new vault.') + + takes_options = LDAPCreate.takes_options + vault_options + + msg_summary = _('Added vault "%(value)s"') + + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, + **options): + assert isinstance(dn, DN) + + try: + parent_dn = DN(*dn[1:]) + self.obj.create_container(parent_dn) + except errors.DuplicateEntry, e: + pass + + return dn + + + at register() +class vault_del(LDAPDelete): + __doc__ = _('Delete a vault.') + + takes_options = LDAPDelete.takes_options + vault_options + + msg_summary = _('Deleted vault "%(value)s"') + + + at register() +class vault_find(LDAPSearch): + __doc__ = _('Search for vaults.') + + takes_options = LDAPSearch.takes_options + vault_options + + msg_summary = ngettext( + '%(count)d vault matched', + '%(count)d vaults matched', + 0, + ) + + def pre_callback(self, ldap, filter, attrs_list, base_dn, scope, *args, + **options): + assert isinstance(base_dn, DN) + + base_dn = self.obj.get_dn(*args, **options) + + return (filter, base_dn, scope) + + def exc_callback(self, args, options, exc, call_func, *call_args, + **call_kwargs): + if call_func.__name__ == 'find_entries': + if isinstance(exc, errors.NotFound): + # ignore missing containers since they will be created + # automatically on vault creation. + raise errors.EmptyResult(reason=str(exc)) + + raise exc + + + at register() +class vault_mod(LDAPUpdate): + __doc__ = _('Modify a vault.') + + takes_options = LDAPUpdate.takes_options + vault_options + + msg_summary = _('Modified vault "%(value)s"') + + + at register() +class vault_show(LDAPRetrieve): + __doc__ = _('Display information about a vault.') + + takes_options = LDAPRetrieve.takes_options + vault_options diff --git a/ipatests/test_xmlrpc/test_vault_plugin.py b/ipatests/test_xmlrpc/test_vault_plugin.py new file mode 100644 index 0000000000000000000000000000000000000000..44d397c583928d98ec252899398ae6c3a83c207c --- /dev/null +++ b/ipatests/test_xmlrpc/test_vault_plugin.py @@ -0,0 +1,445 @@ +# Authors: +# Endi S. Dewata +# +# Copyright (C) 2015 Red Hat +# see file 'COPYING' for use and warranty information +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation, either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see . + +""" +Test the `ipalib/plugins/vault.py` module. +""" + +from ipalib import api, errors +from xmlrpc_test import Declarative, fuzzy_string + +vault_name = u'test_vault' +service_name = u'HTTP/server.example.com' +user_name = u'testuser' + + +class test_vault_plugin(Declarative): + + cleanup_commands = [ + ('vault_del', [vault_name], {'continue': True}), + ('vault_del', [vault_name], { + 'service': service_name, + 'continue': True + }), + ('vault_del', [vault_name], {'shared': True, 'continue': True}), + ('vault_del', [vault_name], {'user': user_name, 'continue': True}), + ] + + tests = [ + + { + 'desc': 'Create private vault', + 'command': ( + 'vault_add', + [vault_name], + {}, + ), + 'expected': { + 'value': vault_name, + 'summary': 'Added vault "%s"' % vault_name, + 'result': { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,%s' + % (vault_name, api.env.basedn), + 'objectclass': [u'top', u'ipaVault'], + 'cn': [vault_name], + }, + }, + }, + + { + 'desc': 'Find private vaults', + 'command': ( + 'vault_find', + [], + {}, + ), + 'expected': { + 'count': 1, + 'truncated': False, + 'summary': u'1 vault matched', + 'result': [ + { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,%s' + % (vault_name, api.env.basedn), + 'cn': [vault_name], + }, + ], + }, + }, + + { + 'desc': 'Show private vault', + 'command': ( + 'vault_show', + [vault_name], + {}, + ), + 'expected': { + 'value': vault_name, + 'summary': None, + 'result': { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,%s' + % (vault_name, api.env.basedn), + 'cn': [vault_name], + }, + }, + }, + + { + 'desc': 'Modify private vault', + 'command': ( + 'vault_mod', + [vault_name], + { + 'description': u'Test vault', + }, + ), + 'expected': { + 'value': vault_name, + 'summary': u'Modified vault "%s"' % vault_name, + 'result': { + 'cn': [vault_name], + 'description': [u'Test vault'], + }, + }, + }, + + { + 'desc': 'Delete private vault', + 'command': ( + 'vault_del', + [vault_name], + {}, + ), + 'expected': { + 'value': [vault_name], + 'summary': u'Deleted vault "%s"' % vault_name, + 'result': { + 'failed': (), + }, + }, + }, + + { + 'desc': 'Create service vault', + 'command': ( + 'vault_add', + [vault_name], + { + 'service': service_name, + }, + ), + 'expected': { + 'value': vault_name, + 'summary': u'Added vault "%s"' % vault_name, + 'result': { + 'dn': u'cn=%s,cn=%s,cn=services,cn=vaults,%s' + % (vault_name, service_name, api.env.basedn), + 'objectclass': [u'top', u'ipaVault'], + 'cn': [vault_name], + }, + }, + }, + + { + 'desc': 'Find service vaults', + 'command': ( + 'vault_find', + [], + { + 'service': service_name, + }, + ), + 'expected': { + 'count': 1, + 'truncated': False, + 'summary': u'1 vault matched', + 'result': [ + { + 'dn': u'cn=%s,cn=%s,cn=services,cn=vaults,%s' + % (vault_name, service_name, api.env.basedn), + 'cn': [vault_name], + }, + ], + }, + }, + + { + 'desc': 'Show service vault', + 'command': ( + 'vault_show', + [vault_name], + { + 'service': service_name, + }, + ), + 'expected': { + 'value': vault_name, + 'summary': None, + 'result': { + 'dn': u'cn=%s,cn=%s,cn=services,cn=vaults,%s' + % (vault_name, service_name, api.env.basedn), + 'cn': [vault_name], + }, + }, + }, + + { + 'desc': 'Modify service vault', + 'command': ( + 'vault_mod', + [vault_name], + { + 'service': service_name, + 'description': u'Test vault', + }, + ), + 'expected': { + 'value': vault_name, + 'summary': u'Modified vault "%s"' % vault_name, + 'result': { + 'cn': [vault_name], + 'description': [u'Test vault'], + }, + }, + }, + + { + 'desc': 'Delete service vault', + 'command': ( + 'vault_del', + [vault_name], + { + 'service': service_name, + }, + ), + 'expected': { + 'value': [vault_name], + 'summary': u'Deleted vault "%s"' % vault_name, + 'result': { + 'failed': (), + }, + }, + }, + + { + 'desc': 'Create shared vault', + 'command': ( + 'vault_add', + [vault_name], + { + 'shared': True + }, + ), + 'expected': { + 'value': vault_name, + 'summary': u'Added vault "%s"' % vault_name, + 'result': { + 'dn': u'cn=%s,cn=shared,cn=vaults,%s' + % (vault_name, api.env.basedn), + 'objectclass': [u'top', u'ipaVault'], + 'cn': [vault_name], + }, + }, + }, + + { + 'desc': 'Find shared vaults', + 'command': ( + 'vault_find', + [], + { + 'shared': True + }, + ), + 'expected': { + 'count': 1, + 'truncated': False, + 'summary': u'1 vault matched', + 'result': [ + { + 'dn': u'cn=%s,cn=shared,cn=vaults,%s' + % (vault_name, api.env.basedn), + 'cn': [vault_name], + }, + ], + }, + }, + + { + 'desc': 'Show shared vault', + 'command': ( + 'vault_show', + [vault_name], + { + 'shared': True + }, + ), + 'expected': { + 'value': vault_name, + 'summary': None, + 'result': { + 'dn': u'cn=%s,cn=shared,cn=vaults,%s' + % (vault_name, api.env.basedn), + 'cn': [vault_name], + }, + }, + }, + + { + 'desc': 'Modify shared vault', + 'command': ( + 'vault_mod', + [vault_name], + { + 'shared': True, + 'description': u'Test vault', + }, + ), + 'expected': { + 'value': vault_name, + 'summary': u'Modified vault "%s"' % vault_name, + 'result': { + 'cn': [vault_name], + 'description': [u'Test vault'], + }, + }, + }, + + { + 'desc': 'Delete shared vault', + 'command': ( + 'vault_del', + [vault_name], + { + 'shared': True + }, + ), + 'expected': { + 'value': [vault_name], + 'summary': u'Deleted vault "%s"' % vault_name, + 'result': { + 'failed': (), + }, + }, + }, + + { + 'desc': 'Create user vault', + 'command': ( + 'vault_add', + [vault_name], + { + 'user': user_name, + }, + ), + 'expected': { + 'value': vault_name, + 'summary': u'Added vault "%s"' % vault_name, + 'result': { + 'dn': u'cn=%s,cn=%s,cn=users,cn=vaults,%s' + % (vault_name, user_name, api.env.basedn), + 'objectclass': [u'top', u'ipaVault'], + 'cn': [vault_name], + }, + }, + }, + + { + 'desc': 'Find user vaults', + 'command': ( + 'vault_find', + [], + { + 'user': user_name, + }, + ), + 'expected': { + 'count': 1, + 'truncated': False, + 'summary': u'1 vault matched', + 'result': [ + { + 'dn': u'cn=%s,cn=%s,cn=users,cn=vaults,%s' + % (vault_name, user_name, api.env.basedn), + 'cn': [vault_name], + }, + ], + }, + }, + + { + 'desc': 'Show user vault', + 'command': ( + 'vault_show', + [vault_name], + { + 'user': user_name, + }, + ), + 'expected': { + 'value': vault_name, + 'summary': None, + 'result': { + 'dn': u'cn=%s,cn=%s,cn=users,cn=vaults,%s' + % (vault_name, user_name, api.env.basedn), + 'cn': [vault_name], + }, + }, + }, + + { + 'desc': 'Modify user vault', + 'command': ( + 'vault_mod', + [vault_name], + { + 'user': user_name, + 'description': u'Test vault', + }, + ), + 'expected': { + 'value': vault_name, + 'summary': u'Modified vault "%s"' % vault_name, + 'result': { + 'cn': [vault_name], + 'description': [u'Test vault'], + }, + }, + }, + + { + 'desc': 'Delete user vault', + 'command': ( + 'vault_del', + [vault_name], + { + 'user': user_name, + }, + ), + 'expected': { + 'value': [vault_name], + 'summary': u'Deleted vault "%s"' % vault_name, + 'result': { + 'failed': (), + }, + }, + }, + + ] -- 1.9.3 From tbabej at redhat.com Thu May 21 16:18:58 2015 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 21 May 2015 18:18:58 +0200 Subject: [Freeipa-devel] [PATCH 0325] Add Domain Level feature In-Reply-To: <555B43BB.90404@redhat.com> References: <5554643E.4030600@redhat.com> <55546F6C.4060108@redhat.com> <555B390B.6000907@redhat.com> <555B3C61.7080508@redhat.com> <555B3F67.3040604@redhat.com> <555B3FFE.5040806@redhat.com> <555B4112.202@redhat.com> <555B41C8.7070503@redhat.com> <555B43BB.90404@redhat.com> Message-ID: <555E0572.8000600@redhat.com> On 05/19/2015 04:07 PM, Tomas Babej wrote: > > > 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 A new iteration of the patch, including the server-side checks for the installers. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0325-5-Add-Domain-Level-feature.patch Type: text/x-patch Size: 21146 bytes Desc: not available URL: From jcholast at redhat.com Fri May 22 05:08:55 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 22 May 2015 07:08:55 +0200 Subject: [Freeipa-devel] [PATCH 0325] Add Domain Level feature In-Reply-To: <555E0572.8000600@redhat.com> References: <5554643E.4030600@redhat.com> <55546F6C.4060108@redhat.com> <555B390B.6000907@redhat.com> <555B3C61.7080508@redhat.com> <555B3F67.3040604@redhat.com> <555B3FFE.5040806@redhat.com> <555B4112.202@redhat.com> <555B41C8.7070503@redhat.com> <555B43BB.90404@redhat.com> <555E0572.8000600@redhat.com> Message-ID: <555EB9E7.3020800@redhat.com> Dne 21.5.2015 v 18:18 Tomas Babej napsal(a): > > > On 05/19/2015 04:07 PM, Tomas Babej wrote: >> >> >> 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 > > A new iteration of the patch, including the server-side checks for the > installers. > > Tomas 1) https://www.redhat.com/archives/freeipa-devel/2015-May/msg00228.html - I still don't agree that the plugin should be based on LDAPObject. 2) Use api domainlevel-show call to get the current domain level in ipa-replica-install instead of duplicating the code. 3) Set the domain level in DSInstance.create_instance instead of a separate call in ipa-server-install. It should be done about the same time as the master entry is added. 4) I think the option should be named --domain-level (with a dash), for consistency. -- Jan Cholasta From mkosek at redhat.com Fri May 22 07:06:16 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 22 May 2015 09:06:16 +0200 Subject: [Freeipa-devel] [PATCHES 0001-0011 v3] Profile management In-Reply-To: <555DFAB7.3080303@redhat.com> References: <555305EC.5020001@redhat.com> <55530D23.5040702@redhat.com> <55530DDB.9000101@redhat.com> <20150515082420.GR12806@dhcp-40-8.bne.redhat.com> <5555E63D.4050808@redhat.com> <555AF9E1.1010606@redhat.com> <20150519115027.GA12806@dhcp-40-8.bne.redhat.com> <555C1E5C.2080707@redhat.com> <20150520055636.GF12806@dhcp-40-8.bne.redhat.com> <555C30FE.4030707@redhat.com> <20150520144106.GH12806@dhcp-40-8.bne.redhat.com> <555DFAB7.3080303@redhat.com> Message-ID: <555ED568.3030801@redhat.com> On 05/21/2015 05:33 PM, Martin Basti wrote: > On 20/05/15 16:41, Fraser Tweedale wrote: >> Hi Honza, Martin et al, >> >> Latest patches attached. On top of previous patches (most review >> matters addressed**) patches 0008..0011 add support for profiles and >> user certificates to `ipa cert-request'. >> >> ** those that were not are being tracked at [1]; please add anything >> I missed. >> >> Some points to note: >> >> - usercertificate is not yet a multi-valued attribute for users, >> hosts and services. It should be multivalued now, for all 3 entities. >> QUESTION - we do want to allow multiple certificates for all >> principal types, not just users? Or have I got that wrong. You have that right (unless I miss something). > Changing schema can cause issues in future, we already burn ourselves several > times. > If you plan to have multi valued attribute in close future, could be better to > have mutltivalued schema now, instead of make this change in future? +1. In general, it is better to do the schema right from the day 0, temporary limitations should be rather solved in framework - that is easier to change. >> >> - "DN and SAN match principal" checks are not implemented for users >> yet. >> >> - ACL was added to allow user principals to request their own >> certificates, however, this will be further subject to CA/profile >> ACLs which are to come. >> >> - Pursuant to [2] revocation logic was removed from `cert-request' >> >> [1] http://idm.etherpad.corp.redhat.com/rhel72-cert-mgmt-progress >> [2] >> http://www.freeipa.org/page/V4/User_Certificates#Revocation_of_the_Certificates >> >> Thanks, >> Fraser Thank you too. Martin From mbasti at redhat.com Fri May 22 07:17:09 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 22 May 2015 09:17:09 +0200 Subject: [Freeipa-devel] [PATCH 0376] Add schema for unknown record types In-Reply-To: <555DB694.4090808@redhat.com> References: <555DB694.4090808@redhat.com> Message-ID: <555ED7F5.9020608@redhat.com> On 21/05/15 12:42, Petr Spacek wrote: > Hello, > > Add schema for unknown record types. > > This patch complements my previous patch 367. > > The change was pushed to > https://github.com/pspacek/bind-dyndb-ldap/tree/unknown_record_types , too. > > > ACK -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri May 22 07:22:27 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 22 May 2015 09:22:27 +0200 Subject: [Freeipa-devel] [PATCH 0376] Add schema for unknown record types In-Reply-To: <555ED7F5.9020608@redhat.com> References: <555DB694.4090808@redhat.com> <555ED7F5.9020608@redhat.com> Message-ID: <555ED933.8040606@redhat.com> On 05/22/2015 09:17 AM, Martin Basti wrote: > On 21/05/15 12:42, Petr Spacek wrote: >> Hello, >> >> Add schema for unknown record types. >> >> This patch complements my previous patch 367. >> >> The change was pushed to >> https://github.com/pspacek/bind-dyndb-ldap/tree/unknown_record_types , too. >> >> >> > ACK Hmmm, I wish the LDAP attribute is named differently, "UnknownRecord" is too general IMO. But I assume this is something you have thought about already, I just wanted to make sure the reasoning is included before pushing this. From pspacek at redhat.com Fri May 22 07:54:09 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 22 May 2015 09:54:09 +0200 Subject: [Freeipa-devel] [PATCH 0376] Add schema for unknown record types In-Reply-To: <555ED933.8040606@redhat.com> References: <555DB694.4090808@redhat.com> <555ED7F5.9020608@redhat.com> <555ED933.8040606@redhat.com> Message-ID: <555EE0A1.5000109@redhat.com> On 22.5.2015 09:22, Martin Kosek wrote: > On 05/22/2015 09:17 AM, Martin Basti wrote: >> On 21/05/15 12:42, Petr Spacek wrote: >>> Hello, >>> >>> Add schema for unknown record types. >>> >>> This patch complements my previous patch 367. >>> >>> The change was pushed to >>> https://github.com/pspacek/bind-dyndb-ldap/tree/unknown_record_types , too. >>> >>> >>> >> ACK > > Hmmm, I wish the LDAP attribute is named differently, "UnknownRecord" is too > general IMO. But I assume this is something you have thought about already, I > just wanted to make sure the reasoning is included before pushing this. Sorry, it is too late. It was discussed on ipa-devel list and Honza seemed to insist on this name :-) More importantly, it is already in UNINETT schema upstream: http://drift.uninett.no/nett/ip-nett/dnsattributes.schema http://drift.uninett.no/nett/ip-nett/oids.html It might be generic but is is consistent with RFC & rest of DNS attributes. Personally I'm more worried about brain-dead idnsRecord object class definition :-) -- Petr^2 Spacek From pspacek at redhat.com Fri May 22 08:03:49 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 22 May 2015 10:03:49 +0200 Subject: [Freeipa-devel] [PATCH 0367] Support unknown record types (RFC 3597) In-Reply-To: <555A05D2.7000408@redhat.com> References: <555A05D2.7000408@redhat.com> Message-ID: <555EE2E5.2020001@redhat.com> On 18.5.2015 17:31, Petr Spacek wrote: > Hello, > > This patch is unrelated to metaDB but it should be merged before alpha, too. > > Thank you for review! > > Support unknown record types (RFC 3597). > > Fallback to generic LDAP attribute "UnknownRecord;TYP256" if attempt to > add specific attribute like "URIRecord" failed with LDAP_OBJECT_CLASS_VIOLATION > and always delete both attributes like "URIRecord" and "UnknownRecord;TYPE256". > > https://fedorahosted.org/bind-dyndb-ldap/ticket/157 Fixed version is attached. Version 1 could dereference NULL pointers in second iteration of while loops. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0367-2-Support-unknown-record-types-RFC-3597.patch Type: text/x-patch Size: 15686 bytes Desc: not available URL: From thozza at redhat.com Fri May 22 09:10:50 2015 From: thozza at redhat.com (Tomas Hozza) Date: Fri, 22 May 2015 11:10:50 +0200 Subject: [Freeipa-devel] [PATCH 0339-0363] Implement meta-database In-Reply-To: <5555BE4F.9020609@redhat.com> References: <5555BE4F.9020609@redhat.com> Message-ID: <555EF29A.7060102@redhat.com> On 05/15/2015 11:37 AM, Petr Spacek wrote: > Hello, > > this patch set adds meta-database which is one of prerequisites for other work. > > These changes should not be user-visible. You might compile the plugin with > CFLAGS="-DMETADB_DEBUG" and check contect of /tmp/metadb.db after BIND shutdown. > > Please see > https://fedorahosted.org/bind-dyndb-ldap/ticket/151 > https://fedorahosted.org/bind-dyndb-ldap/wiki/Design/MetaDB > for further information and let me know if you can help you somehow. > In Patch 351 Rename ldap_entry_create() to ldap_entry_parse(), you should rename the functions also in documentation: https://github.com/pspacek/bind-dyndb-ldap/blob/4fb7bd42609c2b6a4ffbdf6f3a1e58e00d84fa1e/src/ldap_entry.c#L111 https://github.com/pspacek/bind-dyndb-ldap/blob/4fb7bd42609c2b6a4ffbdf6f3a1e58e00d84fa1e/src/ldap_entry.h#L101 Other than that, it looks good. I did no functional testing... It compiled, functional testing done by others. ACK Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com From cheimes at redhat.com Fri May 22 10:24:27 2015 From: cheimes at redhat.com (Christian Heimes) Date: Fri, 22 May 2015 12:24:27 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) Message-ID: <555F03DB.3090702@redhat.com> Hello, since May 1st I'm a new Red Hat employee and developer with the FreeIPA team. Some of you may already recognize my name from my contributions to CPython core, Python security and TLS/SSL improvements, or a couple of PEPs. I'm very glad that I can now work on Open Source as a full time job. I haven't had any dealings with FreeIPA before and just rudimentary experience with LDAP and Kerberos as a developer. Over the past two weeks I have been digging through FreeIPA sources, read docs and played with its services. I'm slowly starting to grasp the building blocks. I was put in charge of MS-KKDCP integration into FreeIPA 4.2 [1]. The task is small and isolated enough for a new contributor. KKDCP stands for Kerberos KDC proxy protocol. It was developed by Microsoft to tunnel KDC requests over HTTPS. It's useful for firewalled environments where 88/TCP+UDP are blocked and only 80/TCP + 443/TCP are available. With KKDCP the client side wraps each Kerberos request in an additional ASN.1 sequence and sends it as POST request to a proxy. The proxy unpacks the request, forwards it to a KDC and returns its reply to the client. MIT krb5 supports [2] KKDCP since 1.13, Fedora has backports for 1.12. Nathaniel McCallum has written [3] a proxy server as WSGI app. I'm working on improvements and integration of the WSGI app into FreeIPA. Yesterday several bug fixes already landed in kdcproxy. The integration into FreeIPA is the tricky part for me. I'm not familiar enough with FreeIPA yet to understand possible implications, so I need your guidance. I already got some feedback from several people (Dmitri, Nathan, Nathaniel, Martin, Martin2, Petr, Alexander...). Here is what I have so far: 1) The FreeIPA webui already depends on Apache and mod_wsgi. KDC proxy will run from the same Apache HTTPD instance but it will use a different mod_wsgi daemon configuration. A second WSGI daemon is easily configured and allows us to tune the daemon for KDC proxy's needs. FreeIPA is mounted at /ipa, KDC Proxy will be available at /KdcProxy or /kdc. 2) For now we are not going to introduce a separate package freeipa-server-kdcproxy. freeipa-server will depend on python-kdcproxy and install all configuration files. Therefore the entry point /KdcProxy is always configured 3) An administrator must be able to enable/disable the new feature. The state of the switch will be read when Apache is started or reloaded. The feature must be configurable for each replica, too. A WSGI wrapper will read the setting from ipaConfigString=enabledService in cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. When the feature is disabled, it will reply with 404 Not Found error. 4) In order to read the state of the switch, the WSGI script needs to be able to connect to LDAP. I can use Apache's / FreeIPA webui's keytab to get a ticket for GSSAPI bind. However Apache has no permission to read ipaConfigStrings in the masters subtree. A new role/permission and ACI is required here. 5) python-kdcproxy can read its configuration from multiple places. For performance reasons we don't want DNS lookups. Therefore our proxy instance will only use libkrb5.so to read a list of KDCs, kpasswd and admin servers from /etc/krb5.conf. Open questions / issues ----------------------- For 3) and 4) the Apache HTTP principal must be able to read or at least compare the state of the switch. The ACIs in the masters tree forbid any access to ipaConfigString entries except for principals with 'System: Read IPA Masters' permission. Martin Basti and Petr Spacek have suggested that I introduce a new permission for the task. I haven't figured out how to configure and assign a new permission. Right now my experimental code uses this ACI: (targetfilter="(ipaConfigString=enabledService)")(targetattr="ipaConfigString")(version 3.0; acl "Compare enabledService access to masters"; allow(search, compare) userdn = "ldap:///all";) I found ipaserver.install.service.Service and SimpleServiceInstance in the FreeIPA sources. As far as I understand the use of the classes, they are used in the installers to configure service instances. However the kdcproxy service instance is going to be special. It has no 1:1 relation to a system service. Instead it shares a system service (Apache HTTPD) with the HttpInstance for FreeIPA's webui. AFAIK no other service instance has such a relation. Finally I haven't figured out the best way to configure the instance. An admin should be able to enable / disable KDC proxy. Should I write a script or a ipa plugin for the job? You can find my patch in my Github repos [4]. The installer code is mostly untested, though. Please advice :) Christian [1] https://www.freeipa.org/page/V4/KDC_Proxy [2] http://web.mit.edu/kerberos/krb5-current/doc/admin/https.html [3] https://github.com/npmccallum/kdcproxy [4] https://github.com/tiran/freeipa/compare/master...kdcproxy2 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From pvoborni at redhat.com Fri May 22 10:36:26 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 22 May 2015 12:36:26 +0200 Subject: [Freeipa-devel] [PATCH 0325] Add Domain Level feature In-Reply-To: <555EB9E7.3020800@redhat.com> References: <5554643E.4030600@redhat.com> <55546F6C.4060108@redhat.com> <555B390B.6000907@redhat.com> <555B3C61.7080508@redhat.com> <555B3F67.3040604@redhat.com> <555B3FFE.5040806@redhat.com> <555B4112.202@redhat.com> <555B41C8.7070503@redhat.com> <555B43BB.90404@redhat.com> <555E0572.8000600@redhat.com> <555EB9E7.3020800@redhat.com> Message-ID: <555F06AA.50206@redhat.com> On 05/22/2015 07:08 AM, Jan Cholasta wrote: > Dne 21.5.2015 v 18:18 Tomas Babej napsal(a): >> >> >> On 05/19/2015 04:07 PM, Tomas Babej wrote: >>> >>> >>> 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 >> >> A new iteration of the patch, including the server-side checks for the >> installers. >> >> Tomas > > 1) https://www.redhat.com/archives/freeipa-devel/2015-May/msg00228.html > - I still don't agree that the plugin should be based on LDAPObject. On the other hand, with LDAPObject base, Web UI for this feature is much more simpler because it can rely on existing conventions. > > 2) Use api domainlevel-show call to get the current domain level in > ipa-replica-install instead of duplicating the code. > > 3) Set the domain level in DSInstance.create_instance instead of a > separate call in ipa-server-install. It should be done about the same > time as the master entry is added. > > 4) I think the option should be named --domain-level (with a dash), for > consistency. > -- Petr Vobornik From mkosek at redhat.com Fri May 22 11:02:40 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 22 May 2015 13:02:40 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <555F03DB.3090702@redhat.com> References: <555F03DB.3090702@redhat.com> Message-ID: <555F0CD0.4070404@redhat.com> On 05/22/2015 12:24 PM, Christian Heimes wrote: > Hello, > > since May 1st I'm a new Red Hat employee and developer with the FreeIPA > team. Some of you may already recognize my name from my contributions to > CPython core, Python security and TLS/SSL improvements, or a couple of > PEPs. I'm very glad that I can now work on Open Source as a full time > job. I haven't had any dealings with FreeIPA before and just rudimentary > experience with LDAP and Kerberos as a developer. Over the past two > weeks I have been digging through FreeIPA sources, read docs and played > with its services. I'm slowly starting to grasp the building blocks. > > I was put in charge of MS-KKDCP integration into FreeIPA 4.2 [1]. The > task is small and isolated enough for a new contributor. KKDCP stands > for Kerberos KDC proxy protocol. It was developed by Microsoft to tunnel > KDC requests over HTTPS. It's useful for firewalled environments where > 88/TCP+UDP are blocked and only 80/TCP + 443/TCP are available. With > KKDCP the client side wraps each Kerberos request in an additional ASN.1 > sequence and sends it as POST request to a proxy. The proxy unpacks the > request, forwards it to a KDC and returns its reply to the client. MIT > krb5 supports [2] KKDCP since 1.13, Fedora has backports for 1.12. > > Nathaniel McCallum has written [3] a proxy server as WSGI app. I'm > working on improvements and integration of the WSGI app into FreeIPA. > Yesterday several bug fixes already landed in kdcproxy. > > The integration into FreeIPA is the tricky part for me. I'm not familiar > enough with FreeIPA yet to understand possible implications, so I need > your guidance. I already got some feedback from several people (Dmitri, > Nathan, Nathaniel, Martin, Martin2, Petr, Alexander...). > > > Here is what I have so far: > > 1) The FreeIPA webui already depends on Apache and mod_wsgi. KDC proxy > will run from the same Apache HTTPD instance but it will use a different > mod_wsgi daemon configuration. A second WSGI daemon is easily configured > and allows us to tune the daemon for KDC proxy's needs. FreeIPA is > mounted at /ipa, KDC Proxy will be available at /KdcProxy or /kdc. Right. > > 2) For now we are not going to introduce a separate package > freeipa-server-kdcproxy. freeipa-server will depend on python-kdcproxy > and install all configuration files. Therefore the entry point /KdcProxy > is always configured Right. > 3) An administrator must be able to enable/disable the new feature. The > state of the switch will be read when Apache is started or reloaded. The > feature must be configurable for each replica, too. A WSGI wrapper will > read the setting from ipaConfigString=enabledService in > cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. When the feature is > disabled, it will reply with 404 Not Found error. The original proposal was to do it globally in cn=config. But if it is about to be stored in the cn=masters, per-replica, this looks as the right way. What API did you plan using, for enabling/disabling service? If we go the general IPA service way, should we extend the planned service-* API that Petr Vobornik announced in http://www.redhat.com/archives/freeipa-devel/2015-May/msg00309.html and have command like serverservice-mod ipa.server kdcproxy --enabled=0? > 4) In order to read the state of the switch, the WSGI script needs to be > able to connect to LDAP. I can use Apache's / FreeIPA webui's keytab to > get a ticket for GSSAPI bind. However Apache has no permission to read > ipaConfigStrings in the masters subtree. A new role/permission and ACI > is required here. There is already a permission 'System: Read IPA Masters' and privilege "IPA Masters Readers" defined, in ipaserver/install/plugins/update_managed_permissions.py. Can this be used? > 5) python-kdcproxy can read its configuration from multiple places. For > performance reasons we don't want DNS lookups. Therefore our proxy > instance will only use libkrb5.so to read a list of KDCs, kpasswd and > admin servers from /etc/krb5.conf. Ok. > Open questions / issues > ----------------------- > > For 3) and 4) the Apache HTTP principal must be able to read or at least > compare the state of the switch. The ACIs in the masters tree forbid any > access to ipaConfigString entries except for principals with 'System: > Read IPA Masters' permission. Martin Basti and Petr Spacek have > suggested that I introduce a new permission for the task. I haven't > figured out how to configure and assign a new permission. Right now my > experimental code uses this ACI: > > > (targetfilter="(ipaConfigString=enabledService)")(targetattr="ipaConfigString")(version > 3.0; acl "Compare enabledService access to masters"; allow(search, > compare) userdn = "ldap:///all";) > > > I found ipaserver.install.service.Service and SimpleServiceInstance in > the FreeIPA sources. As far as I understand the use of the classes, they > are used in the installers to configure service instances. However the > kdcproxy service instance is going to be special. It has no 1:1 relation > to a system service. Instead it shares a system service (Apache HTTPD) > with the HttpInstance for FreeIPA's webui. AFAIK no other service > instance has such a relation. > > > Finally I haven't figured out the best way to configure the instance. An > admin should be able to enable / disable KDC proxy. Should I write a > script or a ipa plugin for the job? > > > You can find my patch in my Github repos [4]. The installer code is > mostly untested, though. > > > Please advice :) > Christian > > > [1] https://www.freeipa.org/page/V4/KDC_Proxy > [2] http://web.mit.edu/kerberos/krb5-current/doc/admin/https.html > [3] https://github.com/npmccallum/kdcproxy > [4] https://github.com/tiran/freeipa/compare/master...kdcproxy2 > > > From mkosek at redhat.com Fri May 22 11:05:19 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 22 May 2015 13:05:19 +0200 Subject: [Freeipa-devel] proposal: new API command to list IPA servers In-Reply-To: <555DEBB6.8050206@redhat.com> References: <555DE859.9070908@redhat.com> <555DEBB6.8050206@redhat.com> Message-ID: <555F0D6F.4050206@redhat.com> On 05/21/2015 04:29 PM, Rob Crittenden wrote: > Petr Vobornik wrote: >> Hi all, >> >> proposal is to create following two commands: >> >> ipa server-find >> ipa server-show FQDN >> >> These commands will display a list of IPA servers stored in >> cn=masters,cn=ipa,cn=etc,$SUFFIX >> >> No mod and add commands atm. They could be added when needed. Installed >> service won't be shown as well.; >> >> Main reasons for adding them are: >> >> 1. let people know what they could enter in: >> ipa topologysegment-add SUFFIX --leftnode=NODE --rightnode=NODE >> 2. web ui needs this info to offer a list of IPA servers for the same >> task as in #1 >> 3. it's convenient >> >> In Brno, we had an offline discussion about the object name and 'server' >> was a winner. Other discussed candidates were: topologynode, node, >> master, replica, topologyserver, managedserver. Server was chosen because: >> - IPA server is commonly used >> - works well with other terminology/commands, e.g. ipa-server-install >> - is not bound to topology (in comparison to replica or master) >> - is short >> - works well with future installation of server parts like CA through API >> >> Adding Rob and Simo to CC explicitly so they could object if they wish ;) > > Kudos for including the reasoning. I still lean more towards master but don't > object too much to server given the reasoning. My main concern with master-* based API was that if we eventually do other type of replicas, e.g. read only replicas, they would not longer be "master" and we may still want to return them via this API. > My only hesitation to server is > that it is a rather generic term but it seems like a CLI user will quickly > learn the difference between host and server so it should be ok. > > +1 > > rob > From tbabej at redhat.com Fri May 22 11:08:07 2015 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 22 May 2015 13:08:07 +0200 Subject: [Freeipa-devel] [PATCH 0325] Add Domain Level feature In-Reply-To: <555F06AA.50206@redhat.com> References: <5554643E.4030600@redhat.com> <55546F6C.4060108@redhat.com> <555B390B.6000907@redhat.com> <555B3C61.7080508@redhat.com> <555B3F67.3040604@redhat.com> <555B3FFE.5040806@redhat.com> <555B4112.202@redhat.com> <555B41C8.7070503@redhat.com> <555B43BB.90404@redhat.com> <555E0572.8000600@redhat.com> <555EB9E7.3020800@redhat.com> <555F06AA.50206@redhat.com> Message-ID: <555F0E17.5090902@redhat.com> On 05/22/2015 12:36 PM, Petr Vobornik wrote: > On 05/22/2015 07:08 AM, Jan Cholasta wrote: >> Dne 21.5.2015 v 18:18 Tomas Babej napsal(a): >>> >>> >>> On 05/19/2015 04:07 PM, Tomas Babej wrote: >>>> >>>> >>>> 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 >>> >>> A new iteration of the patch, including the server-side checks for the >>> installers. >>> >>> Tomas >> >> 1) https://www.redhat.com/archives/freeipa-devel/2015-May/msg00228.html >> - I still don't agree that the plugin should be based on LDAPObject. > > On the other hand, with LDAPObject base, Web UI for this feature is > much more simpler because it can rely on existing conventions. IMHO we can swap the approach in a later patch, if we decide it's necessary. It does not block or relate to other features much. > >> >> 2) Use api domainlevel-show call to get the current domain level in >> ipa-replica-install instead of duplicating the code. I chose the former approach since the domainlevel_show command doesn't need to be available, but yeah, this can be properly detected and worked around too. Fixed. >> >> 3) Set the domain level in DSInstance.create_instance instead of a >> separate call in ipa-server-install. It should be done about the same >> time as the master entry is added. >> >> 4) I think the option should be named --domain-level (with a dash), for >> consistency. >> > > All other issues fixed. Updated patch atttached. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0325-6-Add-Domain-Level-feature.patch Type: text/x-patch Size: 21212 bytes Desc: not available URL: From cheimes at redhat.com Fri May 22 11:17:35 2015 From: cheimes at redhat.com (Christian Heimes) Date: Fri, 22 May 2015 13:17:35 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <555F0CD0.4070404@redhat.com> References: <555F03DB.3090702@redhat.com> <555F0CD0.4070404@redhat.com> Message-ID: <555F104F.1070202@redhat.com> On 2015-05-22 13:02, Martin Kosek wrote: > The original proposal was to do it globally in cn=config. But if it is > about to be stored in the cn=masters, per-replica, this looks as the > right way. My first proposal used cn=ipaConfig,cn=etc because it was the first place I found. It took me a bit to find and understand the other subtrees in cn=etc. Other developers have pointed me to the cn=masters subtree. > What API did you plan using, for enabling/disabling service? If we go > the general IPA service way, should we extend the planned service-* API > that Petr Vobornik announced in > > http://www.redhat.com/archives/freeipa-devel/2015-May/msg00309.html > > and have command like serverservice-mod ipa.server kdcproxy --enabled=0? I don't have concrete plans for an enabling/disabling API yet. It's one of the questions I have raised at the end of my mail. I'm going to study Petr Vobornik's mail now. In order to disable or enable KDC proxy, the switch in LDAP must be switched and Apache must be reloaded or restarted. The WSGI wrapper does NOT poll the state of the switch. >> 4) In order to read the state of the switch, the WSGI script needs to be >> able to connect to LDAP. I can use Apache's / FreeIPA webui's keytab to >> get a ticket for GSSAPI bind. However Apache has no permission to read >> ipaConfigStrings in the masters subtree. A new role/permission and ACI >> is required here. > > There is already a permission 'System: Read IPA Masters' and privilege > "IPA Masters Readers" defined, in > ipaserver/install/plugins/update_managed_permissions.py. Can this be used? The permission sounds too broad to me. There is probably a reason why all ipaConfigStrings entries are read-protected. I really just need search (and maybe compare) for ipaConfigString=enabledService. Thanks for your feedback, Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From pvoborni at redhat.com Fri May 22 12:02:19 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 22 May 2015 14:02:19 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <555F104F.1070202@redhat.com> References: <555F03DB.3090702@redhat.com> <555F0CD0.4070404@redhat.com> <555F104F.1070202@redhat.com> Message-ID: <555F1ACB.8050305@redhat.com> On 05/22/2015 01:17 PM, Christian Heimes wrote: > On 2015-05-22 13:02, Martin Kosek wrote: >> The original proposal was to do it globally in cn=config. But if it is >> about to be stored in the cn=masters, per-replica, this looks as the >> right way. > > My first proposal used cn=ipaConfig,cn=etc because it was the first > place I found. It took me a bit to find and understand the other > subtrees in cn=etc. Other developers have pointed me to the cn=masters > subtree. > >> What API did you plan using, for enabling/disabling service? If we go >> the general IPA service way, should we extend the planned service-* API >> that Petr Vobornik announced in >> >> http://www.redhat.com/archives/freeipa-devel/2015-May/msg00309.html >> >> and have command like serverservice-mod ipa.server kdcproxy --enabled=0? > > I don't have concrete plans for an enabling/disabling API yet. It's one > of the questions I have raised at the end of my mail. I'm going to study > Petr Vobornik's mail now. > > In order to disable or enable KDC proxy, the switch in LDAP must be > switched and Apache must be reloaded or restarted. The WSGI wrapper does > NOT poll the state of the switch. Actually the service part of "IPA servers" is not covered in the proposal. The proposal just says that it can be added later. There will be question if it should even be called "services". Maybe capabilities would be better term given that KDC Proxy is not a standalone service. > > >>> 4) In order to read the state of the switch, the WSGI script needs to be >>> able to connect to LDAP. I can use Apache's / FreeIPA webui's keytab to >>> get a ticket for GSSAPI bind. However Apache has no permission to read >>> ipaConfigStrings in the masters subtree. A new role/permission and ACI >>> is required here. >> >> There is already a permission 'System: Read IPA Masters' and privilege >> "IPA Masters Readers" defined, in >> ipaserver/install/plugins/update_managed_permissions.py. Can this be used? > > The permission sounds too broad to me. There is probably a reason why > all ipaConfigStrings entries are read-protected. I really just need > search (and maybe compare) for ipaConfigString=enabledService. > > Thanks for your feedback, > Christian > > -- Petr Vobornik From mbasti at redhat.com Fri May 22 12:14:43 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 22 May 2015 14:14:43 +0200 Subject: [Freeipa-devel] [PATCH 0256] DNS: add UnknonwRecord attribute to schema Message-ID: <555F1DB3.8050604@redhat.com> Patch attached. Initial part of https://fedorahosted.org/freeipa/ticket/4939 -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0256-DNS-add-UnknownRecord-to-schema.patch Type: text/x-patch Size: 22339 bytes Desc: not available URL: From mbasti at redhat.com Fri May 22 12:25:05 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 22 May 2015 14:25:05 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <555F0CD0.4070404@redhat.com> References: <555F03DB.3090702@redhat.com> <555F0CD0.4070404@redhat.com> Message-ID: <555F2021.6020003@redhat.com> On 22/05/15 13:02, Martin Kosek wrote: > On 05/22/2015 12:24 PM, Christian Heimes wrote: >> Hello, >> >> since May 1st I'm a new Red Hat employee and developer with the FreeIPA >> team. Some of you may already recognize my name from my contributions to >> CPython core, Python security and TLS/SSL improvements, or a couple of >> PEPs. I'm very glad that I can now work on Open Source as a full time >> job. I haven't had any dealings with FreeIPA before and just rudimentary >> experience with LDAP and Kerberos as a developer. Over the past two >> weeks I have been digging through FreeIPA sources, read docs and played >> with its services. I'm slowly starting to grasp the building blocks. >> >> I was put in charge of MS-KKDCP integration into FreeIPA 4.2 [1]. The >> task is small and isolated enough for a new contributor. KKDCP stands >> for Kerberos KDC proxy protocol. It was developed by Microsoft to tunnel >> KDC requests over HTTPS. It's useful for firewalled environments where >> 88/TCP+UDP are blocked and only 80/TCP + 443/TCP are available. With >> KKDCP the client side wraps each Kerberos request in an additional ASN.1 >> sequence and sends it as POST request to a proxy. The proxy unpacks the >> request, forwards it to a KDC and returns its reply to the client. MIT >> krb5 supports [2] KKDCP since 1.13, Fedora has backports for 1.12. >> >> Nathaniel McCallum has written [3] a proxy server as WSGI app. I'm >> working on improvements and integration of the WSGI app into FreeIPA. >> Yesterday several bug fixes already landed in kdcproxy. >> >> The integration into FreeIPA is the tricky part for me. I'm not familiar >> enough with FreeIPA yet to understand possible implications, so I need >> your guidance. I already got some feedback from several people (Dmitri, >> Nathan, Nathaniel, Martin, Martin2, Petr, Alexander...). >> >> >> Here is what I have so far: >> >> 1) The FreeIPA webui already depends on Apache and mod_wsgi. KDC proxy >> will run from the same Apache HTTPD instance but it will use a different >> mod_wsgi daemon configuration. A second WSGI daemon is easily configured >> and allows us to tune the daemon for KDC proxy's needs. FreeIPA is >> mounted at /ipa, KDC Proxy will be available at /KdcProxy or /kdc. > > Right. > >> >> 2) For now we are not going to introduce a separate package >> freeipa-server-kdcproxy. freeipa-server will depend on python-kdcproxy >> and install all configuration files. Therefore the entry point /KdcProxy >> is always configured > > Right. > >> 3) An administrator must be able to enable/disable the new feature. The >> state of the switch will be read when Apache is started or reloaded. The >> feature must be configurable for each replica, too. A WSGI wrapper will >> read the setting from ipaConfigString=enabledService in >> cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. When the feature is >> disabled, it will reply with 404 Not Found error. > > The original proposal was to do it globally in cn=config. But if it is > about to be stored in the cn=masters, per-replica, this looks as the > right way. > > What API did you plan using, for enabling/disabling service? If we go > the general IPA service way, should we extend the planned service-* > API that Petr Vobornik announced in > > http://www.redhat.com/archives/freeipa-devel/2015-May/msg00309.html > > and have command like serverservice-mod ipa.server kdcproxy --enabled=0? > > >> 4) In order to read the state of the switch, the WSGI script needs to be >> able to connect to LDAP. I can use Apache's / FreeIPA webui's keytab to >> get a ticket for GSSAPI bind. However Apache has no permission to read >> ipaConfigStrings in the masters subtree. A new role/permission and ACI >> is required here. > > There is already a permission 'System: Read IPA Masters' and privilege > "IPA Masters Readers" defined, in > ipaserver/install/plugins/update_managed_permissions.py. Can this be > used? Do we want to expose which services are configured and how they are configured for apache service? IMO this may be a security issue, to give overall read access to configuration of all services on all servers. > >> 5) python-kdcproxy can read its configuration from multiple places. For >> performance reasons we don't want DNS lookups. Therefore our proxy >> instance will only use libkrb5.so to read a list of KDCs, kpasswd and >> admin servers from /etc/krb5.conf. > > Ok. > >> Open questions / issues >> ----------------------- >> >> For 3) and 4) the Apache HTTP principal must be able to read or at least >> compare the state of the switch. The ACIs in the masters tree forbid any >> access to ipaConfigString entries except for principals with 'System: >> Read IPA Masters' permission. Martin Basti and Petr Spacek have >> suggested that I introduce a new permission for the task. I haven't >> figured out how to configure and assign a new permission. Right now my >> experimental code uses this ACI: >> >> >> (targetfilter="(ipaConfigString=enabledService)")(targetattr="ipaConfigString")(version >> >> 3.0; acl "Compare enabledService access to masters"; allow(search, >> compare) userdn = "ldap:///all";) >> >> >> I found ipaserver.install.service.Service and SimpleServiceInstance in >> the FreeIPA sources. As far as I understand the use of the classes, they >> are used in the installers to configure service instances. However the >> kdcproxy service instance is going to be special. It has no 1:1 relation >> to a system service. Instead it shares a system service (Apache HTTPD) >> with the HttpInstance for FreeIPA's webui. AFAIK no other service >> instance has such a relation. >> >> >> Finally I haven't figured out the best way to configure the instance. An >> admin should be able to enable / disable KDC proxy. Should I write a >> script or a ipa plugin for the job? >> >> >> You can find my patch in my Github repos [4]. The installer code is >> mostly untested, though. >> >> >> Please advice :) >> Christian >> >> >> [1] https://www.freeipa.org/page/V4/KDC_Proxy >> [2] http://web.mit.edu/kerberos/krb5-current/doc/admin/https.html >> [3] https://github.com/npmccallum/kdcproxy >> [4] https://github.com/tiran/freeipa/compare/master...kdcproxy2 >> >> >> > -- Martin Basti From cheimes at redhat.com Fri May 22 12:27:04 2015 From: cheimes at redhat.com (Christian Heimes) Date: Fri, 22 May 2015 14:27:04 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <555F1ACB.8050305@redhat.com> References: <555F03DB.3090702@redhat.com> <555F0CD0.4070404@redhat.com> <555F104F.1070202@redhat.com> <555F1ACB.8050305@redhat.com> Message-ID: <555F2098.90404@redhat.com> On 2015-05-22 14:02, Petr Vobornik wrote: > Actually the service part of "IPA servers" is not covered in the > proposal. The proposal just says that it can be added later. > > There will be question if it should even be called "services". Maybe > capabilities would be better term given that KDC Proxy is not a > standalone service. It's an implementation detail. KDC Proxy shares the Apache HTTP with webui because it is the simplest way. We don't have to create another certificate and an additional principal. However in the future that may change. For high traffic sites a separation of webui and KDC proxy may make sense. The KKDCP WSGI app has different tuning requirements than webui. Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From pvoborni at redhat.com Fri May 22 13:18:55 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 22 May 2015 15:18:55 +0200 Subject: [Freeipa-devel] [PATCH 0325] Add Domain Level feature In-Reply-To: <555F0E17.5090902@redhat.com> References: <5554643E.4030600@redhat.com> <55546F6C.4060108@redhat.com> <555B390B.6000907@redhat.com> <555B3C61.7080508@redhat.com> <555B3F67.3040604@redhat.com> <555B3FFE.5040806@redhat.com> <555B4112.202@redhat.com> <555B41C8.7070503@redhat.com> <555B43BB.90404@redhat.com> <555E0572.8000600@redhat.com> <555EB9E7.3020800@redhat.com> <555F06AA.50206@redhat.com> <555F0E17.5090902@redhat.com> Message-ID: <555F2CBF.20601@redhat.com> On 05/22/2015 01:08 PM, Tomas Babej wrote: snip >>> >>> 1) https://www.redhat.com/archives/freeipa-devel/2015-May/msg00228.html >>> - I still don't agree that the plugin should be based on LDAPObject. >> >> On the other hand, with LDAPObject base, Web UI for this feature is >> much more simpler because it can rely on existing conventions. > > IMHO we can swap the approach in a later patch, if we decide it's > necessary. It does not block or relate to other features much. > >> >>> >>> 2) Use api domainlevel-show call to get the current domain level in >>> ipa-replica-install instead of duplicating the code. > I chose the former approach since the domainlevel_show command doesn't > need to be available, but yeah, this can be properly detected and worked > around too. Fixed. > >>> >>> 3) Set the domain level in DSInstance.create_instance instead of a >>> separate call in ipa-server-install. It should be done about the same >>> time as the master entry is added. >>> >>> 4) I think the option should be named --domain-level (with a dash), for >>> consistency. >>> >> >> > All other issues fixed. > > Updated patch atttached [36/41]: initializing domain level [error] TypeError: __set_domain_level() takes exactly 2 arguments (1 given) Unexpected error - see /var/log/ipaserver-install.log for details: TypeError: __set_domain_level() takes exactly 2 arguments (1 given) Install failed -- Petr Vobornik From pvoborni at redhat.com Fri May 22 13:32:04 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 22 May 2015 15:32:04 +0200 Subject: [Freeipa-devel] [PATCH 0325] Add Domain Level feature In-Reply-To: <555F2CBF.20601@redhat.com> References: <5554643E.4030600@redhat.com> <55546F6C.4060108@redhat.com> <555B390B.6000907@redhat.com> <555B3C61.7080508@redhat.com> <555B3F67.3040604@redhat.com> <555B3FFE.5040806@redhat.com> <555B4112.202@redhat.com> <555B41C8.7070503@redhat.com> <555B43BB.90404@redhat.com> <555E0572.8000600@redhat.com> <555EB9E7.3020800@redhat.com> <555F06AA.50206@redhat.com> <555F0E17.5090902@redhat.com> <555F2CBF.20601@redhat.com> Message-ID: <555F2FD4.7040507@redhat.com> On 05/22/2015 03:18 PM, Petr Vobornik wrote: > On 05/22/2015 01:08 PM, Tomas Babej wrote: > > snip > >>>> >>>> 1) https://www.redhat.com/archives/freeipa-devel/2015-May/msg00228.html >>>> - I still don't agree that the plugin should be based on LDAPObject. >>> >>> On the other hand, with LDAPObject base, Web UI for this feature is >>> much more simpler because it can rely on existing conventions. >> >> IMHO we can swap the approach in a later patch, if we decide it's >> necessary. It does not block or relate to other features much. >> >>> >>>> >>>> 2) Use api domainlevel-show call to get the current domain level in >>>> ipa-replica-install instead of duplicating the code. >> I chose the former approach since the domainlevel_show command doesn't >> need to be available, but yeah, this can be properly detected and worked >> around too. Fixed. >> >>>> >>>> 3) Set the domain level in DSInstance.create_instance instead of a >>>> separate call in ipa-server-install. It should be done about the same >>>> time as the master entry is added. >>>> >>>> 4) I think the option should be named --domain-level (with a dash), for >>>> consistency. >>>> >>> >>> >> All other issues fixed. >> >> Updated patch atttached > > [36/41]: initializing domain level > [error] TypeError: __set_domain_level() takes exactly 2 arguments (1 > given) > Unexpected error - see /var/log/ipaserver-install.log for details: > TypeError: __set_domain_level() takes exactly 2 arguments (1 given) > > > Install failed > 2. during installation, __set_domain_level is called before the Domain Level entry is created and hence it fails even if the issue above is fixed -- Petr Vobornik From pvoborni at redhat.com Fri May 22 13:42:40 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 22 May 2015 15:42:40 +0200 Subject: [Freeipa-devel] [PATCH 0251] Fix uniqueness: exclude compat tree from uid uniquness plugin In-Reply-To: <555DA069.6010802@redhat.com> References: <555C8633.6090508@redhat.com> <555D93CD.6030403@redhat.com> <555D9D17.7020503@redhat.com> <555D9E8A.5040201@redhat.com> <555DA028.7000405@redhat.com> <555DA069.6010802@redhat.com> Message-ID: <555F3250.5070003@redhat.com> On 05/21/2015 11:07 AM, thierry bordaz wrote: >>>>>> Enforcing uniqueness for uid attribute prevent to move users to >>>>>> delete users subtree. snip >> >> So is this patch ACKed? > > Sorry, yes the fix is good. ACK master: * 98e4c6d6de130a0e94cd1705acc5418bdbda1eb1 Uid uniqueness: fix: exclude compat tree from uniqueness -- Petr Vobornik From tbabej at redhat.com Fri May 22 13:52:33 2015 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 22 May 2015 15:52:33 +0200 Subject: [Freeipa-devel] [PATCH 0325] Add Domain Level feature In-Reply-To: <555F2FD4.7040507@redhat.com> References: <5554643E.4030600@redhat.com> <55546F6C.4060108@redhat.com> <555B390B.6000907@redhat.com> <555B3C61.7080508@redhat.com> <555B3F67.3040604@redhat.com> <555B3FFE.5040806@redhat.com> <555B4112.202@redhat.com> <555B41C8.7070503@redhat.com> <555B43BB.90404@redhat.com> <555E0572.8000600@redhat.com> <555EB9E7.3020800@redhat.com> <555F06AA.50206@redhat.com> <555F0E17.5090902@redhat.com> <555F2CBF.20601@redhat.com> <555F2FD4.7040507@redhat.com> Message-ID: <555F34A1.6030409@redhat.com> On 05/22/2015 03:32 PM, Petr Vobornik wrote: > On 05/22/2015 03:18 PM, Petr Vobornik wrote: >> On 05/22/2015 01:08 PM, Tomas Babej wrote: >> >> snip >> >>>>> >>>>> 1) >>>>> https://www.redhat.com/archives/freeipa-devel/2015-May/msg00228.html >>>>> - I still don't agree that the plugin should be based on LDAPObject. >>>> >>>> On the other hand, with LDAPObject base, Web UI for this feature is >>>> much more simpler because it can rely on existing conventions. >>> >>> IMHO we can swap the approach in a later patch, if we decide it's >>> necessary. It does not block or relate to other features much. >>> >>>> >>>>> >>>>> 2) Use api domainlevel-show call to get the current domain level in >>>>> ipa-replica-install instead of duplicating the code. >>> I chose the former approach since the domainlevel_show command doesn't >>> need to be available, but yeah, this can be properly detected and >>> worked >>> around too. Fixed. >>> >>>>> >>>>> 3) Set the domain level in DSInstance.create_instance instead of a >>>>> separate call in ipa-server-install. It should be done about the same >>>>> time as the master entry is added. >>>>> >>>>> 4) I think the option should be named --domain-level (with a >>>>> dash), for >>>>> consistency. >>>>> >>>> >>>> >>> All other issues fixed. >>> >>> Updated patch atttached >> >> [36/41]: initializing domain level >> [error] TypeError: __set_domain_level() takes exactly 2 arguments (1 >> given) >> Unexpected error - see /var/log/ipaserver-install.log for details: >> TypeError: __set_domain_level() takes exactly 2 arguments (1 given) >> >> >> Install failed >> > > 2. during installation, __set_domain_level is called before the Domain > Level entry is created and hence it fails even if the issue above is > fixed > Yeah.. we probably need to apply the 72-domainlevel.ldif manually. From pvoborni at redhat.com Fri May 22 13:53:38 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 22 May 2015 15:53:38 +0200 Subject: [Freeipa-devel] [PATCH 0254] Server Upgrade: Wait until DS is ready after restart In-Reply-To: <20150521131637.GJ12806@dhcp-40-8.bne.redhat.com> References: <555DC3C3.30707@redhat.com> <20150521131637.GJ12806@dhcp-40-8.bne.redhat.com> Message-ID: <555F34E2.8090804@redhat.com> On 05/21/2015 03:16 PM, Fraser Tweedale wrote: > On Thu, May 21, 2015 at 01:38:43PM +0200, Martin Basti wrote: >> This patch should fix following traceback. >> >> 2015-05-20T03:50:41Z ERROR Upgrade failed with cannot connect to 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': >> 2015-05-20T03:50:41Z DEBUG Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 304, in __upgrade >> ld = ldapupdate.LDAPUpdate(dm_password='', ldapi=True) >> File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 314, in __init__ >> self.create_connection() >> File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 862, in create_connection >> autobind=self.ldapi) >> File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 66, in connect >> conn = self.create_connection(*args, **kw) >> File "/usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py", line 188, in create_connection >> client_controls=clientctrls) >> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1074, in external_bind >> '', auth_tokens, server_controls, client_controls) >> File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ >> self.gen.throw(type, value, traceback) >> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 976, in error_handler >> error=info) >> NetworkError: cannot connect to 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': >> >> 2015-05-20T03:50:41Z DEBUG Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 388, in start_creation >> run_step(full_msg, method) >> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 378, in run_step >> method() >> File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 315, in __upgrade >> raise RuntimeError(e) >> RuntimeError: cannot connect to 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': >> >> Reason was the ipa-server-install tried to connect before DS was ready. >> >> The patch adds waiting until DS is ready. >> >> Patch attached. >> >> Fraser can you please check if this fix works? I can't reproduce it. >> Thank you, Martin^2. >> > ACK; fixes the issue for me. > > One minor comment: > >> + def __start(self): >> + super(IPAUpgrade, self).start() >> >> def __stop_instance(self): >> """Stop only the main DS instance""" >> @@ -187,7 +185,7 @@ class IPAUpgrade(service.Service): >> self.step("saving configuration", self.__save_config) >> self.step("disabling listeners", self.__disable_listeners) >> self.step("enabling DS global lock", self.__enable_ds_global_write_lock) >> - self.step("starting directory server", self.__start_nowait) >> + self.step("starting directory server", self.__start) > > I think you can just say `self.start' and remove `__start' function. > > Cheers, > Fraser > Pushed to master: 3d17bf8e639616893d6937d98662ccc7541d1e23 -- Petr Vobornik From pvoborni at redhat.com Fri May 22 13:57:21 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 22 May 2015 15:57:21 +0200 Subject: [Freeipa-devel] [PATCH 0255] Server Upgrade: Fix: executed schema upgrade In-Reply-To: <20150521145102.GP12806@dhcp-40-8.bne.redhat.com> References: <555DD43F.3060708@redhat.com> <20150521145102.GP12806@dhcp-40-8.bne.redhat.com> Message-ID: <555F35C1.3080709@redhat.com> On 05/21/2015 04:51 PM, Fraser Tweedale wrote: > On Thu, May 21, 2015 at 02:49:03PM +0200, Martin Basti wrote: >> Accidentaly , schema upgrade hasn't beed executed by ipa-server-upgrade. >> >> https://fedorahosted.org/freeipa/ticket/4904 >> >> Patch attached. >> >> -- >> Martin Basti >> > ACK; the schema changes once again are applied during upgrade. > > Thanks, > Fraser > Pushed to master: c43c5d1e437cffacc64220935ee6dd83a8e72a89 -- Petr Vobornik From pvoborni at redhat.com Fri May 22 13:59:08 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 22 May 2015 15:59:08 +0200 Subject: [Freeipa-devel] [PATCH] 854 git ignore ipaplatform/__init__.py In-Reply-To: <555D8F87.4090803@redhat.com> References: <555C92CE.1070603@redhat.com> <555D8F87.4090803@redhat.com> Message-ID: <555F362C.7050000@redhat.com> On 05/21/2015 09:55 AM, Martin Babinsky wrote: > On 05/20/2015 03:57 PM, Petr Vobornik wrote: >> This file is generated in `make version-update` >> >> added in 9f049ca14403f3696d54d186e6b1b15181f055df >> >> > Yay no more warnings about untracked file! > > ACK > Pushed to master: 5f04da35dfd324686cce33c552839231cc5eba43 -- Petr Vobornik From redhatrises at gmail.com Fri May 22 14:08:21 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Fri, 22 May 2015 08:08:21 -0600 Subject: [Freeipa-devel] [PATCH 0048] fix ipa help command output errors Message-ID: Hello, This should fix https://fedorahosted.org/freeipa/ticket/3584, and as requested in the ticket, this should also fix https://fedorahosted.org/freeipa/ticket/2284 Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0048-Fix-ipa-help-command-output-errors.patch Type: text/x-patch Size: 1374 bytes Desc: not available URL: From pvoborni at redhat.com Fri May 22 14:20:09 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 22 May 2015 16:20:09 +0200 Subject: [Freeipa-devel] [PATCH] manage replication topology in the shared tree In-Reply-To: <555DB9BA.6090001@redhat.com> References: <552B84C5.80300@redhat.com> <55362C43.4020406@redhat.com> <55362FDC.7090104@redhat.com> <55519EAC.9000204@redhat.com> <555B2998.9020608@redhat.com> <555C8392.7010908@redhat.com> <555C84F2.7030500@redhat.com> <555C86F5.2080708@redhat.com> <555C8EB7.5030800@redhat.com> <555CAADB.1030306@redhat.com> <555DB9BA.6090001@redhat.com> Message-ID: <555F3B19.1040004@redhat.com> On 05/21/2015 12:55 PM, thierry bordaz wrote: > On 05/20/2015 05:40 PM, Ludwig Krispenz wrote: >> please find new versions of patches 0003 and 0005 for the topology >> plugin. >> >> the ds plugin patch includes >> - changes to match domain level patch >> - remove trailing white spaces >> - use proper oids for topology schema >> >> the install patch >> - has the 70topology.ldif removed > > Hello Ludwig, > > I failed to do 'git am patch-0003', it returned a strange "Patch format > detection failed.". > However I was able to do 'git apply' and to review it. > > I focus on the points discussed during previous reviews. > The patch is looking good to me. ACK Patch 0005 looks good to me if we squash there attached patch(typo fixes). I think that both 0003 and 0005 could be pushed. But I'll do it when testing with Domain Level patch is successful. patch 0006 will be replaced with the one I'm working on. > > thanks > thierry >> -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: wip-freeipa-pvoborni-0744-topology-installation-minor-fixes.patch Type: text/x-patch Size: 2268 bytes Desc: not available URL: From tbabej at redhat.com Fri May 22 14:27:48 2015 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 22 May 2015 16:27:48 +0200 Subject: [Freeipa-devel] [PATCH 0325] Add Domain Level feature In-Reply-To: <555F34A1.6030409@redhat.com> References: <5554643E.4030600@redhat.com> <55546F6C.4060108@redhat.com> <555B390B.6000907@redhat.com> <555B3C61.7080508@redhat.com> <555B3F67.3040604@redhat.com> <555B3FFE.5040806@redhat.com> <555B4112.202@redhat.com> <555B41C8.7070503@redhat.com> <555B43BB.90404@redhat.com> <555E0572.8000600@redhat.com> <555EB9E7.3020800@redhat.com> <555F06AA.50206@redhat.com> <555F0E17.5090902@redhat.com> <555F2CBF.20601@redhat.com> <555F2FD4.7040507@redhat.com> <555F34A1.6030409@redhat.com> Message-ID: <555F3CE4.2010509@redhat.com> On 05/22/2015 03:52 PM, Tomas Babej wrote: > > > On 05/22/2015 03:32 PM, Petr Vobornik wrote: >> On 05/22/2015 03:18 PM, Petr Vobornik wrote: >>> On 05/22/2015 01:08 PM, Tomas Babej wrote: >>> >>> snip >>> >>>>>> >>>>>> 1) >>>>>> https://www.redhat.com/archives/freeipa-devel/2015-May/msg00228.html >>>>>> - I still don't agree that the plugin should be based on LDAPObject. >>>>> >>>>> On the other hand, with LDAPObject base, Web UI for this feature is >>>>> much more simpler because it can rely on existing conventions. >>>> >>>> IMHO we can swap the approach in a later patch, if we decide it's >>>> necessary. It does not block or relate to other features much. >>>> >>>>> >>>>>> >>>>>> 2) Use api domainlevel-show call to get the current domain level in >>>>>> ipa-replica-install instead of duplicating the code. >>>> I chose the former approach since the domainlevel_show command doesn't >>>> need to be available, but yeah, this can be properly detected and >>>> worked >>>> around too. Fixed. >>>> >>>>>> >>>>>> 3) Set the domain level in DSInstance.create_instance instead of a >>>>>> separate call in ipa-server-install. It should be done about the >>>>>> same >>>>>> time as the master entry is added. >>>>>> >>>>>> 4) I think the option should be named --domain-level (with a >>>>>> dash), for >>>>>> consistency. >>>>>> >>>>> >>>>> >>>> All other issues fixed. >>>> >>>> Updated patch atttached >>> >>> [36/41]: initializing domain level >>> [error] TypeError: __set_domain_level() takes exactly 2 arguments (1 >>> given) >>> Unexpected error - see /var/log/ipaserver-install.log for details: >>> TypeError: __set_domain_level() takes exactly 2 arguments (1 given) >>> >>> >>> Install failed >>> >> >> 2. during installation, __set_domain_level is called before the >> Domain Level entry is created and hence it fails even if the issue >> above is fixed >> > > Yeah.. we probably need to apply the 72-domainlevel.ldif manually. Updated patch attached. I ran a successful installation with this patch. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0325-7-Add-Domain-Level-feature.patch Type: text/x-patch Size: 24357 bytes Desc: not available URL: From mbasti at redhat.com Fri May 22 15:01:27 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 22 May 2015 17:01:27 +0200 Subject: [Freeipa-devel] [PATCH 0048] fix ipa help command output errors In-Reply-To: References: Message-ID: <555F44C7.8000905@redhat.com> On 22/05/15 16:08, Gabe Alford wrote: > Hello, > > This should fix https://fedorahosted.org/freeipa/ticket/3584, and as > requested in the ticket, this should also fix > https://fedorahosted.org/freeipa/ticket/2284 > > Thanks, > > Gabe > > Thank you! IMO your first part of fix only mask issue, not solving it. This could be way, but I did not test it. out_encoding = getattr(outfile, 'encoding', None) if out_encoding is None: out_encoding = 'utf-8' print >> outfile, unicode(string).encode(out_encoding) Can you split this patch into 2 separate patches for each ticket please? Martin^2 -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From redhatrises at gmail.com Fri May 22 15:40:03 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Fri, 22 May 2015 09:40:03 -0600 Subject: [Freeipa-devel] [PATCH 0048] fix ipa help command output errors In-Reply-To: <555F44C7.8000905@redhat.com> References: <555F44C7.8000905@redhat.com> Message-ID: On Fri, May 22, 2015 at 9:01 AM, Martin Basti wrote: > On 22/05/15 16:08, Gabe Alford wrote: > > Hello, > > This should fix https://fedorahosted.org/freeipa/ticket/3584, and as > requested in the ticket, this should also fix > https://fedorahosted.org/freeipa/ticket/2284 > > Thanks, > > Gabe > > > Thank you! > > IMO your first part of fix only mask issue, not solving it. > > This could be way, but I did not test it. > > out_encoding = getattr(outfile, 'encoding', None) > if out_encoding is None: > out_encoding = 'utf-8' > print >> outfile, unicode(string).encode(out_encoding) > I'm confused and maybe missing something here. If I run `ipa help dns | bad_command`, shouldn't the command fail with only the following? -bash: bad: command not found > > Can you split this patch into 2 separate patches for each ticket please? > Done > Martin^2 > > -- > Martin Basti > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0048-Allow-ipa-help-command-to-run-when-ipa-client-instal.patch Type: text/x-patch Size: 894 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0049-Do-not-print-traceback-when-pipe-is-broken.patch Type: text/x-patch Size: 866 bytes Desc: not available URL: From mbasti at redhat.com Fri May 22 15:58:20 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 22 May 2015 17:58:20 +0200 Subject: [Freeipa-devel] [PATCH 0048] fix ipa help command output errors In-Reply-To: References: <555F44C7.8000905@redhat.com> Message-ID: <555F521C.8070307@redhat.com> On 22/05/15 17:40, Gabe Alford wrote: > On Fri, May 22, 2015 at 9:01 AM, Martin Basti > wrote: > > On 22/05/15 16:08, Gabe Alford wrote: >> Hello, >> >> This should fix https://fedorahosted.org/freeipa/ticket/3584, and >> as requested in the ticket, this should also fix >> https://fedorahosted.org/freeipa/ticket/2284 >> >> Thanks, >> >> Gabe >> >> > Thank you! > > IMO your first part of fix only mask issue, not solving it. > > This could be way, but I did not test it. > > out_encoding = getattr(outfile, 'encoding', None) > if out_encoding is None: > out_encoding = 'utf-8' > print >> outfile, unicode(string).encode(out_encoding) > > > I'm confused and maybe missing something here. If I run `ipa help dns > | bad_command`, shouldn't the command fail with only the following? > -bash: bad: command not found Oh sorry, I misread the exception there, I did read unicode error, I dont know why. You are right. > > > Can you split this patch into 2 separate patches for each ticket > please? > > > Done > > Martin^2 > > -- > Martin Basti > > -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri May 22 15:59:26 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 22 May 2015 17:59:26 +0200 Subject: [Freeipa-devel] [PATCH 0257] ULC: Fix: Upgrade for stage user admins failed Message-ID: <555F525E.7000007@redhat.com> Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0257-ULC-fix-upgrade-for-stage-Stage-User-Admins-failed.patch Type: text/x-patch Size: 1239 bytes Desc: not available URL: From mbasti at redhat.com Fri May 22 16:13:02 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 22 May 2015 18:13:02 +0200 Subject: [Freeipa-devel] [PATCH 0258] Server Upgrade: move code from ipa-upgrade config into separate module Message-ID: <555F558E.9060503@redhat.com> IPA services upgrade is executed only by ipa-server-upgrade, ipa-upgradeconfig will not work. Patch attached. https://fedorahosted.org/freeipa/ticket/4904 -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0258-Server-Upgrade-Move-code-from-ipa-upgradeconfig-to-s.patch Type: text/x-patch Size: 62284 bytes Desc: not available URL: From ftweedal at redhat.com Sat May 23 05:03:07 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Sat, 23 May 2015 15:03:07 +1000 Subject: [Freeipa-devel] [PATCHES 0001-0011 v3] Profile management In-Reply-To: <555DFAB7.3080303@redhat.com> References: <55530DDB.9000101@redhat.com> <20150515082420.GR12806@dhcp-40-8.bne.redhat.com> <5555E63D.4050808@redhat.com> <555AF9E1.1010606@redhat.com> <20150519115027.GA12806@dhcp-40-8.bne.redhat.com> <555C1E5C.2080707@redhat.com> <20150520055636.GF12806@dhcp-40-8.bne.redhat.com> <555C30FE.4030707@redhat.com> <20150520144106.GH12806@dhcp-40-8.bne.redhat.com> <555DFAB7.3080303@redhat.com> Message-ID: <20150523050307.GH2915@dhcp-40-8.bne.redhat.com> On Thu, May 21, 2015 at 05:33:11PM +0200, Martin Basti wrote: > On 20/05/15 16:41, Fraser Tweedale wrote: > >Hi Honza, Martin et al, > > > >Latest patches attached. On top of previous patches (most review > >matters addressed**) patches 0008..0011 add support for profiles and > >user certificates to `ipa cert-request'. > > > >** those that were not are being tracked at [1]; please add anything > > I missed. > > > >Some points to note: > > > >- usercertificate is not yet a multi-valued attribute for users, > > hosts and services. > > > > QUESTION - we do want to allow multiple certificates for all > > principal types, not just users? Or have I got that wrong. > Changing schema can cause issues in future, we already burn ourselves > several times. > If you plan to have multi valued attribute in close future, could be better > to have mutltivalued schema now, instead of make this change in future? > The 'usercertificate' attribute is multi-valued in schema. Only how we treat it in IPA framework would change. Martin Kosek clarified that services and hosts are also supporting multiple certs so I will make that change for next patch set as well. > > > >- "DN and SAN match principal" checks are not implemented for users > > yet. > > > >- ACL was added to allow user principals to request their own > > certificates, however, this will be further subject to CA/profile > > ACLs which are to come. > > > >- Pursuant to [2] revocation logic was removed from `cert-request' > > > >[1] http://idm.etherpad.corp.redhat.com/rhel72-cert-mgmt-progress > >[2] http://www.freeipa.org/page/V4/User_Certificates#Revocation_of_the_Certificates > > > >Thanks, > >Fraser > Thanks for updated patches: > > Please update required pki version in freeipa.spec.in > > Patch 0001: > Again, will be this change done after upgrade, instead of new installation? > config.set("CA", "pki_profiles_in_ldap", "True") > > I blame method 'ca_enable_ldap_profile_subsystem' in upgrade to do this, but > I'm not sure. > That's correct. The `config.set' is setting the value in the (ephemeral) pkispawn(8) config file. > > Patch 0005: > 1) > just nitpick: > profile_id_pattern = re.compile('^[a-zA-Z]\w*$') > PROFILE_ID_PATTERN = re.compile('^profileId=(\w+)', re.MULTILINE) > > In PROFILE_ID_PATTERN should be '^profileId=([a-zA-Z]\w*)' to be consistent > Good point; is fixed for next patchset. > Patch 0007: > There are still modifications in ipa-server-isntall > It is necessary to import the included profiles into Dogtag after LDAP updates are applied to IPA DIT, so that step is inevitable. I would like to avoid the import hackery but haven't found the better way yet. IMO it shouldn't be a blocker, but something to revisit once I finish the caacl plugin and move to bugfixing / polishing. (I suspect the best way forward is to explicitly pass more arguments around where they are needed and reduce the amount of shared state that is implicitly relied on in the module.) > Patch 0010: > 1) > +aci: (targetattr = "usercertificate")(version 3.0;acl "selfservice:Users > can manage their own X.509 certificates";allow (write) userdn = > "ldap:///self";) > This is not in any upgrade file > > 2) > +# User certificates > +dn: $SUFFIX > +add:aci:(targetattr = "ipasshpubkey")(version 3.0;acl "selfservice:Users > can manage their own X.509 certificates";allow (write) userdn = > "ldap:///self";) > Is this right? (ipasshpubkey) This ACI with different name is already there. > Whups, this is copy-pasta error :) Changing it to 'usercertificate' will fix 1) and 2). This is done for the next patchset. > 3) > IMO this should not be there. > > 'replaces': [ > - '(targetattr = "givenname || sn || cn || displayname || > title || initials || loginshell || gecos || homephone || mobile || pager || > facsimiletelephonenumber || telephonenumber || street || roomnumber || l || > st || postalcode || manager || secretary || description || carlicense || > labeleduri || inetuserhttpurl || seealso || employeetype || businesscategory > || ou || mepmanagedentry || objectclass")(target = > "ldap:///uid=*,cn=users,cn=accounts,$SUFFIX")(version 3.0;acl > "permission:Modify Users";allow (write) groupdn = "ldap:///cn=Modify > Users,cn=permissions,cn=pbac,$SUFFIX";)', > + '(targetattr = "givenname || sn || cn || displayname || > title || initials || loginshell || gecos || homephone || mobile || pager || > facsimiletelephonenumber || telephonenumber || street || roomnumber || l || > st || postalcode || manager || secretary || description || carlicense || > labeleduri || inetuserhttpurl || seealso || employeetype || businesscategory > || usercertificate || ou || mepmanagedentry || objectclass")(target = > "ldap:///uid=*,cn=users,cn=accounts,$SUFFIX")(version 3.0;acl > "permission:Modify Users";allow (write) groupdn = "ldap:///cn=Modify > Users,cn=permissions,cn=pbac,$SUFFIX";)', > ], > > this replace replaces permissions written in old style. New permission are > updated automaticaly (AFAIK) > OK, thanks. Is removed in next patchset. > PAtch 0011: > Please dont use '_' in code, this is for ugettext and may cause an issue in > future > + bind_service, _, _ = bind_principal > Oh yeah! I am used to using "_" for "don't care". Thanks for pointing this out. I have given them proper names for the next patchset. Thanks! Fraser > Martin^2 > > -- > Martin Basti > From ftweedal at redhat.com Sat May 23 05:04:31 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Sat, 23 May 2015 15:04:31 +1000 Subject: [Freeipa-devel] certprofiles -- problem with delete In-Reply-To: <555DDB9E.20701@redhat.com> References: <555DD13E.5060503@redhat.com> <20150521131026.GI12806@dhcp-40-8.bne.redhat.com> <555DDB9E.20701@redhat.com> Message-ID: <20150523050431.GI2915@dhcp-40-8.bne.redhat.com> On Thu, May 21, 2015 at 03:20:30PM +0200, Martin Kosek wrote: > On 05/21/2015 03:10 PM, Fraser Tweedale wrote: > > On Thu, May 21, 2015 at 02:36:14PM +0200, Milan Kubik wrote: > >> Hi Fraser and list, > >> > >> I ran into this when I was tinkering with the commands. > >> > >> The ipa certprofile plugin[s] does not take the backend result into the > >> picture right now. When I tried to delete the *default profile*, the entry > >> from ipa suffix got deleted. However the command failed > >> and the profile is still in the dogtag managed suffix. > >> After I've done this to the installed instance, subsequent uninstall > >> operation failed on some step involving dogtag. I suspect it is related. > >> I haven't been able to reproduce this for now as at the moment there > >> was no package with dogtag in the copr repo. > >> Reproducer for this is attached. (This reproducer requires patches at > >> least up to freeipa-ftweedal-0005-3-Add-certprofile-plugin.patch) > >> > >> It may be more complicated issue than it seems, though. > >> If we delete the ipa managed entry before the dogtag operation > >> and this one fails, it leaves us in an inconsistent state. > >> If on the other hand we delete the ipa managed entry after dogtag > >> call, it opens an possibility of failing to delete the entry in ipa, leading > >> to inconsistency again. > >> > >> The solution to this would be a transaction. The problem here is > >> that the transaction here would span through two integrated > >> components (three actually, ipa, 389 and dogtag, in this context). > >> Not an easy thing to do I assume. > >> > >> TL;DR: > >> > >> * certprofile-del deletes ipa managed entry and dogtag doesn't > >> * how do we approach possibly irreversible changes in LDAPObject > >> plugins when integrated component doesn't behave? > >> > >> Your thoughts on this? > >> > > Thanks for the report - certprofile-del was working at an earlier > > stage so I will track down the issue and fix. > > > > I have pondered the transaction requirements: I am managing it for > > certprofile-import by deleting the entry if the dogtag import fails. > > I suppose I can do a similar thing for certprofile del - keep a copy > > of the entry and re-add it if delete fails. Sound OK to you? > > Yeah, this is what we do in permission-mod post_callback for example. > > > > > Cheers, > > Fraser > > > >> > >> Thanks, > >> Milan > > > > > Milan, I found the problem and it is fixed in the next patch set. Thanks, Fraser From jcholast at redhat.com Mon May 25 05:30:40 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 25 May 2015 07:30:40 +0200 Subject: [Freeipa-devel] [PATCH 0325] Add Domain Level feature In-Reply-To: <555F06AA.50206@redhat.com> References: <5554643E.4030600@redhat.com> <55546F6C.4060108@redhat.com> <555B390B.6000907@redhat.com> <555B3C61.7080508@redhat.com> <555B3F67.3040604@redhat.com> <555B3FFE.5040806@redhat.com> <555B4112.202@redhat.com> <555B41C8.7070503@redhat.com> <555B43BB.90404@redhat.com> <555E0572.8000600@redhat.com> <555EB9E7.3020800@redhat.com> <555F06AA.50206@redhat.com> Message-ID: <5562B380.8070609@redhat.com> Dne 22.5.2015 v 12:36 Petr Vobornik napsal(a): > On 05/22/2015 07:08 AM, Jan Cholasta wrote: >> Dne 21.5.2015 v 18:18 Tomas Babej napsal(a): >>> >>> >>> On 05/19/2015 04:07 PM, Tomas Babej wrote: >>>> >>>> >>>> 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 >>> >>> A new iteration of the patch, including the server-side checks for the >>> installers. >>> >>> Tomas >> >> 1) https://www.redhat.com/archives/freeipa-devel/2015-May/msg00228.html >> - I still don't agree that the plugin should be based on LDAPObject. > > On the other hand, with LDAPObject base, Web UI for this feature is much > more simpler because it can rely on existing conventions. Following this logic, should *everything* be based on LDAPObject, because it would satisfy the convetion? I don't think so. The convetion should not apply here, because domain level is conceptually *not* an object, it is a property. IMHO having a clean API should be preferred over implementation convenience. -- Jan Cholasta From jcholast at redhat.com Mon May 25 06:13:35 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 25 May 2015 08:13:35 +0200 Subject: [Freeipa-devel] [PATCH 0254] Server Upgrade: Wait until DS is ready after restart In-Reply-To: <555F34E2.8090804@redhat.com> References: <555DC3C3.30707@redhat.com> <20150521131637.GJ12806@dhcp-40-8.bne.redhat.com> <555F34E2.8090804@redhat.com> Message-ID: <5562BD8F.1050403@redhat.com> Dne 22.5.2015 v 15:53 Petr Vobornik napsal(a): > On 05/21/2015 03:16 PM, Fraser Tweedale wrote: >> On Thu, May 21, 2015 at 01:38:43PM +0200, Martin Basti wrote: >>> This patch should fix following traceback. >>> >>> 2015-05-20T03:50:41Z ERROR Upgrade failed with cannot connect to >>> 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': >>> 2015-05-20T03:50:41Z DEBUG Traceback (most recent call last): >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", >>> line 304, in __upgrade >>> ld = ldapupdate.LDAPUpdate(dm_password='', ldapi=True) >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", >>> line 314, in __init__ >>> self.create_connection() >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", >>> line 862, in create_connection >>> autobind=self.ldapi) >>> File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line >>> 66, in connect >>> conn = self.create_connection(*args, **kw) >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py", line >>> 188, in create_connection >>> client_controls=clientctrls) >>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>> 1074, in external_bind >>> '', auth_tokens, server_controls, client_controls) >>> File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ >>> self.gen.throw(type, value, traceback) >>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>> 976, in error_handler >>> error=info) >>> NetworkError: cannot connect to >>> 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': >>> >>> 2015-05-20T03:50:41Z DEBUG Traceback (most recent call last): >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line >>> 388, in start_creation >>> run_step(full_msg, method) >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line >>> 378, in run_step >>> method() >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", >>> line 315, in __upgrade >>> raise RuntimeError(e) >>> RuntimeError: cannot connect to >>> 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': >>> >>> Reason was the ipa-server-install tried to connect before DS was ready. >>> >>> The patch adds waiting until DS is ready. >>> >>> Patch attached. >>> >>> Fraser can you please check if this fix works? I can't reproduce it. >>> Thank you, Martin^2. >>> >> ACK; fixes the issue for me. >> >> One minor comment: >> >>> + def __start(self): >>> + super(IPAUpgrade, self).start() >>> >>> def __stop_instance(self): >>> """Stop only the main DS instance""" >>> @@ -187,7 +185,7 @@ class IPAUpgrade(service.Service): >>> self.step("saving configuration", self.__save_config) >>> self.step("disabling listeners", self.__disable_listeners) >>> self.step("enabling DS global lock", >>> self.__enable_ds_global_write_lock) >>> - self.step("starting directory server", self.__start_nowait) >>> + self.step("starting directory server", self.__start) >> >> I think you can just say `self.start' and remove `__start' function. >> >> Cheers, >> Fraser >> > > Pushed to master: 3d17bf8e639616893d6937d98662ccc7541d1e23 This semi-breaks ipa-server-install for me: Configuring directory server (dirsrv): Estimated time 1 minute [1/38]: creating directory server user [2/38]: creating directory server instance ipa : CRITICAL Failed to restart the directory server ([Errno 2] No such file or directory). See the installation log for details. [3/38]: adding default schema [4/38]: enabling memberof plugin It would be nice to check if the socket exists before waiting for it. -- Jan Cholasta From jcholast at redhat.com Mon May 25 06:17:27 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 25 May 2015 08:17:27 +0200 Subject: [Freeipa-devel] [PATCH] Password vault In-Reply-To: <555DFD80.6020909@redhat.com> References: <54E1AF55.3060409@redhat.com> <54EBEB55.6010306@redhat.com> <54F96B22.9050507@redhat.com> <55004D5D.6060300@redhat.com> <550FE5EB.1070606@redhat.com> <551E0AE1.8040500@redhat.com> <553498D1.1020901@redhat.com> <5551DB57.6060504@redhat.com> <555314D1.6070304@redhat.com> <55541015.3040206@redhat.com> <5554ECAE.8030908@redhat.com> <55553B0A.10800@redhat.com> <555A3ACF.3000305@redhat.com> <555AF3EC.1060100@redhat.com> <555B4B40.1060702@redhat.com> <555C2F4F.4080406@redhat.com> <555DFD80.6020909@redhat.com> Message-ID: <5562BE77.2030501@redhat.com> Dne 21.5.2015 v 17:45 Endi Sukma Dewata napsal(a): > Please take a look at the new patch. > > On 5/20/2015 1:53 AM, Jan Cholasta wrote: >>> I suppose you meant you're OK with not adding host vaults now? >> >> Yes. >> >>> 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/@, 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. >> >> The reason is consistency. Private vaults should be available for all >> identities, because anything else would be an arbitrary limitation >> (which is not elegant). If private vaults were available for all >> identities, we would need a container for host vaults. I'm not saying >> the container has to be added now, but there should at least be a check >> to reject requests when the authenticated identity is a host (i.e. >> context.principal.startswith('host/')). > > In the previous patch, since a host was considered a service it could > have private vaults too. But anyway, I added the code to reject host > principals as you requested. > >>>>>> 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? >> >> I don't think there is a ticket for this particular issue. > > Added TODOs in the code. > >>>>> 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. >> >> Thanks for understanding. > > Changed the code as requested. > >>> There is an obvious inefficiency here: all containers in the path >>> (including the built-in ones) will be re-added on every vault-add >>> operation. >>> >>> I don't see anything wrong with recursions, especially if it works more >>> efficiently since only the immediate parent will be re-added. >> >> I tend to stick to the "don't use recursion in production code" rule, >> epsecially in simple cases like this one. > > I think the rule is kind of misguided. Recursion might be considered bad > if it goes very deep thus consuming so much stack space, which is not > the case here given the short and flat tree topology. Or, if it's > unnecessary such as a tail-recursion, which is not the case here either. > >>> So for example, with the loop every time you add a private vault you're >>> guaranteed to have three failed LDAP Add operations whereas with the >>> recursion there's only one failed operation. >> >> This is not about loop vs. recursion, this is about the used approach. >> Your code can be easily transformed into a loop while keeping the same >> approach: >> >> entries = [] >> >> while dn: >> assert dn.endswith(self.base_dn) >> >> rdn = dn[0] >> entry = self.backend.make_entry( >> dn, >> { >> 'objectclass': ['nsContainer'], >> 'cn': rdn['cn'], >> }) >> >> # if entry can be added, return >> try: >> self.backend.add_entry(entry) >> break >> >> except errors.NotFound: >> pass >> >> # otherwise, create parent entry first >> dn = DN(*dn[1:]) >> entries.insert(0, entry) >> >> for entry in entries: >> # then create the entry itself again >> self.backend.add_entry(entry) >> >>> >>> Do you still want to use the loop? >> >> Yes please. > > This algorithm is recursive by nature (start at the bottom, but add the > parent first). The above code basically emulates recursion with two > loops and an explicit stack of entries, but the memory requirement is > pretty much the same because it's still using a stack. With real > recursion there is no loops and the stack is implicit, so the code is at > least cleaner. I thought you cared about efficiency in the first place, given our discussion about container_dn. The looped variant is faster, even when it has 2 for loops, and consumes less memory, because of the function call overhead in the recursive variant. > > If you really want to avoid recursion you probably should use an RDN > iterator instead of a stack, but the code would be either even uglier or > less efficient. > > Anyway, it's not a big deal, I included this change. > Thanks, LGTM. Pushed to master: fde21adcbd62b9a300740d9ba237ca9e89a905e4 -- Jan Cholasta From ftweedal at redhat.com Mon May 25 07:20:04 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 25 May 2015 17:20:04 +1000 Subject: [Freeipa-devel] [PATCH 0254] Server Upgrade: Wait until DS is ready after restart In-Reply-To: <5562BD8F.1050403@redhat.com> References: <555DC3C3.30707@redhat.com> <20150521131637.GJ12806@dhcp-40-8.bne.redhat.com> <555F34E2.8090804@redhat.com> <5562BD8F.1050403@redhat.com> Message-ID: <20150525072004.GJ2915@dhcp-40-8.bne.redhat.com> On Mon, May 25, 2015 at 08:13:35AM +0200, Jan Cholasta wrote: > Dne 22.5.2015 v 15:53 Petr Vobornik napsal(a): > >On 05/21/2015 03:16 PM, Fraser Tweedale wrote: > >>On Thu, May 21, 2015 at 01:38:43PM +0200, Martin Basti wrote: > >>>This patch should fix following traceback. > >>> > >>>2015-05-20T03:50:41Z ERROR Upgrade failed with cannot connect to > >>>'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': > >>>2015-05-20T03:50:41Z DEBUG Traceback (most recent call last): > >>> File > >>>"/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", > >>>line 304, in __upgrade > >>> ld = ldapupdate.LDAPUpdate(dm_password='', ldapi=True) > >>> File > >>>"/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", > >>>line 314, in __init__ > >>> self.create_connection() > >>> File > >>>"/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", > >>>line 862, in create_connection > >>> autobind=self.ldapi) > >>> File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line > >>>66, in connect > >>> conn = self.create_connection(*args, **kw) > >>> File > >>>"/usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py", line > >>>188, in create_connection > >>> client_controls=clientctrls) > >>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line > >>>1074, in external_bind > >>> '', auth_tokens, server_controls, client_controls) > >>> File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ > >>> self.gen.throw(type, value, traceback) > >>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line > >>>976, in error_handler > >>> error=info) > >>>NetworkError: cannot connect to > >>>'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': > >>> > >>>2015-05-20T03:50:41Z DEBUG Traceback (most recent call last): > >>> File > >>>"/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line > >>>388, in start_creation > >>> run_step(full_msg, method) > >>> File > >>>"/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line > >>>378, in run_step > >>> method() > >>> File > >>>"/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", > >>>line 315, in __upgrade > >>> raise RuntimeError(e) > >>>RuntimeError: cannot connect to > >>>'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': > >>> > >>>Reason was the ipa-server-install tried to connect before DS was ready. > >>> > >>>The patch adds waiting until DS is ready. > >>> > >>>Patch attached. > >>> > >>>Fraser can you please check if this fix works? I can't reproduce it. > >>>Thank you, Martin^2. > >>> > >>ACK; fixes the issue for me. > >> > >>One minor comment: > >> > >>>+ def __start(self): > >>>+ super(IPAUpgrade, self).start() > >>> > >>> def __stop_instance(self): > >>> """Stop only the main DS instance""" > >>>@@ -187,7 +185,7 @@ class IPAUpgrade(service.Service): > >>> self.step("saving configuration", self.__save_config) > >>> self.step("disabling listeners", self.__disable_listeners) > >>> self.step("enabling DS global lock", > >>>self.__enable_ds_global_write_lock) > >>>- self.step("starting directory server", self.__start_nowait) > >>>+ self.step("starting directory server", self.__start) > >> > >>I think you can just say `self.start' and remove `__start' function. > >> > >>Cheers, > >>Fraser > >> > > > >Pushed to master: 3d17bf8e639616893d6937d98662ccc7541d1e23 > > This semi-breaks ipa-server-install for me: > > Configuring directory server (dirsrv): Estimated time 1 minute > [1/38]: creating directory server user > [2/38]: creating directory server instance > ipa : CRITICAL Failed to restart the directory server ([Errno 2] No > such file or directory). See the installation log for details. > [3/38]: adding default schema > [4/38]: enabling memberof plugin > > It would be nice to check if the socket exists before waiting for it. > This (non-catastrophic but annoying) regression occurred for me too. I wasn't paying enough attention to ipa-server-install before I ACKed the patch :/ > -- > Jan Cholasta From ftweedal at redhat.com Mon May 25 07:35:59 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 25 May 2015 17:35:59 +1000 Subject: [Freeipa-devel] using pyhbac for CA ACLs Message-ID: <20150525073559.GK2915@dhcp-40-8.bne.redhat.com> Hi everyone, CA ACLs (the forthcoming `caacl' plugin) will be used to declare which users/hosts/services can get certificates from which CAs and profiles. For v4.2, we will enforce the ACLs in the framework; the plan is to move ACL enforcement to Dogtag in a future release (https://fedorahosted.org/freeipa/ticket/5011). I have written most of the caacl plugin and now I must update cert-request to enforce the ACLs. Using hbacrule as the guide, I had a look at pyhbac and it seems to be a reasonable fit for implementing this. In particular: - "targethost" and "service" correspond nicely to "(sub)CA" and "profile-id" for evaluation. - A certificate request can be for a user, host or service; these will be overloaded into the pyhbac "user" concept. But because we will always know who the requesting principal is, we will only ever need to deal with whatever of {user,host,service} the principal actually is, to be able to evaluate access. - The "srchost" concept will be unused (therefore fixed to HBAC_CATEGORY_ALL). Perhaps there could be some future use. So, please provide feedback if you think this is a great idea or a terrible idea :) Thanks, Fraser From pspacek at redhat.com Mon May 25 08:43:30 2015 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 25 May 2015 10:43:30 +0200 Subject: [Freeipa-devel] [PATCH 0339-0363] Implement meta-database In-Reply-To: <555EF29A.7060102@redhat.com> References: <5555BE4F.9020609@redhat.com> <555EF29A.7060102@redhat.com> Message-ID: <5562E0B2.7000906@redhat.com> On 22.5.2015 11:10, Tomas Hozza wrote: > On 05/15/2015 11:37 AM, Petr Spacek wrote: >> Hello, >> >> this patch set adds meta-database which is one of prerequisites for other work. >> >> These changes should not be user-visible. You might compile the plugin with >> CFLAGS="-DMETADB_DEBUG" and check contect of /tmp/metadb.db after BIND shutdown. >> >> Please see >> https://fedorahosted.org/bind-dyndb-ldap/ticket/151 >> https://fedorahosted.org/bind-dyndb-ldap/wiki/Design/MetaDB >> for further information and let me know if you can help you somehow. >> > > In Patch 351 Rename ldap_entry_create() to ldap_entry_parse(), you should > rename the functions also in documentation: > https://github.com/pspacek/bind-dyndb-ldap/blob/4fb7bd42609c2b6a4ffbdf6f3a1e58e00d84fa1e/src/ldap_entry.c#L111 > https://github.com/pspacek/bind-dyndb-ldap/blob/4fb7bd42609c2b6a4ffbdf6f3a1e58e00d84fa1e/src/ldap_entry.h#L101 > > Other than that, it looks good. > > I did no functional testing... It compiled, functional testing done by others. > > ACK Thank you! Pushed to master: aaae746022d82b2b08944580f1ab4add7c980d59 Move SOA serial update functions to zone.c. 068538eacfe7b59e86d6712f83860584fa167787 Add LDAP UUID -> meta-database name mapping function. 35e79d6794ddf7a3a3472cfde07d983402be0f65 Add basic infratructure for generic meta-database. 9af629f8b1ccae72aa052744d4ba964d55778913 Add static (compile-time) assert macro. 01ab6db5d0b002f4848446678930a3280742d211 Add basic infratructure for LDAP meta-database. ed82a73cbf9f087737073455d5e42c1cecbd4d11 Add functions for populating LDAP meta-database. ffcc971fafbf50a0d65c8703e62584e3814064e3 Add meta-LDAP database to LDAP instance. dddb69ddbecec1b28109cc6d552a1643d6410c27 Add LDAP UUID to LDAP entry structure. b0b0fb542ed42d40e0ba3f8bae34f7fe9aa0a633 Store object class, generation number, and DNS names into meta-LDAP DB. 472c1f2f739a793ea90044c9c35b32cae58d27d0 Move typedefs to types.h to avoid cross-include problems. 316ca66683d94345eb7db99499be7e58dc8f06ec Add functions for reading from generic meta-database. e64dea627ff965149ca5dc2f5ed29c4307e229c4 Add functions for reading from meta-LDAP database. 980d00c05d749d5a87ebf3b45e9ed222ac729626 Use information from metaDB for LDAP object deletion. 808647cb1b35a4d8dbfe79b0c238509342780e36 Rename ldap_entry_create() to ldap_entry_parse(). f83d99b6cdec9f89f624163996425f8c5eb9d018 Replace ldap_entry_parseclass() by LDAP entry struct member variable. 7e79bd6e90541131a21dc2a4784cd58abc7423e8 Add pre-parsed DNS names to LDAP entry structure. 0aa700bae38a5c653bb048b032cc785235591002 Adapt update_record() to use pre-parsed DNS names in LDAP entry. 32b5764969c64eac9c1783098ddddb35025e99ff Adapt ldap_parse_fwd_zoneentry() to use pre-parsed DNS names in LDAP entry. f1ca7432fe363a7175a9aa030ba3d9177863b0e0 Adapt update_zone() to use pre-parsed DNS names in LDAP entry. 9f64fe6f1d0860a201f6331b7996f76fcaf054fd Adapt ldap_parse_master_zoneentry() to use pre-parsed DNS names in LDAP entry. 5a203a3ecc49a4bbb6cd32fb2dc669c701c04030 Adapt ldap_sync_search_entry() to use pre-parsed DNS names in LDAP entry. 414f84d77372ef7d748d33047af0ea60d2282fe9 Adapt syncrepl_update() to use pre-parsed DNS names and metadata in LDAP entry. a6513c44d5576f94485630d5a0273c49f5c6c66e Add function for node deletion from generic meta-database. a14e1c4044cf6df5f4fc3198c119f877ddd37fc3 Add ability to open existing metaDB node for writing. b1a7bbab23e7b8669bb468094fe8faff104ebdd8 Add function for node deletion to meta-LDAP database API. d6071339f25e082373cf440f5c81a980e9459a64 Delete metadata about objects deleted from LDAP. fff69de438108311c644a61dcf09dc3e367af23c Fix comments regarding ldap_entry_create(). -- Petr^2 Spacek From mbabinsk at redhat.com Mon May 25 08:48:58 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 25 May 2015 10:48:58 +0200 Subject: [Freeipa-devel] Fix password changes via kadmin In-Reply-To: <1428274413.19641.118.camel@willson.usersys.redhat.com> References: <1428274413.19641.118.camel@willson.usersys.redhat.com> Message-ID: <5562E1FA.3050001@redhat.com> On 04/06/2015 12:53 AM, Simo Sorce wrote: > Fix for bug 4914. > > I've tested it locally and seem to do exactly what is needed. I couldn't > detect any side effects, except that if you use kadmin to get a > randomized password for a service then you'll get a key for all > supported types (currently aes256, aes128, des3, rc4, camellia128, > camellia256) instead of just the default ones (aes256, aes128, des3, > rc4) if you do not specify enctypes. I think that is fine, we use > ipa-getkeytab anyway in the normal course of business and that one uses > a different code path. > > Simo. > > > Hi Simo, the patch works as expected. My only gripe is with the duplicate code in 'daemons/ipa-kdb/ipa_kdb.c' between lines 389 and 455. It could be made into a single function to get key encoding/salt types from LDAP (see my feeble and untested attempt which I attached). -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-common-function-to-get-salt-types.patch Type: text/x-patch Size: 5838 bytes Desc: not available URL: From dkupka at redhat.com Mon May 25 08:53:45 2015 From: dkupka at redhat.com (David Kupka) Date: Mon, 25 May 2015 10:53:45 +0200 Subject: [Freeipa-devel] [PATCH 0257] ULC: Fix: Upgrade for stage user admins failed In-Reply-To: <555F525E.7000007@redhat.com> References: <555F525E.7000007@redhat.com> Message-ID: <5562E319.2080000@redhat.com> On 05/22/2015 05:59 PM, Martin Basti wrote: > Patch attached. > Thanks for patch. Works for me, ACK. -- David Kupka From tbabej at redhat.com Mon May 25 10:42:32 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 25 May 2015 12:42:32 +0200 Subject: [Freeipa-devel] [PATCH 0325] Add Domain Level feature In-Reply-To: <5562B380.8070609@redhat.com> References: <5554643E.4030600@redhat.com> <55546F6C.4060108@redhat.com> <555B390B.6000907@redhat.com> <555B3C61.7080508@redhat.com> <555B3F67.3040604@redhat.com> <555B3FFE.5040806@redhat.com> <555B4112.202@redhat.com> <555B41C8.7070503@redhat.com> <555B43BB.90404@redhat.com> <555E0572.8000600@redhat.com> <555EB9E7.3020800@redhat.com> <555F06AA.50206@redhat.com> <5562B380.8070609@redhat.com> Message-ID: <5562FC98.5040109@redhat.com> On 05/25/2015 07:30 AM, Jan Cholasta wrote: > Dne 22.5.2015 v 12:36 Petr Vobornik napsal(a): >> On 05/22/2015 07:08 AM, Jan Cholasta wrote: >>> Dne 21.5.2015 v 18:18 Tomas Babej napsal(a): >>>> >>>> >>>> On 05/19/2015 04:07 PM, Tomas Babej wrote: >>>>> >>>>> >>>>> 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 >>>> >>>> A new iteration of the patch, including the server-side checks for the >>>> installers. >>>> >>>> Tomas >>> >>> 1) https://www.redhat.com/archives/freeipa-devel/2015-May/msg00228.html >>> - I still don't agree that the plugin should be based on LDAPObject. >> >> On the other hand, with LDAPObject base, Web UI for this feature is much >> more simpler because it can rely on existing conventions. > > Following this logic, should *everything* be based on LDAPObject, > because it would satisfy the convetion? I don't think so. The convetion > should not apply here, because domain level is conceptually *not* an > object, it is a property. IMHO having a clean API should be preferred > over implementation convenience. > I do not have strong opinions over this. Attached version implements a lightweight approach to the domainlevel related commands. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0325-8-Add-Domain-Level-feature.patch Type: text/x-patch Size: 25530 bytes Desc: not available URL: From abokovoy at redhat.com Mon May 25 11:09:32 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 25 May 2015 14:09:32 +0300 Subject: [Freeipa-devel] using pyhbac for CA ACLs In-Reply-To: <20150525073559.GK2915@dhcp-40-8.bne.redhat.com> References: <20150525073559.GK2915@dhcp-40-8.bne.redhat.com> Message-ID: <20150525110932.GB19176@redhat.com> On Mon, 25 May 2015, Fraser Tweedale wrote: >Hi everyone, > >CA ACLs (the forthcoming `caacl' plugin) will be used to declare >which users/hosts/services can get certificates from which CAs and >profiles. For v4.2, we will enforce the ACLs in the framework; the >plan is to move ACL enforcement to Dogtag in a future release >(https://fedorahosted.org/freeipa/ticket/5011). > >I have written most of the caacl plugin and now I must update >cert-request to enforce the ACLs. Using hbacrule as the guide, I >had a look at pyhbac and it seems to be a reasonable fit for >implementing this. In particular: > >- "targethost" and "service" correspond nicely to "(sub)CA" and > "profile-id" for evaluation. > >- A certificate request can be for a user, host or service; these > will be overloaded into the pyhbac "user" concept. But because we > will always know who the requesting principal is, we will only > ever need to deal with whatever of {user,host,service} the > principal actually is, to be able to evaluate access. > >- The "srchost" concept will be unused (therefore fixed to > HBAC_CATEGORY_ALL). Perhaps there could be some future use. > >So, please provide feedback if you think this is a great idea or a >terrible idea :) So, let me re-iterate. You want to define a set of rules, to be used in 'ipa cert-request' that would grant access to (sub)CA and profiles. These rules would be managed with commands like ipa cert-request-allow-access 'subCa' 'profile' [--users|--hosts|--services] ipa cert-request-remove-access 'subCa' 'profile' [--users|--hosts|--services] and internally 'ipa cert-request' would use HBAC engine from SSSD to actually perform evaluation of the rules. Is that right? -- / Alexander Bokovoy From mkosek at redhat.com Mon May 25 11:14:59 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 25 May 2015 13:14:59 +0200 Subject: [Freeipa-devel] using pyhbac for CA ACLs In-Reply-To: <20150525073559.GK2915@dhcp-40-8.bne.redhat.com> References: <20150525073559.GK2915@dhcp-40-8.bne.redhat.com> Message-ID: <55630433.8060008@redhat.com> On 05/25/2015 09:35 AM, Fraser Tweedale wrote: > Hi everyone, > > CA ACLs (the forthcoming `caacl' plugin) will be used to declare > which users/hosts/services can get certificates from which CAs and > profiles. For v4.2, we will enforce the ACLs in the framework; the > plan is to move ACL enforcement to Dogtag in a future release > (https://fedorahosted.org/freeipa/ticket/5011). > > I have written most of the caacl plugin and now I must update > cert-request to enforce the ACLs. Using hbacrule as the guide, I > had a look at pyhbac and it seems to be a reasonable fit for > implementing this. In particular: > > - "targethost" and "service" correspond nicely to "(sub)CA" and > "profile-id" for evaluation. > > - A certificate request can be for a user, host or service; these > will be overloaded into the pyhbac "user" concept. But because we > will always know who the requesting principal is, we will only > ever need to deal with whatever of {user,host,service} the > principal actually is, to be able to evaluate access. > > - The "srchost" concept will be unused (therefore fixed to > HBAC_CATEGORY_ALL). Perhaps there could be some future use. > > So, please provide feedback if you think this is a great idea or a > terrible idea :) CCing Jakub as pyhbac is owned by SSSD to advise. I think pyhbac rule evaluation could be hacked to do what you want to do, but IMO, we would be really calling for trouble if we reuse an evaluation mechanism for HBAC for different ACL (though similar in concept). Now question is if the risk of implementing the whole ACL mechanism on your own is bigger than reusing existing proven HBAC evaluation mechanism for another purpose... If we go with implementing the evaluation purely in the framework code, I would if it makes sense to "Is user $USER member of group $GROUP" via SSSD interfaces or if we need to evaluate manually the user groups in the framework (direct and indirect) manually as in hbactest: https://git.fedorahosted.org/cgit/freeipa.git/tree/ipalib/plugins/hbactest.py#n404 Martin From abokovoy at redhat.com Mon May 25 11:28:52 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 25 May 2015 14:28:52 +0300 Subject: [Freeipa-devel] using pyhbac for CA ACLs In-Reply-To: <55630433.8060008@redhat.com> References: <20150525073559.GK2915@dhcp-40-8.bne.redhat.com> <55630433.8060008@redhat.com> Message-ID: <20150525112852.GD19176@redhat.com> On Mon, 25 May 2015, Martin Kosek wrote: >On 05/25/2015 09:35 AM, Fraser Tweedale wrote: >> Hi everyone, >> >> CA ACLs (the forthcoming `caacl' plugin) will be used to declare >> which users/hosts/services can get certificates from which CAs and >> profiles. For v4.2, we will enforce the ACLs in the framework; the >> plan is to move ACL enforcement to Dogtag in a future release >> (https://fedorahosted.org/freeipa/ticket/5011). >> >> I have written most of the caacl plugin and now I must update >> cert-request to enforce the ACLs. Using hbacrule as the guide, I >> had a look at pyhbac and it seems to be a reasonable fit for >> implementing this. In particular: >> >> - "targethost" and "service" correspond nicely to "(sub)CA" and >> "profile-id" for evaluation. >> >> - A certificate request can be for a user, host or service; these >> will be overloaded into the pyhbac "user" concept. But because we >> will always know who the requesting principal is, we will only >> ever need to deal with whatever of {user,host,service} the >> principal actually is, to be able to evaluate access. >> >> - The "srchost" concept will be unused (therefore fixed to >> HBAC_CATEGORY_ALL). Perhaps there could be some future use. >> >> So, please provide feedback if you think this is a great idea or a >> terrible idea :) > >CCing Jakub as pyhbac is owned by SSSD to advise. I think pyhbac rule >evaluation could be hacked to do what you want to do, but IMO, we would be >really calling for trouble if we reuse an evaluation mechanism for HBAC for >different ACL (though similar in concept). No, it is just fine. The engine is abstracted away from the real knowledge of where the data comes in and really does very simple task that perfectly fitted for purpose here. >Now question is if the risk of implementing the whole ACL mechanism on your own >is bigger than reusing existing proven HBAC evaluation mechanism for another >purpose... > >If we go with implementing the evaluation purely in the framework code, I would >if it makes sense to "Is user $USER member of group $GROUP" via SSSD >interfaces or if we need to evaluate manually the user groups in the framework >(direct and indirect) manually as in hbactest: > >https://git.fedorahosted.org/cgit/freeipa.git/tree/ipalib/plugins/hbactest.py#n404 Just do the explicit filling of the data in case of 'cert-request' because we need to handle not only users but also hosts and services. As for hbactest, it might be good to pull the data from SSSD because that would allow us to solve some long standing corner cases. -- / Alexander Bokovoy From jhrozek at redhat.com Mon May 25 11:37:53 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 25 May 2015 13:37:53 +0200 Subject: [Freeipa-devel] using pyhbac for CA ACLs In-Reply-To: <20150525112852.GD19176@redhat.com> References: <20150525073559.GK2915@dhcp-40-8.bne.redhat.com> <55630433.8060008@redhat.com> <20150525112852.GD19176@redhat.com> Message-ID: <20150525113753.GH4381@hendrix.redhat.com> On Mon, May 25, 2015 at 02:28:52PM +0300, Alexander Bokovoy wrote: > On Mon, 25 May 2015, Martin Kosek wrote: > >On 05/25/2015 09:35 AM, Fraser Tweedale wrote: > >>Hi everyone, > >> > >>CA ACLs (the forthcoming `caacl' plugin) will be used to declare > >>which users/hosts/services can get certificates from which CAs and > >>profiles. For v4.2, we will enforce the ACLs in the framework; the > >>plan is to move ACL enforcement to Dogtag in a future release > >>(https://fedorahosted.org/freeipa/ticket/5011). > >> > >>I have written most of the caacl plugin and now I must update > >>cert-request to enforce the ACLs. Using hbacrule as the guide, I > >>had a look at pyhbac and it seems to be a reasonable fit for > >>implementing this. In particular: > >> > >>- "targethost" and "service" correspond nicely to "(sub)CA" and > >> "profile-id" for evaluation. > >> > >>- A certificate request can be for a user, host or service; these > >> will be overloaded into the pyhbac "user" concept. But because we > >> will always know who the requesting principal is, we will only > >> ever need to deal with whatever of {user,host,service} the > >> principal actually is, to be able to evaluate access. > >> > >>- The "srchost" concept will be unused (therefore fixed to > >> HBAC_CATEGORY_ALL). Perhaps there could be some future use. > >> > >>So, please provide feedback if you think this is a great idea or a > >>terrible idea :) > > > >CCing Jakub as pyhbac is owned by SSSD to advise. I think pyhbac rule > >evaluation could be hacked to do what you want to do, but IMO, we would be > >really calling for trouble if we reuse an evaluation mechanism for HBAC for > >different ACL (though similar in concept). > No, it is just fine. The engine is abstracted away from the real > knowledge of where the data comes in and really does very simple task > that perfectly fitted for purpose here. Right, the whole logic is contained here: https://git.fedorahosted.org/cgit/sssd.git/tree/src/providers/ipa/hbac_evaluator.c What I wonder is if we should extend the API to provide a certificate-specific function that would be pretty much just an alias for an existing one to avoid overloading names and parameters? Or does it make more sense to create a CA specific wrapper around pyhbac in the CA code? From mbasti at redhat.com Mon May 25 11:57:35 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 25 May 2015 13:57:35 +0200 Subject: [Freeipa-devel] [PATCH 0259] Server Upgrade: Wait until DS is ready after restart In-Reply-To: <20150525072004.GJ2915@dhcp-40-8.bne.redhat.com> References: <555DC3C3.30707@redhat.com> <20150521131637.GJ12806@dhcp-40-8.bne.redhat.com> <555F34E2.8090804@redhat.com> <5562BD8F.1050403@redhat.com> <20150525072004.GJ2915@dhcp-40-8.bne.redhat.com> Message-ID: <55630E2F.6050306@redhat.com> On 25/05/15 09:20, Fraser Tweedale wrote: > On Mon, May 25, 2015 at 08:13:35AM +0200, Jan Cholasta wrote: >> Dne 22.5.2015 v 15:53 Petr Vobornik napsal(a): >>> On 05/21/2015 03:16 PM, Fraser Tweedale wrote: >>>> On Thu, May 21, 2015 at 01:38:43PM +0200, Martin Basti wrote: >>>>> This patch should fix following traceback. >>>>> >>>>> 2015-05-20T03:50:41Z ERROR Upgrade failed with cannot connect to >>>>> 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': >>>>> 2015-05-20T03:50:41Z DEBUG Traceback (most recent call last): >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", >>>>> line 304, in __upgrade >>>>> ld = ldapupdate.LDAPUpdate(dm_password='', ldapi=True) >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", >>>>> line 314, in __init__ >>>>> self.create_connection() >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", >>>>> line 862, in create_connection >>>>> autobind=self.ldapi) >>>>> File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line >>>>> 66, in connect >>>>> conn = self.create_connection(*args, **kw) >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py", line >>>>> 188, in create_connection >>>>> client_controls=clientctrls) >>>>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>>>> 1074, in external_bind >>>>> '', auth_tokens, server_controls, client_controls) >>>>> File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ >>>>> self.gen.throw(type, value, traceback) >>>>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>>>> 976, in error_handler >>>>> error=info) >>>>> NetworkError: cannot connect to >>>>> 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': >>>>> >>>>> 2015-05-20T03:50:41Z DEBUG Traceback (most recent call last): >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line >>>>> 388, in start_creation >>>>> run_step(full_msg, method) >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line >>>>> 378, in run_step >>>>> method() >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", >>>>> line 315, in __upgrade >>>>> raise RuntimeError(e) >>>>> RuntimeError: cannot connect to >>>>> 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': >>>>> >>>>> Reason was the ipa-server-install tried to connect before DS was ready. >>>>> >>>>> The patch adds waiting until DS is ready. >>>>> >>>>> Patch attached. >>>>> >>>>> Fraser can you please check if this fix works? I can't reproduce it. >>>>> Thank you, Martin^2. >>>>> >>>> ACK; fixes the issue for me. >>>> >>>> One minor comment: >>>> >>>>> + def __start(self): >>>>> + super(IPAUpgrade, self).start() >>>>> >>>>> def __stop_instance(self): >>>>> """Stop only the main DS instance""" >>>>> @@ -187,7 +185,7 @@ class IPAUpgrade(service.Service): >>>>> self.step("saving configuration", self.__save_config) >>>>> self.step("disabling listeners", self.__disable_listeners) >>>>> self.step("enabling DS global lock", >>>>> self.__enable_ds_global_write_lock) >>>>> - self.step("starting directory server", self.__start_nowait) >>>>> + self.step("starting directory server", self.__start) >>>> I think you can just say `self.start' and remove `__start' function. >>>> >>>> Cheers, >>>> Fraser >>>> >>> Pushed to master: 3d17bf8e639616893d6937d98662ccc7541d1e23 >> This semi-breaks ipa-server-install for me: >> >> Configuring directory server (dirsrv): Estimated time 1 minute >> [1/38]: creating directory server user >> [2/38]: creating directory server instance >> ipa : CRITICAL Failed to restart the directory server ([Errno 2] No >> such file or directory). See the installation log for details. >> [3/38]: adding default schema >> [4/38]: enabling memberof plugin >> >> It would be nice to check if the socket exists before waiting for it. >> > This (non-catastrophic but annoying) regression occurred for me too. > I wasn't paying enough attention to ipa-server-install before I > ACKed the patch :/ > >> -- >> Jan Cholasta Hello, this patch fixes the issue. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0259-Fix-use-DS-socket-check-only-for-upgrade.patch Type: text/x-patch Size: 4446 bytes Desc: not available URL: From mbasti at redhat.com Mon May 25 12:27:32 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 25 May 2015 14:27:32 +0200 Subject: [Freeipa-devel] [PATCH 0048] fix ipa help command output errors In-Reply-To: References: <555F44C7.8000905@redhat.com> Message-ID: <55631534.2080204@redhat.com> On 22/05/15 17:40, Gabe Alford wrote: > On Fri, May 22, 2015 at 9:01 AM, Martin Basti > wrote: > > On 22/05/15 16:08, Gabe Alford wrote: >> Hello, >> >> This should fix https://fedorahosted.org/freeipa/ticket/3584, and >> as requested in the ticket, this should also fix >> https://fedorahosted.org/freeipa/ticket/2284 >> >> Thanks, >> >> Gabe >> >> > Thank you! > > IMO your first part of fix only mask issue, not solving it. > > This could be way, but I did not test it. > > out_encoding = getattr(outfile, 'encoding', None) > if out_encoding is None: > out_encoding = 'utf-8' > print >> outfile, unicode(string).encode(out_encoding) > > > I'm confused and maybe missing something here. If I run `ipa help dns > | bad_command`, shouldn't the command fail with only the following? > -bash: bad: command not found > > > Can you split this patch into 2 separate patches for each ticket > please? > > > Done > > Martin^2 > > -- > Martin Basti > > Thank you! ACK and ACK. -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Mon May 25 12:41:08 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 25 May 2015 14:41:08 +0200 Subject: [Freeipa-devel] [PATCH 0321] Update and standardize copyright headers; introduce AUTHORS file In-Reply-To: <553F8227.8070509@redhat.com> References: <553F8227.8070509@redhat.com> Message-ID: <20150525124107.GE11986@mail.corp.redhat.com> On (28/04/15 14:50), Petr Spacek wrote: >Hello, > >I'm going to add couple new files to the source tree and current copyright >header drove me mad, so here is (finally) a clenaup. > > >Update and standardize copyright headers; introduce AUTHORS file. > >Dates in all headers were harmonized with Git history. >AUTHORS file lists all authors listed in Git history and source files too. > >-- >Petr^2 Spacek >From 06c00763378629977e458322bc4862719ce7f9a0 Mon Sep 17 00:00:00 2001 >From: Petr Spacek >Date: Tue, 28 Apr 2015 14:40:46 +0200 >Subject: [PATCH] Update and standardize copyright headers; introduce AUTHORS > file. > >Dates in all headers were harmonized with Git history. >AUTHORS file lists all authors listed in Git history and source files too. >--- > AUTHORS | 9 ++++++++ > COPYING | 26 +++++++++++++++++++++ > releng/bumpver.py | 3 +++ > releng/srcversion.py | 3 +++ > releng/trac.py | 3 +++ > releng/tracvers.py | 3 +++ > src/acl.c | 37 +----------------------------- > src/acl.h | 18 +-------------- > src/compat.h | 18 +-------------- > src/fs.c | 18 +-------------- > src/fs.h | 48 +++++++++++++-------------------------- > src/fwd_register.c | 4 ++++ > src/fwd_register.h | 4 ++++ > src/krb5_helper.c | 15 +----------- > src/krb5_helper.h | 4 ++++ > src/ldap_convert.c | 18 +-------------- > src/ldap_convert.h | 18 +-------------- > src/ldap_driver.c | 19 +--------------- > src/ldap_driver.h | 18 +-------------- > src/ldap_entry.c | 19 +--------------- > src/ldap_entry.h | 19 +--------------- > src/ldap_helper.c | 20 +--------------- > src/ldap_helper.h | 19 +--------------- > src/lock.c | 18 +-------------- > src/lock.h | 50 ++++++++++++++-------------------------- > src/log.c | 64 ++++++++++++++++++++-------------------------------- > src/log.h | 18 +-------------- > src/rbt_helper.c | 4 ++++ > src/rbt_helper.h | 4 ++++ > src/rdlist.c | 19 +--------------- > src/rdlist.h | 19 +--------------- > src/semaphore.c | 18 +-------------- > src/semaphore.h | 18 +-------------- > src/settings.c | 18 +-------------- > src/settings.h | 18 +-------------- > src/str.c | 18 +-------------- > src/str.h | 18 +-------------- > src/syncrepl.c | 18 +-------------- > src/syncrepl.h | 18 +-------------- > src/types.h | 18 +-------------- > src/util.h | 18 +-------------- > src/zone_manager.c | 18 +-------------- > src/zone_manager.h | 19 +--------------- > src/zone_register.c | 18 +-------------- > src/zone_register.h | 18 +-------------- > 45 files changed, 155 insertions(+), 657 deletions(-) > create mode 100644 AUTHORS > rewrite src/fs.h (76%) > rewrite src/lock.h (74%) > rewrite src/log.c (70%) > There is a conflict due to already removed files; other wise it looks good. ACK BTW I noticed that two header fiels does not have a include guard compat.h krb5_helper.h LS From mbabinsk at redhat.com Mon May 25 12:55:39 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 25 May 2015 14:55:39 +0200 Subject: [Freeipa-devel] Yet another user certificates/Smart Card thread Message-ID: <55631BCB.8090608@redhat.com> Hello all, long post ahead! I became a proud owner of https://fedorahosted.org/freeipa/ticket/4238, and while Martin's design page (http://www.freeipa.org/page/V4/User_Certificates) brings a comprehensive overview of what should be done, there are still some gray areas we should address both in the design page and the actual implementation. These are the things that were agreed upon in previous thread(s): 1.) If the whole user certificates are available, the should be stored directly in the user entry as an attribute of the following format: "userCertificate;binary;$id", where "id" should be an unique identifier. IIRC we agreed that the first/last 4 bytes of cert's SHA512 hash should fill the 'id' role nicely. During user authentication the whole binary blob would be matched (pspacek pointed out that the cost of this operation is acceptable). 2.) In addition, or when the user certs are stored externally, we should store the certificate metadata in the user entry. These metadata should be represented by "userCertAttrs;$id;$attr" attributes, where $attr subtype corresponds to the type of metadata (issuer, serial no., profile id, certificate hash etc.). The authentication/lookup would require some custom matching rule to fetch the correct cert. Point 1. seems clear to me, we need to implement an index for userCertificate attribute in DS and modify 'user-add/mod' commands to allow for direct enrollment through API ("--usercertificate" option). Point 2. requires more work: we need to add a new attribute "userCertAttrs" to the schema and create DS index/custom matching rule for searching. I'm also not quite sure how to approach the task of getting these metadata from external storage and putting them to the user entry. These are the questions that should be addressed in a broader discussion: What is the relation to Fraser's work (cert profiles/sub-CAs)? I have seen that the recent iteration of Fraser's patches (0010-3 and 0011-3) add some ACIs and attributes/requests related to user certificates. I suppose that the only way the user certs are related to cert profile will be that there will be a profile ID stored either in cert itself, or as a separate userCertAttr;$id;profileId attribute in user entry. What to do with user certs when the entry is deleted? Should we revoke them or let them expire? In the case that the user cert is stored in a separate location and not available to FreeIPA, how will we get the required attributes (see point 2) to the user entry in LDAP tree? How much of this work should actually be done in 4.2 timeframe? I guess all work related to point 1 will be done, but what about other features? If I forgot something or got it wrong, please correct me. Whew, this mail got out of hand quickly. Anyway let the discussion begin! -- Martin^3 Babinsky From ftweedal at redhat.com Mon May 25 13:03:37 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 25 May 2015 23:03:37 +1000 Subject: [Freeipa-devel] using pyhbac for CA ACLs In-Reply-To: <20150525110932.GB19176@redhat.com> References: <20150525073559.GK2915@dhcp-40-8.bne.redhat.com> <20150525110932.GB19176@redhat.com> Message-ID: <20150525130337.GA13469@dhcp-40-8.bne.redhat.com> On Mon, May 25, 2015 at 02:09:32PM +0300, Alexander Bokovoy wrote: > On Mon, 25 May 2015, Fraser Tweedale wrote: > >Hi everyone, > > > >CA ACLs (the forthcoming `caacl' plugin) will be used to declare > >which users/hosts/services can get certificates from which CAs and > >profiles. For v4.2, we will enforce the ACLs in the framework; the > >plan is to move ACL enforcement to Dogtag in a future release > >(https://fedorahosted.org/freeipa/ticket/5011). > > > >I have written most of the caacl plugin and now I must update > >cert-request to enforce the ACLs. Using hbacrule as the guide, I > >had a look at pyhbac and it seems to be a reasonable fit for > >implementing this. In particular: > > > >- "targethost" and "service" correspond nicely to "(sub)CA" and > > "profile-id" for evaluation. > > > >- A certificate request can be for a user, host or service; these > > will be overloaded into the pyhbac "user" concept. But because we > > will always know who the requesting principal is, we will only > > ever need to deal with whatever of {user,host,service} the > > principal actually is, to be able to evaluate access. > > > >- The "srchost" concept will be unused (therefore fixed to > > HBAC_CATEGORY_ALL). Perhaps there could be some future use. > > > >So, please provide feedback if you think this is a great idea or a > >terrible idea :) > So, let me re-iterate. You want to define a set of rules, to be used in > 'ipa cert-request' that would grant access to (sub)CA and profiles. > These rules would be managed with commands like > ipa cert-request-allow-access 'subCa' 'profile' [--users|--hosts|--services] > ipa cert-request-remove-access 'subCa' 'profile' [--users|--hosts|--services] > > and internally 'ipa cert-request' would use HBAC engine from SSSD to > actually perform evaluation of the rules. > > Is that right? > Exactly right (although the actual commands will look slight different, but the essence is the same). Thanks (all) for your input. I will proceed with pyhbac as planned. Cheers, Fraser > -- > / Alexander Bokovoy From pspacek at redhat.com Mon May 25 13:04:25 2015 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 25 May 2015 15:04:25 +0200 Subject: [Freeipa-devel] [PATCH 0321] Update and standardize copyright headers; introduce AUTHORS file In-Reply-To: <20150525124107.GE11986@mail.corp.redhat.com> References: <553F8227.8070509@redhat.com> <20150525124107.GE11986@mail.corp.redhat.com> Message-ID: <55631DD9.20702@redhat.com> On 25.5.2015 14:41, Lukas Slebodnik wrote: > On (28/04/15 14:50), Petr Spacek wrote: >> Hello, >> >> I'm going to add couple new files to the source tree and current copyright >> header drove me mad, so here is (finally) a clenaup. >> >> >> Update and standardize copyright headers; introduce AUTHORS file. >> >> Dates in all headers were harmonized with Git history. >> AUTHORS file lists all authors listed in Git history and source files too. >> >> -- >> Petr^2 Spacek > >>From 06c00763378629977e458322bc4862719ce7f9a0 Mon Sep 17 00:00:00 2001 >> From: Petr Spacek >> Date: Tue, 28 Apr 2015 14:40:46 +0200 >> Subject: [PATCH] Update and standardize copyright headers; introduce AUTHORS >> file. >> >> Dates in all headers were harmonized with Git history. >> AUTHORS file lists all authors listed in Git history and source files too. >> --- >> AUTHORS | 9 ++++++++ >> COPYING | 26 +++++++++++++++++++++ >> releng/bumpver.py | 3 +++ >> releng/srcversion.py | 3 +++ >> releng/trac.py | 3 +++ >> releng/tracvers.py | 3 +++ >> src/acl.c | 37 +----------------------------- >> src/acl.h | 18 +-------------- >> src/compat.h | 18 +-------------- >> src/fs.c | 18 +-------------- >> src/fs.h | 48 +++++++++++++-------------------------- >> src/fwd_register.c | 4 ++++ >> src/fwd_register.h | 4 ++++ >> src/krb5_helper.c | 15 +----------- >> src/krb5_helper.h | 4 ++++ >> src/ldap_convert.c | 18 +-------------- >> src/ldap_convert.h | 18 +-------------- >> src/ldap_driver.c | 19 +--------------- >> src/ldap_driver.h | 18 +-------------- >> src/ldap_entry.c | 19 +--------------- >> src/ldap_entry.h | 19 +--------------- >> src/ldap_helper.c | 20 +--------------- >> src/ldap_helper.h | 19 +--------------- >> src/lock.c | 18 +-------------- >> src/lock.h | 50 ++++++++++++++-------------------------- >> src/log.c | 64 ++++++++++++++++++++-------------------------------- >> src/log.h | 18 +-------------- >> src/rbt_helper.c | 4 ++++ >> src/rbt_helper.h | 4 ++++ >> src/rdlist.c | 19 +--------------- >> src/rdlist.h | 19 +--------------- >> src/semaphore.c | 18 +-------------- >> src/semaphore.h | 18 +-------------- >> src/settings.c | 18 +-------------- >> src/settings.h | 18 +-------------- >> src/str.c | 18 +-------------- >> src/str.h | 18 +-------------- >> src/syncrepl.c | 18 +-------------- >> src/syncrepl.h | 18 +-------------- >> src/types.h | 18 +-------------- >> src/util.h | 18 +-------------- >> src/zone_manager.c | 18 +-------------- >> src/zone_manager.h | 19 +--------------- >> src/zone_register.c | 18 +-------------- >> src/zone_register.h | 18 +-------------- >> 45 files changed, 155 insertions(+), 657 deletions(-) >> create mode 100644 AUTHORS >> rewrite src/fs.h (76%) >> rewrite src/lock.h (74%) >> rewrite src/log.c (70%) >> > There is a conflict due to already removed files; > other wise it looks good. > > ACK > > BTW I noticed that two header fiels does not have a include guard > compat.h krb5_helper.h Thank you! Pushed to master: a2ec9e66dafaab8958dc4bb40201eef6f7ba7ddc -- Petr^2 Spacek From mbasti at redhat.com Mon May 25 13:10:39 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 25 May 2015 15:10:39 +0200 Subject: [Freeipa-devel] [PATCH 0260] Server Upgrade: fix the remove statement Message-ID: <55631F4F.9080201@redhat.com> This fixes issue with the remove statement, which causes LDAP error, when the updater is trying to remove value from nonexistent entry. Reproducer: apply my patch mbasti-0256, install the IPA server without the DNS subsystem. Patch attached. https://fedorahosted.org/freeipa/ticket/4904 -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0260-Server-Upgrade-fix-remove-statement.patch Type: text/x-patch Size: 1551 bytes Desc: not available URL: From jcholast at redhat.com Mon May 25 13:13:25 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 25 May 2015 15:13:25 +0200 Subject: [Freeipa-devel] Yet another user certificates/Smart Card thread In-Reply-To: <55631BCB.8090608@redhat.com> References: <55631BCB.8090608@redhat.com> Message-ID: <55631FF5.3080008@redhat.com> Hi, Dne 25.5.2015 v 14:55 Martin Babinsky napsal(a): > Hello all, long post ahead! > > I became a proud owner of https://fedorahosted.org/freeipa/ticket/4238, > and while Martin's design page > (http://www.freeipa.org/page/V4/User_Certificates) brings a > comprehensive overview of what should be done, there are still some gray > areas we should address both in the design page and the actual > implementation. > > These are the things that were agreed upon in previous thread(s): > > 1.) If the whole user certificates are available, the should be stored > directly in the user entry as an attribute of the following format: > > "userCertificate;binary;$id", > > where "id" should be an unique identifier. IIRC we agreed that the > first/last 4 bytes of cert's SHA512 hash should fill the 'id' role > nicely. During user authentication the whole binary blob would be > matched (pspacek pointed out that the cost of this operation is > acceptable). > > 2.) In addition, or when the user certs are stored externally, we should > store the certificate metadata in the user entry. These metadata should > be represented by "userCertAttrs;$id;$attr" attributes, where $attr > subtype corresponds to the type of metadata (issuer, serial no., profile > id, certificate hash etc.). The authentication/lookup would require some > custom matching rule to fetch the correct cert. > > Point 1. seems clear to me, we need to implement an index for > userCertificate attribute in DS and modify 'user-add/mod' commands to > allow for direct enrollment through API ("--usercertificate" option). > > Point 2. requires more work: we need to add a new attribute > "userCertAttrs" to the schema and create DS index/custom matching rule > for searching. I'm also not quite sure how to approach the task of > getting these metadata from external storage and putting them to the > user entry. Both points are obsolete. See the design page you linked for the current plan. > > These are the questions that should be addressed in a broader discussion: > > What is the relation to Fraser's work (cert profiles/sub-CAs)? I have > seen that the recent iteration of Fraser's patches (0010-3 and 0011-3) > add some ACIs and attributes/requests related to user certificates. I > suppose that the only way the user certs are related to cert profile > will be that there will be a profile ID stored either in cert itself, or > as a separate userCertAttr;$id;profileId attribute in user entry. > > What to do with user certs when the entry is deleted? Should we revoke > them or let them expire? See . > > In the case that the user cert is stored in a separate location and not > available to FreeIPA, how will we get the required attributes (see point > 2) to the user entry in LDAP tree? > > How much of this work should actually be done in 4.2 timeframe? I guess > all work related to point 1 will be done, but what about other features? We need an API to modify the userCertificate attribute of users/hosts/services. Should be easy to do. > > If I forgot something or got it wrong, please correct me. > > Whew, this mail got out of hand quickly. Anyway let the discussion begin! > Honza -- Jan Cholasta From mbasti at redhat.com Mon May 25 13:38:39 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 25 May 2015 15:38:39 +0200 Subject: [Freeipa-devel] [PATCH 0259] Server Upgrade: Wait until DS is ready after restart In-Reply-To: <55630E2F.6050306@redhat.com> References: <555DC3C3.30707@redhat.com> <20150521131637.GJ12806@dhcp-40-8.bne.redhat.com> <555F34E2.8090804@redhat.com> <5562BD8F.1050403@redhat.com> <20150525072004.GJ2915@dhcp-40-8.bne.redhat.com> <55630E2F.6050306@redhat.com> Message-ID: <556325DF.9060602@redhat.com> On 25/05/15 13:57, Martin Basti wrote: > On 25/05/15 09:20, Fraser Tweedale wrote: >> On Mon, May 25, 2015 at 08:13:35AM +0200, Jan Cholasta wrote: >>> Dne 22.5.2015 v 15:53 Petr Vobornik napsal(a): >>>> On 05/21/2015 03:16 PM, Fraser Tweedale wrote: >>>>> On Thu, May 21, 2015 at 01:38:43PM +0200, Martin Basti wrote: >>>>>> This patch should fix following traceback. >>>>>> >>>>>> 2015-05-20T03:50:41Z ERROR Upgrade failed with cannot connect to >>>>>> 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': >>>>>> 2015-05-20T03:50:41Z DEBUG Traceback (most recent call last): >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", >>>>>> >>>>>> line 304, in __upgrade >>>>>> ld = ldapupdate.LDAPUpdate(dm_password='', ldapi=True) >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", >>>>>> line 314, in __init__ >>>>>> self.create_connection() >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", >>>>>> line 862, in create_connection >>>>>> autobind=self.ldapi) >>>>>> File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line >>>>>> 66, in connect >>>>>> conn = self.create_connection(*args, **kw) >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py", line >>>>>> 188, in create_connection >>>>>> client_controls=clientctrls) >>>>>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", >>>>>> line >>>>>> 1074, in external_bind >>>>>> '', auth_tokens, server_controls, client_controls) >>>>>> File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ >>>>>> self.gen.throw(type, value, traceback) >>>>>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", >>>>>> line >>>>>> 976, in error_handler >>>>>> error=info) >>>>>> NetworkError: cannot connect to >>>>>> 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': >>>>>> >>>>>> 2015-05-20T03:50:41Z DEBUG Traceback (most recent call last): >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>>>>> line >>>>>> 388, in start_creation >>>>>> run_step(full_msg, method) >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>>>>> line >>>>>> 378, in run_step >>>>>> method() >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", >>>>>> >>>>>> line 315, in __upgrade >>>>>> raise RuntimeError(e) >>>>>> RuntimeError: cannot connect to >>>>>> 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': >>>>>> >>>>>> Reason was the ipa-server-install tried to connect before DS was >>>>>> ready. >>>>>> >>>>>> The patch adds waiting until DS is ready. >>>>>> >>>>>> Patch attached. >>>>>> >>>>>> Fraser can you please check if this fix works? I can't reproduce it. >>>>>> Thank you, Martin^2. >>>>>> >>>>> ACK; fixes the issue for me. >>>>> >>>>> One minor comment: >>>>> >>>>>> + def __start(self): >>>>>> + super(IPAUpgrade, self).start() >>>>>> >>>>>> def __stop_instance(self): >>>>>> """Stop only the main DS instance""" >>>>>> @@ -187,7 +185,7 @@ class IPAUpgrade(service.Service): >>>>>> self.step("saving configuration", self.__save_config) >>>>>> self.step("disabling listeners", self.__disable_listeners) >>>>>> self.step("enabling DS global lock", >>>>>> self.__enable_ds_global_write_lock) >>>>>> - self.step("starting directory server", self.__start_nowait) >>>>>> + self.step("starting directory server", self.__start) >>>>> I think you can just say `self.start' and remove `__start' function. >>>>> >>>>> Cheers, >>>>> Fraser >>>>> >>>> Pushed to master: 3d17bf8e639616893d6937d98662ccc7541d1e23 >>> This semi-breaks ipa-server-install for me: >>> >>> Configuring directory server (dirsrv): Estimated time 1 minute >>> [1/38]: creating directory server user >>> [2/38]: creating directory server instance >>> ipa : CRITICAL Failed to restart the directory server >>> ([Errno 2] No >>> such file or directory). See the installation log for details. >>> [3/38]: adding default schema >>> [4/38]: enabling memberof plugin >>> >>> It would be nice to check if the socket exists before waiting for it. >>> >> This (non-catastrophic but annoying) regression occurred for me too. >> I wasn't paying enough attention to ipa-server-install before I >> ACKed the patch :/ >> >>> -- >>> Jan Cholasta > Hello, > > this patch fixes the issue. > > > > > Updated patch attached -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0259.2-Fix-use-DS-socket-check-only-for-upgrade.patch Type: text/x-patch Size: 4561 bytes Desc: not available URL: From ofayans at redhat.com Mon May 25 13:56:39 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Mon, 25 May 2015 15:56:39 +0200 Subject: [Freeipa-devel] Replication Topology plugin issues Message-ID: <55632A17.9050205@redhat.com> Hi, Playing around with the replication topology plugin, I've noticed a couple of issues: 1. around 50% of attempts to setup a replica of a freeipa master with topology plugin enabled (domain level set to 1.0) end up with the following error message in the stdoutput: [error] RuntimeError: One of the ldap service principals is missing. Replication agreement cannot be converted. Replication error message: Unable to acquire replicaLDAP error: No such object I am not sure whether the reason is in the Topology Plugin itself or in some of the latest changes in upstream, though. 2. Whenever this happens, master retains the information about the new topology segment, even despite the replica setup was unsuccessful. IMHO, we should have a way to notify the master about replica setup faiures/aborts so that the master would automatically erase the corresponding freshly-created segments in such cases. 3. After this happens user is unable to delete the replication agreement with the standard `ipa-replica-manage del` way: $ ipa-replica-manage del replica1.pesen.net --force Connection to 'replica1.pesen.net' failed: [Errno -2] Name or service not known Forcing removal of replica1.pesen.net Skipping calculation to determine if one or more masters would be orphaned. Deleting replication agreements between replica1.pesen.net and newmaster.pesen.net Failed to get list of agreements from 'replica1.pesen.net': [Errno -2] Name or service not known Forcing removal on 'newmaster.pesen.net' Any DNA range on 'replica1.pesen.net' will be lost There were issues removing a connection for replica1.pesen.net from newmaster.pesen.net: Server is unwilling to perform: Entry is managed by topology plugin.Deletion not allowed. Failed to cleanup replica1.pesen.net entries: Not allowed on non-leaf entry You may need to manually remove them from the tree Failed to cleanup replica1.pesen.net DNS entries: no matching entry found You may need to manually remove them from the tree IIRC upon one of the early discussions with Ludwig, this is yet to be implemented. -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mkosek at redhat.com Mon May 25 13:56:46 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 25 May 2015 15:56:46 +0200 Subject: [Freeipa-devel] Yet another user certificates/Smart Card thread In-Reply-To: <55631FF5.3080008@redhat.com> References: <55631BCB.8090608@redhat.com> <55631FF5.3080008@redhat.com> Message-ID: <55632A1E.2000802@redhat.com> On 05/25/2015 03:13 PM, Jan Cholasta wrote: > Hi, > > Dne 25.5.2015 v 14:55 Martin Babinsky napsal(a): >> Hello all, long post ahead! >> >> I became a proud owner of https://fedorahosted.org/freeipa/ticket/4238, >> and while Martin's design page >> (http://www.freeipa.org/page/V4/User_Certificates) brings a >> comprehensive overview of what should be done, there are still some gray >> areas we should address both in the design page and the actual >> implementation. >> >> These are the things that were agreed upon in previous thread(s): >> >> 1.) If the whole user certificates are available, the should be stored >> directly in the user entry as an attribute of the following format: >> >> "userCertificate;binary;$id", >> >> where "id" should be an unique identifier. IIRC we agreed that the >> first/last 4 bytes of cert's SHA512 hash should fill the 'id' role >> nicely. During user authentication the whole binary blob would be >> matched (pspacek pointed out that the cost of this operation is >> acceptable). >> >> 2.) In addition, or when the user certs are stored externally, we should >> store the certificate metadata in the user entry. These metadata should >> be represented by "userCertAttrs;$id;$attr" attributes, where $attr >> subtype corresponds to the type of metadata (issuer, serial no., profile >> id, certificate hash etc.). The authentication/lookup would require some >> custom matching rule to fetch the correct cert. >> >> Point 1. seems clear to me, we need to implement an index for >> userCertificate attribute in DS and modify 'user-add/mod' commands to >> allow for direct enrollment through API ("--usercertificate" option). >> >> Point 2. requires more work: we need to add a new attribute >> "userCertAttrs" to the schema and create DS index/custom matching rule >> for searching. I'm also not quite sure how to approach the task of >> getting these metadata from external storage and putting them to the >> user entry. > > Both points are obsolete. See the design page you linked for the current plan. Huh, where that came from Martin? Did you have some cached old version of the design page? I am just wondering what went wrong, as this is something I deleted from that page month ago. > >> >> These are the questions that should be addressed in a broader discussion: >> >> What is the relation to Fraser's work (cert profiles/sub-CAs)? I have >> seen that the recent iteration of Fraser's patches (0010-3 and 0011-3) >> add some ACIs and attributes/requests related to user certificates. I >> suppose that the only way the user certs are related to cert profile >> will be that there will be a profile ID stored either in cert itself, or >> as a separate userCertAttr;$id;profileId attribute in user entry. >> >> What to do with user certs when the entry is deleted? Should we revoke >> them or let them expire? > > See . > >> >> In the case that the user cert is stored in a separate location and not >> available to FreeIPA, how will we get the required attributes (see point >> 2) to the user entry in LDAP tree? >> >> How much of this work should actually be done in 4.2 timeframe? I guess >> all work related to point 1 will be done, but what about other features? > > We need an API to modify the userCertificate attribute of users/hosts/services. > Should be easy to do. What API would you propose? Just using the current "--certificate" option we have for hosts/services, but extending it so that it can also store other, non-IPA certificates? Right now, I can do only this: # ipa host-mod test.host.test --certificate=MIIDYTCCAkmgAwIBAgIJAIz9FKFUvzv0MA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAkNaMQ0wCwYDVQQHDARCcm5vMRAwDgYDVQQKDAdSZWQgSGF0MRcwFQYDVQQDDA50ZXN0Lmhvc3QudGVzdDAeFw0xNTA1MjUxMzQwMTVaFw0xNTA2MjQxMzQwMTVaMEcxCzAJBgNVBAYTAkNaMQ0wCwYDVQQHDARCcm5vMRAwDgYDVQQKDAdSZWQgSGF0MRcwFQYDVQQDDA50ZXN0Lmhvc3QudGVzdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOi4goei6KU8dU2VVqzu9OA+6RJEAdpawp3KvCbTnGPJJx7SzgguDPj5L3+tx9kjyYKD1L7eAWZHv6QSNuCe4kixIg/iamyY8OOt7wkGHzSzDGm4gVheD6OCuQ2OmwcDebysfINUugQIvUCgxAxRV6fZhQzvtMnao4N+sclrnfi+Njz1Otf0/UqVG0Le0tHSTFRA7A8ECOCMpY7TLSr8VViRp0A2pX/dr3tgvQO+EsZUwKVKSQcBGJQ3MW/Cn9NPLj03zESG8305Q6YLpQVyFHTCJJi/ZLEJjiK8emmq+6K4X7/5x6zlmJZ5llY3x3b0cJ44u5sXqUqvuhHDMbyxiKMCAwEAAaNQME4wHQYDVR0OBBYEFE+42oRjb/cmPRAU+tejUwkvzIubMB8GA1UdIwQYMBaAFE+42oRjb/cmPRAU+tejUwkvzIubMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEBAHqUTsVcr9h9/rjPTLQ2GWMmYjAKR0SpN+EnXT4cMLTyF8ZmN6ZlrNnUJXC4uqhTTwribxkNfp2sTABa9i3CrsWNGKM2RZj5Fz2H03p+ZMFm0JpDjpu1sKQ064pvliHaiA/w2ejDH9kgNMU6+Csn5cIndOzHVrf! 2NtMgTishM IkUKGJGhPV4lL+WKjkFVKlhKNAYcmsELkIJqISL/W6TEzPOxFSSrGi4QNP4ekaL+hhAACBP+ecRYel7kRcBPddwvtzOt+MusHPEeHdZpmyubs0UXI2OGcDT21SC4ydjOADnv/gTxdZFarJKWAQlyTEj9X1EzBrv6uQuprwGQjpOE2w= ipa: ERROR: Certificate operation cannot be completed: Issuer "CN=test.host.test,O=Red Hat,L=Brno,C=CZ" does not match the expected issuer Martin From ftweedal at redhat.com Mon May 25 14:07:44 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 26 May 2015 00:07:44 +1000 Subject: [Freeipa-devel] [PATCH 0259] Server Upgrade: Wait until DS is ready after restart In-Reply-To: <556325DF.9060602@redhat.com> References: <555DC3C3.30707@redhat.com> <20150521131637.GJ12806@dhcp-40-8.bne.redhat.com> <555F34E2.8090804@redhat.com> <5562BD8F.1050403@redhat.com> <20150525072004.GJ2915@dhcp-40-8.bne.redhat.com> <55630E2F.6050306@redhat.com> <556325DF.9060602@redhat.com> Message-ID: <20150525140744.GC13469@dhcp-40-8.bne.redhat.com> On Mon, May 25, 2015 at 03:38:39PM +0200, Martin Basti wrote: > On 25/05/15 13:57, Martin Basti wrote: > >On 25/05/15 09:20, Fraser Tweedale wrote: > >>On Mon, May 25, 2015 at 08:13:35AM +0200, Jan Cholasta wrote: > >>>Dne 22.5.2015 v 15:53 Petr Vobornik napsal(a): > >>>>On 05/21/2015 03:16 PM, Fraser Tweedale wrote: > >>>>>On Thu, May 21, 2015 at 01:38:43PM +0200, Martin Basti wrote: > >>>>>>This patch should fix following traceback. > >>>>>> > >>>>>>2015-05-20T03:50:41Z ERROR Upgrade failed with cannot connect to > >>>>>>'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': > >>>>>>2015-05-20T03:50:41Z DEBUG Traceback (most recent call last): > >>>>>> File > >>>>>>"/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", > >>>>>> > >>>>>>line 304, in __upgrade > >>>>>> ld = ldapupdate.LDAPUpdate(dm_password='', ldapi=True) > >>>>>> File > >>>>>>"/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", > >>>>>>line 314, in __init__ > >>>>>> self.create_connection() > >>>>>> File > >>>>>>"/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", > >>>>>>line 862, in create_connection > >>>>>> autobind=self.ldapi) > >>>>>> File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line > >>>>>>66, in connect > >>>>>> conn = self.create_connection(*args, **kw) > >>>>>> File > >>>>>>"/usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py", line > >>>>>>188, in create_connection > >>>>>> client_controls=clientctrls) > >>>>>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", > >>>>>>line > >>>>>>1074, in external_bind > >>>>>> '', auth_tokens, server_controls, client_controls) > >>>>>> File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ > >>>>>> self.gen.throw(type, value, traceback) > >>>>>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", > >>>>>>line > >>>>>>976, in error_handler > >>>>>> error=info) > >>>>>>NetworkError: cannot connect to > >>>>>>'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': > >>>>>> > >>>>>>2015-05-20T03:50:41Z DEBUG Traceback (most recent call last): > >>>>>> File > >>>>>>"/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > >>>>>>line > >>>>>>388, in start_creation > >>>>>> run_step(full_msg, method) > >>>>>> File > >>>>>>"/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > >>>>>>line > >>>>>>378, in run_step > >>>>>> method() > >>>>>> File > >>>>>>"/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", > >>>>>> > >>>>>>line 315, in __upgrade > >>>>>> raise RuntimeError(e) > >>>>>>RuntimeError: cannot connect to > >>>>>>'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': > >>>>>> > >>>>>>Reason was the ipa-server-install tried to connect before DS was > >>>>>>ready. > >>>>>> > >>>>>>The patch adds waiting until DS is ready. > >>>>>> > >>>>>>Patch attached. > >>>>>> > >>>>>>Fraser can you please check if this fix works? I can't reproduce it. > >>>>>>Thank you, Martin^2. > >>>>>> > >>>>>ACK; fixes the issue for me. > >>>>> > >>>>>One minor comment: > >>>>> > >>>>>>+ def __start(self): > >>>>>>+ super(IPAUpgrade, self).start() > >>>>>> > >>>>>> def __stop_instance(self): > >>>>>> """Stop only the main DS instance""" > >>>>>>@@ -187,7 +185,7 @@ class IPAUpgrade(service.Service): > >>>>>> self.step("saving configuration", self.__save_config) > >>>>>> self.step("disabling listeners", self.__disable_listeners) > >>>>>> self.step("enabling DS global lock", > >>>>>>self.__enable_ds_global_write_lock) > >>>>>>- self.step("starting directory server", self.__start_nowait) > >>>>>>+ self.step("starting directory server", self.__start) > >>>>>I think you can just say `self.start' and remove `__start' function. > >>>>> > >>>>>Cheers, > >>>>>Fraser > >>>>> > >>>>Pushed to master: 3d17bf8e639616893d6937d98662ccc7541d1e23 > >>>This semi-breaks ipa-server-install for me: > >>> > >>>Configuring directory server (dirsrv): Estimated time 1 minute > >>> [1/38]: creating directory server user > >>> [2/38]: creating directory server instance > >>>ipa : CRITICAL Failed to restart the directory server ([Errno > >>>2] No > >>>such file or directory). See the installation log for details. > >>> [3/38]: adding default schema > >>> [4/38]: enabling memberof plugin > >>> > >>>It would be nice to check if the socket exists before waiting for it. > >>> > >>This (non-catastrophic but annoying) regression occurred for me too. > >>I wasn't paying enough attention to ipa-server-install before I > >>ACKed the patch :/ > >> > >>>-- > >>>Jan Cholasta > >Hello, > > > >this patch fixes the issue. > > > > > > > > > > > Updated patch attached > > -- > Martin Basti > > From 25c90638f02d36f3d992b6b20dbb66afb09e74f2 Mon Sep 17 00:00:00 2001 > From: Martin Basti > Date: Mon, 25 May 2015 09:01:42 +0200 > Subject: [PATCH] Fix: use DS socket check only for upgrade > > To detect if DS server is running, use the slapd socket for upgrade, and the LDAP port > for installation. > > Without enabled LDAPi socket checking doesnt work. > > https://fedorahosted.org/freeipa/ticket/4904 > --- > ipaplatform/redhat/services.py | 43 ++++++++++++++++++++++++------------ > ipaserver/install/upgradeinstance.py | 3 ++- > 2 files changed, 31 insertions(+), 15 deletions(-) > > diff --git a/ipaplatform/redhat/services.py b/ipaplatform/redhat/services.py > index 565bf1fdef27e9a780ad2e2638b5051a95782bd2..757908f9581d5f04176dd5243fc64bec4c074c7f 100644 > --- a/ipaplatform/redhat/services.py > +++ b/ipaplatform/redhat/services.py > @@ -25,6 +25,7 @@ Contains Red Hat OS family-specific service class implementations. > import os > import time > import xml.dom.minidom > +import contextlib > > from ipaplatform.tasks import tasks > from ipaplatform.base import services as base_services > @@ -124,7 +125,8 @@ class RedHatDirectoryService(RedHatService): > > return True > > - def restart(self, instance_name="", capture_output=True, wait=True): > + def restart(self, instance_name="", capture_output=True, wait=True, > + ldapi=False): > # We need to explicitly enable instances to install proper symlinks as > # dirsrv.target.wants/ dependencies. Standard systemd service class does it > # on enable() method call. Unfortunately, ipa-server-install does not do > @@ -150,22 +152,35 @@ class RedHatDirectoryService(RedHatService): > os.unlink(srv_lnk) > os.symlink(srv_etc, srv_lnk) > > - super(RedHatDirectoryService, self).restart(instance_name, > - capture_output=capture_output, wait=wait) > + with self.__wait(instance_name, wait, ldapi) as wait: > + super(RedHatDirectoryService, self).restart( > + instance_name, capture_output=capture_output, wait=wait) > > - def wait_for_open_ports(self, instance_name=""): > - if instance_name.endswith('.service'): > - instance_name = instance_name[:-8] > - if instance_name.startswith('dirsrv@'): > - instance_name = instance_name[7:] > + def start(self, instance_name="", capture_output=True, wait=True, > + ldapi=False): > + with self.__wait(instance_name, wait, ldapi) as wait: > + super(RedHatDirectoryService, self).start( > + instance_name, capture_output=capture_output, wait=wait) > > - if instance_name: > - > - ipautil.wait_for_open_socket( > - paths.SLAPD_INSTANCE_SOCKET_TEMPLATE % instance_name, > - self.api.env.startup_timeout) > + @contextlib.contextmanager > + def __wait(self, instance_name, wait, ldapi): > + if ldapi: > + instance_name = self.service_instance(instance_name) > + if instance_name.endswith('.service'): > + instance_name = instance_name[:-8] > + if instance_name.startswith('dirsrv'): > + # this is intentional, return the empty string if the instance > + # name is 'dirsrv' > + instance_name = instance_name[7:] > + if not instance_name: > + ldapi = False > + if ldapi: > + yield False > + socket_name = paths.SLAPD_INSTANCE_SOCKET_TEMPLATE % instance_name > + ipautil.wait_for_open_socket(socket_name, > + self.api.env.startup_timeout) > else: > - super(RedHatDirectoryService, self).wait_for_open_ports() > + yield wait > > > class RedHatIPAService(RedHatService): > diff --git a/ipaserver/install/upgradeinstance.py b/ipaserver/install/upgradeinstance.py > index d58c934bc1bd926c0c0c068086c746ac28e8c737..10f7c2ce0c25e733fb572502add82eedadf73d05 100644 > --- a/ipaserver/install/upgradeinstance.py > +++ b/ipaserver/install/upgradeinstance.py > @@ -24,6 +24,7 @@ import shutil > import random > import traceback > from ipaplatform.paths import paths > +from ipaplatform import services > from ipapython.ipa_log_manager import * > from ipapython import ipaldap > > @@ -172,7 +173,7 @@ class IPAUpgrade(service.Service): > self.realm = realm_name > > def __start(self): > - super(IPAUpgrade, self).start() > + services.service(self.service_name).start(self.serverid, ldapi=True) > > def __stop_instance(self): > """Stop only the main DS instance""" > -- > 2.1.0 > I tested 0259.1 (it worked for install and update) but not 0259.2 yet. 0259.2 looks OK though; ACK if tested for install and update. Fraser From mbabinsk at redhat.com Mon May 25 14:19:42 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 25 May 2015 16:19:42 +0200 Subject: [Freeipa-devel] Yet another user certificates/Smart Card thread In-Reply-To: <55632A1E.2000802@redhat.com> References: <55631BCB.8090608@redhat.com> <55631FF5.3080008@redhat.com> <55632A1E.2000802@redhat.com> Message-ID: <55632F7E.4050806@redhat.com> On 05/25/2015 03:56 PM, Martin Kosek wrote: > On 05/25/2015 03:13 PM, Jan Cholasta wrote: >> Hi, >> >> Dne 25.5.2015 v 14:55 Martin Babinsky napsal(a): >>> Hello all, long post ahead! >>> >>> I became a proud owner of https://fedorahosted.org/freeipa/ticket/4238, >>> and while Martin's design page >>> (http://www.freeipa.org/page/V4/User_Certificates) brings a >>> comprehensive overview of what should be done, there are still some gray >>> areas we should address both in the design page and the actual >>> implementation. >>> >>> These are the things that were agreed upon in previous thread(s): >>> >>> 1.) If the whole user certificates are available, the should be stored >>> directly in the user entry as an attribute of the following format: >>> >>> "userCertificate;binary;$id", >>> >>> where "id" should be an unique identifier. IIRC we agreed that the >>> first/last 4 bytes of cert's SHA512 hash should fill the 'id' role >>> nicely. During user authentication the whole binary blob would be >>> matched (pspacek pointed out that the cost of this operation is >>> acceptable). >>> >>> 2.) In addition, or when the user certs are stored externally, we should >>> store the certificate metadata in the user entry. These metadata should >>> be represented by "userCertAttrs;$id;$attr" attributes, where $attr >>> subtype corresponds to the type of metadata (issuer, serial no., profile >>> id, certificate hash etc.). The authentication/lookup would require some >>> custom matching rule to fetch the correct cert. >>> >>> Point 1. seems clear to me, we need to implement an index for >>> userCertificate attribute in DS and modify 'user-add/mod' commands to >>> allow for direct enrollment through API ("--usercertificate" option). >>> >>> Point 2. requires more work: we need to add a new attribute >>> "userCertAttrs" to the schema and create DS index/custom matching rule >>> for searching. I'm also not quite sure how to approach the task of >>> getting these metadata from external storage and putting them to the >>> user entry. >> >> Both points are obsolete. See the design page you linked for the current plan. > > Huh, where that came from Martin? Did you have some cached old version of the > design page? I am just wondering what went wrong, as this is something I > deleted from that page month ago. > I probably got confused during re-reading threads on 'ipa-samba-team-list'. So the only thing we require (for now) is the ability to search and store full user certificates in the user entry? Did I get it right? -- Martin^3 Babinsky From ftweedal at redhat.com Mon May 25 14:26:07 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 26 May 2015 00:26:07 +1000 Subject: [Freeipa-devel] Yet another user certificates/Smart Card thread In-Reply-To: <55632A1E.2000802@redhat.com> References: <55631BCB.8090608@redhat.com> <55631FF5.3080008@redhat.com> <55632A1E.2000802@redhat.com> Message-ID: <20150525142607.GD13469@dhcp-40-8.bne.redhat.com> On Mon, May 25, 2015 at 03:56:46PM +0200, Martin Kosek wrote: > On 05/25/2015 03:13 PM, Jan Cholasta wrote: > > Hi, > > > > Dne 25.5.2015 v 14:55 Martin Babinsky napsal(a): > >> Hello all, long post ahead! > >> > >> I became a proud owner of https://fedorahosted.org/freeipa/ticket/4238, > >> and while Martin's design page > >> (http://www.freeipa.org/page/V4/User_Certificates) brings a > >> comprehensive overview of what should be done, there are still some gray > >> areas we should address both in the design page and the actual > >> implementation. > >> > >> These are the things that were agreed upon in previous thread(s): > >> > >> 1.) If the whole user certificates are available, the should be stored > >> directly in the user entry as an attribute of the following format: > >> > >> "userCertificate;binary;$id", > >> > >> where "id" should be an unique identifier. IIRC we agreed that the > >> first/last 4 bytes of cert's SHA512 hash should fill the 'id' role > >> nicely. During user authentication the whole binary blob would be > >> matched (pspacek pointed out that the cost of this operation is > >> acceptable). > >> > >> 2.) In addition, or when the user certs are stored externally, we should > >> store the certificate metadata in the user entry. These metadata should > >> be represented by "userCertAttrs;$id;$attr" attributes, where $attr > >> subtype corresponds to the type of metadata (issuer, serial no., profile > >> id, certificate hash etc.). The authentication/lookup would require some > >> custom matching rule to fetch the correct cert. > >> > >> Point 1. seems clear to me, we need to implement an index for > >> userCertificate attribute in DS and modify 'user-add/mod' commands to > >> allow for direct enrollment through API ("--usercertificate" option). > >> > >> Point 2. requires more work: we need to add a new attribute > >> "userCertAttrs" to the schema and create DS index/custom matching rule > >> for searching. I'm also not quite sure how to approach the task of > >> getting these metadata from external storage and putting them to the > >> user entry. > > > > Both points are obsolete. See the design page you linked for the current plan. > > Huh, where that came from Martin? Did you have some cached old version of the > design page? I am just wondering what went wrong, as this is something I > deleted from that page month ago. > +1 ; we will just store the certificate(s) in the userCertificate attribute. > > > >> > >> These are the questions that should be addressed in a broader discussion: > >> > >> What is the relation to Fraser's work (cert profiles/sub-CAs)? I have > >> seen that the recent iteration of Fraser's patches (0010-3 and 0011-3) > >> add some ACIs and attributes/requests related to user certificates. I > >> suppose that the only way the user certs are related to cert profile > >> will be that there will be a profile ID stored either in cert itself, or > >> as a separate userCertAttr;$id;profileId attribute in user entry. > >> For the avoidance of doubt, there well be no way to query which profile was used to issue a certificate in the near term. Dogtag does store this information, but at the moment we are not planning to use it or expose it in IPA. > >> What to do with user certs when the entry is deleted? Should we revoke > >> them or let them expire? > > > > See . > > There was not really any conclusion to that discussion. I am in favour of a ``{user,host,service}-{del,mod} --[no-]revoke[=$REASON]`` argument that says what to do when we delete a certificate, and allows specifying the revocation reason. I don't have a strong opinion on whether the default should be to revoke or not revoke, but I do think that the default revocation reason should be unspecified(0). superseded(4) is no longer appropriate. Cheers, Fraser > >> > >> In the case that the user cert is stored in a separate location and not > >> available to FreeIPA, how will we get the required attributes (see point > >> 2) to the user entry in LDAP tree? > >> > >> How much of this work should actually be done in 4.2 timeframe? I guess > >> all work related to point 1 will be done, but what about other features? > > > > We need an API to modify the userCertificate attribute of users/hosts/services. > > Should be easy to do. > > What API would you propose? Just using the current "--certificate" option we > have for hosts/services, but extending it so that it can also store other, > non-IPA certificates? > > Right now, I can do only this: > > # ipa host-mod test.host.test > --certificate=MIIDYTCCAkmgAwIBAgIJAIz9FKFUvzv0MA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAkNaMQ0wCwYDVQQHDARCcm5vMRAwDgYDVQQKDAdSZWQgSGF0MRcwFQYDVQQDDA50ZXN0Lmhvc3QudGVzdDAeFw0xNTA1MjUxMzQwMTVaFw0xNTA2MjQxMzQwMTVaMEcxCzAJBgNVBAYTAkNaMQ0wCwYDVQQHDARCcm5vMRAwDgYDVQQKDAdSZWQgSGF0MRcwFQYDVQQDDA50ZXN0Lmhvc3QudGVzdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOi4goei6KU8dU2VVqzu9OA+6RJEAdpawp3KvCbTnGPJJx7SzgguDPj5L3+tx9kjyYKD1L7eAWZHv6QSNuCe4kixIg/iamyY8OOt7wkGHzSzDGm4gVheD6OCuQ2OmwcDebysfINUugQIvUCgxAxRV6fZhQzvtMnao4N+sclrnfi+Njz1Otf0/UqVG0Le0tHSTFRA7A8ECOCMpY7TLSr8VViRp0A2pX/dr3tgvQO+EsZUwKVKSQcBGJQ3MW/Cn9NPLj03zESG8305Q6YLpQVyFHTCJJi/ZLEJjiK8emmq+6K4X7/5x6zlmJZ5llY3x3b0cJ44u5sXqUqvuhHDMbyxiKMCAwEAAaNQME4wHQYDVR0OBBYEFE+42oRjb/cmPRAU+tejUwkvzIubMB8GA1UdIwQYMBaAFE+42oRjb/cmPRAU+tejUwkvzIubMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEBAHqUTsVcr9h9/rjPTLQ2GWMmYjAKR0SpN+EnXT4cMLTyF8ZmN6ZlrNnUJXC4uqhTTwribxkNfp2sTABa9i3CrsWNGKM2RZj5Fz2H03p+ZMFm0JpDjpu1sKQ064pvliHaiA/w2ejDH9kgNMU6+Csn5cIndOzHVrf! > 2NtMgTishM > IkUKGJGhPV4lL+WKjkFVKlhKNAYcmsELkIJqISL/W6TEzPOxFSSrGi4QNP4ekaL+hhAACBP+ecRYel7kRcBPddwvtzOt+MusHPEeHdZpmyubs0UXI2OGcDT21SC4ydjOADnv/gTxdZFarJKWAQlyTEj9X1EzBrv6uQuprwGQjpOE2w= > ipa: ERROR: Certificate operation cannot be completed: Issuer > "CN=test.host.test,O=Red Hat,L=Brno,C=CZ" does not match the expected issuer > > Martin From mkosek at redhat.com Mon May 25 14:26:59 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 25 May 2015 16:26:59 +0200 Subject: [Freeipa-devel] Yet another user certificates/Smart Card thread In-Reply-To: <55632F7E.4050806@redhat.com> References: <55631BCB.8090608@redhat.com> <55631FF5.3080008@redhat.com> <55632A1E.2000802@redhat.com> <55632F7E.4050806@redhat.com> Message-ID: <55633133.4090802@redhat.com> On 05/25/2015 04:19 PM, Martin Babinsky wrote: > On 05/25/2015 03:56 PM, Martin Kosek wrote: >> On 05/25/2015 03:13 PM, Jan Cholasta wrote: >>> Hi, >>> >>> Dne 25.5.2015 v 14:55 Martin Babinsky napsal(a): >>>> Hello all, long post ahead! >>>> >>>> I became a proud owner of https://fedorahosted.org/freeipa/ticket/4238, >>>> and while Martin's design page >>>> (http://www.freeipa.org/page/V4/User_Certificates) brings a >>>> comprehensive overview of what should be done, there are still some gray >>>> areas we should address both in the design page and the actual >>>> implementation. >>>> >>>> These are the things that were agreed upon in previous thread(s): >>>> >>>> 1.) If the whole user certificates are available, the should be stored >>>> directly in the user entry as an attribute of the following format: >>>> >>>> "userCertificate;binary;$id", >>>> >>>> where "id" should be an unique identifier. IIRC we agreed that the >>>> first/last 4 bytes of cert's SHA512 hash should fill the 'id' role >>>> nicely. During user authentication the whole binary blob would be >>>> matched (pspacek pointed out that the cost of this operation is >>>> acceptable). >>>> >>>> 2.) In addition, or when the user certs are stored externally, we should >>>> store the certificate metadata in the user entry. These metadata should >>>> be represented by "userCertAttrs;$id;$attr" attributes, where $attr >>>> subtype corresponds to the type of metadata (issuer, serial no., profile >>>> id, certificate hash etc.). The authentication/lookup would require some >>>> custom matching rule to fetch the correct cert. >>>> >>>> Point 1. seems clear to me, we need to implement an index for >>>> userCertificate attribute in DS and modify 'user-add/mod' commands to >>>> allow for direct enrollment through API ("--usercertificate" option). >>>> >>>> Point 2. requires more work: we need to add a new attribute >>>> "userCertAttrs" to the schema and create DS index/custom matching rule >>>> for searching. I'm also not quite sure how to approach the task of >>>> getting these metadata from external storage and putting them to the >>>> user entry. >>> >>> Both points are obsolete. See the design page you linked for the current plan. >> >> Huh, where that came from Martin? Did you have some cached old version of the >> design page? I am just wondering what went wrong, as this is something I >> deleted from that page month ago. >> > I probably got confused during re-reading threads on 'ipa-samba-team-list'. > > So the only thing we require (for now) is the ability to search and store full > user certificates in the user entry? Did I get it right? If you read freeipa-devel more closely, you would see I already sent proposal for this feature almost a month ago :-) http://www.redhat.com/archives/freeipa-devel/2015-May/msg00001.html HTH, Martin From tbabej at redhat.com Mon May 25 14:39:02 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 25 May 2015 16:39:02 +0200 Subject: [Freeipa-devel] [PATCH] 0178 Fix AD trusts in Fedora 22 In-Reply-To: <20150512140352.GO5152@redhat.com> References: <20150508130753.GA4748@onega.vda.li> <20150512053707.GF5152@redhat.com> <20150512124615.GN5152@redhat.com> <20150512140352.GO5152@redhat.com> Message-ID: <55633406.7040807@redhat.com> On 05/12/2015 04:03 PM, Alexander Bokovoy wrote: > On Tue, 12 May 2015, Alexander Bokovoy wrote: >> On Tue, 12 May 2015, Alexander Bokovoy wrote: >>> On Fri, 08 May 2015, Alexander Bokovoy wrote: >>>> Hi, >>>> >>>> attached patch fixes issues with Samba 4.2 in Fedora 22. >>>> >>>> See commit message for the details. Note that you'll >>>> also need Samba fixes from >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1219832 >>>> to test the patch. >>>> >>>> Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1219834 >>> An update is available in Bodhi: >>> https://admin.fedoraproject.org/updates/samba-4.2.1-8.fc22,freeipa-4.1.4-3.fc22 >>> >>> >>> Please test and support. >> Attached please find an update of the patch 0178. I've found one typo >> which was missed in the original version due to exception handling. >> >> I'll update bodhi request when builds are ready. > Updated bodhi request: > https://admin.fedoraproject.org/updates/samba-4.2.1-8.fc22,freeipa-4.1.4-4.fc22 > > > Please test! > Works fine in my testing, code wise looks fine. Thanks for the catch! ACK. Pushed to: master: 5fd8e53f66bcc96afbcf08686c345e6f2b7ee775 ipa-4-1: d74f938bde65d2fad4dde06c56d7889fa053c7db Tomas From jcholast at redhat.com Mon May 25 14:40:06 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 25 May 2015 16:40:06 +0200 Subject: [Freeipa-devel] Yet another user certificates/Smart Card thread In-Reply-To: <20150525142607.GD13469@dhcp-40-8.bne.redhat.com> References: <55631BCB.8090608@redhat.com> <55631FF5.3080008@redhat.com> <55632A1E.2000802@redhat.com> <20150525142607.GD13469@dhcp-40-8.bne.redhat.com> Message-ID: <55633446.9020709@redhat.com> Dne 25.5.2015 v 16:26 Fraser Tweedale napsal(a): > On Mon, May 25, 2015 at 03:56:46PM +0200, Martin Kosek wrote: >> On 05/25/2015 03:13 PM, Jan Cholasta wrote: >>> Hi, >>> >>> Dne 25.5.2015 v 14:55 Martin Babinsky napsal(a): >>>> Hello all, long post ahead! >>>> >>>> I became a proud owner of https://fedorahosted.org/freeipa/ticket/4238, >>>> and while Martin's design page >>>> (http://www.freeipa.org/page/V4/User_Certificates) brings a >>>> comprehensive overview of what should be done, there are still some gray >>>> areas we should address both in the design page and the actual >>>> implementation. >>>> >>>> These are the things that were agreed upon in previous thread(s): >>>> >>>> 1.) If the whole user certificates are available, the should be stored >>>> directly in the user entry as an attribute of the following format: >>>> >>>> "userCertificate;binary;$id", >>>> >>>> where "id" should be an unique identifier. IIRC we agreed that the >>>> first/last 4 bytes of cert's SHA512 hash should fill the 'id' role >>>> nicely. During user authentication the whole binary blob would be >>>> matched (pspacek pointed out that the cost of this operation is >>>> acceptable). >>>> >>>> 2.) In addition, or when the user certs are stored externally, we should >>>> store the certificate metadata in the user entry. These metadata should >>>> be represented by "userCertAttrs;$id;$attr" attributes, where $attr >>>> subtype corresponds to the type of metadata (issuer, serial no., profile >>>> id, certificate hash etc.). The authentication/lookup would require some >>>> custom matching rule to fetch the correct cert. >>>> >>>> Point 1. seems clear to me, we need to implement an index for >>>> userCertificate attribute in DS and modify 'user-add/mod' commands to >>>> allow for direct enrollment through API ("--usercertificate" option). >>>> >>>> Point 2. requires more work: we need to add a new attribute >>>> "userCertAttrs" to the schema and create DS index/custom matching rule >>>> for searching. I'm also not quite sure how to approach the task of >>>> getting these metadata from external storage and putting them to the >>>> user entry. >>> >>> Both points are obsolete. See the design page you linked for the current plan. >> >> Huh, where that came from Martin? Did you have some cached old version of the >> design page? I am just wondering what went wrong, as this is something I >> deleted from that page month ago. >> > +1 ; we will just store the certificate(s) in the userCertificate > attribute. > >>> >>>> >>>> These are the questions that should be addressed in a broader discussion: >>>> >>>> What is the relation to Fraser's work (cert profiles/sub-CAs)? I have >>>> seen that the recent iteration of Fraser's patches (0010-3 and 0011-3) >>>> add some ACIs and attributes/requests related to user certificates. I >>>> suppose that the only way the user certs are related to cert profile >>>> will be that there will be a profile ID stored either in cert itself, or >>>> as a separate userCertAttr;$id;profileId attribute in user entry. >>>> > For the avoidance of doubt, there well be no way to query which > profile was used to issue a certificate in the near term. Dogtag > does store this information, but at the moment we are not planning > to use it or expose it in IPA. > >>>> What to do with user certs when the entry is deleted? Should we revoke >>>> them or let them expire? >>> >>> See . >>> > > There was not really any conclusion to that discussion. I am in > favour of a ``{user,host,service}-{del,mod} --[no-]revoke[=$REASON]`` > argument that says what to do when we delete a certificate, and > allows specifying the revocation reason. I don't think we should add such option, for the same reasons why we did not add the option to override the "store certificate in entry" policy in cert-request. > > I don't have a strong opinion on whether the default should be to > revoke or not revoke, but I do think that the default revocation > reason should be unspecified(0). superseded(4) is no longer > appropriate. I would rather wait for Dogtag to implement the profile querying interface before doing anything and just not revoke certificates for now. > > Cheers, > Fraser > >>>> >>>> In the case that the user cert is stored in a separate location and not >>>> available to FreeIPA, how will we get the required attributes (see point >>>> 2) to the user entry in LDAP tree? >>>> >>>> How much of this work should actually be done in 4.2 timeframe? I guess >>>> all work related to point 1 will be done, but what about other features? >>> >>> We need an API to modify the userCertificate attribute of users/hosts/services. >>> Should be easy to do. >> >> What API would you propose? Just using the current "--certificate" option we >> have for hosts/services, but extending it so that it can also store other, >> non-IPA certificates? >> >> Right now, I can do only this: >> >> # ipa host-mod test.host.test >> --certificate=MIIDYTCCAkmgAwIBAgIJAIz9FKFUvzv0MA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAkNaMQ0wCwYDVQQHDARCcm5vMRAwDgYDVQQKDAdSZWQgSGF0MRcwFQYDVQQDDA50ZXN0Lmhvc3QudGVzdDAeFw0xNTA1MjUxMzQwMTVaFw0xNTA2MjQxMzQwMTVaMEcxCzAJBgNVBAYTAkNaMQ0wCwYDVQQHDARCcm5vMRAwDgYDVQQKDAdSZWQgSGF0MRcwFQYDVQQDDA50ZXN0Lmhvc3QudGVzdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOi4goei6KU8dU2VVqzu9OA+6RJEAdpawp3KvCbTnGPJJx7SzgguDPj5L3+tx9kjyYKD1L7eAWZHv6QSNuCe4kixIg/iamyY8OOt7wkGHzSzDGm4gVheD6OCuQ2OmwcDebysfINUugQIvUCgxAxRV6fZhQzvtMnao4N+sclrnfi+Njz1Otf0/UqVG0Le0tHSTFRA7A8ECOCMpY7TLSr8VViRp0A2pX/dr3tgvQO+EsZUwKVKSQcBGJQ3MW/Cn9NPLj03zESG8305Q6YLpQVyFHTCJJi/ZLEJjiK8emmq+6K4X7/5x6zlmJZ5llY3x3b0cJ44u5sXqUqvuhHDMbyxiKMCAwEAAaNQME4wHQYDVR0OBBYEFE+42oRjb/cmPRAU+tejUwkvzIubMB8GA1UdIwQYMBaAFE+42oRjb/cmPRAU+tejUwkvzIubMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEBAHqUTsVcr9h9/rjPTLQ2GWMmYjAKR0SpN+EnXT4cMLTyF8ZmN6ZlrNnUJXC4uqhTTwribxkNfp2sTABa9i3CrsWNGKM2RZj5Fz2H03p+ZMFm0JpDjpu1sKQ064pvliHaiA/w2ejDH9kgNMU6+Csn5cIndOzH! Vrf! >> 2NtMgTishM >> IkUKGJGhPV4lL+WKjkFVKlhKNAYcmsELkIJqISL/W6TEzPOxFSSrGi4QNP4ekaL+hhAACBP+ecRYel7kRcBPddwvtzOt+MusHPEeHdZpmyubs0UXI2OGcDT21SC4ydjOADnv/gTxdZFarJKWAQlyTEj9X1EzBrv6uQuprwGQjpOE2w= >> ipa: ERROR: Certificate operation cannot be completed: Issuer >> "CN=test.host.test,O=Red Hat,L=Brno,C=CZ" does not match the expected issuer >> >> Martin -- Jan Cholasta From mbasti at redhat.com Mon May 25 14:46:23 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 25 May 2015 16:46:23 +0200 Subject: [Freeipa-devel] [PATCH 0258] Server Upgrade: move code from ipa-upgrade config into separate module In-Reply-To: <555F558E.9060503@redhat.com> References: <555F558E.9060503@redhat.com> Message-ID: <556335BF.80507@redhat.com> On 22/05/15 18:13, Martin Basti wrote: > IPA services upgrade is executed only by ipa-server-upgrade, > ipa-upgradeconfig will not work. > > Patch attached. > > https://fedorahosted.org/freeipa/ticket/4904 > > > Updated patch attached. -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0258.2-Server-Upgrade-Move-code-from-ipa-upgradeconfig-to-s.patch Type: text/x-patch Size: 63195 bytes Desc: not available URL: From mbabinsk at redhat.com Mon May 25 14:58:29 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 25 May 2015 16:58:29 +0200 Subject: [Freeipa-devel] [PATCH 0036] merge KRA installation machinery to a single module In-Reply-To: <555D944B.1050001@redhat.com> References: <555B7FB0.6030809@redhat.com> <555D944B.1050001@redhat.com> Message-ID: <55633895.7000405@redhat.com> On 05/21/2015 10:16 AM, Martin Babinsky wrote: > On 05/19/2015 08:23 PM, Martin Babinsky wrote: >> 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. >> >> >> > Attaching rebased patch that should apply cleanly on current master > without prerequisites. > > > Attaching updated patch. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0036.2-merge-KRA-installation-machinery-to-a-single-module.patch Type: text/x-patch Size: 13668 bytes Desc: not available URL: From tbabej at redhat.com Mon May 25 15:15:11 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 25 May 2015 17:15:11 +0200 Subject: [Freeipa-devel] [PATCH 0325] Add Domain Level feature In-Reply-To: <5562FC98.5040109@redhat.com> References: <5554643E.4030600@redhat.com> <55546F6C.4060108@redhat.com> <555B390B.6000907@redhat.com> <555B3C61.7080508@redhat.com> <555B3F67.3040604@redhat.com> <555B3FFE.5040806@redhat.com> <555B4112.202@redhat.com> <555B41C8.7070503@redhat.com> <555B43BB.90404@redhat.com> <555E0572.8000600@redhat.com> <555EB9E7.3020800@redhat.com> <555F06AA.50206@redhat.com> <5562B380.8070609@redhat.com> <5562FC98.5040109@redhat.com> Message-ID: <55633C7F.1090103@redhat.com> On 05/25/2015 12:42 PM, Tomas Babej wrote: > > > On 05/25/2015 07:30 AM, Jan Cholasta wrote: >> Dne 22.5.2015 v 12:36 Petr Vobornik napsal(a): >>> On 05/22/2015 07:08 AM, Jan Cholasta wrote: >>>> Dne 21.5.2015 v 18:18 Tomas Babej napsal(a): >>>>> >>>>> >>>>> On 05/19/2015 04:07 PM, Tomas Babej wrote: >>>>>> >>>>>> >>>>>> 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 >>>>> >>>>> A new iteration of the patch, including the server-side checks for the >>>>> installers. >>>>> >>>>> Tomas >>>> >>>> 1) https://www.redhat.com/archives/freeipa-devel/2015-May/msg00228.html >>>> - I still don't agree that the plugin should be based on LDAPObject. >>> >>> On the other hand, with LDAPObject base, Web UI for this feature is much >>> more simpler because it can rely on existing conventions. >> >> Following this logic, should *everything* be based on LDAPObject, >> because it would satisfy the convetion? I don't think so. The convetion >> should not apply here, because domain level is conceptually *not* an >> object, it is a property. IMHO having a clean API should be preferred >> over implementation convenience. >> > > I do not have strong opinions over this. Attached version implements > a lightweight approach to the domainlevel related commands. > > Tomas > > > Fixes a slight schema glitch. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0325-9-Add-Domain-Level-feature.patch Type: text/x-patch Size: 25515 bytes Desc: not available URL: From jcholast at redhat.com Mon May 25 16:26:05 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 25 May 2015 18:26:05 +0200 Subject: [Freeipa-devel] [PATCH 0036] merge KRA installation machinery to a single module In-Reply-To: <55633895.7000405@redhat.com> References: <555B7FB0.6030809@redhat.com> <555D944B.1050001@redhat.com> <55633895.7000405@redhat.com> Message-ID: <55634D1D.6030500@redhat.com> Dne 25.5.2015 v 16:58 Martin Babinsky napsal(a): > On 05/21/2015 10:16 AM, Martin Babinsky wrote: >> On 05/19/2015 08:23 PM, Martin Babinsky wrote: >>> 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. >>> >>> >>> >> Attaching rebased patch that should apply cleanly on current master >> without prerequisites. >> >> >> > Attaching updated patch. > Thanks, ACK. Pushed to master: 6a4b428120c2e351ad0f1b4573f50b106844b1fd -- Jan Cholasta From jcholast at redhat.com Mon May 25 16:35:16 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 25 May 2015 18:35:16 +0200 Subject: [Freeipa-devel] [PATCH 0258] Server Upgrade: move code from ipa-upgrade config into separate module In-Reply-To: <556335BF.80507@redhat.com> References: <555F558E.9060503@redhat.com> <556335BF.80507@redhat.com> Message-ID: <55634F44.4010602@redhat.com> Dne 25.5.2015 v 16:46 Martin Basti napsal(a): > On 22/05/15 18:13, Martin Basti wrote: >> IPA services upgrade is executed only by ipa-server-upgrade, >> ipa-upgradeconfig will not work. >> >> Patch attached. >> >> https://fedorahosted.org/freeipa/ticket/4904 >> >> >> > Updated patch attached. Thanks, ACK. Pushed to master: 027515230a93a7a60983d3eca26a97a0d9c3610e -- Jan Cholasta From mkosek at redhat.com Tue May 26 05:49:10 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 26 May 2015 07:49:10 +0200 Subject: [Freeipa-devel] Yet another user certificates/Smart Card thread In-Reply-To: <55633446.9020709@redhat.com> References: <55631BCB.8090608@redhat.com> <55631FF5.3080008@redhat.com> <55632A1E.2000802@redhat.com> <20150525142607.GD13469@dhcp-40-8.bne.redhat.com> <55633446.9020709@redhat.com> Message-ID: <55640956.30703@redhat.com> On 05/25/2015 04:40 PM, Jan Cholasta wrote: > Dne 25.5.2015 v 16:26 Fraser Tweedale napsal(a): >> On Mon, May 25, 2015 at 03:56:46PM +0200, Martin Kosek wrote: >>> On 05/25/2015 03:13 PM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> Dne 25.5.2015 v 14:55 Martin Babinsky napsal(a): >>>>> Hello all, long post ahead! >>>>> >>>>> I became a proud owner of https://fedorahosted.org/freeipa/ticket/4238, >>>>> and while Martin's design page >>>>> (http://www.freeipa.org/page/V4/User_Certificates) brings a >>>>> comprehensive overview of what should be done, there are still some gray >>>>> areas we should address both in the design page and the actual >>>>> implementation. >>>>> >>>>> These are the things that were agreed upon in previous thread(s): >>>>> >>>>> 1.) If the whole user certificates are available, the should be stored >>>>> directly in the user entry as an attribute of the following format: >>>>> >>>>> "userCertificate;binary;$id", >>>>> >>>>> where "id" should be an unique identifier. IIRC we agreed that the >>>>> first/last 4 bytes of cert's SHA512 hash should fill the 'id' role >>>>> nicely. During user authentication the whole binary blob would be >>>>> matched (pspacek pointed out that the cost of this operation is >>>>> acceptable). >>>>> >>>>> 2.) In addition, or when the user certs are stored externally, we should >>>>> store the certificate metadata in the user entry. These metadata should >>>>> be represented by "userCertAttrs;$id;$attr" attributes, where $attr >>>>> subtype corresponds to the type of metadata (issuer, serial no., profile >>>>> id, certificate hash etc.). The authentication/lookup would require some >>>>> custom matching rule to fetch the correct cert. >>>>> >>>>> Point 1. seems clear to me, we need to implement an index for >>>>> userCertificate attribute in DS and modify 'user-add/mod' commands to >>>>> allow for direct enrollment through API ("--usercertificate" option). >>>>> >>>>> Point 2. requires more work: we need to add a new attribute >>>>> "userCertAttrs" to the schema and create DS index/custom matching rule >>>>> for searching. I'm also not quite sure how to approach the task of >>>>> getting these metadata from external storage and putting them to the >>>>> user entry. >>>> >>>> Both points are obsolete. See the design page you linked for the current plan. >>> >>> Huh, where that came from Martin? Did you have some cached old version of the >>> design page? I am just wondering what went wrong, as this is something I >>> deleted from that page month ago. >>> >> +1 ; we will just store the certificate(s) in the userCertificate >> attribute. >> >>>> >>>>> >>>>> These are the questions that should be addressed in a broader discussion: >>>>> >>>>> What is the relation to Fraser's work (cert profiles/sub-CAs)? I have >>>>> seen that the recent iteration of Fraser's patches (0010-3 and 0011-3) >>>>> add some ACIs and attributes/requests related to user certificates. I >>>>> suppose that the only way the user certs are related to cert profile >>>>> will be that there will be a profile ID stored either in cert itself, or >>>>> as a separate userCertAttr;$id;profileId attribute in user entry. >>>>> >> For the avoidance of doubt, there well be no way to query which >> profile was used to issue a certificate in the near term. Dogtag >> does store this information, but at the moment we are not planning >> to use it or expose it in IPA. >> >>>>> What to do with user certs when the entry is deleted? Should we revoke >>>>> them or let them expire? >>>> >>>> See . >>>> >> >> There was not really any conclusion to that discussion. I am in >> favour of a ``{user,host,service}-{del,mod} --[no-]revoke[=$REASON]`` >> argument that says what to do when we delete a certificate, and >> allows specifying the revocation reason. > > I don't think we should add such option, for the same reasons why we did not > add the option to override the "store certificate in entry" policy in > cert-request. > >> >> I don't have a strong opinion on whether the default should be to >> revoke or not revoke, but I do think that the default revocation >> reason should be unspecified(0). superseded(4) is no longer >> appropriate. > > I would rather wait for Dogtag to implement the profile querying interface > before doing anything and just not revoke certificates for now. Well, whatever we do, it should not be a regression. So, we can change the global default (or make it different for upgraded/new installations as with some ACIs for PermissionsV2) but we should still have some possibility for a user to configure the behavior. FreeIPA should be still able to revoke certs stored in user/service/host entry during object-del/object-disable. What should we do in this case? Option for "ipa config-*"? Martin From mkosek at redhat.com Tue May 26 05:55:00 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 26 May 2015 07:55:00 +0200 Subject: [Freeipa-devel] [PATCH] 496 Fix typo in ipa-server-upgrade man page Message-ID: <55640AB4.9020602@redhat.com> Pushed to master (oneliner): d0a330aa1ce250da3ab552f6517945c7cf871ad1 -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-496-fix-typo-in-ipa-server-upgrade-man-page.patch Type: text/x-patch Size: 812 bytes Desc: not available URL: From mbabinsk at redhat.com Tue May 26 07:37:29 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 26 May 2015 09:37:29 +0200 Subject: [Freeipa-devel] tbabej's [PATCH 0324] replica-manage: properly delete nested entries Message-ID: <556422B9.4020300@redhat.com> The attached patch contains fix for bug https://fedorahosted.org/freeipa/ticket/5019 which Tomas posted on freeipa-devel here: https://www.redhat.com/archives/freeipa-devel/2015-May/msg00045.html I have reviewed the patch and it works, so ACK. I have just changed the commit message to something more meaningful. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0324-replica-manage-Properly-delete-nested-entries.patch Type: text/x-patch Size: 2567 bytes Desc: not available URL: From pvoborni at redhat.com Tue May 26 07:53:25 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 26 May 2015 09:53:25 +0200 Subject: [Freeipa-devel] tbabej's [PATCH 0324] replica-manage: properly delete nested entries In-Reply-To: <556422B9.4020300@redhat.com> References: <556422B9.4020300@redhat.com> Message-ID: <55642675.9040601@redhat.com> On 05/26/2015 09:37 AM, Martin Babinsky wrote: > The attached patch contains fix for bug > https://fedorahosted.org/freeipa/ticket/5019 which Tomas posted on > freeipa-devel here: > > https://www.redhat.com/archives/freeipa-devel/2015-May/msg00045.html > > I have reviewed the patch and it works, so ACK. > > I have just changed the commit message to something more meaningful. > Pushed to: master: c5f319d3e8d1b5e500225af207ac247f75baea17 ipa-4-1: aa83d2011268195d2a183c1de67560536b83ff72 -- Petr Vobornik From thozza at redhat.com Tue May 26 08:17:43 2015 From: thozza at redhat.com (Tomas Hozza) Date: Tue, 26 May 2015 10:17:43 +0200 Subject: [Freeipa-devel] [PATCH 0368-0371] Support LDAP MODRDN for ordinary DNS records In-Reply-To: <555C3287.3080108@redhat.com> References: <555C3287.3080108@redhat.com> Message-ID: <55642C27.4020203@redhat.com> On 05/20/2015 09:06 AM, Petr Spacek wrote: > Hello, > > this patchset implements support for MODRDN for ordinary records. As noted in > ticket https://fedorahosted.org/bind-dyndb-ldap/ticket/123, we agreed > yesterday that renaming zones is out of scope and seems unnecessarily complex. > > This patch set depends on 'metadb' branch. It is also available from: > https://github.com/pspacek/bind-dyndb-ldap/tree/modrdn > > Thank you for your time! > I did formal review. Everything looks OK. ACK Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com From pvoborni at redhat.com Tue May 26 09:00:03 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 26 May 2015 11:00:03 +0200 Subject: [Freeipa-devel] [PATCH] manage replication topology in the shared tree In-Reply-To: <555F3B19.1040004@redhat.com> References: <552B84C5.80300@redhat.com> <55362C43.4020406@redhat.com> <55362FDC.7090104@redhat.com> <55519EAC.9000204@redhat.com> <555B2998.9020608@redhat.com> <555C8392.7010908@redhat.com> <555C84F2.7030500@redhat.com> <555C86F5.2080708@redhat.com> <555C8EB7.5030800@redhat.com> <555CAADB.1030306@redhat.com> <555DB9BA.6090001@redhat.com> <555F3B19.1040004@redhat.com> Message-ID: <55643613.5040102@redhat.com> On 05/22/2015 04:20 PM, Petr Vobornik wrote: > On 05/21/2015 12:55 PM, thierry bordaz wrote: >> On 05/20/2015 05:40 PM, Ludwig Krispenz wrote: >>> please find new versions of patches 0003 and 0005 for the topology >>> plugin. >>> >>> the ds plugin patch includes >>> - changes to match domain level patch >>> - remove trailing white spaces >>> - use proper oids for topology schema >>> >>> the install patch >>> - has the 70topology.ldif removed >> >> Hello Ludwig, >> >> I failed to do 'git am patch-0003', it returned a strange "Patch format >> detection failed.". >> However I was able to do 'git apply' and to review it. >> >> I focus on the points discussed during previous reviews. >> The patch is looking good to me. ACK Patch 0003 pushed to master: 25bf0c6e78dca62e7fa11cd654ed0d8675408176 Note that installation of replica with domain level 1 suffers from: https://fedorahosted.org/freeipa/ticket/5035 > > Patch 0005 looks good to me if we squash there attached patch(typo fixes). > > I think that both 0003 and 0005 could be pushed. But I'll do it when > testing with Domain Level patch is successful. Patch 0005 ACK Pushed to master: 4bcc2546d59041f0d09960d6f9d44ca68bd424e1 > > patch 0006 will be replaced with the one I'm working on. > >> >> thanks >> thierry -- Petr Vobornik From pvoborni at redhat.com Tue May 26 09:00:21 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 26 May 2015 11:00:21 +0200 Subject: [Freeipa-devel] Replication Topology plugin issues In-Reply-To: <55632A17.9050205@redhat.com> References: <55632A17.9050205@redhat.com> Message-ID: <55643625.4040106@redhat.com> On 05/25/2015 03:56 PM, Oleg Fayans wrote: > Hi, > > Playing around with the replication topology plugin, I've noticed a > couple of issues: > 1. around 50% of attempts to setup a replica of a freeipa master with > topology plugin enabled (domain level set to 1.0) end up with the > following error message in the stdoutput: > > [error] RuntimeError: One of the ldap service principals is missing. > Replication agreement cannot be converted. > Replication error message: Unable to acquire replicaLDAP error: No such > object > > I am not sure whether the reason is in the Topology Plugin itself or in > some of the latest changes in upstream, though. I have the same experience. It seems that data from master were replicated to new replica but new replica entries(host, services) were not replicated back to master. The installation then hangs on replica's check if its ldap service principal is on master. New ticket: https://fedorahosted.org/freeipa/ticket/5035 > > 2. Whenever this happens, master retains the information about the new > topology segment, even despite the replica setup was unsuccessful. IMHO, > we should have a way to notify the master about replica setup > faiures/aborts so that the master would automatically erase the > corresponding freshly-created segments in such cases. Not sure if we can rely on that because the chosen communication mechanism(what ever it might be) might suffer from the same root cause as the replica installation. > > 3. After this happens user is unable to delete the replication agreement > with the standard `ipa-replica-manage del` way: > $ ipa-replica-manage del replica1.pesen.net --force > Connection to 'replica1.pesen.net' failed: [Errno -2] Name or service > not known > Forcing removal of replica1.pesen.net > Skipping calculation to determine if one or more masters would be orphaned. > Deleting replication agreements between replica1.pesen.net and > newmaster.pesen.net > Failed to get list of agreements from 'replica1.pesen.net': [Errno -2] > Name or service not known > Forcing removal on 'newmaster.pesen.net' > Any DNA range on 'replica1.pesen.net' will be lost > There were issues removing a connection for replica1.pesen.net from > newmaster.pesen.net: Server is unwilling to perform: Entry is managed by > topology plugin.Deletion not allowed. > Failed to cleanup replica1.pesen.net entries: Not allowed on non-leaf entry this line was fixed by https://fedorahosted.org/freeipa/ticket/5019 . When this succeeds (master entry is deleted), topology plugin should delete the rest. I.e., with this patch I was able to delete the replica. That said, the output might want some love. > You may need to manually remove them from the tree > Failed to cleanup replica1.pesen.net DNS entries: no matching entry found > You may need to manually remove them from the tree > > IIRC upon one of the early discussions with Ludwig, this is yet to be > implemented. > -- Petr Vobornik From ofayans at redhat.com Tue May 26 09:21:17 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 26 May 2015 11:21:17 +0200 Subject: [Freeipa-devel] Replication Topology plugin issues In-Reply-To: <55643625.4040106@redhat.com> References: <55632A17.9050205@redhat.com> <55643625.4040106@redhat.com> Message-ID: <55643B0D.4090902@redhat.com> Thanks Petr! Did I understand correctly, that the master branch does not yet contain patches 0005 and 0006 from Ludwig, only the 0003 patch has been merged? I must apply them manually to get the full plugin functionality, right? On 05/26/2015 11:00 AM, Petr Vobornik wrote: > On 05/25/2015 03:56 PM, Oleg Fayans wrote: >> Hi, >> >> Playing around with the replication topology plugin, I've noticed a >> couple of issues: >> 1. around 50% of attempts to setup a replica of a freeipa master with >> topology plugin enabled (domain level set to 1.0) end up with the >> following error message in the stdoutput: >> >> [error] RuntimeError: One of the ldap service principals is missing. >> Replication agreement cannot be converted. >> Replication error message: Unable to acquire replicaLDAP error: No such >> object >> >> I am not sure whether the reason is in the Topology Plugin itself or in >> some of the latest changes in upstream, though. > > I have the same experience. It seems that data from master were > replicated to new replica but new replica entries(host, services) were > not replicated back to master. > > The installation then hangs on replica's check if its ldap service > principal is on master. > > New ticket: https://fedorahosted.org/freeipa/ticket/5035 > > >> >> 2. Whenever this happens, master retains the information about the new >> topology segment, even despite the replica setup was unsuccessful. IMHO, >> we should have a way to notify the master about replica setup >> faiures/aborts so that the master would automatically erase the >> corresponding freshly-created segments in such cases. > > Not sure if we can rely on that because the chosen communication > mechanism(what ever it might be) might suffer from the same root cause > as the replica installation. > >> >> 3. After this happens user is unable to delete the replication agreement >> with the standard `ipa-replica-manage del` way: >> $ ipa-replica-manage del replica1.pesen.net --force >> Connection to 'replica1.pesen.net' failed: [Errno -2] Name or service >> not known >> Forcing removal of replica1.pesen.net >> Skipping calculation to determine if one or more masters would be >> orphaned. >> Deleting replication agreements between replica1.pesen.net and >> newmaster.pesen.net >> Failed to get list of agreements from 'replica1.pesen.net': [Errno -2] >> Name or service not known >> Forcing removal on 'newmaster.pesen.net' >> Any DNA range on 'replica1.pesen.net' will be lost >> There were issues removing a connection for replica1.pesen.net from >> newmaster.pesen.net: Server is unwilling to perform: Entry is managed by >> topology plugin.Deletion not allowed. >> Failed to cleanup replica1.pesen.net entries: Not allowed on non-leaf >> entry > > this line was fixed by https://fedorahosted.org/freeipa/ticket/5019 . > When this succeeds (master entry is deleted), topology plugin should > delete the rest. I.e., with this patch I was able to delete the replica. > > That said, the output might want some love. > >> You may need to manually remove them from the tree >> Failed to cleanup replica1.pesen.net DNS entries: no matching entry >> found >> You may need to manually remove them from the tree >> >> IIRC upon one of the early discussions with Ludwig, this is yet to be >> implemented. >> -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From jcholast at redhat.com Tue May 26 09:57:07 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 26 May 2015 11:57:07 +0200 Subject: [Freeipa-devel] [PATCH 0325] Add Domain Level feature In-Reply-To: <55633C7F.1090103@redhat.com> References: <5554643E.4030600@redhat.com> <55546F6C.4060108@redhat.com> <555B390B.6000907@redhat.com> <555B3C61.7080508@redhat.com> <555B3F67.3040604@redhat.com> <555B3FFE.5040806@redhat.com> <555B4112.202@redhat.com> <555B41C8.7070503@redhat.com> <555B43BB.90404@redhat.com> <555E0572.8000600@redhat.com> <555EB9E7.3020800@redhat.com> <555F06AA.50206@redhat.com> <5562B380.8070609@redhat.com> <5562FC98.5040109@redhat.com> <55633C7F.1090103@redhat.com> Message-ID: <55644373.5000503@redhat.com> Dne 25.5.2015 v 17:15 Tomas Babej napsal(a): > > > On 05/25/2015 12:42 PM, Tomas Babej wrote: >> >> >> On 05/25/2015 07:30 AM, Jan Cholasta wrote: >>> Dne 22.5.2015 v 12:36 Petr Vobornik napsal(a): >>>> On 05/22/2015 07:08 AM, Jan Cholasta wrote: >>>>> Dne 21.5.2015 v 18:18 Tomas Babej napsal(a): >>>>>> >>>>>> >>>>>> On 05/19/2015 04:07 PM, Tomas Babej wrote: >>>>>>> >>>>>>> >>>>>>> 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 >>>>>> >>>>>> A new iteration of the patch, including the server-side checks for the >>>>>> installers. >>>>>> >>>>>> Tomas >>>>> >>>>> 1) https://www.redhat.com/archives/freeipa-devel/2015-May/msg00228.html >>>>> - I still don't agree that the plugin should be based on LDAPObject. >>>> >>>> On the other hand, with LDAPObject base, Web UI for this feature is much >>>> more simpler because it can rely on existing conventions. >>> >>> Following this logic, should *everything* be based on LDAPObject, >>> because it would satisfy the convetion? I don't think so. The convetion >>> should not apply here, because domain level is conceptually *not* an >>> object, it is a property. IMHO having a clean API should be preferred >>> over implementation convenience. >>> >> >> I do not have strong opinions over this. Attached version implements >> a lightweight approach to the domainlevel related commands. >> >> Tomas >> >> >> > > Fixes a slight schema glitch. > Thanks for the patch! 1) + # Detect the current domain level + try: + current = remote_api.Command['domainlevel_show']['result'] + except KeyError: + # If we're joining an older master, domainlevel_show is not + # available + current = 0 KeyError? That does not look right. remote_api differs from api only in that it sets up ldap2 to connect to the remote server, but it uses local plugins and everything, so domainlevel_show should always be available. 2) Could you also set supported domain levels in install/share/master-entry.ldif? I think it makes sense to have them there right from the beginning of server install. 3) I think you should use the per-plugin api object instead of ipalib.api when constructing DNs (domainlevel_dn, container_masters). 4) I would say the opposite of "domainlevel-set" should be "domainlevel-get", not "domainlevel-show". IMO it's OK since property commands are an uncharted territory and don't have to (maybe even shouldn't) use the same convention as objects. 5) + 'System: Read Domain Level': { + 'ipapermlocation': DN('cn=masters,cn=ipa,cn=etc', api.env.basedn), + 'ipapermtargetfilter': {'(objectclass=ipadomainlevelconfig)'}, + 'ipapermbindruletype': 'all', + 'ipapermright': {'read', 'search', 'compare'}, + 'ipapermdefaultattr': { + 'ipadomainlevel', 'objectclass', + }, + }, Shouldn't ipapermlocation say "cn=Domain Level,cn=ipa,cn=etc"? -- Jan Cholasta From pvoborni at redhat.com Tue May 26 10:14:07 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 26 May 2015 12:14:07 +0200 Subject: [Freeipa-devel] [PATCH] 855 server-find and server-show commands Message-ID: <5564476F.2090100@redhat.com> the patch is rebased on top of tbabej 325-9 (but it might not be needed) ipa server-find ipa server-show FQDN These commands display a list of IPA servers stored in cn=masters,cn=ipa,cn=etc,$SUFFIX https://fedorahosted.org/freeipa/ticket/4302 (maybe we could create a different one) -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0855-server-find-and-server-show-commands.patch Type: text/x-patch Size: 6233 bytes Desc: not available URL: From thozza at redhat.com Tue May 26 10:16:09 2015 From: thozza at redhat.com (Tomas Hozza) Date: Tue, 26 May 2015 12:16:09 +0200 Subject: [Freeipa-devel] [PATCH 0376] Add schema for unknown record types In-Reply-To: <555DB694.4090808@redhat.com> References: <555DB694.4090808@redhat.com> Message-ID: <556447E9.5070705@redhat.com> On 05/21/2015 12:42 PM, Petr Spacek wrote: > Hello, > > Add schema for unknown record types. > > This patch complements my previous patch 367. > > The change was pushed to > https://github.com/pspacek/bind-dyndb-ldap/tree/unknown_record_types , too. > ACK Tomas -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com From thozza at redhat.com Tue May 26 10:17:25 2015 From: thozza at redhat.com (Tomas Hozza) Date: Tue, 26 May 2015 12:17:25 +0200 Subject: [Freeipa-devel] [PATCH 0367] Support unknown record types (RFC 3597) In-Reply-To: <555EE2E5.2020001@redhat.com> References: <555A05D2.7000408@redhat.com> <555EE2E5.2020001@redhat.com> Message-ID: <55644835.3050208@redhat.com> On 05/22/2015 10:03 AM, Petr Spacek wrote: > On 18.5.2015 17:31, Petr Spacek wrote: > > Hello, > > > > This patch is unrelated to metaDB but it should be merged before alpha, too. > > > > Thank you for review! > > > > Support unknown record types (RFC 3597). > > > > Fallback to generic LDAP attribute "UnknownRecord;TYP256" if attempt to > > add specific attribute like "URIRecord" failed with LDAP_OBJECT_CLASS_VIOLATION > > and always delete both attributes like "URIRecord" and "UnknownRecord;TYPE256". > > > > https://fedorahosted.org/bind-dyndb-ldap/ticket/157 > > Fixed version is attached. Version 1 could dereference NULL pointers in second > iteration of while loops. > I did only formal review. Didn't find any issues. ACK. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com From pvoborni at redhat.com Tue May 26 10:19:31 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 26 May 2015 12:19:31 +0200 Subject: [Freeipa-devel] [PATCH] 857 topology: ipa management commands Message-ID: <556448B3.9050105@redhat.com> this patch is based on top of my patch #856 and tbabej' s 325-9. Obsoletes Ludwig's 0006. ipalib part of topology management Design: - http://www.freeipa.org/page/V4/Manage_replication_topology https://fedorahosted.org/freeipa/ticket/4302 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0857-topology-ipa-management-commands.patch Type: text/x-patch Size: 26888 bytes Desc: not available URL: From pvoborni at redhat.com Tue May 26 10:22:56 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 26 May 2015 12:22:56 +0200 Subject: [Freeipa-devel] [PATCH] 822 webui: topology plugin In-Reply-To: <5555DD7F.10000@redhat.com> References: <55365A0B.1030305@redhat.com> <5555DD7F.10000@redhat.com> Message-ID: <55644980.9020209@redhat.com> On 05/15/2015 01:50 PM, Petr Vobornik wrote: > On 04/21/2015 04:09 PM, Petr Vobornik wrote: >> First iteration of Topology plugin Web UI. >> >> It reflects current state of topology plugin python part which is >> implemented in "[PATCH] manage replication topology in the shared tree" >> and my wip patch. >> >> I expect that the server API part will change a bit therefore this will >> as well. >> >> Graphical visualization/management (ticket 4286) will be implemented in >> separate patch. >> >> https://fedorahosted.org/freeipa/ticket/4997 >> http://www.freeipa.org/page/V4/Manage_replication_topology >> >> > > New version attached. It requires stage user web ui patches in order to > apply (I expect that user life cycle backend will be pushed sooner than > topology) > > Changes: > - Left host and Right host fields are now host comboboxes > - Connectivity are radio buttons with "both, left-right, right-left, > none" options > - segment name is not a required field in its adder dialog > > IMHO "Attributes to strip", "Attributes to replicate", "Attributes for > total update", "Initialize replica", "Session timeout", "Replication > agreement enabled" fields should not be just free-form textboxes, but > they should be more specific, e.g. a checkbox for "Replication agreement > enabled" or integer for "Session timeout", but that should be modified > first in the backend python plugin. > > New patchset which replaces the old patch. Contains Web UI for: - topologysuffix, topologysegment, domain level, server Backend is implemented in patches: - tbabej 325-9 - pvoborni 855, 857 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0861-webui-topology-plugin.patch Type: text/x-patch Size: 17814 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0860-webui-make-usage-of-all-in-details-facet-optional.patch Type: text/x-patch Size: 1855 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0859-webui-use-command_dialog-as-a-base-class-for-passwor.patch Type: text/x-patch Size: 6864 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0858-webui-IPA.command_dialog-a-new-dialog-base-class.patch Type: text/x-patch Size: 7403 bytes Desc: not available URL: From pvoborni at redhat.com Tue May 26 10:30:35 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 26 May 2015 12:30:35 +0200 Subject: [Freeipa-devel] Replication Topology plugin issues In-Reply-To: <55643B0D.4090902@redhat.com> References: <55632A17.9050205@redhat.com> <55643625.4040106@redhat.com> <55643B0D.4090902@redhat.com> Message-ID: <55644B4B.7030504@redhat.com> On 05/26/2015 11:21 AM, Oleg Fayans wrote: > Thanks Petr! > > Did I understand correctly, that the master branch does not yet contain > patches 0005 and 0006 from Ludwig, only the 0003 patch has been merged? > I must apply them manually to get the full plugin functionality, right? No, today I've pushed 0003 and 0005 to master. 0006 was replaced by my patches 855 and 857 which depends on tbabej's 325-9+ (domain level feature) > > > On 05/26/2015 11:00 AM, Petr Vobornik wrote: >> On 05/25/2015 03:56 PM, Oleg Fayans wrote: >>> Hi, >>> >>> Playing around with the replication topology plugin, I've noticed a >>> couple of issues: >>> 1. around 50% of attempts to setup a replica of a freeipa master with >>> topology plugin enabled (domain level set to 1.0) end up with the >>> following error message in the stdoutput: >>> >>> [error] RuntimeError: One of the ldap service principals is missing. >>> Replication agreement cannot be converted. >>> Replication error message: Unable to acquire replicaLDAP error: No such >>> object >>> >>> I am not sure whether the reason is in the Topology Plugin itself or in >>> some of the latest changes in upstream, though. >> >> I have the same experience. It seems that data from master were >> replicated to new replica but new replica entries(host, services) were >> not replicated back to master. >> >> The installation then hangs on replica's check if its ldap service >> principal is on master. >> >> New ticket: https://fedorahosted.org/freeipa/ticket/5035 >> >> >>> >>> 2. Whenever this happens, master retains the information about the new >>> topology segment, even despite the replica setup was unsuccessful. IMHO, >>> we should have a way to notify the master about replica setup >>> faiures/aborts so that the master would automatically erase the >>> corresponding freshly-created segments in such cases. >> >> Not sure if we can rely on that because the chosen communication >> mechanism(what ever it might be) might suffer from the same root cause >> as the replica installation. >> >>> >>> 3. After this happens user is unable to delete the replication agreement >>> with the standard `ipa-replica-manage del` way: >>> $ ipa-replica-manage del replica1.pesen.net --force >>> Connection to 'replica1.pesen.net' failed: [Errno -2] Name or service >>> not known >>> Forcing removal of replica1.pesen.net >>> Skipping calculation to determine if one or more masters would be >>> orphaned. >>> Deleting replication agreements between replica1.pesen.net and >>> newmaster.pesen.net >>> Failed to get list of agreements from 'replica1.pesen.net': [Errno -2] >>> Name or service not known >>> Forcing removal on 'newmaster.pesen.net' >>> Any DNA range on 'replica1.pesen.net' will be lost >>> There were issues removing a connection for replica1.pesen.net from >>> newmaster.pesen.net: Server is unwilling to perform: Entry is managed by >>> topology plugin.Deletion not allowed. >>> Failed to cleanup replica1.pesen.net entries: Not allowed on non-leaf >>> entry >> >> this line was fixed by https://fedorahosted.org/freeipa/ticket/5019 . >> When this succeeds (master entry is deleted), topology plugin should >> delete the rest. I.e., with this patch I was able to delete the replica. >> >> That said, the output might want some love. >> >>> You may need to manually remove them from the tree >>> Failed to cleanup replica1.pesen.net DNS entries: no matching entry >>> found >>> You may need to manually remove them from the tree >>> >>> IIRC upon one of the early discussions with Ludwig, this is yet to be >>> implemented. >>> > -- Petr Vobornik From tbabej at redhat.com Tue May 26 10:39:02 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 26 May 2015 12:39:02 +0200 Subject: [Freeipa-devel] [PATCH 0325] Add Domain Level feature In-Reply-To: <55644373.5000503@redhat.com> References: <5554643E.4030600@redhat.com> <55546F6C.4060108@redhat.com> <555B390B.6000907@redhat.com> <555B3C61.7080508@redhat.com> <555B3F67.3040604@redhat.com> <555B3FFE.5040806@redhat.com> <555B4112.202@redhat.com> <555B41C8.7070503@redhat.com> <555B43BB.90404@redhat.com> <555E0572.8000600@redhat.com> <555EB9E7.3020800@redhat.com> <555F06AA.50206@redhat.com> <5562B380.8070609@redhat.com> <5562FC98.5040109@redhat.com> <55633C7F.1090103@redhat.com> <55644373.5000503@redhat.com> Message-ID: <55644D46.1090602@redhat.com> On 05/26/2015 11:57 AM, Jan Cholasta wrote: > Dne 25.5.2015 v 17:15 Tomas Babej napsal(a): >> >> >> On 05/25/2015 12:42 PM, Tomas Babej wrote: >>> >>> >>> On 05/25/2015 07:30 AM, Jan Cholasta wrote: >>>> Dne 22.5.2015 v 12:36 Petr Vobornik napsal(a): >>>>> On 05/22/2015 07:08 AM, Jan Cholasta wrote: >>>>>> Dne 21.5.2015 v 18:18 Tomas Babej napsal(a): >>>>>>> >>>>>>> >>>>>>> On 05/19/2015 04:07 PM, Tomas Babej wrote: >>>>>>>> >>>>>>>> >>>>>>>> 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 >>>>>>> >>>>>>> A new iteration of the patch, including the server-side checks >>>>>>> for the >>>>>>> installers. >>>>>>> >>>>>>> Tomas >>>>>> >>>>>> 1) >>>>>> https://www.redhat.com/archives/freeipa-devel/2015-May/msg00228.html >>>>>> - I still don't agree that the plugin should be based on LDAPObject. >>>>> >>>>> On the other hand, with LDAPObject base, Web UI for this feature is >>>>> much >>>>> more simpler because it can rely on existing conventions. >>>> >>>> Following this logic, should *everything* be based on LDAPObject, >>>> because it would satisfy the convetion? I don't think so. The convetion >>>> should not apply here, because domain level is conceptually *not* an >>>> object, it is a property. IMHO having a clean API should be preferred >>>> over implementation convenience. >>>> >>> >>> I do not have strong opinions over this. Attached version implements >>> a lightweight approach to the domainlevel related commands. >>> >>> Tomas >>> >>> >>> >> >> Fixes a slight schema glitch. >> > > Thanks for the patch! > > 1) > > + # Detect the current domain level > + try: > + current = remote_api.Command['domainlevel_show']['result'] > + except KeyError: > + # If we're joining an older master, domainlevel_show is > not > + # available > + current = 0 > > KeyError? That does not look right. remote_api differs from api only in > that it sets up ldap2 to connect to the remote server, but it uses local > plugins and everything, so domainlevel_show should always be available. > > > 2) Could you also set supported domain levels in > install/share/master-entry.ldif? I think it makes sense to have them > there right from the beginning of server install. > > > 3) I think you should use the per-plugin api object instead of > ipalib.api when constructing DNs (domainlevel_dn, container_masters). > > > 4) I would say the opposite of "domainlevel-set" should be > "domainlevel-get", not "domainlevel-show". IMO it's OK since property > commands are an uncharted territory and don't have to (maybe even > shouldn't) use the same convention as objects. > > > 5) > > + 'System: Read Domain Level': { > + 'ipapermlocation': DN('cn=masters,cn=ipa,cn=etc', api.env.basedn), > + 'ipapermtargetfilter': {'(objectclass=ipadomainlevelconfig)'}, > + 'ipapermbindruletype': 'all', > + 'ipapermright': {'read', 'search', 'compare'}, > + 'ipapermdefaultattr': { > + 'ipadomainlevel', 'objectclass', > + }, > + }, > > Shouldn't ipapermlocation say "cn=Domain Level,cn=ipa,cn=etc"? > Thanks for the review, I fixed all the issues raised. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0325-10-Add-Domain-Level-feature.patch Type: text/x-patch Size: 25183 bytes Desc: not available URL: From pvoborni at redhat.com Tue May 26 11:03:19 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 26 May 2015 13:03:19 +0200 Subject: [Freeipa-devel] [PATCH] 855 server-find and server-show commands In-Reply-To: <5564476F.2090100@redhat.com> References: <5564476F.2090100@redhat.com> Message-ID: <556452F7.2020201@redhat.com> On 05/26/2015 12:14 PM, Petr Vobornik wrote: > the patch is rebased on top of tbabej 325-9 (but it might not be needed) > > ipa server-find > ipa server-show FQDN > > These commands display a list of IPA servers stored in > cn=masters,cn=ipa,cn=etc,$SUFFIX > > https://fedorahosted.org/freeipa/ticket/4302 (maybe we could create a > different one) > minor update based on Honza's offline comments -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0855-1-server-find-and-server-show-commands.patch Type: text/x-patch Size: 6676 bytes Desc: not available URL: From sbose at redhat.com Tue May 26 11:15:45 2015 From: sbose at redhat.com (Sumit Bose) Date: Tue, 26 May 2015 13:15:45 +0200 Subject: [Freeipa-devel] [PATCH 143] ipa-sam: use proper domain GUID Message-ID: <20150526111545.GN3943@p.redhat.com> Hi, I came across this very old code. Before there was a domain GUID attribute for the IPA domain in the directory tree ipa-sam used a auto generated one. Since we now have that attribute and deliver it e.g. via CLDAP ipa-sam should use the same. bye, Sumit -------------- next part -------------- From 45af7302b80bff25892bb6629689dbf4dfa3b37d Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Fri, 16 Jan 2015 12:35:57 +0100 Subject: [PATCH] ipa-sam: use proper domain GUID --- daemons/ipa-sam/ipa_sam.c | 28 ++++++++++++++++------------ 1 file changed, 16 insertions(+), 12 deletions(-) diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c index 07249fd27b362ed6499e372d651192dfc31b5173..f514546fd3152bda65062a8c236dedd787f7a5d8 100644 --- a/daemons/ipa-sam/ipa_sam.c +++ b/daemons/ipa-sam/ipa_sam.c @@ -126,6 +126,7 @@ void idmap_cache_set_sid2unixid(const struct dom_sid *sid, struct unixid *unix_i #define LDAP_ATTRIBUTE_SUPPORTED_ENC_TYPE "ipaNTSupportedEncryptionTypes" #define LDAP_ATTRIBUTE_TRUST_PARTNER "ipaNTTrustPartner" #define LDAP_ATTRIBUTE_FLAT_NAME "ipaNTFlatName" +#define LDAP_ATTRIBUTE_DOMAIN_GUID "ipaNTDomainGUID" #define LDAP_ATTRIBUTE_TRUST_AUTH_OUTGOING "ipaNTTrustAuthOutgoing" #define LDAP_ATTRIBUTE_TRUST_AUTH_INCOMING "ipaNTTrustAuthIncoming" #define LDAP_ATTRIBUTE_SECURITY_IDENTIFIER "ipaNTSecurityIdentifier" @@ -179,6 +180,7 @@ struct ipasam_privates { char *base_dn; char *trust_dn; char *flat_name; + char *guid; struct dom_sid fallback_primary_group; char *server_princ; char *client_princ; @@ -3473,8 +3475,6 @@ static struct pdb_domain_info *pdb_ipasam_get_domain_info(struct pdb_methods *pd struct pdb_domain_info *info; struct ldapsam_privates *ldap_state = (struct ldapsam_privates *)pdb_methods->private_data; - char sid_buf[24]; - DATA_BLOB sid_blob; NTSTATUS status; info = talloc(mem_ctx, struct pdb_domain_info); @@ -3502,16 +3502,7 @@ static struct pdb_domain_info *pdb_ipasam_get_domain_info(struct pdb_methods *pd sid_copy(&info->sid, &ldap_state->domain_sid); - if (!sid_linearize(sid_buf, sizeof(sid_buf), &info->sid)) { - goto fail; - } - - /* the first 8 bytes of the linearized SID are not random, - * so we skip them */ - sid_blob.data = (uint8_t *) sid_buf + 8 ; - sid_blob.length = 16; - - status = GUID_from_ndr_blob(&sid_blob, &info->guid); + status = GUID_from_string(ldap_state->ipasam_privates->guid, &info->guid); if (!NT_STATUS_IS_OK(status)) { goto fail; } @@ -3612,6 +3603,7 @@ static NTSTATUS ipasam_search_domain_info(struct smbldap_state *ldap_state, const char *filter = "objectClass=ipaNTDomainAttrs"; const char *attr_list[] = { LDAP_ATTRIBUTE_FLAT_NAME, + LDAP_ATTRIBUTE_DOMAIN_GUID, LDAP_ATTRIBUTE_SID, LDAP_ATTRIBUTE_FALLBACK_PRIMARY_GROUP, LDAP_ATTRIBUTE_OBJECTCLASS, @@ -4525,6 +4517,18 @@ static NTSTATUS pdb_init_ipasam(struct pdb_methods **pdb_method, return NT_STATUS_INVALID_PARAMETER; } + ldap_state->ipasam_privates->guid = get_single_attribute( + ldap_state, + ldap_state->smbldap_state->ldap_struct, + entry, + LDAP_ATTRIBUTE_DOMAIN_GUID); + if (ldap_state->ipasam_privates->guid == NULL) { + DEBUG(0, ("Missing mandatory attribute %s.\n", + LDAP_ATTRIBUTE_DOMAIN_GUID)); + ldap_msgfree(result); + return NT_STATUS_INVALID_PARAMETER; + } + err = sss_idmap_init(idmap_talloc, ldap_state->ipasam_privates, idmap_talloc_free, &ldap_state->ipasam_privates->idmap_ctx); -- 2.1.0 From sbose at redhat.com Tue May 26 11:21:19 2015 From: sbose at redhat.com (Sumit Bose) Date: Tue, 26 May 2015 13:21:19 +0200 Subject: [Freeipa-devel] [PATCH 144] extdom: add unit-test for get_user_grouplist() Message-ID: <20150526112119.GO3943@p.redhat.com> Hi, this tests should have gone together with c1114ef82516002de08e004a930b5ba4a1791b25 but got lost somehow during the bugzilla processing. bye, Sumit -------------- next part -------------- From 724258fc3eff2872cf95a5401f25b8134233ee68 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Thu, 26 Feb 2015 14:08:06 +0100 Subject: [PATCH] extdom: add unit-test for get_user_grouplist() --- .../ipa-extdom-extop/ipa_extdom.h | 2 + .../ipa-extdom-extop/ipa_extdom_cmocka_tests.c | 41 + .../ipa-extdom-extop/ipa_extdom_common.c | 4 +- .../ipa-extdom-extop/test_data/group | 1000 ++++++++++++++++++++ 4 files changed, 1045 insertions(+), 2 deletions(-) diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h index 65dd43ea35726db6231386a0fcbba9be1bd71412..a77711977186b702caafa2729dc13090c6031791 100644 --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h @@ -185,6 +185,8 @@ int getgrnam_r_wrapper(size_t buf_max, const char *name, struct group *grp, char **_buf, size_t *_buf_len); int getgrgid_r_wrapper(size_t buf_max, gid_t gid, struct group *grp, char **_buf, size_t *_buf_len); +int get_user_grouplist(const char *name, gid_t gid, + size_t *_ngroups, gid_t **_groups); int pack_ber_sid(const char *sid, struct berval **berval); int pack_ber_name(const char *domain_name, const char *name, struct berval **berval); diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_cmocka_tests.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_cmocka_tests.c index 42d588d08a96f8a26345f85aade9523e05f6f56e..ec553fe62c27738f258defc267fe761c72157df0 100644 --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_cmocka_tests.c +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_cmocka_tests.c @@ -213,6 +213,46 @@ void test_getgrgid_r_wrapper(void **state) free(buf); } +void test_get_user_grouplist(void **state) +{ + int ret; + size_t ngroups; + gid_t *groups; + size_t c; + + /* This is a bit odd behaviour of getgrouplist() it does not check if the + * user exists, only if memberships of the user can be found. */ + ret = get_user_grouplist("non_exisiting_user", 23456, &ngroups, &groups); + assert_int_equal(ret, LDAP_SUCCESS); + assert_int_equal(ngroups, 1); + assert_int_equal(groups[0], 23456); + free(groups); + + ret = get_user_grouplist("member0001", 23456, &ngroups, &groups); + assert_int_equal(ret, LDAP_SUCCESS); + assert_int_equal(ngroups, 3); + assert_int_equal(groups[0], 23456); + assert_int_equal(groups[1], 11111); + assert_int_equal(groups[2], 22222); + free(groups); + + ret = get_user_grouplist("member0003", 23456, &ngroups, &groups); + assert_int_equal(ret, LDAP_SUCCESS); + assert_int_equal(ngroups, 2); + assert_int_equal(groups[0], 23456); + assert_int_equal(groups[1], 22222); + free(groups); + + ret = get_user_grouplist("user_big", 23456, &ngroups, &groups); + assert_int_equal(ret, LDAP_SUCCESS); + assert_int_equal(ngroups, 1001); + assert_int_equal(groups[0], 23456); + for (c = 1; c < ngroups; c++) { + assert_int_equal(groups[c], 29999 + c); + } + free(groups); +} + struct test_data { struct extdom_req *req; struct ipa_extdom_ctx *ctx; @@ -398,6 +438,7 @@ int main(int argc, const char *argv[]) unit_test(test_getpwuid_r_wrapper), unit_test(test_getgrnam_r_wrapper), unit_test(test_getgrgid_r_wrapper), + unit_test(test_get_user_grouplist), unit_test_setup_teardown(test_set_err_msg, extdom_req_setup, extdom_req_teardown), unit_test_setup_teardown(test_encode, diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c index b2e690471cd045154454a26aa6756c2628bbc262..f5905c78e5f6eb635fcd0acf0afeda3bdb3b9baa 100644 --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c @@ -400,8 +400,8 @@ int check_request(struct extdom_req *req, enum extdom_version version) return LDAP_SUCCESS; } -static int get_user_grouplist(const char *name, gid_t gid, - size_t *_ngroups, gid_t **_groups ) +int get_user_grouplist(const char *name, gid_t gid, + size_t *_ngroups, gid_t **_groups) { int ret; int ngroups; diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/test_data/group b/daemons/ipa-slapi-plugins/ipa-extdom-extop/test_data/group index 8d1b012871b21cc9d5ffdba2168f35ef3e8a5f81..8394789f9ab89cda928af7a3e2b03de1f2a98395 100644 --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/test_data/group +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/test_data/group @@ -1,2 +1,1002 @@ group:x:11111:member0001,member0002 group_big:x:22222:member0001,member0002,member0003,member0004,member0005,member0006,member0007,member0008,member0009,member0010,member0011,member0012,member0013,member0014,member0015,member0016,member0017,member0018,member0019,member0020,member0021,member0022,member0023,member0024,member0025,member0026,member0027,member0028,member0029,member0030,member0031,member0032,member0033,member0034,member0035,member0036,member0037,member0038,member0039,member0040,member0041,member0042,member0043,member0044,member0045,member0046,member0047,member0048,member0049,member0050,member0051,member0052,member0053,member0054,member0055,member0056,member0057,member0058,member0059,member0060,member0061,member0062,member0063,member0064,member0065,member0066,member0067,member0068,member0069,member0070,member0071,member0072,member0073,member0074,member0075,member0076,member0077,member0078,member0079,member0080,member0081,member0082,member0083,member0084,member0085,member0086,member0087,member0088,member0089,member0090,member0091,member0092,member0093,member0094,member0095,member0096,member0097,member0098,member0099,member0100,member0101,member0102,member0103,member0104,member0105,member0106,member0107,member0108,member0109,member0110,member0111,member0112,member0113,member0114,member0115,member0116,member0117,member0118,member0119,member0120,member0121,member0122,member0123,member0124,member0125,member0126,member0127,member0128,member0129,member0130,member0131,member0132,member0133,member0134,member0135,member0136,member0137,member0138,member0139,member0140,member0141,member0142,member0143,member0144,member0145,member0146,member0147,member0148,member0149,member0150,member0151,member0152,member0153,member0154,member0155,member0156,member0157,member0158,member0159,member0160,member0161,member0162,member0163,member0164,member0165,member0166,member0167,member0168,member0169,member0170,member0171,member0172,member0173,member0174,member0175,member0176,member0177,member0178,member0179,member0180,member0181,member0182,member0183,member0184,member0185,member0186,member0187,member0188,member0189,member0190,member0191,member0192,member0193,member0194,member0195,member0196,member0197,member0198,member0199,member0200,member0201,member0202,member0203,member0204,member0205,member0206,member0207,member0208,member0209,member0210,member0211,member0212,member0213,member0214,member0215,member0216,member0217,member0218,member0219,member0220,member0221,member0222,member0223,member0224,member0225,member0226,member0227,member0228,member0229,member0230,member0231,member0232,member0233,member0234,member0235,member0236,member0237,member0238,member0239,member0240,member0241,member0242,member0243,member0244,member0245,member0246,member0247,member0248,member0249,member0250,member0251,member0252,member0253,member0254,member0255,member0256,member0257,member0258,member0259,member0260,member0261,member0262,member0263,member0264,member0265,member0266,member0267,member0268,member0269,member0270,member0271,member0272,member0273,member0274,member0275,member0276,member0277,member0278,member0279,member0280,member0281,member0282,member0283,member0284,member0285,member0286,member0287,member0288,member0289,member0290,member0291,member0292,member0293,member0294,member0295,member0296,member0297,member0298,member0299,member0300,member0301,member0302,member0303,member0304,member0305,member0306,member0307,member0308,member0309,member0310,member0311,member0312,member0313,member0314,member0315,member0316,member0317,member0318,member0319,member0320,member0321,member0322,member0323,member0324,member0325,member0326,member0327,member0328,member0329,member0330,member0331,member0332,member0333,member0334,member0335,member0336,member0337,member0338,member0339,member0340,member0341,member0342,member0343,member0344,member0345,member0346,member0347,member0348,member0349,member0350,member0351,member0352,member0353,member0354,member0355,member0356,member0357,member0358,member0359,member0360,member0361,member0362,member0363,member0364,member0365,member0366,member0367,member0368,member0369,member0370,member0371,member0372,member0373,member0374,member0375,member0376,member0377,member0378,member0379,member0380,member0381,member0382,member0383,member0384,member0385,member0386,member0387,member0388,member0389,member0390,member0391,member0392,member0393,member0394,member0395,member0396,member0397,member0398,member0399,member0400,member0401,member0402,member0403,member0404,member0405,member0406,member0407,member0408,member0409,member0410,member0411,member0412,member0413,member0414,member0415,member0416,member0417,member0418,member0419,member0420,member0421,member0422,member0423,member0424,member0425,member0426,member0427,member0428,member0429,member0430,member0431,member0432,member0433,member0434,member0435,member0436,member0437,member0438,member0439,member0440,member0441,member0442,member0443,member0444,member0445,member0446,member0447,member0448,member0449,member0450,member0451,member0452,member0453,member0454,member0455,member0456,member0457,member0458,member0459,member0460,member0461,member0462,member0463,member0464,member0465,member0466,member0467,member0468,member0469,member0470,member0471,member0472,member0473,member0474,member0475,member0476,member0477,member0478,member0479,member0480,member0481,member0482,member0483,member0484,member0485,member0486,member0487,member0488,member0489,member0490,member0491,member0492,member0493,member0494,member0495,member0496,member0497,member0498,member0499,member0500,member0501,member0502,member0503,member0504,member0505,member0506,member0507,member0508,member0509,member0510,member0511,member0512,member0513,member0514,member0515,member0516,member0517,member0518,member0519,member0520,member0521,member0522,member0523,member0524,member0525,member0526,member0527,member0528,member0529,member0530,member0531,member0532,member0533,member0534,member0535,member0536,member0537,member0538,member0539,member0540,member0541,member0542,member0543,member0544,member0545,member0546,member0547,member0548,member0549,member0550,member0551,member0552,member0553,member0554,member0555,member0556,member0557,member0558,member0559,member0560,member0561,member0562,member0563,member0564,member0565,member0566,member0567,member0568,member0569,member0570,member0571,member0572,member0573,member0574,member0575,member0576,member0577,member0578,member0579,member0580,member0581,member0582,member0583,member0584,member0585,member0586,member0587,member0588,member0589,member0590,member0591,member0592,member0593,member0594,member0595,member0596,member0597,member0598,member0599,member0600,member0601,member0602,member0603,member0604,member0605,member0606,member0607,member0608,member0609,member0610,member0611,member0612,member0613,member0614,member0615,member0616,member0617,member0618,member0619,member0620,member0621,member0622,member0623,member0624,member0625,member0626,member0627,member0628,member0629,member0630,member0631,member0632,member0633,member0634,member0635,member0636,member0637,member0638,member0639,member0640,member0641,member0642,member0643,member0644,member0645,member0646,member0647,member0648,member0649,member0650,member0651,member0652,member0653,member0654,member0655,member0656,member0657,member0658,member0659,member0660,member0661,member0662,member0663,member0664,member0665,member0666,member0667,member0668,member0669,member0670,member0671,member0672,member0673,member0674,member0675,member0676,member0677,member0678,member0679,member0680,member0681,member0682,member0683,member0684,member0685,member0686,member0687,member0688,member0689,member0690,member0691,member0692,member0693,member0694,member0695,member0696,member0697,member0698,member0699,member0700,member0701,member0702,member0703,member0704,member0705,member0706,member0707,member0708,member0709,member0710,member0711,member0712,member0713,member0714,member0715,member0716,member0717,member0718,member0719,member0720,member0721,member0722,member0723,member0724,member0725,member0726,member0727,member0728,member0729,member0730,member0731,member0732,member0733,member0734,member0735,member0736,member0737,member0738,member0739,member0740,member0741,member0742,member0743,member0744,member0745,member0746,member0747,member0748,member0749,member0750,member0751,member0752,member0753,member0754,member0755,member0756,member0757,member0758,member0759,member0760,member0761,member0762,member0763,member0764,member0765,member0766,member0767,member0768,member0769,member0770,member0771,member0772,member0773,member0774,member0775,member0776,member0777,member0778,member0779,member0780,member0781,member0782,member0783,member0784,member0785,member0786,member0787,member0788,member0789,member0790,member0791,member0792,member0793,member0794,member0795,member0796,member0797,member0798,member0799,member0800,member0801,member0802,member0803,member0804,member0805,member0806,member0807,member0808,member0809,member0810,member0811,member0812,member0813,member0814,member0815,member0816,member0817,member0818,member0819,member0820,member0821,member0822,member0823,member0824,member0825,member0826,member0827,member0828,member0829,member0830,member0831,member0832,member0833,member0834,member0835,member0836,member0837,member0838,member0839,member0840,member0841,member0842,member0843,member0844,member0845,member0846,member0847,member0848,member0849,member0850,member0851,member0852,member0853,member0854,member0855,member0856,member0857,member0858,member0859,member0860,member0861,member0862,member0863,member0864,member0865,member0866,member0867,member0868,member0869,member0870,member0871,member0872,member0873,member0874,member0875,member0876,member0877,member0878,member0879,member0880,member0881,member0882,member0883,member0884,member0885,member0886,member0887,member0888,member0889,member0890,member0891,member0892,member0893,member0894,member0895,member0896,member0897,member0898,member0899,member0900,member0901,member0902,member0903,member0904,member0905,member0906,member0907,member0908,member0909,member0910,member0911,member0912,member0913,member0914,member0915,member0916,member0917,member0918,member0919,member0920,member0921,member0922,member0923,member0924,member0925,member0926,member0927,member0928,member0929,member0930,member0931,member0932,member0933,member0934,member0935,member0936,member0937,member0938,member0939,member0940,member0941,member0942,member0943,member0944,member0945,member0946,member0947,member0948,member0949,member0950,member0951,member0952,member0953,member0954,member0955,member0956,member0957,member0958,member0959,member0960,member0961,member0962,member0963,member0964,member0965,member0966,member0967,member0968,member0969,member0970,member0971,member0972,member0973,member0974,member0975,member0976,member0977,member0978,member0979,member0980,member0981,member0982,member0983,member0984,member0985,member0986,member0987,member0988,member0989,member0990,member0991,member0992,member0993,member0994,member0995,member0996,member0997,member0998,member0999,member1000,member1001,member1002,member1003,member1004,member1005,member1006,member1007,member1008,member1009,member1010,member1011,member1012,member1013,member1014,member1015,member1016,member1017,member1018,member1019,member1020,member1021,member1022,member1023,member1024,member1025,member1026,member1027,member1028,member1029,member1030,member1031,member1032,member1033,member1034,member1035,member1036,member1037,member1038,member1039,member1040,member1041,member1042,member1043,member1044,member1045,member1046,member1047,member1048,member1049,member1050,member1051,member1052,member1053,member1054,member1055,member1056,member1057,member1058,member1059,member1060,member1061,member1062,member1063,member1064,member1065,member1066,member1067,member1068,member1069,member1070,member1071,member1072,member1073,member1074,member1075,member1076,member1077,member1078,member1079,member1080,member1081,member1082,member1083,member1084,member1085,member1086,member1087,member1088,member1089,member1090,member1091,member1092,member1093,member1094,member1095,member1096,member1097,member1098,member1099,member1100,member1101,member1102,member1103,member1104,member1105,member1106,member1107,member1108,member1109,member1110,member1111,member1112,member1113,member1114,member1115,member1116,member1117,member1118,member1119,member1120,member1121,member1122,member1123,member1124,member1125,member1126,member1127,member1128,member1129,member1130,member1131,member1132,member1133,member1134,member1135,member1136,member1137,member1138,member1139,member1140,member1141,member1142,member1143,member1144,member1145,member1146,member1147,member1148,member1149,member1150,member1151,member1152,member1153,member1154,member1155,member1156,member1157,member1158,member1159,member1160,member1161,member1162,member1163,member1164,member1165,member1166,member1167,member1168,member1169,member1170,member1171,member1172,member1173,member1174,member1175,member1176,member1177,member1178,member1179,member1180,member1181,member1182,member1183,member1184,member1185,member1186,member1187,member1188,member1189,member1190,member1191,member1192,member1193,member1194,member1195,member1196,member1197,member1198,member1199,member1200,member1201,member1202,member1203,member1204,member1205,member1206,member1207,member1208,member1209,member1210,member1211,member1212,member1213,member1214,member1215,member1216,member1217,member1218,member1219,member1220,member1221,member1222,member1223,member1224,member1225,member1226,member1227,member1228,member1229,member1230,member1231,member1232,member1233,member1234,member1235,member1236,member1237,member1238,member1239,member1240,member1241,member1242,member1243,member1244,member1245,member1246,member1247,member1248,member1249,member1250,member1251,member1252,member1253,member1254,member1255,member1256,member1257,member1258,member1259,member1260,member1261,member1262,member1263,member1264,member1265,member1266,member1267,member1268,member1269,member1270,member1271,member1272,member1273,member1274,member1275,member1276,member1277,member1278,member1279,member1280,member1281,member1282,member1283,member1284,member1285,member1286,member1287,member1288,member1289,member1290,member1291,member1292,member1293,member1294,member1295,member1296,member1297,member1298,member1299,member1300,member1301,member1302,member1303,member1304,member1305,member1306,member1307,member1308,member1309,member1310,member1311,member1312,member1313,member1314,member1315,member1316,member1317,member1318,member1319,member1320,member1321,member1322,member1323,member1324,member1325,member1326,member1327,member1328,member1329,member1330,member1331,member1332,member1333,member1334,member1335,member1336,member1337,member1338,member1339,member1340,member1341,member1342,member1343,member1344,member1345,member1346,member1347,member1348,member1349,member1350,member1351,member1352,member1353,member1354,member1355,member1356,member1357,member1358,member1359,member1360,member1361,member1362,member1363,member1364,member1365,member1366,member1367,member1368,member1369,member1370,member1371,member1372,member1373,member1374,member1375,member1376,member1377,member1378,member1379,member1380,member1381,member1382,member1383,member1384,member1385,member1386,member1387,member1388,member1389,member1390,member1391,member1392,member1393,member1394,member1395,member1396,member1397,member1398,member1399,member1400,member1401,member1402,member1403,member1404,member1405,member1406,member1407,member1408,member1409,member1410,member1411,member1412,member1413,member1414,member1415,member1416,member1417,member1418,member1419,member1420,member1421,member1422,member1423,member1424,member1425,member1426,member1427,member1428,member1429,member1430,member1431,member1432,member1433,member1434,member1435,member1436,member1437,member1438,member1439,member1440,member1441,member1442,member1443,member1444,member1445,member1446,member1447,member1448,member1449,member1450,member1451,member1452,member1453,member1454,member1455,member1456,member1457,member1458,member1459,member1460,member1461,member1462,member1463,member1464,member1465,member1466,member1467,member1468,member1469,member1470,member1471,member1472,member1473,member1474,member1475,member1476,member1477,member1478,member1479,member1480,member1481,member1482,member1483,member1484,member1485,member1486,member1487,member1488,member1489,member1490,member1491,member1492,member1493,member1494,member1495,member1496,member1497,member1498,member1499,member1500,member1501,member1502,member1503,member1504,member1505,member1506,member1507,member1508,member1509,member1510,member1511,member1512,member1513,member1514,member1515,member1516,member1517,member1518,member1519,member1520,member1521,member1522,member1523,member1524,member1525,member1526,member1527,member1528,member1529,member1530,member1531,member1532,member1533,member1534,member1535,member1536,member1537,member1538,member1539,member1540,member1541,member1542,member1543,member1544,member1545,member1546,member1547,member1548,member1549,member1550,member1551,member1552,member1553,member1554,member1555,member1556,member1557,member1558,member1559,member1560,member1561,member1562,member1563,member1564,member1565,member1566,member1567,member1568,member1569,member1570,member1571,member1572,member1573,member1574,member1575,member1576,member1577,member1578,member1579,member1580,member1581,member1582,member1583,member1584,member1585,member1586,member1587,member1588,member1589,member1590,member1591,member1592,member1593,member1594,member1595,member1596,member1597,member1598,member1599,member1600,member1601,member1602,member1603,member1604,member1605,member1606,member1607,member1608,member1609,member1610,member1611,member1612,member1613,member1614,member1615,member1616,member1617,member1618,member1619,member1620,member1621,member1622,member1623,member1624,member1625,member1626,member1627,member1628,member1629,member1630,member1631,member1632,member1633,member1634,member1635,member1636,member1637,member1638,member1639,member1640,member1641,member1642,member1643,member1644,member1645,member1646,member1647,member1648,member1649,member1650,member1651,member1652,member1653,member1654,member1655,member1656,member1657,member1658,member1659,member1660,member1661,member1662,member1663,member1664,member1665,member1666,member1667,member1668,member1669,member1670,member1671,member1672,member1673,member1674,member1675,member1676,member1677,member1678,member1679,member1680,member1681,member1682,member1683,member1684,member1685,member1686,member1687,member1688,member1689,member1690,member1691,member1692,member1693,member1694,member1695,member1696,member1697,member1698,member1699,member1700,member1701,member1702,member1703,member1704,member1705,member1706,member1707,member1708,member1709,member1710,member1711,member1712,member1713,member1714,member1715,member1716,member1717,member1718,member1719,member1720,member1721,member1722,member1723,member1724,member1725,member1726,member1727,member1728,member1729,member1730,member1731,member1732,member1733,member1734,member1735,member1736,member1737,member1738,member1739,member1740,member1741,member1742,member1743,member1744,member1745,member1746,member1747,member1748,member1749,member1750,member1751,member1752,member1753,member1754,member1755,member1756,member1757,member1758,member1759,member1760,member1761,member1762,member1763,member1764,member1765,member1766,member1767,member1768,member1769,member1770,member1771,member1772,member1773,member1774,member1775,member1776,member1777,member1778,member1779,member1780,member1781,member1782,member1783,member1784,member1785,member1786,member1787,member1788,member1789,member1790,member1791,member1792,member1793,member1794,member1795,member1796,member1797,member1798,member1799,member1800,member1801,member1802,member1803,member1804,member1805,member1806,member1807,member1808,member1809,member1810,member1811,member1812,member1813,member1814,member1815,member1816,member1817,member1818,member1819,member1820,member1821,member1822,member1823,member1824,member1825,member1826,member1827,member1828,member1829,member1830,member1831,member1832,member1833,member1834,member1835,member1836,member1837,member1838,member1839,member1840,member1841,member1842,member1843,member1844,member1845,member1846,member1847,member1848,member1849,member1850,member1851,member1852,member1853,member1854,member1855,member1856,member1857,member1858,member1859,member1860,member1861,member1862,member1863,member1864,member1865,member1866,member1867,member1868,member1869,member1870,member1871,member1872,member1873,member1874,member1875,member1876,member1877,member1878,member1879,member1880,member1881,member1882,member1883,member1884,member1885,member1886,member1887,member1888,member1889,member1890,member1891,member1892,member1893,member1894,member1895,member1896,member1897,member1898,member1899,member1900,member1901,member1902,member1903,member1904,member1905,member1906,member1907,member1908,member1909,member1910,member1911,member1912,member1913,member1914,member1915,member1916,member1917,member1918,member1919,member1920,member1921,member1922,member1923,member1924,member1925,member1926,member1927,member1928,member1929,member1930,member1931,member1932,member1933,member1934,member1935,member1936,member1937,member1938,member1939,member1940,member1941,member1942,member1943,member1944,member1945,member1946,member1947,member1948,member1949,member1950,member1951,member1952,member1953,member1954,member1955,member1956,member1957,member1958,member1959,member1960,member1961,member1962,member1963,member1964,member1965,member1966,member1967,member1968,member1969,member1970,member1971,member1972,member1973,member1974,member1975,member1976,member1977,member1978,member1979,member1980,member1981,member1982,member1983,member1984,member1985,member1986,member1987,member1988,member1989,member1990,member1991,member1992,member1993,member1994,member1995,member1996,member1997,member1998,member1999,member2000, +group30000:x:30000:user_big +group30001:x:30001:user_big +group30002:x:30002:user_big +group30003:x:30003:user_big +group30004:x:30004:user_big +group30005:x:30005:user_big +group30006:x:30006:user_big +group30007:x:30007:user_big +group30008:x:30008:user_big +group30009:x:30009:user_big +group30010:x:30010:user_big +group30011:x:30011:user_big +group30012:x:30012:user_big +group30013:x:30013:user_big +group30014:x:30014:user_big +group30015:x:30015:user_big +group30016:x:30016:user_big +group30017:x:30017:user_big +group30018:x:30018:user_big +group30019:x:30019:user_big +group30020:x:30020:user_big +group30021:x:30021:user_big +group30022:x:30022:user_big +group30023:x:30023:user_big +group30024:x:30024:user_big +group30025:x:30025:user_big +group30026:x:30026:user_big +group30027:x:30027:user_big +group30028:x:30028:user_big +group30029:x:30029:user_big +group30030:x:30030:user_big +group30031:x:30031:user_big +group30032:x:30032:user_big +group30033:x:30033:user_big +group30034:x:30034:user_big +group30035:x:30035:user_big +group30036:x:30036:user_big +group30037:x:30037:user_big +group30038:x:30038:user_big +group30039:x:30039:user_big +group30040:x:30040:user_big +group30041:x:30041:user_big +group30042:x:30042:user_big +group30043:x:30043:user_big +group30044:x:30044:user_big +group30045:x:30045:user_big +group30046:x:30046:user_big +group30047:x:30047:user_big +group30048:x:30048:user_big +group30049:x:30049:user_big +group30050:x:30050:user_big +group30051:x:30051:user_big +group30052:x:30052:user_big +group30053:x:30053:user_big +group30054:x:30054:user_big +group30055:x:30055:user_big +group30056:x:30056:user_big +group30057:x:30057:user_big +group30058:x:30058:user_big +group30059:x:30059:user_big +group30060:x:30060:user_big +group30061:x:30061:user_big +group30062:x:30062:user_big +group30063:x:30063:user_big +group30064:x:30064:user_big +group30065:x:30065:user_big +group30066:x:30066:user_big +group30067:x:30067:user_big +group30068:x:30068:user_big +group30069:x:30069:user_big +group30070:x:30070:user_big +group30071:x:30071:user_big +group30072:x:30072:user_big +group30073:x:30073:user_big +group30074:x:30074:user_big +group30075:x:30075:user_big +group30076:x:30076:user_big +group30077:x:30077:user_big +group30078:x:30078:user_big +group30079:x:30079:user_big +group30080:x:30080:user_big +group30081:x:30081:user_big +group30082:x:30082:user_big +group30083:x:30083:user_big +group30084:x:30084:user_big +group30085:x:30085:user_big +group30086:x:30086:user_big +group30087:x:30087:user_big +group30088:x:30088:user_big +group30089:x:30089:user_big +group30090:x:30090:user_big +group30091:x:30091:user_big +group30092:x:30092:user_big +group30093:x:30093:user_big +group30094:x:30094:user_big +group30095:x:30095:user_big +group30096:x:30096:user_big +group30097:x:30097:user_big +group30098:x:30098:user_big +group30099:x:30099:user_big +group30100:x:30100:user_big +group30101:x:30101:user_big +group30102:x:30102:user_big +group30103:x:30103:user_big +group30104:x:30104:user_big +group30105:x:30105:user_big +group30106:x:30106:user_big +group30107:x:30107:user_big +group30108:x:30108:user_big +group30109:x:30109:user_big +group30110:x:30110:user_big +group30111:x:30111:user_big +group30112:x:30112:user_big +group30113:x:30113:user_big +group30114:x:30114:user_big +group30115:x:30115:user_big +group30116:x:30116:user_big +group30117:x:30117:user_big +group30118:x:30118:user_big +group30119:x:30119:user_big +group30120:x:30120:user_big +group30121:x:30121:user_big +group30122:x:30122:user_big +group30123:x:30123:user_big +group30124:x:30124:user_big +group30125:x:30125:user_big +group30126:x:30126:user_big +group30127:x:30127:user_big +group30128:x:30128:user_big +group30129:x:30129:user_big +group30130:x:30130:user_big +group30131:x:30131:user_big +group30132:x:30132:user_big +group30133:x:30133:user_big +group30134:x:30134:user_big +group30135:x:30135:user_big +group30136:x:30136:user_big +group30137:x:30137:user_big +group30138:x:30138:user_big +group30139:x:30139:user_big +group30140:x:30140:user_big +group30141:x:30141:user_big +group30142:x:30142:user_big +group30143:x:30143:user_big +group30144:x:30144:user_big +group30145:x:30145:user_big +group30146:x:30146:user_big +group30147:x:30147:user_big +group30148:x:30148:user_big +group30149:x:30149:user_big +group30150:x:30150:user_big +group30151:x:30151:user_big +group30152:x:30152:user_big +group30153:x:30153:user_big +group30154:x:30154:user_big +group30155:x:30155:user_big +group30156:x:30156:user_big +group30157:x:30157:user_big +group30158:x:30158:user_big +group30159:x:30159:user_big +group30160:x:30160:user_big +group30161:x:30161:user_big +group30162:x:30162:user_big +group30163:x:30163:user_big +group30164:x:30164:user_big +group30165:x:30165:user_big +group30166:x:30166:user_big +group30167:x:30167:user_big +group30168:x:30168:user_big +group30169:x:30169:user_big +group30170:x:30170:user_big +group30171:x:30171:user_big +group30172:x:30172:user_big +group30173:x:30173:user_big +group30174:x:30174:user_big +group30175:x:30175:user_big +group30176:x:30176:user_big +group30177:x:30177:user_big +group30178:x:30178:user_big +group30179:x:30179:user_big +group30180:x:30180:user_big +group30181:x:30181:user_big +group30182:x:30182:user_big +group30183:x:30183:user_big +group30184:x:30184:user_big +group30185:x:30185:user_big +group30186:x:30186:user_big +group30187:x:30187:user_big +group30188:x:30188:user_big +group30189:x:30189:user_big +group30190:x:30190:user_big +group30191:x:30191:user_big +group30192:x:30192:user_big +group30193:x:30193:user_big +group30194:x:30194:user_big +group30195:x:30195:user_big +group30196:x:30196:user_big +group30197:x:30197:user_big +group30198:x:30198:user_big +group30199:x:30199:user_big +group30200:x:30200:user_big +group30201:x:30201:user_big +group30202:x:30202:user_big +group30203:x:30203:user_big +group30204:x:30204:user_big +group30205:x:30205:user_big +group30206:x:30206:user_big +group30207:x:30207:user_big +group30208:x:30208:user_big +group30209:x:30209:user_big +group30210:x:30210:user_big +group30211:x:30211:user_big +group30212:x:30212:user_big +group30213:x:30213:user_big +group30214:x:30214:user_big +group30215:x:30215:user_big +group30216:x:30216:user_big +group30217:x:30217:user_big +group30218:x:30218:user_big +group30219:x:30219:user_big +group30220:x:30220:user_big +group30221:x:30221:user_big +group30222:x:30222:user_big +group30223:x:30223:user_big +group30224:x:30224:user_big +group30225:x:30225:user_big +group30226:x:30226:user_big +group30227:x:30227:user_big +group30228:x:30228:user_big +group30229:x:30229:user_big +group30230:x:30230:user_big +group30231:x:30231:user_big +group30232:x:30232:user_big +group30233:x:30233:user_big +group30234:x:30234:user_big +group30235:x:30235:user_big +group30236:x:30236:user_big +group30237:x:30237:user_big +group30238:x:30238:user_big +group30239:x:30239:user_big +group30240:x:30240:user_big +group30241:x:30241:user_big +group30242:x:30242:user_big +group30243:x:30243:user_big +group30244:x:30244:user_big +group30245:x:30245:user_big +group30246:x:30246:user_big +group30247:x:30247:user_big +group30248:x:30248:user_big +group30249:x:30249:user_big +group30250:x:30250:user_big +group30251:x:30251:user_big +group30252:x:30252:user_big +group30253:x:30253:user_big +group30254:x:30254:user_big +group30255:x:30255:user_big +group30256:x:30256:user_big +group30257:x:30257:user_big +group30258:x:30258:user_big +group30259:x:30259:user_big +group30260:x:30260:user_big +group30261:x:30261:user_big +group30262:x:30262:user_big +group30263:x:30263:user_big +group30264:x:30264:user_big +group30265:x:30265:user_big +group30266:x:30266:user_big +group30267:x:30267:user_big +group30268:x:30268:user_big +group30269:x:30269:user_big +group30270:x:30270:user_big +group30271:x:30271:user_big +group30272:x:30272:user_big +group30273:x:30273:user_big +group30274:x:30274:user_big +group30275:x:30275:user_big +group30276:x:30276:user_big +group30277:x:30277:user_big +group30278:x:30278:user_big +group30279:x:30279:user_big +group30280:x:30280:user_big +group30281:x:30281:user_big +group30282:x:30282:user_big +group30283:x:30283:user_big +group30284:x:30284:user_big +group30285:x:30285:user_big +group30286:x:30286:user_big +group30287:x:30287:user_big +group30288:x:30288:user_big +group30289:x:30289:user_big +group30290:x:30290:user_big +group30291:x:30291:user_big +group30292:x:30292:user_big +group30293:x:30293:user_big +group30294:x:30294:user_big +group30295:x:30295:user_big +group30296:x:30296:user_big +group30297:x:30297:user_big +group30298:x:30298:user_big +group30299:x:30299:user_big +group30300:x:30300:user_big +group30301:x:30301:user_big +group30302:x:30302:user_big +group30303:x:30303:user_big +group30304:x:30304:user_big +group30305:x:30305:user_big +group30306:x:30306:user_big +group30307:x:30307:user_big +group30308:x:30308:user_big +group30309:x:30309:user_big +group30310:x:30310:user_big +group30311:x:30311:user_big +group30312:x:30312:user_big +group30313:x:30313:user_big +group30314:x:30314:user_big +group30315:x:30315:user_big +group30316:x:30316:user_big +group30317:x:30317:user_big +group30318:x:30318:user_big +group30319:x:30319:user_big +group30320:x:30320:user_big +group30321:x:30321:user_big +group30322:x:30322:user_big +group30323:x:30323:user_big +group30324:x:30324:user_big +group30325:x:30325:user_big +group30326:x:30326:user_big +group30327:x:30327:user_big +group30328:x:30328:user_big +group30329:x:30329:user_big +group30330:x:30330:user_big +group30331:x:30331:user_big +group30332:x:30332:user_big +group30333:x:30333:user_big +group30334:x:30334:user_big +group30335:x:30335:user_big +group30336:x:30336:user_big +group30337:x:30337:user_big +group30338:x:30338:user_big +group30339:x:30339:user_big +group30340:x:30340:user_big +group30341:x:30341:user_big +group30342:x:30342:user_big +group30343:x:30343:user_big +group30344:x:30344:user_big +group30345:x:30345:user_big +group30346:x:30346:user_big +group30347:x:30347:user_big +group30348:x:30348:user_big +group30349:x:30349:user_big +group30350:x:30350:user_big +group30351:x:30351:user_big +group30352:x:30352:user_big +group30353:x:30353:user_big +group30354:x:30354:user_big +group30355:x:30355:user_big +group30356:x:30356:user_big +group30357:x:30357:user_big +group30358:x:30358:user_big +group30359:x:30359:user_big +group30360:x:30360:user_big +group30361:x:30361:user_big +group30362:x:30362:user_big +group30363:x:30363:user_big +group30364:x:30364:user_big +group30365:x:30365:user_big +group30366:x:30366:user_big +group30367:x:30367:user_big +group30368:x:30368:user_big +group30369:x:30369:user_big +group30370:x:30370:user_big +group30371:x:30371:user_big +group30372:x:30372:user_big +group30373:x:30373:user_big +group30374:x:30374:user_big +group30375:x:30375:user_big +group30376:x:30376:user_big +group30377:x:30377:user_big +group30378:x:30378:user_big +group30379:x:30379:user_big +group30380:x:30380:user_big +group30381:x:30381:user_big +group30382:x:30382:user_big +group30383:x:30383:user_big +group30384:x:30384:user_big +group30385:x:30385:user_big +group30386:x:30386:user_big +group30387:x:30387:user_big +group30388:x:30388:user_big +group30389:x:30389:user_big +group30390:x:30390:user_big +group30391:x:30391:user_big +group30392:x:30392:user_big +group30393:x:30393:user_big +group30394:x:30394:user_big +group30395:x:30395:user_big +group30396:x:30396:user_big +group30397:x:30397:user_big +group30398:x:30398:user_big +group30399:x:30399:user_big +group30400:x:30400:user_big +group30401:x:30401:user_big +group30402:x:30402:user_big +group30403:x:30403:user_big +group30404:x:30404:user_big +group30405:x:30405:user_big +group30406:x:30406:user_big +group30407:x:30407:user_big +group30408:x:30408:user_big +group30409:x:30409:user_big +group30410:x:30410:user_big +group30411:x:30411:user_big +group30412:x:30412:user_big +group30413:x:30413:user_big +group30414:x:30414:user_big +group30415:x:30415:user_big +group30416:x:30416:user_big +group30417:x:30417:user_big +group30418:x:30418:user_big +group30419:x:30419:user_big +group30420:x:30420:user_big +group30421:x:30421:user_big +group30422:x:30422:user_big +group30423:x:30423:user_big +group30424:x:30424:user_big +group30425:x:30425:user_big +group30426:x:30426:user_big +group30427:x:30427:user_big +group30428:x:30428:user_big +group30429:x:30429:user_big +group30430:x:30430:user_big +group30431:x:30431:user_big +group30432:x:30432:user_big +group30433:x:30433:user_big +group30434:x:30434:user_big +group30435:x:30435:user_big +group30436:x:30436:user_big +group30437:x:30437:user_big +group30438:x:30438:user_big +group30439:x:30439:user_big +group30440:x:30440:user_big +group30441:x:30441:user_big +group30442:x:30442:user_big +group30443:x:30443:user_big +group30444:x:30444:user_big +group30445:x:30445:user_big +group30446:x:30446:user_big +group30447:x:30447:user_big +group30448:x:30448:user_big +group30449:x:30449:user_big +group30450:x:30450:user_big +group30451:x:30451:user_big +group30452:x:30452:user_big +group30453:x:30453:user_big +group30454:x:30454:user_big +group30455:x:30455:user_big +group30456:x:30456:user_big +group30457:x:30457:user_big +group30458:x:30458:user_big +group30459:x:30459:user_big +group30460:x:30460:user_big +group30461:x:30461:user_big +group30462:x:30462:user_big +group30463:x:30463:user_big +group30464:x:30464:user_big +group30465:x:30465:user_big +group30466:x:30466:user_big +group30467:x:30467:user_big +group30468:x:30468:user_big +group30469:x:30469:user_big +group30470:x:30470:user_big +group30471:x:30471:user_big +group30472:x:30472:user_big +group30473:x:30473:user_big +group30474:x:30474:user_big +group30475:x:30475:user_big +group30476:x:30476:user_big +group30477:x:30477:user_big +group30478:x:30478:user_big +group30479:x:30479:user_big +group30480:x:30480:user_big +group30481:x:30481:user_big +group30482:x:30482:user_big +group30483:x:30483:user_big +group30484:x:30484:user_big +group30485:x:30485:user_big +group30486:x:30486:user_big +group30487:x:30487:user_big +group30488:x:30488:user_big +group30489:x:30489:user_big +group30490:x:30490:user_big +group30491:x:30491:user_big +group30492:x:30492:user_big +group30493:x:30493:user_big +group30494:x:30494:user_big +group30495:x:30495:user_big +group30496:x:30496:user_big +group30497:x:30497:user_big +group30498:x:30498:user_big +group30499:x:30499:user_big +group30500:x:30500:user_big +group30501:x:30501:user_big +group30502:x:30502:user_big +group30503:x:30503:user_big +group30504:x:30504:user_big +group30505:x:30505:user_big +group30506:x:30506:user_big +group30507:x:30507:user_big +group30508:x:30508:user_big +group30509:x:30509:user_big +group30510:x:30510:user_big +group30511:x:30511:user_big +group30512:x:30512:user_big +group30513:x:30513:user_big +group30514:x:30514:user_big +group30515:x:30515:user_big +group30516:x:30516:user_big +group30517:x:30517:user_big +group30518:x:30518:user_big +group30519:x:30519:user_big +group30520:x:30520:user_big +group30521:x:30521:user_big +group30522:x:30522:user_big +group30523:x:30523:user_big +group30524:x:30524:user_big +group30525:x:30525:user_big +group30526:x:30526:user_big +group30527:x:30527:user_big +group30528:x:30528:user_big +group30529:x:30529:user_big +group30530:x:30530:user_big +group30531:x:30531:user_big +group30532:x:30532:user_big +group30533:x:30533:user_big +group30534:x:30534:user_big +group30535:x:30535:user_big +group30536:x:30536:user_big +group30537:x:30537:user_big +group30538:x:30538:user_big +group30539:x:30539:user_big +group30540:x:30540:user_big +group30541:x:30541:user_big +group30542:x:30542:user_big +group30543:x:30543:user_big +group30544:x:30544:user_big +group30545:x:30545:user_big +group30546:x:30546:user_big +group30547:x:30547:user_big +group30548:x:30548:user_big +group30549:x:30549:user_big +group30550:x:30550:user_big +group30551:x:30551:user_big +group30552:x:30552:user_big +group30553:x:30553:user_big +group30554:x:30554:user_big +group30555:x:30555:user_big +group30556:x:30556:user_big +group30557:x:30557:user_big +group30558:x:30558:user_big +group30559:x:30559:user_big +group30560:x:30560:user_big +group30561:x:30561:user_big +group30562:x:30562:user_big +group30563:x:30563:user_big +group30564:x:30564:user_big +group30565:x:30565:user_big +group30566:x:30566:user_big +group30567:x:30567:user_big +group30568:x:30568:user_big +group30569:x:30569:user_big +group30570:x:30570:user_big +group30571:x:30571:user_big +group30572:x:30572:user_big +group30573:x:30573:user_big +group30574:x:30574:user_big +group30575:x:30575:user_big +group30576:x:30576:user_big +group30577:x:30577:user_big +group30578:x:30578:user_big +group30579:x:30579:user_big +group30580:x:30580:user_big +group30581:x:30581:user_big +group30582:x:30582:user_big +group30583:x:30583:user_big +group30584:x:30584:user_big +group30585:x:30585:user_big +group30586:x:30586:user_big +group30587:x:30587:user_big +group30588:x:30588:user_big +group30589:x:30589:user_big +group30590:x:30590:user_big +group30591:x:30591:user_big +group30592:x:30592:user_big +group30593:x:30593:user_big +group30594:x:30594:user_big +group30595:x:30595:user_big +group30596:x:30596:user_big +group30597:x:30597:user_big +group30598:x:30598:user_big +group30599:x:30599:user_big +group30600:x:30600:user_big +group30601:x:30601:user_big +group30602:x:30602:user_big +group30603:x:30603:user_big +group30604:x:30604:user_big +group30605:x:30605:user_big +group30606:x:30606:user_big +group30607:x:30607:user_big +group30608:x:30608:user_big +group30609:x:30609:user_big +group30610:x:30610:user_big +group30611:x:30611:user_big +group30612:x:30612:user_big +group30613:x:30613:user_big +group30614:x:30614:user_big +group30615:x:30615:user_big +group30616:x:30616:user_big +group30617:x:30617:user_big +group30618:x:30618:user_big +group30619:x:30619:user_big +group30620:x:30620:user_big +group30621:x:30621:user_big +group30622:x:30622:user_big +group30623:x:30623:user_big +group30624:x:30624:user_big +group30625:x:30625:user_big +group30626:x:30626:user_big +group30627:x:30627:user_big +group30628:x:30628:user_big +group30629:x:30629:user_big +group30630:x:30630:user_big +group30631:x:30631:user_big +group30632:x:30632:user_big +group30633:x:30633:user_big +group30634:x:30634:user_big +group30635:x:30635:user_big +group30636:x:30636:user_big +group30637:x:30637:user_big +group30638:x:30638:user_big +group30639:x:30639:user_big +group30640:x:30640:user_big +group30641:x:30641:user_big +group30642:x:30642:user_big +group30643:x:30643:user_big +group30644:x:30644:user_big +group30645:x:30645:user_big +group30646:x:30646:user_big +group30647:x:30647:user_big +group30648:x:30648:user_big +group30649:x:30649:user_big +group30650:x:30650:user_big +group30651:x:30651:user_big +group30652:x:30652:user_big +group30653:x:30653:user_big +group30654:x:30654:user_big +group30655:x:30655:user_big +group30656:x:30656:user_big +group30657:x:30657:user_big +group30658:x:30658:user_big +group30659:x:30659:user_big +group30660:x:30660:user_big +group30661:x:30661:user_big +group30662:x:30662:user_big +group30663:x:30663:user_big +group30664:x:30664:user_big +group30665:x:30665:user_big +group30666:x:30666:user_big +group30667:x:30667:user_big +group30668:x:30668:user_big +group30669:x:30669:user_big +group30670:x:30670:user_big +group30671:x:30671:user_big +group30672:x:30672:user_big +group30673:x:30673:user_big +group30674:x:30674:user_big +group30675:x:30675:user_big +group30676:x:30676:user_big +group30677:x:30677:user_big +group30678:x:30678:user_big +group30679:x:30679:user_big +group30680:x:30680:user_big +group30681:x:30681:user_big +group30682:x:30682:user_big +group30683:x:30683:user_big +group30684:x:30684:user_big +group30685:x:30685:user_big +group30686:x:30686:user_big +group30687:x:30687:user_big +group30688:x:30688:user_big +group30689:x:30689:user_big +group30690:x:30690:user_big +group30691:x:30691:user_big +group30692:x:30692:user_big +group30693:x:30693:user_big +group30694:x:30694:user_big +group30695:x:30695:user_big +group30696:x:30696:user_big +group30697:x:30697:user_big +group30698:x:30698:user_big +group30699:x:30699:user_big +group30700:x:30700:user_big +group30701:x:30701:user_big +group30702:x:30702:user_big +group30703:x:30703:user_big +group30704:x:30704:user_big +group30705:x:30705:user_big +group30706:x:30706:user_big +group30707:x:30707:user_big +group30708:x:30708:user_big +group30709:x:30709:user_big +group30710:x:30710:user_big +group30711:x:30711:user_big +group30712:x:30712:user_big +group30713:x:30713:user_big +group30714:x:30714:user_big +group30715:x:30715:user_big +group30716:x:30716:user_big +group30717:x:30717:user_big +group30718:x:30718:user_big +group30719:x:30719:user_big +group30720:x:30720:user_big +group30721:x:30721:user_big +group30722:x:30722:user_big +group30723:x:30723:user_big +group30724:x:30724:user_big +group30725:x:30725:user_big +group30726:x:30726:user_big +group30727:x:30727:user_big +group30728:x:30728:user_big +group30729:x:30729:user_big +group30730:x:30730:user_big +group30731:x:30731:user_big +group30732:x:30732:user_big +group30733:x:30733:user_big +group30734:x:30734:user_big +group30735:x:30735:user_big +group30736:x:30736:user_big +group30737:x:30737:user_big +group30738:x:30738:user_big +group30739:x:30739:user_big +group30740:x:30740:user_big +group30741:x:30741:user_big +group30742:x:30742:user_big +group30743:x:30743:user_big +group30744:x:30744:user_big +group30745:x:30745:user_big +group30746:x:30746:user_big +group30747:x:30747:user_big +group30748:x:30748:user_big +group30749:x:30749:user_big +group30750:x:30750:user_big +group30751:x:30751:user_big +group30752:x:30752:user_big +group30753:x:30753:user_big +group30754:x:30754:user_big +group30755:x:30755:user_big +group30756:x:30756:user_big +group30757:x:30757:user_big +group30758:x:30758:user_big +group30759:x:30759:user_big +group30760:x:30760:user_big +group30761:x:30761:user_big +group30762:x:30762:user_big +group30763:x:30763:user_big +group30764:x:30764:user_big +group30765:x:30765:user_big +group30766:x:30766:user_big +group30767:x:30767:user_big +group30768:x:30768:user_big +group30769:x:30769:user_big +group30770:x:30770:user_big +group30771:x:30771:user_big +group30772:x:30772:user_big +group30773:x:30773:user_big +group30774:x:30774:user_big +group30775:x:30775:user_big +group30776:x:30776:user_big +group30777:x:30777:user_big +group30778:x:30778:user_big +group30779:x:30779:user_big +group30780:x:30780:user_big +group30781:x:30781:user_big +group30782:x:30782:user_big +group30783:x:30783:user_big +group30784:x:30784:user_big +group30785:x:30785:user_big +group30786:x:30786:user_big +group30787:x:30787:user_big +group30788:x:30788:user_big +group30789:x:30789:user_big +group30790:x:30790:user_big +group30791:x:30791:user_big +group30792:x:30792:user_big +group30793:x:30793:user_big +group30794:x:30794:user_big +group30795:x:30795:user_big +group30796:x:30796:user_big +group30797:x:30797:user_big +group30798:x:30798:user_big +group30799:x:30799:user_big +group30800:x:30800:user_big +group30801:x:30801:user_big +group30802:x:30802:user_big +group30803:x:30803:user_big +group30804:x:30804:user_big +group30805:x:30805:user_big +group30806:x:30806:user_big +group30807:x:30807:user_big +group30808:x:30808:user_big +group30809:x:30809:user_big +group30810:x:30810:user_big +group30811:x:30811:user_big +group30812:x:30812:user_big +group30813:x:30813:user_big +group30814:x:30814:user_big +group30815:x:30815:user_big +group30816:x:30816:user_big +group30817:x:30817:user_big +group30818:x:30818:user_big +group30819:x:30819:user_big +group30820:x:30820:user_big +group30821:x:30821:user_big +group30822:x:30822:user_big +group30823:x:30823:user_big +group30824:x:30824:user_big +group30825:x:30825:user_big +group30826:x:30826:user_big +group30827:x:30827:user_big +group30828:x:30828:user_big +group30829:x:30829:user_big +group30830:x:30830:user_big +group30831:x:30831:user_big +group30832:x:30832:user_big +group30833:x:30833:user_big +group30834:x:30834:user_big +group30835:x:30835:user_big +group30836:x:30836:user_big +group30837:x:30837:user_big +group30838:x:30838:user_big +group30839:x:30839:user_big +group30840:x:30840:user_big +group30841:x:30841:user_big +group30842:x:30842:user_big +group30843:x:30843:user_big +group30844:x:30844:user_big +group30845:x:30845:user_big +group30846:x:30846:user_big +group30847:x:30847:user_big +group30848:x:30848:user_big +group30849:x:30849:user_big +group30850:x:30850:user_big +group30851:x:30851:user_big +group30852:x:30852:user_big +group30853:x:30853:user_big +group30854:x:30854:user_big +group30855:x:30855:user_big +group30856:x:30856:user_big +group30857:x:30857:user_big +group30858:x:30858:user_big +group30859:x:30859:user_big +group30860:x:30860:user_big +group30861:x:30861:user_big +group30862:x:30862:user_big +group30863:x:30863:user_big +group30864:x:30864:user_big +group30865:x:30865:user_big +group30866:x:30866:user_big +group30867:x:30867:user_big +group30868:x:30868:user_big +group30869:x:30869:user_big +group30870:x:30870:user_big +group30871:x:30871:user_big +group30872:x:30872:user_big +group30873:x:30873:user_big +group30874:x:30874:user_big +group30875:x:30875:user_big +group30876:x:30876:user_big +group30877:x:30877:user_big +group30878:x:30878:user_big +group30879:x:30879:user_big +group30880:x:30880:user_big +group30881:x:30881:user_big +group30882:x:30882:user_big +group30883:x:30883:user_big +group30884:x:30884:user_big +group30885:x:30885:user_big +group30886:x:30886:user_big +group30887:x:30887:user_big +group30888:x:30888:user_big +group30889:x:30889:user_big +group30890:x:30890:user_big +group30891:x:30891:user_big +group30892:x:30892:user_big +group30893:x:30893:user_big +group30894:x:30894:user_big +group30895:x:30895:user_big +group30896:x:30896:user_big +group30897:x:30897:user_big +group30898:x:30898:user_big +group30899:x:30899:user_big +group30900:x:30900:user_big +group30901:x:30901:user_big +group30902:x:30902:user_big +group30903:x:30903:user_big +group30904:x:30904:user_big +group30905:x:30905:user_big +group30906:x:30906:user_big +group30907:x:30907:user_big +group30908:x:30908:user_big +group30909:x:30909:user_big +group30910:x:30910:user_big +group30911:x:30911:user_big +group30912:x:30912:user_big +group30913:x:30913:user_big +group30914:x:30914:user_big +group30915:x:30915:user_big +group30916:x:30916:user_big +group30917:x:30917:user_big +group30918:x:30918:user_big +group30919:x:30919:user_big +group30920:x:30920:user_big +group30921:x:30921:user_big +group30922:x:30922:user_big +group30923:x:30923:user_big +group30924:x:30924:user_big +group30925:x:30925:user_big +group30926:x:30926:user_big +group30927:x:30927:user_big +group30928:x:30928:user_big +group30929:x:30929:user_big +group30930:x:30930:user_big +group30931:x:30931:user_big +group30932:x:30932:user_big +group30933:x:30933:user_big +group30934:x:30934:user_big +group30935:x:30935:user_big +group30936:x:30936:user_big +group30937:x:30937:user_big +group30938:x:30938:user_big +group30939:x:30939:user_big +group30940:x:30940:user_big +group30941:x:30941:user_big +group30942:x:30942:user_big +group30943:x:30943:user_big +group30944:x:30944:user_big +group30945:x:30945:user_big +group30946:x:30946:user_big +group30947:x:30947:user_big +group30948:x:30948:user_big +group30949:x:30949:user_big +group30950:x:30950:user_big +group30951:x:30951:user_big +group30952:x:30952:user_big +group30953:x:30953:user_big +group30954:x:30954:user_big +group30955:x:30955:user_big +group30956:x:30956:user_big +group30957:x:30957:user_big +group30958:x:30958:user_big +group30959:x:30959:user_big +group30960:x:30960:user_big +group30961:x:30961:user_big +group30962:x:30962:user_big +group30963:x:30963:user_big +group30964:x:30964:user_big +group30965:x:30965:user_big +group30966:x:30966:user_big +group30967:x:30967:user_big +group30968:x:30968:user_big +group30969:x:30969:user_big +group30970:x:30970:user_big +group30971:x:30971:user_big +group30972:x:30972:user_big +group30973:x:30973:user_big +group30974:x:30974:user_big +group30975:x:30975:user_big +group30976:x:30976:user_big +group30977:x:30977:user_big +group30978:x:30978:user_big +group30979:x:30979:user_big +group30980:x:30980:user_big +group30981:x:30981:user_big +group30982:x:30982:user_big +group30983:x:30983:user_big +group30984:x:30984:user_big +group30985:x:30985:user_big +group30986:x:30986:user_big +group30987:x:30987:user_big +group30988:x:30988:user_big +group30989:x:30989:user_big +group30990:x:30990:user_big +group30991:x:30991:user_big +group30992:x:30992:user_big +group30993:x:30993:user_big +group30994:x:30994:user_big +group30995:x:30995:user_big +group30996:x:30996:user_big +group30997:x:30997:user_big +group30998:x:30998:user_big +group30999:x:30999:user_big -- 2.1.0 From pvoborni at redhat.com Tue May 26 11:24:30 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 26 May 2015 13:24:30 +0200 Subject: [Freeipa-devel] [PATCH 144] extdom: add unit-test for get_user_grouplist() In-Reply-To: <20150526112119.GO3943@p.redhat.com> References: <20150526112119.GO3943@p.redhat.com> Message-ID: <556457EE.5040508@redhat.com> On 05/26/2015 01:21 PM, Sumit Bose wrote: > Hi, > > this tests should have gone together with > c1114ef82516002de08e004a930b5ba4a1791b25 but got lost somehow during the > bugzilla processing. > > bye, > Sumit > So it has been acked? And we can push it? -- Petr Vobornik From jcholast at redhat.com Tue May 26 11:31:42 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 26 May 2015 13:31:42 +0200 Subject: [Freeipa-devel] [PATCH 0259] Server Upgrade: Wait until DS is ready after restart In-Reply-To: <20150525140744.GC13469@dhcp-40-8.bne.redhat.com> References: <555DC3C3.30707@redhat.com> <20150521131637.GJ12806@dhcp-40-8.bne.redhat.com> <555F34E2.8090804@redhat.com> <5562BD8F.1050403@redhat.com> <20150525072004.GJ2915@dhcp-40-8.bne.redhat.com> <55630E2F.6050306@redhat.com> <556325DF.9060602@redhat.com> <20150525140744.GC13469@dhcp-40-8.bne.redhat.com> Message-ID: <5564599E.7010408@redhat.com> Dne 25.5.2015 v 16:07 Fraser Tweedale napsal(a): > On Mon, May 25, 2015 at 03:38:39PM +0200, Martin Basti wrote: >> On 25/05/15 13:57, Martin Basti wrote: >>> On 25/05/15 09:20, Fraser Tweedale wrote: >>>> On Mon, May 25, 2015 at 08:13:35AM +0200, Jan Cholasta wrote: >>>>> Dne 22.5.2015 v 15:53 Petr Vobornik napsal(a): >>>>>> On 05/21/2015 03:16 PM, Fraser Tweedale wrote: >>>>>>> On Thu, May 21, 2015 at 01:38:43PM +0200, Martin Basti wrote: >>>>>>>> This patch should fix following traceback. >>>>>>>> >>>>>>>> 2015-05-20T03:50:41Z ERROR Upgrade failed with cannot connect to >>>>>>>> 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': >>>>>>>> 2015-05-20T03:50:41Z DEBUG Traceback (most recent call last): >>>>>>>> File >>>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", >>>>>>>> >>>>>>>> line 304, in __upgrade >>>>>>>> ld = ldapupdate.LDAPUpdate(dm_password='', ldapi=True) >>>>>>>> File >>>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", >>>>>>>> line 314, in __init__ >>>>>>>> self.create_connection() >>>>>>>> File >>>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", >>>>>>>> line 862, in create_connection >>>>>>>> autobind=self.ldapi) >>>>>>>> File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line >>>>>>>> 66, in connect >>>>>>>> conn = self.create_connection(*args, **kw) >>>>>>>> File >>>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py", line >>>>>>>> 188, in create_connection >>>>>>>> client_controls=clientctrls) >>>>>>>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", >>>>>>>> line >>>>>>>> 1074, in external_bind >>>>>>>> '', auth_tokens, server_controls, client_controls) >>>>>>>> File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ >>>>>>>> self.gen.throw(type, value, traceback) >>>>>>>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", >>>>>>>> line >>>>>>>> 976, in error_handler >>>>>>>> error=info) >>>>>>>> NetworkError: cannot connect to >>>>>>>> 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': >>>>>>>> >>>>>>>> 2015-05-20T03:50:41Z DEBUG Traceback (most recent call last): >>>>>>>> File >>>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>>>>>>> line >>>>>>>> 388, in start_creation >>>>>>>> run_step(full_msg, method) >>>>>>>> File >>>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>>>>>>> line >>>>>>>> 378, in run_step >>>>>>>> method() >>>>>>>> File >>>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", >>>>>>>> >>>>>>>> line 315, in __upgrade >>>>>>>> raise RuntimeError(e) >>>>>>>> RuntimeError: cannot connect to >>>>>>>> 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': >>>>>>>> >>>>>>>> Reason was the ipa-server-install tried to connect before DS was >>>>>>>> ready. >>>>>>>> >>>>>>>> The patch adds waiting until DS is ready. >>>>>>>> >>>>>>>> Patch attached. >>>>>>>> >>>>>>>> Fraser can you please check if this fix works? I can't reproduce it. >>>>>>>> Thank you, Martin^2. >>>>>>>> >>>>>>> ACK; fixes the issue for me. >>>>>>> >>>>>>> One minor comment: >>>>>>> >>>>>>>> + def __start(self): >>>>>>>> + super(IPAUpgrade, self).start() >>>>>>>> >>>>>>>> def __stop_instance(self): >>>>>>>> """Stop only the main DS instance""" >>>>>>>> @@ -187,7 +185,7 @@ class IPAUpgrade(service.Service): >>>>>>>> self.step("saving configuration", self.__save_config) >>>>>>>> self.step("disabling listeners", self.__disable_listeners) >>>>>>>> self.step("enabling DS global lock", >>>>>>>> self.__enable_ds_global_write_lock) >>>>>>>> - self.step("starting directory server", self.__start_nowait) >>>>>>>> + self.step("starting directory server", self.__start) >>>>>>> I think you can just say `self.start' and remove `__start' function. >>>>>>> >>>>>>> Cheers, >>>>>>> Fraser >>>>>>> >>>>>> Pushed to master: 3d17bf8e639616893d6937d98662ccc7541d1e23 >>>>> This semi-breaks ipa-server-install for me: >>>>> >>>>> Configuring directory server (dirsrv): Estimated time 1 minute >>>>> [1/38]: creating directory server user >>>>> [2/38]: creating directory server instance >>>>> ipa : CRITICAL Failed to restart the directory server ([Errno >>>>> 2] No >>>>> such file or directory). See the installation log for details. >>>>> [3/38]: adding default schema >>>>> [4/38]: enabling memberof plugin >>>>> >>>>> It would be nice to check if the socket exists before waiting for it. >>>>> >>>> This (non-catastrophic but annoying) regression occurred for me too. >>>> I wasn't paying enough attention to ipa-server-install before I >>>> ACKed the patch :/ >>>> >>>>> -- >>>>> Jan Cholasta >>> Hello, >>> >>> this patch fixes the issue. >>> >>> >>> >>> >>> >> Updated patch attached >> >> -- >> Martin Basti >> > >> From 25c90638f02d36f3d992b6b20dbb66afb09e74f2 Mon Sep 17 00:00:00 2001 >> From: Martin Basti >> Date: Mon, 25 May 2015 09:01:42 +0200 >> Subject: [PATCH] Fix: use DS socket check only for upgrade >> >> To detect if DS server is running, use the slapd socket for upgrade, and the LDAP port >> for installation. >> >> Without enabled LDAPi socket checking doesnt work. >> >> https://fedorahosted.org/freeipa/ticket/4904 >> --- >> ipaplatform/redhat/services.py | 43 ++++++++++++++++++++++++------------ >> ipaserver/install/upgradeinstance.py | 3 ++- >> 2 files changed, 31 insertions(+), 15 deletions(-) >> >> diff --git a/ipaplatform/redhat/services.py b/ipaplatform/redhat/services.py >> index 565bf1fdef27e9a780ad2e2638b5051a95782bd2..757908f9581d5f04176dd5243fc64bec4c074c7f 100644 >> --- a/ipaplatform/redhat/services.py >> +++ b/ipaplatform/redhat/services.py >> @@ -25,6 +25,7 @@ Contains Red Hat OS family-specific service class implementations. >> import os >> import time >> import xml.dom.minidom >> +import contextlib >> >> from ipaplatform.tasks import tasks >> from ipaplatform.base import services as base_services >> @@ -124,7 +125,8 @@ class RedHatDirectoryService(RedHatService): >> >> return True >> >> - def restart(self, instance_name="", capture_output=True, wait=True): >> + def restart(self, instance_name="", capture_output=True, wait=True, >> + ldapi=False): >> # We need to explicitly enable instances to install proper symlinks as >> # dirsrv.target.wants/ dependencies. Standard systemd service class does it >> # on enable() method call. Unfortunately, ipa-server-install does not do >> @@ -150,22 +152,35 @@ class RedHatDirectoryService(RedHatService): >> os.unlink(srv_lnk) >> os.symlink(srv_etc, srv_lnk) >> >> - super(RedHatDirectoryService, self).restart(instance_name, >> - capture_output=capture_output, wait=wait) >> + with self.__wait(instance_name, wait, ldapi) as wait: >> + super(RedHatDirectoryService, self).restart( >> + instance_name, capture_output=capture_output, wait=wait) >> >> - def wait_for_open_ports(self, instance_name=""): >> - if instance_name.endswith('.service'): >> - instance_name = instance_name[:-8] >> - if instance_name.startswith('dirsrv@'): >> - instance_name = instance_name[7:] >> + def start(self, instance_name="", capture_output=True, wait=True, >> + ldapi=False): >> + with self.__wait(instance_name, wait, ldapi) as wait: >> + super(RedHatDirectoryService, self).start( >> + instance_name, capture_output=capture_output, wait=wait) >> >> - if instance_name: >> - >> - ipautil.wait_for_open_socket( >> - paths.SLAPD_INSTANCE_SOCKET_TEMPLATE % instance_name, >> - self.api.env.startup_timeout) >> + @contextlib.contextmanager >> + def __wait(self, instance_name, wait, ldapi): >> + if ldapi: >> + instance_name = self.service_instance(instance_name) >> + if instance_name.endswith('.service'): >> + instance_name = instance_name[:-8] >> + if instance_name.startswith('dirsrv'): >> + # this is intentional, return the empty string if the instance >> + # name is 'dirsrv' >> + instance_name = instance_name[7:] >> + if not instance_name: >> + ldapi = False >> + if ldapi: >> + yield False >> + socket_name = paths.SLAPD_INSTANCE_SOCKET_TEMPLATE % instance_name >> + ipautil.wait_for_open_socket(socket_name, >> + self.api.env.startup_timeout) >> else: >> - super(RedHatDirectoryService, self).wait_for_open_ports() >> + yield wait >> >> >> class RedHatIPAService(RedHatService): >> diff --git a/ipaserver/install/upgradeinstance.py b/ipaserver/install/upgradeinstance.py >> index d58c934bc1bd926c0c0c068086c746ac28e8c737..10f7c2ce0c25e733fb572502add82eedadf73d05 100644 >> --- a/ipaserver/install/upgradeinstance.py >> +++ b/ipaserver/install/upgradeinstance.py >> @@ -24,6 +24,7 @@ import shutil >> import random >> import traceback >> from ipaplatform.paths import paths >> +from ipaplatform import services >> from ipapython.ipa_log_manager import * >> from ipapython import ipaldap >> >> @@ -172,7 +173,7 @@ class IPAUpgrade(service.Service): >> self.realm = realm_name >> >> def __start(self): >> - super(IPAUpgrade, self).start() >> + services.service(self.service_name).start(self.serverid, ldapi=True) >> >> def __stop_instance(self): >> """Stop only the main DS instance""" >> -- >> 2.1.0 >> > I tested 0259.1 (it worked for install and update) but not 0259.2 > yet. 0259.2 looks OK though; ACK if tested for install and update. The new patch has only one additional minor fix for a potential problem that currently does not appear anywhere in install and update (see interdiff below), so I consider the ACK transitive. - if instance_name.startswith('dirsrv@'): + if instance_name.startswith('dirsrv'): + # this is intentional, return the empty string if the instance + # name is 'dirsrv' Pushed to master: f903c2d5bff3e420519f7bbf026b9bfcc5460fb0 -- Jan Cholasta From mbabinsk at redhat.com Tue May 26 11:32:20 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 26 May 2015 13:32:20 +0200 Subject: [Freeipa-devel] [PATCH 0260] Server Upgrade: fix the remove statement In-Reply-To: <55631F4F.9080201@redhat.com> References: <55631F4F.9080201@redhat.com> Message-ID: <556459C4.4090304@redhat.com> On 05/25/2015 03:10 PM, Martin Basti wrote: > This fixes issue with the remove statement, which causes LDAP error, > when the updater is trying to remove value from nonexistent entry. > > Reproducer: apply my patch mbasti-0256, install the IPA server without > the DNS subsystem. > > Patch attached. > https://fedorahosted.org/freeipa/ticket/4904 > > > ACK -- Martin^3 Babinsky From sbose at redhat.com Tue May 26 11:33:40 2015 From: sbose at redhat.com (Sumit Bose) Date: Tue, 26 May 2015 13:33:40 +0200 Subject: [Freeipa-devel] [PATCHES 145-148] ipa-kdb: add unit-test for filter_logon_info() Message-ID: <20150526113340.GP3943@p.redhat.com> Hi, these patches add some unit tests and some additional improvements related to the issues described in https://bugzilla.redhat.com/show_bug.cgi?id=1222475 . The original issue is fixed by a patch from Alexander attached to the ticket. The first patch converts the existing check-based test to cmocka. If I see it correctly all check-based test are converted now. The second adds tests for filter_logon_info() where the original issue occurred. The wrong behavior in filter_logon_info() caused a crash in dom_sid_string() which is made a bit more robust together with string_to_sid() in the 3rd patch. The last patch add unit tests for those two calls as well. bye, Sumit -------------- next part -------------- From ddd3ac0a38521ae9450f9dee46fbd8434ac85870 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Wed, 20 May 2015 18:31:19 +0200 Subject: [PATCH 145/148] ipa-kdb: convert test to cmocka --- daemons/ipa-kdb/Makefile.am | 6 +- daemons/ipa-kdb/tests/ipa_kdb_tests.c | 129 ++++++++++++---------------------- 2 files changed, 48 insertions(+), 87 deletions(-) diff --git a/daemons/ipa-kdb/Makefile.am b/daemons/ipa-kdb/Makefile.am index 80747491f8315a9cb0b38965423ba5d160946278..a4ea366b01b248d3f0fbc0b694e02d00c2e4c3d1 100644 --- a/daemons/ipa-kdb/Makefile.am +++ b/daemons/ipa-kdb/Makefile.am @@ -55,7 +55,7 @@ ipadb_la_LIBADD = \ $(NSS_LIBS) \ $(NULL) -if HAVE_CHECK +if HAVE_CMOCKA TESTS = ipa_kdb_tests check_PROGRAMS = ipa_kdb_tests endif @@ -73,9 +73,9 @@ ipa_kdb_tests_SOURCES = \ ipa_kdb_audit_as.c \ $(KRB5_UTIL_SRCS) \ $(NULL) -ipa_kdb_tests_CFLAGS = $(CHECK_CFLAGS) +ipa_kdb_tests_CFLAGS = $(CMOCKA_CFLAGS) ipa_kdb_tests_LDADD = \ - $(CHECK_LIBS) \ + $(CMOCKA_LIBS) \ $(KRB5_LIBS) \ $(LDAP_LIBS) \ $(NDRPAC_LIBS) \ diff --git a/daemons/ipa-kdb/tests/ipa_kdb_tests.c b/daemons/ipa-kdb/tests/ipa_kdb_tests.c index e1ae06a6e359e65873241116581f028f1a4e1bf3..1ff1cd49a4e409545ee908f0f7842520ae82e0a0 100644 --- a/daemons/ipa-kdb/tests/ipa_kdb_tests.c +++ b/daemons/ipa-kdb/tests/ipa_kdb_tests.c @@ -1,49 +1,30 @@ -/** BEGIN COPYRIGHT BLOCK - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation, either version 3 of the License, or - * (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program. If not, see . - * - * Additional permission under GPLv3 section 7: - * - * In the following paragraph, "GPL" means the GNU General Public - * License, version 3 or any later version, and "Non-GPL Code" means - * code that is governed neither by the GPL nor a license - * compatible with the GPL. - * - * You may link the code of this Program with Non-GPL Code and convey - * linked combinations including the two, provided that such Non-GPL - * Code only links to the code of this Program through those well - * defined interfaces identified in the file named EXCEPTION found in - * the source code files (the "Approved Interfaces"). The files of - * Non-GPL Code may instantiate templates or use macros or inline - * functions from the Approved Interfaces without causing the resulting - * work to be covered by the GPL. Only the copyright holders of this - * Program may make changes or additions to the list of Approved - * Interfaces. - * - * Authors: - * Sumit Bose - * - * Copyright (C) 2013 Red Hat, Inc. - * All rights reserved. - * END COPYRIGHT BLOCK **/ +/* + Authors: + Sumit Bose -#include -#include + Copyright (C) 2015 Red Hat + + ipa-kdb tests + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see . +*/ + +#include #include -#include -#include -#include -#include +#include +#include +#include #include "ipa-kdb/ipa_kdb.h" @@ -74,7 +55,7 @@ int krb5_klog_syslog(int l, const char *format, ...) extern void get_authz_data_types(krb5_context context, krb5_db_entry *entry, bool *with_pac, bool *with_pad); -START_TEST(test_get_authz_data_types) +void test_get_authz_data_types(void **state) { bool with_pac; bool with_pad; @@ -100,40 +81,40 @@ START_TEST(test_get_authz_data_types) with_pad = true; get_authz_data_types(NULL, NULL, NULL, &with_pad); - fail_unless(!with_pad, "with_pad not false with NULL inuput."); + assert_false(with_pad); with_pac = true; get_authz_data_types(NULL, NULL, &with_pac, NULL); - fail_unless(!with_pac, "with_pac not false with NULL inuput."); + assert_false(with_pad); with_pad = true; with_pac = true; get_authz_data_types(NULL, NULL, &with_pac, &with_pad); - fail_unless(!with_pad, "with_pad not false with NULL inuput."); - fail_unless(!with_pac, "with_pac not false with NULL inuput."); + assert_false(with_pac); + assert_false(with_pad); entry = calloc(1, sizeof(krb5_db_entry)); - fail_unless(entry != NULL, "calloc krb5_db_entry failed."); + assert_non_null(entry); ied = calloc(1, sizeof(struct ipadb_e_data)); - fail_unless(ied != NULL, "calloc struct ipadb_e_data failed."); + assert_non_null(ied); entry->e_data = (void *) ied; kerr = krb5_init_context(&krb5_ctx); - fail_unless(kerr == 0, "krb5_init_context failed."); + assert_int_equal(kerr, 0); kerr = krb5_db_setup_lib_handle(krb5_ctx); - fail_unless(kerr == 0, "krb5_db_setup_lib_handle failed.\n"); + assert_int_equal(kerr, 0); ipa_ctx = calloc(1, sizeof(struct ipadb_context)); - fail_unless(ipa_ctx != NULL, "calloc failed.\n"); + assert_non_null(ipa_ctx); ipa_ctx->kcontext = krb5_ctx; kerr = krb5_db_set_context(krb5_ctx, ipa_ctx); - fail_unless(kerr == 0, "krb5_db_set_context failed.\n"); + assert_int_equal(kerr, 0); kerr = krb5_parse_name(krb5_ctx, NFS_PRINC_STRING, &nfs_princ); - fail_unless(kerr == 0, "krb5_parse_name failed."); + assert_int_equal(kerr, 0); kerr = krb5_parse_name(krb5_ctx, NON_NFS_PRINC_STRING, &non_nfs_princ); - fail_unless(kerr == 0, "krb5_parse_name failed."); + assert_int_equal(kerr, 0); struct test_set { char **authz_data; @@ -179,12 +160,8 @@ START_TEST(test_get_authz_data_types) ipa_ctx->config.last_update = time(NULL); entry->princ = test_set[c].princ; get_authz_data_types(krb5_ctx, entry, &with_pac, &with_pad); - fail_unless(with_pad == test_set[c].exp_with_pad, "with_pad not %s %s.", - test_set[c].exp_with_pad ? "true" : "false", - test_set[c].err_msg); - fail_unless(with_pac == test_set[c].exp_with_pac, "with_pac not %s %s.", - test_set[c].exp_with_pac ? "true" : "false", - test_set[c].err_msg); + assert_true(with_pad == test_set[c].exp_with_pad); + assert_true(with_pac == test_set[c].exp_with_pac); } krb5_free_principal(krb5_ctx, nfs_princ); @@ -192,28 +169,12 @@ START_TEST(test_get_authz_data_types) krb5_db_fini(krb5_ctx); krb5_free_context(krb5_ctx); } -END_TEST -Suite * ipa_kdb_suite(void) +int main(int argc, const char *argv[]) { - Suite *s = suite_create("IPA kdb"); + const UnitTest tests[] = { + unit_test(test_get_authz_data_types), + }; - TCase *tc_helper = tcase_create("Helper functions"); - tcase_add_test(tc_helper, test_get_authz_data_types); - suite_add_tcase(s, tc_helper); - - return s; -} - -int main(void) -{ - int number_failed; - - Suite *s = ipa_kdb_suite (); - SRunner *sr = srunner_create (s); - srunner_run_all (sr, CK_VERBOSE); - number_failed = srunner_ntests_failed (sr); - srunner_free (sr); - - return (number_failed == 0) ? EXIT_SUCCESS : EXIT_FAILURE; + return run_tests(tests); } -- 2.1.0 -------------- next part -------------- From bc375ae2bd2f23f2a5fc7a45db13d732bec4f6d3 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 26 May 2015 10:26:28 +0200 Subject: [PATCH 146/148] ipa-kdb: add unit-test for filter_logon_info() --- daemons/ipa-kdb/ipa_kdb_mspac.c | 41 ++--- daemons/ipa-kdb/ipa_kdb_mspac_private.h | 57 +++++++ daemons/ipa-kdb/tests/ipa_kdb_tests.c | 275 +++++++++++++++++++++++++++++--- 3 files changed, 323 insertions(+), 50 deletions(-) create mode 100644 daemons/ipa-kdb/ipa_kdb_mspac_private.h diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index 0e53a8099dc272f7bfbf54a8b3cd13c8f472ca67..70b111ac7858f47324d71b8a53996e26fc52e9f5 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -28,31 +28,7 @@ #include "util/time.h" #include "gen_ndr/ndr_krb5pac.h" -struct ipadb_adtrusts { - char *domain_name; - char *flat_name; - char *domain_sid; - struct dom_sid domsid; - struct dom_sid *sid_blacklist_incoming; - int len_sid_blacklist_incoming; - struct dom_sid *sid_blacklist_outgoing; - int len_sid_blacklist_outgoing; - struct ipadb_adtrusts *parent; - char *parent_name; -}; - -struct ipadb_mspac { - char *flat_domain_name; - char *flat_server_name; - struct dom_sid domsid; - - char *fallback_group; - uint32_t fallback_rid; - - int num_trusts; - struct ipadb_adtrusts *trusts; - time_t last_update; -}; +#include "ipa_kdb_mspac_private.h" static char *user_pac_attrs[] = { "objectClass", @@ -113,10 +89,11 @@ static struct { #define AUTHZ_DATA_TYPE_PAD "PAD" #define AUTHZ_DATA_TYPE_NONE "NONE" -static int string_to_sid(char *str, struct dom_sid *sid) +int string_to_sid(const char *str, struct dom_sid *sid) { unsigned long val; - char *s, *t; + const char *s; + char *t; int i; memset(sid, '\0', sizeof(struct dom_sid)); @@ -174,7 +151,7 @@ static int string_to_sid(char *str, struct dom_sid *sid) return 0; } -static char *dom_sid_string(TALLOC_CTX *memctx, const struct dom_sid *dom_sid) +char *dom_sid_string(TALLOC_CTX *memctx, const struct dom_sid *dom_sid) { size_t c; size_t len; @@ -1317,10 +1294,10 @@ static void filter_logon_info_log_message(struct dom_sid *sid) } } -static krb5_error_code filter_logon_info(krb5_context context, - TALLOC_CTX *memctx, - krb5_data realm, - struct PAC_LOGON_INFO_CTR *info) +krb5_error_code filter_logon_info(krb5_context context, + TALLOC_CTX *memctx, + krb5_data realm, + struct PAC_LOGON_INFO_CTR *info) { /* We must refuse a PAC that comes signed with a cross realm TGT diff --git a/daemons/ipa-kdb/ipa_kdb_mspac_private.h b/daemons/ipa-kdb/ipa_kdb_mspac_private.h new file mode 100644 index 0000000000000000000000000000000000000000..be04071762316643d687e80986db0d7510e53ded --- /dev/null +++ b/daemons/ipa-kdb/ipa_kdb_mspac_private.h @@ -0,0 +1,57 @@ +/* + * MIT Kerberos KDC database backend for FreeIPA + * This head file contains private declarations for ipa_kdb_mspac.c and should + * be used only there or in unit-test. + * + * Authors: Sumit Bose + * + * see file 'COPYING' for use and warranty information + * + * This program is free software you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation, either version 3 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program. If not, see . + */ + + +#ifndef _IPA_KDB_MSPAC_PRIVATE_H_ +#define _IPA_KDB_MSPAC_PRIVATE_H_ + +struct ipadb_mspac { + char *flat_domain_name; + char *flat_server_name; + struct dom_sid domsid; + + char *fallback_group; + uint32_t fallback_rid; + + int num_trusts; + struct ipadb_adtrusts *trusts; + time_t last_update; +}; + +struct ipadb_adtrusts { + char *domain_name; + char *flat_name; + char *domain_sid; + struct dom_sid domsid; + struct dom_sid *sid_blacklist_incoming; + int len_sid_blacklist_incoming; + struct dom_sid *sid_blacklist_outgoing; + int len_sid_blacklist_outgoing; + struct ipadb_adtrusts *parent; + char *parent_name; +}; + +int string_to_sid(const char *str, struct dom_sid *sid); +char *dom_sid_string(TALLOC_CTX *memctx, const struct dom_sid *dom_sid); + +#endif /* _IPA_KDB_MSPAC_PRIVATE_H_ */ diff --git a/daemons/ipa-kdb/tests/ipa_kdb_tests.c b/daemons/ipa-kdb/tests/ipa_kdb_tests.c index 1ff1cd49a4e409545ee908f0f7842520ae82e0a0..7b9b85d2cf7fcc2478a522eccf686b3e2582447e 100644 --- a/daemons/ipa-kdb/tests/ipa_kdb_tests.c +++ b/daemons/ipa-kdb/tests/ipa_kdb_tests.c @@ -22,11 +22,19 @@ #include #include +#include #include +#include #include #include +#include + +#include "gen_ndr/ndr_krb5pac.h" +#include "gen_ndr/netlogon.h" + #include "ipa-kdb/ipa_kdb.h" +#include "ipa-kdb/ipa_kdb_mspac_private.h" #define NFS_PRINC_STRING "nfs/fully.qualified.host.name at REALM.NAME" #define NON_NFS_PRINC_STRING "abcdef/fully.qualified.host.name at REALM.NAME" @@ -52,6 +60,240 @@ int krb5_klog_syslog(int l, const char *format, ...) return 0; } +struct test_ctx { + krb5_context krb5_ctx; +}; + +#define DOMAIN_NAME "my.domain" +#define REALM "MY.DOMAIN" +#define REALM_LEN (sizeof(REALM) - 1) +#define FLAT_NAME "MYDOM" +#define DOM_SID "S-1-5-21-1-2-3" +#define DOM_SID_TRUST "S-1-5-21-4-5-6" +#define BLACKLIST_SID "S-1-5-1" + +void setup(void **state) +{ + int ret; + krb5_context krb5_ctx; + krb5_error_code kerr; + struct ipadb_context *ipa_ctx; + struct test_ctx *test_ctx; + + kerr = krb5_init_context(&krb5_ctx); + assert_int_equal(kerr, 0); + kerr = krb5_db_setup_lib_handle(krb5_ctx); + assert_int_equal(kerr, 0); + + ipa_ctx = calloc(1, sizeof(struct ipadb_context)); + assert_non_null(ipa_ctx); + + ipa_ctx->mspac = calloc(1, sizeof(struct ipadb_mspac)); + assert_non_null(ipa_ctx->mspac); + + /* make sure data is not read from LDAP */ + ipa_ctx->mspac->last_update = time(NULL) - 1; + + ret = string_to_sid(DOM_SID, &ipa_ctx->mspac->domsid); + assert_int_equal(ret, 0); + + ipa_ctx->mspac->num_trusts = 1; + ipa_ctx->mspac->trusts = calloc(1, sizeof(struct ipadb_adtrusts)); + assert_non_null(ipa_ctx->mspac->trusts); + + ipa_ctx->mspac->trusts[0].domain_name = strdup(DOMAIN_NAME); + assert_non_null(ipa_ctx->mspac->trusts[0].domain_name); + + ipa_ctx->mspac->trusts[0].flat_name = strdup(FLAT_NAME); + assert_non_null(ipa_ctx->mspac->trusts[0].flat_name); + + ipa_ctx->mspac->trusts[0].domain_sid = strdup(DOM_SID_TRUST); + assert_non_null(ipa_ctx->mspac->trusts[0].domain_sid); + + ret = string_to_sid(DOM_SID_TRUST, &ipa_ctx->mspac->trusts[0].domsid); + assert_int_equal(ret, 0); + + ipa_ctx->mspac->trusts[0].len_sid_blacklist_incoming = 1; + ipa_ctx->mspac->trusts[0].sid_blacklist_incoming = calloc( + ipa_ctx->mspac->trusts[0].len_sid_blacklist_incoming, + sizeof(struct dom_sid)); + assert_non_null(ipa_ctx->mspac->trusts[0].sid_blacklist_incoming); + ret = string_to_sid(BLACKLIST_SID, + &ipa_ctx->mspac->trusts[0].sid_blacklist_incoming[0]); + assert_int_equal(ret, 0); + + struct dom_sid *sid_blacklist_incoming; + int len_sid_blacklist_incoming; + + ipa_ctx->kcontext = krb5_ctx; + kerr = krb5_db_set_context(krb5_ctx, ipa_ctx); + assert_int_equal(kerr, 0); + + test_ctx = talloc(NULL, struct test_ctx); + assert_non_null(test_ctx); + + test_ctx->krb5_ctx = krb5_ctx; + + *state = test_ctx; +} + +void teardown(void **state) +{ + struct test_ctx *test_ctx; + struct ipadb_context *ipa_ctx; + + test_ctx = (struct test_ctx *) *state; + + ipa_ctx = ipadb_get_context(test_ctx->krb5_ctx); + assert_non_null(ipa_ctx); + ipadb_mspac_struct_free(&ipa_ctx->mspac); + + krb5_db_fini(test_ctx->krb5_ctx); + krb5_free_context(test_ctx->krb5_ctx); + + talloc_free(test_ctx); +} + +extern krb5_error_code filter_logon_info(krb5_context context, + TALLOC_CTX *memctx, + krb5_data realm, + struct PAC_LOGON_INFO_CTR *info); + +void test_filter_logon_info(void **state) +{ + krb5_error_code kerr; + krb5_data realm = {KV5M_DATA, REALM_LEN, REALM}; + struct test_ctx *test_ctx; + struct PAC_LOGON_INFO_CTR *info; + int ret; + struct dom_sid dom_sid; + size_t c; + size_t d; + + test_ctx = (struct test_ctx *) *state; + + info = talloc_zero(test_ctx, struct PAC_LOGON_INFO_CTR); + assert_non_null(info); + info->info = talloc_zero(info, struct PAC_LOGON_INFO); + assert_non_null(info->info); + + /* wrong flat name */ + info->info->info3.base.logon_domain.string = talloc_strdup(info->info, + "WRONG"); + assert_non_null(info->info->info3.base.logon_domain.string); + + kerr = filter_logon_info(test_ctx->krb5_ctx, test_ctx, realm, info); + assert_int_equal(kerr, EINVAL); + + info->info->info3.base.logon_domain.string = talloc_strdup(info->info, + FLAT_NAME); + assert_non_null(info->info->info3.base.logon_domain.string); + + /* missing domain SID */ + kerr = filter_logon_info(test_ctx->krb5_ctx, test_ctx, realm, info); + assert_int_equal(kerr, EINVAL); + + /* wrong domain SID */ + ret = string_to_sid("S-1-5-21-1-1-1", &dom_sid); + assert_int_equal(ret, 0); + info->info->info3.base.domain_sid = &dom_sid; + + kerr = filter_logon_info(test_ctx->krb5_ctx, test_ctx, realm, info); + assert_int_equal(kerr, EINVAL); + + /* matching domain SID */ + ret = string_to_sid(DOM_SID_TRUST, &dom_sid); + assert_int_equal(ret, 0); + info->info->info3.base.domain_sid = &dom_sid; + + kerr = filter_logon_info(test_ctx->krb5_ctx, test_ctx, realm, info); + assert_int_equal(kerr, 0); + + /* empty SIDs */ + info->info->info3.sidcount = 3; + info->info->info3.sids = talloc_zero_array(info->info, + struct netr_SidAttr, + info->info->info3.sidcount); + assert_non_null(info->info->info3.sids); + for(c = 0; c < info->info->info3.sidcount; c++) { + info->info->info3.sids[c].sid = talloc_zero(info->info->info3.sids, + struct dom_sid2); + assert_non_null(info->info->info3.sids[c].sid); + } + + kerr = filter_logon_info(test_ctx->krb5_ctx, NULL, realm, info); + assert_int_equal(kerr, 0); + assert_int_equal(info->info->info3.sidcount, 3); + + struct test_data { + size_t sidcount; + const char *sids[3]; + size_t exp_sidcount; + const char *exp_sids[3]; + } test_data[] = { + /* only allowed SIDs */ + {3, {DOM_SID_TRUST"-1000", DOM_SID_TRUST"-1001", DOM_SID_TRUST"-1002"}, + 3, {DOM_SID_TRUST"-1000", DOM_SID_TRUST"-1001", DOM_SID_TRUST"-1002"}}, + /* last SID filtered */ + {3, {DOM_SID_TRUST"-1000", DOM_SID_TRUST"-1001", BLACKLIST_SID"-1002"}, + 2, {DOM_SID_TRUST"-1000", DOM_SID_TRUST"-1001"}}, + /* center SID filtered */ + {3, {DOM_SID_TRUST"-1000", BLACKLIST_SID"-1001", DOM_SID_TRUST"-1002"}, + 2, {DOM_SID_TRUST"-1000", DOM_SID_TRUST"-1002"}}, + /* first SID filtered */ + {3, {BLACKLIST_SID"-1000", DOM_SID_TRUST"-1001", DOM_SID_TRUST"-1002"}, + 2, {DOM_SID_TRUST"-1001", DOM_SID_TRUST"-1002"}}, + /* first and last SID filtered */ + {3, {BLACKLIST_SID"-1000", DOM_SID_TRUST"-1001", BLACKLIST_SID"-1002"}, + 1, {DOM_SID_TRUST"-1001"}}, + /* two SIDs in a rwo filtered */ + {3, {BLACKLIST_SID"-1000", BLACKLIST_SID"-1001", DOM_SID_TRUST"-1002"}, + 1, {DOM_SID_TRUST"-1002"}}, + /* all SIDs filtered*/ + {3, {BLACKLIST_SID"-1000", BLACKLIST_SID"-1001", BLACKLIST_SID"-1002"}, + 0, NULL}, + {0, NULL, 0 , NULL} + }; + + for (c = 0; test_data[c].sidcount != 0; c++) { + talloc_free(info->info->info3.sids); + + info->info->info3.sidcount = test_data[c].sidcount; + info->info->info3.sids = talloc_zero_array(info->info, + struct netr_SidAttr, + info->info->info3.sidcount); + assert_non_null(info->info->info3.sids); + for(d = 0; d < info->info->info3.sidcount; d++) { + info->info->info3.sids[d].sid = talloc_zero(info->info->info3.sids, + struct dom_sid2); + assert_non_null(info->info->info3.sids[d].sid); + } + + for (d = 0; d < info->info->info3.sidcount; d++) { + ret = string_to_sid(test_data[c].sids[d], + info->info->info3.sids[d].sid); + assert_int_equal(ret, 0); + } + + kerr = filter_logon_info(test_ctx->krb5_ctx, NULL, realm, info); + assert_int_equal(kerr, 0); + assert_int_equal(info->info->info3.sidcount, test_data[c].exp_sidcount); + if (test_data[c].exp_sidcount == 0) { + assert_null(info->info->info3.sids); + } else { + for (d = 0; d < test_data[c].exp_sidcount; d++) { + assert_string_equal(test_data[c].exp_sids[d], + dom_sid_string(info->info->info3.sids, + info->info->info3.sids[d].sid)); + } + } + } + + + talloc_free(info); + +} + extern void get_authz_data_types(krb5_context context, krb5_db_entry *entry, bool *with_pac, bool *with_pad); @@ -76,6 +318,11 @@ void test_get_authz_data_types(void **state) struct ipadb_context *ipa_ctx; krb5_principal nfs_princ; krb5_principal non_nfs_princ; + struct test_ctx *test_ctx; + + test_ctx = (struct test_ctx *) *state; + ipa_ctx = ipadb_get_context(test_ctx->krb5_ctx); + assert_non_null(ipa_ctx); get_authz_data_types(NULL, NULL, NULL, NULL); @@ -100,20 +347,11 @@ void test_get_authz_data_types(void **state) assert_non_null(ied); entry->e_data = (void *) ied; - kerr = krb5_init_context(&krb5_ctx); - assert_int_equal(kerr, 0); - kerr = krb5_db_setup_lib_handle(krb5_ctx); - assert_int_equal(kerr, 0); - ipa_ctx = calloc(1, sizeof(struct ipadb_context)); - assert_non_null(ipa_ctx); - ipa_ctx->kcontext = krb5_ctx; - kerr = krb5_db_set_context(krb5_ctx, ipa_ctx); - assert_int_equal(kerr, 0); - - kerr = krb5_parse_name(krb5_ctx, NFS_PRINC_STRING, &nfs_princ); + kerr = krb5_parse_name(test_ctx->krb5_ctx, NFS_PRINC_STRING, &nfs_princ); assert_int_equal(kerr, 0); - kerr = krb5_parse_name(krb5_ctx, NON_NFS_PRINC_STRING, &non_nfs_princ); + kerr = krb5_parse_name(test_ctx->krb5_ctx, NON_NFS_PRINC_STRING, + &non_nfs_princ); assert_int_equal(kerr, 0); struct test_set { @@ -159,21 +397,22 @@ void test_get_authz_data_types(void **state) /* Set last_update to avoid LDAP lookups during tests */ ipa_ctx->config.last_update = time(NULL); entry->princ = test_set[c].princ; - get_authz_data_types(krb5_ctx, entry, &with_pac, &with_pad); + get_authz_data_types(test_ctx->krb5_ctx, entry, &with_pac, &with_pad); assert_true(with_pad == test_set[c].exp_with_pad); assert_true(with_pac == test_set[c].exp_with_pac); } - krb5_free_principal(krb5_ctx, nfs_princ); - krb5_free_principal(krb5_ctx, non_nfs_princ); - krb5_db_fini(krb5_ctx); - krb5_free_context(krb5_ctx); + free(ied); + free(entry); + krb5_free_principal(test_ctx->krb5_ctx, nfs_princ); + krb5_free_principal(test_ctx->krb5_ctx, non_nfs_princ); } int main(int argc, const char *argv[]) { const UnitTest tests[] = { - unit_test(test_get_authz_data_types), + unit_test_setup_teardown(test_get_authz_data_types, setup, teardown), + unit_test_setup_teardown(test_filter_logon_info, setup, teardown), }; return run_tests(tests); -- 2.1.0 -------------- next part -------------- From d113fa62f208e80dcfc354b1594dbf17783dc3b5 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 26 May 2015 13:00:26 +0200 Subject: [PATCH 147/148] ipa-kdb: make string_to_sid() and dom_sid_string() more robust --- daemons/ipa-kdb/ipa_kdb_mspac.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index 70b111ac7858f47324d71b8a53996e26fc52e9f5..7c0e4dc792dc99bb493477c88c11967b443a197f 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -96,6 +96,10 @@ int string_to_sid(const char *str, struct dom_sid *sid) char *t; int i; + if (str == NULL) { + return EINVAL; + } + memset(sid, '\0', sizeof(struct dom_sid)); s = str; @@ -159,13 +163,18 @@ char *dom_sid_string(TALLOC_CTX *memctx, const struct dom_sid *dom_sid) uint32_t ia; char *buf; - if (dom_sid == NULL) { + if (dom_sid == NULL + || dom_sid->num_auths < 0 + || dom_sid->num_auths > SID_SUB_AUTHS) { return NULL; } len = 25 + dom_sid->num_auths * 11; buf = talloc_zero_size(memctx, len); + if (buf == NULL) { + return NULL; + } ia = (dom_sid->id_auth[5]) + (dom_sid->id_auth[4] << 8 ) + -- 2.1.0 -------------- next part -------------- From 26cf5d8247a462bd3584fd4ad6a204c4592650fe Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 26 May 2015 13:01:13 +0200 Subject: [PATCH 148/148] ipa-kdb: add unit_tests for string_to_sid() and dom_sid_string() --- daemons/ipa-kdb/tests/ipa_kdb_tests.c | 60 +++++++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+) diff --git a/daemons/ipa-kdb/tests/ipa_kdb_tests.c b/daemons/ipa-kdb/tests/ipa_kdb_tests.c index 7b9b85d2cf7fcc2478a522eccf686b3e2582447e..edd4ae0975628d6b3abe9bab2852c990c9a8c590 100644 --- a/daemons/ipa-kdb/tests/ipa_kdb_tests.c +++ b/daemons/ipa-kdb/tests/ipa_kdb_tests.c @@ -408,11 +408,71 @@ void test_get_authz_data_types(void **state) krb5_free_principal(test_ctx->krb5_ctx, non_nfs_princ); } +void test_string_to_sid(void **state) +{ + int ret; + struct dom_sid sid; + struct dom_sid exp_sid = {1, 5, {0, 0, 0, 0, 0, 5}, + {21, 2127521184, 1604012920, 1887927527, 72713, + 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}}; + + ret = string_to_sid(NULL, &sid); + assert_int_equal(ret, EINVAL); + + ret = string_to_sid("abc", &sid); + assert_int_equal(ret, EINVAL); + + ret = string_to_sid("S-", &sid); + assert_int_equal(ret, EINVAL); + + ret = string_to_sid("S-ABC", &sid); + assert_int_equal(ret, EINVAL); + + ret = string_to_sid("S-123", &sid); + assert_int_equal(ret, EINVAL); + + ret = string_to_sid("S-1-123-1-2-3-4-5-6-7-8-9-0-1-2-3-4-5-6", &sid); + assert_int_equal(ret, EINVAL); + + ret = string_to_sid("S-1-5-21-2127521184-1604012920-1887927527-72713", + &sid); + assert_int_equal(ret, 0); + assert_memory_equal(&exp_sid, &sid, sizeof(struct dom_sid)); +} + +void test_dom_sid_string(void **state) +{ + struct test_ctx *test_ctx; + char *str_sid; + struct dom_sid test_sid = {1, 5, {0, 0, 0, 0, 0, 5}, + {21, 2127521184, 1604012920, 1887927527, 72713, + 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}}; + + test_ctx = (struct test_ctx *) *state; + + str_sid = dom_sid_string(test_ctx, NULL); + assert_null(str_sid); + + str_sid = dom_sid_string(test_ctx, &test_sid); + assert_non_null(str_sid); + assert_string_equal(str_sid, + "S-1-5-21-2127521184-1604012920-1887927527-72713"); + + test_sid.num_auths = -3; + str_sid = dom_sid_string(test_ctx, &test_sid); + + test_sid.num_auths = 16; + str_sid = dom_sid_string(test_ctx, &test_sid); +} + + int main(int argc, const char *argv[]) { const UnitTest tests[] = { unit_test_setup_teardown(test_get_authz_data_types, setup, teardown), unit_test_setup_teardown(test_filter_logon_info, setup, teardown), + unit_test(test_string_to_sid), + unit_test_setup_teardown(test_dom_sid_string, setup, teardown), }; return run_tests(tests); -- 2.1.0 From jcholast at redhat.com Tue May 26 11:33:29 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 26 May 2015 13:33:29 +0200 Subject: [Freeipa-devel] [PATCH 0260] Server Upgrade: fix the remove statement In-Reply-To: <556459C4.4090304@redhat.com> References: <55631F4F.9080201@redhat.com> <556459C4.4090304@redhat.com> Message-ID: <55645A09.5080501@redhat.com> Dne 26.5.2015 v 13:32 Martin Babinsky napsal(a): > On 05/25/2015 03:10 PM, Martin Basti wrote: >> This fixes issue with the remove statement, which causes LDAP error, >> when the updater is trying to remove value from nonexistent entry. >> >> Reproducer: apply my patch mbasti-0256, install the IPA server without >> the DNS subsystem. >> >> Patch attached. >> https://fedorahosted.org/freeipa/ticket/4904 >> >> >> > ACK > Pushed to master: 9eedffdfa62b4fa64244f048969b45b27a995c7a -- Jan Cholasta From mkosek at redhat.com Tue May 26 11:36:35 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 26 May 2015 13:36:35 +0200 Subject: [Freeipa-devel] [PATCHES 145-148] ipa-kdb: add unit-test for filter_logon_info() In-Reply-To: <20150526113340.GP3943@p.redhat.com> References: <20150526113340.GP3943@p.redhat.com> Message-ID: <55645AC3.9050304@redhat.com> On 05/26/2015 01:33 PM, Sumit Bose wrote: > Hi, > > these patches add some unit tests and some additional improvements > related to the issues described in > https://bugzilla.redhat.com/show_bug.cgi?id=1222475 . The original issue > is fixed by a patch from Alexander attached to the ticket. > > The first patch converts the existing check-based test to cmocka. If I > see it correctly all check-based test are converted now. Cool! Before pushing, we should also reference ticket https://fedorahosted.org/freeipa/ticket/4922 in the patch (no need to rebase right now). > > The second adds tests for filter_logon_info() where the original issue > occurred. The wrong behavior in filter_logon_info() caused a crash in > dom_sid_string() which is made a bit more robust together with > string_to_sid() in the 3rd patch. The last patch add unit tests for > those two calls as well. > > bye, > Sumit > > From sbose at redhat.com Tue May 26 11:40:04 2015 From: sbose at redhat.com (Sumit Bose) Date: Tue, 26 May 2015 13:40:04 +0200 Subject: [Freeipa-devel] [PATCH 144] extdom: add unit-test for get_user_grouplist() In-Reply-To: <556457EE.5040508@redhat.com> References: <20150526112119.GO3943@p.redhat.com> <556457EE.5040508@redhat.com> Message-ID: <20150526114004.GQ3943@p.redhat.com> On Tue, May 26, 2015 at 01:24:30PM +0200, Petr Vobornik wrote: > On 05/26/2015 01:21 PM, Sumit Bose wrote: > >Hi, > > > >this tests should have gone together with > >c1114ef82516002de08e004a930b5ba4a1791b25 but got lost somehow during the > >bugzilla processing. > > > >bye, > >Sumit > > > > So it has been acked? And we can push it? I have to admit that I'm not sure, there were just to many related tickets. Alexander, do you remember seeing this patch? If not, I think it would be good if someone can review it. Since it is "only" a unit-test, it is not urgent. bye, Sumit > -- > Petr Vobornik From abokovoy at redhat.com Tue May 26 11:44:28 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 26 May 2015 14:44:28 +0300 Subject: [Freeipa-devel] [PATCH 0259] Server Upgrade: Wait until DS is ready after restart In-Reply-To: <5564599E.7010408@redhat.com> References: <555DC3C3.30707@redhat.com> <20150521131637.GJ12806@dhcp-40-8.bne.redhat.com> <555F34E2.8090804@redhat.com> <5562BD8F.1050403@redhat.com> <20150525072004.GJ2915@dhcp-40-8.bne.redhat.com> <55630E2F.6050306@redhat.com> <556325DF.9060602@redhat.com> <20150525140744.GC13469@dhcp-40-8.bne.redhat.com> <5564599E.7010408@redhat.com> Message-ID: <20150526114428.GE19176@redhat.com> On Tue, 26 May 2015, Jan Cholasta wrote: >>I tested 0259.1 (it worked for install and update) but not 0259.2 >>yet. 0259.2 looks OK though; ACK if tested for install and update. > >The new patch has only one additional minor fix for a potential >problem that currently does not appear anywhere in install and update >(see interdiff below), so I consider the ACK transitive. > >- if instance_name.startswith('dirsrv@'): >+ if instance_name.startswith('dirsrv'): >+ # this is intentional, return the empty string if the >instance >+ # name is 'dirsrv' This one is actually pretty bad. If you only check for dirsrv, then dirsrv.service would get in it and you'd get instance_name[7:] returning empty string, not a service name at all: >>> s='dirsrv.service' >>> s[:-8] 'dirsrv' >>> s[:-8][7:] '' >>> s='dirsrv at foobar.service' >>> s[:-8] 'dirsrv at foobar' >>> s[:-8][7:] 'foobar' >>> -- / Alexander Bokovoy From abokovoy at redhat.com Tue May 26 11:47:02 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 26 May 2015 14:47:02 +0300 Subject: [Freeipa-devel] [PATCH 144] extdom: add unit-test for get_user_grouplist() In-Reply-To: <20150526114004.GQ3943@p.redhat.com> References: <20150526112119.GO3943@p.redhat.com> <556457EE.5040508@redhat.com> <20150526114004.GQ3943@p.redhat.com> Message-ID: <20150526114702.GF19176@redhat.com> On Tue, 26 May 2015, Sumit Bose wrote: >On Tue, May 26, 2015 at 01:24:30PM +0200, Petr Vobornik wrote: >> On 05/26/2015 01:21 PM, Sumit Bose wrote: >> >Hi, >> > >> >this tests should have gone together with >> >c1114ef82516002de08e004a930b5ba4a1791b25 but got lost somehow during the >> >bugzilla processing. >> > >> >bye, >> >Sumit >> > >> >> So it has been acked? And we can push it? > >I have to admit that I'm not sure, there were just to many related >tickets. Alexander, do you remember seeing this patch? If not, I think >it would be good if someone can review it. Since it is "only" a >unit-test, it is not urgent. I've seen this patch and I thought I've acked it by the time... -- / Alexander Bokovoy From tbabej at redhat.com Tue May 26 11:51:48 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 26 May 2015 13:51:48 +0200 Subject: [Freeipa-devel] [PATCH 0325] Add Domain Level feature In-Reply-To: <55644D46.1090602@redhat.com> References: <5554643E.4030600@redhat.com> <55546F6C.4060108@redhat.com> <555B390B.6000907@redhat.com> <555B3C61.7080508@redhat.com> <555B3F67.3040604@redhat.com> <555B3FFE.5040806@redhat.com> <555B4112.202@redhat.com> <555B41C8.7070503@redhat.com> <555B43BB.90404@redhat.com> <555E0572.8000600@redhat.com> <555EB9E7.3020800@redhat.com> <555F06AA.50206@redhat.com> <5562B380.8070609@redhat.com> <5562FC98.5040109@redhat.com> <55633C7F.1090103@redhat.com> <55644373.5000503@redhat.com> <55644D46.1090602@redhat.com> Message-ID: <55645E54.3000105@redhat.com> On 05/26/2015 12:39 PM, Tomas Babej wrote: > > > On 05/26/2015 11:57 AM, Jan Cholasta wrote: >> Dne 25.5.2015 v 17:15 Tomas Babej napsal(a): >>> >>> >>> On 05/25/2015 12:42 PM, Tomas Babej wrote: >>>> >>>> >>>> On 05/25/2015 07:30 AM, Jan Cholasta wrote: >>>>> Dne 22.5.2015 v 12:36 Petr Vobornik napsal(a): >>>>>> On 05/22/2015 07:08 AM, Jan Cholasta wrote: >>>>>>> Dne 21.5.2015 v 18:18 Tomas Babej napsal(a): >>>>>>>> >>>>>>>> >>>>>>>> On 05/19/2015 04:07 PM, Tomas Babej wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> 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 >>>>>>>> >>>>>>>> A new iteration of the patch, including the server-side checks >>>>>>>> for the >>>>>>>> installers. >>>>>>>> >>>>>>>> Tomas >>>>>>> >>>>>>> 1) >>>>>>> https://www.redhat.com/archives/freeipa-devel/2015-May/msg00228.html >>>>>>> - I still don't agree that the plugin should be based on LDAPObject. >>>>>> >>>>>> On the other hand, with LDAPObject base, Web UI for this feature is >>>>>> much >>>>>> more simpler because it can rely on existing conventions. >>>>> >>>>> Following this logic, should *everything* be based on LDAPObject, >>>>> because it would satisfy the convetion? I don't think so. The convetion >>>>> should not apply here, because domain level is conceptually *not* an >>>>> object, it is a property. IMHO having a clean API should be preferred >>>>> over implementation convenience. >>>>> >>>> >>>> I do not have strong opinions over this. Attached version implements >>>> a lightweight approach to the domainlevel related commands. >>>> >>>> Tomas >>>> >>>> >>>> >>> >>> Fixes a slight schema glitch. >>> >> >> Thanks for the patch! >> >> 1) >> >> + # Detect the current domain level >> + try: >> + current = remote_api.Command['domainlevel_show']['result'] >> + except KeyError: >> + # If we're joining an older master, domainlevel_show is >> not >> + # available >> + current = 0 >> >> KeyError? That does not look right. remote_api differs from api only in >> that it sets up ldap2 to connect to the remote server, but it uses local >> plugins and everything, so domainlevel_show should always be available. >> >> >> 2) Could you also set supported domain levels in >> install/share/master-entry.ldif? I think it makes sense to have them >> there right from the beginning of server install. >> >> >> 3) I think you should use the per-plugin api object instead of >> ipalib.api when constructing DNs (domainlevel_dn, container_masters). >> >> >> 4) I would say the opposite of "domainlevel-set" should be >> "domainlevel-get", not "domainlevel-show". IMO it's OK since property >> commands are an uncharted territory and don't have to (maybe even >> shouldn't) use the same convention as objects. >> >> >> 5) >> >> + 'System: Read Domain Level': { >> + 'ipapermlocation': DN('cn=masters,cn=ipa,cn=etc', api.env.basedn), >> + 'ipapermtargetfilter': {'(objectclass=ipadomainlevelconfig)'}, >> + 'ipapermbindruletype': 'all', >> + 'ipapermright': {'read', 'search', 'compare'}, >> + 'ipapermdefaultattr': { >> + 'ipadomainlevel', 'objectclass', >> + }, >> + }, >> >> Shouldn't ipapermlocation say "cn=Domain Level,cn=ipa,cn=etc"? >> > > Thanks for the review, I fixed all the issues raised. > > Tomas > Added a small fix for replca install, to avoid duplicated creation of the domainlevel entry. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0325-11-Add-Domain-Level-feature.patch Type: text/x-patch Size: 25217 bytes Desc: not available URL: From mbasti at redhat.com Tue May 26 11:54:13 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 26 May 2015 13:54:13 +0200 Subject: [Freeipa-devel] [PATCH 0259] Server Upgrade: Wait until DS is ready after restart In-Reply-To: <20150526114428.GE19176@redhat.com> References: <555DC3C3.30707@redhat.com> <20150521131637.GJ12806@dhcp-40-8.bne.redhat.com> <555F34E2.8090804@redhat.com> <5562BD8F.1050403@redhat.com> <20150525072004.GJ2915@dhcp-40-8.bne.redhat.com> <55630E2F.6050306@redhat.com> <556325DF.9060602@redhat.com> <20150525140744.GC13469@dhcp-40-8.bne.redhat.com> <5564599E.7010408@redhat.com> <20150526114428.GE19176@redhat.com> Message-ID: <55645EE5.8040300@redhat.com> On 26/05/15 13:44, Alexander Bokovoy wrote: > On Tue, 26 May 2015, Jan Cholasta wrote: >>> I tested 0259.1 (it worked for install and update) but not 0259.2 >>> yet. 0259.2 looks OK though; ACK if tested for install and update. >> >> The new patch has only one additional minor fix for a potential >> problem that currently does not appear anywhere in install and update >> (see interdiff below), so I consider the ACK transitive. >> >> - if instance_name.startswith('dirsrv@'): >> + if instance_name.startswith('dirsrv'): >> + # this is intentional, return the empty string if >> the instance >> + # name is 'dirsrv' > This one is actually pretty bad. If you only check for dirsrv, then > dirsrv.service would get in it and you'd get instance_name[7:] returning > empty string, not a service name at all: > >>> s='dirsrv.service' > >>> s[:-8] > 'dirsrv' > >>> s[:-8][7:] > '' > > >>> s='dirsrv at foobar.service' > >>> s[:-8] > 'dirsrv at foobar' > >>> s[:-8][7:] > 'foobar' > >>> Empty string is expected. Emptry string means the instance has not been specified, and check will be skipped. Because 'dirsrv.service' doest not contain instance name, so empty string should be returned. -- Martin Basti From tbabej at redhat.com Tue May 26 11:54:17 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 26 May 2015 13:54:17 +0200 Subject: [Freeipa-devel] [PATCH 0325] Add Domain Level feature In-Reply-To: <55645E54.3000105@redhat.com> References: <5554643E.4030600@redhat.com> <55546F6C.4060108@redhat.com> <555B390B.6000907@redhat.com> <555B3C61.7080508@redhat.com> <555B3F67.3040604@redhat.com> <555B3FFE.5040806@redhat.com> <555B4112.202@redhat.com> <555B41C8.7070503@redhat.com> <555B43BB.90404@redhat.com> <555E0572.8000600@redhat.com> <555EB9E7.3020800@redhat.com> <555F06AA.50206@redhat.com> <5562B380.8070609@redhat.com> <5562FC98.5040109@redhat.com> <55633C7F.1090103@redhat.com> <55644373.5000503@redhat.com> <55644D46.1090602@redhat.com> <55645E54.3000105@redhat.com> Message-ID: <55645EE9.60802@redhat.com> On 05/26/2015 01:51 PM, Tomas Babej wrote: > > > On 05/26/2015 12:39 PM, Tomas Babej wrote: >> >> >> On 05/26/2015 11:57 AM, Jan Cholasta wrote: >>> Dne 25.5.2015 v 17:15 Tomas Babej napsal(a): >>>> >>>> >>>> On 05/25/2015 12:42 PM, Tomas Babej wrote: >>>>> >>>>> >>>>> On 05/25/2015 07:30 AM, Jan Cholasta wrote: >>>>>> Dne 22.5.2015 v 12:36 Petr Vobornik napsal(a): >>>>>>> On 05/22/2015 07:08 AM, Jan Cholasta wrote: >>>>>>>> Dne 21.5.2015 v 18:18 Tomas Babej napsal(a): >>>>>>>>> >>>>>>>>> >>>>>>>>> On 05/19/2015 04:07 PM, Tomas Babej wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> A new iteration of the patch, including the server-side checks >>>>>>>>> for the >>>>>>>>> installers. >>>>>>>>> >>>>>>>>> Tomas >>>>>>>> >>>>>>>> 1) >>>>>>>> https://www.redhat.com/archives/freeipa-devel/2015-May/msg00228.html >>>>>>>> - I still don't agree that the plugin should be based on LDAPObject. >>>>>>> >>>>>>> On the other hand, with LDAPObject base, Web UI for this feature is >>>>>>> much >>>>>>> more simpler because it can rely on existing conventions. >>>>>> >>>>>> Following this logic, should *everything* be based on LDAPObject, >>>>>> because it would satisfy the convetion? I don't think so. The convetion >>>>>> should not apply here, because domain level is conceptually *not* an >>>>>> object, it is a property. IMHO having a clean API should be preferred >>>>>> over implementation convenience. >>>>>> >>>>> >>>>> I do not have strong opinions over this. Attached version implements >>>>> a lightweight approach to the domainlevel related commands. >>>>> >>>>> Tomas >>>>> >>>>> >>>>> >>>> >>>> Fixes a slight schema glitch. >>>> >>> >>> Thanks for the patch! >>> >>> 1) >>> >>> + # Detect the current domain level >>> + try: >>> + current = remote_api.Command['domainlevel_show']['result'] >>> + except KeyError: >>> + # If we're joining an older master, domainlevel_show is >>> not >>> + # available >>> + current = 0 >>> >>> KeyError? That does not look right. remote_api differs from api only in >>> that it sets up ldap2 to connect to the remote server, but it uses local >>> plugins and everything, so domainlevel_show should always be available. >>> >>> >>> 2) Could you also set supported domain levels in >>> install/share/master-entry.ldif? I think it makes sense to have them >>> there right from the beginning of server install. >>> >>> >>> 3) I think you should use the per-plugin api object instead of >>> ipalib.api when constructing DNs (domainlevel_dn, container_masters). >>> >>> >>> 4) I would say the opposite of "domainlevel-set" should be >>> "domainlevel-get", not "domainlevel-show". IMO it's OK since property >>> commands are an uncharted territory and don't have to (maybe even >>> shouldn't) use the same convention as objects. >>> >>> >>> 5) >>> >>> + 'System: Read Domain Level': { >>> + 'ipapermlocation': DN('cn=masters,cn=ipa,cn=etc', api.env.basedn), >>> + 'ipapermtargetfilter': {'(objectclass=ipadomainlevelconfig)'}, >>> + 'ipapermbindruletype': 'all', >>> + 'ipapermright': {'read', 'search', 'compare'}, >>> + 'ipapermdefaultattr': { >>> + 'ipadomainlevel', 'objectclass', >>> + }, >>> + }, >>> >>> Shouldn't ipapermlocation say "cn=Domain Level,cn=ipa,cn=etc"? >>> >> >> Thanks for the review, I fixed all the issues raised. >> >> Tomas >> > > Added a small fix for replca install, to avoid duplicated creation of > the domainlevel entry. > > Tomas > Aand the correct patch. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0325-12-Add-Domain-Level-feature.patch Type: text/x-patch Size: 25229 bytes Desc: not available URL: From mbabinsk at redhat.com Tue May 26 11:55:28 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 26 May 2015 13:55:28 +0200 Subject: [Freeipa-devel] [PATCH 0037] KRA: get the right dogtag version during server uninstall Message-ID: <55645F30.5030600@redhat.com> This little patch fixes an issue introduced by commit 6a4b428120c2e351ad0f1b4573f50b106844b1fd: If uninstalling IPA server with KRA enabled a wrong Dogtag version was being passed to KRA uninstaller due to missing config, resulting in uninstallation crash and inability to install new server instance. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0037-KRA-get-the-right-dogtag-version-during-server-unins.patch Type: text/x-patch Size: 980 bytes Desc: not available URL: From jcholast at redhat.com Tue May 26 12:00:24 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 26 May 2015 14:00:24 +0200 Subject: [Freeipa-devel] [PATCH 0325] Add Domain Level feature In-Reply-To: <55645EE9.60802@redhat.com> References: <5554643E.4030600@redhat.com> <55546F6C.4060108@redhat.com> <555B390B.6000907@redhat.com> <555B3C61.7080508@redhat.com> <555B3F67.3040604@redhat.com> <555B3FFE.5040806@redhat.com> <555B4112.202@redhat.com> <555B41C8.7070503@redhat.com> <555B43BB.90404@redhat.com> <555E0572.8000600@redhat.com> <555EB9E7.3020800@redhat.com> <555F06AA.50206@redhat.com> <5562B380.8070609@redhat.com> <5562FC98.5040109@redhat.com> <55633C7F.1090103@redhat.com> <55644373.5000503@redhat.com> <55644D46.1090602@redhat.com> <55645E54.3000105@redhat.com> <55645EE9.60802@redhat.com> Message-ID: <55646058.3050400@redhat.com> Dne 26.5.2015 v 13:54 Tomas Babej napsal(a): > > > On 05/26/2015 01:51 PM, Tomas Babej wrote: >> >> >> On 05/26/2015 12:39 PM, Tomas Babej wrote: >>> >>> >>> On 05/26/2015 11:57 AM, Jan Cholasta wrote: >>>> Dne 25.5.2015 v 17:15 Tomas Babej napsal(a): >>>>> >>>>> >>>>> On 05/25/2015 12:42 PM, Tomas Babej wrote: >>>>>> >>>>>> >>>>>> On 05/25/2015 07:30 AM, Jan Cholasta wrote: >>>>>>> Dne 22.5.2015 v 12:36 Petr Vobornik napsal(a): >>>>>>>> On 05/22/2015 07:08 AM, Jan Cholasta wrote: >>>>>>>>> Dne 21.5.2015 v 18:18 Tomas Babej napsal(a): >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 05/19/2015 04:07 PM, Tomas Babej wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> A new iteration of the patch, including the server-side checks >>>>>>>>>> for the >>>>>>>>>> installers. >>>>>>>>>> >>>>>>>>>> Tomas >>>>>>>>> >>>>>>>>> 1) >>>>>>>>> https://www.redhat.com/archives/freeipa-devel/2015-May/msg00228.html >>>>>>>>> - I still don't agree that the plugin should be based on LDAPObject. >>>>>>>> >>>>>>>> On the other hand, with LDAPObject base, Web UI for this feature is >>>>>>>> much >>>>>>>> more simpler because it can rely on existing conventions. >>>>>>> >>>>>>> Following this logic, should *everything* be based on LDAPObject, >>>>>>> because it would satisfy the convetion? I don't think so. The convetion >>>>>>> should not apply here, because domain level is conceptually *not* an >>>>>>> object, it is a property. IMHO having a clean API should be preferred >>>>>>> over implementation convenience. >>>>>>> >>>>>> >>>>>> I do not have strong opinions over this. Attached version implements >>>>>> a lightweight approach to the domainlevel related commands. >>>>>> >>>>>> Tomas >>>>>> >>>>>> >>>>>> >>>>> >>>>> Fixes a slight schema glitch. >>>>> >>>> >>>> Thanks for the patch! >>>> >>>> 1) >>>> >>>> + # Detect the current domain level >>>> + try: >>>> + current = remote_api.Command['domainlevel_show']['result'] >>>> + except KeyError: >>>> + # If we're joining an older master, domainlevel_show is >>>> not >>>> + # available >>>> + current = 0 >>>> >>>> KeyError? That does not look right. remote_api differs from api only in >>>> that it sets up ldap2 to connect to the remote server, but it uses local >>>> plugins and everything, so domainlevel_show should always be available. >>>> >>>> >>>> 2) Could you also set supported domain levels in >>>> install/share/master-entry.ldif? I think it makes sense to have them >>>> there right from the beginning of server install. >>>> >>>> >>>> 3) I think you should use the per-plugin api object instead of >>>> ipalib.api when constructing DNs (domainlevel_dn, container_masters). >>>> >>>> >>>> 4) I would say the opposite of "domainlevel-set" should be >>>> "domainlevel-get", not "domainlevel-show". IMO it's OK since property >>>> commands are an uncharted territory and don't have to (maybe even >>>> shouldn't) use the same convention as objects. >>>> >>>> >>>> 5) >>>> >>>> + 'System: Read Domain Level': { >>>> + 'ipapermlocation': DN('cn=masters,cn=ipa,cn=etc', api.env.basedn), >>>> + 'ipapermtargetfilter': {'(objectclass=ipadomainlevelconfig)'}, >>>> + 'ipapermbindruletype': 'all', >>>> + 'ipapermright': {'read', 'search', 'compare'}, >>>> + 'ipapermdefaultattr': { >>>> + 'ipadomainlevel', 'objectclass', >>>> + }, >>>> + }, >>>> >>>> Shouldn't ipapermlocation say "cn=Domain Level,cn=ipa,cn=etc"? >>>> >>> >>> Thanks for the review, I fixed all the issues raised. >>> >>> Tomas >>> >> >> Added a small fix for replca install, to avoid duplicated creation of >> the domainlevel entry. >> >> Tomas >> > > Aand the correct patch. Thanks, ACK. Pushed to master: f3010498af2a4b98512d219b8e09101176c172fe -- Jan Cholasta From mkosek at redhat.com Tue May 26 12:09:03 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 26 May 2015 14:09:03 +0200 Subject: [Freeipa-devel] [PATCH] 1112 Add service constraint delegation plugin In-Reply-To: <555CB00B.3080309@redhat.com> References: <555B4696.2070502@redhat.com> <555BA115.5070408@redhat.com> <555CB00B.3080309@redhat.com> Message-ID: <5564625F.4030406@redhat.com> On 05/20/2015 06:02 PM, Rob Crittenden wrote: > Rob Crittenden wrote: >> 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. > > I must be getting rustly. Forgot to include ACIs. Added now. Thanks Rob! Martin Basti planned to look at this patch set. BTW, I did not see any design. Would it be fine with you to prepare some? This is a new feature, far from straightforward one, so it would be very helpful to have some metadata and docs on FreeIPA.org design. Thanks, Martin From pspacek at redhat.com Tue May 26 12:12:33 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 26 May 2015 14:12:33 +0200 Subject: [Freeipa-devel] Domain level for topology plugin = 2 Message-ID: <55646331.5050807@redhat.com> Hello, it came to my mind that domain level for topology plugin should actually be number 2, not 1. We already used number 1 for incompatible changes in DNS tree and I believe that it is not a good idea to have two places which say 'version 1' but and actually mean two different things. (DNS tree version 1 + domain level 1) Patch is attached. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0029-Bump-domain-level-for-topology-plugin-to-2.patch Type: text/x-patch Size: 1425 bytes Desc: not available URL: From jcholast at redhat.com Tue May 26 12:17:17 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 26 May 2015 14:17:17 +0200 Subject: [Freeipa-devel] [PATCH] 855 server-find and server-show commands In-Reply-To: <556452F7.2020201@redhat.com> References: <5564476F.2090100@redhat.com> <556452F7.2020201@redhat.com> Message-ID: <5564644D.30409@redhat.com> Dne 26.5.2015 v 13:03 Petr Vobornik napsal(a): > On 05/26/2015 12:14 PM, Petr Vobornik wrote: >> the patch is rebased on top of tbabej 325-9 (but it might not be needed) >> >> ipa server-find >> ipa server-show FQDN >> >> These commands display a list of IPA servers stored in >> cn=masters,cn=ipa,cn=etc,$SUFFIX >> >> https://fedorahosted.org/freeipa/ticket/4302 (maybe we could create a >> different one) >> > > minor update based on Honza's offline comments Thanks, ACK. Rebased and pushed to master: 41662eb9f02fc6bf1399508a13de8d6f18d7b3b1 -- Jan Cholasta From jcholast at redhat.com Tue May 26 12:44:08 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 26 May 2015 14:44:08 +0200 Subject: [Freeipa-devel] [PATCH 0037] KRA: get the right dogtag version during server uninstall In-Reply-To: <55645F30.5030600@redhat.com> References: <55645F30.5030600@redhat.com> Message-ID: <55646A98.8050502@redhat.com> Hi, Dne 26.5.2015 v 13:55 Martin Babinsky napsal(a): > This little patch fixes an issue introduced by commit > 6a4b428120c2e351ad0f1b4573f50b106844b1fd: > > If uninstalling IPA server with KRA enabled a wrong Dogtag version was > being passed to KRA uninstaller due to missing config, resulting in > uninstallation crash and inability to install new server instance. > Thanks, ACK. Added ticket URL and Pushed to master: 01fa05dd4ec7bd79abee8df0dd3642eabf138bcf Honza -- Jan Cholasta From pvoborni at redhat.com Tue May 26 13:31:27 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 26 May 2015 15:31:27 +0200 Subject: [Freeipa-devel] [PATCH] 857 topology: ipa management commands In-Reply-To: <556448B3.9050105@redhat.com> References: <556448B3.9050105@redhat.com> Message-ID: <556475AF.7060301@redhat.com> On 05/26/2015 12:19 PM, Petr Vobornik wrote: > this patch is based on top of my patch #856 and tbabej' > s 325-9. > > Obsoletes Ludwig's 0006. > > ipalib part of topology management > > Design: > - http://www.freeipa.org/page/V4/Manage_replication_topology > > https://fedorahosted.org/freeipa/ticket/4302 > > New version attached: - domainlevel_show usage changed to domainlevel_get - updated VERSION - added more attrs to default_attributes -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0857-1-topology-ipa-management-commands.patch Type: text/x-patch Size: 27558 bytes Desc: not available URL: From ofayans at redhat.com Tue May 26 13:56:40 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 26 May 2015 15:56:40 +0200 Subject: [Freeipa-devel] [PATCH] 857 topology: ipa management commands In-Reply-To: <556475AF.7060301@redhat.com> References: <556448B3.9050105@redhat.com> <556475AF.7060301@redhat.com> Message-ID: <55647B98.9030907@redhat.com> Hi Petr, team After playing around with the previous version of your patch applied on top of the current master branch today in the morning, I still observe the problem with replica installation, described here: https://fedorahosted.org/freeipa/ticket/5035 the session transcript together with ipareplica-install.log and the errors log of the dirsrv on master are attached. The following lines in the error log might be of interest: [26/May/2015:08:46:09 -0400] NSMMReplicationPlugin - Finished total update of replica "agmt="cn=meToreplica1.pesen.net" (replica1:389)". Sent 382 entries. [26/May/2015:08:46:11 -0400] ipa-topology-plugin - ipa_topo_util_modify: failed to modify entry (cn=meToreplica1.pesen.net,cn=replica,cn=dc\3Dpesen\2Cdc\3Dnet,cn=mapping tree,cn=config): error 53 [26/May/2015:08:46:17 -0400] repl_version_plugin_recv_acquire_cb - [file ipa_repl_version.c, line 119]: Incompatible IPA versions, pausing replication. This server: "20100614120000" remote server: "(null)". [26/May/2015:08:46:38 -0400] NSMMReplicationPlugin - agmt="cn=meToreplica1.pesen.net" (replica1:389): Unable to receive the response for a startReplication extended operation to consumer (Can't contact LDAP server). Will retry later. [26/May/2015:08:46:41 -0400] NSMMReplicationPlugin - agmt="cn=meToreplica1.pesen.net" (replica1:389): Replication bind with SIMPLE auth resumed [26/May/2015:08:47:42 -0400] NSMMReplicationPlugin - Beginning total update of replica "agmt="cn=masterAgreement1-replica1.pesen.net-pki-tomcat" (replica1:389)". [26/May/2015:08:47:46 -0400] NSMMReplicationPlugin - Finished total update of replica "agmt="cn=masterAgreement1-replica1.pesen.net-pki-tomcat" (replica1:389)". Sent 70 entries. [26/May/2015:08:48:28 -0400] repl_version_plugin_recv_acquire_cb - [file ipa_repl_version.c, line 119]: Incompatible IPA versions, pausing replication. This server: "20100614120000" remote server: "(null)". [26/May/2015:08:48:28 -0400] repl_version_plugin_recv_acquire_cb - [file ipa_repl_version.c, line 119]: Incompatible IPA versions, pausing replication. This server: "20100614120000" remote server: "(null)". Should I rebuild the packages with the latest version of your patch on top of the current master with Tomas' latest Domain Level-related changes and try again? On 05/26/2015 03:31 PM, Petr Vobornik wrote: > On 05/26/2015 12:19 PM, Petr Vobornik wrote: >> this patch is based on top of my patch #856 and tbabej' >> s 325-9. >> >> Obsoletes Ludwig's 0006. >> >> ipalib part of topology management >> >> Design: >> - http://www.freeipa.org/page/V4/Manage_replication_topology >> >> https://fedorahosted.org/freeipa/ticket/4302 >> >> > > New version attached: > - domainlevel_show usage changed to domainlevel_get > - updated VERSION > - added more attrs to default_attributes > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- 389-Directory/1.3.4.a1 B2015.070.423 mymaster.pesen.net:389 (/etc/dirsrv/slapd-PESEN-NET) [26/May/2015:08:12:20 -0400] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [26/May/2015:08:12:20 -0400] - check_and_set_import_cache: pagesize: 4096, pages: 512432, procpages: 54077 [26/May/2015:08:12:20 -0400] - Import allocates 819888KB import cache. [26/May/2015:08:12:20 -0400] - import userRoot: Beginning import job... [26/May/2015:08:12:20 -0400] - import userRoot: Index buffering enabled with bucket size 100 [26/May/2015:08:12:20 -0400] - import userRoot: Processing file "/var/lib/dirsrv/boot.ldif" [26/May/2015:08:12:20 -0400] - import userRoot: Finished scanning file "/var/lib/dirsrv/boot.ldif" (1 entries) [26/May/2015:08:12:21 -0400] - import userRoot: Workers finished; cleaning up... [26/May/2015:08:12:21 -0400] - import userRoot: Workers cleaned up. [26/May/2015:08:12:21 -0400] - import userRoot: Cleaning up producer thread... [26/May/2015:08:12:21 -0400] - import userRoot: Indexing complete. Post-processing... [26/May/2015:08:12:21 -0400] - import userRoot: Generating numsubordinates (this may take several minutes to complete)... [26/May/2015:08:12:21 -0400] - import userRoot: Generating numSubordinates complete. [26/May/2015:08:12:21 -0400] - import userRoot: Gathering ancestorid non-leaf IDs... [26/May/2015:08:12:21 -0400] - import userRoot: Finished gathering ancestorid non-leaf IDs. [26/May/2015:08:12:21 -0400] - Nothing to do to build ancestorid index [26/May/2015:08:12:21 -0400] - import userRoot: Created ancestorid index (new idl). [26/May/2015:08:12:21 -0400] - import userRoot: Flushing caches... [26/May/2015:08:12:21 -0400] - import userRoot: Closing files... [26/May/2015:08:12:21 -0400] - All database threads now stopped [26/May/2015:08:12:21 -0400] - import userRoot: Import complete. Processed 1 entries in 1 seconds. (1.00 entries/sec) [26/May/2015:08:12:23 -0400] - 389-Directory/1.3.4.a1 B2015.070.423 starting up [26/May/2015:08:12:23 -0400] - Db home directory is not set. Possibly nsslapd-directory (optionally nsslapd-db-home-directory) is missing in the config file. [26/May/2015:08:12:23 -0400] - resizing db cache size: 839565312 -> 6400000 [26/May/2015:08:12:23 -0400] - slapd started. Listening on All Interfaces port 389 for LDAP requests [26/May/2015:08:12:23 -0400] - convert_pbe_des_to_aes: Converting DES passwords to AES... [26/May/2015:08:12:23 -0400] - convert_pbe_des_to_aes: Successfully disabled DES plugin (cn=DES,cn=Password Storage Schemes,cn=plugins,cn=config) [26/May/2015:08:12:23 -0400] - convert_pbe_des_to_aes: Finished - no DES passwords to convert. [26/May/2015:08:12:24 -0400] - slapd shutting down - signaling operation threads - op stack size 0 max work q size 0 max work q stack size 0 [26/May/2015:08:12:24 -0400] - slapd shutting down - closing down internal subsystems and plugins [26/May/2015:08:12:24 -0400] - Waiting for 4 database threads to stop [26/May/2015:08:12:25 -0400] - All database threads now stopped [26/May/2015:08:12:25 -0400] - slapd shutting down - freed 0 work q stack objects - freed 0 op stack objects [26/May/2015:08:12:25 -0400] - slapd stopped. [26/May/2015:08:12:26 -0400] - 389-Directory/1.3.4.a1 B2015.070.423 starting up [26/May/2015:08:12:26 -0400] - resizing db cache size: 6400000 -> 5120000 [26/May/2015:08:12:27 -0400] - slapd started. Listening on All Interfaces port 389 for LDAP requests [26/May/2015:08:17:26 -0400] - The change of nsslapd-ldapilisten will not take effect until the server is restarted [26/May/2015:08:17:27 -0400] - slapd shutting down - signaling operation threads - op stack size 2 max work q size 1 max work q stack size 1 [26/May/2015:08:17:27 -0400] - slapd shutting down - waiting for 1 thread to terminate [26/May/2015:08:17:27 -0400] - slapd shutting down - closing down internal subsystems and plugins [26/May/2015:08:17:28 -0400] - Waiting for 4 database threads to stop [26/May/2015:08:17:28 -0400] - All database threads now stopped [26/May/2015:08:17:28 -0400] - slapd shutting down - freed 1 work q stack objects - freed 2 op stack objects [26/May/2015:08:17:28 -0400] - slapd stopped. [26/May/2015:08:17:29 -0400] - 389-Directory/1.3.4.a1 B2015.070.423 starting up [26/May/2015:08:17:29 -0400] - resizing db cache size: 5120000 -> 4096000 [26/May/2015:08:17:31 -0400] ipalockout_get_global_config - [file ipa_lockout.c, line 185]: Failed to get default realm (-1765328160) [26/May/2015:08:17:32 -0400] ipaenrollment_start - [file ipa_enrollment.c, line 393]: Failed to get default realm?! [26/May/2015:08:17:32 -0400] - slapd started. Listening on All Interfaces port 389 for LDAP requests [26/May/2015:08:17:32 -0400] - Listening on /var/run/slapd-PESEN-NET.socket for LDAPI requests [26/May/2015:08:17:38 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=pesen,dc=net--no CoS Templates found, which should be added before the CoS Definition. [26/May/2015:08:17:40 -0400] NSACLPlugin - The ACL target cn=retrieve certificate,cn=virtual operations,cn=etc,dc=pesen,dc=net does not exist [26/May/2015:08:17:40 -0400] NSACLPlugin - The ACL target cn=request certificate,cn=virtual operations,cn=etc,dc=pesen,dc=net does not exist [26/May/2015:08:17:40 -0400] NSACLPlugin - The ACL target cn=request certificate different host,cn=virtual operations,cn=etc,dc=pesen,dc=net does not exist [26/May/2015:08:17:40 -0400] NSACLPlugin - The ACL target cn=certificate status,cn=virtual operations,cn=etc,dc=pesen,dc=net does not exist [26/May/2015:08:17:41 -0400] NSACLPlugin - The ACL target cn=revoke certificate,cn=virtual operations,cn=etc,dc=pesen,dc=net does not exist [26/May/2015:08:17:41 -0400] NSACLPlugin - The ACL target cn=certificate remove hold,cn=virtual operations,cn=etc,dc=pesen,dc=net does not exist [26/May/2015:08:17:42 -0400] memberof-plugin - Memberof task starts (arg: (objectclass=*)) ... [26/May/2015:08:17:42 -0400] memberof-plugin - Memberof task finished (arg: (objectclass=*)) ... [26/May/2015:08:17:45 -0400] - slapd shutting down - signaling operation threads - op stack size 3 max work q size 2 max work q stack size 2 [26/May/2015:08:17:45 -0400] - slapd shutting down - waiting for 3 threads to terminate [26/May/2015:08:17:45 -0400] - slapd shutting down - closing down internal subsystems and plugins [26/May/2015:08:17:46 -0400] - Waiting for 4 database threads to stop [26/May/2015:08:17:47 -0400] - All database threads now stopped [26/May/2015:08:17:47 -0400] - slapd shutting down - freed 2 work q stack objects - freed 3 op stack objects [26/May/2015:08:17:47 -0400] - slapd stopped. [26/May/2015:08:17:48 -0400] - 389-Directory/1.3.4.a1 B2015.070.423 starting up [26/May/2015:08:17:48 -0400] - resizing db cache size: 4096000 -> 3276800 [26/May/2015:08:17:49 -0400] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=pesen,dc=net [26/May/2015:08:17:49 -0400] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=pesen,dc=net [26/May/2015:08:17:49 -0400] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=pesen,dc=net [26/May/2015:08:17:49 -0400] NSACLPlugin - The ACL target cn=retrieve certificate,cn=virtual operations,cn=etc,dc=pesen,dc=net does not exist [26/May/2015:08:17:49 -0400] NSACLPlugin - The ACL target cn=request certificate,cn=virtual operations,cn=etc,dc=pesen,dc=net does not exist [26/May/2015:08:17:49 -0400] NSACLPlugin - The ACL target cn=request certificate different host,cn=virtual operations,cn=etc,dc=pesen,dc=net does not exist [26/May/2015:08:17:49 -0400] NSACLPlugin - The ACL target cn=certificate status,cn=virtual operations,cn=etc,dc=pesen,dc=net does not exist [26/May/2015:08:17:49 -0400] NSACLPlugin - The ACL target cn=revoke certificate,cn=virtual operations,cn=etc,dc=pesen,dc=net does not exist [26/May/2015:08:17:49 -0400] NSACLPlugin - The ACL target cn=certificate remove hold,cn=virtual operations,cn=etc,dc=pesen,dc=net does not exist [26/May/2015:08:17:49 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=pesen,dc=net--no CoS Templates found, which should be added before the CoS Definition. [26/May/2015:08:17:49 -0400] ipalockout_get_global_config - [file ipa_lockout.c, line 185]: Failed to get default realm (-1765328160) [26/May/2015:08:17:49 -0400] ipaenrollment_start - [file ipa_enrollment.c, line 393]: Failed to get default realm?! [26/May/2015:08:17:49 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=pesen,dc=net--no CoS Templates found, which should be added before the CoS Definition. [26/May/2015:08:17:49 -0400] - slapd started. Listening on All Interfaces port 389 for LDAP requests [26/May/2015:08:17:49 -0400] - Listening on /var/run/slapd-PESEN-NET.socket for LDAPI requests [26/May/2015:08:17:49 -0400] - The change of nsslapd-maxdescriptors will not take effect until the server is restarted [26/May/2015:08:18:27 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=pesen,dc=net--no CoS Templates found, which should be added before the CoS Definition. [26/May/2015:08:19:25 -0400] - ipaca: Indexing VLV: allCerts-pki-tomcatIndex [26/May/2015:08:19:25 -0400] - ipaca: Indexing VLV: allExpiredCerts-pki-tomcatIndex [26/May/2015:08:19:25 -0400] - ipaca: Indexing VLV: allInvalidCerts-pki-tomcatIndex [26/May/2015:08:19:26 -0400] - ipaca: Indexing VLV: allInValidCertsNotBefore-pki-tomcatIndex [26/May/2015:08:19:26 -0400] - ipaca: Indexing VLV: allNonRevokedCerts-pki-tomcatIndex [26/May/2015:08:19:26 -0400] - ipaca: Indexing VLV: allRevokedCaCerts-pki-tomcatIndex [26/May/2015:08:19:26 -0400] - ipaca: Indexing VLV: allRevokedCerts-pki-tomcatIndex [26/May/2015:08:19:26 -0400] - ipaca: Indexing VLV: allRevokedCertsNotAfter-pki-tomcatIndex [26/May/2015:08:19:26 -0400] - ipaca: Indexing VLV: allRevokedExpiredCerts-pki-tomcatIndex [26/May/2015:08:19:26 -0400] - ipaca: Indexing VLV: allRevokedOrRevokedExpiredCaCerts-pki-tomcatIndex [26/May/2015:08:19:26 -0400] - ipaca: Indexing VLV: allRevokedOrRevokedExpiredCerts-pki-tomcatIndex [26/May/2015:08:19:26 -0400] - ipaca: Indexing VLV: allValidCerts-pki-tomcatIndex [26/May/2015:08:19:26 -0400] - ipaca: Indexing VLV: allValidCertsNotAfter-pki-tomcatIndex [26/May/2015:08:19:26 -0400] - ipaca: Indexing VLV: allValidOrRevokedCerts-pki-tomcatIndex [26/May/2015:08:19:26 -0400] - ipaca: Indexing VLV: caAll-pki-tomcatIndex [26/May/2015:08:19:26 -0400] - ipaca: Indexing VLV: caCanceled-pki-tomcatIndex [26/May/2015:08:19:26 -0400] - ipaca: Indexing VLV: caCanceledEnrollment-pki-tomcatIndex [26/May/2015:08:19:26 -0400] - ipaca: Indexing VLV: caCanceledRenewal-pki-tomcatIndex [26/May/2015:08:19:26 -0400] - ipaca: Indexing VLV: caCanceledRevocation-pki-tomcatIndex [26/May/2015:08:19:26 -0400] - ipaca: Indexing VLV: caComplete-pki-tomcatIndex [26/May/2015:08:19:26 -0400] - ipaca: Indexing VLV: caCompleteEnrollment-pki-tomcatIndex [26/May/2015:08:19:26 -0400] - ipaca: Indexing VLV: caCompleteRenewal-pki-tomcatIndex [26/May/2015:08:19:26 -0400] - ipaca: Indexing VLV: caCompleteRevocation-pki-tomcatIndex [26/May/2015:08:19:26 -0400] - ipaca: Indexing VLV: caEnrollment-pki-tomcatIndex [26/May/2015:08:19:26 -0400] - ipaca: Indexing VLV: caPending-pki-tomcatIndex [26/May/2015:08:19:26 -0400] - ipaca: Indexing VLV: caPendingEnrollment-pki-tomcatIndex [26/May/2015:08:19:26 -0400] - ipaca: Indexing VLV: caPendingRenewal-pki-tomcatIndex [26/May/2015:08:19:26 -0400] - ipaca: Indexing VLV: caPendingRevocation-pki-tomcatIndex [26/May/2015:08:19:26 -0400] - ipaca: Indexing VLV: caRejected-pki-tomcatIndex [26/May/2015:08:19:26 -0400] - ipaca: Indexing VLV: caRejectedEnrollment-pki-tomcatIndex [26/May/2015:08:19:26 -0400] - ipaca: Indexing VLV: caRejectedRenewal-pki-tomcatIndex [26/May/2015:08:19:27 -0400] - ipaca: Indexing VLV: caRejectedRevocation-pki-tomcatIndex [26/May/2015:08:19:27 -0400] - ipaca: Indexing VLV: caRenewal-pki-tomcatIndex [26/May/2015:08:19:27 -0400] - ipaca: Indexing VLV: caRevocation-pki-tomcatIndex [26/May/2015:08:19:27 -0400] - warning: ancestorid not indexed on 21; possibly, the entry id 21 has no descendants yet. [26/May/2015:08:19:27 -0400] - warning: ancestorid not indexed on 21; possibly, the entry id 21 has no descendants yet. [26/May/2015:08:19:27 -0400] - warning: ancestorid not indexed on 21; possibly, the entry id 21 has no descendants yet. [26/May/2015:08:19:27 -0400] - warning: ancestorid not indexed on 21; possibly, the entry id 21 has no descendants yet. [26/May/2015:08:19:27 -0400] - warning: ancestorid not indexed on 21; possibly, the entry id 21 has no descendants yet. [26/May/2015:08:19:27 -0400] - warning: ancestorid not indexed on 21; possibly, the entry id 21 has no descendants yet. [26/May/2015:08:19:27 -0400] - warning: ancestorid not indexed on 21; possibly, the entry id 21 has no descendants yet. [26/May/2015:08:19:27 -0400] - warning: ancestorid not indexed on 21; possibly, the entry id 21 has no descendants yet. [26/May/2015:08:19:27 -0400] - warning: ancestorid not indexed on 21; possibly, the entry id 21 has no descendants yet. [26/May/2015:08:19:27 -0400] - warning: ancestorid not indexed on 21; possibly, the entry id 21 has no descendants yet. [26/May/2015:08:19:27 -0400] - warning: ancestorid not indexed on 21; possibly, the entry id 21 has no descendants yet. [26/May/2015:08:19:27 -0400] - warning: ancestorid not indexed on 21; possibly, the entry id 21 has no descendants yet. [26/May/2015:08:19:27 -0400] - warning: ancestorid not indexed on 21; possibly, the entry id 21 has no descendants yet. [26/May/2015:08:19:27 -0400] - warning: ancestorid not indexed on 21; possibly, the entry id 21 has no descendants yet. [26/May/2015:08:19:27 -0400] - warning: ancestorid not indexed on 23; possibly, the entry id 23 has no descendants yet. [26/May/2015:08:19:27 -0400] - warning: ancestorid not indexed on 23; possibly, the entry id 23 has no descendants yet. [26/May/2015:08:19:27 -0400] - warning: ancestorid not indexed on 23; possibly, the entry id 23 has no descendants yet. [26/May/2015:08:19:27 -0400] - warning: ancestorid not indexed on 23; possibly, the entry id 23 has no descendants yet. [26/May/2015:08:19:27 -0400] - warning: ancestorid not indexed on 23; possibly, the entry id 23 has no descendants yet. [26/May/2015:08:19:27 -0400] - warning: ancestorid not indexed on 23; possibly, the entry id 23 has no descendants yet. [26/May/2015:08:19:27 -0400] - warning: ancestorid not indexed on 23; possibly, the entry id 23 has no descendants yet. [26/May/2015:08:19:27 -0400] - warning: ancestorid not indexed on 23; possibly, the entry id 23 has no descendants yet. [26/May/2015:08:19:27 -0400] - warning: ancestorid not indexed on 23; possibly, the entry id 23 has no descendants yet. [26/May/2015:08:19:27 -0400] - warning: ancestorid not indexed on 23; possibly, the entry id 23 has no descendants yet. [26/May/2015:08:19:27 -0400] - warning: ancestorid not indexed on 23; possibly, the entry id 23 has no descendants yet. [26/May/2015:08:19:27 -0400] - warning: ancestorid not indexed on 23; possibly, the entry id 23 has no descendants yet. [26/May/2015:08:19:27 -0400] - warning: ancestorid not indexed on 23; possibly, the entry id 23 has no descendants yet. [26/May/2015:08:19:28 -0400] - warning: ancestorid not indexed on 23; possibly, the entry id 23 has no descendants yet. [26/May/2015:08:19:28 -0400] - warning: ancestorid not indexed on 23; possibly, the entry id 23 has no descendants yet. [26/May/2015:08:19:28 -0400] - warning: ancestorid not indexed on 23; possibly, the entry id 23 has no descendants yet. [26/May/2015:08:19:28 -0400] - warning: ancestorid not indexed on 23; possibly, the entry id 23 has no descendants yet. [26/May/2015:08:19:28 -0400] - warning: ancestorid not indexed on 23; possibly, the entry id 23 has no descendants yet. [26/May/2015:08:19:28 -0400] - warning: ancestorid not indexed on 23; possibly, the entry id 23 has no descendants yet. [26/May/2015:08:19:28 -0400] - warning: ancestorid not indexed on 23; possibly, the entry id 23 has no descendants yet. [26/May/2015:08:19:28 -0400] - ipaca: Finished indexing. [26/May/2015:08:20:20 -0400] - Warning: Adding configuration attribute "nsslapd-security" [26/May/2015:08:20:21 -0400] - slapd shutting down - signaling operation threads - op stack size 2 max work q size 2 max work q stack size 2 [26/May/2015:08:20:21 -0400] - slapd shutting down - waiting for 1 thread to terminate [26/May/2015:08:20:21 -0400] - slapd shutting down - closing down internal subsystems and plugins [26/May/2015:08:20:22 -0400] - Waiting for 4 database threads to stop [26/May/2015:08:20:22 -0400] - All database threads now stopped [26/May/2015:08:20:22 -0400] - slapd shutting down - freed 2 work q stack objects - freed 3 op stack objects [26/May/2015:08:20:22 -0400] - slapd stopped. [26/May/2015:08:20:23 -0400] SSL Initialization - Configured SSL version range: min: TLS1.0, max: TLS1.2 [26/May/2015:08:20:23 -0400] - SSL alert: Configured NSS Ciphers [26/May/2015:08:20:23 -0400] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled [26/May/2015:08:20:23 -0400] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled [26/May/2015:08:20:23 -0400] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled [26/May/2015:08:20:23 -0400] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled [26/May/2015:08:20:23 -0400] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled [26/May/2015:08:20:23 -0400] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: enabled [26/May/2015:08:20:23 -0400] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled [26/May/2015:08:20:23 -0400] - SSL alert: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled [26/May/2015:08:20:23 -0400] - SSL alert: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled [26/May/2015:08:20:23 -0400] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled [26/May/2015:08:20:23 -0400] - SSL alert: TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled [26/May/2015:08:20:23 -0400] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled [26/May/2015:08:20:23 -0400] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled [26/May/2015:08:20:24 -0400] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: enabled [26/May/2015:08:20:24 -0400] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled [26/May/2015:08:20:24 -0400] - SSL alert: TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled [26/May/2015:08:20:24 -0400] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled [26/May/2015:08:20:24 -0400] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled [26/May/2015:08:20:24 -0400] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: enabled [26/May/2015:08:20:24 -0400] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled [26/May/2015:08:20:24 -0400] - SSL alert: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled [26/May/2015:08:20:24 -0400] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled [26/May/2015:08:20:24 -0400] - SSL alert: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled [26/May/2015:08:20:24 -0400] - SSL alert: TLS_RSA_WITH_AES_128_GCM_SHA256: enabled [26/May/2015:08:20:24 -0400] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA: enabled [26/May/2015:08:20:24 -0400] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA256: enabled [26/May/2015:08:20:24 -0400] - SSL alert: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled [26/May/2015:08:20:25 -0400] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA: enabled [26/May/2015:08:20:25 -0400] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA256: enabled [26/May/2015:08:20:25 -0400] - SSL alert: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled [26/May/2015:08:20:25 -0400] - SSL alert: TLS_RSA_WITH_SEED_CBC_SHA: enabled [26/May/2015:08:20:25 -0400] - 389-Directory/1.3.4.a1 B2015.070.423 starting up [26/May/2015:08:20:25 -0400] - resizing db cache size: 3276800 -> 2621440 [26/May/2015:08:20:25 -0400] attrcrypt - No symmetric key found for cipher AES in backend userRoot, attempting to create one... [26/May/2015:08:20:26 -0400] attrcrypt - Key for cipher AES successfully generated and stored [26/May/2015:08:20:26 -0400] attrcrypt - No symmetric key found for cipher 3DES in backend userRoot, attempting to create one... [26/May/2015:08:20:26 -0400] attrcrypt - Key for cipher 3DES successfully generated and stored [26/May/2015:08:20:26 -0400] attrcrypt - No symmetric key found for cipher AES in backend ipaca, attempting to create one... [26/May/2015:08:20:26 -0400] attrcrypt - Key for cipher AES successfully generated and stored [26/May/2015:08:20:27 -0400] attrcrypt - No symmetric key found for cipher 3DES in backend ipaca, attempting to create one... [26/May/2015:08:20:27 -0400] attrcrypt - Key for cipher 3DES successfully generated and stored [26/May/2015:08:20:27 -0400] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=pesen,dc=net [26/May/2015:08:20:27 -0400] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=pesen,dc=net [26/May/2015:08:20:27 -0400] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=pesen,dc=net [26/May/2015:08:20:27 -0400] NSACLPlugin - The ACL target cn=retrieve certificate,cn=virtual operations,cn=etc,dc=pesen,dc=net does not exist [26/May/2015:08:20:27 -0400] NSACLPlugin - The ACL target cn=request certificate,cn=virtual operations,cn=etc,dc=pesen,dc=net does not exist [26/May/2015:08:20:27 -0400] NSACLPlugin - The ACL target cn=request certificate different host,cn=virtual operations,cn=etc,dc=pesen,dc=net does not exist [26/May/2015:08:20:27 -0400] NSACLPlugin - The ACL target cn=certificate status,cn=virtual operations,cn=etc,dc=pesen,dc=net does not exist [26/May/2015:08:20:27 -0400] NSACLPlugin - The ACL target cn=revoke certificate,cn=virtual operations,cn=etc,dc=pesen,dc=net does not exist [26/May/2015:08:20:27 -0400] NSACLPlugin - The ACL target cn=certificate remove hold,cn=virtual operations,cn=etc,dc=pesen,dc=net does not exist [26/May/2015:08:20:27 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=pesen,dc=net--no CoS Templates found, which should be added before the CoS Definition. [26/May/2015:08:20:27 -0400] ipalockout_get_global_config - [file ipa_lockout.c, line 185]: Failed to get default realm (-1765328160) [26/May/2015:08:20:28 -0400] ipaenrollment_start - [file ipa_enrollment.c, line 393]: Failed to get default realm?! [26/May/2015:08:20:28 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=pesen,dc=net--no CoS Templates found, which should be added before the CoS Definition. [26/May/2015:08:20:28 -0400] - slapd started. Listening on All Interfaces port 389 for LDAP requests [26/May/2015:08:20:28 -0400] - Listening on All Interfaces port 636 for LDAPS requests [26/May/2015:08:20:28 -0400] - Listening on /var/run/slapd-PESEN-NET.socket for LDAPI requests [26/May/2015:08:21:02 -0400] - slapd shutting down - signaling operation threads - op stack size 3 max work q size 2 max work q stack size 2 [26/May/2015:08:21:02 -0400] - slapd shutting down - waiting for 3 threads to terminate [26/May/2015:08:21:02 -0400] - slapd shutting down - closing down internal subsystems and plugins [26/May/2015:08:21:02 -0400] - Waiting for 4 database threads to stop [26/May/2015:08:21:05 -0400] - All database threads now stopped [26/May/2015:08:21:05 -0400] - slapd shutting down - freed 2 work q stack objects - freed 4 op stack objects [26/May/2015:08:21:05 -0400] - slapd stopped. [26/May/2015:08:21:07 -0400] - Information: Non-Secure Port Disabled [26/May/2015:08:21:07 -0400] - 389-Directory/1.3.4.a1 B2015.070.423 starting up [26/May/2015:08:21:07 -0400] - resizing db cache size: 2621440 -> 2097152 [26/May/2015:08:21:07 -0400] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=pesen,dc=net [26/May/2015:08:21:08 -0400] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=pesen,dc=net [26/May/2015:08:21:08 -0400] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=pesen,dc=net [26/May/2015:08:21:08 -0400] NSACLPlugin - The ACL target cn=retrieve certificate,cn=virtual operations,cn=etc,dc=pesen,dc=net does not exist [26/May/2015:08:21:08 -0400] NSACLPlugin - The ACL target cn=request certificate,cn=virtual operations,cn=etc,dc=pesen,dc=net does not exist [26/May/2015:08:21:08 -0400] NSACLPlugin - The ACL target cn=request certificate different host,cn=virtual operations,cn=etc,dc=pesen,dc=net does not exist [26/May/2015:08:21:08 -0400] NSACLPlugin - The ACL target cn=certificate status,cn=virtual operations,cn=etc,dc=pesen,dc=net does not exist [26/May/2015:08:21:08 -0400] NSACLPlugin - The ACL target cn=revoke certificate,cn=virtual operations,cn=etc,dc=pesen,dc=net does not exist [26/May/2015:08:21:08 -0400] NSACLPlugin - The ACL target cn=certificate remove hold,cn=virtual operations,cn=etc,dc=pesen,dc=net does not exist [26/May/2015:08:21:08 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=pesen,dc=net--no CoS Templates found, which should be added before the CoS Definition. [26/May/2015:08:21:09 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=pesen,dc=net--no CoS Templates found, which should be added before the CoS Definition. [26/May/2015:08:21:09 -0400] - slapd started. Listening on /var/run/slapd-PESEN-NET.socket for LDAPI requests [26/May/2015:08:21:11 -0400] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=pesen,dc=net [26/May/2015:08:21:11 -0400] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=pesen,dc=net [26/May/2015:08:21:11 -0400] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=pesen,dc=net [26/May/2015:08:21:11 -0400] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=pesen,dc=net [26/May/2015:08:21:17 -0400] - userRoot: Indexing attribute: memberuid [26/May/2015:08:21:18 -0400] - userRoot: Finished indexing. [26/May/2015:08:21:23 -0400] - userRoot: Indexing attribute: member [26/May/2015:08:21:24 -0400] - userRoot: Finished indexing. [26/May/2015:08:21:30 -0400] - userRoot: Indexing attribute: uniquemember [26/May/2015:08:21:31 -0400] - userRoot: Finished indexing. [26/May/2015:08:21:36 -0400] - userRoot: Indexing attribute: owner [26/May/2015:08:21:37 -0400] - userRoot: Finished indexing. [26/May/2015:08:21:42 -0400] - userRoot: Indexing attribute: seeAlso [26/May/2015:08:21:43 -0400] - userRoot: Finished indexing. [26/May/2015:08:21:49 -0400] - userRoot: Indexing attribute: ipatokenradiusconfiglink [26/May/2015:08:21:49 -0400] - userRoot: Finished indexing. [26/May/2015:08:21:55 -0400] - userRoot: Indexing attribute: ipaassignedidview [26/May/2015:08:21:55 -0400] - userRoot: Finished indexing. [26/May/2015:08:22:01 -0400] - userRoot: Indexing attribute: ntUniqueId [26/May/2015:08:22:02 -0400] - userRoot: Finished indexing. [26/May/2015:08:22:07 -0400] - userRoot: Indexing attribute: ntUserDomainId [26/May/2015:08:22:08 -0400] - userRoot: Finished indexing. [26/May/2015:08:22:09 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=pesen,dc=net--no CoS Templates found, which should be added before the CoS Definition. [26/May/2015:08:22:09 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=pesen,dc=net--no CoS Templates found, which should be added before the CoS Definition. [26/May/2015:08:22:17 -0400] memberof-plugin - Memberof task starts (arg: (objectclass=*)) ... [26/May/2015:08:22:17 -0400] memberof-plugin - Memberof task starts (arg: (objectclass=*)) ... [26/May/2015:08:22:18 -0400] memberof-plugin - Memberof task finished (arg: (objectclass=*)) ... [26/May/2015:08:22:18 -0400] memberof-plugin - Memberof task finished (arg: (objectclass=*)) ... [26/May/2015:08:22:22 -0400] NSACLPlugin - The ACL target cn=dns,dc=pesen,dc=net does not exist [26/May/2015:08:22:22 -0400] NSACLPlugin - The ACL target cn=dns,dc=pesen,dc=net does not exist [26/May/2015:08:22:23 -0400] NSACLPlugin - The ACL target cn=keys,cn=sec,cn=dns,dc=pesen,dc=net does not exist [26/May/2015:08:22:23 -0400] NSACLPlugin - The ACL target cn=dns,dc=pesen,dc=net does not exist [26/May/2015:08:22:23 -0400] NSACLPlugin - The ACL target cn=dns,dc=pesen,dc=net does not exist [26/May/2015:08:22:51 -0400] NSACLPlugin - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=pesen,dc=net does not exist [26/May/2015:08:22:51 -0400] NSACLPlugin - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=pesen,dc=net does not exist [26/May/2015:08:22:51 -0400] NSACLPlugin - The ACL target cn=ad,cn=etc,dc=pesen,dc=net does not exist [26/May/2015:08:22:53 -0400] - slapd shutting down - signaling operation threads - op stack size 3 max work q size 1 max work q stack size 1 [26/May/2015:08:22:53 -0400] - slapd shutting down - waiting for 1 thread to terminate [26/May/2015:08:22:53 -0400] - slapd shutting down - closing down internal subsystems and plugins [26/May/2015:08:22:53 -0400] - Waiting for 4 database threads to stop [26/May/2015:08:22:54 -0400] - All database threads now stopped [26/May/2015:08:22:54 -0400] - slapd shutting down - freed 1 work q stack objects - freed 3 op stack objects [26/May/2015:08:22:54 -0400] - slapd stopped. [26/May/2015:08:22:55 -0400] SSL Initialization - Configured SSL version range: min: TLS1.0, max: TLS1.2 [26/May/2015:08:22:55 -0400] - SSL alert: Configured NSS Ciphers [26/May/2015:08:22:55 -0400] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled [26/May/2015:08:22:55 -0400] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled [26/May/2015:08:22:55 -0400] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled [26/May/2015:08:22:55 -0400] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled [26/May/2015:08:22:55 -0400] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled [26/May/2015:08:22:55 -0400] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: enabled [26/May/2015:08:22:55 -0400] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled [26/May/2015:08:22:55 -0400] - SSL alert: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled [26/May/2015:08:22:55 -0400] - SSL alert: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled [26/May/2015:08:22:55 -0400] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled [26/May/2015:08:22:55 -0400] - SSL alert: TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled [26/May/2015:08:22:56 -0400] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled [26/May/2015:08:22:56 -0400] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled [26/May/2015:08:22:56 -0400] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: enabled [26/May/2015:08:22:56 -0400] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled [26/May/2015:08:22:56 -0400] - SSL alert: TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled [26/May/2015:08:22:56 -0400] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled [26/May/2015:08:22:56 -0400] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled [26/May/2015:08:22:56 -0400] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: enabled [26/May/2015:08:22:56 -0400] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled [26/May/2015:08:22:56 -0400] - SSL alert: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled [26/May/2015:08:22:56 -0400] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled [26/May/2015:08:22:56 -0400] - SSL alert: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled [26/May/2015:08:22:56 -0400] - SSL alert: TLS_RSA_WITH_AES_128_GCM_SHA256: enabled [26/May/2015:08:22:56 -0400] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA: enabled [26/May/2015:08:22:56 -0400] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA256: enabled [26/May/2015:08:22:56 -0400] - SSL alert: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled [26/May/2015:08:22:56 -0400] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA: enabled [26/May/2015:08:22:56 -0400] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA256: enabled [26/May/2015:08:22:56 -0400] - SSL alert: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled [26/May/2015:08:22:56 -0400] - SSL alert: TLS_RSA_WITH_SEED_CBC_SHA: enabled [26/May/2015:08:22:56 -0400] - 389-Directory/1.3.4.a1 B2015.070.423 starting up [26/May/2015:08:22:56 -0400] - resizing db cache size: 2097152 -> 1677721 [26/May/2015:08:22:56 -0400] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=pesen,dc=net [26/May/2015:08:22:57 -0400] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=pesen,dc=net [26/May/2015:08:22:57 -0400] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=pesen,dc=net [26/May/2015:08:22:57 -0400] NSACLPlugin - The ACL target cn=dns,dc=pesen,dc=net does not exist [26/May/2015:08:22:57 -0400] NSACLPlugin - The ACL target cn=dns,dc=pesen,dc=net does not exist [26/May/2015:08:22:57 -0400] NSACLPlugin - The ACL target cn=keys,cn=sec,cn=dns,dc=pesen,dc=net does not exist [26/May/2015:08:22:57 -0400] NSACLPlugin - The ACL target cn=dns,dc=pesen,dc=net does not exist [26/May/2015:08:22:57 -0400] NSACLPlugin - The ACL target cn=dns,dc=pesen,dc=net does not exist [26/May/2015:08:22:57 -0400] NSACLPlugin - The ACL target cn=groups,cn=compat,dc=pesen,dc=net does not exist [26/May/2015:08:22:57 -0400] NSACLPlugin - The ACL target cn=computers,cn=compat,dc=pesen,dc=net does not exist [26/May/2015:08:22:57 -0400] NSACLPlugin - The ACL target cn=ng,cn=compat,dc=pesen,dc=net does not exist [26/May/2015:08:22:57 -0400] NSACLPlugin - The ACL target ou=sudoers,dc=pesen,dc=net does not exist [26/May/2015:08:22:57 -0400] NSACLPlugin - The ACL target cn=users,cn=compat,dc=pesen,dc=net does not exist [26/May/2015:08:22:57 -0400] NSACLPlugin - The ACL target cn=ad,cn=etc,dc=pesen,dc=net does not exist [26/May/2015:08:22:57 -0400] NSACLPlugin - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=pesen,dc=net does not exist [26/May/2015:08:22:57 -0400] NSACLPlugin - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=pesen,dc=net does not exist [26/May/2015:08:22:57 -0400] NSACLPlugin - The ACL target cn=automember rebuild membership,cn=tasks,cn=config does not exist [26/May/2015:08:22:57 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=pesen,dc=net--no CoS Templates found, which should be added before the CoS Definition. [26/May/2015:08:22:57 -0400] attrcrypt - No symmetric key found for cipher AES in backend changelog, attempting to create one... [26/May/2015:08:22:57 -0400] attrcrypt - Key for cipher AES successfully generated and stored [26/May/2015:08:22:57 -0400] attrcrypt - No symmetric key found for cipher 3DES in backend changelog, attempting to create one... [26/May/2015:08:22:58 -0400] attrcrypt - Key for cipher 3DES successfully generated and stored [26/May/2015:08:22:59 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=pesen,dc=net--no CoS Templates found, which should be added before the CoS Definition. [26/May/2015:08:22:59 -0400] - slapd started. Listening on All Interfaces port 389 for LDAP requests [26/May/2015:08:22:59 -0400] - Listening on All Interfaces port 636 for LDAPS requests [26/May/2015:08:22:59 -0400] - Listening on /var/run/slapd-PESEN-NET.socket for LDAPI requests [26/May/2015:08:22:59 -0400] - slapd shutting down - signaling operation threads - op stack size 1 max work q size 1 max work q stack size 1 [26/May/2015:08:22:59 -0400] - slapd shutting down - closing down internal subsystems and plugins [26/May/2015:08:22:59 -0400] - Waiting for 4 database threads to stop [26/May/2015:08:23:00 -0400] - All database threads now stopped [26/May/2015:08:23:00 -0400] - slapd shutting down - freed 1 work q stack objects - freed 1 op stack objects [26/May/2015:08:23:00 -0400] - slapd stopped. [26/May/2015:08:23:01 -0400] SSL Initialization - Configured SSL version range: min: TLS1.0, max: TLS1.2 [26/May/2015:08:23:01 -0400] - SSL alert: Configured NSS Ciphers [26/May/2015:08:23:01 -0400] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled [26/May/2015:08:23:01 -0400] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled [26/May/2015:08:23:01 -0400] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled [26/May/2015:08:23:01 -0400] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled [26/May/2015:08:23:01 -0400] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled [26/May/2015:08:23:01 -0400] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: enabled [26/May/2015:08:23:01 -0400] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled [26/May/2015:08:23:01 -0400] - SSL alert: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled [26/May/2015:08:23:01 -0400] - SSL alert: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled [26/May/2015:08:23:01 -0400] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled [26/May/2015:08:23:01 -0400] - SSL alert: TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled [26/May/2015:08:23:02 -0400] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled [26/May/2015:08:23:02 -0400] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled [26/May/2015:08:23:02 -0400] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: enabled [26/May/2015:08:23:02 -0400] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled [26/May/2015:08:23:02 -0400] - SSL alert: TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled [26/May/2015:08:23:02 -0400] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled [26/May/2015:08:23:02 -0400] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled [26/May/2015:08:23:02 -0400] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: enabled [26/May/2015:08:23:02 -0400] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled [26/May/2015:08:23:02 -0400] - SSL alert: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled [26/May/2015:08:23:02 -0400] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled [26/May/2015:08:23:02 -0400] - SSL alert: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled [26/May/2015:08:23:02 -0400] - SSL alert: TLS_RSA_WITH_AES_128_GCM_SHA256: enabled [26/May/2015:08:23:02 -0400] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA: enabled [26/May/2015:08:23:02 -0400] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA256: enabled [26/May/2015:08:23:02 -0400] - SSL alert: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled [26/May/2015:08:23:02 -0400] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA: enabled [26/May/2015:08:23:02 -0400] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA256: enabled [26/May/2015:08:23:02 -0400] - SSL alert: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled [26/May/2015:08:23:02 -0400] - SSL alert: TLS_RSA_WITH_SEED_CBC_SHA: enabled [26/May/2015:08:23:02 -0400] - 389-Directory/1.3.4.a1 B2015.070.423 starting up [26/May/2015:08:23:02 -0400] - resizing db cache size: 1677721 -> 1342176 [26/May/2015:08:23:03 -0400] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=pesen,dc=net [26/May/2015:08:23:03 -0400] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=pesen,dc=net [26/May/2015:08:23:03 -0400] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=pesen,dc=net [26/May/2015:08:23:03 -0400] NSACLPlugin - The ACL target cn=dns,dc=pesen,dc=net does not exist [26/May/2015:08:23:03 -0400] NSACLPlugin - The ACL target cn=dns,dc=pesen,dc=net does not exist [26/May/2015:08:23:03 -0400] NSACLPlugin - The ACL target cn=keys,cn=sec,cn=dns,dc=pesen,dc=net does not exist [26/May/2015:08:23:03 -0400] NSACLPlugin - The ACL target cn=dns,dc=pesen,dc=net does not exist [26/May/2015:08:23:03 -0400] NSACLPlugin - The ACL target cn=dns,dc=pesen,dc=net does not exist [26/May/2015:08:23:03 -0400] NSACLPlugin - The ACL target cn=groups,cn=compat,dc=pesen,dc=net does not exist [26/May/2015:08:23:03 -0400] NSACLPlugin - The ACL target cn=computers,cn=compat,dc=pesen,dc=net does not exist [26/May/2015:08:23:03 -0400] NSACLPlugin - The ACL target cn=ng,cn=compat,dc=pesen,dc=net does not exist [26/May/2015:08:23:03 -0400] NSACLPlugin - The ACL target ou=sudoers,dc=pesen,dc=net does not exist [26/May/2015:08:23:03 -0400] NSACLPlugin - The ACL target cn=users,cn=compat,dc=pesen,dc=net does not exist [26/May/2015:08:23:03 -0400] NSACLPlugin - The ACL target cn=ad,cn=etc,dc=pesen,dc=net does not exist [26/May/2015:08:23:03 -0400] NSACLPlugin - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=pesen,dc=net does not exist [26/May/2015:08:23:03 -0400] NSACLPlugin - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=pesen,dc=net does not exist [26/May/2015:08:23:03 -0400] NSACLPlugin - The ACL target cn=automember rebuild membership,cn=tasks,cn=config does not exist [26/May/2015:08:23:03 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=pesen,dc=net--no CoS Templates found, which should be added before the CoS Definition. [26/May/2015:08:23:04 -0400] - slapd started. Listening on All Interfaces port 389 for LDAP requests [26/May/2015:08:23:04 -0400] - Listening on All Interfaces port 636 for LDAPS requests [26/May/2015:08:23:04 -0400] - Listening on /var/run/slapd-PESEN-NET.socket for LDAPI requests [26/May/2015:08:23:19 -0400] memberof-plugin - Memberof task starts (arg: (objectclass=*)) ... [26/May/2015:08:23:21 -0400] memberof-plugin - Memberof task finished (arg: (objectclass=*)) ... [26/May/2015:08:29:55 -0400] - slapd shutting down - signaling operation threads - op stack size 5 max work q size 2 max work q stack size 2 [26/May/2015:08:29:55 -0400] - slapd shutting down - waiting for 1 thread to terminate [26/May/2015:08:29:55 -0400] - slapd shutting down - closing down internal subsystems and plugins [26/May/2015:08:29:55 -0400] - Waiting for 4 database threads to stop [26/May/2015:08:29:55 -0400] - All database threads now stopped [26/May/2015:08:29:56 -0400] - slapd shutting down - freed 2 work q stack objects - freed 6 op stack objects [26/May/2015:08:29:56 -0400] - slapd stopped. [26/May/2015:08:29:57 -0400] SSL Initialization - Configured SSL version range: min: TLS1.0, max: TLS1.2 [26/May/2015:08:29:57 -0400] - SSL alert: Configured NSS Ciphers [26/May/2015:08:29:57 -0400] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled [26/May/2015:08:29:57 -0400] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled [26/May/2015:08:29:58 -0400] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled [26/May/2015:08:29:58 -0400] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled [26/May/2015:08:29:58 -0400] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled [26/May/2015:08:29:58 -0400] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: enabled [26/May/2015:08:29:58 -0400] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled [26/May/2015:08:29:58 -0400] - SSL alert: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled [26/May/2015:08:29:58 -0400] - SSL alert: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled [26/May/2015:08:29:58 -0400] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled [26/May/2015:08:29:58 -0400] - SSL alert: TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled [26/May/2015:08:29:58 -0400] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled [26/May/2015:08:29:58 -0400] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled [26/May/2015:08:29:58 -0400] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: enabled [26/May/2015:08:29:58 -0400] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled [26/May/2015:08:29:58 -0400] - SSL alert: TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled [26/May/2015:08:29:58 -0400] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled [26/May/2015:08:29:58 -0400] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled [26/May/2015:08:29:58 -0400] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: enabled [26/May/2015:08:29:58 -0400] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled [26/May/2015:08:29:58 -0400] - SSL alert: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled [26/May/2015:08:29:58 -0400] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled [26/May/2015:08:29:58 -0400] - SSL alert: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled [26/May/2015:08:29:58 -0400] - SSL alert: TLS_RSA_WITH_AES_128_GCM_SHA256: enabled [26/May/2015:08:29:58 -0400] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA: enabled [26/May/2015:08:29:58 -0400] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA256: enabled [26/May/2015:08:29:58 -0400] - SSL alert: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled [26/May/2015:08:29:58 -0400] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA: enabled [26/May/2015:08:29:58 -0400] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA256: enabled [26/May/2015:08:29:58 -0400] - SSL alert: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled [26/May/2015:08:29:58 -0400] - SSL alert: TLS_RSA_WITH_SEED_CBC_SHA: enabled [26/May/2015:08:29:58 -0400] - 389-Directory/1.3.4.a1 B2015.070.423 starting up [26/May/2015:08:29:58 -0400] - resizing db cache size: 1342176 -> 1073740 [26/May/2015:08:29:59 -0400] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=pesen,dc=net [26/May/2015:08:29:59 -0400] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=pesen,dc=net [26/May/2015:08:29:59 -0400] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=pesen,dc=net [26/May/2015:08:29:59 -0400] NSACLPlugin - The ACL target cn=groups,cn=compat,dc=pesen,dc=net does not exist [26/May/2015:08:29:59 -0400] NSACLPlugin - The ACL target cn=computers,cn=compat,dc=pesen,dc=net does not exist [26/May/2015:08:29:59 -0400] NSACLPlugin - The ACL target cn=ng,cn=compat,dc=pesen,dc=net does not exist [26/May/2015:08:29:59 -0400] NSACLPlugin - The ACL target ou=sudoers,dc=pesen,dc=net does not exist [26/May/2015:08:29:59 -0400] NSACLPlugin - The ACL target cn=users,cn=compat,dc=pesen,dc=net does not exist [26/May/2015:08:29:59 -0400] NSACLPlugin - The ACL target cn=ad,cn=etc,dc=pesen,dc=net does not exist [26/May/2015:08:29:59 -0400] NSACLPlugin - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=pesen,dc=net does not exist [26/May/2015:08:29:59 -0400] NSACLPlugin - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=pesen,dc=net does not exist [26/May/2015:08:29:59 -0400] NSACLPlugin - The ACL target cn=automember rebuild membership,cn=tasks,cn=config does not exist [26/May/2015:08:30:00 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=pesen,dc=net--no CoS Templates found, which should be added before the CoS Definition. [26/May/2015:08:30:00 -0400] - slapd started. Listening on All Interfaces port 389 for LDAP requests [26/May/2015:08:30:00 -0400] - Listening on All Interfaces port 636 for LDAPS requests [26/May/2015:08:30:00 -0400] - Listening on /var/run/slapd-PESEN-NET.socket for LDAPI requests [26/May/2015:08:30:01 -0400] - Entry "uid=admin,ou=people,o=ipaca" -- attribute "krbExtraData" not allowed [26/May/2015:08:46:02 -0400] NSMMReplicationPlugin - agmt="cn=meToreplica1.pesen.net" (replica1:389): The remote replica has a different database generation ID than the local database. You may have to reinitialize the remote replica, or the local replica. [26/May/2015:08:46:03 -0400] NSMMReplicationPlugin - Beginning total update of replica "agmt="cn=meToreplica1.pesen.net" (replica1:389)". [26/May/2015:08:46:09 -0400] NSMMReplicationPlugin - Finished total update of replica "agmt="cn=meToreplica1.pesen.net" (replica1:389)". Sent 382 entries. [26/May/2015:08:46:11 -0400] ipa-topology-plugin - ipa_topo_util_modify: failed to modify entry (cn=meToreplica1.pesen.net,cn=replica,cn=dc\3Dpesen\2Cdc\3Dnet,cn=mapping tree,cn=config): error 53 [26/May/2015:08:46:17 -0400] repl_version_plugin_recv_acquire_cb - [file ipa_repl_version.c, line 119]: Incompatible IPA versions, pausing replication. This server: "20100614120000" remote server: "(null)". [26/May/2015:08:46:38 -0400] NSMMReplicationPlugin - agmt="cn=meToreplica1.pesen.net" (replica1:389): Unable to receive the response for a startReplication extended operation to consumer (Can't contact LDAP server). Will retry later. [26/May/2015:08:46:41 -0400] NSMMReplicationPlugin - agmt="cn=meToreplica1.pesen.net" (replica1:389): Replication bind with SIMPLE auth resumed [26/May/2015:08:47:42 -0400] NSMMReplicationPlugin - Beginning total update of replica "agmt="cn=masterAgreement1-replica1.pesen.net-pki-tomcat" (replica1:389)". [26/May/2015:08:47:46 -0400] NSMMReplicationPlugin - Finished total update of replica "agmt="cn=masterAgreement1-replica1.pesen.net-pki-tomcat" (replica1:389)". Sent 70 entries. [26/May/2015:08:48:28 -0400] repl_version_plugin_recv_acquire_cb - [file ipa_repl_version.c, line 119]: Incompatible IPA versions, pausing replication. This server: "20100614120000" remote server: "(null)". [26/May/2015:08:48:28 -0400] repl_version_plugin_recv_acquire_cb - [file ipa_repl_version.c, line 119]: Incompatible IPA versions, pausing replication. This server: "20100614120000" remote server: "(null)". [26/May/2015:09:06:42 -0400] NSMMReplicationPlugin - agmt_delete: begin [26/May/2015:09:06:43 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Initiating CleanAllRUV Task... [26/May/2015:09:06:43 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Retrieving maxcsn... [26/May/2015:09:06:43 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Found maxcsn (55646baa000000030000) [26/May/2015:09:06:43 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Cleaning rid (3)... [26/May/2015:09:06:43 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Waiting to process all the updates from the deleted replica... [26/May/2015:09:06:43 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Waiting for all the replicas to be online... [26/May/2015:09:06:43 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Waiting for all the replicas to receive all the deleted replica updates... [26/May/2015:09:06:43 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Sending cleanAllRUV task to all the replicas... [26/May/2015:09:06:43 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Cleaning local ruv's... [26/May/2015:09:06:43 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Waiting for all the replicas to be cleaned... [26/May/2015:09:06:45 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Waiting for all the replicas to finish cleaning... [26/May/2015:09:06:45 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Successfully cleaned rid(3). -------------- next part -------------- A non-text attachment was scrubbed... Name: ipareplica-install.log Type: text/x-log Size: 295485 bytes Desc: not available URL: -------------- next part -------------- $ ipa-replica-install --setup-ca --setup-dns --no-forwarders /var/lib/ipa/replica-info-replica1.pesen.net.gpg Directory Manager (existing master) password: Existing BIND configuration detected, overwrite? [no]: yes Adding [192.168.122.233 replica1.pesen.net] to your /etc/hosts file Using reverse zone(s) 122.168.192.in-addr.arpa. Run connection check to master Check connection from replica to remote master 'mymaster.pesen.net': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos Kpasswd: TCP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK The following list of ports use UDP protocol and would need to be checked manually: Kerberos KDC: UDP (88): SKIPPED Kerberos Kpasswd: UDP (464): SKIPPED Connection from replica to master is OK. Start listening on required ports for remote master check Get credentials to log in to remote master admin at PESEN.NET password: Check SSH connection to remote master Execute check on remote master Check connection from master to remote replica 'replica1.pesen.net': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos KDC: UDP (88): OK Kerberos Kpasswd: TCP (464): OK Kerberos Kpasswd: UDP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK Connection from master to replica is OK. Connection check OK Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd Done configuring NTP daemon (ntpd). Configuring directory server (dirsrv): Estimated time 1 minute [1/37]: creating directory server user [2/37]: creating directory server instance ipa : CRITICAL Failed to restart the directory server ([Errno 2] No such file or directory). See the installation log for details. [3/37]: adding default schema [4/37]: enabling memberof plugin [5/37]: enabling winsync plugin [6/37]: configuring replication version plugin [7/37]: enabling IPA enrollment plugin [8/37]: enabling ldapi [9/37]: configuring uniqueness plugin [10/37]: configuring uuid plugin [11/37]: configuring modrdn plugin [12/37]: configuring DNS plugin [13/37]: enabling entryUSN plugin [14/37]: configuring lockout plugin [15/37]: configuring topology plugin [16/37]: creating indices [17/37]: enabling referential integrity plugin [18/37]: configuring ssl for ds instance [19/37]: configuring certmap.conf [20/37]: configure autobind for root [21/37]: configure new location for managed entries [22/37]: configure dirsrv ccache [23/37]: enable SASL mapping fallback [24/37]: restarting directory server [25/37]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 6 seconds elapsed Update succeeded [26/37]: updating schema [27/37]: setting Auto Member configuration [28/37]: enabling S4U2Proxy delegation [29/37]: importing CA certificates from LDAP [30/37]: initializing group membership [31/37]: adding master entry [32/37]: initializing domain level ipa : CRITICAL Failed to load domainlevel.ldif: Command ''/usr/bin/ldapmodify' '-v' '-f' '/tmp/tmplQ0cnE' '-H' 'ldap://replica1.pesen.net:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpsdHRHh'' returned non-zero exit status 68 [33/37]: configuring Posix uid/gid generation [34/37]: adding replication acis [35/37]: enabling compatibility plugin [36/37]: tuning directory server [37/37]: configuring directory to start on boot Done configuring directory server (dirsrv). Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/21]: creating certificate server user [2/21]: configuring certificate server instance [3/21]: stopping certificate server instance to update CS.cfg [4/21]: backing up CS.cfg [5/21]: disabling nonces [6/21]: set up CRL publishing [7/21]: enable PKIX certificate path discovery and validation [8/21]: starting certificate server instance [9/21]: creating RA agent certificate database [10/21]: importing CA chain to RA certificate database [11/21]: fixing RA database permissions [12/21]: setting up signing cert profile [13/21]: set certificate subject base [14/21]: enabling Subject Key Identifier [15/21]: enabling Subject Alternative Name [16/21]: enabling CRL and OCSP extensions for certificates [17/21]: setting audit signing renewal to 2 years [18/21]: configure certmonger for renewals [19/21]: configure certificate renewals [20/21]: configure Server-Cert certificate renewal [21/21]: Configure HTTP to proxy connections Done configuring certificate server (pki-tomcatd). Restarting the directory and certificate servers Configuring Kerberos KDC (krb5kdc): Estimated time 30 seconds [1/8]: adding sasl mappings to the directory [2/8]: configuring KDC [3/8]: creating a keytab for the directory [4/8]: creating a keytab for the machine [5/8]: adding the password extension to the directory [6/8]: enable GSSAPI for replication [error] RuntimeError: One of the ldap service principals is missing. Replication agreement cannot be converted. Replication error message: Unable to acquire replicaLDAP error: Local error Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. One of the ldap service principals is missing. Replication agreement cannot be converted. Replication error message: Unable to acquire replicaLDAP error: Local error From npmccallum at redhat.com Tue May 26 13:57:56 2015 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 26 May 2015 09:57:56 -0400 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <555F03DB.3090702@redhat.com> References: <555F03DB.3090702@redhat.com> Message-ID: <1432648676.3354.6.camel@redhat.com> On Fri, 2015-05-22 at 12:24 +0200, Christian Heimes wrote: > Here is what I have so far: > > 1) The FreeIPA webui already depends on Apache and mod_wsgi. KDC > proxy > will run from the same Apache HTTPD instance but it will use a > different > mod_wsgi daemon configuration. A second WSGI daemon is easily > configured > and allows us to tune the daemon for KDC proxy's needs. FreeIPA is > mounted at /ipa, KDC Proxy will be available at /KdcProxy or /kdc. /KdcProxy "The URI uses the virtual directory /KdcProxy unless otherwise configured." https://msdn.microsoft.com/en-us/library/hh553891.aspx Also, the proxy should be available over both HTTP and HTTPS. > 3) An administrator must be able to enable/disable the new feature. > The > state of the switch will be read when Apache is started or reloaded. > The > feature must be configurable for each replica, too. A WSGI wrapper > will > read the setting from ipaConfigString=enabledService in > cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. When the feature is > disabled, it will reply with 404 Not Found error. I prefer enabled by default unless there is some performance or security consideration. Mere proxying isn't a security consideration since we already expose the KDC by default. > 4) In order to read the state of the switch, the WSGI script needs to > be > able to connect to LDAP. I can use Apache's / FreeIPA webui's keytab > to > get a ticket for GSSAPI bind. However Apache has no permission to > read > ipaConfigStrings in the masters subtree. A new role/permission and > ACI > is required here. This is, indeed, a security problem. Do we have a strong use case for per-replica control? If not, let's just do a single global control since we can easily make this globally readable. > 5) python-kdcproxy can read its configuration from multiple places. > For > performance reasons we don't want DNS lookups. Therefore our proxy > instance will only use libkrb5.so to read a list of KDCs, kpasswd and > admin servers from /etc/krb5.conf. > > Open questions / issues > ----------------------- > > For 3) and 4) the Apache HTTP principal must be able to read or at > least > compare the state of the switch. The ACIs in the masters tree forbid > any > access to ipaConfigString entries except for principals with 'System: > Read IPA Masters' permission. Martin Basti and Petr Spacek have > suggested that I introduce a new permission for the task. I haven't > figured out how to configure and assign a new permission. Right now > my > experimental code uses this ACI: > > > (targetfilter="(ipaConfigString=enabledService)")(targetattr="ipaConf > igString")(version > 3.0; acl "Compare enabledService access to masters"; allow(search, > compare) userdn = "ldap:///all";) > > > I found ipaserver.install.service.Service and SimpleServiceInstance > in > the FreeIPA sources. As far as I understand the use of the classes, > they > are used in the installers to configure service instances. However > the > kdcproxy service instance is going to be special. It has no 1:1 > relation > to a system service. Instead it shares a system service (Apache > HTTPD) > with the HttpInstance for FreeIPA's webui. AFAIK no other service > instance has such a relation. > > > Finally I haven't figured out the best way to configure the instance. > An > admin should be able to enable / disable KDC proxy. Should I write a > script or a ipa plugin for the job? IMHO, use a global switch and put the control in the ipa config plugin. We shouldn't over-engineer this. Nathaniel From tbordaz at redhat.com Tue May 26 14:13:36 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 26 May 2015 16:13:36 +0200 Subject: [Freeipa-devel] Domain level for topology plugin = 2 In-Reply-To: <55646331.5050807@redhat.com> References: <55646331.5050807@redhat.com> Message-ID: <55647F90.506@redhat.com> On 05/26/2015 02:12 PM, Petr Spacek wrote: > Hello, > > it came to my mind that domain level for topology plugin should actually be > number 2, not 1. > > We already used number 1 for incompatible changes in DNS tree and I believe > that it is not a good idea to have two places which say 'version 1' but and > actually mean two different things. (DNS tree version 1 + domain level 1) > > Patch is attached. > > > Hello, The fix looks good but that seems strange to have to set the initial version of the topology plugin to 2.0. (IIUC That is the version that will be written in dse.ldif) I would rather expects that topology plugin 1.0, would activate itself if the DomainLevel is 2.0 or more. If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate itself if DomainLevel >= DomainLevel_trigger. Let's wait for Ludwig feedback. thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From redhatrises at gmail.com Tue May 26 14:16:16 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Tue, 26 May 2015 08:16:16 -0600 Subject: [Freeipa-devel] [PATCH 0050] Fix client ca.crt to match the server's cert Message-ID: Hello, Fix for https://fedorahosted.org/freeipa/ticket/3809 Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0050-Fix-client-ca.crt-to-match-the-server-s-cert.patch Type: text/x-patch Size: 1052 bytes Desc: not available URL: From mkosek at redhat.com Tue May 26 14:16:43 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 26 May 2015 16:16:43 +0200 Subject: [Freeipa-devel] Domain level for topology plugin = 2 In-Reply-To: <55647F90.506@redhat.com> References: <55646331.5050807@redhat.com> <55647F90.506@redhat.com> Message-ID: <5564804B.6080305@redhat.com> On 05/26/2015 04:13 PM, thierry bordaz wrote: > On 05/26/2015 02:12 PM, Petr Spacek wrote: >> Hello, >> >> it came to my mind that domain level for topology plugin should actually be >> number 2, not 1. >> >> We already used number 1 for incompatible changes in DNS tree and I believe >> that it is not a good idea to have two places which say 'version 1' but and >> actually mean two different things. (DNS tree version 1 + domain level 1) >> >> Patch is attached. >> >> >> > Hello, > The fix looks good but that seems strange to have to set the initial version of > the topology plugin to 2.0. (IIUC That is the version that will be written in > dse.ldif) > I would rather expects that topology plugin 1.0, would activate itself if the > DomainLevel is 2.0 or more. > If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate > itself if DomainLevel >= DomainLevel_trigger. > > Let's wait for Ludwig feedback. > > thanks > thierry My personal opinion on this is to start with Domain Level 1 regardless. We already "solved" the DNS forwarders otherwise, with docs, async updates etc. I do not think we will be returning to implementing proper Domain Level support for that anyway. So I rather think that all the "Domain Level starts with 0, 1 is unused, 2 is the top one" will cause unforeseen issues I would rather like to avoid. My 2 cents. Martin From cheimes at redhat.com Tue May 26 14:17:15 2015 From: cheimes at redhat.com (Christian Heimes) Date: Tue, 26 May 2015 16:17:15 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <1432648676.3354.6.camel@redhat.com> References: <555F03DB.3090702@redhat.com> <1432648676.3354.6.camel@redhat.com> Message-ID: <5564806B.8030202@redhat.com> On 2015-05-26 15:57, Nathaniel McCallum wrote: > /KdcProxy > > "The URI uses the virtual directory /KdcProxy unless otherwise > configured." > > https://msdn.microsoft.com/en-us/library/hh553891.aspx > > Also, the proxy should be available over both HTTP and HTTPS. Easy-peasy! I'm using /KdcProxy already and the default configuration allows HTTP and HTTPS requests. > I prefer enabled by default unless there is some performance or > security consideration. Mere proxying isn't a security consideration > since we already expose the KDC by default. My latest patch enables the proxy by default. > This is, indeed, a security problem. Do we have a strong use case for > per-replica control? If not, let's just do a single global control > since we can easily make this globally readable. Martin and Petr both suggested per-replica configuration of the new feature. Petr has argued it is a future-proof design. It will make containerization of FreeIPA simpler as no schema change is required later. Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From mkosek at redhat.com Tue May 26 14:24:03 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 26 May 2015 16:24:03 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <5564806B.8030202@redhat.com> References: <555F03DB.3090702@redhat.com> <1432648676.3354.6.camel@redhat.com> <5564806B.8030202@redhat.com> Message-ID: <55648203.3060109@redhat.com> On 05/26/2015 04:17 PM, Christian Heimes wrote: > On 2015-05-26 15:57, Nathaniel McCallum wrote: >> /KdcProxy >> >> "The URI uses the virtual directory /KdcProxy unless otherwise >> configured." >> >> https://msdn.microsoft.com/en-us/library/hh553891.aspx >> >> Also, the proxy should be available over both HTTP and HTTPS. > > Easy-peasy! I'm using /KdcProxy already and the default configuration > allows HTTP and HTTPS requests. Just make sure it works with the IPA might https rewrite rule: # Redirect to the secure port if not displaying an error or retrieving # configuration. RewriteCond %{SERVER_PORT} !^443$$ RewriteCond %{REQUEST_URI} !^/ipa/(errors|config|crl) RewriteCond %{REQUEST_URI} !^/ipa/[^\?]+(\.js|\.css|\.png|\.gif|\.ico|\.woff|\.svg|\.ttf|\.eot)$$ RewriteRule ^/ipa/(.*) https://$FQDN/ipa/$$1 [L,R=301,NC] > >> I prefer enabled by default unless there is some performance or >> security consideration. Mere proxying isn't a security consideration >> since we already expose the KDC by default. > > My latest patch enables the proxy by default. > >> This is, indeed, a security problem. Do we have a strong use case for >> per-replica control? If not, let's just do a single global control >> since we can easily make this globally readable. > > Martin and Petr both suggested per-replica configuration of the new > feature. Petr has argued it is a future-proof design. It will make > containerization of FreeIPA simpler as no schema change is required later. I discussed this briefly with Nathaniel, if this is sufficiently easy/doable, I am fine with it. If not, then adding the global control may be the way for FreeIPA 4.2 GA and implement the per-replica control later. From pspacek at redhat.com Tue May 26 14:32:59 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 26 May 2015 16:32:59 +0200 Subject: [Freeipa-devel] Domain level for topology plugin = 2 In-Reply-To: <5564804B.6080305@redhat.com> References: <55646331.5050807@redhat.com> <55647F90.506@redhat.com> <5564804B.6080305@redhat.com> Message-ID: <5564841B.4020906@redhat.com> On 26.5.2015 16:16, Martin Kosek wrote: > On 05/26/2015 04:13 PM, thierry bordaz wrote: >> On 05/26/2015 02:12 PM, Petr Spacek wrote: >>> Hello, >>> >>> it came to my mind that domain level for topology plugin should actually be >>> number 2, not 1. >>> >>> We already used number 1 for incompatible changes in DNS tree and I believe >>> that it is not a good idea to have two places which say 'version 1' but and >>> actually mean two different things. (DNS tree version 1 + domain level 1) >>> >>> Patch is attached. >>> >>> >>> >> Hello, >> The fix looks good but that seems strange to have to set the initial version of >> the topology plugin to 2.0. (IIUC That is the version that will be written in >> dse.ldif) >> I would rather expects that topology plugin 1.0, would activate itself if the >> DomainLevel is 2.0 or more. >> If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate >> itself if DomainLevel >= DomainLevel_trigger. >> >> Let's wait for Ludwig feedback. >> >> thanks >> thierry > > My personal opinion on this is to start with Domain Level 1 regardless. We > already "solved" the DNS forwarders otherwise, with docs, async updates etc. I > do not think we will be returning to implementing proper Domain Level support > for that anyway. > > So I rather think that all the "Domain Level starts with 0, 1 is unused, 2 is > the top one" will cause unforeseen issues I would rather like to avoid. I'm more worried about confusion in future. To to me it simply seems easier to bump one integer now than to document and explain (to users & new developers) why we have two "ones" which mean something else. Code-wise it is just an integer. Also, it can simplify logic in future when we decide to do another incompatible change in DNS tree because we will have only one integer to test (instead of checking two separate version attribute in DNS tree & domain level). If you really want to avoid unforeseen issues rather go and get rid of "major.minor" logic we have in the topology plugin right now :-) -- Petr^2 Spacek From pspacek at redhat.com Tue May 26 14:36:41 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 26 May 2015 16:36:41 +0200 Subject: [Freeipa-devel] [PATCH 0368-0371] Support LDAP MODRDN for ordinary DNS records In-Reply-To: <55642C27.4020203@redhat.com> References: <555C3287.3080108@redhat.com> <55642C27.4020203@redhat.com> Message-ID: <556484F9.40309@redhat.com> On 26.5.2015 10:17, Tomas Hozza wrote: > On 05/20/2015 09:06 AM, Petr Spacek wrote: >> Hello, >> >> this patchset implements support for MODRDN for ordinary records. As noted in >> ticket https://fedorahosted.org/bind-dyndb-ldap/ticket/123, we agreed >> yesterday that renaming zones is out of scope and seems unnecessarily complex. >> >> This patch set depends on 'metadb' branch. It is also available from: >> https://github.com/pspacek/bind-dyndb-ldap/tree/modrdn >> >> Thank you for your time! >> > > I did formal review. Everything looks OK. > > ACK Thank you very much! Pushed to master: 9f4a95a3f36ce98e3b51f894090b521e4c444c38 Move SOA serial update functions to zone.c. 37236dd1a4fe20b3e7254d12bb03498e5174e161 Add LDAP UUID -> meta-database name mapping function. 9ccc78af80661403a7c13df41d77cc8dd5658273 Store object class, generation number, and DNS names into meta-LDAP DB. ea561ba7e4af91eeef2f56834e32e3581d8e4123 Support LDAP MODRDN for ordinary DNS records. a1f960e1edd4c6317d81e48a9b57f9c87c581e22 Add memory context to ldap_entry_t. fd7ad464d072a2abd7805a52d3bcd0e5b4f0fa9e Remove dangling declarations for ldap_entrylist_*. eb599ae5b3b7a3f86237f60830357bd53deab012 Remove dependency on entry->dn to avoid problems with reconstructed entries. -- Petr^2 Spacek From cheimes at redhat.com Tue May 26 14:43:41 2015 From: cheimes at redhat.com (Christian Heimes) Date: Tue, 26 May 2015 16:43:41 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <55648203.3060109@redhat.com> References: <555F03DB.3090702@redhat.com> <1432648676.3354.6.camel@redhat.com> <5564806B.8030202@redhat.com> <55648203.3060109@redhat.com> Message-ID: <5564869D.9040804@redhat.com> On 2015-05-26 16:24, Martin Kosek wrote: > On 05/26/2015 04:17 PM, Christian Heimes wrote: >> On 2015-05-26 15:57, Nathaniel McCallum wrote: >>> /KdcProxy >>> >>> "The URI uses the virtual directory /KdcProxy unless otherwise >>> configured." >>> >>> https://msdn.microsoft.com/en-us/library/hh553891.aspx >>> >>> Also, the proxy should be available over both HTTP and HTTPS. >> >> Easy-peasy! I'm using /KdcProxy already and the default configuration >> allows HTTP and HTTPS requests. > > Just make sure it works with the IPA might https rewrite rule: > > # Redirect to the secure port if not displaying an error or retrieving > # configuration. > RewriteCond %{SERVER_PORT} !^443$$ > RewriteCond %{REQUEST_URI} !^/ipa/(errors|config|crl) > RewriteCond %{REQUEST_URI} > !^/ipa/[^\?]+(\.js|\.css|\.png|\.gif|\.ico|\.woff|\.svg|\.ttf|\.eot)$$ > RewriteRule ^/ipa/(.*) https://$FQDN/ipa/$$1 [L,R=301,NC] The KDC proxy WSGI app is mounted at /KdcProxy. The IPA rewrite rule only affect /ipa* paths. > I discussed this briefly with Nathaniel, if this is sufficiently > easy/doable, I am fine with it. If not, then adding the global control > may be the way for FreeIPA 4.2 GA and implement the per-replica control > later. I guess the per-replica configuration is a bit more work. As far as I know FreeIPA has no command line tool to enable/disable services in the cn=masters,cn=ipa,cn=etc subtree. For starters Petr Vobornik has suggested an API command to list IPA servers. His proposal doesn't include an API to modify services of a server, though. Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From npmccallum at redhat.com Tue May 26 14:50:49 2015 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 26 May 2015 10:50:49 -0400 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <5564869D.9040804@redhat.com> References: <555F03DB.3090702@redhat.com> <1432648676.3354.6.camel@redhat.com> <5564806B.8030202@redhat.com> <55648203.3060109@redhat.com> <5564869D.9040804@redhat.com> Message-ID: <1432651849.3354.26.camel@redhat.com> On Tue, 2015-05-26 at 16:43 +0200, Christian Heimes wrote: > On 2015-05-26 16:24, Martin Kosek wrote: > > On 05/26/2015 04:17 PM, Christian Heimes wrote: > > > On 2015-05-26 15:57, Nathaniel McCallum wrote: > > > > /KdcProxy > > > > > > > > "The URI uses the virtual directory /KdcProxy unless otherwise > > > > configured." > > > > > > > > https://msdn.microsoft.com/en-us/library/hh553891.aspx > > > > > > > > Also, the proxy should be available over both HTTP and HTTPS. > > > > > > Easy-peasy! I'm using /KdcProxy already and the default > > > configuration > > > allows HTTP and HTTPS requests. > > > > Just make sure it works with the IPA might https rewrite rule: > > > > # Redirect to the secure port if not displaying an error or > > retrieving > > # configuration. > > RewriteCond %{SERVER_PORT} !^443$$ > > RewriteCond %{REQUEST_URI} !^/ipa/(errors|config|crl) > > RewriteCond %{REQUEST_URI} > > !^/ipa/[^\?]+(\.js|\.css|\.png|\.gif|\.ico|\.woff|\.svg|\.ttf|\.eot > > )$$ > > RewriteRule ^/ipa/(.*) https://$FQDN/ipa/$$1 [L,R=301,NC] > > The KDC proxy WSGI app is mounted at /KdcProxy. The IPA rewrite rule > only affect /ipa* paths. > > > > I discussed this briefly with Nathaniel, if this is sufficiently > > easy/doable, I am fine with it. If not, then adding the global > > control > > may be the way for FreeIPA 4.2 GA and implement the per-replica > > control > > later. > > I guess the per-replica configuration is a bit more work. As far as I > know FreeIPA has no command line tool to enable/disable services in > the > cn=masters,cn=ipa,cn=etc subtree. For starters Petr Vobornik has > suggested an API command to list IPA servers. His proposal doesn't > include an API to modify services of a server, though. Right. So as I see it, we have three options: 1. Merge kdcproxy soon with a global switch. A. Build per-replica switches later. B. Never build per-replica switches. 2. Merge kdcproxy later with per-replica switches. I don't think having both types of switches is bad UX. In fact, I think it is better UX than per-replica switches alone. Since per-replica switches are a superset of the global switch functionality, let's do 1A and do per-replica switches later (if needed and feasible) Nathaniel From cheimes at redhat.com Tue May 26 15:09:14 2015 From: cheimes at redhat.com (Christian Heimes) Date: Tue, 26 May 2015 17:09:14 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <1432651849.3354.26.camel@redhat.com> References: <555F03DB.3090702@redhat.com> <1432648676.3354.6.camel@redhat.com> <5564806B.8030202@redhat.com> <55648203.3060109@redhat.com> <5564869D.9040804@redhat.com> <1432651849.3354.26.camel@redhat.com> Message-ID: <55648C9A.8040603@redhat.com> On 2015-05-26 16:50, Nathaniel McCallum wrote: > Right. So as I see it, we have three options: > 1. Merge kdcproxy soon with a global switch. > A. Build per-replica switches later. > B. Never build per-replica switches. > 2. Merge kdcproxy later with per-replica switches. > > I don't think having both types of switches is bad UX. In fact, I think > it is better UX than per-replica switches alone. Since per-replica > switches are a superset of the global switch functionality, let's do 1A > and do per-replica switches later (if needed and feasible) You know what? That was basically my second implementation. :) I had a global switch in cn=ipaConfig,cn=etc and a per-replica switch in cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. The code is still in another branch on my laptop. Since I have both variants mostly implemented, I'd like to suggest yet another option: 2. Merge kdcproxy with global and per-replica switch, but for now offer only a CLI command for the global switch. That's easy to implement. I only need an ACI for cn=masters,cn=ipa,cn=etc in order to allow compare and search for ipaConfigString=enabledService. Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From mhonek at redhat.com Tue May 26 15:10:31 2015 From: mhonek at redhat.com (Matus Honek) Date: Tue, 26 May 2015 11:10:31 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0367] Support unknown record types (RFC 3597) In-Reply-To: <555EE2E5.2020001@redhat.com> References: <555A05D2.7000408@redhat.com> <555EE2E5.2020001@redhat.com> Message-ID: <493605240.4506885.1432653031696.JavaMail.zimbra@redhat.com> Works with correct privileges checking, as in your patch attached. ACK Mat?? Hon?k ----- Original Message ----- From: "Petr Spacek" To: thozza at redhat.com Cc: freeipa-devel at redhat.com, "Matus Honek" Sent: Friday, May 22, 2015 10:03:49 AM Subject: Re: [Freeipa-devel] [PATCH 0367] Support unknown record types (RFC 3597) On 18.5.2015 17:31, Petr Spacek wrote: > Hello, > > This patch is unrelated to metaDB but it should be merged before alpha, too. > > Thank you for review! > > Support unknown record types (RFC 3597). > > Fallback to generic LDAP attribute "UnknownRecord;TYP256" if attempt to > add specific attribute like "URIRecord" failed with LDAP_OBJECT_CLASS_VIOLATION > and always delete both attributes like "URIRecord" and "UnknownRecord;TYPE256". > > https://fedorahosted.org/bind-dyndb-ldap/ticket/157 Fixed version is attached. Version 1 could dereference NULL pointers in second iteration of while loops. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0367-2-Support-unknown-record-types-RFC-3597-Handle-privileges-correctly.patch Type: text/x-patch Size: 577 bytes Desc: not available URL: From npmccallum at redhat.com Tue May 26 15:11:29 2015 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 26 May 2015 11:11:29 -0400 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <55648C9A.8040603@redhat.com> References: <555F03DB.3090702@redhat.com> <1432648676.3354.6.camel@redhat.com> <5564806B.8030202@redhat.com> <55648203.3060109@redhat.com> <5564869D.9040804@redhat.com> <1432651849.3354.26.camel@redhat.com> <55648C9A.8040603@redhat.com> Message-ID: <1432653089.3354.36.camel@redhat.com> On Tue, 2015-05-26 at 17:09 +0200, Christian Heimes wrote: > On 2015-05-26 16:50, Nathaniel McCallum wrote: > > Right. So as I see it, we have three options: > > 1. Merge kdcproxy soon with a global switch. > > A. Build per-replica switches later. > > B. Never build per-replica switches. > > 2. Merge kdcproxy later with per-replica switches. > > > > I don't think having both types of switches is bad UX. In fact, I > > think > > it is better UX than per-replica switches alone. Since per-replica > > switches are a superset of the global switch functionality, let's > > do 1A > > and do per-replica switches later (if needed and feasible) > > You know what? That was basically my second implementation. :) I had > a > global switch in cn=ipaConfig,cn=etc and a per-replica switch in > cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. The code is still in > another branch on my laptop. > > Since I have both variants mostly implemented, I'd like to suggest > yet > another option: > > 2. Merge kdcproxy with global and per-replica switch, but for now > offer > only a CLI command for the global switch. > > That's easy to implement. I only need an ACI for > cn=masters,cn=ipa,cn=etc in order to allow compare and search for > ipaConfigString=enabledService. I don't want to add code that: 1. is half-baked 2. we aren't committed to supporting. I'd rather land per-replica switches as a separate commit with everything polished and supportable. Nathaniel From jcholast at redhat.com Tue May 26 15:40:03 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 26 May 2015 17:40:03 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <555F03DB.3090702@redhat.com> References: <555F03DB.3090702@redhat.com> Message-ID: <556493D3.8010402@redhat.com> Dne 22.5.2015 v 12:24 Christian Heimes napsal(a): > Hello, > > since May 1st I'm a new Red Hat employee and developer with the FreeIPA > team. Some of you may already recognize my name from my contributions to > CPython core, Python security and TLS/SSL improvements, or a couple of > PEPs. I'm very glad that I can now work on Open Source as a full time > job. I haven't had any dealings with FreeIPA before and just rudimentary > experience with LDAP and Kerberos as a developer. Over the past two > weeks I have been digging through FreeIPA sources, read docs and played > with its services. I'm slowly starting to grasp the building blocks. > > I was put in charge of MS-KKDCP integration into FreeIPA 4.2 [1]. The > task is small and isolated enough for a new contributor. KKDCP stands > for Kerberos KDC proxy protocol. It was developed by Microsoft to tunnel > KDC requests over HTTPS. It's useful for firewalled environments where > 88/TCP+UDP are blocked and only 80/TCP + 443/TCP are available. With > KKDCP the client side wraps each Kerberos request in an additional ASN.1 > sequence and sends it as POST request to a proxy. The proxy unpacks the > request, forwards it to a KDC and returns its reply to the client. MIT > krb5 supports [2] KKDCP since 1.13, Fedora has backports for 1.12. > > Nathaniel McCallum has written [3] a proxy server as WSGI app. I'm > working on improvements and integration of the WSGI app into FreeIPA. > Yesterday several bug fixes already landed in kdcproxy. > > The integration into FreeIPA is the tricky part for me. I'm not familiar > enough with FreeIPA yet to understand possible implications, so I need > your guidance. I already got some feedback from several people (Dmitri, > Nathan, Nathaniel, Martin, Martin2, Petr, Alexander...). > > > Here is what I have so far: > > 1) The FreeIPA webui already depends on Apache and mod_wsgi. KDC proxy > will run from the same Apache HTTPD instance but it will use a different > mod_wsgi daemon configuration. A second WSGI daemon is easily configured > and allows us to tune the daemon for KDC proxy's needs. FreeIPA is > mounted at /ipa, KDC Proxy will be available at /KdcProxy or /kdc. > > 2) For now we are not going to introduce a separate package > freeipa-server-kdcproxy. freeipa-server will depend on python-kdcproxy > and install all configuration files. Therefore the entry point /KdcProxy > is always configured > > 3) An administrator must be able to enable/disable the new feature. The > state of the switch will be read when Apache is started or reloaded. The > feature must be configurable for each replica, too. A WSGI wrapper will > read the setting from ipaConfigString=enabledService in > cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. When the feature is > disabled, it will reply with 404 Not Found error. > > 4) In order to read the state of the switch, the WSGI script needs to be > able to connect to LDAP. I can use Apache's / FreeIPA webui's keytab to > get a ticket for GSSAPI bind. However Apache has no permission to read > ipaConfigStrings in the masters subtree. A new role/permission and ACI > is required here. > > 5) python-kdcproxy can read its configuration from multiple places. For > performance reasons we don't want DNS lookups. Therefore our proxy > instance will only use libkrb5.so to read a list of KDCs, kpasswd and > admin servers from /etc/krb5.conf. > > > Open questions / issues > ----------------------- > > For 3) and 4) the Apache HTTP principal must be able to read or at least > compare the state of the switch. The ACIs in the masters tree forbid any > access to ipaConfigString entries except for principals with 'System: > Read IPA Masters' permission. Martin Basti and Petr Spacek have > suggested that I introduce a new permission for the task. I haven't > figured out how to configure and assign a new permission. Right now my > experimental code uses this ACI: > > > (targetfilter="(ipaConfigString=enabledService)")(targetattr="ipaConfigString")(version > 3.0; acl "Compare enabledService access to masters"; allow(search, > compare) userdn = "ldap:///all";) I think a "normal" ACI is fine, I'm not sure if it even should be a permission, given we have no service group object in IPA for use in roles. However, access should be limited only to HTTP on IPA servers. > > > I found ipaserver.install.service.Service and SimpleServiceInstance in > the FreeIPA sources. As far as I understand the use of the classes, they > are used in the installers to configure service instances. However the > kdcproxy service instance is going to be special. It has no 1:1 relation > to a system service. Instead it shares a system service (Apache HTTPD) > with the HttpInstance for FreeIPA's webui. AFAIK no other service > instance has such a relation. Go ahead, it doesn't really matter there is no 1:1 relation to a system service. I don't think the services were supposed to have a 1:1 relation to system services in the first place. Notice how none of the older service names refer to a particular system service, but rather name what kind of service is provided (HTTP, DNS, CA, ...). It was only (relatively) recently that people started adding service entries for each system service. I believe it's wrong - for example, it does not make much sense to handle all of the DNSSEC related services separately from the DNS service. > > > Finally I haven't figured out the best way to configure the instance. An > admin should be able to enable / disable KDC proxy. Should I write a > script or a ipa plugin for the job? A script, ipa-kdcproxy-install, if you want to be consistent with what's already there. > > > You can find my patch in my Github repos [4]. The installer code is > mostly untested, though. > > > Please advice :) > Christian > > > [1] https://www.freeipa.org/page/V4/KDC_Proxy > [2] http://web.mit.edu/kerberos/krb5-current/doc/admin/https.html > [3] https://github.com/npmccallum/kdcproxy > [4] https://github.com/tiran/freeipa/compare/master...kdcproxy2 > > > -- Jan Cholasta From jcholast at redhat.com Tue May 26 15:49:29 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 26 May 2015 17:49:29 +0200 Subject: [Freeipa-devel] [PATCH 429] replica-install: Allow install on top of already configured client In-Reply-To: <555CA7E7.6050808@redhat.com> References: <555CA7E7.6050808@redhat.com> Message-ID: <55649609.2020203@redhat.com> Dne 20.5.2015 v 17:27 Jan Cholasta napsal(a): > Hi, > > the attached patch implements the initial bits for > . > > Test by running ipa-client-install and then ipa-replica-install on the > same host. Updated patch attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-429.1-replica-install-Allow-install-on-top-of-already-conf.patch Type: text/x-patch Size: 13490 bytes Desc: not available URL: From cheimes at redhat.com Tue May 26 15:56:41 2015 From: cheimes at redhat.com (Christian Heimes) Date: Tue, 26 May 2015 17:56:41 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <1432653089.3354.36.camel@redhat.com> References: <555F03DB.3090702@redhat.com> <1432648676.3354.6.camel@redhat.com> <5564806B.8030202@redhat.com> <55648203.3060109@redhat.com> <5564869D.9040804@redhat.com> <1432651849.3354.26.camel@redhat.com> <55648C9A.8040603@redhat.com> <1432653089.3354.36.camel@redhat.com> Message-ID: <556497B9.6020709@redhat.com> On 2015-05-26 17:11, Nathaniel McCallum wrote: > I don't want to add code that: > 1. is half-baked > 2. we aren't committed to supporting. > > I'd rather land per-replica switches as a separate commit with > everything polished and supportable. Well then ... I'm going to remove the code for per-replica config and go back to the global switch. Since I'm now familiar with the code, it's easy for me to add it back, in case we need it again. :) Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From ftweedal at redhat.com Tue May 26 15:59:30 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 27 May 2015 01:59:30 +1000 Subject: [Freeipa-devel] [PATCHES 0001-0013 v4] Profile management In-Reply-To: <555DD39C.3070103@redhat.com> References: <5555E63D.4050808@redhat.com> <555AF9E1.1010606@redhat.com> <20150519115027.GA12806@dhcp-40-8.bne.redhat.com> <555C1E5C.2080707@redhat.com> <20150520055636.GF12806@dhcp-40-8.bne.redhat.com> <555C30FE.4030707@redhat.com> <20150520144106.GH12806@dhcp-40-8.bne.redhat.com> <555DCC96.2050001@redhat.com> <555DD031.8070302@redhat.com> <555DD39C.3070103@redhat.com> Message-ID: <20150526155930.GI13469@dhcp-40-8.bne.redhat.com> 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 -------------- next part -------------- >From aa197b04c0337ab6244702cbf212fe9f233aecb7 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 20 Apr 2015 23:20:19 -0400 Subject: [PATCH 01/13] Install CA with LDAP profiles backend Install the Dogtag CA to use the LDAPProfileSubsystem instead of the default (file-based) ProfileSubsystem. Part of: https://fedorahosted.org/freeipa/ticket/4560 --- ipaserver/install/cainstance.py | 1 + 1 file changed, 1 insertion(+) diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index 5133940687204b615eec56b6a89542ddd5617539..030c9f12daba4b38b748da8940e38d3cf2109788 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -503,6 +503,7 @@ class CAInstance(DogtagInstance): config.set("CA", "pki_restart_configured_instance", "False") config.set("CA", "pki_backup_keys", "True") config.set("CA", "pki_backup_password", self.admin_password) + config.set("CA", "pki_profiles_in_ldap", "True") # Client security database config.set("CA", "pki_client_database_dir", self.agent_db) -- 2.1.0 -------------- next part -------------- >From 05a74613d05dd63713539dec91c430f876687f9f Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Tue, 21 Apr 2015 02:24:10 -0400 Subject: [PATCH 02/13] Add schema for certificate profiles The certprofile object class is used to track IPA-managed certificate profiles in Dogtag and store IPA-specific settings. Part of: https://fedorahosted.org/freeipa/ticket/57 --- install/share/60certificate-profiles.ldif | 3 +++ install/share/Makefile.am | 1 + install/share/bootstrap-template.ldif | 12 ++++++++++++ ipaserver/install/dsinstance.py | 1 + 4 files changed, 17 insertions(+) create mode 100644 install/share/60certificate-profiles.ldif diff --git a/install/share/60certificate-profiles.ldif b/install/share/60certificate-profiles.ldif new file mode 100644 index 0000000000000000000000000000000000000000..f1281949e53386e5bfe8b35e0c15858c693c5467 --- /dev/null +++ b/install/share/60certificate-profiles.ldif @@ -0,0 +1,3 @@ +dn: cn=schema +attributeTypes: (2.16.840.1.113730.3.8.21.1.1 NAME 'ipaCertProfileStoreIssued' DESC 'Store certificates issued using this profile' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA v4.2' ) +objectClasses: (2.16.840.1.113730.3.8.21.2.1 NAME 'ipaCertProfile' SUP top STRUCTURAL MUST ( cn $ description $ ipaCertProfileStoreIssued ) X-ORIGIN 'IPA v4.2' ) diff --git a/install/share/Makefile.am b/install/share/Makefile.am index 8d336690f184025f8199ed1d2c57d8274f0d3886..f44772b20c173c6fe43503716f40454f6f6b6f11 100644 --- a/install/share/Makefile.am +++ b/install/share/Makefile.am @@ -16,6 +16,7 @@ app_DATA = \ 60basev3.ldif \ 60ipadns.ldif \ 60ipapk11.ldif \ + 60certificate-profiles.ldif \ 61kerberos-ipav3.ldif \ 65ipacertstore.ldif \ 65ipasudo.ldif \ diff --git a/install/share/bootstrap-template.ldif b/install/share/bootstrap-template.ldif index 06b82aa4ae74e7766d0c09a63aa75fa222e7ab7d..c5d4bad8b80640881f4631e4873a12c82b0ea48a 100644 --- a/install/share/bootstrap-template.ldif +++ b/install/share/bootstrap-template.ldif @@ -429,3 +429,15 @@ cn: ${REALM}_id_range ipaBaseID: $IDSTART ipaIDRangeSize: $IDRANGE_SIZE ipaRangeType: ipa-local + +dn: cn=ca,$SUFFIX +changetype: add +objectClass: nsContainer +objectClass: top +cn: ca + +dn: cn=certprofiles,cn=ca,$SUFFIX +changetype: add +objectClass: nsContainer +objectClass: top +cn: certprofiles diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py index 064a2ab1db61b465638a77e13e1d9ea43b1cce63..2acab13f247ed18a750f0e1cbbd98f4e63718c03 100644 --- a/ipaserver/install/dsinstance.py +++ b/ipaserver/install/dsinstance.py @@ -57,6 +57,7 @@ IPA_SCHEMA_FILES = ("60kerberos.ldif", "60basev3.ldif", "60ipapk11.ldif", "60ipadns.ldif", + "60certificate-profiles.ldif", "61kerberos-ipav3.ldif", "65ipacertstore.ldif", "65ipasudo.ldif", -- 2.1.0 -------------- next part -------------- >From 2fac21c1722fed25031ea515af1fe088857b4034 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Wed, 29 Apr 2015 06:07:58 -0400 Subject: [PATCH 03/13] ipa-pki-proxy: provide access to profiles REST API Part of: https://fedorahosted.org/freeipa/ticket/57 --- install/conf/ipa-pki-proxy.conf | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/install/conf/ipa-pki-proxy.conf b/install/conf/ipa-pki-proxy.conf index 5d21156848f3b5ddf14c42d92a26a30a9f94af36..366ca15a1868758547f9f1d3334fddba38793083 100644 --- a/install/conf/ipa-pki-proxy.conf +++ b/install/conf/ipa-pki-proxy.conf @@ -1,4 +1,4 @@ -# VERSION 5 - DO NOT REMOVE THIS LINE +# VERSION 6 - DO NOT REMOVE THIS LINE ProxyRequests Off @@ -11,7 +11,7 @@ ProxyRequests Off # matches for admin port and installer - + NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate NSSVerifyClient none ProxyPassMatch ajp://localhost:$DOGTAG_PORT @@ -26,5 +26,13 @@ ProxyRequests Off ProxyPassReverse ajp://localhost:$DOGTAG_PORT +# matches for REST API + + NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate + NSSVerifyClient require + ProxyPassMatch ajp://localhost:$DOGTAG_PORT + ProxyPassReverse ajp://localhost:$DOGTAG_PORT + + # Only enable this on servers that are not generating a CRL ${CLONE}RewriteRule ^/ipa/crl/MasterCRL.bin https://$FQDN/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL [L,R=301,NC] -- 2.1.0 -------------- next part -------------- >From 32d4d23426d8285bd282033814627e9a0b088b59 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Thu, 30 Apr 2015 23:50:41 -0400 Subject: [PATCH 04/13] Add ACL to allow CA agent to modify profiles Part of: https://fedorahosted.org/freeipa/ticket/57 --- ipaserver/install/cainstance.py | 29 +++++++++++++++++++++++++++++ ipaserver/install/server.py | 11 +++++++++++ 2 files changed, 40 insertions(+) diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index 030c9f12daba4b38b748da8940e38d3cf2109788..871581b4afc5df854b9a090ef51bb0ad3b3871ee 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -469,6 +469,7 @@ class CAInstance(DogtagInstance): self.step("requesting RA certificate from CA", self.__request_ra_certificate) self.step("issuing RA agent certificate", self.__issue_ra_cert) self.step("adding RA agent as a trusted user", self.__configure_ra) + self.step("authorizing RA to modify profiles", self.__configure_profiles_acl) self.step("configure certmonger for renewals", self.configure_certmonger_renewal) self.step("configure certificate renewals", self.configure_renewal) if not self.clone: @@ -940,6 +941,10 @@ class CAInstance(DogtagInstance): conn.unbind() + def __configure_profiles_acl(self): + """Allow the Certificate Manager Agents group to modify profiles.""" + configure_profiles_acl() + def __run_certutil(self, args, database=None, pwd_file=None, stdin=None): if not database: database = self.ra_agent_db @@ -1825,6 +1830,30 @@ def update_people_entry(dercert): return True +def configure_profiles_acl(): + server_id = installutils.realm_to_serverid(api.env.realm) + dogtag_uri = 'ldapi://%%2fvar%%2frun%%2fslapd-%s.socket' % server_id + updated = False + + dn = DN(('cn', 'aclResources'), ('o', 'ipaca')) + rule = ( + 'certServer.profile.configuration:read,modify:allow (read,modify) ' + 'group="Certificate Manager Agents":' + 'Certificate Manager agents may modify (create/update/delete) and read profiles' + ) + modlist = [(ldap.MOD_ADD, 'resourceACLS', [rule])] + + conn = ldap2.ldap2(shared_instance=False, ldap_uri=dogtag_uri) + if not conn.isconnected(): + conn.connect(autobind=True) + rules = conn.get_entry(dn).get('resourceACLS', []) + if rule not in rules: + conn.conn.modify_s(str(dn), modlist) + updated = True + + conn.disconnect() + return updated + if __name__ == "__main__": standard_logging_setup("install.log") ds = dsinstance.DsInstance() diff --git a/ipaserver/install/server.py b/ipaserver/install/server.py index c08b74828bf811c560963cc4f9e267d3afbeedb3..7bfcb48ea48c0eb108055321d9a00b14ffbfe790 100644 --- a/ipaserver/install/server.py +++ b/ipaserver/install/server.py @@ -284,6 +284,16 @@ def setup_firefox_extension(fstore): http.setup_firefox_extension(realm, domain) +def ca_configure_profiles_acl(ca): + root_logger.info('[Authorizing RA Agent to modify profiles]') + + if not ca.is_configured(): + root_logger.info('CA is not configured') + return False + + return cainstance.configure_profiles_acl() + + def upgrade_ipa_profile(ca, domain, fqdn): """ Update the IPA Profile provided by dogtag @@ -1364,6 +1374,7 @@ def upgrade_configuration(): upgrade_ipa_profile(ca, api.env.domain, fqdn), certificate_renewal_update(ca), ca_enable_pkix(ca), + ca_configure_profiles_acl(ca), ]) if ca_restart: -- 2.1.0 -------------- next part -------------- >From a9ff8cf670ce7c339c6a0edcea5047428fcb6595 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Thu, 30 Apr 2015 04:55:29 -0400 Subject: [PATCH 05/13] Add certprofile plugin Add the 'certprofile' plugin which defines the commands for managing certificate profiles and associated permissions. Also update Dogtag network code in 'ipapython.dogtag' to support headers and arbitrary request bodies, to facilitate use of the Dogtag profiles REST API. Part of: https://fedorahosted.org/freeipa/ticket/57 --- ACI.txt | 8 ++ API.txt | 62 +++++++++ install/updates/40-certprofile.update | 9 ++ install/updates/40-delegation.update | 8 ++ install/updates/Makefile.am | 1 + ipalib/constants.py | 1 + ipalib/plugins/certprofile.py | 253 ++++++++++++++++++++++++++++++++++ ipapython/dogtag.py | 29 ++-- ipaserver/plugins/dogtag.py | 176 ++++++++++++++++++++++- 9 files changed, 534 insertions(+), 13 deletions(-) create mode 100644 install/updates/40-certprofile.update create mode 100644 ipalib/plugins/certprofile.py diff --git a/ACI.txt b/ACI.txt index 3c4ebde5b3ac2eb0b8e9465c5f2bd74f5bdbfb01..035a545511e4f56dcb492c97514de59cfc028405 100644 --- a/ACI.txt +++ b/ACI.txt @@ -22,6 +22,14 @@ dn: cn=automount,dc=ipa,dc=example aci: (targetattr = "automountmapname || description")(targetfilter = "(objectclass=automountmap)")(version 3.0;acl "permission:System: Modify Automount Maps";allow (write) groupdn = "ldap:///cn=System: Modify Automount Maps,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: cn=automount,dc=ipa,dc=example aci: (targetfilter = "(objectclass=automountmap)")(version 3.0;acl "permission:System: Remove Automount Maps";allow (delete) groupdn = "ldap:///cn=System: Remove Automount Maps,cn=permissions,cn=pbac,dc=ipa,dc=example";) +dn: cn=certprofiles,cn=ca,dc=ipa,dc=example +aci: (targetfilter = "(objectclass=ipacertprofile)")(version 3.0;acl "permission:System: Delete Certificate Profile";allow (delete) groupdn = "ldap:///cn=System: Delete Certificate Profile,cn=permissions,cn=pbac,dc=ipa,dc=example";) +dn: cn=certprofiles,cn=ca,dc=ipa,dc=example +aci: (targetfilter = "(objectclass=ipacertprofile)")(version 3.0;acl "permission:System: Import Certificate Profile";allow (add) groupdn = "ldap:///cn=System: Import Certificate Profile,cn=permissions,cn=pbac,dc=ipa,dc=example";) +dn: cn=certprofiles,cn=ca,dc=ipa,dc=example +aci: (targetattr = "cn || description || ipacertprofilestoreissued")(targetfilter = "(objectclass=ipacertprofile)")(version 3.0;acl "permission:System: Modify Certificate Profile";allow (write) groupdn = "ldap:///cn=System: Modify Certificate Profile,cn=permissions,cn=pbac,dc=ipa,dc=example";) +dn: cn=certprofiles,cn=ca,dc=ipa,dc=example +aci: (targetattr = "cn || createtimestamp || description || entryusn || ipacertprofilestoreissued || modifytimestamp || objectclass")(targetfilter = "(objectclass=ipacertprofile)")(version 3.0;acl "permission:System: Read Certificate Profiles";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=ipaconfig,cn=etc,dc=ipa,dc=example aci: (targetattr = "cn || createtimestamp || entryusn || ipacertificatesubjectbase || ipaconfigstring || ipacustomfields || ipadefaultemaildomain || ipadefaultloginshell || ipadefaultprimarygroup || ipagroupobjectclasses || ipagroupsearchfields || ipahomesrootdir || ipakrbauthzdata || ipamaxusernamelength || ipamigrationenabled || ipapwdexpadvnotify || ipasearchrecordslimit || ipasearchtimelimit || ipaselinuxusermapdefault || ipaselinuxusermaporder || ipauserauthtype || ipauserobjectclasses || ipausersearchfields || modifytimestamp || objectclass")(targetfilter = "(objectclass=ipaguiconfig)")(version 3.0;acl "permission:System: Read Global Configuration";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=costemplates,cn=accounts,dc=ipa,dc=example diff --git a/API.txt b/API.txt index da69f32de5c12c0d85a7d61d9027385aa3c0ee05..7d221b839a7058e2bc7c6c95f7121e79a30ebcfd 100644 --- a/API.txt +++ b/API.txt @@ -509,6 +509,68 @@ args: 1,1,1 arg: Str('request_id') option: Str('version?', exclude='webui') output: Output('result', None, None) +command: certprofile_del +args: 1,2,3 +arg: Str('cn', attribute=True, cli_name='id', multivalue=True, 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', , None) +output: Output('summary', (, ), None) +output: ListOfPrimaryKeys('value', None, None) +command: certprofile_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='id', multivalue=False, primary_key=True, query=True, required=False) +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, query=True, required=False) +option: Bool('ipacertprofilestoreissued', attribute=True, autofill=False, cli_name='store', default=True, multivalue=False, query=True, required=False) +option: Flag('pkey_only?', autofill=True, default=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Int('sizelimit?', autofill=False, minvalue=0) +option: Int('timelimit?', autofill=False, minvalue=0) +option: Str('version?', exclude='webui') +output: Output('count', , None) +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('truncated', , None) +command: certprofile_import +args: 1,6,3 +arg: Str('cn', attribute=True, cli_name='id', multivalue=False, primary_key=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=True) +option: File('file', cli_name='file') +option: Bool('ipacertprofilestoreissued', attribute=True, cli_name='store', default=True, multivalue=False, required=True) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: certprofile_mod +args: 1,10,3 +arg: Str('cn', attribute=True, cli_name='id', multivalue=False, primary_key=True, query=True, required=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('delattr*', cli_name='delattr', exclude='webui') +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) +option: Bool('ipacertprofilestoreissued', attribute=True, autofill=False, cli_name='store', default=True, multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('rename', cli_name='rename', multivalue=False, primary_key=True, required=False) +option: Flag('rights', autofill=True, default=False) +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: certprofile_show +args: 1,4,3 +arg: Str('cn', attribute=True, cli_name='id', multivalue=False, primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) command: compat_is_enabled args: 0,1,1 option: Str('version?', exclude='webui') diff --git a/install/updates/40-certprofile.update b/install/updates/40-certprofile.update new file mode 100644 index 0000000000000000000000000000000000000000..6b0a81d0ff6d69dabe82138227d105fc780ee17d --- /dev/null +++ b/install/updates/40-certprofile.update @@ -0,0 +1,9 @@ +dn: cn=ca,$SUFFIX +default: objectClass: nsContainer +default: objectClass: top +default: cn: ca + +dn: cn=certprofiles,cn=ca,$SUFFIX +default: objectClass: nsContainer +default: objectClass: top +default: cn: certprofiles diff --git a/install/updates/40-delegation.update b/install/updates/40-delegation.update index 975929bd70400b2f9cf407d6faedb246003d7f58..bc0736c5b6c07747586a56c2cbde9596c7522d1c 100644 --- a/install/updates/40-delegation.update +++ b/install/updates/40-delegation.update @@ -237,3 +237,11 @@ default:ipapermissiontype: SYSTEM dn: cn=config add:aci: (version 3.0;acl "permission:Add Configuration Sub-Entries";allow (add) groupdn = "ldap:///cn=Add Configuration Sub-Entries,cn=permissions,cn=pbac,$SUFFIX";) + +# CA Administrators +dn: cn=CA Administrator,cn=privileges,cn=pbac,$SUFFIX +default:objectClass: nestedgroup +default:objectClass: groupofnames +default:objectClass: top +default:cn: CA Administrator +default:description: CA Administrator diff --git a/install/updates/Makefile.am b/install/updates/Makefile.am index 4e2da05d61a41543914e79c4634331df6018c041..fc6bd624eac619cdddeba29b85440571d85fd69f 100644 --- a/install/updates/Makefile.am +++ b/install/updates/Makefile.am @@ -32,6 +32,7 @@ app_DATA = \ 40-replication.update \ 40-dns.update \ 40-automember.update \ + 40-certprofile.update \ 40-otp.update \ 40-vault.update \ 45-roles.update \ diff --git a/ipalib/constants.py b/ipalib/constants.py index 95dec54a51f38ae63eba667daacf35dcd7500cf3..96396a236b8694b3dd988dfe28c1b0c3cc9e3180 100644 --- a/ipalib/constants.py +++ b/ipalib/constants.py @@ -118,6 +118,7 @@ DEFAULT_CONFIG = ( ('container_radiusproxy', DN(('cn', 'radiusproxy'))), ('container_views', DN(('cn', 'views'), ('cn', 'accounts'))), ('container_masters', DN(('cn', 'masters'), ('cn', 'ipa'), ('cn', 'etc'))), + ('container_certprofile', DN(('cn', 'certprofiles'), ('cn', 'ca'))), # Ports, hosts, and URIs: ('xmlrpc_uri', 'http://localhost:8888/ipa/xml'), diff --git a/ipalib/plugins/certprofile.py b/ipalib/plugins/certprofile.py new file mode 100644 index 0000000000000000000000000000000000000000..1a2d143882469858f225b37ba4ff2dd368fb8853 --- /dev/null +++ b/ipalib/plugins/certprofile.py @@ -0,0 +1,253 @@ +# +# Copyright (C) 2015 FreeIPA Contributors see COPYING for license +# + +import re + +from ipalib import api, Bool, File, Str +from ipalib import output +from ipalib.plugable import Registry +from ipalib.plugins.virtual import VirtualCommand +from ipalib.plugins.baseldap import ( + LDAPObject, LDAPSearch, LDAPCreate, + LDAPDelete, LDAPUpdate, LDAPRetrieve) +from ipalib import ngettext +from ipalib.text import _ + +from ipalib import errors + + +__doc__ = _(""" +Manage Certificate Profiles + +Certificate Profiles are used by Certificate Authority (CA) in the signing of +certificates to determine if a Certificate Signing Request (CSR) is acceptable, +and if so what features and extensions will be present on the certificate. + +The Certificate Profile format is the property-list format understood by the +Dogtag or Red Hat Certificate System CA. + +PROFILE ID SYNTAX: + +A Profile ID is a string without spaces or punctuation starting with a letter +and followed by a sequence of letters, digits or underscore ("_"). + +EXAMPLES: + + Import a profile that will not store issued certificates: + ipa certprofile-import ShortLivedUserCert \\ + --file UserCert.profile --summary "User Certificates" \\ + --store=false + + Delete a certificate profile: + ipa certprofile-del ShortLivedUserCert + + Show information about a profile: + ipa certprofile-show ShortLivedUserCert + + Search for profiles that do not store certificates: + ipa certprofile-find --store=false + +""") + + +register = Registry() + + +def ca_enabled_check(): + """Raise NotFound if CA is not enabled. + + This function is defined in multiple plugins to avoid circular imports + (cert depends on certprofile, so we cannot import cert here). + + """ + if not api.Command.ca_is_enabled()['result']: + raise errors.NotFound(reason=_('CA is not configured')) + + +profile_id_pattern = re.compile('^[a-zA-Z]\w*$') + + +def validate_profile_id(ugettext, value): + """Ensure profile ID matches form required by CA.""" + if profile_id_pattern.match(value) is None: + return _('invalid Profile ID') + else: + return None + + + at register() +class certprofile(LDAPObject): + """ + Certificate Profile object. + """ + container_dn = api.env.container_certprofile + object_name = _('Certificate Profile') + object_name_plural = _('Certificate Profiles') + object_class = ['ipacertprofile'] + default_attributes = [ + 'cn', 'description', 'ipacertprofilestoreissued' + ] + search_attributes = [ + 'cn', 'description', 'ipacertprofilestoreissued' + ] + rdn_is_primary_key = True + label = _('Certificate Profiles') + label_singular = _('Certificate Profile') + + takes_params = ( + Str('cn', validate_profile_id, + primary_key=True, + cli_name='id', + label=_('Profile ID'), + doc=_('Profile ID for referring to this profile'), + ), + Str('description', + required=True, + cli_name='desc', + label=_('Profile description'), + doc=_('Brief description of this profile'), + ), + Bool('ipacertprofilestoreissued', + default=True, + cli_name='store', + label=_('Store issued certificates'), + doc=_('Whether to store certs issued using this profile'), + ), + ) + + permission_filter_objectclasses = ['ipacertprofile'] + managed_permissions = { + 'System: Read Certificate Profiles': { + 'replaces_global_anonymous_aci': True, + 'ipapermbindruletype': 'all', + 'ipapermright': {'read', 'search', 'compare'}, + 'ipapermdefaultattr': { + 'cn', + 'description', + 'ipacertprofilestoreissued', + 'objectclass', + }, + }, + 'System: Import Certificate Profile': { + 'ipapermright': {'add'}, + 'replaces': [ + '(target = "ldap:///cn=*,cn=certprofiles,cn=ca,$SUFFIX")(version 3.0;acl "permission:Import Certificate Profile";allow (add) groupdn = "ldap:///cn=Import Certificate Profile,cn=permissions,cn=pbac,$SUFFIX";)', + ], + 'default_privileges': {'CA Administrator'}, + }, + 'System: Delete Certificate Profile': { + 'ipapermright': {'delete'}, + 'replaces': [ + '(target = "ldap:///cn=*,cn=certprofiles,cn=ca,$SUFFIX")(version 3.0;acl "permission:Delete Certificate Profile";allow (delete) groupdn = "ldap:///cn=Delete Certificate Profile,cn=permissions,cn=pbac,$SUFFIX";)', + ], + 'default_privileges': {'CA Administrator'}, + }, + 'System: Modify Certificate Profile': { + 'ipapermright': {'write'}, + 'ipapermdefaultattr': { + 'cn', + 'description', + 'ipacertprofilestoreissued', + }, + 'replaces': [ + '(targetattr = "cn || description || ipacertprofilestoreissued")(target = "ldap:///cn=*,cn=certprofiles,cn=ca,$SUFFIX")(version 3.0;acl "permission:Modify Certificate Profile";allow (write) groupdn = "ldap:///cn=Modify Certificate Profile,cn=permissions,cn=pbac,$SUFFIX";)', + ], + 'default_privileges': {'CA Administrator'}, + }, + } + + + + at register() +class certprofile_find(LDAPSearch): + __doc__ = _("Search for Certificate Profiles.") + msg_summary = ngettext( + '%(count)d profile matched', '%(count)d profiles matched', 0 + ) + + def execute(self, *args, **kwargs): + ca_enabled_check() + return super(certprofile_find, self).execute(*args, **kwargs) + + + at register() +class certprofile_show(LDAPRetrieve): + __doc__ = _("Display the properties of a Certificate Profile.") + + def execute(self, *args, **kwargs): + ca_enabled_check() + return super(certprofile_show, self).execute(*args, **kwargs) + + + at register() +class certprofile_import(LDAPCreate): + __doc__ = _("Import a Certificate Profile.") + msg_summary = _('Imported profile "%(value)s"') + takes_options = ( + File('file', + label=_('Filename'), + cli_name='file', + flags=('virtual_attribute',), + ), + ) + + PROFILE_ID_PATTERN = re.compile('^profileId=([a-zA-Z]\w*)', re.MULTILINE) + + def pre_callback(self, ldap, dn, entry, entry_attrs, *keys, **options): + ca_enabled_check() + + match = self.PROFILE_ID_PATTERN.search(options['file']) + if match is None: + raise errors.ValidationError(name='file', + error=_("Profile ID is not present in profile data")) + elif keys[0] != match.group(1): + raise errors.ValidationError(name='file', + error=_("Profile ID '%(cli_value)s' does not match profile data '%(file_value)s'") + % {'cli_value': keys[0], 'file_value': match.group(1)} + ) + return dn + + + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + """Import the profile into Dogtag and enable it. + + If the operation succeeds, update the LDAP entry to 'enabled'. + If the operation fails, remove the LDAP entry. + """ + try: + with self.api.Backend.ra_certprofile as profile_api: + profile_api.create_profile(options['file']) + profile_api.enable_profile(keys[0]) + except: + # something went wrong ; delete entry + ldap.delete_entry(dn) + raise + + return dn + + + at register() +class certprofile_del(LDAPDelete): + __doc__ = _("Delete a Certificate Profile.") + msg_summary = _('Deleted profile "%(value)s"') + + def execute(self, *args, **kwargs): + ca_enabled_check() + return super(certprofile_del, self).execute(*args, **kwargs) + + def post_callback(self, ldap, dn, *keys, **options): + with self.api.Backend.ra_certprofile as profile_api: + profile_api.disable_profile(keys[0]) + profile_api.delete_profile(keys[0]) + return dn + + + at register() +class certprofile_mod(LDAPUpdate): + __doc__ = _("Modify Certificate Profile configuration.") + msg_summary = _('Modified Certificate Profile "%(value)s') + + def execute(self, *args, **kwargs): + ca_enabled_check() + return super(certprofile_mod, self).execute(*args, **kwargs) diff --git a/ipapython/dogtag.py b/ipapython/dogtag.py index c74b8736a4b15f7bf081206b52b9876a8c4928af..11311cf7b55d7b84e9434a698dbfd60b0eb142a1 100644 --- a/ipapython/dogtag.py +++ b/ipapython/dogtag.py @@ -233,9 +233,12 @@ def ca_status(ca_host=None, use_proxy=True): return _parse_ca_status(body) -def https_request(host, port, url, secdir, password, nickname, **kw): +def https_request(host, port, url, secdir, password, nickname, + method='POST', headers=None, body=None, **kw): """ + :param method: HTTP request method (defalut: 'POST') :param url: The path (not complete URL!) to post to. + :param body: The request body (encodes kw if None) :param kw: Keyword arguments to encode into POST body. :return: (http_status, http_reason_phrase, http_headers, http_body) as (integer, unicode, dict, str) @@ -254,9 +257,11 @@ def https_request(host, port, url, secdir, password, nickname, **kw): nickname, password, nss.get_default_certdb()) return conn - body = urlencode(kw) + if body is None: + body = urlencode(kw) return _httplib_request( - 'https', host, port, url, connection_factory, body) + 'https', host, port, url, connection_factory, body, + method=method, headers=headers) def http_request(host, port, url, **kw): @@ -288,11 +293,13 @@ def unauthenticated_https_request(host, port, url, **kw): def _httplib_request( - protocol, host, port, path, connection_factory, request_body): + protocol, host, port, path, connection_factory, request_body, + method='POST', headers=None): """ :param request_body: Request body :param connection_factory: Connection class to use. Will be called with the host and port arguments. + :param method: HTTP request method (default: 'POST') Perform a HTTP(s) request. """ @@ -301,13 +308,17 @@ def _httplib_request( uri = '%s://%s%s' % (protocol, ipautil.format_netloc(host, port), path) root_logger.debug('request %r', uri) root_logger.debug('request body %r', request_body) + + headers = headers or {} + if ( + method == 'POST' + and 'content-type' not in (str(k).lower() for k in headers.viewkeys()) + ): + headers['content-type'] = 'application/x-www-form-urlencoded' + try: conn = connection_factory(host, port) - conn.request( - 'POST', uri, - body=request_body, - headers={'Content-type': 'application/x-www-form-urlencoded'}, - ) + conn.request(method, uri, body=request_body, headers=headers) res = conn.getresponse() http_status = res.status diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py index 52bdb0d4245594785e718c63242e27cee0e59322..9654123b16d8e417398d49bf1305fd41880bc3a7 100644 --- a/ipaserver/plugins/dogtag.py +++ b/ipaserver/plugins/dogtag.py @@ -4,8 +4,9 @@ # Jason Gerard DeRose # Rob Crittenden # John Dennis +# Fraser Tweedale # -# Copyright (C) 2014 Red Hat +# Copyright (C) 2014, 2015 Red Hat # see file 'COPYING' for use and warranty information # # This program is free software; you can redistribute it and/or modify @@ -238,17 +239,21 @@ digits and nothing else follows. ''' import datetime +import json from lxml import etree +import os import tempfile import time import urllib2 +import pki from pki.client import PKIConnection import pki.crypto as cryptoutil from pki.kra import KRAClient from ipalib import Backend from ipapython.dn import DN +import ipapython.cookie import ipapython.dogtag from ipapython import ipautil from ipaserver.install.certs import CertDB @@ -1262,13 +1267,12 @@ def select_any_master(ldap2, service='CA'): #------------------------------------------------------------------------------- -from ipalib import api, SkipPluginModule +from ipalib import api, errors, SkipPluginModule if api.env.ra_plugin != 'dogtag': # In this case, abort loading this plugin module... raise SkipPluginModule(reason='dogtag not selected as RA plugin') import os, random from ipaserver.plugins import rabase -from ipalib.errors import CertificateOperationError from ipalib.constants import TYPE_ERROR from ipalib.util import cachedproperty from ipapython import dogtag @@ -1318,7 +1322,7 @@ class ra(rabase.rabase): err_msg = u'%s (%s)' % (err_msg, detail) self.error('%s.%s(): %s', self.fullname, func_name, err_msg) - raise CertificateOperationError(error=err_msg) + raise errors.CertificateOperationError(error=err_msg) @cachedproperty def ca_host(self): @@ -1923,3 +1927,167 @@ class kra(Backend): return KRAClient(connection, crypto) api.register(kra) + + +class RestClient(Backend): + """Simple Dogtag REST client to be subclassed by other backends. + + This class is a context manager. Authenticated calls must be + executed in a ``with`` suite:: + + class ra_certprofile(RestClient): + path = 'profile' + ... + + api.register(ra_certprofile) + + with api.Backend.ra_certprofile as profile_api: + # REST client is now logged in + profile_api.create_profile(...) + + """ + path = None + + @staticmethod + def _parse_dogtag_error(body): + try: + return pki.PKIException.from_json(json.loads(body)) + except: + return None + + def __init__(self): + if api.env.in_tree: + self.sec_dir = api.env.dot_ipa + os.sep + 'alias' + self.pwd_file = self.sec_dir + os.sep + '.pwd' + else: + self.sec_dir = paths.HTTPD_ALIAS_DIR + self.pwd_file = paths.ALIAS_PWDFILE_TXT + self.noise_file = self.sec_dir + os.sep + '.noise' + self.ipa_key_size = "2048" + self.ipa_certificate_nickname = "ipaCert" + self.ca_certificate_nickname = "caCert" + try: + f = open(self.pwd_file, "r") + self.password = f.readline().strip() + f.close() + except IOError: + self.password = '' + super(RestClient, self).__init__() + + # session cookie + self.cookie = None + + @cachedproperty + def ca_host(self): + """ + :return: host + as str + + Select our CA host. + """ + ldap2 = self.api.Backend.ldap2 + if host_has_service(api.env.ca_host, ldap2, "CA"): + return api.env.ca_host + if api.env.host != api.env.ca_host: + if host_has_service(api.env.host, ldap2, "CA"): + return api.env.host + host = select_any_master(ldap2) + if host: + return host + else: + return api.env.ca_host + + def __enter__(self): + """Log into the REST API""" + if self.cookie is not None: + return + status, status_text, resp_headers, resp_body = dogtag.https_request( + self.ca_host, self.env.ca_agent_port, '/ca/rest/account/login', + self.sec_dir, self.password, self.ipa_certificate_nickname, + method='GET' + ) + cookies = ipapython.cookie.Cookie.parse(resp_headers.get('set-cookie', '')) + if status != 200 or len(cookies) == 0: + raise errors.RemoteRetrieveError(reason=_('Failed to authenticate to CA REST API')) + self.cookie = str(cookies[0]) + return self + + def __exit__(self, exc_type, exc_value, traceback): + """Log out of the REST API""" + dogtag.https_request( + self.ca_host, self.env.ca_agent_port, '/ca/rest/account/logout', + self.sec_dir, self.password, self.ipa_certificate_nickname, + method='GET' + ) + self.cookie = None + + def _ssldo(self, method, path, headers=None, body=None): + """ + :param url: The URL to post to. + :param kw: Keyword arguments to encode into POST body. + :return: (http_status, http_reason_phrase, http_headers, http_body) + as (integer, unicode, dict, str) + + Perform an HTTPS request + """ + if self.cookie is None: + raise errors.RemoteRetrieveError( + reason=_("REST API is not logged in.")) + + headers = headers or {} + headers['Cookie'] = self.cookie + + resource = os.path.join('/ca/rest', self.path, path) + + # perform main request + status, status_text, resp_headers, resp_body = dogtag.https_request( + self.ca_host, self.env.ca_agent_port, resource, + self.sec_dir, self.password, self.ipa_certificate_nickname, + method=method, headers=headers, body=body + ) + if status < 200 or status >= 300: + explanation = self._parse_dogtag_error(resp_body) or '' + raise errors.RemoteRetrieveError( + reason=_('Non-2xx response from CA REST API: %(status)d %(status_text)s. %(explanation)s') + % {'status': status, 'status_text': status_text, 'explanation': explanation} + ) + return (status, status_text, resp_headers, resp_body) + + +class ra_certprofile(RestClient): + """ + Profile management backend plugin. + """ + path = 'profiles' + + def create_profile(self, profile_data): + """ + Import the profile into Dogtag + """ + self._ssldo('POST', 'raw', + headers={ + 'Content-type': 'application/xml', + 'Accept': 'application/json', + }, + body=profile_data + ) + + def enable_profile(self, profile_id): + """ + Enable the profile in Dogtag + """ + self._ssldo('POST', profile_id + '?action=enable') + + def disable_profile(self, profile_id): + """ + Enable the profile in Dogtag + """ + self._ssldo('POST', profile_id + '?action=disable') + + def delete_profile(self, profile_id): + """ + Delete the profile from Dogtag + """ + self._ssldo('DELETE', profile_id, headers={'Accept': 'application/json'}) + +api.register(ra_certprofile) -- 2.1.0 -------------- next part -------------- >From fc4d8d4b7b7c2ab9a4c58ea243daf1ddaf337893 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 11 May 2015 23:38:41 -0400 Subject: [PATCH 06/13] Enable LDAP-based profiles in CA on upgrade Part of: https://fedorahosted.org/freeipa/ticket/4560 --- ipaserver/install/server.py | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/ipaserver/install/server.py b/ipaserver/install/server.py index 7bfcb48ea48c0eb108055321d9a00b14ffbfe790..52d68877c64245b683bf5b310eff637e412cd146 100644 --- a/ipaserver/install/server.py +++ b/ipaserver/install/server.py @@ -294,6 +294,45 @@ def ca_configure_profiles_acl(ca): return cainstance.configure_profiles_acl() +def ca_enable_ldap_profile_subsystem(ca): + root_logger.info('[Ensuring CA is using LDAPProfileSubsystem]') + if not ca.is_configured(): + root_logger.info('CA is not configured') + return False + + caconfig = dogtag.configured_constants() + + needs_update = False + directive = None + try: + for i in range(15): + directive = "subsystem.{}.class".format(i) + value = installutils.get_directive( + caconfig.CS_CFG_PATH, + directive, + separator='=') + if value == 'ProfileSubsystem': + needs_update = True + break + except OSError, e: + root_logger.error('Cannot read CA configuration file "%s": %s', + caconfig.CS_CFG_PATH, e) + return False + + if needs_update: + installutils.set_directive( + caconfig.CS_CFG_PATH, + directive, + 'LDAPProfileSubsystem', + quotes=False, + separator='=') + + # TODO import file-based profiles into Dogtag + # More code needed on Dogtag side for this. + + return needs_update + + def upgrade_ipa_profile(ca, domain, fqdn): """ Update the IPA Profile provided by dogtag @@ -1375,6 +1414,7 @@ def upgrade_configuration(): certificate_renewal_update(ca), ca_enable_pkix(ca), ca_configure_profiles_acl(ca), + ca_enable_ldap_profile_subsystem(ca), ]) if ca_restart: -- 2.1.0 -------------- next part -------------- >From adfb0d3e3dc790f693f2b72fb2f27a29801fa0ee Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 11 May 2015 21:17:48 -0400 Subject: [PATCH 07/13] Import included profiles during install or upgrade Add a default service profile template as part of FreeIPA and format and import it as part of installation or upgrade process. Also remove the code that modifies the old (file-based) `caIPAserviceCert' profile. Fixes https://fedorahosted.org/freeipa/ticket/4002 --- freeipa.spec.in | 2 + install/configure.ac | 1 + install/share/Makefile.am | 1 + install/share/profiles/Makefile.am | 14 ++ install/share/profiles/caIPAserviceCert.cfg | 109 ++++++++++++ install/tools/ipa-server-install | 6 + install/tools/ipa-upgradeconfig | 1 - ipapython/dogtag.py | 7 +- ipaserver/install/cainstance.py | 253 +++++++--------------------- ipaserver/install/ipa_server_upgrade.py | 1 + ipaserver/install/server.py | 42 ++--- ipaserver/plugins/dogtag.py | 14 +- 12 files changed, 228 insertions(+), 223 deletions(-) create mode 100644 install/share/profiles/Makefile.am create mode 100644 install/share/profiles/caIPAserviceCert.cfg diff --git a/freeipa.spec.in b/freeipa.spec.in index 7dc576256865fb04b3f322b2094a5e3ece7776a5..23459a5ee78c4f65242d1ebeaca72a6f8de7d535 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -719,6 +719,8 @@ fi %dir %{_usr}/share/ipa/advise %dir %{_usr}/share/ipa/advise/legacy %{_usr}/share/ipa/advise/legacy/*.template +%dir %{_usr}/share/ipa/profiles +%{_usr}/share/ipa/profiles/*.cfg %dir %{_usr}/share/ipa/ffextension %{_usr}/share/ipa/ffextension/bootstrap.js %{_usr}/share/ipa/ffextension/install.rdf diff --git a/install/configure.ac b/install/configure.ac index 2e48aa5cc67b30f2582de987a12d4e7043256679..57f4219b66bbe1dadaed3e89c3e84b1c8240399e 100644 --- a/install/configure.ac +++ b/install/configure.ac @@ -88,6 +88,7 @@ AC_CONFIG_FILES([ share/Makefile share/advise/Makefile share/advise/legacy/Makefile + share/profiles/Makefile ui/Makefile ui/css/Makefile ui/src/Makefile diff --git a/install/share/Makefile.am b/install/share/Makefile.am index f44772b20c173c6fe43503716f40454f6f6b6f11..31f391be25c58b76cc71971852074d80c5514745 100644 --- a/install/share/Makefile.am +++ b/install/share/Makefile.am @@ -2,6 +2,7 @@ NULL = SUBDIRS = \ advise \ + profiles \ $(NULL) appdir = $(IPA_DATA_DIR) diff --git a/install/share/profiles/Makefile.am b/install/share/profiles/Makefile.am new file mode 100644 index 0000000000000000000000000000000000000000..4e6cf975a0f51d02ec29bd07ac8cb9ccc8320818 --- /dev/null +++ b/install/share/profiles/Makefile.am @@ -0,0 +1,14 @@ +NULL = + +appdir = $(IPA_DATA_DIR)/profiles +app_DATA = \ + caIPAserviceCert.cfg \ + $(NULL) + +EXTRA_DIST = \ + $(app_DATA) \ + $(NULL) + +MAINTAINERCLEANFILES = \ + *~ \ + Makefile.in diff --git a/install/share/profiles/caIPAserviceCert.cfg b/install/share/profiles/caIPAserviceCert.cfg new file mode 100644 index 0000000000000000000000000000000000000000..6c5102f0dbd6bd6c6eaf2fa22e87ed4a5f34553c --- /dev/null +++ b/install/share/profiles/caIPAserviceCert.cfg @@ -0,0 +1,109 @@ +profileId=caIPAserviceCert +classId=caEnrollImpl +desc=This certificate profile is for enrolling server certificates with IPA-RA agent authentication. +visible=false +enable=true +enableBy=admin +auth.instance_id=raCertAuth +name=IPA-RA Agent-Authenticated Server Certificate Enrollment +input.list=i1,i2 +input.i1.class_id=certReqInputImpl +input.i2.class_id=submitterInfoInputImpl +output.list=o1 +output.o1.class_id=certOutputImpl +policyset.list=serverCertSet +policyset.serverCertSet.list=1,2,3,4,5,6,7,8,9,10,11 +policyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl +policyset.serverCertSet.1.constraint.name=Subject Name Constraint +policyset.serverCertSet.1.constraint.params.pattern=CN=[^,]+,.+ +policyset.serverCertSet.1.constraint.params.accept=true +policyset.serverCertSet.1.default.class_id=subjectNameDefaultImpl +policyset.serverCertSet.1.default.name=Subject Name Default +policyset.serverCertSet.1.default.params.name=CN=$$request.req_subject_name.cn$$, $SUBJECT_DN_O +policyset.serverCertSet.2.constraint.class_id=validityConstraintImpl +policyset.serverCertSet.2.constraint.name=Validity Constraint +policyset.serverCertSet.2.constraint.params.range=740 +policyset.serverCertSet.2.constraint.params.notBeforeCheck=false +policyset.serverCertSet.2.constraint.params.notAfterCheck=false +policyset.serverCertSet.2.default.class_id=validityDefaultImpl +policyset.serverCertSet.2.default.name=Validity Default +policyset.serverCertSet.2.default.params.range=731 +policyset.serverCertSet.2.default.params.startTime=0 +policyset.serverCertSet.3.constraint.class_id=keyConstraintImpl +policyset.serverCertSet.3.constraint.name=Key Constraint +policyset.serverCertSet.3.constraint.params.keyType=RSA +policyset.serverCertSet.3.constraint.params.keyParameters=1024,2048,3072,4096 +policyset.serverCertSet.3.default.class_id=userKeyDefaultImpl +policyset.serverCertSet.3.default.name=Key Default +policyset.serverCertSet.4.constraint.class_id=noConstraintImpl +policyset.serverCertSet.4.constraint.name=No Constraint +policyset.serverCertSet.4.default.class_id=authorityKeyIdentifierExtDefaultImpl +policyset.serverCertSet.4.default.name=Authority Key Identifier Default +policyset.serverCertSet.5.constraint.class_id=noConstraintImpl +policyset.serverCertSet.5.constraint.name=No Constraint +policyset.serverCertSet.5.default.class_id=authInfoAccessExtDefaultImpl +policyset.serverCertSet.5.default.name=AIA Extension Default +policyset.serverCertSet.5.default.params.authInfoAccessADEnable_0=true +policyset.serverCertSet.5.default.params.authInfoAccessADLocationType_0=URIName +policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0=http://$IPA_CA_RECORD.$DOMAIN/ca/ocsp +policyset.serverCertSet.5.default.params.authInfoAccessADMethod_0=1.3.6.1.5.5.7.48.1 +policyset.serverCertSet.5.default.params.authInfoAccessCritical=false +policyset.serverCertSet.5.default.params.authInfoAccessNumADs=1 +policyset.serverCertSet.6.constraint.class_id=keyUsageExtConstraintImpl +policyset.serverCertSet.6.constraint.name=Key Usage Extension Constraint +policyset.serverCertSet.6.constraint.params.keyUsageCritical=true +policyset.serverCertSet.6.constraint.params.keyUsageDigitalSignature=true +policyset.serverCertSet.6.constraint.params.keyUsageNonRepudiation=true +policyset.serverCertSet.6.constraint.params.keyUsageDataEncipherment=true +policyset.serverCertSet.6.constraint.params.keyUsageKeyEncipherment=true +policyset.serverCertSet.6.constraint.params.keyUsageKeyAgreement=false +policyset.serverCertSet.6.constraint.params.keyUsageKeyCertSign=false +policyset.serverCertSet.6.constraint.params.keyUsageCrlSign=false +policyset.serverCertSet.6.constraint.params.keyUsageEncipherOnly=false +policyset.serverCertSet.6.constraint.params.keyUsageDecipherOnly=false +policyset.serverCertSet.6.default.class_id=keyUsageExtDefaultImpl +policyset.serverCertSet.6.default.name=Key Usage Default +policyset.serverCertSet.6.default.params.keyUsageCritical=true +policyset.serverCertSet.6.default.params.keyUsageDigitalSignature=true +policyset.serverCertSet.6.default.params.keyUsageNonRepudiation=true +policyset.serverCertSet.6.default.params.keyUsageDataEncipherment=true +policyset.serverCertSet.6.default.params.keyUsageKeyEncipherment=true +policyset.serverCertSet.6.default.params.keyUsageKeyAgreement=false +policyset.serverCertSet.6.default.params.keyUsageKeyCertSign=false +policyset.serverCertSet.6.default.params.keyUsageCrlSign=false +policyset.serverCertSet.6.default.params.keyUsageEncipherOnly=false +policyset.serverCertSet.6.default.params.keyUsageDecipherOnly=false +policyset.serverCertSet.7.constraint.class_id=noConstraintImpl +policyset.serverCertSet.7.constraint.name=No Constraint +policyset.serverCertSet.7.default.class_id=extendedKeyUsageExtDefaultImpl +policyset.serverCertSet.7.default.name=Extended Key Usage Extension Default +policyset.serverCertSet.7.default.params.exKeyUsageCritical=false +policyset.serverCertSet.7.default.params.exKeyUsageOIDs=1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 +policyset.serverCertSet.8.constraint.class_id=signingAlgConstraintImpl +policyset.serverCertSet.8.constraint.name=No Constraint +policyset.serverCertSet.8.constraint.params.signingAlgsAllowed=SHA1withRSA,SHA256withRSA,SHA512withRSA,MD5withRSA,MD2withRSA,SHA1withDSA,SHA1withEC,SHA256withEC,SHA384withEC,SHA512withEC +policyset.serverCertSet.8.default.class_id=signingAlgDefaultImpl +policyset.serverCertSet.8.default.name=Signing Alg +policyset.serverCertSet.8.default.params.signingAlg=- +policyset.serverCertSet.9.constraint.class_id=noConstraintImpl +policyset.serverCertSet.9.constraint.name=No Constraint +policyset.serverCertSet.9.default.class_id=crlDistributionPointsExtDefaultImpl +policyset.serverCertSet.9.default.name=CRL Distribution Points Extension Default +policyset.serverCertSet.9.default.params.crlDistPointsCritical=false +policyset.serverCertSet.9.default.params.crlDistPointsNum=1 +policyset.serverCertSet.9.default.params.crlDistPointsEnable_0=true +policyset.serverCertSet.9.default.params.crlDistPointsIssuerName_0=$CRL_ISSUER +policyset.serverCertSet.9.default.params.crlDistPointsIssuerType_0=DirectoryName +policyset.serverCertSet.9.default.params.crlDistPointsPointName_0=http://$IPA_CA_RECORD.$DOMAIN/ipa/crl/MasterCRL.bin +policyset.serverCertSet.9.default.params.crlDistPointsPointType_0=URIName +policyset.serverCertSet.9.default.params.crlDistPointsReasons_0= +policyset.serverCertSet.10.constraint.class_id=noConstraintImpl +policyset.serverCertSet.10.constraint.name=No Constraint +policyset.serverCertSet.10.default.class_id=subjectKeyIdentifierExtDefaultImpl +policyset.serverCertSet.10.default.name=Subject Key Identifier Extension Default +policyset.serverCertSet.10.default.params.critical=false +policyset.serverCertSet.11.constraint.class_id=noConstraintImpl +policyset.serverCertSet.11.constraint.name=No Constraint +policyset.serverCertSet.11.default.class_id=userExtensionDefaultImpl +policyset.serverCertSet.11.default.name=User Supplied Extension Default +policyset.serverCertSet.11.default.params.userExtOID=2.5.29.17 diff --git a/install/tools/ipa-server-install b/install/tools/ipa-server-install index c7d7c7bff7d5a5e818eaa4a8cb93be94eae7d0c1..b0fc86521ef52c110d2f3860d9c24d0065f13756 100755 --- a/install/tools/ipa-server-install +++ b/install/tools/ipa-server-install @@ -1139,6 +1139,9 @@ def main(): api.env.ca_host = host_name api.bootstrap(**cfg) + if setup_ca: + # ensure profile backend is available + import ipaserver.plugins.dogtag api.finalize() # Create DS user/group if it doesn't exist yet @@ -1291,6 +1294,9 @@ def main(): service.print_msg("Restarting the certificate server") ca.restart(dogtag.configured_constants().PKI_INSTANCE_NAME) + service.print_msg("Importing certificate profiles") + cainstance.import_included_profiles() + if options.setup_dns: api.Backend.ldap2.connect(autobind=True) dns_installer.install(False, False, options) diff --git a/install/tools/ipa-upgradeconfig b/install/tools/ipa-upgradeconfig index 43292966a29c9077443913bdda1c81aa3de06a10..5f3a2b4a2f3864c2809178815c244c2012333fc8 100755 --- a/install/tools/ipa-upgradeconfig +++ b/install/tools/ipa-upgradeconfig @@ -21,7 +21,6 @@ import sys - if __name__ == '__main__': sys.exit("Please run the 'ipa-server-upgrade' command to upgrade the " "IPA server.") diff --git a/ipapython/dogtag.py b/ipapython/dogtag.py index 11311cf7b55d7b84e9434a698dbfd60b0eb142a1..2b4d233354b974884c88d13a3a1b437915ba0776 100644 --- a/ipapython/dogtag.py +++ b/ipapython/dogtag.py @@ -42,6 +42,11 @@ from ipapython.ipa_log_manager import * # the configured version. +INCLUDED_PROFILES = { + # ( profile_id , description , store_issued) + (u'caIPAserviceCert', u'Standard profile for network services', True), + } + class Dogtag10Constants(object): DOGTAG_VERSION = 10 UNSECURE_PORT = 8080 @@ -71,7 +76,6 @@ class Dogtag10Constants(object): RACERT_LINE_SEP = '\n' - IPA_SERVICE_PROFILE = '%s/caIPAserviceCert.cfg' % SERVICE_PROFILE_DIR SIGN_PROFILE = '%s/caJarSigningCert.cfg' % SERVICE_PROFILE_DIR SHARED_DB = True DS_USER = "dirsrv" @@ -110,7 +114,6 @@ class Dogtag9Constants(object): EE_CLIENT_AUTH_PORT = 9446 TOMCAT_SERVER_PORT = 9701 - IPA_SERVICE_PROFILE = '%s/caIPAserviceCert.cfg' % SERVICE_PROFILE_DIR SIGN_PROFILE = '%s/caJarSigningCert.cfg' % SERVICE_PROFILE_DIR SHARED_DB = False DS_USER = "pkisrv" diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index 871581b4afc5df854b9a090ef51bb0ad3b3871ee..ca0b6df5db80bc842a78f614872831ddd82330b1 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -459,10 +459,6 @@ class CAInstance(DogtagInstance): self.step("importing CA chain to RA certificate database", self.__import_ca_chain) self.step("fixing RA database permissions", self.fix_ra_perms) self.step("setting up signing cert profile", self.__setup_sign_profile) - self.step("set certificate subject base", self.__set_subject_in_config) - self.step("enabling Subject Key Identifier", self.enable_subject_key_identifier) - self.step("enabling Subject Alternative Name", self.enable_subject_alternative_name) - self.step("enabling CRL and OCSP extensions for certificates", self.__set_crl_ocsp_extensions) self.step("setting audit signing renewal to 2 years", self.set_audit_renewal) if not self.clone: self.step("restarting certificate server", self.restart_instance) @@ -1125,94 +1121,6 @@ class CAInstance(DogtagInstance): return publishdir - def __set_crl_ocsp_extensions(self): - self.set_crl_ocsp_extensions(self.domain, self.fqdn) - - def set_crl_ocsp_extensions(self, domain, fqdn): - """ - Configure CRL and OCSP extensions in default IPA certificate profile - if not done already. - """ - changed = False - - # OCSP extension - ocsp_url = 'http://%s.%s/ca/ocsp' % (IPA_CA_RECORD, ipautil.format_netloc(domain)) - - ocsp_location_0 = installutils.get_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0', - separator='=') - - if ocsp_location_0 != ocsp_url: - # Set the first OCSP URI - installutils.set_directive(self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0', - ocsp_url, quotes=False, separator='=') - changed = True - - ocsp_profile_count = installutils.get_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.5.default.params.authInfoAccessNumADs', - separator='=') - - if ocsp_profile_count != '1': - installutils.set_directive(self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.5.default.params.authInfoAccessNumADs', - '1', quotes=False, separator='=') - changed = True - - - # CRL extension - crl_url = 'http://%s.%s/ipa/crl/MasterCRL.bin'% (IPA_CA_RECORD, ipautil.format_netloc(domain)) - - crl_point_0 = installutils.get_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.9.default.params.crlDistPointsPointName_0', - separator='=') - - if crl_point_0 != crl_url: - installutils.set_directive(self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.9.default.params.crlDistPointsIssuerName_0', - 'CN=Certificate Authority,o=ipaca', quotes=False, separator='=') - installutils.set_directive(self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.9.default.params.crlDistPointsIssuerType_0', - 'DirectoryName', quotes=False, separator='=') - installutils.set_directive(self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.9.default.params.crlDistPointsPointName_0', - crl_url, quotes=False, separator='=') - changed = True - - crl_profile_count = installutils.get_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.9.default.params.crlDistPointsNum', - separator='=') - - if crl_profile_count != '1': - installutils.set_directive(self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.9.default.params.crlDistPointsNum', - '1', quotes=False, separator='=') - changed = True - - # CRL extension is not enabled by default - setlist = installutils.get_directive(self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.list', separator='=') - new_set_list = None - - if setlist == '1,2,3,4,5,6,7,8': - new_set_list = '1,2,3,4,5,6,7,8,9' - elif setlist == '1,2,3,4,5,6,7,8,10': - new_set_list = '1,2,3,4,5,6,7,8,9,10' - elif setlist == '1,2,3,4,5,6,7,8,10,11': - new_set_list = '1,2,3,4,5,6,7,8,9,10,11' - - if new_set_list: - installutils.set_directive(self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.list', - new_set_list, quotes=False, separator='=') - changed = True - - return changed - def __enable_crl_publish(self): """ @@ -1267,13 +1175,6 @@ class CAInstance(DogtagInstance): installutils.set_directive(caconfig, 'ca.crl.MasterCRL.enableCRLUpdates', 'false', quotes=False, separator='=') installutils.set_directive(caconfig, 'ca.listenToCloneModifications', 'false', quotes=False, separator='=') - def __set_subject_in_config(self): - # dogtag ships with an IPA-specific profile that forces a subject - # format. We need to update that template with our base subject - if installutils.update_file(self.dogtag_constants.IPA_SERVICE_PROFILE, - 'OU=pki-ipa, O=IPA', str(self.subject_base)): - print "Updating subject_base in CA template failed" - def uninstall(self): # just eat state self.restore_state("enabled") @@ -1407,100 +1308,6 @@ class CAInstance(DogtagInstance): services.knownservices.certmonger.stop() - def enable_subject_key_identifier(self): - """ - See if Subject Key Identifier is set in the profile and if not, add it. - """ - setlist = installutils.get_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.list', separator='=') - - # this is the default setting from pki-ca/pki-tomcat. Don't touch it - # if a user has manually modified it. - if setlist == '1,2,3,4,5,6,7,8' or setlist == '1,2,3,4,5,6,7,8,9': - setlist += ',10' - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.list', - setlist, - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.10.constraint.class_id', - 'noConstraintImpl', - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.10.constraint.name', - 'No Constraint', - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.10.default.class_id', - 'subjectKeyIdentifierExtDefaultImpl', - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.10.default.name', - 'Subject Key Identifier Extension Default', - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.10.default.params.critical', - 'false', - quotes=False, separator='=') - return True - - # No update was done - return False - - def enable_subject_alternative_name(self): - """ - See if Subject Alternative Name is set in the profile and if not, add - it. - """ - setlist = installutils.get_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.list', separator='=') - - # this is the default setting from pki-ca/pki-tomcat. Don't touch it - # if a user has manually modified it. - if setlist == '1,2,3,4,5,6,7,8,10' or setlist == '1,2,3,4,5,6,7,8,9,10': - setlist += ',11' - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.list', - setlist, - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.11.constraint.class_id', - 'noConstraintImpl', - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.11.constraint.name', - 'No Constraint', - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.11.default.class_id', - 'userExtensionDefaultImpl', - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.11.default.name', - 'User Supplied Extension Default', - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.11.default.params.userExtOID', - '2.5.29.17', - quotes=False, separator='=') - return True - - # No update was done - return False def set_audit_renewal(self): """ @@ -1586,7 +1393,6 @@ class CAInstance(DogtagInstance): master_entry['ipaConfigString'].append('caRenewalMaster') self.admin_conn.update_entry(master_entry) - @staticmethod def update_cert_config(nickname, cert, dogtag_constants=None): """ @@ -1854,6 +1660,65 @@ def configure_profiles_acl(): conn.disconnect() return updated +def import_included_profiles(): + sub_dict = dict( + DOMAIN=ipautil.format_netloc(api.env.domain), + IPA_CA_RECORD=IPA_CA_RECORD, + CRL_ISSUER='CN=Certificate Authority,o=ipaca', + SUBJECT_DN_O=str(DN(('O', api.env.realm))), + ) + + server_id = installutils.realm_to_serverid(api.env.realm) + dogtag_uri = 'ldapi://%%2fvar%%2frun%%2fslapd-%s.socket' % server_id + conn = ldap2.ldap2(shared_instance=False, ldap_uri=dogtag_uri) + if not conn.isconnected(): + conn.connect(autobind=True) + + for (profile_id, desc, store_issued) in dogtag.INCLUDED_PROFILES: + dn = DN(('cn', profile_id), + api.env.container_certprofile, api.env.basedn) + try: + conn.get_entry(dn) + continue # the profile is present + except errors.NotFound: + # profile not found; add it + profile_data = ipautil.template_file( + '/usr/share/ipa/profiles/{}.cfg'.format(profile_id), sub_dict) + + entry = conn.make_entry( + dn, + objectclass=['ipacertprofile'], + cn=[profile_id], + description=[desc], + ipacertprofilestoreissued=['TRUE' if store_issued else 'FALSE'], + ) + conn.add_entry(entry) + api.Backend.ra_certprofile._read_password() + with api.Backend.ra_certprofile as profile_api: + # import the profile + try: + profile_api.create_profile(profile_data) + except errors.RemoteRetrieveError: + # conflicting profile; replace it if we are + # installing IPA, but keep it for upgrades + if api.env.context == 'installer': + try: + profile_api.disable_profile(profile_id) + except errors.RemoteRetrieveError: + pass + profile_api.delete_profile(profile_id) + profile_api.create_profile(profile_data) + + # enable the profile + try: + profile_api.enable_profile(profile_id) + except errors.RemoteRetrieveError: + pass + + root_logger.info("Imported profile '%s'", profile_id) + + conn.disconnect() + if __name__ == "__main__": standard_logging_setup("install.log") ds = dsinstance.DsInstance() diff --git a/ipaserver/install/ipa_server_upgrade.py b/ipaserver/install/ipa_server_upgrade.py index 31772dc7147e53d2bf07eea191295a7fe30155e4..d3524a4159a17141d989b2f320dbfbeaa3ab305d 100644 --- a/ipaserver/install/ipa_server_upgrade.py +++ b/ipaserver/install/ipa_server_upgrade.py @@ -53,6 +53,7 @@ class ServerUpgrade(admintool.AdminTool): super(ServerUpgrade, self).run() api.bootstrap(in_server=True, context='updates') + import ipaserver.plugins.dogtag # ensure profile backend gets loaded api.finalize() options = self.options diff --git a/ipaserver/install/server.py b/ipaserver/install/server.py index 52d68877c64245b683bf5b310eff637e412cd146..db4d9fbb7271e53efde7fba7f746d3037e717f28 100644 --- a/ipaserver/install/server.py +++ b/ipaserver/install/server.py @@ -333,32 +333,28 @@ def ca_enable_ldap_profile_subsystem(ca): return needs_update -def upgrade_ipa_profile(ca, domain, fqdn): +def ca_import_included_profiles(ca): + root_logger.info('[Ensuring presence of included profiles]') + + if not ca.is_configured(): + root_logger.info('CA is not configured') + return False + + return cainstance.import_included_profiles() + + +def upgrade_ca_audit_cert_validity(ca): """ - Update the IPA Profile provided by dogtag + Update the Dogtag audit signing certificate. Returns True if restart is needed, False otherwise. """ - root_logger.info('[Verifying that CA service certificate profile is updated]') + root_logger.info('[Verifying that CA audit signing cert has 2 year validity]') if ca.is_configured(): - ski = ca.enable_subject_key_identifier() - if ski: - root_logger.debug('Subject Key Identifier updated.') - else: - root_logger.debug('Subject Key Identifier already set.') - san = ca.enable_subject_alternative_name() - if san: - root_logger.debug('Subject Alternative Name updated.') - else: - root_logger.debug('Subject Alternative Name already set.') - audit = ca.set_audit_renewal() - uri = ca.set_crl_ocsp_extensions(domain, fqdn) - if audit or ski or san or uri: - return True + return ca.set_audit_renewal() else: root_logger.info('CA is not configured') - - return False + return False def named_remove_deprecated_options(): @@ -1410,7 +1406,7 @@ def upgrade_configuration(): ca_restart = any([ ca_restart, - upgrade_ipa_profile(ca, api.env.domain, fqdn), + upgrade_ca_audit_cert_validity(ca), certificate_renewal_update(ca), ca_enable_pkix(ca), ca_configure_profiles_acl(ca), @@ -1424,4 +1420,10 @@ def upgrade_configuration(): except ipautil.CalledProcessError as e: root_logger.error("Failed to restart %s: %s", ca.service_name, e) + # This step MUST be done after ca_enable_ldap_profile_subsystem and + # ca_configure_profiles_acl, and the consequent restart, but does not + # itself require a restart. + # + ca_import_included_profiles(ca) + set_sssd_domain_option('ipa_server_mode', 'True') diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py index 9654123b16d8e417398d49bf1305fd41880bc3a7..880b319d68728a40f4479626d5a7c2b8c56ced02 100644 --- a/ipaserver/plugins/dogtag.py +++ b/ipaserver/plugins/dogtag.py @@ -1966,17 +1966,19 @@ class RestClient(Backend): self.ipa_key_size = "2048" self.ipa_certificate_nickname = "ipaCert" self.ca_certificate_nickname = "caCert" - try: - f = open(self.pwd_file, "r") - self.password = f.readline().strip() - f.close() - except IOError: - self.password = '' + self._read_password() super(RestClient, self).__init__() # session cookie self.cookie = None + def _read_password(self): + try: + with open(self.pwd_file) as f: + self.password = f.readline().strip() + except IOError: + self.password = '' + @cachedproperty def ca_host(self): """ -- 2.1.0 -------------- next part -------------- >From d7220c976518ba93b44ca0d811e5418fbd17ba19 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Thu, 7 May 2015 21:26:24 -0400 Subject: [PATCH 08/13] Add generic split_any_principal method There exist methods to split user or service/host principals, but there is no method to split any kind of principal and allow the caller to decide what to do. Generalize ``ipalib.plugins.service.split_principal`` to return a service of ``None`` if the principal is a user principal, rename it ``split_any_principal`` and reimplement ``split_principal`` to preserve existing behaviour. Part of: https://fedorahosted.org/freeipa/ticket/4938 --- ipalib/plugins/service.py | 27 +++++++++++++++++++-------- 1 file changed, 19 insertions(+), 8 deletions(-) diff --git a/ipalib/plugins/service.py b/ipalib/plugins/service.py index b37dc7b4bf56b69df204fd29e9487f1390197bbe..5af320286bab98535e1f7118840afc4d525be401 100644 --- a/ipalib/plugins/service.py +++ b/ipalib/plugins/service.py @@ -185,19 +185,24 @@ _ticket_flags_map = { _ticket_flags_default = _ticket_flags_map['ipakrbrequirespreauth'] -def split_principal(principal): +def split_any_principal(principal): service = hostname = realm = None # Break down the principal into its component parts, which may or # may not include the realm. sp = principal.split('/') - if len(sp) != 2: - raise errors.MalformedServicePrincipal(reason=_('missing service')) + name_and_realm = None + if len(sp) > 2: + raise errors.MalformedServicePrincipal(reason=_('unable to determine service')) + elif len(sp) == 2: + service = sp[0] + if len(service) == 0: + raise errors.MalformedServicePrincipal(reason=_('blank service')) + name_and_realm = sp[1] + else: + name_and_realm = sp[0] - service = sp[0] - if len(service) == 0: - raise errors.MalformedServicePrincipal(reason=_('blank service')) - sr = sp[1].split('@') + sr = name_and_realm.split('@') if len(sr) > 2: raise errors.MalformedServicePrincipal( reason=_('unable to determine realm')) @@ -212,7 +217,13 @@ def split_principal(principal): realm = api.env.realm # Note that realm may be None. - return (service, hostname, realm) + return service, hostname, realm + +def split_principal(principal): + service, name, realm = split_any_principal(principal) + if service is None: + raise errors.MalformedServicePrincipal(reason=_('missing service')) + return service, name, realm def validate_principal(ugettext, principal): (service, hostname, principal) = split_principal(principal) -- 2.1.0 -------------- next part -------------- >From 54e99b0db2ce92a429a532f11ab6e7a2aad847bc Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Fri, 8 May 2015 02:23:24 -0400 Subject: [PATCH 09/13] Add profile_id parameter to 'request_certificate' Add the profile_id parameter to the 'request_certificate' function and update call sites. Also remove multiple occurrences of the default profile ID 'caIPAserviceCert'. Part of: https://fedorahosted.org/freeipa/ticket/57 --- API.txt | 3 ++- checks/check-ra.py | 2 +- ipalib/plugins/cert.py | 2 +- ipapython/dogtag.py | 2 ++ ipaserver/install/certs.py | 2 +- ipaserver/plugins/dogtag.py | 7 +++++-- ipaserver/plugins/rabase.py | 3 ++- 7 files changed, 14 insertions(+), 7 deletions(-) diff --git a/API.txt b/API.txt index 7d221b839a7058e2bc7c6c95f7121e79a30ebcfd..ec414a97c5913c0f4cc812716c72670dae7432da 100644 --- a/API.txt +++ b/API.txt @@ -485,10 +485,11 @@ arg: Str('serial_number') option: Str('version?', exclude='webui') output: Output('result', None, None) command: cert_request -args: 1,4,1 +args: 1,5,1 arg: File('csr', cli_name='csr_file') option: Flag('add', autofill=True, default=False) option: Str('principal') +option: Str('profile_id') option: Str('request_type', autofill=True, default=u'pkcs10') option: Str('version?', exclude='webui') output: Output('result', , None) diff --git a/checks/check-ra.py b/checks/check-ra.py index a1df50ba4a4ad7fc0b6d2118e40977b1da6edf65..28929545ab7f0a63e47a3829c53cf08d784c9524 100755 --- a/checks/check-ra.py +++ b/checks/check-ra.py @@ -90,7 +90,7 @@ def assert_equal(trial, reference): api.log.info('******** Testing ra.request_certificate() ********') -request_result = ra.request_certificate(csr) +request_result = ra.request_certificate(csr, ra.DEFAULT_PROFILE) if verbose: print "request_result=\n%s" % request_result assert_equal(request_result, {'subject' : subject, diff --git a/ipalib/plugins/cert.py b/ipalib/plugins/cert.py index 7e2c77622b3627e9e57bbcb69291f723ecf509bf..e4cb6dc0aa8b89368806b08674aae277b3653e8f 100644 --- a/ipalib/plugins/cert.py +++ b/ipalib/plugins/cert.py @@ -436,7 +436,7 @@ class cert_request(VirtualCommand): # Request the certificate result = self.Backend.ra.request_certificate( - csr, request_type=request_type) + csr, 'caIPAserviceCert', request_type=request_type) cert = x509.load_certificate(result['certificate']) result['issuer'] = unicode(cert.issuer) result['valid_not_before'] = unicode(cert.valid_not_before_str) diff --git a/ipapython/dogtag.py b/ipapython/dogtag.py index 2b4d233354b974884c88d13a3a1b437915ba0776..659751e57bf3deead0966e748c7302600db0f56c 100644 --- a/ipapython/dogtag.py +++ b/ipapython/dogtag.py @@ -47,6 +47,8 @@ INCLUDED_PROFILES = { (u'caIPAserviceCert', u'Standard profile for network services', True), } +DEFAULT_PROFILE = 'caIPAserviceCert' + class Dogtag10Constants(object): DOGTAG_VERSION = 10 UNSECURE_PORT = 8080 diff --git a/ipaserver/install/certs.py b/ipaserver/install/certs.py index bc7dccf805386e9fa84b58d2ff9346085e1b93b1..564332e6fde0698a23884922c5018fab59da7e4d 100644 --- a/ipaserver/install/certs.py +++ b/ipaserver/install/certs.py @@ -386,7 +386,7 @@ class CertDB(object): # We just want the CSR bits, make sure there is nothing else csr = pkcs10.strip_header(csr) - params = {'profileId': 'caIPAserviceCert', + params = {'profileId': dogtag.DEFAULT_PROFILE, 'cert_request_type': 'pkcs10', 'requestor_name': 'IPA Installer', 'cert_request': csr, diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py index 880b319d68728a40f4479626d5a7c2b8c56ced02..e6668bb43b994863a14fdd347635753422ed9388 100644 --- a/ipaserver/plugins/dogtag.py +++ b/ipaserver/plugins/dogtag.py @@ -1284,6 +1284,8 @@ class ra(rabase.rabase): """ Request Authority backend plugin. """ + DEFAULT_PROFILE = dogtag.DEFAULT_PROFILE + def __init__(self): if api.env.in_tree: self.sec_dir = api.env.dot_ipa + os.sep + 'alias' @@ -1541,9 +1543,10 @@ class ra(rabase.rabase): return cmd_result - def request_certificate(self, csr, request_type='pkcs10'): + def request_certificate(self, csr, profile_id, request_type='pkcs10'): """ :param csr: The certificate signing request. + :param profile_id: The profile to use for the request. :param request_type: The request type (defaults to ``'pkcs10'``). Submit certificate signing request. @@ -1575,7 +1578,7 @@ class ra(rabase.rabase): http_status, http_reason_phrase, http_headers, http_body = \ self._sslget('/ca/eeca/ca/profileSubmitSSLClient', self.env.ca_ee_port, - profileId='caIPAserviceCert', + profileId=profile_id, cert_request_type=request_type, cert_request=csr, xml='true') diff --git a/ipaserver/plugins/rabase.py b/ipaserver/plugins/rabase.py index e14969970ef5b402d06b766f895200c6eb4fc76f..cf4426235b02866a3f565c51c52c44aabbdc1153 100644 --- a/ipaserver/plugins/rabase.py +++ b/ipaserver/plugins/rabase.py @@ -67,11 +67,12 @@ class rabase(Backend): """ raise errors.NotImplementedError(name='%s.get_certificate' % self.name) - def request_certificate(self, csr, request_type='pkcs10'): + def request_certificate(self, csr, profile_id, request_type='pkcs10'): """ Submit certificate signing request. :param csr: The certificate signing request. + :param profile_id: Profile to use for this request. :param request_type: The request type (defaults to ``'pkcs10'``). """ raise errors.NotImplementedError(name='%s.request_certificate' % self.name) -- 2.1.0 -------------- next part -------------- >From 10a75249f0df9cbe5a6e776d17c91fa195bee60f Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 18 May 2015 22:11:52 -0400 Subject: [PATCH 10/13] Add usercertificate attribute to user plugin Part of: https://fedorahosted.org/freeipa/tickets/4938 --- ACI.txt | 2 +- API.txt | 18 ++++++++++++------ install/share/default-aci.ldif | 1 + install/updates/20-aci.update | 4 ++++ ipalib/plugins/baseuser.py | 10 ++++++++-- ipalib/plugins/user.py | 2 +- 6 files changed, 27 insertions(+), 10 deletions(-) diff --git a/ACI.txt b/ACI.txt index 035a545511e4f56dcb492c97514de59cfc028405..fca5b269522c4ab80858c23b1a61e229eee0048e 100644 --- a/ACI.txt +++ b/ACI.txt @@ -281,7 +281,7 @@ aci: (targetattr = "krbprincipalkey || passwordhistory || sambalmpassword || sam dn: cn=users,cn=accounts,dc=ipa,dc=example aci: (targetattr = "ipasshpubkey")(targetfilter = "(objectclass=posixaccount)")(version 3.0;acl "permission:System: Manage User SSH Public Keys";allow (write) groupdn = "ldap:///cn=System: Manage User SSH Public Keys,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: cn=users,cn=accounts,dc=ipa,dc=example -aci: (targetattr = "businesscategory || carlicense || cn || description || displayname || employeetype || facsimiletelephonenumber || gecos || givenname || homephone || inetuserhttpurl || initials || l || labeleduri || loginshell || manager || mepmanagedentry || mobile || objectclass || ou || pager || postalcode || preferredlanguage || roomnumber || secretary || seealso || sn || st || street || telephonenumber || title || userclass")(targetfilter = "(objectclass=posixaccount)")(version 3.0;acl "permission:System: Modify Users";allow (write) groupdn = "ldap:///cn=System: Modify Users,cn=permissions,cn=pbac,dc=ipa,dc=example";) +aci: (targetattr = "businesscategory || carlicense || cn || description || displayname || employeetype || facsimiletelephonenumber || gecos || givenname || homephone || inetuserhttpurl || initials || l || labeleduri || loginshell || manager || mepmanagedentry || mobile || objectclass || ou || pager || postalcode || preferredlanguage || roomnumber || secretary || seealso || sn || st || street || telephonenumber || title || usercertificate || userclass")(targetfilter = "(objectclass=posixaccount)")(version 3.0;acl "permission:System: Modify Users";allow (write) groupdn = "ldap:///cn=System: Modify Users,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: cn=UPG Definition,cn=Definitions,cn=Managed Entries,cn=etc,dc=ipa,dc=example aci: (targetattr = "*")(target = "ldap:///cn=UPG Definition,cn=Definitions,cn=Managed Entries,cn=etc,dc=ipa,dc=example")(version 3.0;acl "permission:System: Read UPG Definition";allow (compare,read,search) groupdn = "ldap:///cn=System: Read UPG Definition,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: cn=users,cn=accounts,dc=ipa,dc=example diff --git a/API.txt b/API.txt index ec414a97c5913c0f4cc812716c72670dae7432da..a59e99ba31bf901b960c36b05541c3e400d4ec7c 100644 --- a/API.txt +++ b/API.txt @@ -3808,7 +3808,7 @@ output: Entry('result', , Gettext('A dictionary representing an LDA output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: stageuser_add -args: 1,43,3 +args: 1,44,3 arg: Str('uid', attribute=True, cli_name='login', 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') @@ -3850,6 +3850,7 @@ option: Str('street', attribute=True, cli_name='street', multivalue=False, requi option: Str('telephonenumber', attribute=True, cli_name='phone', multivalue=True, required=False) option: Str('title', attribute=True, cli_name='title', multivalue=False, required=False) option: Int('uidnumber', attribute=True, cli_name='uid', minvalue=1, multivalue=False, required=False) +option: Bytes('usercertificate', attribute=True, cli_name='certificate', multivalue=True, required=False) option: Str('userclass', attribute=True, cli_name='class', multivalue=True, required=False) option: Password('userpassword', attribute=True, cli_name='password', exclude='webui', multivalue=False, required=False) option: Str('version?', exclude='webui') @@ -3865,7 +3866,7 @@ output: Output('result', , None) output: Output('summary', (, ), None) output: ListOfPrimaryKeys('value', None, None) command: stageuser_find -args: 1,52,4 +args: 1,53,4 arg: Str('criteria?', noextrawhitespace=False) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('carlicense', attribute=True, autofill=False, cli_name='carlicense', multivalue=True, query=True, required=False) @@ -3916,6 +3917,7 @@ option: Int('timelimit?', autofill=False, minvalue=0) option: Str('title', attribute=True, autofill=False, cli_name='title', multivalue=False, query=True, required=False) option: Str('uid', attribute=True, autofill=False, cli_name='login', 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: Int('uidnumber', attribute=True, autofill=False, cli_name='uid', minvalue=1, multivalue=False, query=True, required=False) +option: Bytes('usercertificate', attribute=True, autofill=False, cli_name='certificate', multivalue=True, query=True, required=False) option: Str('userclass', attribute=True, autofill=False, cli_name='class', multivalue=True, query=True, required=False) option: Password('userpassword', attribute=True, autofill=False, cli_name='password', exclude='webui', multivalue=False, query=True, required=False) option: Str('version?', exclude='webui') @@ -3924,7 +3926,7 @@ output: ListOfEntries('result', (, ), Gettext('A list output: Output('summary', (, ), None) output: Output('truncated', , None) command: stageuser_mod -args: 1,44,3 +args: 1,45,3 arg: Str('uid', attribute=True, cli_name='login', 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: Str('addattr*', cli_name='addattr', exclude='webui') option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') @@ -3967,6 +3969,7 @@ option: Str('street', attribute=True, autofill=False, cli_name='street', multiva option: Str('telephonenumber', attribute=True, autofill=False, cli_name='phone', multivalue=True, required=False) option: Str('title', attribute=True, autofill=False, cli_name='title', multivalue=False, required=False) option: Int('uidnumber', attribute=True, autofill=False, cli_name='uid', minvalue=1, multivalue=False, required=False) +option: Bytes('usercertificate', attribute=True, autofill=False, cli_name='certificate', multivalue=True, required=False) option: Str('userclass', attribute=True, autofill=False, cli_name='class', multivalue=True, required=False) option: Password('userpassword', attribute=True, autofill=False, cli_name='password', exclude='webui', multivalue=False, required=False) option: Str('version?', exclude='webui') @@ -4594,7 +4597,7 @@ output: Entry('result', , Gettext('A dictionary representing an LDA output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: user_add -args: 1,44,3 +args: 1,45,3 arg: Str('uid', attribute=True, cli_name='login', 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') @@ -4637,6 +4640,7 @@ option: Str('street', attribute=True, cli_name='street', multivalue=False, requi option: Str('telephonenumber', attribute=True, cli_name='phone', multivalue=True, required=False) option: Str('title', attribute=True, cli_name='title', multivalue=False, required=False) option: Int('uidnumber', attribute=True, cli_name='uid', minvalue=1, multivalue=False, required=False) +option: Bytes('usercertificate', attribute=True, cli_name='certificate', multivalue=True, required=False) option: Str('userclass', attribute=True, cli_name='class', multivalue=True, required=False) option: Password('userpassword', attribute=True, cli_name='password', exclude='webui', multivalue=False, required=False) option: Str('version?', exclude='webui') @@ -4668,7 +4672,7 @@ output: Output('result', , None) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: user_find -args: 1,55,4 +args: 1,56,4 arg: Str('criteria?', noextrawhitespace=False) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('carlicense', attribute=True, autofill=False, cli_name='carlicense', multivalue=True, query=True, required=False) @@ -4721,6 +4725,7 @@ option: Int('timelimit?', autofill=False, minvalue=0) option: Str('title', attribute=True, autofill=False, cli_name='title', multivalue=False, query=True, required=False) option: Str('uid', attribute=True, autofill=False, cli_name='login', 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: Int('uidnumber', attribute=True, autofill=False, cli_name='uid', minvalue=1, multivalue=False, query=True, required=False) +option: Bytes('usercertificate', attribute=True, autofill=False, cli_name='certificate', multivalue=True, query=True, required=False) option: Str('userclass', attribute=True, autofill=False, cli_name='class', multivalue=True, query=True, required=False) option: Password('userpassword', attribute=True, autofill=False, cli_name='password', exclude='webui', multivalue=False, query=True, required=False) option: Str('version?', exclude='webui') @@ -4730,7 +4735,7 @@ output: ListOfEntries('result', (, ), Gettext('A list output: Output('summary', (, ), None) output: Output('truncated', , None) command: user_mod -args: 1,45,3 +args: 1,46,3 arg: Str('uid', attribute=True, cli_name='login', 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: Str('addattr*', cli_name='addattr', exclude='webui') option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') @@ -4774,6 +4779,7 @@ option: Str('street', attribute=True, autofill=False, cli_name='street', multiva option: Str('telephonenumber', attribute=True, autofill=False, cli_name='phone', multivalue=True, required=False) option: Str('title', attribute=True, autofill=False, cli_name='title', multivalue=False, required=False) option: Int('uidnumber', attribute=True, autofill=False, cli_name='uid', minvalue=1, multivalue=False, required=False) +option: Bytes('usercertificate', attribute=True, autofill=False, cli_name='certificate', multivalue=True, required=False) option: Str('userclass', attribute=True, autofill=False, cli_name='class', multivalue=True, required=False) option: Password('userpassword', attribute=True, autofill=False, cli_name='password', exclude='webui', multivalue=False, required=False) option: Str('version?', exclude='webui') diff --git a/install/share/default-aci.ldif b/install/share/default-aci.ldif index af7eedb0b92375f893a61ad1fb6e2d7b176389f9..7b174e774aae3ea012a431fe4a2535fb4230e402 100644 --- a/install/share/default-aci.ldif +++ b/install/share/default-aci.ldif @@ -10,6 +10,7 @@ changetype: modify add: aci aci: (targetattr = "givenname || sn || cn || displayname || title || initials || loginshell || gecos || homephone || mobile || pager || facsimiletelephonenumber || telephonenumber || street || roomnumber || l || st || postalcode || manager || secretary || description || carlicense || labeleduri || inetuserhttpurl || seealso || employeetype || businesscategory || ou")(version 3.0;acl "selfservice:User Self service";allow (write) userdn = "ldap:///self";) aci: (targetattr = "ipasshpubkey")(version 3.0;acl "selfservice:Users can manage their own SSH public keys";allow (write) userdn = "ldap:///self";) +aci: (targetattr = "usercertificate")(version 3.0;acl "selfservice:Users can manage their own X.509 certificates";allow (write) userdn = "ldap:///self";) dn: cn=etc,$SUFFIX changetype: modify diff --git a/install/updates/20-aci.update b/install/updates/20-aci.update index fde3afeee59e4d4dc0bd6a9c0eb24ab255c4e637..4a8b67c6579da4dab74d02861640264446153f87 100644 --- a/install/updates/20-aci.update +++ b/install/updates/20-aci.update @@ -79,3 +79,7 @@ add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; acl "Group add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; acl "Entities are allowed to rekey themselves"; allow(write) userdn="ldap:///self";) add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; acl "Admins are allowed to rekey any entity"; allow(write) groupdn = "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";) add:aci: (targetfilter="(|(objectclass=ipaHost)(objectclass=ipaService))")(targetattr="ipaProtectedOperation;write_keys")(version 3.0; acl "Entities are allowed to rekey managed entries"; allow(write) userattr="managedby#USERDN";) + +# User certificates +dn: $SUFFIX +add:aci:(targetattr = "usercertificate")(version 3.0;acl "selfservice:Users can manage their own X.509 certificates";allow (write) userdn = "ldap:///self";) diff --git a/ipalib/plugins/baseuser.py b/ipalib/plugins/baseuser.py index a1be29d83550a0412ed37cfde47ac74c6ca478fd..d2bc68f45ad9a3632a237c01961a30592514d96d 100644 --- a/ipalib/plugins/baseuser.py +++ b/ipalib/plugins/baseuser.py @@ -23,10 +23,11 @@ import posixpath import os from ipalib import api, errors -from ipalib import Flag, Int, Password, Str, Bool, StrEnum, DateTime +from ipalib import Flag, Int, Password, Str, Bool, StrEnum, DateTime, Bytes from ipalib.plugable import Registry from ipalib.plugins.baseldap import DN, LDAPObject, \ LDAPCreate, LDAPUpdate, LDAPSearch, LDAPDelete, LDAPRetrieve +from ipalib.plugins.service import validate_certificate from ipalib.plugins import baseldap from ipalib.request import context from ipalib import _, ngettext @@ -188,7 +189,7 @@ class baseuser(LDAPObject): 'telephonenumber', 'title', 'memberof', 'nsaccountlock', 'memberofindirect', 'ipauserauthtype', 'userclass', 'ipatokenradiusconfiglink', 'ipatokenradiususername', - 'krbprincipalexpiration' + 'krbprincipalexpiration', 'usercertificate', ] search_display_attributes = [ 'uid', 'givenname', 'sn', 'homedirectory', 'loginshell', @@ -383,6 +384,11 @@ class baseuser(LDAPObject): + '(\s*,\s*[a-zA-Z]{1,8}(-[a-zA-Z]{1,8})?(;q\=((0(\.[0-9]{0,3})?)|(1(\.0{0,3})?)))?)*)|(\*))$', pattern_errmsg='must match RFC 2068 - 14.4, e.g., "da, en-gb;q=0.8, en;q=0.7"', ), + Bytes('usercertificate*', validate_certificate, + cli_name='certificate', + label=_('Certificate'), + doc=_('Base-64 encoded server certificate'), + ), ) def normalize_and_validate_email(self, email, config=None): diff --git a/ipalib/plugins/user.py b/ipalib/plugins/user.py index 54d47bb01450ec462577e552315e3d680b7648c3..119294b19f54a395a2df65c6cfd47cd8eb844297 100644 --- a/ipalib/plugins/user.py +++ b/ipalib/plugins/user.py @@ -267,7 +267,7 @@ class user(baseuser): 'mepmanagedentry', 'mobile', 'objectclass', 'ou', 'pager', 'postalcode', 'roomnumber', 'secretary', 'seealso', 'sn', 'st', 'street', 'telephonenumber', 'title', 'userclass', - 'preferredlanguage', + 'preferredlanguage', 'usercertificate', }, 'replaces': [ '(targetattr = "givenname || sn || cn || displayname || title || initials || loginshell || gecos || homephone || mobile || pager || facsimiletelephonenumber || telephonenumber || street || roomnumber || l || st || postalcode || manager || secretary || description || carlicense || labeleduri || inetuserhttpurl || seealso || employeetype || businesscategory || ou || mepmanagedentry || objectclass")(target = "ldap:///uid=*,cn=users,cn=accounts,$SUFFIX")(version 3.0;acl "permission:Modify Users";allow (write) groupdn = "ldap:///cn=Modify Users,cn=permissions,cn=pbac,$SUFFIX";)', -- 2.1.0 -------------- next part -------------- >From dfd3883a184638a3cfa9275c750a0f9bb9d7624c Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Thu, 14 May 2015 01:45:16 -0400 Subject: [PATCH 11/13] Update cert-request to support user certs and profiles Part of: https://fedorahosted.org/freeipa/ticket/57 Part of: https://fedorahosted.org/freeipa/ticket/4938 --- ipalib/pkcs10.py | 1 + ipalib/plugins/cert.py | 178 ++++++++++++++++++++++++++----------------------- 2 files changed, 97 insertions(+), 82 deletions(-) diff --git a/ipalib/pkcs10.py b/ipalib/pkcs10.py index f35e200a2c1b47e2a2c8cffcf9b723f398fe3221..6299dfea43b7a3f4104f0b0ec78c4f105d9daf62 100644 --- a/ipalib/pkcs10.py +++ b/ipalib/pkcs10.py @@ -30,6 +30,7 @@ PEM = 0 DER = 1 SAN_DNSNAME = 'DNS name' +SAN_RFC822NAME = 'RFC822 Name' SAN_OTHERNAME_UPN = 'Other Name (OID.1.3.6.1.4.1.311.20.2.3)' SAN_OTHERNAME_KRB5PRINCIPALNAME = 'Other Name (OID.1.3.6.1.5.2.2)' diff --git a/ipalib/plugins/cert.py b/ipalib/plugins/cert.py index e4cb6dc0aa8b89368806b08674aae277b3653e8f..aab2db770c3aae6fbc7d13ae7707f06ba583ba09 100644 --- a/ipalib/plugins/cert.py +++ b/ipalib/plugins/cert.py @@ -31,7 +31,8 @@ from ipalib import ngettext from ipalib.plugable import Registry from ipalib.plugins.virtual import * from ipalib.plugins.baseldap import pkey_to_value -from ipalib.plugins.service import split_principal +from ipalib.plugins.service import split_any_principal +from ipalib.plugins.certprofile import validate_profile_id import base64 import traceback from ipalib.text import _ @@ -122,6 +123,8 @@ http://www.ietf.org/rfc/rfc5280.txt """) +USER, HOST, SERVICE = range(3) + register = Registry() def validate_pkidate(ugettext, value): @@ -232,7 +235,7 @@ class cert_request(VirtualCommand): takes_options = ( Str('principal', label=_('Principal'), - doc=_('Service principal for this certificate (e.g. HTTP/test.example.com)'), + doc=_('Principal for this certificate (e.g. HTTP/test.example.com)'), ), Str('request_type', default=u'pkcs10', @@ -243,6 +246,10 @@ class cert_request(VirtualCommand): default=False, autofill=True ), + Str('profile_id', validate_profile_id, + label=_("Profile ID"), + doc=_("Certificate Profile to use"), + ) ) has_output_params = ( @@ -294,10 +301,9 @@ class cert_request(VirtualCommand): ca_enabled_check() ldap = self.api.Backend.ldap2 - principal = kw.get('principal') add = kw.get('add') request_type = kw.get('request_type') - service = None + profile_id = kw.get('profile_id', self.Backend.ra.DEFAULT_PROFILE) """ Access control is partially handled by the ACI titled @@ -310,9 +316,21 @@ class cert_request(VirtualCommand): taskgroup (directly or indirectly via role membership). """ - bind_principal = getattr(context, 'principal') - # Can this user request certs? - if not bind_principal.startswith('host/'): + principal_string = kw.get('principal') + principal = split_any_principal(principal_string) + servicename, principal_name, realm = principal + if servicename is None: + principal_type = USER + elif servicename == 'host': + principal_type = HOST + else: + principal_type = SERVICE + + bind_principal = split_any_principal(getattr(context, 'principal')) + bind_service, bind_name, bind_realm = bind_principal + + if bind_principal != principal: + # Can the bound principal request certs for another principal? self.check_access() try: @@ -323,57 +341,54 @@ class cert_request(VirtualCommand): raise errors.CertificateOperationError( error=_("Failure decoding Certificate Signing Request: %s") % e) - if not bind_principal.startswith('host/'): + # host principals may bypass allowed ext check + if bind_service != 'host': for ext in extensions: operation = self._allowed_extensions.get(ext) if operation: self.check_access(operation) - # Ensure that the hostname in the CSR matches the principal - subject_host = subject.common_name #pylint: disable=E1101 - if not subject_host: + + # Ensure that the DN in the CSR matches the principal + cn = subject.common_name #pylint: disable=E1101 + if not cn: raise errors.ValidationError(name='csr', - error=_("No hostname was found in subject of request.")) + error=_("No Common Name was found in subject of request.")) - (servicename, hostname, realm) = split_principal(principal) - if subject_host.lower() != hostname.lower(): - raise errors.ACIError( - info=_("hostname in subject of request '%(subject_host)s' " - "does not match principal hostname '%(hostname)s'") % dict( - subject_host=subject_host, hostname=hostname)) + if principal_type in (SERVICE, HOST): + if cn.lower() != principal_name.lower(): + raise errors.ACIError( + info=_("hostname in subject of request '%(cn)s' " + "does not match principal hostname '%(hostname)s'") + % dict(cn=cn, hostname=principal_name)) + elif principal_type == USER: + pass # TODO require cn / emailAddress to match user for ext in extensions: if ext not in self._allowed_extensions: raise errors.ValidationError( name='csr', error=_("extension %s is forbidden") % ext) - for name_type, name in subjectaltname: - if name_type not in (pkcs10.SAN_DNSNAME, - pkcs10.SAN_OTHERNAME_KRB5PRINCIPALNAME, - pkcs10.SAN_OTHERNAME_UPN): - raise errors.ValidationError( - name='csr', - error=_("subject alt name type %s is forbidden") % - name_type) - dn = None - service = None + principal_obj = None # See if the service exists and punt if it doesn't and we aren't # going to add it try: - if servicename != 'host': - service = api.Command['service_show'](principal, all=True) - else: - service = api.Command['host_show'](hostname, all=True) - except errors.NotFound, e: - if not add: - raise errors.NotFound(reason=_("The service principal for " - "this request doesn't exist.")) - service = api.Command['service_add'](principal, force=True) - service = service['result'] - dn = service['dn'] + if principal_type == SERVICE: + principal_obj = api.Command['service_show'](principal_string, all=True) + elif principal_type == HOST: + principal_obj = api.Command['host_show'](principal_name, all=True) + elif principal_type == USER: + principal_obj = api.Command['user_show'](principal_name, all=True) + except errors.NotFound as e: + if principal_type != SERVICE or not add: + raise errors.NotFound( + reason=_("The principal for this request doesn't exist.")) + principal_obj = api.Command['service_add'](principal_string, force=True) + principal_obj = principal_obj['result'] + dn = principal_obj['dn'] - # We got this far so the service entry exists, can we write it? + # We got this far so the principal entry exists, can we write it? if not ldap.can_write(dn, "usercertificate"): raise errors.ACIError(info=_("Insufficient 'write' privilege " "to the 'userCertificate' attribute of entry '%s'.") % dn) @@ -382,13 +397,20 @@ class cert_request(VirtualCommand): for name_type, name in subjectaltname: if name_type == pkcs10.SAN_DNSNAME: name = unicode(name) + alt_principal_obj = None try: - if servicename == 'host': - altservice = api.Command['host_show'](name, all=True) - else: + if principal_type == HOST: + alt_principal_obj = api.Command['host_show'](name, all=True) + elif principal_type == SERVICE: altprincipal = '%s/%s@%s' % (servicename, name, realm) - altservice = api.Command['service_show']( + alt_principal_obj = api.Command['service_show']( altprincipal, all=True) + elif principal_type == USER: + raise errors.ValidationError( + name='csr', + error=_("subject alt name type %s is forbidden " + "for user principals") % name_type + ) except errors.NotFound: # We don't want to issue any certificates referencing # machines we don't know about. Nothing is stored in this @@ -396,47 +418,35 @@ class cert_request(VirtualCommand): raise errors.NotFound(reason=_('The service principal for ' 'subject alt name %s in certificate request does not ' 'exist') % name) - altdn = altservice['result']['dn'] - if not ldap.can_write(altdn, "usercertificate"): - raise errors.ACIError(info=_( - "Insufficient privilege to create a certificate with " - "subject alt name '%s'.") % name) + if alt_principal_obj is not None: + altdn = alt_principal_obj['result']['dn'] + if not ldap.can_write(altdn, "usercertificate"): + raise errors.ACIError(info=_( + "Insufficient privilege to create a certificate " + "with subject alt name '%s'.") % name) elif name_type in (pkcs10.SAN_OTHERNAME_KRB5PRINCIPALNAME, pkcs10.SAN_OTHERNAME_UPN): if name != principal: raise errors.ACIError( info=_("Principal '%s' in subject alt name does not " - "match requested service principal") % name) + "match requested principal") % name) + elif name_type == pkcs10.SAN_RFC822NAME: + if principal_type == USER: + pass # TODO require match to user email address + else: + raise errors.ValidationError( + name='csr', + error=_("subject alt name type %s is forbidden " + "for non-user principals") % name_type + ) else: raise errors.ACIError( info=_("Subject alt name type %s is forbidden") % name_type) - if 'usercertificate' in service: - serial = x509.get_serial_number(service['usercertificate'][0], datatype=x509.DER) - # revoke the certificate and remove it from the service - # entry before proceeding. First we retrieve the certificate to - # see if it is already revoked, if not then we revoke it. - try: - result = api.Command['cert_show'](unicode(serial))['result'] - if 'revocation_reason' not in result: - try: - api.Command['cert_revoke'](unicode(serial), revocation_reason=4) - except errors.NotImplementedError: - # some CA's might not implement revoke - pass - except errors.NotImplementedError: - # some CA's might not implement get - pass - if not principal.startswith('host/'): - api.Command['service_mod'](principal, usercertificate=None) - else: - hostname = get_host_from_principal(principal) - api.Command['host_mod'](hostname, usercertificate=None) - # Request the certificate result = self.Backend.ra.request_certificate( - csr, 'caIPAserviceCert', request_type=request_type) + csr, profile_id, request_type=request_type) cert = x509.load_certificate(result['certificate']) result['issuer'] = unicode(cert.issuer) result['valid_not_before'] = unicode(cert.valid_not_before_str) @@ -444,15 +454,19 @@ class cert_request(VirtualCommand): result['md5_fingerprint'] = unicode(nss.data_to_hex(nss.md5_digest(cert.der_data), 64)[0]) result['sha1_fingerprint'] = unicode(nss.data_to_hex(nss.sha1_digest(cert.der_data), 64)[0]) - # Success? Then add it to the service entry. - if 'certificate' in result: - if not principal.startswith('host/'): - skw = {"usercertificate": str(result.get('certificate'))} - api.Command['service_mod'](principal, **skw) - else: - hostname = get_host_from_principal(principal) - skw = {"usercertificate": str(result.get('certificate'))} - api.Command['host_mod'](hostname, **skw) + # Success? Then add it to the principal's entry + # (unless the profile tells us not to) + profile = api.Command['certprofile_show'](profile_id) + store = profile['result']['ipacertprofilestoreissued'][0] == 'TRUE' + if store and 'certificate' in result: + cert = str(result.get('certificate')) + if principal_type == SERVICE: + api.Command['service_mod'](principal_string, usercertificate=cert) + elif principal_type == HOST: + api.Command['host_mod'](principal_name, usercertificate=cert) + elif principal_type == USER: + api.Command['user_mod'](principal_name, + addattr=u'usercertificate={}'.format(cert)) return dict( result=result -- 2.1.0 -------------- next part -------------- >From 5469b65b83d18daa4c22dd9a40b6848292ac3145 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 25 May 2015 08:39:07 -0400 Subject: [PATCH 12/13] Add CA ACL plugin Implement the caacl commands, which are used to indicate which principals may be issued certificates from which (sub-)CAs, using which profiles. At this commit, and until sub-CAs are implemented, all rules refer to the top-level CA (represented as ".") and no ca-ref argument is exposed. Also add a default CA ACL that permitS certificate issuance for all hosts and services using the profile 'caIPAserviceCert' on the top-level CA. Part of: https://fedorahosted.org/freeipa/ticket/57 Part of: https://fedorahosted.org/freeipa/ticket/4559 --- ACI.txt | 10 + API.txt | 171 +++++++++++++++ install/share/60certificate-profiles.ldif | 8 + install/share/Makefile.am | 1 + install/share/bootstrap-template.ldif | 6 + install/share/default-caacl.ldif | 12 ++ install/updates/41-caacl.update | 4 + install/updates/Makefile.am | 1 + ipalib/constants.py | 1 + ipalib/plugins/caacl.py | 343 ++++++++++++++++++++++++++++++ ipaserver/install/dsinstance.py | 4 + 11 files changed, 561 insertions(+) create mode 100644 install/share/default-caacl.ldif create mode 100644 install/updates/41-caacl.update create mode 100644 ipalib/plugins/caacl.py diff --git a/ACI.txt b/ACI.txt index fca5b269522c4ab80858c23b1a61e229eee0048e..c92e341834c1134cab007e61d2953b8e52f375b5 100644 --- a/ACI.txt +++ b/ACI.txt @@ -22,6 +22,16 @@ dn: cn=automount,dc=ipa,dc=example aci: (targetattr = "automountmapname || description")(targetfilter = "(objectclass=automountmap)")(version 3.0;acl "permission:System: Modify Automount Maps";allow (write) groupdn = "ldap:///cn=System: Modify Automount Maps,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: cn=automount,dc=ipa,dc=example aci: (targetfilter = "(objectclass=automountmap)")(version 3.0;acl "permission:System: Remove Automount Maps";allow (delete) groupdn = "ldap:///cn=System: Remove Automount Maps,cn=permissions,cn=pbac,dc=ipa,dc=example";) +dn: cn=caacls,cn=ca,dc=ipa,dc=example +aci: (targetfilter = "(objectclass=ipacaacl)")(version 3.0;acl "permission:System: Add CA ACL";allow (add) groupdn = "ldap:///cn=System: Add CA ACL,cn=permissions,cn=pbac,dc=ipa,dc=example";) +dn: cn=caacls,cn=ca,dc=ipa,dc=example +aci: (targetfilter = "(objectclass=ipacaacl)")(version 3.0;acl "permission:System: Delete CA ACL";allow (delete) groupdn = "ldap:///cn=System: Delete CA ACL,cn=permissions,cn=pbac,dc=ipa,dc=example";) +dn: cn=caacls,cn=ca,dc=ipa,dc=example +aci: (targetattr = "ipacaaclallhosts || ipacaaclallservices || ipacaaclallusers || memberhost || memberservice || memberuser")(targetfilter = "(objectclass=ipacaacl)")(version 3.0;acl "permission:System: Manage CA ACL Membership";allow (write) groupdn = "ldap:///cn=System: Manage CA ACL Membership,cn=permissions,cn=pbac,dc=ipa,dc=example";) +dn: cn=caacls,cn=ca,dc=ipa,dc=example +aci: (targetattr = "cn || description || ipacaaclallcas || ipacaaclallprofiles || ipacaaclcaref || ipacaaclprofileid || ipaenabledflag")(targetfilter = "(objectclass=ipacaacl)")(version 3.0;acl "permission:System: Modify CA ACL";allow (write) groupdn = "ldap:///cn=System: Modify CA ACL,cn=permissions,cn=pbac,dc=ipa,dc=example";) +dn: cn=caacls,cn=ca,dc=ipa,dc=example +aci: (targetattr = "cn || createtimestamp || description || entryusn || ipacaaclallcas || ipacaaclallhosts || ipacaaclallprofiles || ipacaaclallservices || ipacaaclallusers || ipacaaclcaref || ipacaaclprofileid || ipaenabledflag || ipauniqueid || member || memberhost || memberservice || memberuser || modifytimestamp || objectclass")(targetfilter = "(objectclass=ipacaacl)")(version 3.0;acl "permission:System: Read CA ACLs";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=certprofiles,cn=ca,dc=ipa,dc=example aci: (targetfilter = "(objectclass=ipacertprofile)")(version 3.0;acl "permission:System: Delete Certificate Profile";allow (delete) groupdn = "ldap:///cn=System: Delete Certificate Profile,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: cn=certprofiles,cn=ca,dc=ipa,dc=example diff --git a/API.txt b/API.txt index a59e99ba31bf901b960c36b05541c3e400d4ec7c..1b3727059c362d32ac6cc56d7277ebb8763f6943 100644 --- a/API.txt +++ b/API.txt @@ -456,6 +456,177 @@ option: Str('version?', exclude='webui') output: Output('result', , None) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) +command: caacl_add +args: 1,15,3 +arg: Str('cn', attribute=True, cli_name='name', multivalue=False, 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: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) +option: Bool('ipacaaclallcas', attribute=True, cli_name='allcas', multivalue=False, required=False) +option: Bool('ipacaaclallhosts', attribute=True, cli_name='allhosts', multivalue=False, required=False) +option: Bool('ipacaaclallprofiles', attribute=True, cli_name='allprofiles', multivalue=False, required=False) +option: Bool('ipacaaclallservices', attribute=True, cli_name='allservices', multivalue=False, required=False) +option: Bool('ipacaaclallusers', attribute=True, cli_name='allusers', multivalue=False, required=False) +option: Str('ipacaaclcaref', attribute=True, cli_name='ca_ref', multivalue=True, required=False) +option: Str('ipacaaclprofileid', attribute=True, cli_name='profile_id', multivalue=True, required=False) +option: Bool('ipaenabledflag', attribute=True, cli_name='ipaenabledflag', multivalue=False, required=False) +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: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: caacl_add_host +args: 1,6,3 +arg: Str('cn', attribute=True, cli_name='name', multivalue=False, primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('host*', alwaysask=True, cli_name='hosts', csv=True) +option: Str('hostgroup*', alwaysask=True, cli_name='hostgroups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +command: caacl_add_service +args: 1,5,3 +arg: Str('cn', attribute=True, cli_name='name', multivalue=False, 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: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('service*', alwaysask=True, cli_name='services', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +command: caacl_add_user +args: 1,6,3 +arg: Str('cn', attribute=True, cli_name='name', multivalue=False, primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +command: caacl_del +args: 1,2,3 +arg: Str('cn', attribute=True, cli_name='name', multivalue=True, 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', , None) +output: Output('summary', (, ), None) +output: ListOfPrimaryKeys('value', None, None) +command: caacl_disable +args: 1,1,3 +arg: Str('cn', attribute=True, cli_name='name', multivalue=False, primary_key=True, query=True, required=True) +option: Str('version?', exclude='webui') +output: Output('result', , None) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: caacl_enable +args: 1,1,3 +arg: Str('cn', attribute=True, cli_name='name', multivalue=False, primary_key=True, query=True, required=True) +option: Str('version?', exclude='webui') +output: Output('result', , None) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: caacl_find +args: 1,17,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='name', multivalue=False, primary_key=True, query=True, required=False) +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, query=True, required=False) +option: Bool('ipacaaclallcas', attribute=True, autofill=False, cli_name='allcas', multivalue=False, query=True, required=False) +option: Bool('ipacaaclallhosts', attribute=True, autofill=False, cli_name='allhosts', multivalue=False, query=True, required=False) +option: Bool('ipacaaclallprofiles', attribute=True, autofill=False, cli_name='allprofiles', multivalue=False, query=True, required=False) +option: Bool('ipacaaclallservices', attribute=True, autofill=False, cli_name='allservices', multivalue=False, query=True, required=False) +option: Bool('ipacaaclallusers', attribute=True, autofill=False, cli_name='allusers', multivalue=False, query=True, required=False) +option: Str('ipacaaclcaref', attribute=True, autofill=False, cli_name='ca_ref', multivalue=True, query=True, required=False) +option: Str('ipacaaclprofileid', attribute=True, autofill=False, cli_name='profile_id', multivalue=True, query=True, required=False) +option: Bool('ipaenabledflag', attribute=True, autofill=False, cli_name='ipaenabledflag', multivalue=False, query=True, required=False) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Flag('pkey_only?', autofill=True, default=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Int('sizelimit?', autofill=False, minvalue=0) +option: Int('timelimit?', autofill=False, minvalue=0) +option: Str('version?', exclude='webui') +output: Output('count', , None) +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('truncated', , None) +command: caacl_mod +args: 1,17,3 +arg: Str('cn', attribute=True, cli_name='name', multivalue=False, primary_key=True, query=True, required=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('delattr*', cli_name='delattr', exclude='webui') +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) +option: Bool('ipacaaclallcas', attribute=True, autofill=False, cli_name='allcas', multivalue=False, required=False) +option: Bool('ipacaaclallhosts', attribute=True, autofill=False, cli_name='allhosts', multivalue=False, required=False) +option: Bool('ipacaaclallprofiles', attribute=True, autofill=False, cli_name='allprofiles', multivalue=False, required=False) +option: Bool('ipacaaclallservices', attribute=True, autofill=False, cli_name='allservices', multivalue=False, required=False) +option: Bool('ipacaaclallusers', attribute=True, autofill=False, cli_name='allusers', multivalue=False, required=False) +option: Str('ipacaaclcaref', attribute=True, autofill=False, cli_name='ca_ref', multivalue=True, required=False) +option: Str('ipacaaclprofileid', attribute=True, autofill=False, cli_name='profile_id', multivalue=True, required=False) +option: Bool('ipaenabledflag', attribute=True, autofill=False, cli_name='ipaenabledflag', multivalue=False, required=False) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: caacl_remove_host +args: 1,6,3 +arg: Str('cn', attribute=True, cli_name='name', multivalue=False, primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('host*', alwaysask=True, cli_name='hosts', csv=True) +option: Str('hostgroup*', alwaysask=True, cli_name='hostgroups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +command: caacl_remove_service +args: 1,5,3 +arg: Str('cn', attribute=True, cli_name='name', multivalue=False, 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: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('service*', alwaysask=True, cli_name='services', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +command: caacl_remove_user +args: 1,6,3 +arg: Str('cn', attribute=True, cli_name='name', multivalue=False, primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +command: caacl_show +args: 1,5,3 +arg: Str('cn', attribute=True, cli_name='name', multivalue=False, 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: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) command: cert_find args: 0,17,4 option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') diff --git a/install/share/60certificate-profiles.ldif b/install/share/60certificate-profiles.ldif index f1281949e53386e5bfe8b35e0c15858c693c5467..d8f008c5baed4e0021944bcbaa7256aa250e5c23 100644 --- a/install/share/60certificate-profiles.ldif +++ b/install/share/60certificate-profiles.ldif @@ -1,3 +1,11 @@ dn: cn=schema attributeTypes: (2.16.840.1.113730.3.8.21.1.1 NAME 'ipaCertProfileStoreIssued' DESC 'Store certificates issued using this profile' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA v4.2' ) +attributeTypes: (2.16.840.1.113730.3.8.21.1.2 NAME 'ipaCaAclCaRef' DESC 'Certificate Authority Reference' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 X-ORIGIN 'IPA v4.2' ) +attributeTypes: (2.16.840.1.113730.3.8.21.1.3 NAME 'ipaCaAclProfileId' DESC 'Certificate Profile ID' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 X-ORIGIN 'IPA v4.2' ) +attributeTypes: (2.16.840.1.113730.3.8.21.1.4 NAME 'ipaCaAclAllCAs' DESC 'Allow use of all CAs' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA v4.2' ) +attributeTypes: (2.16.840.1.113730.3.8.21.1.5 NAME 'ipaCaAclAllProfiles' DESC 'Allow ues of all profiles' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA v4.2' ) +attributeTypes: (2.16.840.1.113730.3.8.21.1.6 NAME 'ipaCaAclAllUsers' DESC 'Allow all users' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA v4.2' ) +attributeTypes: (2.16.840.1.113730.3.8.21.1.7 NAME 'ipaCaAclAllHosts' DESC 'Allow all hosts' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA v4.2' ) +attributeTypes: (2.16.840.1.113730.3.8.21.1.8 NAME 'ipaCaAclAllServices' DESC 'Allow all services' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA v4.2' ) objectClasses: (2.16.840.1.113730.3.8.21.2.1 NAME 'ipaCertProfile' SUP top STRUCTURAL MUST ( cn $ description $ ipaCertProfileStoreIssued ) X-ORIGIN 'IPA v4.2' ) +objectClasses: (2.16.840.1.113730.3.8.21.2.2 NAME 'ipaCaAcl' SUP ipaAssociation STRUCTURAL MUST cn MAY ( ipaCaAclCaRef $ ipaCaAclProfileId $ ipaCaAclAllCAs $ ipaCaAclAllProfiles $ ipaCaAclAllUsers $ ipaCaAclAllHosts $ ipaCaAclAllServices $ memberService ) X-ORIGIN 'IPA v4.2' ) diff --git a/install/share/Makefile.am b/install/share/Makefile.am index 31f391be25c58b76cc71971852074d80c5514745..e97a89ca93f7f188e06dc982bd69e251f8082df3 100644 --- a/install/share/Makefile.am +++ b/install/share/Makefile.am @@ -29,6 +29,7 @@ app_DATA = \ bootstrap-template.ldif \ caJarSigningCert.cfg.template \ default-aci.ldif \ + default-caacl.ldif \ default-hbac.ldif \ default-smb-group.ldif \ default-trust-view.ldif \ diff --git a/install/share/bootstrap-template.ldif b/install/share/bootstrap-template.ldif index c5d4bad8b80640881f4631e4873a12c82b0ea48a..2387f220fd4fe6e3ccd59f4b592f2473d7acfa44 100644 --- a/install/share/bootstrap-template.ldif +++ b/install/share/bootstrap-template.ldif @@ -441,3 +441,9 @@ changetype: add objectClass: nsContainer objectClass: top cn: certprofiles + +dn: cn=caacls,cn=ca,$SUFFIX +changetype: add +objectClass: nsContainer +objectClass: top +cn: caacls diff --git a/install/share/default-caacl.ldif b/install/share/default-caacl.ldif new file mode 100644 index 0000000000000000000000000000000000000000..b902c2f84a6898ae51e8123956496d64b6356d3e --- /dev/null +++ b/install/share/default-caacl.ldif @@ -0,0 +1,12 @@ +# default CA ACL that grants use of caIPAserviceCert on top-level CA to all hosts and services +dn: ipauniqueid=autogenerate,cn=caacls,cn=ca,$SUFFIX +changetype: add +objectclass: ipaassociation +objectclass: ipacaacl +ipauniqueid: autogenerate +cn: hosts_services_caIPAserviceCert +ipaenabledflag: TRUE +ipacaaclcaref: . +ipacaaclprofileid: caIPAserviceCert +ipacaaclallhosts: TRUE +ipacaaclallservices: TRUE diff --git a/install/updates/41-caacl.update b/install/updates/41-caacl.update new file mode 100644 index 0000000000000000000000000000000000000000..a18b6ec946855c194077d9ac01a8adcfddf8542e --- /dev/null +++ b/install/updates/41-caacl.update @@ -0,0 +1,4 @@ +dn: cn=caacls,cn=ca,$SUFFIX +default: objectClass: nsContainer +default: objectClass: top +default: cn: caacls diff --git a/install/updates/Makefile.am b/install/updates/Makefile.am index fc6bd624eac619cdddeba29b85440571d85fd69f..eddf4d850ed4b47d5526dc152149fa21b14779d4 100644 --- a/install/updates/Makefile.am +++ b/install/updates/Makefile.am @@ -35,6 +35,7 @@ app_DATA = \ 40-certprofile.update \ 40-otp.update \ 40-vault.update \ + 41-caacl.update \ 45-roles.update \ 50-7_bit_check.update \ 50-dogtag10-migration.update \ diff --git a/ipalib/constants.py b/ipalib/constants.py index 96396a236b8694b3dd988dfe28c1b0c3cc9e3180..9812f843e1e4ced9244f3efd6a9bb6f4c2769655 100644 --- a/ipalib/constants.py +++ b/ipalib/constants.py @@ -119,6 +119,7 @@ DEFAULT_CONFIG = ( ('container_views', DN(('cn', 'views'), ('cn', 'accounts'))), ('container_masters', DN(('cn', 'masters'), ('cn', 'ipa'), ('cn', 'etc'))), ('container_certprofile', DN(('cn', 'certprofiles'), ('cn', 'ca'))), + ('container_caacl', DN(('cn', 'caacls'), ('cn', 'ca'))), # Ports, hosts, and URIs: ('xmlrpc_uri', 'http://localhost:8888/ipa/xml'), diff --git a/ipalib/plugins/caacl.py b/ipalib/plugins/caacl.py new file mode 100644 index 0000000000000000000000000000000000000000..84dc6d3c4db5f46d76bed560023b7cb63c5513b1 --- /dev/null +++ b/ipalib/plugins/caacl.py @@ -0,0 +1,343 @@ +# +# Copyright (C) 2015 FreeIPA Contributors see COPYING for license +# + +from ipalib import api, errors, output +from ipalib import Bool, Str +from ipalib.plugable import Registry +from ipalib.plugins.baseldap import ( + LDAPObject, LDAPSearch, LDAPCreate, LDAPDelete, LDAPQuery, + LDAPUpdate, LDAPRetrieve, LDAPAddMember, LDAPRemoveMember, + pkey_to_value) +from ipalib.plugins.certprofile import validate_profile_id +from ipalib import _, ngettext +from ipapython.dn import DN + + +__doc__ = _(""" +Manage CA ACL rules. + +This plugin is used to define rules governing which principals are +permitted to have certificates issued using a given certificate +profile. + +PROFILE ID SYNTAX: + +A Profile ID is a string without spaces or punctuation starting with a letter +and followed by a sequence of letters, digits or underscore ("_"). + +EXAMPLES: + + Create a CA ACL "test" that grants all users access to the + "UserCert" profile: + ipa caacl-add test --profile-id=UserCert --allusers=1 + + Display the properties of a named CA ACL: + ipa caacl-show test + + Create a CA ACL to let user "alice" use the "DNP3" profile: + ipa caacl-add john_dnp3 --profile-id=DNP3 + ipa caacl-add-user --user=alice + + Disable a CA ACL: + ipa caacl-disable test + + Remove a CA ACL: + ipa caacl-del test +""") + +register = Registry() + + + at register() +class caacl(LDAPObject): + """ + CA ACL object. + """ + container_dn = api.env.container_caacl + object_name = _('CA ACL') + object_name_plural = _('CA ACLs') + object_class = ['ipaassociation', 'ipacaacl'] + permission_filter_objectclasses = ['ipacaacl'] + default_attributes = [ + 'cn', 'description', 'ipaenabledflag', + 'ipacaaclprofileid', 'ipacaaclcaref', + 'ipacaaclallcas', 'ipacaaclallprofiles', + 'ipacaaclallusers', 'ipacaaclallhosts', 'ipacaaclallservices', + 'memberuser', 'memberhost', 'memberservice', 'memberhostgroup', + ] + uuid_attribute = 'ipauniqueid' + rdn_attribute = 'ipauniqueid' + attribute_members = { + 'memberuser': ['user', 'group'], + 'memberhost': ['host', 'hostgroup'], + 'memberservice': ['service'], + } + managed_permissions = { + 'System: Read CA ACLs': { + 'replaces_global_anonymous_aci': True, + 'ipapermbindruletype': 'all', + 'ipapermright': {'read', 'search', 'compare'}, + 'ipapermdefaultattr': { + 'cn', 'description', 'ipaenabledflag', + 'ipacaaclprofileid', 'ipacaaclcaref', + 'ipacaaclallcas', 'ipacaaclallprofiles', + 'ipacaaclallusers', 'ipacaaclallhosts', 'ipacaaclallservices', + 'ipauniqueid', 'memberhost', 'memberservice', 'memberuser', + 'objectclass', 'member', + }, + }, + 'System: Add CA ACL': { + 'ipapermright': {'add'}, + 'replaces': [ + '(target = "ldap:///ipauniqueid=*,cn=caacls,cn=ca,$SUFFIX")(version 3.0;acl "permission:Add CA ACL";allow (add) groupdn = "ldap:///cn=Add CA ACL,cn=permissions,cn=pbac,$SUFFIX";)', + ], + 'default_privileges': {'CA Administrator'}, + }, + 'System: Delete CA ACL': { + 'ipapermright': {'delete'}, + 'replaces': [ + '(target = "ldap:///ipauniqueid=*,cn=caacls,cn=ca,$SUFFIX")(version 3.0;acl "permission:Delete CA ACL";allow (delete) groupdn = "ldap:///cn=Delete CA ACL,cn=permissions,cn=pbac,$SUFFIX";)', + ], + 'default_privileges': {'CA Administrator'}, + }, + 'System: Manage CA ACL Membership': { + 'ipapermright': {'write'}, + 'ipapermdefaultattr': { + 'memberhost', 'memberservice', 'memberuser', + 'ipacaaclallusers', 'ipacaaclallhosts', 'ipacaaclallservices', + }, + 'replaces': [ + '(targetattr = "memberuser || memberservice || memberhost || ipacaaclallusers || ipacaaclallhosts || ipacaaclallservices")(target = "ldap:///ipauniqueid=*,cn=caacls,cn=ca,$SUFFIX")(version 3.0;acl "permission:Manage CA ACL membership";allow (write) groupdn = "ldap:///cn=Manage CA ACL membership,cn=permissions,cn=pbac,$SUFFIX";)', + ], + 'default_privileges': {'CA Administrator'}, + }, + 'System: Modify CA ACL': { + 'ipapermright': {'write'}, + 'ipapermdefaultattr': { + 'cn', 'description', 'ipaenabledflag', + 'ipacaaclallcas', 'ipacaaclallprofiles', + 'ipacaaclprofileid', 'ipacaaclcaref', + }, + 'replaces': [ + '(targetattr = "cn || description || ipaenabledflag || ipacaaclprofileid || ipacaaclcaref || ipacaaclallcas || ipacaaclallprofiles")(target = "ldap:///ipauniqueid=*,cn=caacls,cn=ca,$SUFFIX")(version 3.0;acl "permission:Modify CA ACL";allow (write) groupdn = "ldap:///cn=Modify CA ACL,cn=permissions,cn=pbac,$SUFFIX";)', + ], + 'default_privileges': {'CA Administrator'}, + }, + } + + label = _('CA ACLs') + label_singular = _('CA ACL') + + takes_params = ( + Str('cn', + cli_name='name', + label=_('ACL name'), + primary_key=True, + ), + Str('description?', + cli_name='desc', + label=_('Description'), + ), + Bool('ipaenabledflag?', + label=_('Enabled'), + flags=['no_option'], + ), + Str('ipacaaclprofileid*', validate_profile_id, + cli_name='profile_id', + label=_('Profile ID'), + ), + Str('ipacaaclcaref*', # validate sub-CA handle syntax + cli_name='ca_ref', + label=_('CA Reference'), + flags=['no_option', 'no_output'], # until sub-CAs are implemented + ), + Bool('ipacaaclallcas?', + cli_name='allcas', + label=_('Allow use of all CAs'), + flags=['no_option', 'no_output'], # until sub-CAs are implemented + ), + Bool('ipacaaclallprofiles?', + cli_name='allprofiles', + label=_('Allow use of all profiles'), + ), + Bool('ipacaaclallusers?', + cli_name='allusers', + label=_('Allow all users'), + ), + Bool('ipacaaclallhosts?', + cli_name='allhosts', + label=_('Allow all hosts'), + ), + Bool('ipacaaclallservices?', + cli_name='allservices', + label=_('Allow all services'), + ), + Str('memberuser_user?', + label=_('Users'), + flags=['no_create', 'no_update', 'no_search'], + ), + Str('memberuser_group?', + label=_('User Groups'), + flags=['no_create', 'no_update', 'no_search'], + ), + Str('memberhost_host?', + label=_('Hosts'), + flags=['no_create', 'no_update', 'no_search'], + ), + Str('memberhost_hostgroup?', + label=_('Host Groups'), + flags=['no_create', 'no_update', 'no_search'], + ), + Str('memberservice_service?', + label=_('Services'), + flags=['no_create', 'no_update', 'no_search'], + ), + ) + + + at register() +class caacl_add(LDAPCreate): + __doc__ = _('Create a new CA ACL.') + + msg_summary = _('Added CA ACL "%(value)s"') + + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): + # CA ACLs are enabled by default + entry_attrs['ipaenabledflag'] = ['TRUE'] + entry_attrs['ipacaaclcaref'] = ['.'] + return dn + + + at register() +class caacl_del(LDAPDelete): + __doc__ = _('Delete a CA ACL.') + + msg_summary = _('Deleted CA ACL "%(value)s"') + + + at register() +class caacl_mod(LDAPUpdate): + __doc__ = _('Modify a CA ACL.') + + msg_summary = _('Modified CA ACL "%(value)s"') + + + at register() +class caacl_find(LDAPSearch): + __doc__ = _('Search for CA ACLs.') + + msg_summary = ngettext( + '%(count)d CA ACL matched', '%(count)d CA ACLs matched', 0 + ) + + + at register() +class caacl_show(LDAPRetrieve): + __doc__ = _('Display the properties of a CA ACL.') + + + at register() +class caacl_enable(LDAPQuery): + __doc__ = _('Enable a CA ACL.') + + msg_summary = _('Enabled CA ACL "%(value)s"') + has_output = output.standard_value + + def execute(self, cn, **options): + ldap = self.obj.backend + + dn = self.obj.get_dn(cn) + try: + entry_attrs = ldap.get_entry(dn, ['ipaenabledflag']) + except errors.NotFound: + self.obj.handle_not_found(cn) + + entry_attrs['ipaenabledflag'] = ['TRUE'] + + try: + ldap.update_entry(entry_attrs) + except errors.EmptyModlist: + pass + + return dict( + result=True, + value=pkey_to_value(cn, options), + ) + + + at register() +class caacl_disable(LDAPQuery): + __doc__ = _('Disable a CA ACL.') + + msg_summary = _('Disabled CA ACL "%(value)s"') + has_output = output.standard_value + + def execute(self, cn, **options): + ldap = self.obj.backend + + dn = self.obj.get_dn(cn) + try: + entry_attrs = ldap.get_entry(dn, ['ipaenabledflag']) + except errors.NotFound: + self.obj.handle_not_found(cn) + + entry_attrs['ipaenabledflag'] = ['FALSE'] + + try: + ldap.update_entry(entry_attrs) + except errors.EmptyModlist: + pass + + return dict( + result=True, + value=pkey_to_value(cn, options), + ) + + + at register() +class caacl_add_user(LDAPAddMember): + __doc__ = _('Add users and groups to a CA ACL.') + + member_attributes = ['memberuser'] + member_count_out = ('%i object added.', '%i objects added.') + + + at register() +class caacl_remove_user(LDAPRemoveMember): + __doc__ = _('Remove users and groups from a CA ACL.') + + member_attributes = ['memberuser'] + member_count_out = ('%i object removed.', '%i objects removed.') + + + at register() +class caacl_add_host(LDAPAddMember): + __doc__ = _('Add target hosts and hostgroups to a CA ACL.') + + member_attributes = ['memberhost'] + member_count_out = ('%i object added.', '%i objects added.') + + + at register() +class caacl_remove_host(LDAPRemoveMember): + __doc__ = _('Remove target hosts and hostgroups from a CA ACL.') + + member_attributes = ['memberhost'] + member_count_out = ('%i object removed.', '%i objects removed.') + + + at register() +class caacl_add_service(LDAPAddMember): + __doc__ = _('Add services to a CA ACL.') + + member_attributes = ['memberservice'] + member_count_out = ('%i object added.', '%i objects added.') + + + at register() +class caacl_remove_service(LDAPRemoveMember): + __doc__ = _('Remove service and service groups from a CA ACL.') + + member_attributes = ['memberservice'] + member_count_out = ('%i object removed.', '%i objects removed.') diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py index 2acab13f247ed18a750f0e1cbbd98f4e63718c03..9f24189b6e442e0c55d5de41d15a03f89ecc9578 100644 --- a/ipaserver/install/dsinstance.py +++ b/ipaserver/install/dsinstance.py @@ -307,6 +307,7 @@ class DsInstance(service.Service): self.step("adding range check plugin", self.__add_range_check_plugin) if hbac_allow: self.step("creating default HBAC rule allow_all", self.add_hbac) + self.step("creating default CA ACL rule", self.add_caacl) self.step("adding entries for topology management", self.__add_topology_entries) self.__common_post_setup() @@ -741,6 +742,9 @@ class DsInstance(service.Service): def add_hbac(self): self._ldap_mod("default-hbac.ldif", self.sub_dict) + def add_caacl(self): + self._ldap_mod("default-caacl.ldif", self.sub_dict) + def change_admin_password(self, password): root_logger.debug("Changing admin password") dirname = config_dirname(self.serverid) -- 2.1.0 -------------- next part -------------- >From 0c8b27921ee6c134b09a2a31a5f49ad9bec4bd2d Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Tue, 26 May 2015 04:44:20 -0400 Subject: [PATCH 13/13] Enforce CA ACLs in cert-request command This commit adds CA ACL enforcement to the cert-request command and uses the pyhbac machinery. It is planned to implement ACL enforcement in Dogtag in a future release, and remove certificate issuance privileges and CA ACL enforcement responsibility from the framework. See https://fedorahosted.org/freeipa/ticket/5011 for more information. Part of: https://fedorahosted.org/freeipa/ticket/57 Part of: https://fedorahosted.org/freeipa/ticket/4559 --- ipalib/plugins/caacl.py | 72 +++++++++++++++++++++++++++++++++++++++++++++++++ ipalib/plugins/cert.py | 17 ++++++++++++ 2 files changed, 89 insertions(+) diff --git a/ipalib/plugins/caacl.py b/ipalib/plugins/caacl.py index 84dc6d3c4db5f46d76bed560023b7cb63c5513b1..c09df863847f0e2b0e029b5c7f82d978a7e159bf 100644 --- a/ipalib/plugins/caacl.py +++ b/ipalib/plugins/caacl.py @@ -2,6 +2,8 @@ # Copyright (C) 2015 FreeIPA Contributors see COPYING for license # +import pyhbac + from ipalib import api, errors, output from ipalib import Bool, Str from ipalib.plugable import Registry @@ -10,6 +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 import _, ngettext from ipapython.dn import DN @@ -49,6 +52,75 @@ EXAMPLES: register = Registry() +def _acl_make_request(principal_type, principal, ca_ref, profile_id): + """Construct HBAC request for the given principal, CA and profile""" + req = pyhbac.HbacRequest() + req.targethost.name = ca_ref + req.service.name = profile_id + if principal_type == 'user': + req.user.name = principal + elif principal_type == 'host': + req.user.name = principal[:5] # strip 'host/' + elif principal_type == 'service': + req.user.name = normalize_principal(principal) + groups = [] + if principal_type == 'user': + user_obj = api.Command.user_show(principal)['result'] + groups = user_obj.get('memberof_group', []) + groups += user_obj.get('memberofindirect_group', []) + elif principal_type == 'host': + hostname = principal[5:] + host_obj = api.Command.host_show(hostname)['result'] + groups = host_obj.get('memberof_hostgroup', []) + groups += host_obj.get('memberofindirect_hostgroup', []) + req.user.groups = sorted(set(groups)) + return req + + +def _acl_make_rule(principal_type, obj): + """Turn CA ACL object into HBAC rule. + + ``principal_type`` + String in {'user', 'host', 'service'} + """ + rule = pyhbac.HbacRule(obj['cn'][0]) + rule.enabled = obj['ipaenabledflag'][0] + rule.srchosts.category = {pyhbac.HBAC_CATEGORY_ALL} + + # add CA(s) + if 'ipacaaclallcas' in obj and obj['ipacaaclallcas'][0] == 'TRUE': + rule.targethosts.category = {pyhbac.HBAC_CATEGORY_ALL} + else: + rule.targethosts.names = obj.get('ipacaaclcaref', []) + + # add profiles + if 'ipacaaclallprofiles' in obj and obj['ipacaaclallprofiles'][0] == 'TRUE': + rule.services.category = {pyhbac.HBAC_CATEGORY_ALL} + else: + rule.services.names = obj.get('ipacaaclprofileid', []) + + # add principals and principal's groups + m = {'user': 'group', 'host': 'hostgroup', 'service': None} + all_principals_attr = 'ipacaaclall{}s'.format(principal_type) + if all_principals_attr in obj and obj[all_principals_attr][0] == 'TRUE': + rule.users.category = {pyhbac.HBAC_CATEGORY_ALL} + else: + principal_attr = 'member{}_{}'.format(principal_type, principal_type) + rule.users.names = obj.get(principal_attr, []) + if m[principal_type] is not None: + group_attr = 'member{}_{}'.format(principal_type, m[principal_type]) + rule.users.groups = obj.get(group_attr, []) + + return rule + + +def acl_evaluate(principal_type, principal, ca_ref, profile_id): + req = _acl_make_request(principal_type, principal, ca_ref, profile_id) + acls = api.Command.caacl_find()['result'] + rules = [_acl_make_rule(principal_type, obj) for obj in acls] + return req.evaluate(rules) == pyhbac.HBAC_EVAL_ALLOW + + @register() class caacl(LDAPObject): """ diff --git a/ipalib/plugins/cert.py b/ipalib/plugins/cert.py index aab2db770c3aae6fbc7d13ae7707f06ba583ba09..062c1b8d8e7f8f04ab531ffb449b3d60aa971fed 100644 --- a/ipalib/plugins/cert.py +++ b/ipalib/plugins/cert.py @@ -33,6 +33,7 @@ from ipalib.plugins.virtual import * from ipalib.plugins.baseldap import pkey_to_value from ipalib.plugins.service import split_any_principal from ipalib.plugins.certprofile import validate_profile_id +import ipalib.plugins.caacl import base64 import traceback from ipalib.text import _ @@ -326,6 +327,22 @@ class cert_request(VirtualCommand): else: principal_type = SERVICE + principal_type_map = {USER: 'user', HOST: 'host', SERVICE: 'service'} + ca = '.' # top-level CA hardcoded until subca plugin implemented + if not ipalib.plugins.caacl.acl_evaluate( + principal_type_map[principal_type], + principal_string, ca, profile_id): + raise errors.ACIError(info=_( + "Principal '%(principal)s' " + "is not permitted to use CA '%(ca)s' " + "with profile '%(profile_id)s' for certificate issuance." + ) % dict( + principal=principal_string, + ca=ca or '.', + profile_id=profile_id + ) + ) + bind_principal = split_any_principal(getattr(context, 'principal')) bind_service, bind_name, bind_realm = bind_principal -- 2.1.0 From simo at redhat.com Tue May 26 17:06:39 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 26 May 2015 13:06:39 -0400 Subject: [Freeipa-devel] Fix password changes via kadmin In-Reply-To: <5562E1FA.3050001@redhat.com> References: <1428274413.19641.118.camel@willson.usersys.redhat.com> <5562E1FA.3050001@redhat.com> Message-ID: <1432659999.3243.62.camel@willson.usersys.redhat.com> On Mon, 2015-05-25 at 10:48 +0200, Martin Babinsky wrote: > On 04/06/2015 12:53 AM, Simo Sorce wrote: > > Fix for bug 4914. > > > > I've tested it locally and seem to do exactly what is needed. I couldn't > > detect any side effects, except that if you use kadmin to get a > > randomized password for a service then you'll get a key for all > > supported types (currently aes256, aes128, des3, rc4, camellia128, > > camellia256) instead of just the default ones (aes256, aes128, des3, > > rc4) if you do not specify enctypes. I think that is fine, we use > > ipa-getkeytab anyway in the normal course of business and that one uses > > a different code path. > > > > Simo. > > > > > > > > Hi Simo, > > the patch works as expected. > > My only gripe is with the duplicate code in 'daemons/ipa-kdb/ipa_kdb.c' > between lines 389 and 455. It could be made into a single function to > get key encoding/salt types from LDAP (see my feeble and untested > attempt which I attached). The attached patch looks reasonable to me, feel free to post it as a proposed patch once you have tested it. Simo. -- Simo Sorce * Red Hat, Inc * New York From edewata at redhat.com Wed May 27 00:38:33 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 26 May 2015 19:38:33 -0500 Subject: [Freeipa-devel] [PATCH] Password vault In-Reply-To: <553498D1.1020901@redhat.com> References: <54E1AF55.3060409@redhat.com> <54EBEB55.6010306@redhat.com> <54F96B22.9050507@redhat.com> <55004D5D.6060300@redhat.com> <550FE5EB.1070606@redhat.com> <551E0AE1.8040500@redhat.com> <553498D1.1020901@redhat.com> Message-ID: <55651209.8020000@redhat.com> Please take a look at the attached patch to add vault-archive/retrieve commands. On 4/20/2015 1:12 AM, Jan Cholasta wrote: >>>>> 16) You do way too much stuff in vault_add.forward(). Only code that >>>>> must be done on the client needs to be there, i.e. handling of the >>>>> "data", "text" and "in" options. >>>>> >>>>> The vault_archive call must be in vault_add.execute(), otherwise a) we >>>>> will be making 2 RPC calls from the client and b) it won't be >>>>> called at >>>>> all when api.env.in_server is True. >>>> >>>> This is done by design. The vault_add.forward() generates the salt and >>>> the keys. The vault_archive.forward() will encrypt the data. These >>>> operations have to be done on the client side to secure the >>>> transport of >>>> the data from the client through the server and finally to KRA. This >>>> mechanism prevents the server from looking at the unencrypted data. >>> >>> OK, but that does not justify that it's broken in server-side API. It >>> can and should be done so that it works the same way on both client and >>> server. >>> >>> I think the best solution would be to split the command into two >>> commands, server-side vault_archive_raw to archive already encrypted >>> data, and client-side vault_archive to encrypt data and archive them >>> with vault_archive_raw in its .execute(). Same thing for vault_retrieve. >> >> Actually I think it's better to just merge the add and archive, reducing >> the number of RPC calls. The vault_archive now will support two types of >> operations: >> >> (a) Archive data into a new vault (it will create the vault just before >> archiving the data): >> >> $ ipa vault-archive testvault --create --in data ... >> >> (b) Archive data into an existing vault: >> >> $ ipa vault-archive testvault --in data ... >> >> The vault_add is now just a wrapper for the vault_archive(a). > > If that's just an implementation detail, OK. > > If it's possible to modify existing vault objects using vault-add or > create new objects using vault-archive, then NACK. The vault-archive is now completely separate from vault-add. You can no longer archive data while creating a vault: $ ipa vault-add test $ ipa vault-archive test --in secret.bin >>> BTW, I also think it would be better if there were 2 separate sets of >>> commands for binary and textual data >>> (vault_{archive,retrieve}_{data,text}) rather than trying to handle >>> everything in vault_{archive,retrieve}. >> >> I don't think we want to provide a separate command of every possible >> data type & operation combination. Users would get confused. The archive >> & retrieve commands should be able to handle all current & future data >> types with options. > > A command with two sets of mutually exclusive options is really two > commands in disguise, which is a good sign it should be divided into two > actual commands. > > Who are you to say users would get confused? I say they would be more > confused by a command with a plethora of mutually exclusive "options". > > What other possible data types are there? The patch has been simplified to support only binary data. The data can be specified using either of these options: $ ipa vault-archive test --data $ ipa vault-archive test --in I don't think we want to provide two separate commands for these options although they are mutually exclusive, do we? >>>> The add & archive combination was added for convenience, not for >>>> optimization. This way you would be able to archive data into a new >>>> vault using a single command. Without this, you'd have to execute two >>>> separate commands: add & archive, which will result in 2 RPC calls >>>> anyway. >>> >>> I think I would prefer if it was separate, as that would be consistent >>> with other plugins (e.g. for objects with members, we don't allow adding >>> members directly in -add, you have to use -add-member after -add). >> >> The vault data is similar to group description, not group members. When >> creating a group we can supply the description. If not specified it will >> be blank. Archiving vault data is similar to updating the group >> description. > > It's similar to group members because there are separate commands to > manipulate them. Just because there are separate commands doesn't mean vault data (single-valued) is similar to group members (multi-valued). It uses separate commands because of the encryption steps involved while archiving/retrieving data. > You have to choose one of: > > a) vault data is settable using vault-add and vault-mod and gettable > using vault-mod, vault-show and vault-find > > b) vault data is settable using vault-archive and gettable using > vault-retrieve > > Anything in between is not permitted. As mentioned above, the add and archive commands are now separate. >>>>> 21) vault_archive is not a retrieve operation, it should be based on >>>>> LDAPUpdate instead of LDAPRetrieve. Or Command actually, since it does >>>>> not do anything with LDAP. The same applies to vault_retrieve. >>>> >>>> The vault_archive does not actually modify the LDAP entry because it >>>> stores the data in KRA. It is actually an LDAPRetrieve operation >>>> because >>>> it needs to get the vault info before it can perform the archival >>>> operation. Same thing with vault_retrieve. >>> >>> It is not a LDAPRetrieve operation, because it has different semantics. >>> Please use Command as base class and either use ldap2 for direct LDAP or >>> call vault_show instead of hacking around LDAPRetrieve. >> >> It's been changed to inherit from LDAPQuery instead. > > NACK, it's not a LDAPQuery operation, because it has different > semantics. There is more to a command than executing code, so you should > use a correct base class. Changed to inherit from Command as requested. Now these commands no longer have a direct access to the vault object (self.obj) although they are accessing vault objects like other vault commands. Also now the vault name argument has to be added explicitly on each command. There are existing commands that inherit from LDAPQuery while doing other things too, so the 'semantic' seems to be kind of arbitrarily defined and subjective. >>>>> 22) vault_archive will break with binary data that is not UTF-8 >>>>> encoded >>>>> text. >>>>> >>>>> This is where it occurs: >>>>> >>>>> + vault_data[u'data'] = unicode(data) >>>>> >>>>> Generally, don't use unicode() on str values and str() on unicode >>>>> values >>>>> directly, always use .decode() and .encode(). >> >> The unicode(s, encoding) is actually equivalent to s.decode(encoding), >> so the following code will not solve the problem: >> >> vault_data[u'data'] = data.decode() >> >> As you said, decode() will only work if the data being decoded actually >> follows the encoding rules (i.e. already UTF-8 encoded). >> >>>> It needs to be a Unicode because json.dumps() doesn't work with binary >>>> data. Fixed by adding base-64 encoding. >> >> The base-64 encoding is necessary to convert random binaries into ASCII >> so it can be decoded into Unicode. Here is the current code: >> >> vault_data[u'data'] = unicode(base64.b64encode(data)) >> >> which is equivalent to: >> >> vault_data[u'data'] = base64.b64encode(data).decode() > > If you read a little bit further, you would get to the point, which is > certainly not calling .decode() without arguments, but *always > explicitly specify the encoding*. Added the explicit encoding name although it's not necessary since the data being encoded/decoded is base-64 encoded (i.e. ASCII). >>> If something str needs to be unicode, you should use .decode() to >>> explicitly specify the encoding, instead of relying on unicode() to pick >>> the correct one. >> >> Since we know this is ASCII data we can now specify UTF-8 encoding. >> >> vault_data[u'data'] = base64.b64encode(data).decode('utf-8') >> >> But for anything that comes from user input (e.g. filenames, passwords), >> it's better to use the default encoding because that can be configured >> by the user. > > You are confusing user's configured encoding with Python's default > encoding. Default encoding in Python isn't derived from user's > localization settings. > > Anyway, anything that comes from user input is already decoded using > user's configured encoding when it enters the framework so I don't know > why are you even bringing it up here. It's irrelevant now that the command only supports binary data. >>> Anyway, I think a better solution than base64 would be to use the >>> "raw_unicode_escape" encoding: >> >> As explained above, base-64 encoding is necessary because random >> binaries don't follow any encoding rules. I'd rather not use >> raw_unicode_escape because it's not really a text data. > > The result of decoding binary data using raw_unicode_escape is perfectly > valid unicode data which doesn't eat 33% more space like base64 encoded > binary does, hence my suggestion. > > Anyway, it turns out when encoded in JSON, raw_unicode_escape string > generally takes more space than base64 encoded string because of JSON > escaping, so base64 is indeed better. Unchanged. It still uses base-64 encoding. >> Here's how it's >> now implemented: >> >>> if data: >>> data = data.decode('raw_unicode_escape') >> >> Input data is already in binaries, no conversion needed. >> >>> elif text: >>> data = text >> >> Input text will be converted to binaries with default encoding: >> >> data = text.encode() > > See what the default encoding actually is and why you shouldn't rely on > it above. Irrelevant now. >>> elif input_file: >>> with open(input_file, 'rb') as f: >>> data = f.read() >>> data = data.decode('raw_unicode_escape') >> >> Input contains binary data, no conversion needed. >> >>> else: >>> data = u'' >> >> If not specified, the data will be empty string: >> >> data = '' >> >> The data needs to be converted into binaries so it can be encrypted >> before transport (depending on the vault type): >> >> data = self.obj.encrypt(data, ...) >> >>> vault_data[u'data'] = data >> >> Then for transport the data is base-64 encoded first, then converted >> into Unicode: >> >> vault_data[u'data'] = base64.b64encode(data).decode('utf-8') -- Endi S. Dewata -------------- next part -------------- >From bdd5c6900509e223ba54aa105a77f8404579e2b7 Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Tue, 21 Oct 2014 10:57:08 -0400 Subject: [PATCH] Added vault-archive and vault-retrieve commands. New commands have been added to archive and retrieve data into and from a vault, also to retrieve the transport certificate. https://fedorahosted.org/freeipa/ticket/3872 --- API.txt | 28 ++ VERSION | 4 +- ipalib/plugins/vault.py | 452 +++++++++++++++++++++++++++++- ipatests/test_xmlrpc/test_vault_plugin.py | 71 ++++- 4 files changed, 551 insertions(+), 4 deletions(-) diff --git a/API.txt b/API.txt index da69f32de5c12c0d85a7d61d9027385aa3c0ee05..3741e6f16689e43838c2d31a44872d1ea47589c7 100644 --- a/API.txt +++ b/API.txt @@ -4768,6 +4768,24 @@ option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) +command: vault_archive +args: 1,9,1 +arg: Str('cn', cli_name='name', maxlength=255, pattern='^[a-zA-Z0-9_.-]+$') +option: Bytes('data?') +option: Str('in?') +option: Str('nonce?') +option: Str('service?') +option: Str('session_key?') +option: Flag('shared?', autofill=True, default=False) +option: Str('user?') +option: Str('vault_data?') +option: Str('version?', exclude='webui') +output: Output('result', None, None) +command: vault_config +args: 0,2,1 +option: Str('transport_out?') +option: Str('version?', exclude='webui') +output: Output('result', None, None) command: vault_del args: 1,5,3 arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=True, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) @@ -4814,6 +4832,16 @@ option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) +command: vault_retrieve +args: 1,6,1 +arg: Str('cn', cli_name='name', maxlength=255, pattern='^[a-zA-Z0-9_.-]+$') +option: Str('out?') +option: Str('service?') +option: Str('session_key?') +option: Flag('shared?', autofill=True, default=False) +option: Str('user?') +option: Str('version?', exclude='webui') +output: Output('result', None, None) command: vault_show args: 1,7,3 arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) diff --git a/VERSION b/VERSION index 07c00d000064a7687497b09524aa821dbcecc88a..2bfb2fe46b3760f30e1aa378841544a51f014728 100644 --- a/VERSION +++ b/VERSION @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 # # ######################################################## IPA_API_VERSION_MAJOR=2 -IPA_API_VERSION_MINOR=121 -# Last change: pvoborni - added server-find and server-show +IPA_API_VERSION_MINOR=122 +# Last change: edewata - added vault-archive and vault-retrieve diff --git a/ipalib/plugins/vault.py b/ipalib/plugins/vault.py index ebb9f9fd3cf3b5a7d6b44ac9e63e122e8f71aa1a..c6fd41063058672a90a95979a907876161f3256a 100644 --- a/ipalib/plugins/vault.py +++ b/ipalib/plugins/vault.py @@ -17,8 +17,21 @@ # You should have received a copy of the GNU General Public License # along with this program. If not, see . +import base64 +import json +import os +import sys +import tempfile + +import nss.nss as nss + +import pki.account +import pki.crypto +import pki.key + +from ipalib.frontend import Command from ipalib import api, errors -from ipalib import Str, Flag +from ipalib import Bytes, Str, Flag from ipalib import output from ipalib.plugable import Registry from ipalib.plugins.baseldap import LDAPObject, LDAPCreate, LDAPDelete,\ @@ -26,7 +39,9 @@ from ipalib.plugins.baseldap import LDAPObject, LDAPCreate, LDAPDelete,\ from ipalib.request import context from ipalib.plugins.user import split_principal from ipalib import _, ngettext +from ipaplatform.paths import paths from ipapython.dn import DN +from ipapython.nsslib import current_dbdir __doc__ = _(""" Vaults @@ -94,6 +109,33 @@ EXAMPLES: """) + _(""" Delete a user vault: ipa vault-del --user +""") + _(""" + Display vault configuration: + ipa vault-config +""") + _(""" + Archive data into private vault: + ipa vault-archive --in +""") + _(""" + Archive data into service vault: + ipa vault-archive --service --in +""") + _(""" + Archive data into shared vault: + ipa vault-archive --shared --in +""") + _(""" + Archive data into user vault: + ipa vault-archive --user --in +""") + _(""" + Retrieve data from private vault: + ipa vault-retrieve --out +""") + _(""" + Retrieve data from service vault: + ipa vault-retrieve --service --out +""") + _(""" + Retrieve data from shared vault: + ipa vault-retrieve --shared --out +""") + _(""" + Retrieve data from user vault: + ipa vault-retrieve --user --out """) register = Registry() @@ -243,6 +285,26 @@ class vault(LDAPObject): for entry in entries: self.backend.add_entry(entry) + def get_key_id(self, dn): + """ + Generates a client key ID to archive/retrieve data in KRA. + """ + + # TODO: create container_dn after object initialization then reuse it + container_dn = DN(self.container_dn, self.api.env.basedn) + + # make sure the DN is a vault DN + if not dn.endswith(container_dn, 1): + raise ValueError('Invalid vault DN: %s' % dn) + + # construct the vault ID from the bottom up + id = u'' + for rdn in dn[:-len(container_dn)]: + name = rdn['cn'] + id = u'/' + name + id + + return 'ipa:' + id + @register() class vault_add(LDAPCreate): @@ -273,6 +335,29 @@ class vault_del(LDAPDelete): msg_summary = _('Deleted vault "%(value)s"') + def post_callback(self, ldap, dn, *args, **options): + assert isinstance(dn, DN) + + kra_client = self.api.Backend.kra.get_client() + + kra_account = pki.account.AccountClient(kra_client.connection) + kra_account.login() + + client_key_id = self.obj.get_key_id(dn) + + # deactivate vault record in KRA + response = kra_client.keys.list_keys( + client_key_id, pki.key.KeyClient.KEY_STATUS_ACTIVE) + + for key_info in response.key_infos: + kra_client.keys.modify_key_status( + key_info.get_key_id(), + pki.key.KeyClient.KEY_STATUS_INACTIVE) + + kra_account.logout() + + return True + @register() class vault_find(LDAPSearch): @@ -319,3 +404,368 @@ class vault_show(LDAPRetrieve): __doc__ = _('Display information about a vault.') takes_options = LDAPRetrieve.takes_options + vault_options + + + at register() +class vault_config(Command): + __doc__ = _('Show vault configuration.') + + takes_options = ( + Str( + 'transport_out?', + doc=_('Output file to store the transport certificate'), + ), + ) + + has_output_params = ( + Str( + 'transport_cert', + label=_('Transport Certificate'), + ), + ) + + def forward(self, *args, **options): + + file = options.get('transport_out') + + # don't send these parameters to server + if 'transport_out' in options: + del options['transport_out'] + + response = super(vault_config, self).forward(*args, **options) + + if file: + with open(file, 'w') as f: + f.write(response['result']['transport_cert']) + + return response + + def execute(self, *args, **options): + + kra_client = self.api.Backend.kra.get_client() + transport_cert = kra_client.system_certs.get_transport_cert() + return { + 'result': { + 'transport_cert': transport_cert.encoded + } + } + + + at register() +class vault_archive(Command): + __doc__ = _('Archive data into a vault.') + + takes_args = ( + Str( + 'cn', + cli_name='name', + label=_('Vault name'), + pattern='^[a-zA-Z0-9_.-]+$', + pattern_errmsg='may only include letters, numbers, _, ., and -', + maxlength=255, + ), + ) + + takes_options = vault_options + ( + Bytes( + 'data?', + doc=_('Binary data to archive'), + ), + Str( # TODO: use File parameter + 'in?', + doc=_('File containing data to archive'), + ), + Str( + 'session_key?', + doc=_( + 'Session key wrapped with transport certificate' + ' and encoded in base-64'), + ), + Str( + 'vault_data?', + doc=_( + 'Vault data encrypted with session key' + ' and encoded in base-64'), + ), + Str( + 'nonce?', + doc=_('Nonce encrypted encoded in base-64'), + ), + ) + + msg_summary = _('Archived data into vault "%(value)s"') + + def forward(self, *args, **options): + + data = options.get('data') + input_file = options.get('in') + + # don't send these parameters to server + if 'data' in options: + del options['data'] + if 'in' in options: + del options['in'] + + # get data + if data and input_file: + raise errors.MutuallyExclusiveError( + reason=_('Input data specified multiple times')) + + if input_file: + with open(input_file, 'rb') as f: + data = f.read() + + elif not data: + data = '' + + # initialize NSS database + crypto = pki.crypto.NSSCryptoProvider(paths.IPA_NSSDB_DIR) + crypto.initialize() + current_dbdir = paths.IPA_NSSDB_DIR + + # retrieve transport certificate + (file, filename) = tempfile.mkstemp() + os.close(file) + try: + self.api.Command.vault_config(transport_out=unicode(filename)) + transport_cert_der = nss.read_der_from_file(filename, True) + nss_transport_cert = nss.Certificate(transport_cert_der) + + finally: + os.remove(filename) + + # generate session key + session_key = crypto.generate_session_key() + + # wrap session key with transport certificate + wrapped_session_key = crypto.asymmetric_wrap( + session_key, + nss_transport_cert + ) + + options['session_key'] = base64.b64encode(wrapped_session_key)\ + .decode('utf-8') + + nonce = crypto.generate_nonce_iv() + options['nonce'] = base64.b64encode(nonce).decode('utf-8') + + vault_data = {} + vault_data[u'data'] = base64.b64encode(data).decode('utf-8') + + json_vault_data = json.dumps(vault_data) + + # wrap vault_data with session key + wrapped_vault_data = crypto.symmetric_wrap( + json_vault_data, + session_key, + nonce_iv=nonce + ) + + options['vault_data'] = base64.b64encode(wrapped_vault_data)\ + .decode('utf-8') + + return super(vault_archive, self).forward(*args, **options) + + def execute(self, *args, **options): + + vault_name = args[0] + + # retrieve vault info + vault = self.api.Command.vault_show( + vault_name, + service=options.get('service'), + shared=options.get('shared'), + user=options.get('user'), + )['result'] + + # connect to KRA + kra_client = self.api.Backend.kra.get_client() + + kra_account = pki.account.AccountClient(kra_client.connection) + kra_account.login() + + client_key_id = self.api.Object.vault.get_key_id(vault['dn']) + + # deactivate existing vault record in KRA + response = kra_client.keys.list_keys( + client_key_id, + pki.key.KeyClient.KEY_STATUS_ACTIVE) + + for key_info in response.key_infos: + kra_client.keys.modify_key_status( + key_info.get_key_id(), + pki.key.KeyClient.KEY_STATUS_INACTIVE) + + wrapped_session_key = base64.b64decode(options['session_key']) + nonce = base64.b64decode(options['nonce']) + + # forward wrapped data to KRA + wrapped_vault_data = base64.b64decode(options['vault_data']) + + kra_client.keys.archive_encrypted_data( + client_key_id, + pki.key.KeyClient.PASS_PHRASE_TYPE, + wrapped_vault_data, + wrapped_session_key, + None, + nonce, + ) + + kra_account.logout() + + response = {} + response['result'] = {} + + return response + + + at register() +class vault_retrieve(Command): + __doc__ = _('Retrieve a data from a vault.') + + takes_args = ( + Str( + 'cn', + cli_name='name', + label=_('Vault name'), + pattern='^[a-zA-Z0-9_.-]+$', + pattern_errmsg='may only include letters, numbers, _, ., and -', + maxlength=255, + ), + ) + + takes_options = vault_options + ( + Str( + 'out?', + doc=_('File to store retrieved data'), + ), + Str( + 'session_key?', + doc=_( + 'Session key wrapped with transport certificate' + ' and encoded in base-64'), + ), + ) + + has_output_params = ( + Bytes( + 'data', + label=_('Data'), + ), + ) + + msg_summary = _('Retrieved data from vault "%(value)s"') + + def forward(self, *args, **options): + + output_file = options.get('out') + + # don't send these parameters to server + if 'out' in options: + del options['out'] + + # initialize NSS database + crypto = pki.crypto.NSSCryptoProvider(paths.IPA_NSSDB_DIR) + crypto.initialize() + current_dbdir = paths.IPA_NSSDB_DIR + + # retrieve transport certificate + (file, filename) = tempfile.mkstemp() + os.close(file) + try: + self.api.Command.vault_config(transport_out=unicode(filename)) + transport_cert_der = nss.read_der_from_file(filename, True) + nss_transport_cert = nss.Certificate(transport_cert_der) + + finally: + os.remove(filename) + + # generate session key + session_key = crypto.generate_session_key() + + # wrap session key with transport certificate + wrapped_session_key = crypto.asymmetric_wrap( + session_key, + nss_transport_cert + ) + + # send retrieval request to server + options['session_key'] = base64.b64encode(wrapped_session_key)\ + .decode('utf-8') + + response = super(vault_retrieve, self).forward(*args, **options) + + result = response['result'] + nonce = base64.b64decode(result['nonce']) + + # unwrap data with session key + wrapped_vault_data = base64.b64decode(result['vault_data']) + + json_vault_data = crypto.symmetric_unwrap( + wrapped_vault_data, + session_key, + nonce_iv=nonce) + + vault_data = json.loads(json_vault_data) + data = base64.b64decode(vault_data[u'data'].encode('utf-8')) + + if output_file: + response = {} + response['result'] = {} + with open(output_file, 'w') as f: + f.write(data) + + else: + response['result']['data'] = data + del response['result']['nonce'] + del response['result']['vault_data'] + + return response + + def execute(self, *args, **options): + + vault_name = args[0] + + # retrieve vault info + vault = self.api.Command.vault_show( + vault_name, + service=options.get('service'), + shared=options.get('shared'), + user=options.get('user'), + )['result'] + + wrapped_session_key = base64.b64decode(options['session_key']) + + # connect to KRA + kra_client = self.api.Backend.kra.get_client() + + kra_account = pki.account.AccountClient(kra_client.connection) + kra_account.login() + + client_key_id = self.api.Object.vault.get_key_id(vault['dn']) + + # find vault record in KRA + response = kra_client.keys.list_keys( + client_key_id, + pki.key.KeyClient.KEY_STATUS_ACTIVE) + + if not len(response.key_infos): + raise errors.NotFound(reason=_('No archived data.')) + + key_info = response.key_infos[0] + + # retrieve encrypted data from KRA + key = kra_client.keys.retrieve_key( + key_info.get_key_id(), + wrapped_session_key) + + vault['vault_data'] = base64.b64encode( + key.encrypted_data).decode('utf-8') + vault['nonce'] = base64.b64encode(key.nonce_data).decode('utf-8') + + kra_account.logout() + + response = {} + response['result'] = vault + + return response diff --git a/ipatests/test_xmlrpc/test_vault_plugin.py b/ipatests/test_xmlrpc/test_vault_plugin.py index 44d397c583928d98ec252899398ae6c3a83c207c..0664addd646806f1b8a5083ef5da16c4dfc015dc 100644 --- a/ipatests/test_xmlrpc/test_vault_plugin.py +++ b/ipatests/test_xmlrpc/test_vault_plugin.py @@ -22,12 +22,15 @@ Test the `ipalib/plugins/vault.py` module. """ from ipalib import api, errors -from xmlrpc_test import Declarative, fuzzy_string +from xmlrpc_test import Declarative vault_name = u'test_vault' service_name = u'HTTP/server.example.com' user_name = u'testuser' +# binary data from \x00 to \xff +secret = ''.join(map(chr, xrange(0, 256))) + class test_vault_plugin(Declarative): @@ -442,4 +445,70 @@ class test_vault_plugin(Declarative): }, }, + { + 'desc': 'Create vault for archival', + 'command': ( + 'vault_add', + [vault_name], + {}, + ), + 'expected': { + 'value': vault_name, + 'summary': 'Added vault "%s"' % vault_name, + 'result': { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,%s' + % (vault_name, api.env.basedn), + 'objectclass': [u'top', u'ipaVault'], + 'cn': [vault_name], + }, + }, + }, + + { + 'desc': 'Archive secret', + 'command': ( + 'vault_archive', + [vault_name], + { + 'data': secret, + }, + ), + 'expected': { + 'result': {}, + }, + }, + + { + 'desc': 'Retrieve secret', + 'command': ( + 'vault_retrieve', + [vault_name], + {}, + ), + 'expected': { + 'result': { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,%s' + % (vault_name, api.env.basedn), + 'cn': [vault_name], + 'data': secret, + }, + }, + }, + + { + 'desc': 'Delete vault for archival', + 'command': ( + 'vault_del', + [vault_name], + {}, + ), + 'expected': { + 'value': [vault_name], + 'summary': u'Deleted vault "%s"' % vault_name, + 'result': { + 'failed': (), + }, + }, + }, + ] -- 1.9.3 From jcholast at redhat.com Wed May 27 05:39:54 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 27 May 2015 07:39:54 +0200 Subject: [Freeipa-devel] [PATCH] Password vault In-Reply-To: <55651209.8020000@redhat.com> References: <54E1AF55.3060409@redhat.com> <54EBEB55.6010306@redhat.com> <54F96B22.9050507@redhat.com> <55004D5D.6060300@redhat.com> <550FE5EB.1070606@redhat.com> <551E0AE1.8040500@redhat.com> <553498D1.1020901@redhat.com> <55651209.8020000@redhat.com> Message-ID: <556558AA.6040107@redhat.com> Dne 27.5.2015 v 02:38 Endi Sukma Dewata napsal(a): > Please take a look at the attached patch to add vault-archive/retrieve > commands. > > On 4/20/2015 1:12 AM, Jan Cholasta wrote: >>>>>> 16) You do way too much stuff in vault_add.forward(). Only code that >>>>>> must be done on the client needs to be there, i.e. handling of the >>>>>> "data", "text" and "in" options. >>>>>> >>>>>> The vault_archive call must be in vault_add.execute(), otherwise >>>>>> a) we >>>>>> will be making 2 RPC calls from the client and b) it won't be >>>>>> called at >>>>>> all when api.env.in_server is True. >>>>> >>>>> This is done by design. The vault_add.forward() generates the salt and >>>>> the keys. The vault_archive.forward() will encrypt the data. These >>>>> operations have to be done on the client side to secure the >>>>> transport of >>>>> the data from the client through the server and finally to KRA. This >>>>> mechanism prevents the server from looking at the unencrypted data. >>>> >>>> OK, but that does not justify that it's broken in server-side API. It >>>> can and should be done so that it works the same way on both client and >>>> server. >>>> >>>> I think the best solution would be to split the command into two >>>> commands, server-side vault_archive_raw to archive already encrypted >>>> data, and client-side vault_archive to encrypt data and archive them >>>> with vault_archive_raw in its .execute(). Same thing for >>>> vault_retrieve. >>> >>> Actually I think it's better to just merge the add and archive, reducing >>> the number of RPC calls. The vault_archive now will support two types of >>> operations: >>> >>> (a) Archive data into a new vault (it will create the vault just before >>> archiving the data): >>> >>> $ ipa vault-archive testvault --create --in data ... >>> >>> (b) Archive data into an existing vault: >>> >>> $ ipa vault-archive testvault --in data ... >>> >>> The vault_add is now just a wrapper for the vault_archive(a). >> >> If that's just an implementation detail, OK. >> >> If it's possible to modify existing vault objects using vault-add or >> create new objects using vault-archive, then NACK. > > The vault-archive is now completely separate from vault-add. You can no > longer archive data while creating a vault: > > $ ipa vault-add test > $ ipa vault-archive test --in secret.bin OK. > >>>> BTW, I also think it would be better if there were 2 separate sets of >>>> commands for binary and textual data >>>> (vault_{archive,retrieve}_{data,text}) rather than trying to handle >>>> everything in vault_{archive,retrieve}. >>> >>> I don't think we want to provide a separate command of every possible >>> data type & operation combination. Users would get confused. The archive >>> & retrieve commands should be able to handle all current & future data >>> types with options. >> >> A command with two sets of mutually exclusive options is really two >> commands in disguise, which is a good sign it should be divided into two >> actual commands. >> >> Who are you to say users would get confused? I say they would be more >> confused by a command with a plethora of mutually exclusive "options". >> >> What other possible data types are there? > > The patch has been simplified to support only binary data. The data can > be specified using either of these options: > > $ ipa vault-archive test --data > $ ipa vault-archive test --in > > I don't think we want to provide two separate commands for these options > although they are mutually exclusive, do we? No, these are not really 2 different options, but rather 2 forms of the same option, which for the lack of better support for files in the framework have to be done as 2 options. > >>>>> The add & archive combination was added for convenience, not for >>>>> optimization. This way you would be able to archive data into a new >>>>> vault using a single command. Without this, you'd have to execute two >>>>> separate commands: add & archive, which will result in 2 RPC calls >>>>> anyway. >>>> >>>> I think I would prefer if it was separate, as that would be consistent >>>> with other plugins (e.g. for objects with members, we don't allow >>>> adding >>>> members directly in -add, you have to use -add-member after -add). >>> >>> The vault data is similar to group description, not group members. When >>> creating a group we can supply the description. If not specified it will >>> be blank. Archiving vault data is similar to updating the group >>> description. >> >> It's similar to group members because there are separate commands to >> manipulate them. > > Just because there are separate commands doesn't mean vault data > (single-valued) is similar to group members (multi-valued). It uses > separate commands because of the encryption steps involved while > archiving/retrieving data. That was not the point, but whatever. > >> You have to choose one of: >> >> a) vault data is settable using vault-add and vault-mod and gettable >> using vault-mod, vault-show and vault-find >> >> b) vault data is settable using vault-archive and gettable using >> vault-retrieve >> >> Anything in between is not permitted. > > As mentioned above, the add and archive commands are now separate. > >>>>>> 21) vault_archive is not a retrieve operation, it should be based on >>>>>> LDAPUpdate instead of LDAPRetrieve. Or Command actually, since it >>>>>> does >>>>>> not do anything with LDAP. The same applies to vault_retrieve. >>>>> >>>>> The vault_archive does not actually modify the LDAP entry because it >>>>> stores the data in KRA. It is actually an LDAPRetrieve operation >>>>> because >>>>> it needs to get the vault info before it can perform the archival >>>>> operation. Same thing with vault_retrieve. >>>> >>>> It is not a LDAPRetrieve operation, because it has different semantics. >>>> Please use Command as base class and either use ldap2 for direct >>>> LDAP or >>>> call vault_show instead of hacking around LDAPRetrieve. >>> >>> It's been changed to inherit from LDAPQuery instead. >> >> NACK, it's not a LDAPQuery operation, because it has different >> semantics. There is more to a command than executing code, so you should >> use a correct base class. > > Changed to inherit from Command as requested. Now these commands no > longer have a direct access to the vault object (self.obj) although they > are accessing vault objects like other vault commands. Also now the > vault name argument has to be added explicitly on each command. You can inherit from crud.Retrieve and crud.Update to get self.obj and the argument back. > > There are existing commands that inherit from LDAPQuery while doing > other things too, so the 'semantic' seems to be kind of arbitrarily > defined and subjective. There is a lot of existing stuff in IPA that is bad in one way or another, but it doesn't mean new code should be bad as well. > >>>>>> 22) vault_archive will break with binary data that is not UTF-8 >>>>>> encoded >>>>>> text. >>>>>> >>>>>> This is where it occurs: >>>>>> >>>>>> + vault_data[u'data'] = unicode(data) >>>>>> >>>>>> Generally, don't use unicode() on str values and str() on unicode >>>>>> values >>>>>> directly, always use .decode() and .encode(). >>> >>> The unicode(s, encoding) is actually equivalent to s.decode(encoding), >>> so the following code will not solve the problem: >>> >>> vault_data[u'data'] = data.decode() >>> >>> As you said, decode() will only work if the data being decoded actually >>> follows the encoding rules (i.e. already UTF-8 encoded). >>> >>>>> It needs to be a Unicode because json.dumps() doesn't work with binary >>>>> data. Fixed by adding base-64 encoding. >>> >>> The base-64 encoding is necessary to convert random binaries into ASCII >>> so it can be decoded into Unicode. Here is the current code: >>> >>> vault_data[u'data'] = unicode(base64.b64encode(data)) >>> >>> which is equivalent to: >>> >>> vault_data[u'data'] = base64.b64encode(data).decode() >> >> If you read a little bit further, you would get to the point, which is >> certainly not calling .decode() without arguments, but *always >> explicitly specify the encoding*. > > Added the explicit encoding name although it's not necessary since the > data being encoded/decoded is base-64 encoded (i.e. ASCII). It may not be necessary but it doesn't hurt either, anyway my main concern was with the other uses of unicode() in the original patch. > >>>> If something str needs to be unicode, you should use .decode() to >>>> explicitly specify the encoding, instead of relying on unicode() to >>>> pick >>>> the correct one. >>> >>> Since we know this is ASCII data we can now specify UTF-8 encoding. >>> >>> vault_data[u'data'] = base64.b64encode(data).decode('utf-8') >>> >>> But for anything that comes from user input (e.g. filenames, passwords), >>> it's better to use the default encoding because that can be configured >>> by the user. >> >> You are confusing user's configured encoding with Python's default >> encoding. Default encoding in Python isn't derived from user's >> localization settings. >> >> Anyway, anything that comes from user input is already decoded using >> user's configured encoding when it enters the framework so I don't know >> why are you even bringing it up here. > > It's irrelevant now that the command only supports binary data. OK. > >>>> Anyway, I think a better solution than base64 would be to use the >>>> "raw_unicode_escape" encoding: >>> >>> As explained above, base-64 encoding is necessary because random >>> binaries don't follow any encoding rules. I'd rather not use >>> raw_unicode_escape because it's not really a text data. >> >> The result of decoding binary data using raw_unicode_escape is perfectly >> valid unicode data which doesn't eat 33% more space like base64 encoded >> binary does, hence my suggestion. >> >> Anyway, it turns out when encoded in JSON, raw_unicode_escape string >> generally takes more space than base64 encoded string because of JSON >> escaping, so base64 is indeed better. > > Unchanged. It still uses base-64 encoding. Right. > >>> Here's how it's >>> now implemented: >>> >>>> if data: >>>> data = data.decode('raw_unicode_escape') >>> >>> Input data is already in binaries, no conversion needed. >>> >>>> elif text: >>>> data = text >>> >>> Input text will be converted to binaries with default encoding: >>> >>> data = text.encode() >> >> See what the default encoding actually is and why you shouldn't rely on >> it above. > > Irrelevant now. > >>>> elif input_file: >>>> with open(input_file, 'rb') as f: >>>> data = f.read() >>>> data = data.decode('raw_unicode_escape') >>> >>> Input contains binary data, no conversion needed. >>> >>>> else: >>>> data = u'' >>> >>> If not specified, the data will be empty string: >>> >>> data = '' >>> >>> The data needs to be converted into binaries so it can be encrypted >>> before transport (depending on the vault type): >>> >>> data = self.obj.encrypt(data, ...) >>> >>>> vault_data[u'data'] = data >>> >>> Then for transport the data is base-64 encoded first, then converted >>> into Unicode: >>> >>> vault_data[u'data'] = base64.b64encode(data).decode('utf-8') > If KRA is not installed, vault-archive and vault-retrieve fail with internal error. The commands still behave differently based on whether they were called from API which was initialized with in_server set to True or False. There is no point in exposing the session_key, nonce and vault_data options in CLI when their value is always overwritten in forward(). Will this always succeed? + # deactivate vault record in KRA + response = kra_client.keys.list_keys( + client_key_id, pki.key.KeyClient.KEY_STATUS_ACTIVE) + + for key_info in response.key_infos: + kra_client.keys.modify_key_status( + key_info.get_key_id(), + pki.key.KeyClient.KEY_STATUS_INACTIVE) If not, we might get into an inconsistent state, where the vault is deleted in LDAP but still active in KRA. (I'm not sure if this is actually a problem or not.) -- Jan Cholasta From ofayans at redhat.com Wed May 27 09:36:15 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 27 May 2015 11:36:15 +0200 Subject: [Freeipa-devel] [PATCH] 857 topology: ipa management commands In-Reply-To: <556475AF.7060301@redhat.com> References: <556448B3.9050105@redhat.com> <556475AF.7060301@redhat.com> Message-ID: <5565900F.8050507@redhat.com> The current version of the patch can not be applied: git apply freeipa-pvoborni-0857-1-topology-ipa-management-commands.patch error: patch failed: VERSION:90 error: VERSION: patch does not apply Also, is freeipa-pvoborni-0855-server-find-and-server-show-commands.patch already merged? Generally what is the current list of patches that need to be applied in order to test this feature? I currently have the following set: freeipa-pvoborni-0822-1-webui-topology-plugin.patch freeipa-pvoborni-0857-1-topology-ipa-management-commands.patch freeipa-pvoborni-0858-webui-IPA.command_dialog-a-new-dialog-base-class.patch freeipa-pvoborni-0859-webui-use-command_dialog-as-a-base-class-for-passwor.patch freeipa-pvoborni-0860-webui-make-usage-of-all-in-details-facet-optional.patch freeipa-pvoborni-0861-webui-topology-plugin.patch Is there anything else that I've missed? On 05/26/2015 03:31 PM, Petr Vobornik wrote: > On 05/26/2015 12:19 PM, Petr Vobornik wrote: >> this patch is based on top of my patch #856 and tbabej' >> s 325-9. >> >> Obsoletes Ludwig's 0006. >> >> ipalib part of topology management >> >> Design: >> - http://www.freeipa.org/page/V4/Manage_replication_topology >> >> https://fedorahosted.org/freeipa/ticket/4302 >> >> > > New version attached: > - domainlevel_show usage changed to domainlevel_get > - updated VERSION > - added more attrs to default_attributes > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Wed May 27 09:49:41 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 27 May 2015 11:49:41 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <556493D3.8010402@redhat.com> References: <555F03DB.3090702@redhat.com> <556493D3.8010402@redhat.com> Message-ID: <55659335.2060306@redhat.com> On 05/26/2015 05:40 PM, Jan Cholasta wrote: > Dne 22.5.2015 v 12:24 Christian Heimes napsal(a): ... >> Finally I haven't figured out the best way to configure the instance. An >> admin should be able to enable / disable KDC proxy. Should I write a >> script or a ipa plugin for the job? > > A script, ipa-kdcproxy-install, if you want to be consistent with what's > already there. I thought we wanted to install it by default and only switch it on/off via configuration in LDAP. In that case, no ipa-*-install should be needed. From abokovoy at redhat.com Wed May 27 09:53:22 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 27 May 2015 12:53:22 +0300 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <55659335.2060306@redhat.com> References: <555F03DB.3090702@redhat.com> <556493D3.8010402@redhat.com> <55659335.2060306@redhat.com> Message-ID: <20150527095322.GM19176@redhat.com> On Wed, 27 May 2015, Martin Kosek wrote: >On 05/26/2015 05:40 PM, Jan Cholasta wrote: >> Dne 22.5.2015 v 12:24 Christian Heimes napsal(a): >... >>> Finally I haven't figured out the best way to configure the instance. An >>> admin should be able to enable / disable KDC proxy. Should I write a >>> script or a ipa plugin for the job? >> >> A script, ipa-kdcproxy-install, if you want to be consistent with what's >> already there. > >I thought we wanted to install it by default and only switch it on/off via >configuration in LDAP. In that case, no ipa-*-install should be needed. As with any other feature which requires configuration of other components, if it wasn't installed before, you need to make sure you are able to configure it over upgraded instance. Not providing ipa-kdcproxy-install would mean you are not supporting an upgrade case. -- / Alexander Bokovoy From mkosek at redhat.com Wed May 27 09:59:13 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 27 May 2015 11:59:13 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <20150527095322.GM19176@redhat.com> References: <555F03DB.3090702@redhat.com> <556493D3.8010402@redhat.com> <55659335.2060306@redhat.com> <20150527095322.GM19176@redhat.com> Message-ID: <55659571.8070705@redhat.com> On 05/27/2015 11:53 AM, Alexander Bokovoy wrote: > On Wed, 27 May 2015, Martin Kosek wrote: >> On 05/26/2015 05:40 PM, Jan Cholasta wrote: >>> Dne 22.5.2015 v 12:24 Christian Heimes napsal(a): >> ... >>>> Finally I haven't figured out the best way to configure the instance. An >>>> admin should be able to enable / disable KDC proxy. Should I write a >>>> script or a ipa plugin for the job? >>> >>> A script, ipa-kdcproxy-install, if you want to be consistent with what's >>> already there. >> >> I thought we wanted to install it by default and only switch it on/off via >> configuration in LDAP. In that case, no ipa-*-install should be needed. > As with any other feature which requires configuration of other > components, if it wasn't installed before, you need to make sure you are > able to configure it over upgraded instance. Not providing > ipa-kdcproxy-install would mean you are not supporting an upgrade case. I do not disagree with the approach for optional components. But as I wrote above, this was supposed to be configured everywhere by default - both on new and upgraded installations. AFAIK, it is mostly just one config for Apache and wsgi script. From pspacek at redhat.com Wed May 27 10:03:29 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 27 May 2015 12:03:29 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <556497B9.6020709@redhat.com> References: <555F03DB.3090702@redhat.com> <1432648676.3354.6.camel@redhat.com> <5564806B.8030202@redhat.com> <55648203.3060109@redhat.com> <5564869D.9040804@redhat.com> <1432651849.3354.26.camel@redhat.com> <55648C9A.8040603@redhat.com> <1432653089.3354.36.camel@redhat.com> <556497B9.6020709@redhat.com> Message-ID: <55659671.3050508@redhat.com> On 26.5.2015 17:56, Christian Heimes wrote: > On 2015-05-26 17:11, Nathaniel McCallum wrote: >> I don't want to add code that: 1. is half-baked 2. we aren't committed >> to supporting. >> >> I'd rather land per-replica switches as a separate commit with >> everything polished and supportable. > > Well then ... I'm going to remove the code for per-replica config and go > back to the global switch. Since I'm now familiar with the code, it's > easy for me to add it back, in case we need it again. :) I do not see a *need* for the user interface to the per-replica switch. We do not have such switch for any other optional component, like DNS. IMHO it is perfectly fine to have only per-replica switch as we do for all other components - and do not have user interface to the switch as we do not have it for any other component. It would be consistent, easy, and future proof. -- Petr^2 Spacek From ftweedal at redhat.com Wed May 27 10:04:38 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 27 May 2015 20:04:38 +1000 Subject: [Freeipa-devel] Yet another user certificates/Smart Card thread In-Reply-To: <55640956.30703@redhat.com> References: <55631BCB.8090608@redhat.com> <55631FF5.3080008@redhat.com> <55632A1E.2000802@redhat.com> <20150525142607.GD13469@dhcp-40-8.bne.redhat.com> <55633446.9020709@redhat.com> <55640956.30703@redhat.com> Message-ID: <20150527100431.GB24915@dhcp-40-8.bne.redhat.com> On Tue, May 26, 2015 at 07:49:10AM +0200, Martin Kosek wrote: > On 05/25/2015 04:40 PM, Jan Cholasta wrote: > >Dne 25.5.2015 v 16:26 Fraser Tweedale napsal(a): > >>On Mon, May 25, 2015 at 03:56:46PM +0200, Martin Kosek wrote: > >>>On 05/25/2015 03:13 PM, Jan Cholasta wrote: > >>>>Hi, > >>>> > >>>>Dne 25.5.2015 v 14:55 Martin Babinsky napsal(a): > >>>>>Hello all, long post ahead! > >>>>> > >>>>>I became a proud owner of https://fedorahosted.org/freeipa/ticket/4238, > >>>>>and while Martin's design page > >>>>>(http://www.freeipa.org/page/V4/User_Certificates) brings a > >>>>>comprehensive overview of what should be done, there are still some gray > >>>>>areas we should address both in the design page and the actual > >>>>>implementation. > >>>>> > >>>>>These are the things that were agreed upon in previous thread(s): > >>>>> > >>>>>1.) If the whole user certificates are available, the should be stored > >>>>>directly in the user entry as an attribute of the following format: > >>>>> > >>>>> "userCertificate;binary;$id", > >>>>> > >>>>>where "id" should be an unique identifier. IIRC we agreed that the > >>>>>first/last 4 bytes of cert's SHA512 hash should fill the 'id' role > >>>>>nicely. During user authentication the whole binary blob would be > >>>>>matched (pspacek pointed out that the cost of this operation is > >>>>>acceptable). > >>>>> > >>>>>2.) In addition, or when the user certs are stored externally, we should > >>>>>store the certificate metadata in the user entry. These metadata should > >>>>>be represented by "userCertAttrs;$id;$attr" attributes, where $attr > >>>>>subtype corresponds to the type of metadata (issuer, serial no., profile > >>>>>id, certificate hash etc.). The authentication/lookup would require some > >>>>>custom matching rule to fetch the correct cert. > >>>>> > >>>>>Point 1. seems clear to me, we need to implement an index for > >>>>>userCertificate attribute in DS and modify 'user-add/mod' commands to > >>>>>allow for direct enrollment through API ("--usercertificate" option). > >>>>> > >>>>>Point 2. requires more work: we need to add a new attribute > >>>>>"userCertAttrs" to the schema and create DS index/custom matching rule > >>>>>for searching. I'm also not quite sure how to approach the task of > >>>>>getting these metadata from external storage and putting them to the > >>>>>user entry. > >>>> > >>>>Both points are obsolete. See the design page you linked for the current plan. > >>> > >>>Huh, where that came from Martin? Did you have some cached old version of the > >>>design page? I am just wondering what went wrong, as this is something I > >>>deleted from that page month ago. > >>> > >>+1 ; we will just store the certificate(s) in the userCertificate > >>attribute. > >> > >>>> > >>>>> > >>>>>These are the questions that should be addressed in a broader discussion: > >>>>> > >>>>>What is the relation to Fraser's work (cert profiles/sub-CAs)? I have > >>>>>seen that the recent iteration of Fraser's patches (0010-3 and 0011-3) > >>>>>add some ACIs and attributes/requests related to user certificates. I > >>>>>suppose that the only way the user certs are related to cert profile > >>>>>will be that there will be a profile ID stored either in cert itself, or > >>>>>as a separate userCertAttr;$id;profileId attribute in user entry. > >>>>> > >>For the avoidance of doubt, there well be no way to query which > >>profile was used to issue a certificate in the near term. Dogtag > >>does store this information, but at the moment we are not planning > >>to use it or expose it in IPA. > >> > >>>>>What to do with user certs when the entry is deleted? Should we revoke > >>>>>them or let them expire? > >>>> > >>>>See . > >>>> > >> > >>There was not really any conclusion to that discussion. I am in > >>favour of a ``{user,host,service}-{del,mod} --[no-]revoke[=$REASON]`` > >>argument that says what to do when we delete a certificate, and > >>allows specifying the revocation reason. > > > >I don't think we should add such option, for the same reasons why we did not > >add the option to override the "store certificate in entry" policy in > >cert-request. > > > >> > >>I don't have a strong opinion on whether the default should be to > >>revoke or not revoke, but I do think that the default revocation > >>reason should be unspecified(0). superseded(4) is no longer > >>appropriate. > > > >I would rather wait for Dogtag to implement the profile querying interface > >before doing anything and just not revoke certificates for now. > > Well, whatever we do, it should not be a regression. So, we can change the > global default (or make it different for upgraded/new installations as with > some ACIs for PermissionsV2) but we should still have some possibility for a > user to configure the behavior. FreeIPA should be still able to revoke certs > stored in user/service/host entry during object-del/object-disable. > > What should we do in this case? Option for "ipa config-*"? > I think a global option is sensible starting point. We should also consider an option to use revocation reason "certificateHold" for obj-disable and revive the certificates if the object is re-enabled via obj-enable. (I'm not sure whether Dogtag makes this easy but I am pretty sure it's currently possible; and it's a bit more work for IPA to do this, of course). I'm currently removing the revocation behaviour out of {host,certificate}-{add,mod} as part of the multi-cert support, but will leave the -del/-disable behaviour largely unchanged for now (only to make these commands revoke all the certificates, not just one certificate). Cheers, Fraser > Martin From pvoborni at redhat.com Wed May 27 10:13:07 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 27 May 2015 12:13:07 +0200 Subject: [Freeipa-devel] [PATCH] 857 topology: ipa management commands In-Reply-To: <55647B98.9030907@redhat.com> References: <556448B3.9050105@redhat.com> <556475AF.7060301@redhat.com> <55647B98.9030907@redhat.com> Message-ID: <556598B3.3000006@redhat.com> On 05/26/2015 03:56 PM, Oleg Fayans wrote: > Hi Petr, team > > After playing around with the previous version of your patch applied on > top of the current master branch today in the morning, I still observe > the problem with replica installation, described here: > https://fedorahosted.org/freeipa/ticket/5035 This issue is not fixed with this patch. There is no patch for #5035 yet. This patch only adds ipalib API and CLI related to topology suffix and topology segment management. Over 857, patch 857-1 fixes only the 'internal error' which was in previous version(invalid domainslevel-show call). > the session transcript together with ipareplica-install.log and the > errors log of the dirsrv on master are attached. > The following lines in the error log might be of interest: > > [26/May/2015:08:46:09 -0400] NSMMReplicationPlugin - Finished total > update of replica "agmt="cn=meToreplica1.pesen.net" (replica1:389)". > Sent 382 entries. > [26/May/2015:08:46:11 -0400] ipa-topology-plugin - ipa_topo_util_modify: > failed to modify entry > (cn=meToreplica1.pesen.net,cn=replica,cn=dc\3Dpesen\2Cdc\3Dnet,cn=mapping tree,cn=config): > error 53 > [26/May/2015:08:46:17 -0400] repl_version_plugin_recv_acquire_cb - [file > ipa_repl_version.c, line 119]: Incompatible IPA versions, pausing > replication. This server: "20100614120000" remote server: "(null)". > [26/May/2015:08:46:38 -0400] NSMMReplicationPlugin - > agmt="cn=meToreplica1.pesen.net" (replica1:389): Unable to receive the > response for a startReplication extended operation to consumer (Can't > contact LDAP server). Will retry later. > [26/May/2015:08:46:41 -0400] NSMMReplicationPlugin - > agmt="cn=meToreplica1.pesen.net" (replica1:389): Replication bind with > SIMPLE auth resumed > [26/May/2015:08:47:42 -0400] NSMMReplicationPlugin - Beginning total > update of replica > "agmt="cn=masterAgreement1-replica1.pesen.net-pki-tomcat" (replica1:389)". > [26/May/2015:08:47:46 -0400] NSMMReplicationPlugin - Finished total > update of replica > "agmt="cn=masterAgreement1-replica1.pesen.net-pki-tomcat" > (replica1:389)". Sent 70 entries. > [26/May/2015:08:48:28 -0400] repl_version_plugin_recv_acquire_cb - [file > ipa_repl_version.c, line 119]: Incompatible IPA versions, pausing > replication. This server: "20100614120000" remote server: "(null)". > [26/May/2015:08:48:28 -0400] repl_version_plugin_recv_acquire_cb - [file > ipa_repl_version.c, line 119]: Incompatible IPA versions, pausing > replication. This server: "20100614120000" remote server: "(null)". > > Should I rebuild the packages with the latest version of your patch on > top of the current master with Tomas' latest Domain Level-related > changes and try again? > > > On 05/26/2015 03:31 PM, Petr Vobornik wrote: >> On 05/26/2015 12:19 PM, Petr Vobornik wrote: >>> this patch is based on top of my patch #856 and tbabej' >>> s 325-9. >>> >>> Obsoletes Ludwig's 0006. >>> >>> ipalib part of topology management >>> >>> Design: >>> - http://www.freeipa.org/page/V4/Manage_replication_topology >>> >>> https://fedorahosted.org/freeipa/ticket/4302 >>> >>> >> >> New version attached: >> - domainlevel_show usage changed to domainlevel_get >> - updated VERSION >> - added more attrs to default_attributes >> >> > > > -- Petr Vobornik From pvoborni at redhat.com Wed May 27 10:25:03 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 27 May 2015 12:25:03 +0200 Subject: [Freeipa-devel] [PATCH] 857 topology: ipa management commands In-Reply-To: <5565900F.8050507@redhat.com> References: <556448B3.9050105@redhat.com> <556475AF.7060301@redhat.com> <5565900F.8050507@redhat.com> Message-ID: <55659B7F.4030705@redhat.com> On 05/27/2015 11:36 AM, Oleg Fayans wrote: > The current version of the patch can not be applied: > > git apply freeipa-pvoborni-0857-1-topology-ipa-management-commands.patch > error: patch failed: VERSION:90 > error: VERSION: patch does not apply This patch should apply on current master. All its dependencies were pushed. Worked for me. > > Also, is > freeipa-pvoborni-0855-server-find-and-server-show-commands.patch already > merged? Yes, this was pushed. > > Generally what is the current list of patches that need to be applied in > order to test this feature? > > I currently have the following set: > > freeipa-pvoborni-0822-1-webui-topology-plugin.patch could be disregarded, was replaced with patches 858-861 > freeipa-pvoborni-0857-1-topology-ipa-management-commands.patch needed for testing CLI and is a prerequisite for Web UI > freeipa-pvoborni-0858-webui-IPA.command_dialog-a-new-dialog-base-class.patch > freeipa-pvoborni-0859-webui-use-command_dialog-as-a-base-class-for-passwor.patch > freeipa-pvoborni-0860-webui-make-usage-of-all-in-details-facet-optional.patch > freeipa-pvoborni-0861-webui-topology-plugin.patch 858-861 are Web UI, I'll sent new versions today because the domains level API was changed after these patches had been created and therefore the patches uses an incorrect call. > > Is there anything else that I've missed? No, but we don't have a patch for ticket #5035 which effectively blocks us with testing the core of the topology effort. It's something Ludwig should look at. > > > > On 05/26/2015 03:31 PM, Petr Vobornik wrote: >> On 05/26/2015 12:19 PM, Petr Vobornik wrote: >>> this patch is based on top of my patch #856 and tbabej' >>> s 325-9. >>> >>> Obsoletes Ludwig's 0006. >>> >>> ipalib part of topology management >>> >>> Design: >>> - http://www.freeipa.org/page/V4/Manage_replication_topology >>> >>> https://fedorahosted.org/freeipa/ticket/4302 >>> >>> >> >> New version attached: >> - domainlevel_show usage changed to domainlevel_get >> - updated VERSION >> - added more attrs to default_attributes -- Petr Vobornik From mkosek at redhat.com Wed May 27 11:04:35 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 27 May 2015 13:04:35 +0200 Subject: [Freeipa-devel] Domain level for topology plugin = 2 In-Reply-To: <5564841B.4020906@redhat.com> References: <55646331.5050807@redhat.com> <55647F90.506@redhat.com> <5564804B.6080305@redhat.com> <5564841B.4020906@redhat.com> Message-ID: <5565A4C3.5030002@redhat.com> On 05/26/2015 04:32 PM, Petr Spacek wrote: > On 26.5.2015 16:16, Martin Kosek wrote: ... > If you really want to avoid unforeseen issues rather go and get rid of > "major.minor" logic we have in the topology plugin right now :-) Ludwig, I thought we agreed to avoid using major.minor format in the topology plugin Domain Level implementation, to both avoid confusion of users and to not ship unused code - right? Thanks, Martin From mbabinsk at redhat.com Wed May 27 11:25:28 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 27 May 2015 13:25:28 +0200 Subject: [Freeipa-devel] [PATCH 0038] increase NSS memcache timeout for IPA server Message-ID: <5565A9A8.7020206@redhat.com> https://fedorahosted.org/freeipa/ticket/4964 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0038-increase-NSS-memcache-timeout-for-IPA-server.patch Type: text/x-patch Size: 1530 bytes Desc: not available URL: From cheimes at redhat.com Wed May 27 11:33:04 2015 From: cheimes at redhat.com (Christian Heimes) Date: Wed, 27 May 2015 13:33:04 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <55659571.8070705@redhat.com> References: <555F03DB.3090702@redhat.com> <556493D3.8010402@redhat.com> <55659335.2060306@redhat.com> <20150527095322.GM19176@redhat.com> <55659571.8070705@redhat.com> Message-ID: <5565AB70.7020004@redhat.com> On 2015-05-27 11:59, Martin Kosek wrote: > On 05/27/2015 11:53 AM, Alexander Bokovoy wrote: >> On Wed, 27 May 2015, Martin Kosek wrote: >>> On 05/26/2015 05:40 PM, Jan Cholasta wrote: >>>> Dne 22.5.2015 v 12:24 Christian Heimes napsal(a): >>> ... >>>>> Finally I haven't figured out the best way to configure the instance. An >>>>> admin should be able to enable / disable KDC proxy. Should I write a >>>>> script or a ipa plugin for the job? >>>> >>>> A script, ipa-kdcproxy-install, if you want to be consistent with what's >>>> already there. >>> >>> I thought we wanted to install it by default and only switch it on/off via >>> configuration in LDAP. In that case, no ipa-*-install should be needed. >> As with any other feature which requires configuration of other >> components, if it wasn't installed before, you need to make sure you are >> able to configure it over upgraded instance. Not providing >> ipa-kdcproxy-install would mean you are not supporting an upgrade case. > > I do not disagree with the approach for optional components. But as I wrote > above, this was supposed to be configured everywhere by default - both on new > and upgraded installations. > > AFAIK, it is mostly just one config for Apache and wsgi script. Yes, it is really just one boolean switch (service enabled/disabled). The state of the switch is read when Apache is started or reloaded. In the default state KDC Proxy is enabled. When the service is disabled, the WSGI script replies with 404 instead. All remaining settings like kdc, kadmin and kpasswd server(s) are read from /etc/krb5.conf. I had both the per-replica and the global switch implemented. After I discussion with Nathaniel and Martin, it's now a global switch only. Nathaniel argued, that a global switch is easier to implement as well as sufficient for now. The state of the switch is controlled with ipa config-mod: ipa config-mod --enable-kdcproxy=TRUE ipa config-mod --enable-kdcproxy=FALSE The schema changes for the new attribute are handled by ipa-server-upgrade. The Apache config file is created ipa-server-install, ipa-replica-install and ipa-server-upgrade. Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From lslebodn at redhat.com Wed May 27 11:33:54 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Wed, 27 May 2015 13:33:54 +0200 Subject: [Freeipa-devel] [PATCH 0038] increase NSS memcache timeout for IPA server In-Reply-To: <5565A9A8.7020206@redhat.com> References: <5565A9A8.7020206@redhat.com> Message-ID: <20150527113354.GI12030@mail.corp.redhat.com> On (27/05/15 13:25), Martin Babinsky wrote: >https://fedorahosted.org/freeipa/ticket/4964 > >-- >Martin^3 Babinsky >From ef8481ee0267a720551832baae9398b435b3c6c5 Mon Sep 17 00:00:00 2001 >From: Martin Babinsky >Date: Tue, 26 May 2015 18:11:08 +0200 >Subject: [PATCH] increase NSS memcache timeout for IPA server > >Increasing memcache timeout to 600 seconds when configuring sssd on IPA server >should improve performance when dealing with large groups in trusts. > >https://fedorahosted.org/freeipa/ticket/4964 >--- > ipa-client/ipa-install/ipa-client-install | 9 +++++++++ > 1 file changed, 9 insertions(+) > >diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install >index 63e3c9800791f3d29c977d63815c4291f5a235b9..ab3bc8a652dad01b9db5a26b877f38b850cb07f1 100755 >--- a/ipa-client/ipa-install/ipa-client-install >+++ b/ipa-client/ipa-install/ipa-client-install >@@ -1274,6 +1274,15 @@ def configure_sssd_conf(fstore, cli_realm, cli_domain, cli_server, options, clie > # the master should only use itself for Kerberos > domain.set_option('ipa_server', cli_server[0]) > >+ # increase memcache timeout to 10 minutes when in server mode >+ try: >+ nss_service = sssdconfig.get_service('nss') >+ except SSSDConfig.NoServiceError: >+ nss_service = sssdconfig.new_service('nss') >+ >+ nss_service.set_option('memcache_timeout', 600) >+ sssdconfig.save_service(nss_service) >+ NACK It should not be set to such high value for each client. It should be configured if and only if sssd is in the ipa-server mode (trust with AD) LS From mkosek at redhat.com Wed May 27 11:34:39 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 27 May 2015 13:34:39 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <5565AB70.7020004@redhat.com> References: <555F03DB.3090702@redhat.com> <556493D3.8010402@redhat.com> <55659335.2060306@redhat.com> <20150527095322.GM19176@redhat.com> <55659571.8070705@redhat.com> <5565AB70.7020004@redhat.com> Message-ID: <5565ABCF.5090305@redhat.com> On 05/27/2015 01:33 PM, Christian Heimes wrote: > On 2015-05-27 11:59, Martin Kosek wrote: >> On 05/27/2015 11:53 AM, Alexander Bokovoy wrote: >>> On Wed, 27 May 2015, Martin Kosek wrote: >>>> On 05/26/2015 05:40 PM, Jan Cholasta wrote: >>>>> Dne 22.5.2015 v 12:24 Christian Heimes napsal(a): >>>> ... >>>>>> Finally I haven't figured out the best way to configure the instance. An >>>>>> admin should be able to enable / disable KDC proxy. Should I write a >>>>>> script or a ipa plugin for the job? >>>>> >>>>> A script, ipa-kdcproxy-install, if you want to be consistent with what's >>>>> already there. >>>> >>>> I thought we wanted to install it by default and only switch it on/off via >>>> configuration in LDAP. In that case, no ipa-*-install should be needed. >>> As with any other feature which requires configuration of other >>> components, if it wasn't installed before, you need to make sure you are >>> able to configure it over upgraded instance. Not providing >>> ipa-kdcproxy-install would mean you are not supporting an upgrade case. >> >> I do not disagree with the approach for optional components. But as I wrote >> above, this was supposed to be configured everywhere by default - both on new >> and upgraded installations. >> >> AFAIK, it is mostly just one config for Apache and wsgi script. > > Yes, it is really just one boolean switch (service enabled/disabled). > The state of the switch is read when Apache is started or reloaded. In > the default state KDC Proxy is enabled. When the service is disabled, > the WSGI script replies with 404 instead. All remaining settings like > kdc, kadmin and kpasswd server(s) are read from /etc/krb5.conf. > > I had both the per-replica and the global switch implemented. After I > discussion with Nathaniel and Martin, it's now a global switch only. > Nathaniel argued, that a global switch is easier to implement as well as > sufficient for now. > > The state of the switch is controlled with ipa config-mod: > > ipa config-mod --enable-kdcproxy=TRUE > ipa config-mod --enable-kdcproxy=FALSE > > The schema changes for the new attribute are handled by > ipa-server-upgrade. The Apache config file is created > ipa-server-install, ipa-replica-install and ipa-server-upgrade. Thanks. This is all we need for 4.2, IMO. Martin From mbabinsk at redhat.com Wed May 27 11:40:56 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 27 May 2015 13:40:56 +0200 Subject: [Freeipa-devel] [PATCH 0038] increase NSS memcache timeout for IPA server In-Reply-To: <20150527113354.GI12030@mail.corp.redhat.com> References: <5565A9A8.7020206@redhat.com> <20150527113354.GI12030@mail.corp.redhat.com> Message-ID: <5565AD48.5020405@redhat.com> On 05/27/2015 01:33 PM, Lukas Slebodnik wrote: > On (27/05/15 13:25), Martin Babinsky wrote: >> https://fedorahosted.org/freeipa/ticket/4964 >> >> -- >> Martin^3 Babinsky > >>From ef8481ee0267a720551832baae9398b435b3c6c5 Mon Sep 17 00:00:00 2001 >> From: Martin Babinsky >> Date: Tue, 26 May 2015 18:11:08 +0200 >> Subject: [PATCH] increase NSS memcache timeout for IPA server >> >> Increasing memcache timeout to 600 seconds when configuring sssd on IPA server >> should improve performance when dealing with large groups in trusts. >> >> https://fedorahosted.org/freeipa/ticket/4964 >> --- >> ipa-client/ipa-install/ipa-client-install | 9 +++++++++ >> 1 file changed, 9 insertions(+) >> >> diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install >> index 63e3c9800791f3d29c977d63815c4291f5a235b9..ab3bc8a652dad01b9db5a26b877f38b850cb07f1 100755 >> --- a/ipa-client/ipa-install/ipa-client-install >> +++ b/ipa-client/ipa-install/ipa-client-install >> @@ -1274,6 +1274,15 @@ def configure_sssd_conf(fstore, cli_realm, cli_domain, cli_server, options, clie >> # the master should only use itself for Kerberos >> domain.set_option('ipa_server', cli_server[0]) >> >> + # increase memcache timeout to 10 minutes when in server mode >> + try: >> + nss_service = sssdconfig.get_service('nss') >> + except SSSDConfig.NoServiceError: >> + nss_service = sssdconfig.new_service('nss') >> + >> + nss_service.set_option('memcache_timeout', 600) >> + sssdconfig.save_service(nss_service) >> + > > NACK > > It should not be set to such high value for each client. > > It should be configured if and only if sssd is in the ipa-server mode > (trust with AD) > > LS > Lukas, it actually is set only when '--on-master' option is used, as can be (hopefully) seen from the following code: """ if not options.on_master: if options.primary: domain.set_option('ipa_server', ', '.join(cli_server)) else: domain.set_option('ipa_server', '_srv_, %s' % ', '.join(cli_server)) else: domain.set_option('ipa_server_mode', 'True') # the master should only use itself for Kerberos domain.set_option('ipa_server', cli_server[0]) # increase memcache timeout to 10 minutes when in server mode try: nss_service = sssdconfig.get_service('nss') except SSSDConfig.NoServiceError: nss_service = sssdconfig.new_service('nss') nss_service.set_option('memcache_timeout', 600) sssdconfig.save_service(nss_service) """ -- Martin^3 Babinsky From jcholast at redhat.com Wed May 27 11:57:03 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 27 May 2015 13:57:03 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <5565ABCF.5090305@redhat.com> References: <555F03DB.3090702@redhat.com> <556493D3.8010402@redhat.com> <55659335.2060306@redhat.com> <20150527095322.GM19176@redhat.com> <55659571.8070705@redhat.com> <5565AB70.7020004@redhat.com> <5565ABCF.5090305@redhat.com> Message-ID: <5565B10F.1090802@redhat.com> Dne 27.5.2015 v 13:34 Martin Kosek napsal(a): > On 05/27/2015 01:33 PM, Christian Heimes wrote: >> On 2015-05-27 11:59, Martin Kosek wrote: >>> On 05/27/2015 11:53 AM, Alexander Bokovoy wrote: >>>> On Wed, 27 May 2015, Martin Kosek wrote: >>>>> On 05/26/2015 05:40 PM, Jan Cholasta wrote: >>>>>> Dne 22.5.2015 v 12:24 Christian Heimes napsal(a): >>>>> ... >>>>>>> Finally I haven't figured out the best way to configure the instance. An >>>>>>> admin should be able to enable / disable KDC proxy. Should I write a >>>>>>> script or a ipa plugin for the job? >>>>>> >>>>>> A script, ipa-kdcproxy-install, if you want to be consistent with what's >>>>>> already there. >>>>> >>>>> I thought we wanted to install it by default and only switch it on/off via >>>>> configuration in LDAP. In that case, no ipa-*-install should be needed. >>>> As with any other feature which requires configuration of other >>>> components, if it wasn't installed before, you need to make sure you are >>>> able to configure it over upgraded instance. Not providing >>>> ipa-kdcproxy-install would mean you are not supporting an upgrade case. >>> >>> I do not disagree with the approach for optional components. But as I wrote >>> above, this was supposed to be configured everywhere by default - both on new >>> and upgraded installations. It doesn't matter whether it's installed by default or not. This is to support disabling and enabling the component - "ipa-kdcproxy-install" to enable, "ipa-kdcproxy-install --uninstall" to disable. >>> >>> AFAIK, it is mostly just one config for Apache and wsgi script. >> >> Yes, it is really just one boolean switch (service enabled/disabled). >> The state of the switch is read when Apache is started or reloaded. In >> the default state KDC Proxy is enabled. When the service is disabled, >> the WSGI script replies with 404 instead. All remaining settings like >> kdc, kadmin and kpasswd server(s) are read from /etc/krb5.conf. This is just an implementation detail. >> >> I had both the per-replica and the global switch implemented. After I >> discussion with Nathaniel and Martin, it's now a global switch only. >> Nathaniel argued, that a global switch is easier to implement as well as >> sufficient for now. >> >> The state of the switch is controlled with ipa config-mod: >> >> ipa config-mod --enable-kdcproxy=TRUE >> ipa config-mod --enable-kdcproxy=FALSE I don't like this approach, as it is completely inconsistent with every other optional component. There should be *one* way to handle them and there already is one, no need to reinvent the wheel. >> >> The schema changes for the new attribute are handled by >> ipa-server-upgrade. The Apache config file is created >> ipa-server-install, ipa-replica-install and ipa-server-upgrade. > > Thanks. This is all we need for 4.2, IMO. > > Martin > -- Jan Cholasta From pvoborni at redhat.com Wed May 27 12:47:28 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 27 May 2015 14:47:28 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <5565B10F.1090802@redhat.com> References: <555F03DB.3090702@redhat.com> <556493D3.8010402@redhat.com> <55659335.2060306@redhat.com> <20150527095322.GM19176@redhat.com> <55659571.8070705@redhat.com> <5565AB70.7020004@redhat.com> <5565ABCF.5090305@redhat.com> <5565B10F.1090802@redhat.com> Message-ID: <5565BCE0.6060409@redhat.com> On 05/27/2015 01:57 PM, Jan Cholasta wrote: > Dne 27.5.2015 v 13:34 Martin Kosek napsal(a): >> On 05/27/2015 01:33 PM, Christian Heimes wrote: >>> On 2015-05-27 11:59, Martin Kosek wrote: >>>> On 05/27/2015 11:53 AM, Alexander Bokovoy wrote: >>>>> On Wed, 27 May 2015, Martin Kosek wrote: >>>>>> On 05/26/2015 05:40 PM, Jan Cholasta wrote: >>>>>>> Dne 22.5.2015 v 12:24 Christian Heimes napsal(a): >>>>>> ... >>>>>>>> Finally I haven't figured out the best way to configure the >>>>>>>> instance. An >>>>>>>> admin should be able to enable / disable KDC proxy. Should I >>>>>>>> write a >>>>>>>> script or a ipa plugin for the job? >>>>>>> >>>>>>> A script, ipa-kdcproxy-install, if you want to be consistent with >>>>>>> what's >>>>>>> already there. >>>>>> >>>>>> I thought we wanted to install it by default and only switch it >>>>>> on/off via >>>>>> configuration in LDAP. In that case, no ipa-*-install should be >>>>>> needed. >>>>> As with any other feature which requires configuration of other >>>>> components, if it wasn't installed before, you need to make sure >>>>> you are >>>>> able to configure it over upgraded instance. Not providing >>>>> ipa-kdcproxy-install would mean you are not supporting an upgrade >>>>> case. >>>> >>>> I do not disagree with the approach for optional components. But as >>>> I wrote >>>> above, this was supposed to be configured everywhere by default - >>>> both on new >>>> and upgraded installations. > > It doesn't matter whether it's installed by default or not. This is to > support disabling and enabling the component - "ipa-kdcproxy-install" to > enable, "ipa-kdcproxy-install --uninstall" to disable. Install/uninstall is not the same thing as enable/disable. Installation is a set of steps which first configures and then (optionally) enables the component. E.g: 1. modify configuration file(s), ldap entries 2. run something which starts the component. E.g. `systemctl start xxx`, an ldap change which is being observed (like topology plugin). The only rationale for external tool is to do stuff which can't be done trough API. E.g. restart of httpd.service or a need of Directory Manager. But in that case the tool should be: ipa-kdcproxy-manage enable|disable > >>>> >>>> AFAIK, it is mostly just one config for Apache and wsgi script. >>> >>> Yes, it is really just one boolean switch (service enabled/disabled). >>> The state of the switch is read when Apache is started or reloaded. In >>> the default state KDC Proxy is enabled. When the service is disabled, >>> the WSGI script replies with 404 instead. All remaining settings like >>> kdc, kadmin and kpasswd server(s) are read from /etc/krb5.conf. > > This is just an implementation detail. > >>> >>> I had both the per-replica and the global switch implemented. After I >>> discussion with Nathaniel and Martin, it's now a global switch only. >>> Nathaniel argued, that a global switch is easier to implement as well as >>> sufficient for now. >>> >>> The state of the switch is controlled with ipa config-mod: >>> >>> ipa config-mod --enable-kdcproxy=TRUE >>> ipa config-mod --enable-kdcproxy=FALSE > > I don't like this approach, as it is completely inconsistent with every > other optional component. There should be *one* way to handle them and > there already is one, no need to reinvent the wheel. Could you be more specific? Is there really *one* way? The only optional components/functions of IPA server which can be turned on and off while still being installed are probably Managed Entry plugin(controlled by ipa-managed-entries) and a Migration mode(controlled in the same fashion as current proposal). Other optional components(CA, DNS, KRA) could be just installed later if they are not installed during server installation. They cannot be disabled nor uninstalled (KRA is exception, there is also uninstallation). So they are not the same case. > >>> >>> The schema changes for the new attribute are handled by >>> ipa-server-upgrade. The Apache config file is created >>> ipa-server-install, ipa-replica-install and ipa-server-upgrade. >> >> Thanks. This is all we need for 4.2, IMO. >> >> Martin >> > -- Petr Vobornik From pspacek at redhat.com Wed May 27 12:50:52 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 27 May 2015 14:50:52 +0200 Subject: [Freeipa-devel] [PATCH 0377-0382] Synchronize changes from LDAP after reconnect Message-ID: <5565BDAC.7070806@redhat.com> Hello, https://fedorahosted.org/bind-dyndb-ldap/ticket/128 Previously records deleted when connection to LDAP server was down were not synchronized properly. It should work now. I use this command to simulate broken connections and connection re-establishment: $ socat tcp-listen:3899,reuseaddr,fork tcp-connect:localhost:389 It should be enough to add "ldap://$(hostname):3899" as LDAP URI to /etc/named.conf and then simulate changes by killing and restarting socat. Let me know if you need any assistance! -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0377-Add-functions-for-MetaLDAP-generation-number-manipul.patch Type: text/x-patch Size: 3404 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0378-Increment-MetaLDAP-generation-number-on-reconnect.patch Type: text/x-patch Size: 799 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0379-Add-iterators-for-dead-nodes-in-metaLDAP.patch Type: text/x-patch Size: 10567 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0380-On-reconnect-detect-and-delete-RBT-nodes-which-were-.patch Type: text/x-patch Size: 2073 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0381-Consolidate-synchronization-state-machine-to-sync_st.patch Type: text/x-patch Size: 4652 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0382-Avoid-synchronization-state-resets.patch Type: text/x-patch Size: 3090 bytes Desc: not available URL: From cheimes at redhat.com Wed May 27 13:16:31 2015 From: cheimes at redhat.com (Christian Heimes) Date: Wed, 27 May 2015 15:16:31 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Provide Kerberos over HTTP (MS-KKDCP) Message-ID: <5565C3AF.1070509@redhat.com> Hello, here is my first patch for FreeIPA. The patch integrates python-kdcproxy for MS-KKDCP support (aka Kerberos over HTTPS). https://www.freeipa.org/page/V4/KDC_Proxy Ticket: https://fedorahosted.org/freeipa/ticket/4801 Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-cheimes-0001-Provide-Kerberos-over-HTTP-MS-KKDCP.patch Type: text/x-patch Size: 35445 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From mbabinsk at redhat.com Wed May 27 13:25:58 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 27 May 2015 15:25:58 +0200 Subject: [Freeipa-devel] Fix password changes via kadmin In-Reply-To: <5562E1FA.3050001@redhat.com> References: <1428274413.19641.118.camel@willson.usersys.redhat.com> <5562E1FA.3050001@redhat.com> Message-ID: <5565C5E6.9060005@redhat.com> On 05/25/2015 10:48 AM, Martin Babinsky wrote: > On 04/06/2015 12:53 AM, Simo Sorce wrote: >> Fix for bug 4914. >> >> I've tested it locally and seem to do exactly what is needed. I couldn't >> detect any side effects, except that if you use kadmin to get a >> randomized password for a service then you'll get a key for all >> supported types (currently aes256, aes128, des3, rc4, camellia128, >> camellia256) instead of just the default ones (aes256, aes128, des3, >> rc4) if you do not specify enctypes. I think that is fine, we use >> ipa-getkeytab anyway in the normal course of business and that one uses >> a different code path. >> >> Simo. >> >> >> > > Hi Simo, > > the patch works as expected. > > My only gripe is with the duplicate code in 'daemons/ipa-kdb/ipa_kdb.c' > between lines 389 and 455. It could be made into a single function to > get key encoding/salt types from LDAP (see my feeble and untested > attempt which I attached). > > > ACK. I will then send the patch fixing duplicate code separately once I consult it with somebody more skilled in C than myself. -- Martin^3 Babinsky From rcritten at redhat.com Wed May 27 13:28:16 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 27 May 2015 09:28:16 -0400 Subject: [Freeipa-devel] Yet another user certificates/Smart Card thread In-Reply-To: <20150527100431.GB24915@dhcp-40-8.bne.redhat.com> References: <55631BCB.8090608@redhat.com> <55631FF5.3080008@redhat.com> <55632A1E.2000802@redhat.com> <20150525142607.GD13469@dhcp-40-8.bne.redhat.com> <55633446.9020709@redhat.com> <55640956.30703@redhat.com> <20150527100431.GB24915@dhcp-40-8.bne.redhat.com> Message-ID: <5565C670.2010208@redhat.com> Fraser Tweedale wrote: > On Tue, May 26, 2015 at 07:49:10AM +0200, Martin Kosek wrote: > I think a global option is sensible starting point. > > We should also consider an option to use revocation reason > "certificateHold" for obj-disable and revive the certificates if the > object is re-enabled via obj-enable. (I'm not sure whether Dogtag > makes this easy but I am pretty sure it's currently possible; and > it's a bit more work for IPA to do this, of course). It is already supported. If you revoke with a reason of 6 then you can remove the hold using the cert-remove-hold command. rob From cheimes at redhat.com Wed May 27 13:34:16 2015 From: cheimes at redhat.com (Christian Heimes) Date: Wed, 27 May 2015 15:34:16 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <5565BCE0.6060409@redhat.com> References: <555F03DB.3090702@redhat.com> <556493D3.8010402@redhat.com> <55659335.2060306@redhat.com> <20150527095322.GM19176@redhat.com> <55659571.8070705@redhat.com> <5565AB70.7020004@redhat.com> <5565ABCF.5090305@redhat.com> <5565B10F.1090802@redhat.com> <5565BCE0.6060409@redhat.com> Message-ID: <5565C7D8.9040307@redhat.com> On 2015-05-27 14:47, Petr Vobornik wrote: > Install/uninstall is not the same thing as enable/disable. Installation > is a set of steps which first configures and then (optionally) enables > the component. > > E.g: > 1. modify configuration file(s), ldap entries > 2. run something which starts the component. E.g. `systemctl start xxx`, > an ldap change which is being observed (like topology plugin). > > The only rationale for external tool is to do stuff which can't be done > trough API. E.g. restart of httpd.service or a need of Directory > Manager. But in that case the tool should be: > > ipa-kdcproxy-manage enable|disable Right, the restart of httpd.service isn't handled by ipa config-mod. A tool like ipa-kdcproxy-manage could handle the restart on a local machine. As far as I know it won't be able to restart httpd on all replicas, too. My current implementation needs a restart of all Apache servers on all machines, that run a kdc proxy instance. Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From jcholast at redhat.com Wed May 27 13:34:59 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 27 May 2015 15:34:59 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <5565BCE0.6060409@redhat.com> References: <555F03DB.3090702@redhat.com> <556493D3.8010402@redhat.com> <55659335.2060306@redhat.com> <20150527095322.GM19176@redhat.com> <55659571.8070705@redhat.com> <5565AB70.7020004@redhat.com> <5565ABCF.5090305@redhat.com> <5565B10F.1090802@redhat.com> <5565BCE0.6060409@redhat.com> Message-ID: <5565C803.2000307@redhat.com> Dne 27.5.2015 v 14:47 Petr Vobornik napsal(a): > On 05/27/2015 01:57 PM, Jan Cholasta wrote: >> Dne 27.5.2015 v 13:34 Martin Kosek napsal(a): >>> On 05/27/2015 01:33 PM, Christian Heimes wrote: >>>> On 2015-05-27 11:59, Martin Kosek wrote: >>>>> On 05/27/2015 11:53 AM, Alexander Bokovoy wrote: >>>>>> On Wed, 27 May 2015, Martin Kosek wrote: >>>>>>> On 05/26/2015 05:40 PM, Jan Cholasta wrote: >>>>>>>> Dne 22.5.2015 v 12:24 Christian Heimes napsal(a): >>>>>>> ... >>>>>>>>> Finally I haven't figured out the best way to configure the >>>>>>>>> instance. An >>>>>>>>> admin should be able to enable / disable KDC proxy. Should I >>>>>>>>> write a >>>>>>>>> script or a ipa plugin for the job? >>>>>>>> >>>>>>>> A script, ipa-kdcproxy-install, if you want to be consistent with >>>>>>>> what's >>>>>>>> already there. >>>>>>> >>>>>>> I thought we wanted to install it by default and only switch it >>>>>>> on/off via >>>>>>> configuration in LDAP. In that case, no ipa-*-install should be >>>>>>> needed. >>>>>> As with any other feature which requires configuration of other >>>>>> components, if it wasn't installed before, you need to make sure >>>>>> you are >>>>>> able to configure it over upgraded instance. Not providing >>>>>> ipa-kdcproxy-install would mean you are not supporting an upgrade >>>>>> case. >>>>> >>>>> I do not disagree with the approach for optional components. But as >>>>> I wrote >>>>> above, this was supposed to be configured everywhere by default - >>>>> both on new >>>>> and upgraded installations. >> >> It doesn't matter whether it's installed by default or not. This is to >> support disabling and enabling the component - "ipa-kdcproxy-install" to >> enable, "ipa-kdcproxy-install --uninstall" to disable. > > Install/uninstall is not the same thing as enable/disable. Installation > is a set of steps which first configures and then (optionally) enables > the component. The configuration steps exist for the sole purpose of making it possible to enable the component after they are done. The result of install is that the component is enabled, and the result of uninstall is that the component is disabled. So, in a way, they are the same thing. > > E.g: > 1. modify configuration file(s), ldap entries > 2. run something which starts the component. E.g. `systemctl start xxx`, > an ldap change which is being observed (like topology plugin). Yes, and this boils down to: 1. enable KDC proxy in LDAP for KDC proxy. > > The only rationale for external tool is to do stuff which can't be done > trough API. E.g. restart of httpd.service or a need of Directory > Manager. But in that case the tool should be: There is no API for enabling/disabling components, so it can't be done through API. > > ipa-kdcproxy-manage enable|disable There is no ipa-ca-manage, ipa-dns-manage or ipa-kra-manage. > >> >>>>> >>>>> AFAIK, it is mostly just one config for Apache and wsgi script. >>>> >>>> Yes, it is really just one boolean switch (service enabled/disabled). >>>> The state of the switch is read when Apache is started or reloaded. In >>>> the default state KDC Proxy is enabled. When the service is disabled, >>>> the WSGI script replies with 404 instead. All remaining settings like >>>> kdc, kadmin and kpasswd server(s) are read from /etc/krb5.conf. >> >> This is just an implementation detail. >> >>>> >>>> I had both the per-replica and the global switch implemented. After I >>>> discussion with Nathaniel and Martin, it's now a global switch only. >>>> Nathaniel argued, that a global switch is easier to implement as >>>> well as >>>> sufficient for now. >>>> >>>> The state of the switch is controlled with ipa config-mod: >>>> >>>> ipa config-mod --enable-kdcproxy=TRUE >>>> ipa config-mod --enable-kdcproxy=FALSE >> >> I don't like this approach, as it is completely inconsistent with every >> other optional component. There should be *one* way to handle them and >> there already is one, no need to reinvent the wheel. > > Could you be more specific? Is there really *one* way? The only optional > components/functions of IPA server which can be turned on and off while > still being installed are probably Managed Entry plugin(controlled by > ipa-managed-entries) and a Migration mode(controlled in the same fashion > as current proposal). These are not components, but rather DS "switches". > > Other optional components(CA, DNS, KRA) could be just installed later if > they are not installed during server installation. They cannot be > disabled nor uninstalled (KRA is exception, there is also > uninstallation). So they are not the same case. They can be uninstalled, it's just not implemented yet :-) > >> >>>> >>>> The schema changes for the new attribute are handled by >>>> ipa-server-upgrade. The Apache config file is created >>>> ipa-server-install, ipa-replica-install and ipa-server-upgrade. >>> >>> Thanks. This is all we need for 4.2, IMO. >>> >>> Martin >>> >> -- Jan Cholasta From pvoborni at redhat.com Wed May 27 13:41:29 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 27 May 2015 15:41:29 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <5565C7D8.9040307@redhat.com> References: <555F03DB.3090702@redhat.com> <556493D3.8010402@redhat.com> <55659335.2060306@redhat.com> <20150527095322.GM19176@redhat.com> <55659571.8070705@redhat.com> <5565AB70.7020004@redhat.com> <5565ABCF.5090305@redhat.com> <5565B10F.1090802@redhat.com> <5565BCE0.6060409@redhat.com> <5565C7D8.9040307@redhat.com> Message-ID: <5565C989.7060007@redhat.com> On 05/27/2015 03:34 PM, Christian Heimes wrote: > On 2015-05-27 14:47, Petr Vobornik wrote: >> Install/uninstall is not the same thing as enable/disable. Installation >> is a set of steps which first configures and then (optionally) enables >> the component. >> >> E.g: >> 1. modify configuration file(s), ldap entries >> 2. run something which starts the component. E.g. `systemctl start xxx`, >> an ldap change which is being observed (like topology plugin). >> >> The only rationale for external tool is to do stuff which can't be done >> trough API. E.g. restart of httpd.service or a need of Directory >> Manager. But in that case the tool should be: >> >> ipa-kdcproxy-manage enable|disable > > Right, the restart of httpd.service isn't handled by ipa config-mod. A > tool like ipa-kdcproxy-manage could handle the restart on a local > machine. As far as I know it won't be able to restart httpd on all > replicas, too. > > My current implementation needs a restart of all Apache servers on all > machines, that run a kdc proxy instance. > > Christian > It would be great to have a privileged daemon which could observed replicated configuration and perform such tasks on all servers so we would eliminate manual tasks(and errors and misconceptions which are caused by forgotten manual tasks) as much as possible. -- Petr Vobornik From simo at redhat.com Wed May 27 13:43:08 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 27 May 2015 09:43:08 -0400 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <5565B10F.1090802@redhat.com> References: <555F03DB.3090702@redhat.com> <556493D3.8010402@redhat.com> <55659335.2060306@redhat.com> <20150527095322.GM19176@redhat.com> <55659571.8070705@redhat.com> <5565AB70.7020004@redhat.com> <5565ABCF.5090305@redhat.com> <5565B10F.1090802@redhat.com> Message-ID: <1432734188.3243.117.camel@willson.usersys.redhat.com> On Wed, 2015-05-27 at 13:57 +0200, Jan Cholasta wrote: > >> > >> ipa config-mod --enable-kdcproxy=TRUE > >> ipa config-mod --enable-kdcproxy=FALSE > > I don't like this approach, as it is completely inconsistent with > every > other optional component. There should be *one* way to handle them > and > there already is one, no need to reinvent the wheel. Sorry Jan, but this is really the correct approach. We want a boolean in LDAP to control whether the IPA Domain allows proxying or not, the code is embedded in the overall framework and has no need for explicit install/uninstall unlike the CA or DNS components. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed May 27 13:47:10 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 27 May 2015 09:47:10 -0400 Subject: [Freeipa-devel] Fix password changes via kadmin In-Reply-To: <5565C5E6.9060005@redhat.com> References: <1428274413.19641.118.camel@willson.usersys.redhat.com> <5562E1FA.3050001@redhat.com> <5565C5E6.9060005@redhat.com> Message-ID: <1432734430.3243.118.camel@willson.usersys.redhat.com> On Wed, 2015-05-27 at 15:25 +0200, Martin Babinsky wrote: > On 05/25/2015 10:48 AM, Martin Babinsky wrote: > > On 04/06/2015 12:53 AM, Simo Sorce wrote: > >> Fix for bug 4914. > >> > >> I've tested it locally and seem to do exactly what is needed. I couldn't > >> detect any side effects, except that if you use kadmin to get a > >> randomized password for a service then you'll get a key for all > >> supported types (currently aes256, aes128, des3, rc4, camellia128, > >> camellia256) instead of just the default ones (aes256, aes128, des3, > >> rc4) if you do not specify enctypes. I think that is fine, we use > >> ipa-getkeytab anyway in the normal course of business and that one uses > >> a different code path. > >> > >> Simo. > >> > >> > >> > > > > Hi Simo, > > > > the patch works as expected. > > > > My only gripe is with the duplicate code in 'daemons/ipa-kdb/ipa_kdb.c' > > between lines 389 and 455. It could be made into a single function to > > get key encoding/salt types from LDAP (see my feeble and untested > > attempt which I attached). > > > > > > > ACK. > > I will then send the patch fixing duplicate code separately once I > consult it with somebody more skilled in C than myself. > Thanks, added your reviewed-by and pushed to master. Martin, should we push this to other branches too ? Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Wed May 27 13:47:31 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 27 May 2015 15:47:31 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <1432734188.3243.117.camel@willson.usersys.redhat.com> References: <555F03DB.3090702@redhat.com> <556493D3.8010402@redhat.com> <55659335.2060306@redhat.com> <20150527095322.GM19176@redhat.com> <55659571.8070705@redhat.com> <5565AB70.7020004@redhat.com> <5565ABCF.5090305@redhat.com> <5565B10F.1090802@redhat.com> <1432734188.3243.117.camel@willson.usersys.redhat.com> Message-ID: <5565CAF3.9020903@redhat.com> Dne 27.5.2015 v 15:43 Simo Sorce napsal(a): > On Wed, 2015-05-27 at 13:57 +0200, Jan Cholasta wrote: >>>> >>>> ipa config-mod --enable-kdcproxy=TRUE >>>> ipa config-mod --enable-kdcproxy=FALSE >> >> I don't like this approach, as it is completely inconsistent with >> every >> other optional component. There should be *one* way to handle them >> and >> there already is one, no need to reinvent the wheel. > > Sorry Jan, but this is really the correct approach. I don't think so. > > We want a boolean in LDAP to control whether the IPA Domain allows > proxying or not, the code is embedded in the overall framework and has > no need for explicit install/uninstall unlike the CA or DNS components. There is a boolean for every other component/service as well. If you want to add new API to manipulate the boolean, fine, but it should be done in a generic way that works for other components as well. > > Simo. > -- Jan Cholasta From npmccallum at redhat.com Wed May 27 13:51:00 2015 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 27 May 2015 09:51:00 -0400 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <5565CAF3.9020903@redhat.com> References: <555F03DB.3090702@redhat.com> <556493D3.8010402@redhat.com> <55659335.2060306@redhat.com> <20150527095322.GM19176@redhat.com> <55659571.8070705@redhat.com> <5565AB70.7020004@redhat.com> <5565ABCF.5090305@redhat.com> <5565B10F.1090802@redhat.com> <1432734188.3243.117.camel@willson.usersys.redhat.com> <5565CAF3.9020903@redhat.com> Message-ID: <1432734660.3354.53.camel@redhat.com> On Wed, 2015-05-27 at 15:47 +0200, Jan Cholasta wrote: > Dne 27.5.2015 v 15:43 Simo Sorce napsal(a): > > On Wed, 2015-05-27 at 13:57 +0200, Jan Cholasta wrote: > > > > > > > > > > ipa config-mod --enable-kdcproxy=TRUE > > > > > ipa config-mod --enable-kdcproxy=FALSE > > > > > > I don't like this approach, as it is completely inconsistent with > > > every > > > other optional component. There should be *one* way to handle > > > them > > > and > > > there already is one, no need to reinvent the wheel. > > > > Sorry Jan, but this is really the correct approach. > > I don't think so. > > > > > We want a boolean in LDAP to control whether the IPA Domain allows > > proxying or not, the code is embedded in the overall framework and > > has > > no need for explicit install/uninstall unlike the CA or DNS > > components. > > There is a boolean for every other component/service as well. If you > want to add new API to manipulate the boolean, fine, but it should be > > done in a generic way that works for other components as well. As I understand the problem, there is an assumption that an optional component has a distinct service to start and stop. That is not the case here. This is just new config for apache. Nathaniel From ftweedal at redhat.com Wed May 27 13:53:15 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 27 May 2015 23:53:15 +1000 Subject: [Freeipa-devel] [PATCH 0014] Support multiple user and host certificates Message-ID: <20150527135315.GC24915@dhcp-40-8.bne.redhat.com> This patch adds supports for multiple user / host certificates. No schema change is needed ('usercertificate' attribute is already multi-value). The revoke-previous-cert behaviour of host-mod and user-mod has been removed but revocation behaviour of -del and -disable is preserved. The latest profiles/caacl patchset (0001..0013 v5) depends on this patch for correct cert-request behaviour. There is one design question (or maybe more, let me know): the `--out=FILENAME' option to {host,service} show saves ONE certificate to the named file. I propose to either: a) write all certs, suffixing suggested filename with either a sequential numerical index, e.g. "cert.pem" becomes "cert.pem.1", "cert.pem.2", and so on; or b) as above, but suffix with serial number and, if there are different issues, some issuer-identifying information. Let me know your thoughts. Thanks, Fraser -------------- next part -------------- >From 333654797908ab6a71a84b51723bd1d5e59637d0 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Wed, 27 May 2015 08:02:08 -0400 Subject: [PATCH] Support multiple host and service certificates Update the framework to support multiple host and service certificates. host-mod now sets 'usercertificate' values without revoking existing certificate. Similarly, service-mod does nothing with preexisting 'usercertificate' values where previously it raised an error. The existing behaviour of host-disable, host-del, service-disable and service-del (revoke existing certificate) is preserved but now applies to all certificates in the host or service entry. Part of: http://www.freeipa.org/page/V4/User_Certificates --- ipalib/plugins/host.py | 64 +++++++++++++---------------------------------- ipalib/plugins/service.py | 55 ++++++++++++++++------------------------ 2 files changed, 38 insertions(+), 81 deletions(-) diff --git a/ipalib/plugins/host.py b/ipalib/plugins/host.py index c47439743da45b8629d1b2afbd210d87591784ce..880a3b5d3c2de79a9752ec3fa64ed729ffd42641 100644 --- a/ipalib/plugins/host.py +++ b/ipalib/plugins/host.py @@ -493,7 +493,7 @@ class host(LDAPObject): label=_('Random password'), flags=('no_create', 'no_update', 'no_search', 'virtual_attribute'), ), - Bytes('usercertificate?', validate_certificate, + Bytes('usercertificate*', validate_certificate, cli_name='certificate', label=_('Certificate'), doc=_('Base-64 encoded server certificate'), @@ -640,11 +640,11 @@ class host_add(LDAPCreate): entry_attrs['userpassword'] = ipa_generate_password(characters=host_pwd_chars) # save the password so it can be displayed in post_callback setattr(context, 'randompassword', entry_attrs['userpassword']) - cert = options.get('usercertificate') - if cert: - cert = x509.normalize_certificate(cert) + certs = options.get('usercertificate', []) + certs_der = map(x509.normalize_certificate, certs) + for cert in certs_der: x509.verify_cert_subject(ldap, keys[-1], cert) - entry_attrs['usercertificate'] = cert + entry_attrs['usercertificate'] = certs_der entry_attrs['managedby'] = dn entry_attrs['objectclass'].append('ieee802device') entry_attrs['objectclass'].append('ipasshhost') @@ -786,8 +786,7 @@ class host_del(LDAPDelete): entry_attrs = ldap.get_entry(dn, ['usercertificate']) except errors.NotFound: self.obj.handle_not_found(*keys) - cert = entry_attrs.single_value.get('usercertificate') - if cert: + for cert in entry_attrs.get('usercertificate', []): cert = x509.normalize_certificate(cert) try: serial = unicode(x509.get_serial_number(cert, x509.DER)) @@ -864,39 +863,10 @@ class host_mod(LDAPUpdate): if 'krbprincipalaux' not in obj_classes: obj_classes.append('krbprincipalaux') entry_attrs['objectclass'] = obj_classes - cert = x509.normalize_certificate(entry_attrs.get('usercertificate')) - if cert: - if self.api.Command.ca_is_enabled()['result']: - x509.verify_cert_subject(ldap, keys[-1], cert) - entry_attrs_old = ldap.get_entry(dn, ['usercertificate']) - oldcert = entry_attrs_old.single_value.get('usercertificate') - if oldcert: - oldcert = x509.normalize_certificate(oldcert) - try: - serial = x509.get_serial_number(oldcert, x509.DER) - serial = unicode(serial) - try: - result = api.Command['cert_show'](serial)['result'] - if 'revocation_reason' not in result: - try: - api.Command['cert_revoke']( - serial, revocation_reason=4) - except errors.NotImplementedError: - # some CA's might not implement revoke - pass - except errors.NotImplementedError: - # some CA's might not implement revoke - pass - except NSPRError, nsprerr: - if nsprerr.errno == -8183: - # If we can't decode the cert them proceed with - # modifying the host. - self.log.info("Problem decoding certificate %s" % - nsprerr.args[1]) - else: - raise nsprerr - entry_attrs['usercertificate'] = cert + for usercertificate in entry_attrs.get('usercertificate', []): + cert = x509.normalize_certificate(usercertificate) + x509.verify_cert_subject(ldap, keys[-1], cert) if options.get('random'): entry_attrs['userpassword'] = ipa_generate_password(characters=host_pwd_chars) @@ -1148,10 +1118,9 @@ class host_disable(LDAPQuery): entry_attrs = ldap.get_entry(dn, ['usercertificate']) except errors.NotFound: self.obj.handle_not_found(*keys) - cert = entry_attrs.single_value.get('usercertificate') - if cert: - if self.api.Command.ca_is_enabled()['result']: - cert = x509.normalize_certificate(cert) + if self.api.Command.ca_is_enabled()['result']: + certs = entry_attrs.get('usercertificate', []) + for cert in map(x509.normalize_certificate, certs): try: serial = unicode(x509.get_serial_number(cert, x509.DER)) try: @@ -1175,10 +1144,11 @@ class host_disable(LDAPQuery): else: raise nsprerr - # Remove the usercertificate altogether - entry_attrs['usercertificate'] = None - ldap.update_entry(entry_attrs) - done_work = True + if len(certs) > 0: + # Remove the usercertificate altogether + entry_attrs['usercertificate'] = None + ldap.update_entry(entry_attrs) + done_work = True self.obj.get_password_attributes(ldap, dn, entry_attrs) if entry_attrs['has_keytab']: diff --git a/ipalib/plugins/service.py b/ipalib/plugins/service.py index b37dc7b4bf56b69df204fd29e9487f1390197bbe..8e8f5e9d8683d55e1e334ea880163d84b3d80079 100644 --- a/ipalib/plugins/service.py +++ b/ipalib/plugins/service.py @@ -437,7 +437,7 @@ class service(LDAPObject): primary_key=True, normalizer=lambda value: normalize_principal(value), ), - Bytes('usercertificate?', validate_certificate, + Bytes('usercertificate*', validate_certificate, cli_name='certificate', label=_('Certificate'), doc=_('Base-64 encoded server certificate'), @@ -503,11 +503,11 @@ class service_add(LDAPCreate): self.obj.validate_ipakrbauthzdata(entry_attrs) - cert = options.get('usercertificate') - if cert: - dercert = x509.normalize_certificate(cert) + certs = options.get('usercertificate', []) + certs_der = map(x509.normalize_certificate, certs) + for dercert in certs_der x509.verify_cert_subject(ldap, hostname, dercert) - entry_attrs['usercertificate'] = dercert + entry_attrs['usercertificate'] = certs_der if not options.get('force', False): # We know the host exists if we've gotten this far but we @@ -555,9 +555,7 @@ class service_del(LDAPDelete): entry_attrs = ldap.get_entry(dn, ['usercertificate']) except errors.NotFound: self.obj.handle_not_found(*keys) - cert = entry_attrs.get('usercertificate') - if cert: - cert = cert[0] + for cert in entry_attrs.get('usercertificate', []): try: serial = unicode(x509.get_serial_number(cert, x509.DER)) try: @@ -597,25 +595,13 @@ class service_mod(LDAPUpdate): self.obj.validate_ipakrbauthzdata(entry_attrs) - if 'usercertificate' in options: - (service, hostname, realm) = split_principal(keys[-1]) - cert = options.get('usercertificate') - if cert: - dercert = x509.normalize_certificate(cert) - x509.verify_cert_subject(ldap, hostname, dercert) - try: - entry_attrs_old = ldap.get_entry(dn, ['usercertificate']) - except errors.NotFound: - self.obj.handle_not_found(*keys) - if 'usercertificate' in entry_attrs_old: - # FIXME: what to do here? do we revoke the old cert? - fmt = 'entry already has a certificate, serial number: %s' % ( - x509.get_serial_number(entry_attrs_old['usercertificate'][0], x509.DER) - ) - raise errors.GenericError(format=fmt) - entry_attrs['usercertificate'] = dercert - else: - entry_attrs['usercertificate'] = None + (service, hostname, realm) = split_principal(keys[-1]) + + certs = options.get('usercertificate', []) + certs_der = map(x509.normalize_certificate, certs) + for dercert in certs_der: + x509.verify_cert_subject(ldap, hostname, dercert) + entry_attrs['usercertificate'] = certs_der update_krbticketflags(ldap, entry_attrs, attrs_list, options, True) @@ -815,9 +801,9 @@ class service_disable(LDAPQuery): # See if we do any work at all here and if not raise an exception done_work = False - if 'usercertificate' in entry_attrs: - if self.api.Command.ca_is_enabled()['result']: - cert = x509.normalize_certificate(entry_attrs.get('usercertificate')[0]) + if self.api.Command.ca_is_enabled()['result']: + certs = entry_attrs.get('usercertificate', []) + for cert in map(x509.normalize_certificate, certs): try: serial = unicode(x509.get_serial_number(cert, x509.DER)) try: @@ -839,10 +825,11 @@ class service_disable(LDAPQuery): else: raise nsprerr - # Remove the usercertificate altogether - entry_attrs['usercertificate'] = None - ldap.update_entry(entry_attrs) - done_work = True + if len(certs) > 0: + # Remove the usercertificate altogether + entry_attrs['usercertificate'] = None + ldap.update_entry(entry_attrs) + done_work = True self.obj.get_password_attributes(ldap, dn, entry_attrs) if entry_attrs['has_keytab']: -- 2.1.0 From npmccallum at redhat.com Wed May 27 13:54:16 2015 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 27 May 2015 09:54:16 -0400 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <5565C989.7060007@redhat.com> References: <555F03DB.3090702@redhat.com> <556493D3.8010402@redhat.com> <55659335.2060306@redhat.com> <20150527095322.GM19176@redhat.com> <55659571.8070705@redhat.com> <5565AB70.7020004@redhat.com> <5565ABCF.5090305@redhat.com> <5565B10F.1090802@redhat.com> <5565BCE0.6060409@redhat.com> <5565C7D8.9040307@redhat.com> <5565C989.7060007@redhat.com> Message-ID: <1432734856.3354.55.camel@redhat.com> On Wed, 2015-05-27 at 15:41 +0200, Petr Vobornik wrote: > On 05/27/2015 03:34 PM, Christian Heimes wrote: > > On 2015-05-27 14:47, Petr Vobornik wrote: > > > Install/uninstall is not the same thing as enable/disable. > > > Installation > > > is a set of steps which first configures and then (optionally) > > > enables > > > the component. > > > > > > E.g: > > > 1. modify configuration file(s), ldap entries > > > 2. run something which starts the component. E.g. `systemctl > > > start xxx`, > > > an ldap change which is being observed (like topology plugin). > > > > > > The only rationale for external tool is to do stuff which can't > > > be done > > > trough API. E.g. restart of httpd.service or a need of Directory > > > Manager. But in that case the tool should be: > > > > > > ipa-kdcproxy-manage enable|disable > > > > Right, the restart of httpd.service isn't handled by ipa config > > -mod. A > > tool like ipa-kdcproxy-manage could handle the restart on a local > > machine. As far as I know it won't be able to restart httpd on all > > replicas, too. > > > > My current implementation needs a restart of all Apache servers on > > all > > machines, that run a kdc proxy instance. > > > > Christian > > > > It would be great to have a privileged daemon which could observed > replicated configuration and perform such tasks on all servers so we > would eliminate manual tasks(and errors and misconceptions which are > caused by forgotten manual tasks) as much as possible. *security shiver* From simo at redhat.com Wed May 27 13:54:28 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 27 May 2015 09:54:28 -0400 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <5565CAF3.9020903@redhat.com> References: <555F03DB.3090702@redhat.com> <556493D3.8010402@redhat.com> <55659335.2060306@redhat.com> <20150527095322.GM19176@redhat.com> <55659571.8070705@redhat.com> <5565AB70.7020004@redhat.com> <5565ABCF.5090305@redhat.com> <5565B10F.1090802@redhat.com> <1432734188.3243.117.camel@willson.usersys.redhat.com> <5565CAF3.9020903@redhat.com> Message-ID: <1432734868.3243.121.camel@willson.usersys.redhat.com> On Wed, 2015-05-27 at 15:47 +0200, Jan Cholasta wrote: > Dne 27.5.2015 v 15:43 Simo Sorce napsal(a): > > On Wed, 2015-05-27 at 13:57 +0200, Jan Cholasta wrote: > >>>> > >>>> ipa config-mod --enable-kdcproxy=TRUE > >>>> ipa config-mod --enable-kdcproxy=FALSE > >> > >> I don't like this approach, as it is completely inconsistent with > >> every > >> other optional component. There should be *one* way to handle them > >> and > >> there already is one, no need to reinvent the wheel. > > > > Sorry Jan, but this is really the correct approach. > > I don't think so. > > > > > We want a boolean in LDAP to control whether the IPA Domain allows > > proxying or not, the code is embedded in the overall framework and has > > no need for explicit install/uninstall unlike the CA or DNS components. > > There is a boolean for every other component/service as well. If you > want to add new API to manipulate the boolean, fine, but it should be > done in a generic way that works for other components as well. This is the same as: ipa config-mod --enable-migration=TRUE Why is it a problem ? This is not a separate service. Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Wed May 27 13:55:16 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 27 May 2015 16:55:16 +0300 Subject: [Freeipa-devel] Fix password changes via kadmin In-Reply-To: <1432734430.3243.118.camel@willson.usersys.redhat.com> References: <1428274413.19641.118.camel@willson.usersys.redhat.com> <5562E1FA.3050001@redhat.com> <5565C5E6.9060005@redhat.com> <1432734430.3243.118.camel@willson.usersys.redhat.com> Message-ID: <20150527135516.GQ19176@redhat.com> On Wed, 27 May 2015, Simo Sorce wrote: >On Wed, 2015-05-27 at 15:25 +0200, Martin Babinsky wrote: >> On 05/25/2015 10:48 AM, Martin Babinsky wrote: >> > On 04/06/2015 12:53 AM, Simo Sorce wrote: >> >> Fix for bug 4914. >> >> >> >> I've tested it locally and seem to do exactly what is needed. I couldn't >> >> detect any side effects, except that if you use kadmin to get a >> >> randomized password for a service then you'll get a key for all >> >> supported types (currently aes256, aes128, des3, rc4, camellia128, >> >> camellia256) instead of just the default ones (aes256, aes128, des3, >> >> rc4) if you do not specify enctypes. I think that is fine, we use >> >> ipa-getkeytab anyway in the normal course of business and that one uses >> >> a different code path. >> >> >> >> Simo. >> >> >> >> >> >> >> > >> > Hi Simo, >> > >> > the patch works as expected. >> > >> > My only gripe is with the duplicate code in 'daemons/ipa-kdb/ipa_kdb.c' >> > between lines 389 and 455. It could be made into a single function to >> > get key encoding/salt types from LDAP (see my feeble and untested >> > attempt which I attached). >> > >> > >> > >> ACK. >> >> I will then send the patch fixing duplicate code separately once I >> consult it with somebody more skilled in C than myself. >> > >Thanks, added your reviewed-by and pushed to master. > >Martin, should we push this to other branches too ? I think we also need this in 4.1 so that it can go to Fedora, Debian, and RHEL releases. -- / Alexander Bokovoy From simo at redhat.com Wed May 27 13:56:19 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 27 May 2015 09:56:19 -0400 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <5565C989.7060007@redhat.com> References: <555F03DB.3090702@redhat.com> <556493D3.8010402@redhat.com> <55659335.2060306@redhat.com> <20150527095322.GM19176@redhat.com> <55659571.8070705@redhat.com> <5565AB70.7020004@redhat.com> <5565ABCF.5090305@redhat.com> <5565B10F.1090802@redhat.com> <5565BCE0.6060409@redhat.com> <5565C7D8.9040307@redhat.com> <5565C989.7060007@redhat.com> Message-ID: <1432734979.3243.123.camel@willson.usersys.redhat.com> On Wed, 2015-05-27 at 15:41 +0200, Petr Vobornik wrote: > On 05/27/2015 03:34 PM, Christian Heimes wrote: > > On 2015-05-27 14:47, Petr Vobornik wrote: > >> Install/uninstall is not the same thing as enable/disable. Installation > >> is a set of steps which first configures and then (optionally) enables > >> the component. > >> > >> E.g: > >> 1. modify configuration file(s), ldap entries > >> 2. run something which starts the component. E.g. `systemctl start xxx`, > >> an ldap change which is being observed (like topology plugin). > >> > >> The only rationale for external tool is to do stuff which can't be done > >> trough API. E.g. restart of httpd.service or a need of Directory > >> Manager. But in that case the tool should be: > >> > >> ipa-kdcproxy-manage enable|disable > > > > Right, the restart of httpd.service isn't handled by ipa config-mod. A > > tool like ipa-kdcproxy-manage could handle the restart on a local > > machine. As far as I know it won't be able to restart httpd on all > > replicas, too. > > > > My current implementation needs a restart of all Apache servers on all > > machines, that run a kdc proxy instance. > > > > Christian > > > > It would be great to have a privileged daemon which could observed > replicated configuration and perform such tasks on all servers so we > would eliminate manual tasks(and errors and misconceptions which are > caused by forgotten manual tasks) as much as possible. Yes this is something we had a need for, for a while, we could, perhaps, turn custodia in such a service, or embed custodia in there, as they are both very privileged service that interact with LDAP to find information. Simo. > -- > Petr Vobornik > -- Simo Sorce * Red Hat, Inc * New York From cheimes at redhat.com Wed May 27 14:01:57 2015 From: cheimes at redhat.com (Christian Heimes) Date: Wed, 27 May 2015 16:01:57 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <1432734660.3354.53.camel@redhat.com> References: <555F03DB.3090702@redhat.com> <556493D3.8010402@redhat.com> <55659335.2060306@redhat.com> <20150527095322.GM19176@redhat.com> <55659571.8070705@redhat.com> <5565AB70.7020004@redhat.com> <5565ABCF.5090305@redhat.com> <5565B10F.1090802@redhat.com> <1432734188.3243.117.camel@willson.usersys.redhat.com> <5565CAF3.9020903@redhat.com> <1432734660.3354.53.camel@redhat.com> Message-ID: <5565CE55.50303@redhat.com> On 2015-05-27 15:51, Nathaniel McCallum wrote: > As I understand the problem, there is an assumption that an optional > component has a distinct service to start and stop. That is not the > case here. This is just new config for apache. More details: The KDC Proxy uses the same Apache instance as FreeIPAs Web GUI and Tomcat. There is no extra service involved. The switch just decides if https://ipa.example.org/KdcProxy acts as a MS-KKDCP end point or returns a 404 error. My patch "0001 Provide Kerberos over HTTP (MS-KKDCP)" has more details. Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From ftweedal at redhat.com Wed May 27 14:04:35 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 28 May 2015 00:04:35 +1000 Subject: [Freeipa-devel] [PATCHES 0001-0013 v5] Profiles and CA ACLs In-Reply-To: <20150526155930.GI13469@dhcp-40-8.bne.redhat.com> References: <555AF9E1.1010606@redhat.com> <20150519115027.GA12806@dhcp-40-8.bne.redhat.com> <555C1E5C.2080707@redhat.com> <20150520055636.GF12806@dhcp-40-8.bne.redhat.com> <555C30FE.4030707@redhat.com> <20150520144106.GH12806@dhcp-40-8.bne.redhat.com> <555DCC96.2050001@redhat.com> <555DD031.8070302@redhat.com> <555DD39C.3070103@redhat.com> <20150526155930.GI13469@dhcp-40-8.bne.redhat.com> Message-ID: <20150527140434.GD24915@dhcp-40-8.bne.redhat.com> 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 -------------- next part -------------- >From 39634f726d73e9b2f3a8e07d6486a9d9b80402d1 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 20 Apr 2015 23:20:19 -0400 Subject: [PATCH 01/13] Install CA with LDAP profiles backend Install the Dogtag CA to use the LDAPProfileSubsystem instead of the default (file-based) ProfileSubsystem. Part of: https://fedorahosted.org/freeipa/ticket/4560 --- freeipa.spec.in | 6 +++--- ipaserver/install/cainstance.py | 1 + 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/freeipa.spec.in b/freeipa.spec.in index 7dc576256865fb04b3f322b2094a5e3ece7776a5..d615f74f796ee41f27af0043621d9dfedd083e77 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -92,7 +92,7 @@ BuildRequires: python-backports-ssl_match_hostname BuildRequires: softhsm-devel >= 2.0.0b1-3 BuildRequires: openssl-devel BuildRequires: p11-kit-devel -BuildRequires: pki-base >= 10.2.1-0.1 +BuildRequires: pki-base >= 10.2.4-1 BuildRequires: python-pytest-multihost >= 0.5 BuildRequires: python-pytest-sourceorder @@ -135,8 +135,8 @@ Requires(post): systemd-units Requires: selinux-policy >= %{selinux_policy_version} Requires(post): selinux-policy-base Requires: slapi-nis >= 0.54.2-1 -Requires: pki-ca >= 10.2.1-0.2 -Requires: pki-kra >= 10.2.1-0.1 +Requires: pki-ca >= 10.2.4-1 +Requires: pki-kra >= 10.2.4-1 Requires(preun): python systemd-units Requires(postun): python systemd-units Requires: python-dns >= 1.11.1 diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index 5133940687204b615eec56b6a89542ddd5617539..030c9f12daba4b38b748da8940e38d3cf2109788 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -503,6 +503,7 @@ class CAInstance(DogtagInstance): config.set("CA", "pki_restart_configured_instance", "False") config.set("CA", "pki_backup_keys", "True") config.set("CA", "pki_backup_password", self.admin_password) + config.set("CA", "pki_profiles_in_ldap", "True") # Client security database config.set("CA", "pki_client_database_dir", self.agent_db) -- 2.1.0 -------------- next part -------------- >From 0503e54670d38c06957d2c1bf254c5c3880ba44c Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Tue, 21 Apr 2015 02:24:10 -0400 Subject: [PATCH 02/13] Add schema for certificate profiles The certprofile object class is used to track IPA-managed certificate profiles in Dogtag and store IPA-specific settings. Part of: https://fedorahosted.org/freeipa/ticket/57 --- install/share/60certificate-profiles.ldif | 3 +++ install/share/Makefile.am | 1 + install/share/bootstrap-template.ldif | 12 ++++++++++++ ipaserver/install/dsinstance.py | 1 + 4 files changed, 17 insertions(+) create mode 100644 install/share/60certificate-profiles.ldif diff --git a/install/share/60certificate-profiles.ldif b/install/share/60certificate-profiles.ldif new file mode 100644 index 0000000000000000000000000000000000000000..f1281949e53386e5bfe8b35e0c15858c693c5467 --- /dev/null +++ b/install/share/60certificate-profiles.ldif @@ -0,0 +1,3 @@ +dn: cn=schema +attributeTypes: (2.16.840.1.113730.3.8.21.1.1 NAME 'ipaCertProfileStoreIssued' DESC 'Store certificates issued using this profile' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA v4.2' ) +objectClasses: (2.16.840.1.113730.3.8.21.2.1 NAME 'ipaCertProfile' SUP top STRUCTURAL MUST ( cn $ description $ ipaCertProfileStoreIssued ) X-ORIGIN 'IPA v4.2' ) diff --git a/install/share/Makefile.am b/install/share/Makefile.am index 8d336690f184025f8199ed1d2c57d8274f0d3886..f44772b20c173c6fe43503716f40454f6f6b6f11 100644 --- a/install/share/Makefile.am +++ b/install/share/Makefile.am @@ -16,6 +16,7 @@ app_DATA = \ 60basev3.ldif \ 60ipadns.ldif \ 60ipapk11.ldif \ + 60certificate-profiles.ldif \ 61kerberos-ipav3.ldif \ 65ipacertstore.ldif \ 65ipasudo.ldif \ diff --git a/install/share/bootstrap-template.ldif b/install/share/bootstrap-template.ldif index 06b82aa4ae74e7766d0c09a63aa75fa222e7ab7d..c5d4bad8b80640881f4631e4873a12c82b0ea48a 100644 --- a/install/share/bootstrap-template.ldif +++ b/install/share/bootstrap-template.ldif @@ -429,3 +429,15 @@ cn: ${REALM}_id_range ipaBaseID: $IDSTART ipaIDRangeSize: $IDRANGE_SIZE ipaRangeType: ipa-local + +dn: cn=ca,$SUFFIX +changetype: add +objectClass: nsContainer +objectClass: top +cn: ca + +dn: cn=certprofiles,cn=ca,$SUFFIX +changetype: add +objectClass: nsContainer +objectClass: top +cn: certprofiles diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py index 064a2ab1db61b465638a77e13e1d9ea43b1cce63..2acab13f247ed18a750f0e1cbbd98f4e63718c03 100644 --- a/ipaserver/install/dsinstance.py +++ b/ipaserver/install/dsinstance.py @@ -57,6 +57,7 @@ IPA_SCHEMA_FILES = ("60kerberos.ldif", "60basev3.ldif", "60ipapk11.ldif", "60ipadns.ldif", + "60certificate-profiles.ldif", "61kerberos-ipav3.ldif", "65ipacertstore.ldif", "65ipasudo.ldif", -- 2.1.0 -------------- next part -------------- >From 1153e8563b747338a9448867b5941f5b4e709250 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Wed, 29 Apr 2015 06:07:58 -0400 Subject: [PATCH 03/13] ipa-pki-proxy: provide access to profiles REST API Part of: https://fedorahosted.org/freeipa/ticket/57 --- install/conf/ipa-pki-proxy.conf | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/install/conf/ipa-pki-proxy.conf b/install/conf/ipa-pki-proxy.conf index 5d21156848f3b5ddf14c42d92a26a30a9f94af36..366ca15a1868758547f9f1d3334fddba38793083 100644 --- a/install/conf/ipa-pki-proxy.conf +++ b/install/conf/ipa-pki-proxy.conf @@ -1,4 +1,4 @@ -# VERSION 5 - DO NOT REMOVE THIS LINE +# VERSION 6 - DO NOT REMOVE THIS LINE ProxyRequests Off @@ -11,7 +11,7 @@ ProxyRequests Off # matches for admin port and installer - + NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate NSSVerifyClient none ProxyPassMatch ajp://localhost:$DOGTAG_PORT @@ -26,5 +26,13 @@ ProxyRequests Off ProxyPassReverse ajp://localhost:$DOGTAG_PORT +# matches for REST API + + NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate + NSSVerifyClient require + ProxyPassMatch ajp://localhost:$DOGTAG_PORT + ProxyPassReverse ajp://localhost:$DOGTAG_PORT + + # Only enable this on servers that are not generating a CRL ${CLONE}RewriteRule ^/ipa/crl/MasterCRL.bin https://$FQDN/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL [L,R=301,NC] -- 2.1.0 -------------- next part -------------- >From bec9eb04e7349a27ea0b5ec7dcc21d5cc7aeb2df Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Thu, 30 Apr 2015 23:50:41 -0400 Subject: [PATCH 04/13] Add ACL to allow CA agent to modify profiles Part of: https://fedorahosted.org/freeipa/ticket/57 --- ipaserver/install/cainstance.py | 29 +++++++++++++++++++++++++++++ ipaserver/install/server.py | 11 +++++++++++ 2 files changed, 40 insertions(+) diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index 030c9f12daba4b38b748da8940e38d3cf2109788..871581b4afc5df854b9a090ef51bb0ad3b3871ee 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -469,6 +469,7 @@ class CAInstance(DogtagInstance): self.step("requesting RA certificate from CA", self.__request_ra_certificate) self.step("issuing RA agent certificate", self.__issue_ra_cert) self.step("adding RA agent as a trusted user", self.__configure_ra) + self.step("authorizing RA to modify profiles", self.__configure_profiles_acl) self.step("configure certmonger for renewals", self.configure_certmonger_renewal) self.step("configure certificate renewals", self.configure_renewal) if not self.clone: @@ -940,6 +941,10 @@ class CAInstance(DogtagInstance): conn.unbind() + def __configure_profiles_acl(self): + """Allow the Certificate Manager Agents group to modify profiles.""" + configure_profiles_acl() + def __run_certutil(self, args, database=None, pwd_file=None, stdin=None): if not database: database = self.ra_agent_db @@ -1825,6 +1830,30 @@ def update_people_entry(dercert): return True +def configure_profiles_acl(): + server_id = installutils.realm_to_serverid(api.env.realm) + dogtag_uri = 'ldapi://%%2fvar%%2frun%%2fslapd-%s.socket' % server_id + updated = False + + dn = DN(('cn', 'aclResources'), ('o', 'ipaca')) + rule = ( + 'certServer.profile.configuration:read,modify:allow (read,modify) ' + 'group="Certificate Manager Agents":' + 'Certificate Manager agents may modify (create/update/delete) and read profiles' + ) + modlist = [(ldap.MOD_ADD, 'resourceACLS', [rule])] + + conn = ldap2.ldap2(shared_instance=False, ldap_uri=dogtag_uri) + if not conn.isconnected(): + conn.connect(autobind=True) + rules = conn.get_entry(dn).get('resourceACLS', []) + if rule not in rules: + conn.conn.modify_s(str(dn), modlist) + updated = True + + conn.disconnect() + return updated + if __name__ == "__main__": standard_logging_setup("install.log") ds = dsinstance.DsInstance() diff --git a/ipaserver/install/server.py b/ipaserver/install/server.py index c08b74828bf811c560963cc4f9e267d3afbeedb3..7bfcb48ea48c0eb108055321d9a00b14ffbfe790 100644 --- a/ipaserver/install/server.py +++ b/ipaserver/install/server.py @@ -284,6 +284,16 @@ def setup_firefox_extension(fstore): http.setup_firefox_extension(realm, domain) +def ca_configure_profiles_acl(ca): + root_logger.info('[Authorizing RA Agent to modify profiles]') + + if not ca.is_configured(): + root_logger.info('CA is not configured') + return False + + return cainstance.configure_profiles_acl() + + def upgrade_ipa_profile(ca, domain, fqdn): """ Update the IPA Profile provided by dogtag @@ -1364,6 +1374,7 @@ def upgrade_configuration(): upgrade_ipa_profile(ca, api.env.domain, fqdn), certificate_renewal_update(ca), ca_enable_pkix(ca), + ca_configure_profiles_acl(ca), ]) if ca_restart: -- 2.1.0 -------------- next part -------------- >From a2c9ee6d17d44c5fe277898f7e2671d5258c811e Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Thu, 30 Apr 2015 04:55:29 -0400 Subject: [PATCH 05/13] Add certprofile plugin Add the 'certprofile' plugin which defines the commands for managing certificate profiles and associated permissions. Also update Dogtag network code in 'ipapython.dogtag' to support headers and arbitrary request bodies, to facilitate use of the Dogtag profiles REST API. Part of: https://fedorahosted.org/freeipa/ticket/57 --- ACI.txt | 8 ++ API.txt | 62 +++++++++ install/updates/40-certprofile.update | 9 ++ install/updates/40-delegation.update | 8 ++ install/updates/Makefile.am | 1 + ipalib/constants.py | 1 + ipalib/plugins/certprofile.py | 253 ++++++++++++++++++++++++++++++++++ ipapython/dogtag.py | 29 ++-- ipaserver/plugins/dogtag.py | 176 ++++++++++++++++++++++- 9 files changed, 534 insertions(+), 13 deletions(-) create mode 100644 install/updates/40-certprofile.update create mode 100644 ipalib/plugins/certprofile.py diff --git a/ACI.txt b/ACI.txt index 3c4ebde5b3ac2eb0b8e9465c5f2bd74f5bdbfb01..035a545511e4f56dcb492c97514de59cfc028405 100644 --- a/ACI.txt +++ b/ACI.txt @@ -22,6 +22,14 @@ dn: cn=automount,dc=ipa,dc=example aci: (targetattr = "automountmapname || description")(targetfilter = "(objectclass=automountmap)")(version 3.0;acl "permission:System: Modify Automount Maps";allow (write) groupdn = "ldap:///cn=System: Modify Automount Maps,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: cn=automount,dc=ipa,dc=example aci: (targetfilter = "(objectclass=automountmap)")(version 3.0;acl "permission:System: Remove Automount Maps";allow (delete) groupdn = "ldap:///cn=System: Remove Automount Maps,cn=permissions,cn=pbac,dc=ipa,dc=example";) +dn: cn=certprofiles,cn=ca,dc=ipa,dc=example +aci: (targetfilter = "(objectclass=ipacertprofile)")(version 3.0;acl "permission:System: Delete Certificate Profile";allow (delete) groupdn = "ldap:///cn=System: Delete Certificate Profile,cn=permissions,cn=pbac,dc=ipa,dc=example";) +dn: cn=certprofiles,cn=ca,dc=ipa,dc=example +aci: (targetfilter = "(objectclass=ipacertprofile)")(version 3.0;acl "permission:System: Import Certificate Profile";allow (add) groupdn = "ldap:///cn=System: Import Certificate Profile,cn=permissions,cn=pbac,dc=ipa,dc=example";) +dn: cn=certprofiles,cn=ca,dc=ipa,dc=example +aci: (targetattr = "cn || description || ipacertprofilestoreissued")(targetfilter = "(objectclass=ipacertprofile)")(version 3.0;acl "permission:System: Modify Certificate Profile";allow (write) groupdn = "ldap:///cn=System: Modify Certificate Profile,cn=permissions,cn=pbac,dc=ipa,dc=example";) +dn: cn=certprofiles,cn=ca,dc=ipa,dc=example +aci: (targetattr = "cn || createtimestamp || description || entryusn || ipacertprofilestoreissued || modifytimestamp || objectclass")(targetfilter = "(objectclass=ipacertprofile)")(version 3.0;acl "permission:System: Read Certificate Profiles";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=ipaconfig,cn=etc,dc=ipa,dc=example aci: (targetattr = "cn || createtimestamp || entryusn || ipacertificatesubjectbase || ipaconfigstring || ipacustomfields || ipadefaultemaildomain || ipadefaultloginshell || ipadefaultprimarygroup || ipagroupobjectclasses || ipagroupsearchfields || ipahomesrootdir || ipakrbauthzdata || ipamaxusernamelength || ipamigrationenabled || ipapwdexpadvnotify || ipasearchrecordslimit || ipasearchtimelimit || ipaselinuxusermapdefault || ipaselinuxusermaporder || ipauserauthtype || ipauserobjectclasses || ipausersearchfields || modifytimestamp || objectclass")(targetfilter = "(objectclass=ipaguiconfig)")(version 3.0;acl "permission:System: Read Global Configuration";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=costemplates,cn=accounts,dc=ipa,dc=example diff --git a/API.txt b/API.txt index da69f32de5c12c0d85a7d61d9027385aa3c0ee05..7d221b839a7058e2bc7c6c95f7121e79a30ebcfd 100644 --- a/API.txt +++ b/API.txt @@ -509,6 +509,68 @@ args: 1,1,1 arg: Str('request_id') option: Str('version?', exclude='webui') output: Output('result', None, None) +command: certprofile_del +args: 1,2,3 +arg: Str('cn', attribute=True, cli_name='id', multivalue=True, 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', , None) +output: Output('summary', (, ), None) +output: ListOfPrimaryKeys('value', None, None) +command: certprofile_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='id', multivalue=False, primary_key=True, query=True, required=False) +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, query=True, required=False) +option: Bool('ipacertprofilestoreissued', attribute=True, autofill=False, cli_name='store', default=True, multivalue=False, query=True, required=False) +option: Flag('pkey_only?', autofill=True, default=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Int('sizelimit?', autofill=False, minvalue=0) +option: Int('timelimit?', autofill=False, minvalue=0) +option: Str('version?', exclude='webui') +output: Output('count', , None) +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('truncated', , None) +command: certprofile_import +args: 1,6,3 +arg: Str('cn', attribute=True, cli_name='id', multivalue=False, primary_key=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=True) +option: File('file', cli_name='file') +option: Bool('ipacertprofilestoreissued', attribute=True, cli_name='store', default=True, multivalue=False, required=True) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: certprofile_mod +args: 1,10,3 +arg: Str('cn', attribute=True, cli_name='id', multivalue=False, primary_key=True, query=True, required=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('delattr*', cli_name='delattr', exclude='webui') +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) +option: Bool('ipacertprofilestoreissued', attribute=True, autofill=False, cli_name='store', default=True, multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('rename', cli_name='rename', multivalue=False, primary_key=True, required=False) +option: Flag('rights', autofill=True, default=False) +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: certprofile_show +args: 1,4,3 +arg: Str('cn', attribute=True, cli_name='id', multivalue=False, primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) command: compat_is_enabled args: 0,1,1 option: Str('version?', exclude='webui') diff --git a/install/updates/40-certprofile.update b/install/updates/40-certprofile.update new file mode 100644 index 0000000000000000000000000000000000000000..6b0a81d0ff6d69dabe82138227d105fc780ee17d --- /dev/null +++ b/install/updates/40-certprofile.update @@ -0,0 +1,9 @@ +dn: cn=ca,$SUFFIX +default: objectClass: nsContainer +default: objectClass: top +default: cn: ca + +dn: cn=certprofiles,cn=ca,$SUFFIX +default: objectClass: nsContainer +default: objectClass: top +default: cn: certprofiles diff --git a/install/updates/40-delegation.update b/install/updates/40-delegation.update index 975929bd70400b2f9cf407d6faedb246003d7f58..bc0736c5b6c07747586a56c2cbde9596c7522d1c 100644 --- a/install/updates/40-delegation.update +++ b/install/updates/40-delegation.update @@ -237,3 +237,11 @@ default:ipapermissiontype: SYSTEM dn: cn=config add:aci: (version 3.0;acl "permission:Add Configuration Sub-Entries";allow (add) groupdn = "ldap:///cn=Add Configuration Sub-Entries,cn=permissions,cn=pbac,$SUFFIX";) + +# CA Administrators +dn: cn=CA Administrator,cn=privileges,cn=pbac,$SUFFIX +default:objectClass: nestedgroup +default:objectClass: groupofnames +default:objectClass: top +default:cn: CA Administrator +default:description: CA Administrator diff --git a/install/updates/Makefile.am b/install/updates/Makefile.am index 4e2da05d61a41543914e79c4634331df6018c041..fc6bd624eac619cdddeba29b85440571d85fd69f 100644 --- a/install/updates/Makefile.am +++ b/install/updates/Makefile.am @@ -32,6 +32,7 @@ app_DATA = \ 40-replication.update \ 40-dns.update \ 40-automember.update \ + 40-certprofile.update \ 40-otp.update \ 40-vault.update \ 45-roles.update \ diff --git a/ipalib/constants.py b/ipalib/constants.py index 95dec54a51f38ae63eba667daacf35dcd7500cf3..96396a236b8694b3dd988dfe28c1b0c3cc9e3180 100644 --- a/ipalib/constants.py +++ b/ipalib/constants.py @@ -118,6 +118,7 @@ DEFAULT_CONFIG = ( ('container_radiusproxy', DN(('cn', 'radiusproxy'))), ('container_views', DN(('cn', 'views'), ('cn', 'accounts'))), ('container_masters', DN(('cn', 'masters'), ('cn', 'ipa'), ('cn', 'etc'))), + ('container_certprofile', DN(('cn', 'certprofiles'), ('cn', 'ca'))), # Ports, hosts, and URIs: ('xmlrpc_uri', 'http://localhost:8888/ipa/xml'), diff --git a/ipalib/plugins/certprofile.py b/ipalib/plugins/certprofile.py new file mode 100644 index 0000000000000000000000000000000000000000..1a2d143882469858f225b37ba4ff2dd368fb8853 --- /dev/null +++ b/ipalib/plugins/certprofile.py @@ -0,0 +1,253 @@ +# +# Copyright (C) 2015 FreeIPA Contributors see COPYING for license +# + +import re + +from ipalib import api, Bool, File, Str +from ipalib import output +from ipalib.plugable import Registry +from ipalib.plugins.virtual import VirtualCommand +from ipalib.plugins.baseldap import ( + LDAPObject, LDAPSearch, LDAPCreate, + LDAPDelete, LDAPUpdate, LDAPRetrieve) +from ipalib import ngettext +from ipalib.text import _ + +from ipalib import errors + + +__doc__ = _(""" +Manage Certificate Profiles + +Certificate Profiles are used by Certificate Authority (CA) in the signing of +certificates to determine if a Certificate Signing Request (CSR) is acceptable, +and if so what features and extensions will be present on the certificate. + +The Certificate Profile format is the property-list format understood by the +Dogtag or Red Hat Certificate System CA. + +PROFILE ID SYNTAX: + +A Profile ID is a string without spaces or punctuation starting with a letter +and followed by a sequence of letters, digits or underscore ("_"). + +EXAMPLES: + + Import a profile that will not store issued certificates: + ipa certprofile-import ShortLivedUserCert \\ + --file UserCert.profile --summary "User Certificates" \\ + --store=false + + Delete a certificate profile: + ipa certprofile-del ShortLivedUserCert + + Show information about a profile: + ipa certprofile-show ShortLivedUserCert + + Search for profiles that do not store certificates: + ipa certprofile-find --store=false + +""") + + +register = Registry() + + +def ca_enabled_check(): + """Raise NotFound if CA is not enabled. + + This function is defined in multiple plugins to avoid circular imports + (cert depends on certprofile, so we cannot import cert here). + + """ + if not api.Command.ca_is_enabled()['result']: + raise errors.NotFound(reason=_('CA is not configured')) + + +profile_id_pattern = re.compile('^[a-zA-Z]\w*$') + + +def validate_profile_id(ugettext, value): + """Ensure profile ID matches form required by CA.""" + if profile_id_pattern.match(value) is None: + return _('invalid Profile ID') + else: + return None + + + at register() +class certprofile(LDAPObject): + """ + Certificate Profile object. + """ + container_dn = api.env.container_certprofile + object_name = _('Certificate Profile') + object_name_plural = _('Certificate Profiles') + object_class = ['ipacertprofile'] + default_attributes = [ + 'cn', 'description', 'ipacertprofilestoreissued' + ] + search_attributes = [ + 'cn', 'description', 'ipacertprofilestoreissued' + ] + rdn_is_primary_key = True + label = _('Certificate Profiles') + label_singular = _('Certificate Profile') + + takes_params = ( + Str('cn', validate_profile_id, + primary_key=True, + cli_name='id', + label=_('Profile ID'), + doc=_('Profile ID for referring to this profile'), + ), + Str('description', + required=True, + cli_name='desc', + label=_('Profile description'), + doc=_('Brief description of this profile'), + ), + Bool('ipacertprofilestoreissued', + default=True, + cli_name='store', + label=_('Store issued certificates'), + doc=_('Whether to store certs issued using this profile'), + ), + ) + + permission_filter_objectclasses = ['ipacertprofile'] + managed_permissions = { + 'System: Read Certificate Profiles': { + 'replaces_global_anonymous_aci': True, + 'ipapermbindruletype': 'all', + 'ipapermright': {'read', 'search', 'compare'}, + 'ipapermdefaultattr': { + 'cn', + 'description', + 'ipacertprofilestoreissued', + 'objectclass', + }, + }, + 'System: Import Certificate Profile': { + 'ipapermright': {'add'}, + 'replaces': [ + '(target = "ldap:///cn=*,cn=certprofiles,cn=ca,$SUFFIX")(version 3.0;acl "permission:Import Certificate Profile";allow (add) groupdn = "ldap:///cn=Import Certificate Profile,cn=permissions,cn=pbac,$SUFFIX";)', + ], + 'default_privileges': {'CA Administrator'}, + }, + 'System: Delete Certificate Profile': { + 'ipapermright': {'delete'}, + 'replaces': [ + '(target = "ldap:///cn=*,cn=certprofiles,cn=ca,$SUFFIX")(version 3.0;acl "permission:Delete Certificate Profile";allow (delete) groupdn = "ldap:///cn=Delete Certificate Profile,cn=permissions,cn=pbac,$SUFFIX";)', + ], + 'default_privileges': {'CA Administrator'}, + }, + 'System: Modify Certificate Profile': { + 'ipapermright': {'write'}, + 'ipapermdefaultattr': { + 'cn', + 'description', + 'ipacertprofilestoreissued', + }, + 'replaces': [ + '(targetattr = "cn || description || ipacertprofilestoreissued")(target = "ldap:///cn=*,cn=certprofiles,cn=ca,$SUFFIX")(version 3.0;acl "permission:Modify Certificate Profile";allow (write) groupdn = "ldap:///cn=Modify Certificate Profile,cn=permissions,cn=pbac,$SUFFIX";)', + ], + 'default_privileges': {'CA Administrator'}, + }, + } + + + + at register() +class certprofile_find(LDAPSearch): + __doc__ = _("Search for Certificate Profiles.") + msg_summary = ngettext( + '%(count)d profile matched', '%(count)d profiles matched', 0 + ) + + def execute(self, *args, **kwargs): + ca_enabled_check() + return super(certprofile_find, self).execute(*args, **kwargs) + + + at register() +class certprofile_show(LDAPRetrieve): + __doc__ = _("Display the properties of a Certificate Profile.") + + def execute(self, *args, **kwargs): + ca_enabled_check() + return super(certprofile_show, self).execute(*args, **kwargs) + + + at register() +class certprofile_import(LDAPCreate): + __doc__ = _("Import a Certificate Profile.") + msg_summary = _('Imported profile "%(value)s"') + takes_options = ( + File('file', + label=_('Filename'), + cli_name='file', + flags=('virtual_attribute',), + ), + ) + + PROFILE_ID_PATTERN = re.compile('^profileId=([a-zA-Z]\w*)', re.MULTILINE) + + def pre_callback(self, ldap, dn, entry, entry_attrs, *keys, **options): + ca_enabled_check() + + match = self.PROFILE_ID_PATTERN.search(options['file']) + if match is None: + raise errors.ValidationError(name='file', + error=_("Profile ID is not present in profile data")) + elif keys[0] != match.group(1): + raise errors.ValidationError(name='file', + error=_("Profile ID '%(cli_value)s' does not match profile data '%(file_value)s'") + % {'cli_value': keys[0], 'file_value': match.group(1)} + ) + return dn + + + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + """Import the profile into Dogtag and enable it. + + If the operation succeeds, update the LDAP entry to 'enabled'. + If the operation fails, remove the LDAP entry. + """ + try: + with self.api.Backend.ra_certprofile as profile_api: + profile_api.create_profile(options['file']) + profile_api.enable_profile(keys[0]) + except: + # something went wrong ; delete entry + ldap.delete_entry(dn) + raise + + return dn + + + at register() +class certprofile_del(LDAPDelete): + __doc__ = _("Delete a Certificate Profile.") + msg_summary = _('Deleted profile "%(value)s"') + + def execute(self, *args, **kwargs): + ca_enabled_check() + return super(certprofile_del, self).execute(*args, **kwargs) + + def post_callback(self, ldap, dn, *keys, **options): + with self.api.Backend.ra_certprofile as profile_api: + profile_api.disable_profile(keys[0]) + profile_api.delete_profile(keys[0]) + return dn + + + at register() +class certprofile_mod(LDAPUpdate): + __doc__ = _("Modify Certificate Profile configuration.") + msg_summary = _('Modified Certificate Profile "%(value)s') + + def execute(self, *args, **kwargs): + ca_enabled_check() + return super(certprofile_mod, self).execute(*args, **kwargs) diff --git a/ipapython/dogtag.py b/ipapython/dogtag.py index c74b8736a4b15f7bf081206b52b9876a8c4928af..11311cf7b55d7b84e9434a698dbfd60b0eb142a1 100644 --- a/ipapython/dogtag.py +++ b/ipapython/dogtag.py @@ -233,9 +233,12 @@ def ca_status(ca_host=None, use_proxy=True): return _parse_ca_status(body) -def https_request(host, port, url, secdir, password, nickname, **kw): +def https_request(host, port, url, secdir, password, nickname, + method='POST', headers=None, body=None, **kw): """ + :param method: HTTP request method (defalut: 'POST') :param url: The path (not complete URL!) to post to. + :param body: The request body (encodes kw if None) :param kw: Keyword arguments to encode into POST body. :return: (http_status, http_reason_phrase, http_headers, http_body) as (integer, unicode, dict, str) @@ -254,9 +257,11 @@ def https_request(host, port, url, secdir, password, nickname, **kw): nickname, password, nss.get_default_certdb()) return conn - body = urlencode(kw) + if body is None: + body = urlencode(kw) return _httplib_request( - 'https', host, port, url, connection_factory, body) + 'https', host, port, url, connection_factory, body, + method=method, headers=headers) def http_request(host, port, url, **kw): @@ -288,11 +293,13 @@ def unauthenticated_https_request(host, port, url, **kw): def _httplib_request( - protocol, host, port, path, connection_factory, request_body): + protocol, host, port, path, connection_factory, request_body, + method='POST', headers=None): """ :param request_body: Request body :param connection_factory: Connection class to use. Will be called with the host and port arguments. + :param method: HTTP request method (default: 'POST') Perform a HTTP(s) request. """ @@ -301,13 +308,17 @@ def _httplib_request( uri = '%s://%s%s' % (protocol, ipautil.format_netloc(host, port), path) root_logger.debug('request %r', uri) root_logger.debug('request body %r', request_body) + + headers = headers or {} + if ( + method == 'POST' + and 'content-type' not in (str(k).lower() for k in headers.viewkeys()) + ): + headers['content-type'] = 'application/x-www-form-urlencoded' + try: conn = connection_factory(host, port) - conn.request( - 'POST', uri, - body=request_body, - headers={'Content-type': 'application/x-www-form-urlencoded'}, - ) + conn.request(method, uri, body=request_body, headers=headers) res = conn.getresponse() http_status = res.status diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py index 52bdb0d4245594785e718c63242e27cee0e59322..9654123b16d8e417398d49bf1305fd41880bc3a7 100644 --- a/ipaserver/plugins/dogtag.py +++ b/ipaserver/plugins/dogtag.py @@ -4,8 +4,9 @@ # Jason Gerard DeRose # Rob Crittenden # John Dennis +# Fraser Tweedale # -# Copyright (C) 2014 Red Hat +# Copyright (C) 2014, 2015 Red Hat # see file 'COPYING' for use and warranty information # # This program is free software; you can redistribute it and/or modify @@ -238,17 +239,21 @@ digits and nothing else follows. ''' import datetime +import json from lxml import etree +import os import tempfile import time import urllib2 +import pki from pki.client import PKIConnection import pki.crypto as cryptoutil from pki.kra import KRAClient from ipalib import Backend from ipapython.dn import DN +import ipapython.cookie import ipapython.dogtag from ipapython import ipautil from ipaserver.install.certs import CertDB @@ -1262,13 +1267,12 @@ def select_any_master(ldap2, service='CA'): #------------------------------------------------------------------------------- -from ipalib import api, SkipPluginModule +from ipalib import api, errors, SkipPluginModule if api.env.ra_plugin != 'dogtag': # In this case, abort loading this plugin module... raise SkipPluginModule(reason='dogtag not selected as RA plugin') import os, random from ipaserver.plugins import rabase -from ipalib.errors import CertificateOperationError from ipalib.constants import TYPE_ERROR from ipalib.util import cachedproperty from ipapython import dogtag @@ -1318,7 +1322,7 @@ class ra(rabase.rabase): err_msg = u'%s (%s)' % (err_msg, detail) self.error('%s.%s(): %s', self.fullname, func_name, err_msg) - raise CertificateOperationError(error=err_msg) + raise errors.CertificateOperationError(error=err_msg) @cachedproperty def ca_host(self): @@ -1923,3 +1927,167 @@ class kra(Backend): return KRAClient(connection, crypto) api.register(kra) + + +class RestClient(Backend): + """Simple Dogtag REST client to be subclassed by other backends. + + This class is a context manager. Authenticated calls must be + executed in a ``with`` suite:: + + class ra_certprofile(RestClient): + path = 'profile' + ... + + api.register(ra_certprofile) + + with api.Backend.ra_certprofile as profile_api: + # REST client is now logged in + profile_api.create_profile(...) + + """ + path = None + + @staticmethod + def _parse_dogtag_error(body): + try: + return pki.PKIException.from_json(json.loads(body)) + except: + return None + + def __init__(self): + if api.env.in_tree: + self.sec_dir = api.env.dot_ipa + os.sep + 'alias' + self.pwd_file = self.sec_dir + os.sep + '.pwd' + else: + self.sec_dir = paths.HTTPD_ALIAS_DIR + self.pwd_file = paths.ALIAS_PWDFILE_TXT + self.noise_file = self.sec_dir + os.sep + '.noise' + self.ipa_key_size = "2048" + self.ipa_certificate_nickname = "ipaCert" + self.ca_certificate_nickname = "caCert" + try: + f = open(self.pwd_file, "r") + self.password = f.readline().strip() + f.close() + except IOError: + self.password = '' + super(RestClient, self).__init__() + + # session cookie + self.cookie = None + + @cachedproperty + def ca_host(self): + """ + :return: host + as str + + Select our CA host. + """ + ldap2 = self.api.Backend.ldap2 + if host_has_service(api.env.ca_host, ldap2, "CA"): + return api.env.ca_host + if api.env.host != api.env.ca_host: + if host_has_service(api.env.host, ldap2, "CA"): + return api.env.host + host = select_any_master(ldap2) + if host: + return host + else: + return api.env.ca_host + + def __enter__(self): + """Log into the REST API""" + if self.cookie is not None: + return + status, status_text, resp_headers, resp_body = dogtag.https_request( + self.ca_host, self.env.ca_agent_port, '/ca/rest/account/login', + self.sec_dir, self.password, self.ipa_certificate_nickname, + method='GET' + ) + cookies = ipapython.cookie.Cookie.parse(resp_headers.get('set-cookie', '')) + if status != 200 or len(cookies) == 0: + raise errors.RemoteRetrieveError(reason=_('Failed to authenticate to CA REST API')) + self.cookie = str(cookies[0]) + return self + + def __exit__(self, exc_type, exc_value, traceback): + """Log out of the REST API""" + dogtag.https_request( + self.ca_host, self.env.ca_agent_port, '/ca/rest/account/logout', + self.sec_dir, self.password, self.ipa_certificate_nickname, + method='GET' + ) + self.cookie = None + + def _ssldo(self, method, path, headers=None, body=None): + """ + :param url: The URL to post to. + :param kw: Keyword arguments to encode into POST body. + :return: (http_status, http_reason_phrase, http_headers, http_body) + as (integer, unicode, dict, str) + + Perform an HTTPS request + """ + if self.cookie is None: + raise errors.RemoteRetrieveError( + reason=_("REST API is not logged in.")) + + headers = headers or {} + headers['Cookie'] = self.cookie + + resource = os.path.join('/ca/rest', self.path, path) + + # perform main request + status, status_text, resp_headers, resp_body = dogtag.https_request( + self.ca_host, self.env.ca_agent_port, resource, + self.sec_dir, self.password, self.ipa_certificate_nickname, + method=method, headers=headers, body=body + ) + if status < 200 or status >= 300: + explanation = self._parse_dogtag_error(resp_body) or '' + raise errors.RemoteRetrieveError( + reason=_('Non-2xx response from CA REST API: %(status)d %(status_text)s. %(explanation)s') + % {'status': status, 'status_text': status_text, 'explanation': explanation} + ) + return (status, status_text, resp_headers, resp_body) + + +class ra_certprofile(RestClient): + """ + Profile management backend plugin. + """ + path = 'profiles' + + def create_profile(self, profile_data): + """ + Import the profile into Dogtag + """ + self._ssldo('POST', 'raw', + headers={ + 'Content-type': 'application/xml', + 'Accept': 'application/json', + }, + body=profile_data + ) + + def enable_profile(self, profile_id): + """ + Enable the profile in Dogtag + """ + self._ssldo('POST', profile_id + '?action=enable') + + def disable_profile(self, profile_id): + """ + Enable the profile in Dogtag + """ + self._ssldo('POST', profile_id + '?action=disable') + + def delete_profile(self, profile_id): + """ + Delete the profile from Dogtag + """ + self._ssldo('DELETE', profile_id, headers={'Accept': 'application/json'}) + +api.register(ra_certprofile) -- 2.1.0 -------------- next part -------------- >From 5580c61ca398a0401d45f45f2f5572acb4b3a608 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 11 May 2015 23:38:41 -0400 Subject: [PATCH 06/13] Enable LDAP-based profiles in CA on upgrade Part of: https://fedorahosted.org/freeipa/ticket/4560 --- ipaserver/install/server.py | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/ipaserver/install/server.py b/ipaserver/install/server.py index 7bfcb48ea48c0eb108055321d9a00b14ffbfe790..52d68877c64245b683bf5b310eff637e412cd146 100644 --- a/ipaserver/install/server.py +++ b/ipaserver/install/server.py @@ -294,6 +294,45 @@ def ca_configure_profiles_acl(ca): return cainstance.configure_profiles_acl() +def ca_enable_ldap_profile_subsystem(ca): + root_logger.info('[Ensuring CA is using LDAPProfileSubsystem]') + if not ca.is_configured(): + root_logger.info('CA is not configured') + return False + + caconfig = dogtag.configured_constants() + + needs_update = False + directive = None + try: + for i in range(15): + directive = "subsystem.{}.class".format(i) + value = installutils.get_directive( + caconfig.CS_CFG_PATH, + directive, + separator='=') + if value == 'ProfileSubsystem': + needs_update = True + break + except OSError, e: + root_logger.error('Cannot read CA configuration file "%s": %s', + caconfig.CS_CFG_PATH, e) + return False + + if needs_update: + installutils.set_directive( + caconfig.CS_CFG_PATH, + directive, + 'LDAPProfileSubsystem', + quotes=False, + separator='=') + + # TODO import file-based profiles into Dogtag + # More code needed on Dogtag side for this. + + return needs_update + + def upgrade_ipa_profile(ca, domain, fqdn): """ Update the IPA Profile provided by dogtag @@ -1375,6 +1414,7 @@ def upgrade_configuration(): certificate_renewal_update(ca), ca_enable_pkix(ca), ca_configure_profiles_acl(ca), + ca_enable_ldap_profile_subsystem(ca), ]) if ca_restart: -- 2.1.0 -------------- next part -------------- >From fcce7a1fbea8724a3be83a27364782d83b72a146 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 11 May 2015 21:17:48 -0400 Subject: [PATCH 07/13] Import included profiles during install or upgrade Add a default service profile template as part of FreeIPA and format and import it as part of installation or upgrade process. Also remove the code that modifies the old (file-based) `caIPAserviceCert' profile. Fixes https://fedorahosted.org/freeipa/ticket/4002 --- freeipa.spec.in | 2 + install/configure.ac | 1 + install/share/Makefile.am | 1 + install/share/profiles/Makefile.am | 14 ++ install/share/profiles/caIPAserviceCert.cfg | 109 ++++++++++++ install/tools/ipa-server-install | 6 + install/tools/ipa-upgradeconfig | 1 - ipapython/dogtag.py | 7 +- ipaserver/install/cainstance.py | 253 +++++++--------------------- ipaserver/install/ipa_server_upgrade.py | 1 + ipaserver/install/server.py | 42 ++--- ipaserver/plugins/dogtag.py | 14 +- 12 files changed, 228 insertions(+), 223 deletions(-) create mode 100644 install/share/profiles/Makefile.am create mode 100644 install/share/profiles/caIPAserviceCert.cfg diff --git a/freeipa.spec.in b/freeipa.spec.in index d615f74f796ee41f27af0043621d9dfedd083e77..2306850c550517fe88da63980915392fd3577bf8 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -719,6 +719,8 @@ fi %dir %{_usr}/share/ipa/advise %dir %{_usr}/share/ipa/advise/legacy %{_usr}/share/ipa/advise/legacy/*.template +%dir %{_usr}/share/ipa/profiles +%{_usr}/share/ipa/profiles/*.cfg %dir %{_usr}/share/ipa/ffextension %{_usr}/share/ipa/ffextension/bootstrap.js %{_usr}/share/ipa/ffextension/install.rdf diff --git a/install/configure.ac b/install/configure.ac index 2e48aa5cc67b30f2582de987a12d4e7043256679..57f4219b66bbe1dadaed3e89c3e84b1c8240399e 100644 --- a/install/configure.ac +++ b/install/configure.ac @@ -88,6 +88,7 @@ AC_CONFIG_FILES([ share/Makefile share/advise/Makefile share/advise/legacy/Makefile + share/profiles/Makefile ui/Makefile ui/css/Makefile ui/src/Makefile diff --git a/install/share/Makefile.am b/install/share/Makefile.am index f44772b20c173c6fe43503716f40454f6f6b6f11..31f391be25c58b76cc71971852074d80c5514745 100644 --- a/install/share/Makefile.am +++ b/install/share/Makefile.am @@ -2,6 +2,7 @@ NULL = SUBDIRS = \ advise \ + profiles \ $(NULL) appdir = $(IPA_DATA_DIR) diff --git a/install/share/profiles/Makefile.am b/install/share/profiles/Makefile.am new file mode 100644 index 0000000000000000000000000000000000000000..4e6cf975a0f51d02ec29bd07ac8cb9ccc8320818 --- /dev/null +++ b/install/share/profiles/Makefile.am @@ -0,0 +1,14 @@ +NULL = + +appdir = $(IPA_DATA_DIR)/profiles +app_DATA = \ + caIPAserviceCert.cfg \ + $(NULL) + +EXTRA_DIST = \ + $(app_DATA) \ + $(NULL) + +MAINTAINERCLEANFILES = \ + *~ \ + Makefile.in diff --git a/install/share/profiles/caIPAserviceCert.cfg b/install/share/profiles/caIPAserviceCert.cfg new file mode 100644 index 0000000000000000000000000000000000000000..6c5102f0dbd6bd6c6eaf2fa22e87ed4a5f34553c --- /dev/null +++ b/install/share/profiles/caIPAserviceCert.cfg @@ -0,0 +1,109 @@ +profileId=caIPAserviceCert +classId=caEnrollImpl +desc=This certificate profile is for enrolling server certificates with IPA-RA agent authentication. +visible=false +enable=true +enableBy=admin +auth.instance_id=raCertAuth +name=IPA-RA Agent-Authenticated Server Certificate Enrollment +input.list=i1,i2 +input.i1.class_id=certReqInputImpl +input.i2.class_id=submitterInfoInputImpl +output.list=o1 +output.o1.class_id=certOutputImpl +policyset.list=serverCertSet +policyset.serverCertSet.list=1,2,3,4,5,6,7,8,9,10,11 +policyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl +policyset.serverCertSet.1.constraint.name=Subject Name Constraint +policyset.serverCertSet.1.constraint.params.pattern=CN=[^,]+,.+ +policyset.serverCertSet.1.constraint.params.accept=true +policyset.serverCertSet.1.default.class_id=subjectNameDefaultImpl +policyset.serverCertSet.1.default.name=Subject Name Default +policyset.serverCertSet.1.default.params.name=CN=$$request.req_subject_name.cn$$, $SUBJECT_DN_O +policyset.serverCertSet.2.constraint.class_id=validityConstraintImpl +policyset.serverCertSet.2.constraint.name=Validity Constraint +policyset.serverCertSet.2.constraint.params.range=740 +policyset.serverCertSet.2.constraint.params.notBeforeCheck=false +policyset.serverCertSet.2.constraint.params.notAfterCheck=false +policyset.serverCertSet.2.default.class_id=validityDefaultImpl +policyset.serverCertSet.2.default.name=Validity Default +policyset.serverCertSet.2.default.params.range=731 +policyset.serverCertSet.2.default.params.startTime=0 +policyset.serverCertSet.3.constraint.class_id=keyConstraintImpl +policyset.serverCertSet.3.constraint.name=Key Constraint +policyset.serverCertSet.3.constraint.params.keyType=RSA +policyset.serverCertSet.3.constraint.params.keyParameters=1024,2048,3072,4096 +policyset.serverCertSet.3.default.class_id=userKeyDefaultImpl +policyset.serverCertSet.3.default.name=Key Default +policyset.serverCertSet.4.constraint.class_id=noConstraintImpl +policyset.serverCertSet.4.constraint.name=No Constraint +policyset.serverCertSet.4.default.class_id=authorityKeyIdentifierExtDefaultImpl +policyset.serverCertSet.4.default.name=Authority Key Identifier Default +policyset.serverCertSet.5.constraint.class_id=noConstraintImpl +policyset.serverCertSet.5.constraint.name=No Constraint +policyset.serverCertSet.5.default.class_id=authInfoAccessExtDefaultImpl +policyset.serverCertSet.5.default.name=AIA Extension Default +policyset.serverCertSet.5.default.params.authInfoAccessADEnable_0=true +policyset.serverCertSet.5.default.params.authInfoAccessADLocationType_0=URIName +policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0=http://$IPA_CA_RECORD.$DOMAIN/ca/ocsp +policyset.serverCertSet.5.default.params.authInfoAccessADMethod_0=1.3.6.1.5.5.7.48.1 +policyset.serverCertSet.5.default.params.authInfoAccessCritical=false +policyset.serverCertSet.5.default.params.authInfoAccessNumADs=1 +policyset.serverCertSet.6.constraint.class_id=keyUsageExtConstraintImpl +policyset.serverCertSet.6.constraint.name=Key Usage Extension Constraint +policyset.serverCertSet.6.constraint.params.keyUsageCritical=true +policyset.serverCertSet.6.constraint.params.keyUsageDigitalSignature=true +policyset.serverCertSet.6.constraint.params.keyUsageNonRepudiation=true +policyset.serverCertSet.6.constraint.params.keyUsageDataEncipherment=true +policyset.serverCertSet.6.constraint.params.keyUsageKeyEncipherment=true +policyset.serverCertSet.6.constraint.params.keyUsageKeyAgreement=false +policyset.serverCertSet.6.constraint.params.keyUsageKeyCertSign=false +policyset.serverCertSet.6.constraint.params.keyUsageCrlSign=false +policyset.serverCertSet.6.constraint.params.keyUsageEncipherOnly=false +policyset.serverCertSet.6.constraint.params.keyUsageDecipherOnly=false +policyset.serverCertSet.6.default.class_id=keyUsageExtDefaultImpl +policyset.serverCertSet.6.default.name=Key Usage Default +policyset.serverCertSet.6.default.params.keyUsageCritical=true +policyset.serverCertSet.6.default.params.keyUsageDigitalSignature=true +policyset.serverCertSet.6.default.params.keyUsageNonRepudiation=true +policyset.serverCertSet.6.default.params.keyUsageDataEncipherment=true +policyset.serverCertSet.6.default.params.keyUsageKeyEncipherment=true +policyset.serverCertSet.6.default.params.keyUsageKeyAgreement=false +policyset.serverCertSet.6.default.params.keyUsageKeyCertSign=false +policyset.serverCertSet.6.default.params.keyUsageCrlSign=false +policyset.serverCertSet.6.default.params.keyUsageEncipherOnly=false +policyset.serverCertSet.6.default.params.keyUsageDecipherOnly=false +policyset.serverCertSet.7.constraint.class_id=noConstraintImpl +policyset.serverCertSet.7.constraint.name=No Constraint +policyset.serverCertSet.7.default.class_id=extendedKeyUsageExtDefaultImpl +policyset.serverCertSet.7.default.name=Extended Key Usage Extension Default +policyset.serverCertSet.7.default.params.exKeyUsageCritical=false +policyset.serverCertSet.7.default.params.exKeyUsageOIDs=1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 +policyset.serverCertSet.8.constraint.class_id=signingAlgConstraintImpl +policyset.serverCertSet.8.constraint.name=No Constraint +policyset.serverCertSet.8.constraint.params.signingAlgsAllowed=SHA1withRSA,SHA256withRSA,SHA512withRSA,MD5withRSA,MD2withRSA,SHA1withDSA,SHA1withEC,SHA256withEC,SHA384withEC,SHA512withEC +policyset.serverCertSet.8.default.class_id=signingAlgDefaultImpl +policyset.serverCertSet.8.default.name=Signing Alg +policyset.serverCertSet.8.default.params.signingAlg=- +policyset.serverCertSet.9.constraint.class_id=noConstraintImpl +policyset.serverCertSet.9.constraint.name=No Constraint +policyset.serverCertSet.9.default.class_id=crlDistributionPointsExtDefaultImpl +policyset.serverCertSet.9.default.name=CRL Distribution Points Extension Default +policyset.serverCertSet.9.default.params.crlDistPointsCritical=false +policyset.serverCertSet.9.default.params.crlDistPointsNum=1 +policyset.serverCertSet.9.default.params.crlDistPointsEnable_0=true +policyset.serverCertSet.9.default.params.crlDistPointsIssuerName_0=$CRL_ISSUER +policyset.serverCertSet.9.default.params.crlDistPointsIssuerType_0=DirectoryName +policyset.serverCertSet.9.default.params.crlDistPointsPointName_0=http://$IPA_CA_RECORD.$DOMAIN/ipa/crl/MasterCRL.bin +policyset.serverCertSet.9.default.params.crlDistPointsPointType_0=URIName +policyset.serverCertSet.9.default.params.crlDistPointsReasons_0= +policyset.serverCertSet.10.constraint.class_id=noConstraintImpl +policyset.serverCertSet.10.constraint.name=No Constraint +policyset.serverCertSet.10.default.class_id=subjectKeyIdentifierExtDefaultImpl +policyset.serverCertSet.10.default.name=Subject Key Identifier Extension Default +policyset.serverCertSet.10.default.params.critical=false +policyset.serverCertSet.11.constraint.class_id=noConstraintImpl +policyset.serverCertSet.11.constraint.name=No Constraint +policyset.serverCertSet.11.default.class_id=userExtensionDefaultImpl +policyset.serverCertSet.11.default.name=User Supplied Extension Default +policyset.serverCertSet.11.default.params.userExtOID=2.5.29.17 diff --git a/install/tools/ipa-server-install b/install/tools/ipa-server-install index c7d7c7bff7d5a5e818eaa4a8cb93be94eae7d0c1..b0fc86521ef52c110d2f3860d9c24d0065f13756 100755 --- a/install/tools/ipa-server-install +++ b/install/tools/ipa-server-install @@ -1139,6 +1139,9 @@ def main(): api.env.ca_host = host_name api.bootstrap(**cfg) + if setup_ca: + # ensure profile backend is available + import ipaserver.plugins.dogtag api.finalize() # Create DS user/group if it doesn't exist yet @@ -1291,6 +1294,9 @@ def main(): service.print_msg("Restarting the certificate server") ca.restart(dogtag.configured_constants().PKI_INSTANCE_NAME) + service.print_msg("Importing certificate profiles") + cainstance.import_included_profiles() + if options.setup_dns: api.Backend.ldap2.connect(autobind=True) dns_installer.install(False, False, options) diff --git a/install/tools/ipa-upgradeconfig b/install/tools/ipa-upgradeconfig index 43292966a29c9077443913bdda1c81aa3de06a10..5f3a2b4a2f3864c2809178815c244c2012333fc8 100755 --- a/install/tools/ipa-upgradeconfig +++ b/install/tools/ipa-upgradeconfig @@ -21,7 +21,6 @@ import sys - if __name__ == '__main__': sys.exit("Please run the 'ipa-server-upgrade' command to upgrade the " "IPA server.") diff --git a/ipapython/dogtag.py b/ipapython/dogtag.py index 11311cf7b55d7b84e9434a698dbfd60b0eb142a1..2b4d233354b974884c88d13a3a1b437915ba0776 100644 --- a/ipapython/dogtag.py +++ b/ipapython/dogtag.py @@ -42,6 +42,11 @@ from ipapython.ipa_log_manager import * # the configured version. +INCLUDED_PROFILES = { + # ( profile_id , description , store_issued) + (u'caIPAserviceCert', u'Standard profile for network services', True), + } + class Dogtag10Constants(object): DOGTAG_VERSION = 10 UNSECURE_PORT = 8080 @@ -71,7 +76,6 @@ class Dogtag10Constants(object): RACERT_LINE_SEP = '\n' - IPA_SERVICE_PROFILE = '%s/caIPAserviceCert.cfg' % SERVICE_PROFILE_DIR SIGN_PROFILE = '%s/caJarSigningCert.cfg' % SERVICE_PROFILE_DIR SHARED_DB = True DS_USER = "dirsrv" @@ -110,7 +114,6 @@ class Dogtag9Constants(object): EE_CLIENT_AUTH_PORT = 9446 TOMCAT_SERVER_PORT = 9701 - IPA_SERVICE_PROFILE = '%s/caIPAserviceCert.cfg' % SERVICE_PROFILE_DIR SIGN_PROFILE = '%s/caJarSigningCert.cfg' % SERVICE_PROFILE_DIR SHARED_DB = False DS_USER = "pkisrv" diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index 871581b4afc5df854b9a090ef51bb0ad3b3871ee..ca0b6df5db80bc842a78f614872831ddd82330b1 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -459,10 +459,6 @@ class CAInstance(DogtagInstance): self.step("importing CA chain to RA certificate database", self.__import_ca_chain) self.step("fixing RA database permissions", self.fix_ra_perms) self.step("setting up signing cert profile", self.__setup_sign_profile) - self.step("set certificate subject base", self.__set_subject_in_config) - self.step("enabling Subject Key Identifier", self.enable_subject_key_identifier) - self.step("enabling Subject Alternative Name", self.enable_subject_alternative_name) - self.step("enabling CRL and OCSP extensions for certificates", self.__set_crl_ocsp_extensions) self.step("setting audit signing renewal to 2 years", self.set_audit_renewal) if not self.clone: self.step("restarting certificate server", self.restart_instance) @@ -1125,94 +1121,6 @@ class CAInstance(DogtagInstance): return publishdir - def __set_crl_ocsp_extensions(self): - self.set_crl_ocsp_extensions(self.domain, self.fqdn) - - def set_crl_ocsp_extensions(self, domain, fqdn): - """ - Configure CRL and OCSP extensions in default IPA certificate profile - if not done already. - """ - changed = False - - # OCSP extension - ocsp_url = 'http://%s.%s/ca/ocsp' % (IPA_CA_RECORD, ipautil.format_netloc(domain)) - - ocsp_location_0 = installutils.get_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0', - separator='=') - - if ocsp_location_0 != ocsp_url: - # Set the first OCSP URI - installutils.set_directive(self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0', - ocsp_url, quotes=False, separator='=') - changed = True - - ocsp_profile_count = installutils.get_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.5.default.params.authInfoAccessNumADs', - separator='=') - - if ocsp_profile_count != '1': - installutils.set_directive(self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.5.default.params.authInfoAccessNumADs', - '1', quotes=False, separator='=') - changed = True - - - # CRL extension - crl_url = 'http://%s.%s/ipa/crl/MasterCRL.bin'% (IPA_CA_RECORD, ipautil.format_netloc(domain)) - - crl_point_0 = installutils.get_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.9.default.params.crlDistPointsPointName_0', - separator='=') - - if crl_point_0 != crl_url: - installutils.set_directive(self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.9.default.params.crlDistPointsIssuerName_0', - 'CN=Certificate Authority,o=ipaca', quotes=False, separator='=') - installutils.set_directive(self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.9.default.params.crlDistPointsIssuerType_0', - 'DirectoryName', quotes=False, separator='=') - installutils.set_directive(self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.9.default.params.crlDistPointsPointName_0', - crl_url, quotes=False, separator='=') - changed = True - - crl_profile_count = installutils.get_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.9.default.params.crlDistPointsNum', - separator='=') - - if crl_profile_count != '1': - installutils.set_directive(self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.9.default.params.crlDistPointsNum', - '1', quotes=False, separator='=') - changed = True - - # CRL extension is not enabled by default - setlist = installutils.get_directive(self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.list', separator='=') - new_set_list = None - - if setlist == '1,2,3,4,5,6,7,8': - new_set_list = '1,2,3,4,5,6,7,8,9' - elif setlist == '1,2,3,4,5,6,7,8,10': - new_set_list = '1,2,3,4,5,6,7,8,9,10' - elif setlist == '1,2,3,4,5,6,7,8,10,11': - new_set_list = '1,2,3,4,5,6,7,8,9,10,11' - - if new_set_list: - installutils.set_directive(self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.list', - new_set_list, quotes=False, separator='=') - changed = True - - return changed - def __enable_crl_publish(self): """ @@ -1267,13 +1175,6 @@ class CAInstance(DogtagInstance): installutils.set_directive(caconfig, 'ca.crl.MasterCRL.enableCRLUpdates', 'false', quotes=False, separator='=') installutils.set_directive(caconfig, 'ca.listenToCloneModifications', 'false', quotes=False, separator='=') - def __set_subject_in_config(self): - # dogtag ships with an IPA-specific profile that forces a subject - # format. We need to update that template with our base subject - if installutils.update_file(self.dogtag_constants.IPA_SERVICE_PROFILE, - 'OU=pki-ipa, O=IPA', str(self.subject_base)): - print "Updating subject_base in CA template failed" - def uninstall(self): # just eat state self.restore_state("enabled") @@ -1407,100 +1308,6 @@ class CAInstance(DogtagInstance): services.knownservices.certmonger.stop() - def enable_subject_key_identifier(self): - """ - See if Subject Key Identifier is set in the profile and if not, add it. - """ - setlist = installutils.get_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.list', separator='=') - - # this is the default setting from pki-ca/pki-tomcat. Don't touch it - # if a user has manually modified it. - if setlist == '1,2,3,4,5,6,7,8' or setlist == '1,2,3,4,5,6,7,8,9': - setlist += ',10' - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.list', - setlist, - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.10.constraint.class_id', - 'noConstraintImpl', - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.10.constraint.name', - 'No Constraint', - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.10.default.class_id', - 'subjectKeyIdentifierExtDefaultImpl', - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.10.default.name', - 'Subject Key Identifier Extension Default', - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.10.default.params.critical', - 'false', - quotes=False, separator='=') - return True - - # No update was done - return False - - def enable_subject_alternative_name(self): - """ - See if Subject Alternative Name is set in the profile and if not, add - it. - """ - setlist = installutils.get_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.list', separator='=') - - # this is the default setting from pki-ca/pki-tomcat. Don't touch it - # if a user has manually modified it. - if setlist == '1,2,3,4,5,6,7,8,10' or setlist == '1,2,3,4,5,6,7,8,9,10': - setlist += ',11' - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.list', - setlist, - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.11.constraint.class_id', - 'noConstraintImpl', - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.11.constraint.name', - 'No Constraint', - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.11.default.class_id', - 'userExtensionDefaultImpl', - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.11.default.name', - 'User Supplied Extension Default', - quotes=False, separator='=') - installutils.set_directive( - self.dogtag_constants.IPA_SERVICE_PROFILE, - 'policyset.serverCertSet.11.default.params.userExtOID', - '2.5.29.17', - quotes=False, separator='=') - return True - - # No update was done - return False def set_audit_renewal(self): """ @@ -1586,7 +1393,6 @@ class CAInstance(DogtagInstance): master_entry['ipaConfigString'].append('caRenewalMaster') self.admin_conn.update_entry(master_entry) - @staticmethod def update_cert_config(nickname, cert, dogtag_constants=None): """ @@ -1854,6 +1660,65 @@ def configure_profiles_acl(): conn.disconnect() return updated +def import_included_profiles(): + sub_dict = dict( + DOMAIN=ipautil.format_netloc(api.env.domain), + IPA_CA_RECORD=IPA_CA_RECORD, + CRL_ISSUER='CN=Certificate Authority,o=ipaca', + SUBJECT_DN_O=str(DN(('O', api.env.realm))), + ) + + server_id = installutils.realm_to_serverid(api.env.realm) + dogtag_uri = 'ldapi://%%2fvar%%2frun%%2fslapd-%s.socket' % server_id + conn = ldap2.ldap2(shared_instance=False, ldap_uri=dogtag_uri) + if not conn.isconnected(): + conn.connect(autobind=True) + + for (profile_id, desc, store_issued) in dogtag.INCLUDED_PROFILES: + dn = DN(('cn', profile_id), + api.env.container_certprofile, api.env.basedn) + try: + conn.get_entry(dn) + continue # the profile is present + except errors.NotFound: + # profile not found; add it + profile_data = ipautil.template_file( + '/usr/share/ipa/profiles/{}.cfg'.format(profile_id), sub_dict) + + entry = conn.make_entry( + dn, + objectclass=['ipacertprofile'], + cn=[profile_id], + description=[desc], + ipacertprofilestoreissued=['TRUE' if store_issued else 'FALSE'], + ) + conn.add_entry(entry) + api.Backend.ra_certprofile._read_password() + with api.Backend.ra_certprofile as profile_api: + # import the profile + try: + profile_api.create_profile(profile_data) + except errors.RemoteRetrieveError: + # conflicting profile; replace it if we are + # installing IPA, but keep it for upgrades + if api.env.context == 'installer': + try: + profile_api.disable_profile(profile_id) + except errors.RemoteRetrieveError: + pass + profile_api.delete_profile(profile_id) + profile_api.create_profile(profile_data) + + # enable the profile + try: + profile_api.enable_profile(profile_id) + except errors.RemoteRetrieveError: + pass + + root_logger.info("Imported profile '%s'", profile_id) + + conn.disconnect() + if __name__ == "__main__": standard_logging_setup("install.log") ds = dsinstance.DsInstance() diff --git a/ipaserver/install/ipa_server_upgrade.py b/ipaserver/install/ipa_server_upgrade.py index 31772dc7147e53d2bf07eea191295a7fe30155e4..d3524a4159a17141d989b2f320dbfbeaa3ab305d 100644 --- a/ipaserver/install/ipa_server_upgrade.py +++ b/ipaserver/install/ipa_server_upgrade.py @@ -53,6 +53,7 @@ class ServerUpgrade(admintool.AdminTool): super(ServerUpgrade, self).run() api.bootstrap(in_server=True, context='updates') + import ipaserver.plugins.dogtag # ensure profile backend gets loaded api.finalize() options = self.options diff --git a/ipaserver/install/server.py b/ipaserver/install/server.py index 52d68877c64245b683bf5b310eff637e412cd146..db4d9fbb7271e53efde7fba7f746d3037e717f28 100644 --- a/ipaserver/install/server.py +++ b/ipaserver/install/server.py @@ -333,32 +333,28 @@ def ca_enable_ldap_profile_subsystem(ca): return needs_update -def upgrade_ipa_profile(ca, domain, fqdn): +def ca_import_included_profiles(ca): + root_logger.info('[Ensuring presence of included profiles]') + + if not ca.is_configured(): + root_logger.info('CA is not configured') + return False + + return cainstance.import_included_profiles() + + +def upgrade_ca_audit_cert_validity(ca): """ - Update the IPA Profile provided by dogtag + Update the Dogtag audit signing certificate. Returns True if restart is needed, False otherwise. """ - root_logger.info('[Verifying that CA service certificate profile is updated]') + root_logger.info('[Verifying that CA audit signing cert has 2 year validity]') if ca.is_configured(): - ski = ca.enable_subject_key_identifier() - if ski: - root_logger.debug('Subject Key Identifier updated.') - else: - root_logger.debug('Subject Key Identifier already set.') - san = ca.enable_subject_alternative_name() - if san: - root_logger.debug('Subject Alternative Name updated.') - else: - root_logger.debug('Subject Alternative Name already set.') - audit = ca.set_audit_renewal() - uri = ca.set_crl_ocsp_extensions(domain, fqdn) - if audit or ski or san or uri: - return True + return ca.set_audit_renewal() else: root_logger.info('CA is not configured') - - return False + return False def named_remove_deprecated_options(): @@ -1410,7 +1406,7 @@ def upgrade_configuration(): ca_restart = any([ ca_restart, - upgrade_ipa_profile(ca, api.env.domain, fqdn), + upgrade_ca_audit_cert_validity(ca), certificate_renewal_update(ca), ca_enable_pkix(ca), ca_configure_profiles_acl(ca), @@ -1424,4 +1420,10 @@ def upgrade_configuration(): except ipautil.CalledProcessError as e: root_logger.error("Failed to restart %s: %s", ca.service_name, e) + # This step MUST be done after ca_enable_ldap_profile_subsystem and + # ca_configure_profiles_acl, and the consequent restart, but does not + # itself require a restart. + # + ca_import_included_profiles(ca) + set_sssd_domain_option('ipa_server_mode', 'True') diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py index 9654123b16d8e417398d49bf1305fd41880bc3a7..880b319d68728a40f4479626d5a7c2b8c56ced02 100644 --- a/ipaserver/plugins/dogtag.py +++ b/ipaserver/plugins/dogtag.py @@ -1966,17 +1966,19 @@ class RestClient(Backend): self.ipa_key_size = "2048" self.ipa_certificate_nickname = "ipaCert" self.ca_certificate_nickname = "caCert" - try: - f = open(self.pwd_file, "r") - self.password = f.readline().strip() - f.close() - except IOError: - self.password = '' + self._read_password() super(RestClient, self).__init__() # session cookie self.cookie = None + def _read_password(self): + try: + with open(self.pwd_file) as f: + self.password = f.readline().strip() + except IOError: + self.password = '' + @cachedproperty def ca_host(self): """ -- 2.1.0 -------------- next part -------------- >From 618cd966123845972cc1753d309ebe12b75c1b05 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Thu, 7 May 2015 21:26:24 -0400 Subject: [PATCH 08/13] Add generic split_any_principal method There exist methods to split user or service/host principals, but there is no method to split any kind of principal and allow the caller to decide what to do. Generalize ``ipalib.plugins.service.split_principal`` to return a service of ``None`` if the principal is a user principal, rename it ``split_any_principal`` and reimplement ``split_principal`` to preserve existing behaviour. Part of: https://fedorahosted.org/freeipa/ticket/4938 --- ipalib/plugins/service.py | 27 +++++++++++++++++++-------- 1 file changed, 19 insertions(+), 8 deletions(-) diff --git a/ipalib/plugins/service.py b/ipalib/plugins/service.py index b37dc7b4bf56b69df204fd29e9487f1390197bbe..5af320286bab98535e1f7118840afc4d525be401 100644 --- a/ipalib/plugins/service.py +++ b/ipalib/plugins/service.py @@ -185,19 +185,24 @@ _ticket_flags_map = { _ticket_flags_default = _ticket_flags_map['ipakrbrequirespreauth'] -def split_principal(principal): +def split_any_principal(principal): service = hostname = realm = None # Break down the principal into its component parts, which may or # may not include the realm. sp = principal.split('/') - if len(sp) != 2: - raise errors.MalformedServicePrincipal(reason=_('missing service')) + name_and_realm = None + if len(sp) > 2: + raise errors.MalformedServicePrincipal(reason=_('unable to determine service')) + elif len(sp) == 2: + service = sp[0] + if len(service) == 0: + raise errors.MalformedServicePrincipal(reason=_('blank service')) + name_and_realm = sp[1] + else: + name_and_realm = sp[0] - service = sp[0] - if len(service) == 0: - raise errors.MalformedServicePrincipal(reason=_('blank service')) - sr = sp[1].split('@') + sr = name_and_realm.split('@') if len(sr) > 2: raise errors.MalformedServicePrincipal( reason=_('unable to determine realm')) @@ -212,7 +217,13 @@ def split_principal(principal): realm = api.env.realm # Note that realm may be None. - return (service, hostname, realm) + return service, hostname, realm + +def split_principal(principal): + service, name, realm = split_any_principal(principal) + if service is None: + raise errors.MalformedServicePrincipal(reason=_('missing service')) + return service, name, realm def validate_principal(ugettext, principal): (service, hostname, principal) = split_principal(principal) -- 2.1.0 -------------- next part -------------- >From 733f3ebcc2758ad1f1742a2bcfc6cc0a90a81402 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Fri, 8 May 2015 02:23:24 -0400 Subject: [PATCH 09/13] Add profile_id parameter to 'request_certificate' Add the profile_id parameter to the 'request_certificate' function and update call sites. Also remove multiple occurrences of the default profile ID 'caIPAserviceCert'. Part of: https://fedorahosted.org/freeipa/ticket/57 --- API.txt | 3 ++- checks/check-ra.py | 2 +- ipalib/plugins/cert.py | 2 +- ipapython/dogtag.py | 2 ++ ipaserver/install/certs.py | 2 +- ipaserver/plugins/dogtag.py | 7 +++++-- ipaserver/plugins/rabase.py | 3 ++- 7 files changed, 14 insertions(+), 7 deletions(-) diff --git a/API.txt b/API.txt index 7d221b839a7058e2bc7c6c95f7121e79a30ebcfd..ec414a97c5913c0f4cc812716c72670dae7432da 100644 --- a/API.txt +++ b/API.txt @@ -485,10 +485,11 @@ arg: Str('serial_number') option: Str('version?', exclude='webui') output: Output('result', None, None) command: cert_request -args: 1,4,1 +args: 1,5,1 arg: File('csr', cli_name='csr_file') option: Flag('add', autofill=True, default=False) option: Str('principal') +option: Str('profile_id') option: Str('request_type', autofill=True, default=u'pkcs10') option: Str('version?', exclude='webui') output: Output('result', , None) diff --git a/checks/check-ra.py b/checks/check-ra.py index a1df50ba4a4ad7fc0b6d2118e40977b1da6edf65..28929545ab7f0a63e47a3829c53cf08d784c9524 100755 --- a/checks/check-ra.py +++ b/checks/check-ra.py @@ -90,7 +90,7 @@ def assert_equal(trial, reference): api.log.info('******** Testing ra.request_certificate() ********') -request_result = ra.request_certificate(csr) +request_result = ra.request_certificate(csr, ra.DEFAULT_PROFILE) if verbose: print "request_result=\n%s" % request_result assert_equal(request_result, {'subject' : subject, diff --git a/ipalib/plugins/cert.py b/ipalib/plugins/cert.py index 7e2c77622b3627e9e57bbcb69291f723ecf509bf..e4cb6dc0aa8b89368806b08674aae277b3653e8f 100644 --- a/ipalib/plugins/cert.py +++ b/ipalib/plugins/cert.py @@ -436,7 +436,7 @@ class cert_request(VirtualCommand): # Request the certificate result = self.Backend.ra.request_certificate( - csr, request_type=request_type) + csr, 'caIPAserviceCert', request_type=request_type) cert = x509.load_certificate(result['certificate']) result['issuer'] = unicode(cert.issuer) result['valid_not_before'] = unicode(cert.valid_not_before_str) diff --git a/ipapython/dogtag.py b/ipapython/dogtag.py index 2b4d233354b974884c88d13a3a1b437915ba0776..659751e57bf3deead0966e748c7302600db0f56c 100644 --- a/ipapython/dogtag.py +++ b/ipapython/dogtag.py @@ -47,6 +47,8 @@ INCLUDED_PROFILES = { (u'caIPAserviceCert', u'Standard profile for network services', True), } +DEFAULT_PROFILE = 'caIPAserviceCert' + class Dogtag10Constants(object): DOGTAG_VERSION = 10 UNSECURE_PORT = 8080 diff --git a/ipaserver/install/certs.py b/ipaserver/install/certs.py index bc7dccf805386e9fa84b58d2ff9346085e1b93b1..564332e6fde0698a23884922c5018fab59da7e4d 100644 --- a/ipaserver/install/certs.py +++ b/ipaserver/install/certs.py @@ -386,7 +386,7 @@ class CertDB(object): # We just want the CSR bits, make sure there is nothing else csr = pkcs10.strip_header(csr) - params = {'profileId': 'caIPAserviceCert', + params = {'profileId': dogtag.DEFAULT_PROFILE, 'cert_request_type': 'pkcs10', 'requestor_name': 'IPA Installer', 'cert_request': csr, diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py index 880b319d68728a40f4479626d5a7c2b8c56ced02..e6668bb43b994863a14fdd347635753422ed9388 100644 --- a/ipaserver/plugins/dogtag.py +++ b/ipaserver/plugins/dogtag.py @@ -1284,6 +1284,8 @@ class ra(rabase.rabase): """ Request Authority backend plugin. """ + DEFAULT_PROFILE = dogtag.DEFAULT_PROFILE + def __init__(self): if api.env.in_tree: self.sec_dir = api.env.dot_ipa + os.sep + 'alias' @@ -1541,9 +1543,10 @@ class ra(rabase.rabase): return cmd_result - def request_certificate(self, csr, request_type='pkcs10'): + def request_certificate(self, csr, profile_id, request_type='pkcs10'): """ :param csr: The certificate signing request. + :param profile_id: The profile to use for the request. :param request_type: The request type (defaults to ``'pkcs10'``). Submit certificate signing request. @@ -1575,7 +1578,7 @@ class ra(rabase.rabase): http_status, http_reason_phrase, http_headers, http_body = \ self._sslget('/ca/eeca/ca/profileSubmitSSLClient', self.env.ca_ee_port, - profileId='caIPAserviceCert', + profileId=profile_id, cert_request_type=request_type, cert_request=csr, xml='true') diff --git a/ipaserver/plugins/rabase.py b/ipaserver/plugins/rabase.py index e14969970ef5b402d06b766f895200c6eb4fc76f..cf4426235b02866a3f565c51c52c44aabbdc1153 100644 --- a/ipaserver/plugins/rabase.py +++ b/ipaserver/plugins/rabase.py @@ -67,11 +67,12 @@ class rabase(Backend): """ raise errors.NotImplementedError(name='%s.get_certificate' % self.name) - def request_certificate(self, csr, request_type='pkcs10'): + def request_certificate(self, csr, profile_id, request_type='pkcs10'): """ Submit certificate signing request. :param csr: The certificate signing request. + :param profile_id: Profile to use for this request. :param request_type: The request type (defaults to ``'pkcs10'``). """ raise errors.NotImplementedError(name='%s.request_certificate' % self.name) -- 2.1.0 -------------- next part -------------- >From f497296679b911b73c68c0315f55837e84a78f87 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 18 May 2015 22:11:52 -0400 Subject: [PATCH 10/13] Add usercertificate attribute to user plugin Part of: https://fedorahosted.org/freeipa/tickets/4938 --- ACI.txt | 2 +- API.txt | 18 ++++++++++++------ install/share/default-aci.ldif | 1 + install/updates/20-aci.update | 4 ++++ ipalib/plugins/baseuser.py | 10 ++++++++-- ipalib/plugins/user.py | 2 +- 6 files changed, 27 insertions(+), 10 deletions(-) diff --git a/ACI.txt b/ACI.txt index 035a545511e4f56dcb492c97514de59cfc028405..fca5b269522c4ab80858c23b1a61e229eee0048e 100644 --- a/ACI.txt +++ b/ACI.txt @@ -281,7 +281,7 @@ aci: (targetattr = "krbprincipalkey || passwordhistory || sambalmpassword || sam dn: cn=users,cn=accounts,dc=ipa,dc=example aci: (targetattr = "ipasshpubkey")(targetfilter = "(objectclass=posixaccount)")(version 3.0;acl "permission:System: Manage User SSH Public Keys";allow (write) groupdn = "ldap:///cn=System: Manage User SSH Public Keys,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: cn=users,cn=accounts,dc=ipa,dc=example -aci: (targetattr = "businesscategory || carlicense || cn || description || displayname || employeetype || facsimiletelephonenumber || gecos || givenname || homephone || inetuserhttpurl || initials || l || labeleduri || loginshell || manager || mepmanagedentry || mobile || objectclass || ou || pager || postalcode || preferredlanguage || roomnumber || secretary || seealso || sn || st || street || telephonenumber || title || userclass")(targetfilter = "(objectclass=posixaccount)")(version 3.0;acl "permission:System: Modify Users";allow (write) groupdn = "ldap:///cn=System: Modify Users,cn=permissions,cn=pbac,dc=ipa,dc=example";) +aci: (targetattr = "businesscategory || carlicense || cn || description || displayname || employeetype || facsimiletelephonenumber || gecos || givenname || homephone || inetuserhttpurl || initials || l || labeleduri || loginshell || manager || mepmanagedentry || mobile || objectclass || ou || pager || postalcode || preferredlanguage || roomnumber || secretary || seealso || sn || st || street || telephonenumber || title || usercertificate || userclass")(targetfilter = "(objectclass=posixaccount)")(version 3.0;acl "permission:System: Modify Users";allow (write) groupdn = "ldap:///cn=System: Modify Users,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: cn=UPG Definition,cn=Definitions,cn=Managed Entries,cn=etc,dc=ipa,dc=example aci: (targetattr = "*")(target = "ldap:///cn=UPG Definition,cn=Definitions,cn=Managed Entries,cn=etc,dc=ipa,dc=example")(version 3.0;acl "permission:System: Read UPG Definition";allow (compare,read,search) groupdn = "ldap:///cn=System: Read UPG Definition,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: cn=users,cn=accounts,dc=ipa,dc=example diff --git a/API.txt b/API.txt index ec414a97c5913c0f4cc812716c72670dae7432da..a59e99ba31bf901b960c36b05541c3e400d4ec7c 100644 --- a/API.txt +++ b/API.txt @@ -3808,7 +3808,7 @@ output: Entry('result', , Gettext('A dictionary representing an LDA output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: stageuser_add -args: 1,43,3 +args: 1,44,3 arg: Str('uid', attribute=True, cli_name='login', 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') @@ -3850,6 +3850,7 @@ option: Str('street', attribute=True, cli_name='street', multivalue=False, requi option: Str('telephonenumber', attribute=True, cli_name='phone', multivalue=True, required=False) option: Str('title', attribute=True, cli_name='title', multivalue=False, required=False) option: Int('uidnumber', attribute=True, cli_name='uid', minvalue=1, multivalue=False, required=False) +option: Bytes('usercertificate', attribute=True, cli_name='certificate', multivalue=True, required=False) option: Str('userclass', attribute=True, cli_name='class', multivalue=True, required=False) option: Password('userpassword', attribute=True, cli_name='password', exclude='webui', multivalue=False, required=False) option: Str('version?', exclude='webui') @@ -3865,7 +3866,7 @@ output: Output('result', , None) output: Output('summary', (, ), None) output: ListOfPrimaryKeys('value', None, None) command: stageuser_find -args: 1,52,4 +args: 1,53,4 arg: Str('criteria?', noextrawhitespace=False) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('carlicense', attribute=True, autofill=False, cli_name='carlicense', multivalue=True, query=True, required=False) @@ -3916,6 +3917,7 @@ option: Int('timelimit?', autofill=False, minvalue=0) option: Str('title', attribute=True, autofill=False, cli_name='title', multivalue=False, query=True, required=False) option: Str('uid', attribute=True, autofill=False, cli_name='login', 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: Int('uidnumber', attribute=True, autofill=False, cli_name='uid', minvalue=1, multivalue=False, query=True, required=False) +option: Bytes('usercertificate', attribute=True, autofill=False, cli_name='certificate', multivalue=True, query=True, required=False) option: Str('userclass', attribute=True, autofill=False, cli_name='class', multivalue=True, query=True, required=False) option: Password('userpassword', attribute=True, autofill=False, cli_name='password', exclude='webui', multivalue=False, query=True, required=False) option: Str('version?', exclude='webui') @@ -3924,7 +3926,7 @@ output: ListOfEntries('result', (, ), Gettext('A list output: Output('summary', (, ), None) output: Output('truncated', , None) command: stageuser_mod -args: 1,44,3 +args: 1,45,3 arg: Str('uid', attribute=True, cli_name='login', 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: Str('addattr*', cli_name='addattr', exclude='webui') option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') @@ -3967,6 +3969,7 @@ option: Str('street', attribute=True, autofill=False, cli_name='street', multiva option: Str('telephonenumber', attribute=True, autofill=False, cli_name='phone', multivalue=True, required=False) option: Str('title', attribute=True, autofill=False, cli_name='title', multivalue=False, required=False) option: Int('uidnumber', attribute=True, autofill=False, cli_name='uid', minvalue=1, multivalue=False, required=False) +option: Bytes('usercertificate', attribute=True, autofill=False, cli_name='certificate', multivalue=True, required=False) option: Str('userclass', attribute=True, autofill=False, cli_name='class', multivalue=True, required=False) option: Password('userpassword', attribute=True, autofill=False, cli_name='password', exclude='webui', multivalue=False, required=False) option: Str('version?', exclude='webui') @@ -4594,7 +4597,7 @@ output: Entry('result', , Gettext('A dictionary representing an LDA output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: user_add -args: 1,44,3 +args: 1,45,3 arg: Str('uid', attribute=True, cli_name='login', 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') @@ -4637,6 +4640,7 @@ option: Str('street', attribute=True, cli_name='street', multivalue=False, requi option: Str('telephonenumber', attribute=True, cli_name='phone', multivalue=True, required=False) option: Str('title', attribute=True, cli_name='title', multivalue=False, required=False) option: Int('uidnumber', attribute=True, cli_name='uid', minvalue=1, multivalue=False, required=False) +option: Bytes('usercertificate', attribute=True, cli_name='certificate', multivalue=True, required=False) option: Str('userclass', attribute=True, cli_name='class', multivalue=True, required=False) option: Password('userpassword', attribute=True, cli_name='password', exclude='webui', multivalue=False, required=False) option: Str('version?', exclude='webui') @@ -4668,7 +4672,7 @@ output: Output('result', , None) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: user_find -args: 1,55,4 +args: 1,56,4 arg: Str('criteria?', noextrawhitespace=False) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('carlicense', attribute=True, autofill=False, cli_name='carlicense', multivalue=True, query=True, required=False) @@ -4721,6 +4725,7 @@ option: Int('timelimit?', autofill=False, minvalue=0) option: Str('title', attribute=True, autofill=False, cli_name='title', multivalue=False, query=True, required=False) option: Str('uid', attribute=True, autofill=False, cli_name='login', 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: Int('uidnumber', attribute=True, autofill=False, cli_name='uid', minvalue=1, multivalue=False, query=True, required=False) +option: Bytes('usercertificate', attribute=True, autofill=False, cli_name='certificate', multivalue=True, query=True, required=False) option: Str('userclass', attribute=True, autofill=False, cli_name='class', multivalue=True, query=True, required=False) option: Password('userpassword', attribute=True, autofill=False, cli_name='password', exclude='webui', multivalue=False, query=True, required=False) option: Str('version?', exclude='webui') @@ -4730,7 +4735,7 @@ output: ListOfEntries('result', (, ), Gettext('A list output: Output('summary', (, ), None) output: Output('truncated', , None) command: user_mod -args: 1,45,3 +args: 1,46,3 arg: Str('uid', attribute=True, cli_name='login', 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: Str('addattr*', cli_name='addattr', exclude='webui') option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') @@ -4774,6 +4779,7 @@ option: Str('street', attribute=True, autofill=False, cli_name='street', multiva option: Str('telephonenumber', attribute=True, autofill=False, cli_name='phone', multivalue=True, required=False) option: Str('title', attribute=True, autofill=False, cli_name='title', multivalue=False, required=False) option: Int('uidnumber', attribute=True, autofill=False, cli_name='uid', minvalue=1, multivalue=False, required=False) +option: Bytes('usercertificate', attribute=True, autofill=False, cli_name='certificate', multivalue=True, required=False) option: Str('userclass', attribute=True, autofill=False, cli_name='class', multivalue=True, required=False) option: Password('userpassword', attribute=True, autofill=False, cli_name='password', exclude='webui', multivalue=False, required=False) option: Str('version?', exclude='webui') diff --git a/install/share/default-aci.ldif b/install/share/default-aci.ldif index af7eedb0b92375f893a61ad1fb6e2d7b176389f9..7b174e774aae3ea012a431fe4a2535fb4230e402 100644 --- a/install/share/default-aci.ldif +++ b/install/share/default-aci.ldif @@ -10,6 +10,7 @@ changetype: modify add: aci aci: (targetattr = "givenname || sn || cn || displayname || title || initials || loginshell || gecos || homephone || mobile || pager || facsimiletelephonenumber || telephonenumber || street || roomnumber || l || st || postalcode || manager || secretary || description || carlicense || labeleduri || inetuserhttpurl || seealso || employeetype || businesscategory || ou")(version 3.0;acl "selfservice:User Self service";allow (write) userdn = "ldap:///self";) aci: (targetattr = "ipasshpubkey")(version 3.0;acl "selfservice:Users can manage their own SSH public keys";allow (write) userdn = "ldap:///self";) +aci: (targetattr = "usercertificate")(version 3.0;acl "selfservice:Users can manage their own X.509 certificates";allow (write) userdn = "ldap:///self";) dn: cn=etc,$SUFFIX changetype: modify diff --git a/install/updates/20-aci.update b/install/updates/20-aci.update index fde3afeee59e4d4dc0bd6a9c0eb24ab255c4e637..4a8b67c6579da4dab74d02861640264446153f87 100644 --- a/install/updates/20-aci.update +++ b/install/updates/20-aci.update @@ -79,3 +79,7 @@ add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; acl "Group add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; acl "Entities are allowed to rekey themselves"; allow(write) userdn="ldap:///self";) add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; acl "Admins are allowed to rekey any entity"; allow(write) groupdn = "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";) add:aci: (targetfilter="(|(objectclass=ipaHost)(objectclass=ipaService))")(targetattr="ipaProtectedOperation;write_keys")(version 3.0; acl "Entities are allowed to rekey managed entries"; allow(write) userattr="managedby#USERDN";) + +# User certificates +dn: $SUFFIX +add:aci:(targetattr = "usercertificate")(version 3.0;acl "selfservice:Users can manage their own X.509 certificates";allow (write) userdn = "ldap:///self";) diff --git a/ipalib/plugins/baseuser.py b/ipalib/plugins/baseuser.py index a1be29d83550a0412ed37cfde47ac74c6ca478fd..d2bc68f45ad9a3632a237c01961a30592514d96d 100644 --- a/ipalib/plugins/baseuser.py +++ b/ipalib/plugins/baseuser.py @@ -23,10 +23,11 @@ import posixpath import os from ipalib import api, errors -from ipalib import Flag, Int, Password, Str, Bool, StrEnum, DateTime +from ipalib import Flag, Int, Password, Str, Bool, StrEnum, DateTime, Bytes from ipalib.plugable import Registry from ipalib.plugins.baseldap import DN, LDAPObject, \ LDAPCreate, LDAPUpdate, LDAPSearch, LDAPDelete, LDAPRetrieve +from ipalib.plugins.service import validate_certificate from ipalib.plugins import baseldap from ipalib.request import context from ipalib import _, ngettext @@ -188,7 +189,7 @@ class baseuser(LDAPObject): 'telephonenumber', 'title', 'memberof', 'nsaccountlock', 'memberofindirect', 'ipauserauthtype', 'userclass', 'ipatokenradiusconfiglink', 'ipatokenradiususername', - 'krbprincipalexpiration' + 'krbprincipalexpiration', 'usercertificate', ] search_display_attributes = [ 'uid', 'givenname', 'sn', 'homedirectory', 'loginshell', @@ -383,6 +384,11 @@ class baseuser(LDAPObject): + '(\s*,\s*[a-zA-Z]{1,8}(-[a-zA-Z]{1,8})?(;q\=((0(\.[0-9]{0,3})?)|(1(\.0{0,3})?)))?)*)|(\*))$', pattern_errmsg='must match RFC 2068 - 14.4, e.g., "da, en-gb;q=0.8, en;q=0.7"', ), + Bytes('usercertificate*', validate_certificate, + cli_name='certificate', + label=_('Certificate'), + doc=_('Base-64 encoded server certificate'), + ), ) def normalize_and_validate_email(self, email, config=None): diff --git a/ipalib/plugins/user.py b/ipalib/plugins/user.py index 54d47bb01450ec462577e552315e3d680b7648c3..119294b19f54a395a2df65c6cfd47cd8eb844297 100644 --- a/ipalib/plugins/user.py +++ b/ipalib/plugins/user.py @@ -267,7 +267,7 @@ class user(baseuser): 'mepmanagedentry', 'mobile', 'objectclass', 'ou', 'pager', 'postalcode', 'roomnumber', 'secretary', 'seealso', 'sn', 'st', 'street', 'telephonenumber', 'title', 'userclass', - 'preferredlanguage', + 'preferredlanguage', 'usercertificate', }, 'replaces': [ '(targetattr = "givenname || sn || cn || displayname || title || initials || loginshell || gecos || homephone || mobile || pager || facsimiletelephonenumber || telephonenumber || street || roomnumber || l || st || postalcode || manager || secretary || description || carlicense || labeleduri || inetuserhttpurl || seealso || employeetype || businesscategory || ou || mepmanagedentry || objectclass")(target = "ldap:///uid=*,cn=users,cn=accounts,$SUFFIX")(version 3.0;acl "permission:Modify Users";allow (write) groupdn = "ldap:///cn=Modify Users,cn=permissions,cn=pbac,$SUFFIX";)', -- 2.1.0 -------------- next part -------------- >From 7b1bbb9ba3ff58a5577fb3fe8679ecb1e5c0968d Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Thu, 14 May 2015 01:45:16 -0400 Subject: [PATCH 11/13] Update cert-request to support user certs and profiles Part of: https://fedorahosted.org/freeipa/ticket/57 Part of: https://fedorahosted.org/freeipa/ticket/4938 --- ipalib/pkcs10.py | 1 + ipalib/plugins/cert.py | 213 +++++++++++++++++++++++++++++-------------------- 2 files changed, 126 insertions(+), 88 deletions(-) diff --git a/ipalib/pkcs10.py b/ipalib/pkcs10.py index f35e200a2c1b47e2a2c8cffcf9b723f398fe3221..6299dfea43b7a3f4104f0b0ec78c4f105d9daf62 100644 --- a/ipalib/pkcs10.py +++ b/ipalib/pkcs10.py @@ -30,6 +30,7 @@ PEM = 0 DER = 1 SAN_DNSNAME = 'DNS name' +SAN_RFC822NAME = 'RFC822 Name' SAN_OTHERNAME_UPN = 'Other Name (OID.1.3.6.1.4.1.311.20.2.3)' SAN_OTHERNAME_KRB5PRINCIPALNAME = 'Other Name (OID.1.3.6.1.5.2.2)' diff --git a/ipalib/plugins/cert.py b/ipalib/plugins/cert.py index e4cb6dc0aa8b89368806b08674aae277b3653e8f..34621b552d3e527c2dd0fee46e240542179227f9 100644 --- a/ipalib/plugins/cert.py +++ b/ipalib/plugins/cert.py @@ -31,7 +31,8 @@ from ipalib import ngettext from ipalib.plugable import Registry from ipalib.plugins.virtual import * from ipalib.plugins.baseldap import pkey_to_value -from ipalib.plugins.service import split_principal +from ipalib.plugins.service import split_any_principal +from ipalib.plugins.certprofile import validate_profile_id import base64 import traceback from ipalib.text import _ @@ -122,6 +123,8 @@ http://www.ietf.org/rfc/rfc5280.txt """) +USER, HOST, SERVICE = range(3) + register = Registry() def validate_pkidate(ugettext, value): @@ -232,7 +235,7 @@ class cert_request(VirtualCommand): takes_options = ( Str('principal', label=_('Principal'), - doc=_('Service principal for this certificate (e.g. HTTP/test.example.com)'), + doc=_('Principal for this certificate (e.g. HTTP/test.example.com)'), ), Str('request_type', default=u'pkcs10', @@ -243,6 +246,10 @@ class cert_request(VirtualCommand): default=False, autofill=True ), + Str('profile_id', validate_profile_id, + label=_("Profile ID"), + doc=_("Certificate Profile to use"), + ) ) has_output_params = ( @@ -294,10 +301,9 @@ class cert_request(VirtualCommand): ca_enabled_check() ldap = self.api.Backend.ldap2 - principal = kw.get('principal') add = kw.get('add') request_type = kw.get('request_type') - service = None + profile_id = kw.get('profile_id', self.Backend.ra.DEFAULT_PROFILE) """ Access control is partially handled by the ACI titled @@ -310,9 +316,21 @@ class cert_request(VirtualCommand): taskgroup (directly or indirectly via role membership). """ - bind_principal = getattr(context, 'principal') - # Can this user request certs? - if not bind_principal.startswith('host/'): + principal_string = kw.get('principal') + principal = split_any_principal(principal_string) + servicename, principal_name, realm = principal + if servicename is None: + principal_type = USER + elif servicename == 'host': + principal_type = HOST + else: + principal_type = SERVICE + + bind_principal = split_any_principal(getattr(context, 'principal')) + bind_service, bind_name, bind_realm = bind_principal + + if bind_principal != principal: + # Can the bound principal request certs for another principal? self.check_access() try: @@ -323,57 +341,71 @@ class cert_request(VirtualCommand): raise errors.CertificateOperationError( error=_("Failure decoding Certificate Signing Request: %s") % e) - if not bind_principal.startswith('host/'): + # host principals may bypass allowed ext check + if bind_service != 'host': for ext in extensions: operation = self._allowed_extensions.get(ext) if operation: self.check_access(operation) - # Ensure that the hostname in the CSR matches the principal - subject_host = subject.common_name #pylint: disable=E1101 - if not subject_host: + dn = None + principal_obj = None + # See if the service exists and punt if it doesn't and we aren't + # going to add it + try: + if principal_type == SERVICE: + principal_obj = api.Command['service_show'](principal_string, all=True) + elif principal_type == HOST: + principal_obj = api.Command['host_show'](principal_name, all=True) + elif principal_type == USER: + principal_obj = api.Command['user_show'](principal_name, all=True) + except errors.NotFound as e: + if principal_type == SERVICE and add: + principal_obj = api.Command['service_add'](principal_string, force=True) + else: + raise errors.NotFound( + reason=_("The principal for this request doesn't exist.")) + principal_obj = principal_obj['result'] + dn = principal_obj['dn'] + + # Ensure that the DN in the CSR matches the principal + cn = subject.common_name #pylint: disable=E1101 + if not cn: raise errors.ValidationError(name='csr', - error=_("No hostname was found in subject of request.")) + error=_("No Common Name was found in subject of request.")) - (servicename, hostname, realm) = split_principal(principal) - if subject_host.lower() != hostname.lower(): - raise errors.ACIError( - info=_("hostname in subject of request '%(subject_host)s' " - "does not match principal hostname '%(hostname)s'") % dict( - subject_host=subject_host, hostname=hostname)) + if principal_type in (SERVICE, HOST): + if cn.lower() != principal_name.lower(): + raise errors.ACIError( + info=_("hostname in subject of request '%(cn)s' " + "does not match principal hostname '%(hostname)s'") + % dict(cn=cn, hostname=principal_name)) + elif principal_type == USER: + # check user name + if cn != principal_name: + raise errors.ValidationError( + name='csr', + error=_( + "DN commonName does not match " + "any of user's email addresses") + ) + + # check email address + mail = subject.email_address #pylint: disable=E1101 + if mail is not None and mail not in principal_obj.get('mail', []): + raise errors.ValidationError( + name='csr', + error=_( + "DN emailAddress does not match " + "any of user's email addresses") + ) for ext in extensions: if ext not in self._allowed_extensions: raise errors.ValidationError( name='csr', error=_("extension %s is forbidden") % ext) - for name_type, name in subjectaltname: - if name_type not in (pkcs10.SAN_DNSNAME, - pkcs10.SAN_OTHERNAME_KRB5PRINCIPALNAME, - pkcs10.SAN_OTHERNAME_UPN): - raise errors.ValidationError( - name='csr', - error=_("subject alt name type %s is forbidden") % - name_type) - - dn = None - service = None - # See if the service exists and punt if it doesn't and we aren't - # going to add it - try: - if servicename != 'host': - service = api.Command['service_show'](principal, all=True) - else: - service = api.Command['host_show'](hostname, all=True) - except errors.NotFound, e: - if not add: - raise errors.NotFound(reason=_("The service principal for " - "this request doesn't exist.")) - service = api.Command['service_add'](principal, force=True) - service = service['result'] - dn = service['dn'] - - # We got this far so the service entry exists, can we write it? + # We got this far so the principal entry exists, can we write it? if not ldap.can_write(dn, "usercertificate"): raise errors.ACIError(info=_("Insufficient 'write' privilege " "to the 'userCertificate' attribute of entry '%s'.") % dn) @@ -382,13 +414,20 @@ class cert_request(VirtualCommand): for name_type, name in subjectaltname: if name_type == pkcs10.SAN_DNSNAME: name = unicode(name) + alt_principal_obj = None try: - if servicename == 'host': - altservice = api.Command['host_show'](name, all=True) - else: + if principal_type == HOST: + alt_principal_obj = api.Command['host_show'](name, all=True) + elif principal_type == SERVICE: altprincipal = '%s/%s@%s' % (servicename, name, realm) - altservice = api.Command['service_show']( + alt_principal_obj = api.Command['service_show']( altprincipal, all=True) + elif principal_type == USER: + raise errors.ValidationError( + name='csr', + error=_("subject alt name type %s is forbidden " + "for user principals") % name_type + ) except errors.NotFound: # We don't want to issue any certificates referencing # machines we don't know about. Nothing is stored in this @@ -396,47 +435,41 @@ class cert_request(VirtualCommand): raise errors.NotFound(reason=_('The service principal for ' 'subject alt name %s in certificate request does not ' 'exist') % name) - altdn = altservice['result']['dn'] - if not ldap.can_write(altdn, "usercertificate"): - raise errors.ACIError(info=_( - "Insufficient privilege to create a certificate with " - "subject alt name '%s'.") % name) + if alt_principal_obj is not None: + altdn = alt_principal_obj['result']['dn'] + if not ldap.can_write(altdn, "usercertificate"): + raise errors.ACIError(info=_( + "Insufficient privilege to create a certificate " + "with subject alt name '%s'.") % name) elif name_type in (pkcs10.SAN_OTHERNAME_KRB5PRINCIPALNAME, pkcs10.SAN_OTHERNAME_UPN): - if name != principal: + if name != principal_string: raise errors.ACIError( info=_("Principal '%s' in subject alt name does not " - "match requested service principal") % name) + "match requested principal") % name) + elif name_type == pkcs10.SAN_RFC822NAME: + if principal_type == USER: + if name not in principal_obj.get('mail', []): + raise errors.ValidationError( + name='csr', + error=_( + "RFC822Name does not match " + "any of user's email addresses") + ) + else: + raise errors.ValidationError( + name='csr', + error=_("subject alt name type %s is forbidden " + "for non-user principals") % name_type + ) else: raise errors.ACIError( info=_("Subject alt name type %s is forbidden") % name_type) - if 'usercertificate' in service: - serial = x509.get_serial_number(service['usercertificate'][0], datatype=x509.DER) - # revoke the certificate and remove it from the service - # entry before proceeding. First we retrieve the certificate to - # see if it is already revoked, if not then we revoke it. - try: - result = api.Command['cert_show'](unicode(serial))['result'] - if 'revocation_reason' not in result: - try: - api.Command['cert_revoke'](unicode(serial), revocation_reason=4) - except errors.NotImplementedError: - # some CA's might not implement revoke - pass - except errors.NotImplementedError: - # some CA's might not implement get - pass - if not principal.startswith('host/'): - api.Command['service_mod'](principal, usercertificate=None) - else: - hostname = get_host_from_principal(principal) - api.Command['host_mod'](hostname, usercertificate=None) - # Request the certificate result = self.Backend.ra.request_certificate( - csr, 'caIPAserviceCert', request_type=request_type) + csr, profile_id, request_type=request_type) cert = x509.load_certificate(result['certificate']) result['issuer'] = unicode(cert.issuer) result['valid_not_before'] = unicode(cert.valid_not_before_str) @@ -444,15 +477,19 @@ class cert_request(VirtualCommand): result['md5_fingerprint'] = unicode(nss.data_to_hex(nss.md5_digest(cert.der_data), 64)[0]) result['sha1_fingerprint'] = unicode(nss.data_to_hex(nss.sha1_digest(cert.der_data), 64)[0]) - # Success? Then add it to the service entry. - if 'certificate' in result: - if not principal.startswith('host/'): - skw = {"usercertificate": str(result.get('certificate'))} - api.Command['service_mod'](principal, **skw) - else: - hostname = get_host_from_principal(principal) - skw = {"usercertificate": str(result.get('certificate'))} - api.Command['host_mod'](hostname, **skw) + # Success? Then add it to the principal's entry + # (unless the profile tells us not to) + profile = api.Command['certprofile_show'](profile_id) + store = profile['result']['ipacertprofilestoreissued'][0] == 'TRUE' + if store and 'certificate' in result: + cert = str(result.get('certificate')) + kwargs = dict(addattr=u'usercertificate={}'.format(cert)) + if principal_type == SERVICE: + api.Command['service_mod'](principal_string, **kwargs) + elif principal_type == HOST: + api.Command['host_mod'](principal_name, **kwargs) + elif principal_type == USER: + api.Command['user_mod'](principal_name, **kwargs) return dict( result=result -- 2.1.0 -------------- next part -------------- >From 2b51d1b4f96de77be2824977355c3e9efc439e4d Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 25 May 2015 08:39:07 -0400 Subject: [PATCH 12/13] Add CA ACL plugin Implement the caacl commands, which are used to indicate which principals may be issued certificates from which (sub-)CAs, using which profiles. At this commit, and until sub-CAs are implemented, all rules refer to the top-level CA (represented as ".") and no ca-ref argument is exposed. Also add a default CA ACL that permitS certificate issuance for all hosts and services using the profile 'caIPAserviceCert' on the top-level CA. Part of: https://fedorahosted.org/freeipa/ticket/57 Part of: https://fedorahosted.org/freeipa/ticket/4559 --- ACI.txt | 10 + API.txt | 171 +++++++++++++++ install/share/60certificate-profiles.ldif | 8 + install/share/Makefile.am | 1 + install/share/bootstrap-template.ldif | 6 + install/share/default-caacl.ldif | 12 ++ install/updates/41-caacl.update | 4 + install/updates/Makefile.am | 1 + ipalib/constants.py | 1 + ipalib/plugins/caacl.py | 343 ++++++++++++++++++++++++++++++ ipaserver/install/dsinstance.py | 4 + 11 files changed, 561 insertions(+) create mode 100644 install/share/default-caacl.ldif create mode 100644 install/updates/41-caacl.update create mode 100644 ipalib/plugins/caacl.py diff --git a/ACI.txt b/ACI.txt index fca5b269522c4ab80858c23b1a61e229eee0048e..c92e341834c1134cab007e61d2953b8e52f375b5 100644 --- a/ACI.txt +++ b/ACI.txt @@ -22,6 +22,16 @@ dn: cn=automount,dc=ipa,dc=example aci: (targetattr = "automountmapname || description")(targetfilter = "(objectclass=automountmap)")(version 3.0;acl "permission:System: Modify Automount Maps";allow (write) groupdn = "ldap:///cn=System: Modify Automount Maps,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: cn=automount,dc=ipa,dc=example aci: (targetfilter = "(objectclass=automountmap)")(version 3.0;acl "permission:System: Remove Automount Maps";allow (delete) groupdn = "ldap:///cn=System: Remove Automount Maps,cn=permissions,cn=pbac,dc=ipa,dc=example";) +dn: cn=caacls,cn=ca,dc=ipa,dc=example +aci: (targetfilter = "(objectclass=ipacaacl)")(version 3.0;acl "permission:System: Add CA ACL";allow (add) groupdn = "ldap:///cn=System: Add CA ACL,cn=permissions,cn=pbac,dc=ipa,dc=example";) +dn: cn=caacls,cn=ca,dc=ipa,dc=example +aci: (targetfilter = "(objectclass=ipacaacl)")(version 3.0;acl "permission:System: Delete CA ACL";allow (delete) groupdn = "ldap:///cn=System: Delete CA ACL,cn=permissions,cn=pbac,dc=ipa,dc=example";) +dn: cn=caacls,cn=ca,dc=ipa,dc=example +aci: (targetattr = "ipacaaclallhosts || ipacaaclallservices || ipacaaclallusers || memberhost || memberservice || memberuser")(targetfilter = "(objectclass=ipacaacl)")(version 3.0;acl "permission:System: Manage CA ACL Membership";allow (write) groupdn = "ldap:///cn=System: Manage CA ACL Membership,cn=permissions,cn=pbac,dc=ipa,dc=example";) +dn: cn=caacls,cn=ca,dc=ipa,dc=example +aci: (targetattr = "cn || description || ipacaaclallcas || ipacaaclallprofiles || ipacaaclcaref || ipacaaclprofileid || ipaenabledflag")(targetfilter = "(objectclass=ipacaacl)")(version 3.0;acl "permission:System: Modify CA ACL";allow (write) groupdn = "ldap:///cn=System: Modify CA ACL,cn=permissions,cn=pbac,dc=ipa,dc=example";) +dn: cn=caacls,cn=ca,dc=ipa,dc=example +aci: (targetattr = "cn || createtimestamp || description || entryusn || ipacaaclallcas || ipacaaclallhosts || ipacaaclallprofiles || ipacaaclallservices || ipacaaclallusers || ipacaaclcaref || ipacaaclprofileid || ipaenabledflag || ipauniqueid || member || memberhost || memberservice || memberuser || modifytimestamp || objectclass")(targetfilter = "(objectclass=ipacaacl)")(version 3.0;acl "permission:System: Read CA ACLs";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=certprofiles,cn=ca,dc=ipa,dc=example aci: (targetfilter = "(objectclass=ipacertprofile)")(version 3.0;acl "permission:System: Delete Certificate Profile";allow (delete) groupdn = "ldap:///cn=System: Delete Certificate Profile,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: cn=certprofiles,cn=ca,dc=ipa,dc=example diff --git a/API.txt b/API.txt index a59e99ba31bf901b960c36b05541c3e400d4ec7c..1b3727059c362d32ac6cc56d7277ebb8763f6943 100644 --- a/API.txt +++ b/API.txt @@ -456,6 +456,177 @@ option: Str('version?', exclude='webui') output: Output('result', , None) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) +command: caacl_add +args: 1,15,3 +arg: Str('cn', attribute=True, cli_name='name', multivalue=False, 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: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) +option: Bool('ipacaaclallcas', attribute=True, cli_name='allcas', multivalue=False, required=False) +option: Bool('ipacaaclallhosts', attribute=True, cli_name='allhosts', multivalue=False, required=False) +option: Bool('ipacaaclallprofiles', attribute=True, cli_name='allprofiles', multivalue=False, required=False) +option: Bool('ipacaaclallservices', attribute=True, cli_name='allservices', multivalue=False, required=False) +option: Bool('ipacaaclallusers', attribute=True, cli_name='allusers', multivalue=False, required=False) +option: Str('ipacaaclcaref', attribute=True, cli_name='ca_ref', multivalue=True, required=False) +option: Str('ipacaaclprofileid', attribute=True, cli_name='profile_id', multivalue=True, required=False) +option: Bool('ipaenabledflag', attribute=True, cli_name='ipaenabledflag', multivalue=False, required=False) +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: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: caacl_add_host +args: 1,6,3 +arg: Str('cn', attribute=True, cli_name='name', multivalue=False, primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('host*', alwaysask=True, cli_name='hosts', csv=True) +option: Str('hostgroup*', alwaysask=True, cli_name='hostgroups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +command: caacl_add_service +args: 1,5,3 +arg: Str('cn', attribute=True, cli_name='name', multivalue=False, 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: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('service*', alwaysask=True, cli_name='services', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +command: caacl_add_user +args: 1,6,3 +arg: Str('cn', attribute=True, cli_name='name', multivalue=False, primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +command: caacl_del +args: 1,2,3 +arg: Str('cn', attribute=True, cli_name='name', multivalue=True, 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', , None) +output: Output('summary', (, ), None) +output: ListOfPrimaryKeys('value', None, None) +command: caacl_disable +args: 1,1,3 +arg: Str('cn', attribute=True, cli_name='name', multivalue=False, primary_key=True, query=True, required=True) +option: Str('version?', exclude='webui') +output: Output('result', , None) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: caacl_enable +args: 1,1,3 +arg: Str('cn', attribute=True, cli_name='name', multivalue=False, primary_key=True, query=True, required=True) +option: Str('version?', exclude='webui') +output: Output('result', , None) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: caacl_find +args: 1,17,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='name', multivalue=False, primary_key=True, query=True, required=False) +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, query=True, required=False) +option: Bool('ipacaaclallcas', attribute=True, autofill=False, cli_name='allcas', multivalue=False, query=True, required=False) +option: Bool('ipacaaclallhosts', attribute=True, autofill=False, cli_name='allhosts', multivalue=False, query=True, required=False) +option: Bool('ipacaaclallprofiles', attribute=True, autofill=False, cli_name='allprofiles', multivalue=False, query=True, required=False) +option: Bool('ipacaaclallservices', attribute=True, autofill=False, cli_name='allservices', multivalue=False, query=True, required=False) +option: Bool('ipacaaclallusers', attribute=True, autofill=False, cli_name='allusers', multivalue=False, query=True, required=False) +option: Str('ipacaaclcaref', attribute=True, autofill=False, cli_name='ca_ref', multivalue=True, query=True, required=False) +option: Str('ipacaaclprofileid', attribute=True, autofill=False, cli_name='profile_id', multivalue=True, query=True, required=False) +option: Bool('ipaenabledflag', attribute=True, autofill=False, cli_name='ipaenabledflag', multivalue=False, query=True, required=False) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Flag('pkey_only?', autofill=True, default=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Int('sizelimit?', autofill=False, minvalue=0) +option: Int('timelimit?', autofill=False, minvalue=0) +option: Str('version?', exclude='webui') +output: Output('count', , None) +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('truncated', , None) +command: caacl_mod +args: 1,17,3 +arg: Str('cn', attribute=True, cli_name='name', multivalue=False, primary_key=True, query=True, required=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('delattr*', cli_name='delattr', exclude='webui') +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) +option: Bool('ipacaaclallcas', attribute=True, autofill=False, cli_name='allcas', multivalue=False, required=False) +option: Bool('ipacaaclallhosts', attribute=True, autofill=False, cli_name='allhosts', multivalue=False, required=False) +option: Bool('ipacaaclallprofiles', attribute=True, autofill=False, cli_name='allprofiles', multivalue=False, required=False) +option: Bool('ipacaaclallservices', attribute=True, autofill=False, cli_name='allservices', multivalue=False, required=False) +option: Bool('ipacaaclallusers', attribute=True, autofill=False, cli_name='allusers', multivalue=False, required=False) +option: Str('ipacaaclcaref', attribute=True, autofill=False, cli_name='ca_ref', multivalue=True, required=False) +option: Str('ipacaaclprofileid', attribute=True, autofill=False, cli_name='profile_id', multivalue=True, required=False) +option: Bool('ipaenabledflag', attribute=True, autofill=False, cli_name='ipaenabledflag', multivalue=False, required=False) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: caacl_remove_host +args: 1,6,3 +arg: Str('cn', attribute=True, cli_name='name', multivalue=False, primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('host*', alwaysask=True, cli_name='hosts', csv=True) +option: Str('hostgroup*', alwaysask=True, cli_name='hostgroups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +command: caacl_remove_service +args: 1,5,3 +arg: Str('cn', attribute=True, cli_name='name', multivalue=False, 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: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('service*', alwaysask=True, cli_name='services', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +command: caacl_remove_user +args: 1,6,3 +arg: Str('cn', attribute=True, cli_name='name', multivalue=False, primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +command: caacl_show +args: 1,5,3 +arg: Str('cn', attribute=True, cli_name='name', multivalue=False, 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: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) command: cert_find args: 0,17,4 option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') diff --git a/install/share/60certificate-profiles.ldif b/install/share/60certificate-profiles.ldif index f1281949e53386e5bfe8b35e0c15858c693c5467..d8f008c5baed4e0021944bcbaa7256aa250e5c23 100644 --- a/install/share/60certificate-profiles.ldif +++ b/install/share/60certificate-profiles.ldif @@ -1,3 +1,11 @@ dn: cn=schema attributeTypes: (2.16.840.1.113730.3.8.21.1.1 NAME 'ipaCertProfileStoreIssued' DESC 'Store certificates issued using this profile' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA v4.2' ) +attributeTypes: (2.16.840.1.113730.3.8.21.1.2 NAME 'ipaCaAclCaRef' DESC 'Certificate Authority Reference' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 X-ORIGIN 'IPA v4.2' ) +attributeTypes: (2.16.840.1.113730.3.8.21.1.3 NAME 'ipaCaAclProfileId' DESC 'Certificate Profile ID' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 X-ORIGIN 'IPA v4.2' ) +attributeTypes: (2.16.840.1.113730.3.8.21.1.4 NAME 'ipaCaAclAllCAs' DESC 'Allow use of all CAs' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA v4.2' ) +attributeTypes: (2.16.840.1.113730.3.8.21.1.5 NAME 'ipaCaAclAllProfiles' DESC 'Allow ues of all profiles' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA v4.2' ) +attributeTypes: (2.16.840.1.113730.3.8.21.1.6 NAME 'ipaCaAclAllUsers' DESC 'Allow all users' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA v4.2' ) +attributeTypes: (2.16.840.1.113730.3.8.21.1.7 NAME 'ipaCaAclAllHosts' DESC 'Allow all hosts' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA v4.2' ) +attributeTypes: (2.16.840.1.113730.3.8.21.1.8 NAME 'ipaCaAclAllServices' DESC 'Allow all services' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA v4.2' ) objectClasses: (2.16.840.1.113730.3.8.21.2.1 NAME 'ipaCertProfile' SUP top STRUCTURAL MUST ( cn $ description $ ipaCertProfileStoreIssued ) X-ORIGIN 'IPA v4.2' ) +objectClasses: (2.16.840.1.113730.3.8.21.2.2 NAME 'ipaCaAcl' SUP ipaAssociation STRUCTURAL MUST cn MAY ( ipaCaAclCaRef $ ipaCaAclProfileId $ ipaCaAclAllCAs $ ipaCaAclAllProfiles $ ipaCaAclAllUsers $ ipaCaAclAllHosts $ ipaCaAclAllServices $ memberService ) X-ORIGIN 'IPA v4.2' ) diff --git a/install/share/Makefile.am b/install/share/Makefile.am index 31f391be25c58b76cc71971852074d80c5514745..e97a89ca93f7f188e06dc982bd69e251f8082df3 100644 --- a/install/share/Makefile.am +++ b/install/share/Makefile.am @@ -29,6 +29,7 @@ app_DATA = \ bootstrap-template.ldif \ caJarSigningCert.cfg.template \ default-aci.ldif \ + default-caacl.ldif \ default-hbac.ldif \ default-smb-group.ldif \ default-trust-view.ldif \ diff --git a/install/share/bootstrap-template.ldif b/install/share/bootstrap-template.ldif index c5d4bad8b80640881f4631e4873a12c82b0ea48a..2387f220fd4fe6e3ccd59f4b592f2473d7acfa44 100644 --- a/install/share/bootstrap-template.ldif +++ b/install/share/bootstrap-template.ldif @@ -441,3 +441,9 @@ changetype: add objectClass: nsContainer objectClass: top cn: certprofiles + +dn: cn=caacls,cn=ca,$SUFFIX +changetype: add +objectClass: nsContainer +objectClass: top +cn: caacls diff --git a/install/share/default-caacl.ldif b/install/share/default-caacl.ldif new file mode 100644 index 0000000000000000000000000000000000000000..b902c2f84a6898ae51e8123956496d64b6356d3e --- /dev/null +++ b/install/share/default-caacl.ldif @@ -0,0 +1,12 @@ +# default CA ACL that grants use of caIPAserviceCert on top-level CA to all hosts and services +dn: ipauniqueid=autogenerate,cn=caacls,cn=ca,$SUFFIX +changetype: add +objectclass: ipaassociation +objectclass: ipacaacl +ipauniqueid: autogenerate +cn: hosts_services_caIPAserviceCert +ipaenabledflag: TRUE +ipacaaclcaref: . +ipacaaclprofileid: caIPAserviceCert +ipacaaclallhosts: TRUE +ipacaaclallservices: TRUE diff --git a/install/updates/41-caacl.update b/install/updates/41-caacl.update new file mode 100644 index 0000000000000000000000000000000000000000..a18b6ec946855c194077d9ac01a8adcfddf8542e --- /dev/null +++ b/install/updates/41-caacl.update @@ -0,0 +1,4 @@ +dn: cn=caacls,cn=ca,$SUFFIX +default: objectClass: nsContainer +default: objectClass: top +default: cn: caacls diff --git a/install/updates/Makefile.am b/install/updates/Makefile.am index fc6bd624eac619cdddeba29b85440571d85fd69f..eddf4d850ed4b47d5526dc152149fa21b14779d4 100644 --- a/install/updates/Makefile.am +++ b/install/updates/Makefile.am @@ -35,6 +35,7 @@ app_DATA = \ 40-certprofile.update \ 40-otp.update \ 40-vault.update \ + 41-caacl.update \ 45-roles.update \ 50-7_bit_check.update \ 50-dogtag10-migration.update \ diff --git a/ipalib/constants.py b/ipalib/constants.py index 96396a236b8694b3dd988dfe28c1b0c3cc9e3180..9812f843e1e4ced9244f3efd6a9bb6f4c2769655 100644 --- a/ipalib/constants.py +++ b/ipalib/constants.py @@ -119,6 +119,7 @@ DEFAULT_CONFIG = ( ('container_views', DN(('cn', 'views'), ('cn', 'accounts'))), ('container_masters', DN(('cn', 'masters'), ('cn', 'ipa'), ('cn', 'etc'))), ('container_certprofile', DN(('cn', 'certprofiles'), ('cn', 'ca'))), + ('container_caacl', DN(('cn', 'caacls'), ('cn', 'ca'))), # Ports, hosts, and URIs: ('xmlrpc_uri', 'http://localhost:8888/ipa/xml'), diff --git a/ipalib/plugins/caacl.py b/ipalib/plugins/caacl.py new file mode 100644 index 0000000000000000000000000000000000000000..84dc6d3c4db5f46d76bed560023b7cb63c5513b1 --- /dev/null +++ b/ipalib/plugins/caacl.py @@ -0,0 +1,343 @@ +# +# Copyright (C) 2015 FreeIPA Contributors see COPYING for license +# + +from ipalib import api, errors, output +from ipalib import Bool, Str +from ipalib.plugable import Registry +from ipalib.plugins.baseldap import ( + LDAPObject, LDAPSearch, LDAPCreate, LDAPDelete, LDAPQuery, + LDAPUpdate, LDAPRetrieve, LDAPAddMember, LDAPRemoveMember, + pkey_to_value) +from ipalib.plugins.certprofile import validate_profile_id +from ipalib import _, ngettext +from ipapython.dn import DN + + +__doc__ = _(""" +Manage CA ACL rules. + +This plugin is used to define rules governing which principals are +permitted to have certificates issued using a given certificate +profile. + +PROFILE ID SYNTAX: + +A Profile ID is a string without spaces or punctuation starting with a letter +and followed by a sequence of letters, digits or underscore ("_"). + +EXAMPLES: + + Create a CA ACL "test" that grants all users access to the + "UserCert" profile: + ipa caacl-add test --profile-id=UserCert --allusers=1 + + Display the properties of a named CA ACL: + ipa caacl-show test + + Create a CA ACL to let user "alice" use the "DNP3" profile: + ipa caacl-add john_dnp3 --profile-id=DNP3 + ipa caacl-add-user --user=alice + + Disable a CA ACL: + ipa caacl-disable test + + Remove a CA ACL: + ipa caacl-del test +""") + +register = Registry() + + + at register() +class caacl(LDAPObject): + """ + CA ACL object. + """ + container_dn = api.env.container_caacl + object_name = _('CA ACL') + object_name_plural = _('CA ACLs') + object_class = ['ipaassociation', 'ipacaacl'] + permission_filter_objectclasses = ['ipacaacl'] + default_attributes = [ + 'cn', 'description', 'ipaenabledflag', + 'ipacaaclprofileid', 'ipacaaclcaref', + 'ipacaaclallcas', 'ipacaaclallprofiles', + 'ipacaaclallusers', 'ipacaaclallhosts', 'ipacaaclallservices', + 'memberuser', 'memberhost', 'memberservice', 'memberhostgroup', + ] + uuid_attribute = 'ipauniqueid' + rdn_attribute = 'ipauniqueid' + attribute_members = { + 'memberuser': ['user', 'group'], + 'memberhost': ['host', 'hostgroup'], + 'memberservice': ['service'], + } + managed_permissions = { + 'System: Read CA ACLs': { + 'replaces_global_anonymous_aci': True, + 'ipapermbindruletype': 'all', + 'ipapermright': {'read', 'search', 'compare'}, + 'ipapermdefaultattr': { + 'cn', 'description', 'ipaenabledflag', + 'ipacaaclprofileid', 'ipacaaclcaref', + 'ipacaaclallcas', 'ipacaaclallprofiles', + 'ipacaaclallusers', 'ipacaaclallhosts', 'ipacaaclallservices', + 'ipauniqueid', 'memberhost', 'memberservice', 'memberuser', + 'objectclass', 'member', + }, + }, + 'System: Add CA ACL': { + 'ipapermright': {'add'}, + 'replaces': [ + '(target = "ldap:///ipauniqueid=*,cn=caacls,cn=ca,$SUFFIX")(version 3.0;acl "permission:Add CA ACL";allow (add) groupdn = "ldap:///cn=Add CA ACL,cn=permissions,cn=pbac,$SUFFIX";)', + ], + 'default_privileges': {'CA Administrator'}, + }, + 'System: Delete CA ACL': { + 'ipapermright': {'delete'}, + 'replaces': [ + '(target = "ldap:///ipauniqueid=*,cn=caacls,cn=ca,$SUFFIX")(version 3.0;acl "permission:Delete CA ACL";allow (delete) groupdn = "ldap:///cn=Delete CA ACL,cn=permissions,cn=pbac,$SUFFIX";)', + ], + 'default_privileges': {'CA Administrator'}, + }, + 'System: Manage CA ACL Membership': { + 'ipapermright': {'write'}, + 'ipapermdefaultattr': { + 'memberhost', 'memberservice', 'memberuser', + 'ipacaaclallusers', 'ipacaaclallhosts', 'ipacaaclallservices', + }, + 'replaces': [ + '(targetattr = "memberuser || memberservice || memberhost || ipacaaclallusers || ipacaaclallhosts || ipacaaclallservices")(target = "ldap:///ipauniqueid=*,cn=caacls,cn=ca,$SUFFIX")(version 3.0;acl "permission:Manage CA ACL membership";allow (write) groupdn = "ldap:///cn=Manage CA ACL membership,cn=permissions,cn=pbac,$SUFFIX";)', + ], + 'default_privileges': {'CA Administrator'}, + }, + 'System: Modify CA ACL': { + 'ipapermright': {'write'}, + 'ipapermdefaultattr': { + 'cn', 'description', 'ipaenabledflag', + 'ipacaaclallcas', 'ipacaaclallprofiles', + 'ipacaaclprofileid', 'ipacaaclcaref', + }, + 'replaces': [ + '(targetattr = "cn || description || ipaenabledflag || ipacaaclprofileid || ipacaaclcaref || ipacaaclallcas || ipacaaclallprofiles")(target = "ldap:///ipauniqueid=*,cn=caacls,cn=ca,$SUFFIX")(version 3.0;acl "permission:Modify CA ACL";allow (write) groupdn = "ldap:///cn=Modify CA ACL,cn=permissions,cn=pbac,$SUFFIX";)', + ], + 'default_privileges': {'CA Administrator'}, + }, + } + + label = _('CA ACLs') + label_singular = _('CA ACL') + + takes_params = ( + Str('cn', + cli_name='name', + label=_('ACL name'), + primary_key=True, + ), + Str('description?', + cli_name='desc', + label=_('Description'), + ), + Bool('ipaenabledflag?', + label=_('Enabled'), + flags=['no_option'], + ), + Str('ipacaaclprofileid*', validate_profile_id, + cli_name='profile_id', + label=_('Profile ID'), + ), + Str('ipacaaclcaref*', # validate sub-CA handle syntax + cli_name='ca_ref', + label=_('CA Reference'), + flags=['no_option', 'no_output'], # until sub-CAs are implemented + ), + Bool('ipacaaclallcas?', + cli_name='allcas', + label=_('Allow use of all CAs'), + flags=['no_option', 'no_output'], # until sub-CAs are implemented + ), + Bool('ipacaaclallprofiles?', + cli_name='allprofiles', + label=_('Allow use of all profiles'), + ), + Bool('ipacaaclallusers?', + cli_name='allusers', + label=_('Allow all users'), + ), + Bool('ipacaaclallhosts?', + cli_name='allhosts', + label=_('Allow all hosts'), + ), + Bool('ipacaaclallservices?', + cli_name='allservices', + label=_('Allow all services'), + ), + Str('memberuser_user?', + label=_('Users'), + flags=['no_create', 'no_update', 'no_search'], + ), + Str('memberuser_group?', + label=_('User Groups'), + flags=['no_create', 'no_update', 'no_search'], + ), + Str('memberhost_host?', + label=_('Hosts'), + flags=['no_create', 'no_update', 'no_search'], + ), + Str('memberhost_hostgroup?', + label=_('Host Groups'), + flags=['no_create', 'no_update', 'no_search'], + ), + Str('memberservice_service?', + label=_('Services'), + flags=['no_create', 'no_update', 'no_search'], + ), + ) + + + at register() +class caacl_add(LDAPCreate): + __doc__ = _('Create a new CA ACL.') + + msg_summary = _('Added CA ACL "%(value)s"') + + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): + # CA ACLs are enabled by default + entry_attrs['ipaenabledflag'] = ['TRUE'] + entry_attrs['ipacaaclcaref'] = ['.'] + return dn + + + at register() +class caacl_del(LDAPDelete): + __doc__ = _('Delete a CA ACL.') + + msg_summary = _('Deleted CA ACL "%(value)s"') + + + at register() +class caacl_mod(LDAPUpdate): + __doc__ = _('Modify a CA ACL.') + + msg_summary = _('Modified CA ACL "%(value)s"') + + + at register() +class caacl_find(LDAPSearch): + __doc__ = _('Search for CA ACLs.') + + msg_summary = ngettext( + '%(count)d CA ACL matched', '%(count)d CA ACLs matched', 0 + ) + + + at register() +class caacl_show(LDAPRetrieve): + __doc__ = _('Display the properties of a CA ACL.') + + + at register() +class caacl_enable(LDAPQuery): + __doc__ = _('Enable a CA ACL.') + + msg_summary = _('Enabled CA ACL "%(value)s"') + has_output = output.standard_value + + def execute(self, cn, **options): + ldap = self.obj.backend + + dn = self.obj.get_dn(cn) + try: + entry_attrs = ldap.get_entry(dn, ['ipaenabledflag']) + except errors.NotFound: + self.obj.handle_not_found(cn) + + entry_attrs['ipaenabledflag'] = ['TRUE'] + + try: + ldap.update_entry(entry_attrs) + except errors.EmptyModlist: + pass + + return dict( + result=True, + value=pkey_to_value(cn, options), + ) + + + at register() +class caacl_disable(LDAPQuery): + __doc__ = _('Disable a CA ACL.') + + msg_summary = _('Disabled CA ACL "%(value)s"') + has_output = output.standard_value + + def execute(self, cn, **options): + ldap = self.obj.backend + + dn = self.obj.get_dn(cn) + try: + entry_attrs = ldap.get_entry(dn, ['ipaenabledflag']) + except errors.NotFound: + self.obj.handle_not_found(cn) + + entry_attrs['ipaenabledflag'] = ['FALSE'] + + try: + ldap.update_entry(entry_attrs) + except errors.EmptyModlist: + pass + + return dict( + result=True, + value=pkey_to_value(cn, options), + ) + + + at register() +class caacl_add_user(LDAPAddMember): + __doc__ = _('Add users and groups to a CA ACL.') + + member_attributes = ['memberuser'] + member_count_out = ('%i object added.', '%i objects added.') + + + at register() +class caacl_remove_user(LDAPRemoveMember): + __doc__ = _('Remove users and groups from a CA ACL.') + + member_attributes = ['memberuser'] + member_count_out = ('%i object removed.', '%i objects removed.') + + + at register() +class caacl_add_host(LDAPAddMember): + __doc__ = _('Add target hosts and hostgroups to a CA ACL.') + + member_attributes = ['memberhost'] + member_count_out = ('%i object added.', '%i objects added.') + + + at register() +class caacl_remove_host(LDAPRemoveMember): + __doc__ = _('Remove target hosts and hostgroups from a CA ACL.') + + member_attributes = ['memberhost'] + member_count_out = ('%i object removed.', '%i objects removed.') + + + at register() +class caacl_add_service(LDAPAddMember): + __doc__ = _('Add services to a CA ACL.') + + member_attributes = ['memberservice'] + member_count_out = ('%i object added.', '%i objects added.') + + + at register() +class caacl_remove_service(LDAPRemoveMember): + __doc__ = _('Remove service and service groups from a CA ACL.') + + member_attributes = ['memberservice'] + member_count_out = ('%i object removed.', '%i objects removed.') diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py index 2acab13f247ed18a750f0e1cbbd98f4e63718c03..9f24189b6e442e0c55d5de41d15a03f89ecc9578 100644 --- a/ipaserver/install/dsinstance.py +++ b/ipaserver/install/dsinstance.py @@ -307,6 +307,7 @@ class DsInstance(service.Service): self.step("adding range check plugin", self.__add_range_check_plugin) if hbac_allow: self.step("creating default HBAC rule allow_all", self.add_hbac) + self.step("creating default CA ACL rule", self.add_caacl) self.step("adding entries for topology management", self.__add_topology_entries) self.__common_post_setup() @@ -741,6 +742,9 @@ class DsInstance(service.Service): def add_hbac(self): self._ldap_mod("default-hbac.ldif", self.sub_dict) + def add_caacl(self): + self._ldap_mod("default-caacl.ldif", self.sub_dict) + def change_admin_password(self, password): root_logger.debug("Changing admin password") dirname = config_dirname(self.serverid) -- 2.1.0 -------------- next part -------------- >From 5323e6acf2824fdc121988fbf58ca31925dd81b3 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Tue, 26 May 2015 04:44:20 -0400 Subject: [PATCH 13/13] Enforce CA ACLs in cert-request command This commit adds CA ACL enforcement to the cert-request command and uses the pyhbac machinery. It is planned to implement ACL enforcement in Dogtag in a future release, and remove certificate issuance privileges and CA ACL enforcement responsibility from the framework. See https://fedorahosted.org/freeipa/ticket/5011 for more information. Part of: https://fedorahosted.org/freeipa/ticket/57 Part of: https://fedorahosted.org/freeipa/ticket/4559 --- ipalib/plugins/caacl.py | 72 +++++++++++++++++++++++++++++++++++++++++++++++++ ipalib/plugins/cert.py | 17 ++++++++++++ 2 files changed, 89 insertions(+) diff --git a/ipalib/plugins/caacl.py b/ipalib/plugins/caacl.py index 84dc6d3c4db5f46d76bed560023b7cb63c5513b1..c09df863847f0e2b0e029b5c7f82d978a7e159bf 100644 --- a/ipalib/plugins/caacl.py +++ b/ipalib/plugins/caacl.py @@ -2,6 +2,8 @@ # Copyright (C) 2015 FreeIPA Contributors see COPYING for license # +import pyhbac + from ipalib import api, errors, output from ipalib import Bool, Str from ipalib.plugable import Registry @@ -10,6 +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 import _, ngettext from ipapython.dn import DN @@ -49,6 +52,75 @@ EXAMPLES: register = Registry() +def _acl_make_request(principal_type, principal, ca_ref, profile_id): + """Construct HBAC request for the given principal, CA and profile""" + req = pyhbac.HbacRequest() + req.targethost.name = ca_ref + req.service.name = profile_id + if principal_type == 'user': + req.user.name = principal + elif principal_type == 'host': + req.user.name = principal[:5] # strip 'host/' + elif principal_type == 'service': + req.user.name = normalize_principal(principal) + groups = [] + if principal_type == 'user': + user_obj = api.Command.user_show(principal)['result'] + groups = user_obj.get('memberof_group', []) + groups += user_obj.get('memberofindirect_group', []) + elif principal_type == 'host': + hostname = principal[5:] + host_obj = api.Command.host_show(hostname)['result'] + groups = host_obj.get('memberof_hostgroup', []) + groups += host_obj.get('memberofindirect_hostgroup', []) + req.user.groups = sorted(set(groups)) + return req + + +def _acl_make_rule(principal_type, obj): + """Turn CA ACL object into HBAC rule. + + ``principal_type`` + String in {'user', 'host', 'service'} + """ + rule = pyhbac.HbacRule(obj['cn'][0]) + rule.enabled = obj['ipaenabledflag'][0] + rule.srchosts.category = {pyhbac.HBAC_CATEGORY_ALL} + + # add CA(s) + if 'ipacaaclallcas' in obj and obj['ipacaaclallcas'][0] == 'TRUE': + rule.targethosts.category = {pyhbac.HBAC_CATEGORY_ALL} + else: + rule.targethosts.names = obj.get('ipacaaclcaref', []) + + # add profiles + if 'ipacaaclallprofiles' in obj and obj['ipacaaclallprofiles'][0] == 'TRUE': + rule.services.category = {pyhbac.HBAC_CATEGORY_ALL} + else: + rule.services.names = obj.get('ipacaaclprofileid', []) + + # add principals and principal's groups + m = {'user': 'group', 'host': 'hostgroup', 'service': None} + all_principals_attr = 'ipacaaclall{}s'.format(principal_type) + if all_principals_attr in obj and obj[all_principals_attr][0] == 'TRUE': + rule.users.category = {pyhbac.HBAC_CATEGORY_ALL} + else: + principal_attr = 'member{}_{}'.format(principal_type, principal_type) + rule.users.names = obj.get(principal_attr, []) + if m[principal_type] is not None: + group_attr = 'member{}_{}'.format(principal_type, m[principal_type]) + rule.users.groups = obj.get(group_attr, []) + + return rule + + +def acl_evaluate(principal_type, principal, ca_ref, profile_id): + req = _acl_make_request(principal_type, principal, ca_ref, profile_id) + acls = api.Command.caacl_find()['result'] + rules = [_acl_make_rule(principal_type, obj) for obj in acls] + return req.evaluate(rules) == pyhbac.HBAC_EVAL_ALLOW + + @register() class caacl(LDAPObject): """ diff --git a/ipalib/plugins/cert.py b/ipalib/plugins/cert.py index 34621b552d3e527c2dd0fee46e240542179227f9..70ae610b6e9ec724837ddc516ad990ed08af9e0e 100644 --- a/ipalib/plugins/cert.py +++ b/ipalib/plugins/cert.py @@ -33,6 +33,7 @@ from ipalib.plugins.virtual import * from ipalib.plugins.baseldap import pkey_to_value from ipalib.plugins.service import split_any_principal from ipalib.plugins.certprofile import validate_profile_id +import ipalib.plugins.caacl import base64 import traceback from ipalib.text import _ @@ -326,6 +327,22 @@ class cert_request(VirtualCommand): else: principal_type = SERVICE + principal_type_map = {USER: 'user', HOST: 'host', SERVICE: 'service'} + ca = '.' # top-level CA hardcoded until subca plugin implemented + if not ipalib.plugins.caacl.acl_evaluate( + principal_type_map[principal_type], + principal_string, ca, profile_id): + raise errors.ACIError(info=_( + "Principal '%(principal)s' " + "is not permitted to use CA '%(ca)s' " + "with profile '%(profile_id)s' for certificate issuance." + ) % dict( + principal=principal_string, + ca=ca or '.', + profile_id=profile_id + ) + ) + bind_principal = split_any_principal(getattr(context, 'principal')) bind_service, bind_name, bind_realm = bind_principal -- 2.1.0 From cheimes at redhat.com Wed May 27 14:06:16 2015 From: cheimes at redhat.com (Christian Heimes) Date: Wed, 27 May 2015 16:06:16 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <5565C989.7060007@redhat.com> References: <555F03DB.3090702@redhat.com> <556493D3.8010402@redhat.com> <55659335.2060306@redhat.com> <20150527095322.GM19176@redhat.com> <55659571.8070705@redhat.com> <5565AB70.7020004@redhat.com> <5565ABCF.5090305@redhat.com> <5565B10F.1090802@redhat.com> <5565BCE0.6060409@redhat.com> <5565C7D8.9040307@redhat.com> <5565C989.7060007@redhat.com> Message-ID: <5565CF58.1050405@redhat.com> On 2015-05-27 15:41, Petr Vobornik wrote: > It would be great to have a privileged daemon which could observed > replicated configuration and perform such tasks on all servers so we > would eliminate manual tasks(and errors and misconceptions which are > caused by forgotten manual tasks) as much as possible. We don't need a separate daemon, we already have an HTTP interface. A reload interface can be implemented with an additional route, e.g. GET /KdcProxy/refresh. It needs a bit of extra work in kdcproxy, kdcproxyshim.py and an ACL for the route. Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From pvoborni at redhat.com Wed May 27 14:14:32 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 27 May 2015 16:14:32 +0200 Subject: [Freeipa-devel] [PATCH] 822 webui: topology plugin In-Reply-To: <55644980.9020209@redhat.com> References: <55365A0B.1030305@redhat.com> <5555DD7F.10000@redhat.com> <55644980.9020209@redhat.com> Message-ID: <5565D148.4080807@redhat.com> On 05/26/2015 12:22 PM, Petr Vobornik wrote: > On 05/15/2015 01:50 PM, Petr Vobornik wrote: >> On 04/21/2015 04:09 PM, Petr Vobornik wrote: >>> First iteration of Topology plugin Web UI. >>> >>> It reflects current state of topology plugin python part which is >>> implemented in "[PATCH] manage replication topology in the shared tree" >>> and my wip patch. >>> >>> I expect that the server API part will change a bit therefore this will >>> as well. >>> >>> Graphical visualization/management (ticket 4286) will be implemented in >>> separate patch. >>> >>> https://fedorahosted.org/freeipa/ticket/4997 >>> http://www.freeipa.org/page/V4/Manage_replication_topology >>> >>> >> >> New version attached. It requires stage user web ui patches in order to >> apply (I expect that user life cycle backend will be pushed sooner than >> topology) >> >> Changes: >> - Left host and Right host fields are now host comboboxes >> - Connectivity are radio buttons with "both, left-right, right-left, >> none" options >> - segment name is not a required field in its adder dialog >> >> IMHO "Attributes to strip", "Attributes to replicate", "Attributes for >> total update", "Initialize replica", "Session timeout", "Replication >> agreement enabled" fields should not be just free-form textboxes, but >> they should be more specific, e.g. a checkbox for "Replication agreement >> enabled" or integer for "Session timeout", but that should be modified >> first in the backend python plugin. >> >> > > New patchset which replaces the old patch. > > Contains Web UI for: > - topologysuffix, topologysegment, domain level, server > > Backend is implemented in patches: > - tbabej 325-9 > - pvoborni 855, 857 > > New update which reflects the API change in domain level patches. (domainlevel-show changed to domainlevel-get). Now it depends only on pvoborni 857-2, the rest was pushed. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0861-2-webui-topology-plugin.patch Type: text/x-patch Size: 18568 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0860-1-webui-make-usage-of-all-in-details-facet-optional.patch Type: text/x-patch Size: 1859 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0859-1-webui-use-command_dialog-as-a-base-class-for-passwor.patch Type: text/x-patch Size: 6864 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0858-1-webui-IPA.command_dialog-a-new-dialog-base-class.patch Type: text/x-patch Size: 7403 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0862-webui-configurable-refresh-command.patch Type: text/x-patch Size: 1683 bytes Desc: not available URL: From mkosek at redhat.com Wed May 27 14:33:51 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 27 May 2015 16:33:51 +0200 Subject: [Freeipa-devel] Fix password changes via kadmin In-Reply-To: <20150527135516.GQ19176@redhat.com> References: <1428274413.19641.118.camel@willson.usersys.redhat.com> <5562E1FA.3050001@redhat.com> <5565C5E6.9060005@redhat.com> <1432734430.3243.118.camel@willson.usersys.redhat.com> <20150527135516.GQ19176@redhat.com> Message-ID: <5565D5CF.9000108@redhat.com> On 05/27/2015 03:55 PM, Alexander Bokovoy wrote: > On Wed, 27 May 2015, Simo Sorce wrote: >> On Wed, 2015-05-27 at 15:25 +0200, Martin Babinsky wrote: >>> On 05/25/2015 10:48 AM, Martin Babinsky wrote: >>> > On 04/06/2015 12:53 AM, Simo Sorce wrote: >>> >> Fix for bug 4914. >>> >> >>> >> I've tested it locally and seem to do exactly what is needed. I couldn't >>> >> detect any side effects, except that if you use kadmin to get a >>> >> randomized password for a service then you'll get a key for all >>> >> supported types (currently aes256, aes128, des3, rc4, camellia128, >>> >> camellia256) instead of just the default ones (aes256, aes128, des3, >>> >> rc4) if you do not specify enctypes. I think that is fine, we use >>> >> ipa-getkeytab anyway in the normal course of business and that one uses >>> >> a different code path. >>> >> >>> >> Simo. >>> >> >>> >> >>> >> >>> > >>> > Hi Simo, >>> > >>> > the patch works as expected. >>> > >>> > My only gripe is with the duplicate code in 'daemons/ipa-kdb/ipa_kdb.c' >>> > between lines 389 and 455. It could be made into a single function to >>> > get key encoding/salt types from LDAP (see my feeble and untested >>> > attempt which I attached). >>> > >>> > >>> > >>> ACK. >>> >>> I will then send the patch fixing duplicate code separately once I >>> consult it with somebody more skilled in C than myself. >>> >> >> Thanks, added your reviewed-by and pushed to master. >> >> Martin, should we push this to other branches too ? > I think we also need this in 4.1 so that it can go to Fedora, Debian, > and RHEL releases. 4.2 will be released soon, but if you are confident about the patch so that it does not break stuff, we may add it to 4.1.x too, given the positive impact. From pspacek at redhat.com Wed May 27 14:39:05 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 27 May 2015 16:39:05 +0200 Subject: [Freeipa-devel] [PATCH 0376] Add schema for unknown record types In-Reply-To: <556447E9.5070705@redhat.com> References: <555DB694.4090808@redhat.com> <556447E9.5070705@redhat.com> Message-ID: <5565D709.60206@redhat.com> On 26.5.2015 12:16, Tomas Hozza wrote: > On 05/21/2015 12:42 PM, Petr Spacek wrote: >> Hello, >> >> Add schema for unknown record types. >> >> This patch complements my previous patch 367. >> >> The change was pushed to >> https://github.com/pspacek/bind-dyndb-ldap/tree/unknown_record_types , too. >> > > ACK Pushed to master: d64744725d5607a0b928c59fb233e794b3dc6d48 Thanks! -- Petr^2 Spacek From pspacek at redhat.com Wed May 27 14:39:45 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 27 May 2015 16:39:45 +0200 Subject: [Freeipa-devel] [PATCH 0367] Support unknown record types (RFC 3597) In-Reply-To: <493605240.4506885.1432653031696.JavaMail.zimbra@redhat.com> References: <555A05D2.7000408@redhat.com> <555EE2E5.2020001@redhat.com> <493605240.4506885.1432653031696.JavaMail.zimbra@redhat.com> Message-ID: <5565D731.5050405@redhat.com> On 26.5.2015 17:10, Matus Honek wrote: > Works with correct privileges checking, as in your patch attached. > > ACK Thank you very much! Pushed to master: 79cc0254aca589d6d352d96de1827c84d0fe6cfb Petr^2 Spacek > ----- Original Message ----- > From: "Petr Spacek" > To: thozza at redhat.com > Cc: freeipa-devel at redhat.com, "Matus Honek" > Sent: Friday, May 22, 2015 10:03:49 AM > Subject: Re: [Freeipa-devel] [PATCH 0367] Support unknown record types (RFC 3597) > > On 18.5.2015 17:31, Petr Spacek wrote: >> Hello, >> >> This patch is unrelated to metaDB but it should be merged before alpha, too. >> >> Thank you for review! >> >> Support unknown record types (RFC 3597). >> >> Fallback to generic LDAP attribute "UnknownRecord;TYP256" if attempt to >> add specific attribute like "URIRecord" failed with LDAP_OBJECT_CLASS_VIOLATION >> and always delete both attributes like "URIRecord" and "UnknownRecord;TYPE256". >> >> https://fedorahosted.org/bind-dyndb-ldap/ticket/157 > > Fixed version is attached. Version 1 could dereference NULL pointers in second > iteration of while loops. From simo at redhat.com Wed May 27 14:48:01 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 27 May 2015 10:48:01 -0400 Subject: [Freeipa-devel] Fix password changes via kadmin In-Reply-To: <5565D5CF.9000108@redhat.com> References: <1428274413.19641.118.camel@willson.usersys.redhat.com> <5562E1FA.3050001@redhat.com> <5565C5E6.9060005@redhat.com> <1432734430.3243.118.camel@willson.usersys.redhat.com> <20150527135516.GQ19176@redhat.com> <5565D5CF.9000108@redhat.com> Message-ID: <1432738081.19096.14.camel@willson.usersys.redhat.com> On Wed, 2015-05-27 at 16:33 +0200, Martin Kosek wrote: > On 05/27/2015 03:55 PM, Alexander Bokovoy wrote: > > On Wed, 27 May 2015, Simo Sorce wrote: > >> On Wed, 2015-05-27 at 15:25 +0200, Martin Babinsky wrote: > >>> On 05/25/2015 10:48 AM, Martin Babinsky wrote: > >>> > On 04/06/2015 12:53 AM, Simo Sorce wrote: > >>> >> Fix for bug 4914. > >>> >> > >>> >> I've tested it locally and seem to do exactly what is needed. I couldn't > >>> >> detect any side effects, except that if you use kadmin to get a > >>> >> randomized password for a service then you'll get a key for all > >>> >> supported types (currently aes256, aes128, des3, rc4, camellia128, > >>> >> camellia256) instead of just the default ones (aes256, aes128, des3, > >>> >> rc4) if you do not specify enctypes. I think that is fine, we use > >>> >> ipa-getkeytab anyway in the normal course of business and that one uses > >>> >> a different code path. > >>> >> > >>> >> Simo. > >>> >> > >>> >> > >>> >> > >>> > > >>> > Hi Simo, > >>> > > >>> > the patch works as expected. > >>> > > >>> > My only gripe is with the duplicate code in 'daemons/ipa-kdb/ipa_kdb.c' > >>> > between lines 389 and 455. It could be made into a single function to > >>> > get key encoding/salt types from LDAP (see my feeble and untested > >>> > attempt which I attached). > >>> > > >>> > > >>> > > >>> ACK. > >>> > >>> I will then send the patch fixing duplicate code separately once I > >>> consult it with somebody more skilled in C than myself. > >>> > >> > >> Thanks, added your reviewed-by and pushed to master. > >> > >> Martin, should we push this to other branches too ? > > I think we also need this in 4.1 so that it can go to Fedora, Debian, > > and RHEL releases. > > 4.2 will be released soon, but if you are confident about the patch so that it > does not break stuff, we may add it to 4.1.x too, given the positive impact. Please backport to 4.1 then, it really is only a net positive afaik. Simo. -- Simo Sorce * Red Hat, Inc * New York From mbabinsk at redhat.com Wed May 27 14:50:59 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 27 May 2015 16:50:59 +0200 Subject: [Freeipa-devel] Fix password changes via kadmin In-Reply-To: <5565D5CF.9000108@redhat.com> References: <1428274413.19641.118.camel@willson.usersys.redhat.com> <5562E1FA.3050001@redhat.com> <5565C5E6.9060005@redhat.com> <1432734430.3243.118.camel@willson.usersys.redhat.com> <20150527135516.GQ19176@redhat.com> <5565D5CF.9000108@redhat.com> Message-ID: <5565D9D3.6000105@redhat.com> On 05/27/2015 04:33 PM, Martin Kosek wrote: > On 05/27/2015 03:55 PM, Alexander Bokovoy wrote: >> On Wed, 27 May 2015, Simo Sorce wrote: >>> On Wed, 2015-05-27 at 15:25 +0200, Martin Babinsky wrote: >>>> On 05/25/2015 10:48 AM, Martin Babinsky wrote: >>>>> On 04/06/2015 12:53 AM, Simo Sorce wrote: >>>>>> Fix for bug 4914. >>>>>> >>>>>> I've tested it locally and seem to do exactly what is needed. I couldn't >>>>>> detect any side effects, except that if you use kadmin to get a >>>>>> randomized password for a service then you'll get a key for all >>>>>> supported types (currently aes256, aes128, des3, rc4, camellia128, >>>>>> camellia256) instead of just the default ones (aes256, aes128, des3, >>>>>> rc4) if you do not specify enctypes. I think that is fine, we use >>>>>> ipa-getkeytab anyway in the normal course of business and that one uses >>>>>> a different code path. >>>>>> >>>>>> Simo. >>>>>> >>>>>> >>>>>> >>>>> >>>>> Hi Simo, >>>>> >>>>> the patch works as expected. >>>>> >>>>> My only gripe is with the duplicate code in 'daemons/ipa-kdb/ipa_kdb.c' >>>>> between lines 389 and 455. It could be made into a single function to >>>>> get key encoding/salt types from LDAP (see my feeble and untested >>>>> attempt which I attached). >>>>> >>>>> >>>>> >>>> ACK. >>>> >>>> I will then send the patch fixing duplicate code separately once I >>>> consult it with somebody more skilled in C than myself. >>>> >>> >>> Thanks, added your reviewed-by and pushed to master. >>> >>> Martin, should we push this to other branches too ? >> I think we also need this in 4.1 so that it can go to Fedora, Debian, >> and RHEL releases. > > 4.2 will be released soon, but if you are confident about the patch so that it > does not break stuff, we may add it to 4.1.x too, given the positive impact. > I actually tested it also with 4.1 branch with no problem. -- Martin^3 Babinsky From mkosek at redhat.com Wed May 27 14:59:03 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 27 May 2015 16:59:03 +0200 Subject: [Freeipa-devel] New replica installation and topology - we need stable base Message-ID: <5565DBB7.1030304@redhat.com> Hello all, As FreeIPA 4.2 deadlines are approaching us slowly, there is a concern that not all of the new replica install way (replication-package-less) based on Custodia would be done and finished in time. There will be certainly a lot of integration hurdles, in making sure that the installed replica can ask for all needed secrets and that the server can provide them and ensure proper encryption. My question is - if we postpone new replica promotion way&Custodia, what is needed to make FreeIPA 4.2 replica installation and topology management GA-ready and finished? This is the status of related functions, as I see it: Domain Levels - Done, committed - Defaults to Level 1, i.e. Topology plugin powered infra enabled Topology plugin - We have the base plugin and it's installation pushed - There is a critical bug that needs to be solved - #5035 - API&UI is in works (Petr Vobornik). We already committed the new server-* commands used there. Overall, AFAIU the API should be mostly functionally complete - Plugin is enabled during installation, but we still use the simple auth with DM password during replica creation process. I think we planned to use GSSAPI, no? Is anything else needed in the replica creation process, except fixing #5035? Given this summary, if we forget about the Custodia parts for a moment, it seems to me that the new Topology is almost functionally complete and we only miss the management API. Is that correct or we miss some bigger piece? I am for example not sure if the "IPA masters" hostgroup is needed for Topology work without Custodia, I think Ludwig used some other group for authorization purposes in Topology. Thanks. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From ofayans at redhat.com Wed May 27 15:05:38 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 27 May 2015 17:05:38 +0200 Subject: [Freeipa-devel] New replica installation and topology - we need stable base In-Reply-To: <5565DBB7.1030304@redhat.com> References: <5565DBB7.1030304@redhat.com> Message-ID: <5565DD42.4020604@redhat.com> On 05/27/2015 04:59 PM, Martin Kosek wrote: > Hello all, > > As FreeIPA 4.2 deadlines are approaching us slowly, there is a concern that not > all of the new replica install way (replication-package-less) based on Custodia > would be done and finished in time. > > There will be certainly a lot of integration hurdles, in making sure that the > installed replica can ask for all needed secrets and that the server can > provide them and ensure proper encryption. > > My question is - if we postpone new replica promotion way&Custodia, what is > needed to make FreeIPA 4.2 replica installation and topology management > GA-ready and finished? > > This is the status of related functions, as I see it: > > Domain Levels > - Done, committed > - Defaults to Level 1, i.e. Topology plugin powered infra enabled > > Topology plugin > - We have the base plugin and it's installation pushed > - There is a critical bug that needs to be solved - #5035 Which actually blocks the testing of the feature. Once it is resolved, we need several days to properly test the plugin. I anticipate at least a week, if there will be no other blockers. This does not include WebUI part of the plugin. > - API&UI is in works (Petr Vobornik). We already committed the new server-* > commands used there. Overall, AFAIU the API should be mostly functionally complete > - Plugin is enabled during installation, but we still use the simple auth with > DM password during replica creation process. I think we planned to use GSSAPI, > no? Is anything else needed in the replica creation process, except fixing #5035? > > Given this summary, if we forget about the Custodia parts for a moment, it > seems to me that the new Topology is almost functionally complete and we only > miss the management API. Is that correct or we miss some bigger piece? > > I am for example not sure if the "IPA masters" hostgroup is needed for Topology > work without Custodia, I think Ludwig used some other group for authorization > purposes in Topology. > > Thanks. > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From ssorce at redhat.com Wed May 27 15:10:10 2015 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 27 May 2015 11:10:10 -0400 Subject: [Freeipa-devel] New replica installation and topology - we need stable base In-Reply-To: <5565DBB7.1030304@redhat.com> References: <5565DBB7.1030304@redhat.com> Message-ID: <1432739410.19096.23.camel@willson.usersys.redhat.com> On Wed, 2015-05-27 at 16:59 +0200, Martin Kosek wrote: > Hello all, > > As FreeIPA 4.2 deadlines are approaching us slowly, there is a concern that not > all of the new replica install way (replication-package-less) based on Custodia > would be done and finished in time. > > There will be certainly a lot of integration hurdles, in making sure that the > installed replica can ask for all needed secrets and that the server can > provide them and ensure proper encryption. The encryption part is not a concern, but proper integration of all these interconnected and inter-dependent components is. > My question is - if we postpone new replica promotion way&Custodia, what is > needed to make FreeIPA 4.2 replica installation and topology management > GA-ready and finished? > > This is the status of related functions, as I see it: > > Domain Levels > - Done, committed > - Defaults to Level 1, i.e. Topology plugin powered infra enabled This default is only for a *new* domain right ? If you join a replica it should not automatically enable topology. > Topology plugin > - We have the base plugin and it's installation pushed > - There is a critical bug that needs to be solved - #5035 > - API&UI is in works (Petr Vobornik). We already committed the new server-* > commands used there. Overall, AFAIU the API should be mostly functionally complete > - Plugin is enabled during installation, but we still use the simple auth with > DM password during replica creation process. I think we planned to use GSSAPI, > no? Is anything else needed in the replica creation process, except fixing #5035? > > Given this summary, if we forget about the Custodia parts for a moment, it > seems to me that the new Topology is almost functionally complete and we only > miss the management API. Is that correct or we miss some bigger piece? > > I am for example not sure if the "IPA masters" hostgroup is needed for Topology > work without Custodia, I think Ludwig used some other group for authorization > purposes in Topology. The hostgroup is needed regardless of Custodia, IIRC. Simo. From pvoborni at redhat.com Wed May 27 15:23:30 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 27 May 2015 17:23:30 +0200 Subject: [Freeipa-devel] [PATCH] 1112 Add service constraint delegation plugin In-Reply-To: <555CB00B.3080309@redhat.com> References: <555B4696.2070502@redhat.com> <555BA115.5070408@redhat.com> <555CB00B.3080309@redhat.com> Message-ID: <5565E172.9040206@redhat.com> On 05/20/2015 06:02 PM, Rob Crittenden wrote: > Rob Crittenden wrote: >> 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. > > I must be getting rustly. Forgot to include ACIs. Added now. > > rob > Thanks for the design[1] and patches. First some high level questions before any unnecessary changes are made. From API point of view wouldn't it be better to distinguish rules and targets by object name so we could avoid usage of the --type option. I.e., why expose internal schema limitations in the API? Type could be implied by the object name and commands can do what they do now. They could even have a common base class if needed. E.g.: servicedelegationrule-add MYRULE servicedelegationrule-find servicedelegationrule-del MYRULE servicedelegationrule-add_member MYRULE --targets={MYTARGET,MYTARGET2} --principals={..,..} servicedelegationrule-remove_member MYRULE --targets={MYTARGET,MYTARGET2} --principals={..,..} servicedelegationtarget-add MYTARGET servicedelegationtarget-find servicedelegationtarget-del MYTARGET servicedelegationtarget-add_member MYTARGET --principals={..,..} servicedelegationtarget-remove_member MYTARGET --principals={..,..} Yes, I used delegation instead of constraint. What is the rationale behind 'constraint'? To me 'constraint' specifies what kind of delegation we want to set but a goal of S4U2 proxy is to allow something which is not allowed by default not to create a new constraint. [1] http://www.freeipa.org/page/V4/Service_Constraint_Delegation -- Petr Vobornik From rcritten at redhat.com Wed May 27 15:37:33 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 27 May 2015 11:37:33 -0400 Subject: [Freeipa-devel] [PATCH] 1112 Add service constraint delegation plugin In-Reply-To: <5565E172.9040206@redhat.com> References: <555B4696.2070502@redhat.com> <555BA115.5070408@redhat.com> <555CB00B.3080309@redhat.com> <5565E172.9040206@redhat.com> Message-ID: <5565E4BD.9040209@redhat.com> Petr Vobornik wrote: > On 05/20/2015 06:02 PM, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> 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. >> >> I must be getting rustly. Forgot to include ACIs. Added now. >> >> rob >> > > Thanks for the design[1] and patches. > > First some high level questions before any unnecessary changes are made. > > From API point of view wouldn't it be better to distinguish rules and > targets by object name so we could avoid usage of the --type option. > I.e., why expose internal schema limitations in the API? > > Type could be implied by the object name and commands can do what they > do now. They could even have a common base class if needed. > > E.g.: > > servicedelegationrule-add MYRULE > servicedelegationrule-find > servicedelegationrule-del MYRULE > servicedelegationrule-add_member MYRULE --targets={MYTARGET,MYTARGET2} > --principals={..,..} > servicedelegationrule-remove_member MYRULE > --targets={MYTARGET,MYTARGET2} --principals={..,..} > > servicedelegationtarget-add MYTARGET > servicedelegationtarget-find > servicedelegationtarget-del MYTARGET > servicedelegationtarget-add_member MYTARGET --principals={..,..} > servicedelegationtarget-remove_member MYTARGET --principals={..,..} > > Yes, I used delegation instead of constraint. What is the rationale > behind 'constraint'? To me 'constraint' specifies what kind of > delegation we want to set but a goal of S4U2 proxy is to allow something > which is not allowed by default not to create a new constraint. > > [1] http://www.freeipa.org/page/V4/Service_Constraint_Delegation I considered that but we already have this precedent in automember so I went with it. This is complex enough with the fake memberPrincipal stuff, I don't want to explode it with a baseclass and two subclasses as well, plus doubling the number of new API commands. Technically this is called constrained delegation. I was trying to keep the name short and still descriptive. There is already aci delegation which is a completely separate thing. rob From abokovoy at redhat.com Wed May 27 15:46:13 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 27 May 2015 18:46:13 +0300 Subject: [Freeipa-devel] [PATCH] 1112 Add service constraint delegation plugin In-Reply-To: <5565E4BD.9040209@redhat.com> References: <555B4696.2070502@redhat.com> <555BA115.5070408@redhat.com> <555CB00B.3080309@redhat.com> <5565E172.9040206@redhat.com> <5565E4BD.9040209@redhat.com> Message-ID: <20150527154613.GS19176@redhat.com> On Wed, 27 May 2015, Rob Crittenden wrote: >Petr Vobornik wrote: >>On 05/20/2015 06:02 PM, Rob Crittenden wrote: >>>Rob Crittenden wrote: >>>>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. >>> >>>I must be getting rustly. Forgot to include ACIs. Added now. >>> >>>rob >>> >> >>Thanks for the design[1] and patches. >> >>First some high level questions before any unnecessary changes are made. >> >> From API point of view wouldn't it be better to distinguish rules and >>targets by object name so we could avoid usage of the --type option. >>I.e., why expose internal schema limitations in the API? >> >>Type could be implied by the object name and commands can do what they >>do now. They could even have a common base class if needed. >> >>E.g.: >> >>servicedelegationrule-add MYRULE >>servicedelegationrule-find >>servicedelegationrule-del MYRULE >>servicedelegationrule-add_member MYRULE --targets={MYTARGET,MYTARGET2} >>--principals={..,..} >>servicedelegationrule-remove_member MYRULE >>--targets={MYTARGET,MYTARGET2} --principals={..,..} >> >>servicedelegationtarget-add MYTARGET >>servicedelegationtarget-find >>servicedelegationtarget-del MYTARGET >>servicedelegationtarget-add_member MYTARGET --principals={..,..} >>servicedelegationtarget-remove_member MYTARGET --principals={..,..} >> >>Yes, I used delegation instead of constraint. What is the rationale >>behind 'constraint'? To me 'constraint' specifies what kind of >>delegation we want to set but a goal of S4U2 proxy is to allow something >>which is not allowed by default not to create a new constraint. >> >>[1] http://www.freeipa.org/page/V4/Service_Constraint_Delegation > >I considered that but we already have this precedent in automember so >I went with it. This is complex enough with the fake memberPrincipal >stuff, I don't want to explode it with a baseclass and two subclasses >as well, plus doubling the number of new API commands. > >Technically this is called constrained delegation. I was trying to >keep the name short and still descriptive. There is already aci >delegation which is a completely separate thing. I agree with Rob. There is also a need to address principals which aren't directly accessible as IPA objects in the framework (think about trusts, for example). -- / Alexander Bokovoy From mbasti at redhat.com Wed May 27 16:12:50 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 27 May 2015 18:12:50 +0200 Subject: [Freeipa-devel] [PATCH 0014] Support multiple user and host certificates In-Reply-To: <20150527135315.GC24915@dhcp-40-8.bne.redhat.com> References: <20150527135315.GC24915@dhcp-40-8.bne.redhat.com> Message-ID: <5565ED02.6060709@redhat.com> On 27/05/15 15:53, Fraser Tweedale wrote: > This patch adds supports for multiple user / host certificates. No > schema change is needed ('usercertificate' attribute is already > multi-value). The revoke-previous-cert behaviour of host-mod and > user-mod has been removed but revocation behaviour of -del and > -disable is preserved. > > The latest profiles/caacl patchset (0001..0013 v5) depends on this > patch for correct cert-request behaviour. > > There is one design question (or maybe more, let me know): the > `--out=FILENAME' option to {host,service} show saves ONE certificate > to the named file. I propose to either: > > a) write all certs, suffixing suggested filename with either a > sequential numerical index, e.g. "cert.pem" becomes > "cert.pem.1", "cert.pem.2", and so on; or > > b) as above, but suffix with serial number and, if there are > different issues, some issuer-identifying information. > > Let me know your thoughts. > > Thanks, > Fraser > > Is there a possible way how to store certificates into one file? I read about possibilities to have multiple certs in one .pem file, but I'm not cert guru :) I personally vote for serial number in case there are multiple certificates, if ^ is no possible. 1) + if len(certs) > 0: please use only, if certs: 2) You need to re-generate API/ACI.txt in this patch 3) syntax error: + for dercert in certs_der 4) command ipa user-mod ca_user --certificate= removes the current certificate from the LDAP, by design. Should be the old certificate(s) revoked? You removed that part in the code. only the --addattr='usercertificate=' appends new value there -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Wed May 27 16:21:49 2015 From: sbose at redhat.com (Sumit Bose) Date: Wed, 27 May 2015 18:21:49 +0200 Subject: [Freeipa-devel] [PATCH 0014] Support multiple user and host certificates In-Reply-To: <5565ED02.6060709@redhat.com> References: <20150527135315.GC24915@dhcp-40-8.bne.redhat.com> <5565ED02.6060709@redhat.com> Message-ID: <20150527162149.GS3943@p.redhat.com> On Wed, May 27, 2015 at 06:12:50PM +0200, Martin Basti wrote: > On 27/05/15 15:53, Fraser Tweedale wrote: > >This patch adds supports for multiple user / host certificates. No > >schema change is needed ('usercertificate' attribute is already > >multi-value). The revoke-previous-cert behaviour of host-mod and > >user-mod has been removed but revocation behaviour of -del and > >-disable is preserved. > > > >The latest profiles/caacl patchset (0001..0013 v5) depends on this > >patch for correct cert-request behaviour. > > > >There is one design question (or maybe more, let me know): the > >`--out=FILENAME' option to {host,service} show saves ONE certificate > >to the named file. I propose to either: > > > >a) write all certs, suffixing suggested filename with either a > > sequential numerical index, e.g. "cert.pem" becomes > > "cert.pem.1", "cert.pem.2", and so on; or > > > >b) as above, but suffix with serial number and, if there are > > different issues, some issuer-identifying information. > > > >Let me know your thoughts. > > > >Thanks, > >Fraser > > > > > Is there a possible way how to store certificates into one file? > I read about possibilities to have multiple certs in one .pem file, but I'm > not cert guru :) It is possible, check e.g. /etc/pki/tls/cert.pem. bye, Sumit > > I personally vote for serial number in case there are multiple certificates, > if ^ is no possible. > > > 1) > + if len(certs) > 0: > > please use only, > if certs: > > 2) > You need to re-generate API/ACI.txt in this patch > > 3) > syntax error: > + for dercert in certs_der > > > 4) > command > ipa user-mod ca_user --certificate= > > removes the current certificate from the LDAP, by design. > Should be the old certificate(s) revoked? You removed that part in the code. > > only the --addattr='usercertificate=' appends new value there > > -- > 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 From simo at redhat.com Wed May 27 16:32:01 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 27 May 2015 12:32:01 -0400 Subject: [Freeipa-devel] [PATCH] 1112 Add service constraint delegation plugin In-Reply-To: <20150527154613.GS19176@redhat.com> References: <555B4696.2070502@redhat.com> <555BA115.5070408@redhat.com> <555CB00B.3080309@redhat.com> <5565E172.9040206@redhat.com> <5565E4BD.9040209@redhat.com> <20150527154613.GS19176@redhat.com> Message-ID: <1432744321.19096.46.camel@willson.usersys.redhat.com> On Wed, 2015-05-27 at 18:46 +0300, Alexander Bokovoy wrote: > On Wed, 27 May 2015, Rob Crittenden wrote: > >Petr Vobornik wrote: > >>On 05/20/2015 06:02 PM, Rob Crittenden wrote: > >>>Rob Crittenden wrote: > >>>>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. > >>> > >>>I must be getting rustly. Forgot to include ACIs. Added now. > >>> > >>>rob > >>> > >> > >>Thanks for the design[1] and patches. > >> > >>First some high level questions before any unnecessary changes are made. > >> > >> From API point of view wouldn't it be better to distinguish rules and > >>targets by object name so we could avoid usage of the --type option. > >>I.e., why expose internal schema limitations in the API? > >> > >>Type could be implied by the object name and commands can do what they > >>do now. They could even have a common base class if needed. > >> > >>E.g.: > >> > >>servicedelegationrule-add MYRULE > >>servicedelegationrule-find > >>servicedelegationrule-del MYRULE > >>servicedelegationrule-add_member MYRULE --targets={MYTARGET,MYTARGET2} > >>--principals={..,..} > >>servicedelegationrule-remove_member MYRULE > >>--targets={MYTARGET,MYTARGET2} --principals={..,..} > >> > >>servicedelegationtarget-add MYTARGET > >>servicedelegationtarget-find > >>servicedelegationtarget-del MYTARGET > >>servicedelegationtarget-add_member MYTARGET --principals={..,..} > >>servicedelegationtarget-remove_member MYTARGET --principals={..,..} > >> > >>Yes, I used delegation instead of constraint. What is the rationale > >>behind 'constraint'? To me 'constraint' specifies what kind of > >>delegation we want to set but a goal of S4U2 proxy is to allow something > >>which is not allowed by default not to create a new constraint. > >> > >>[1] http://www.freeipa.org/page/V4/Service_Constraint_Delegation > > > >I considered that but we already have this precedent in automember so > >I went with it. This is complex enough with the fake memberPrincipal > >stuff, I don't want to explode it with a baseclass and two subclasses > >as well, plus doubling the number of new API commands. > > > >Technically this is called constrained delegation. I was trying to > >keep the name short and still descriptive. There is already aci > >delegation which is a completely separate thing. > I agree with Rob. There is also a need to address principals which > aren't directly accessible as IPA objects in the framework (think about > trusts, for example). Shouldn't the commands then be: constraineddelegation-add etc... serviceconstraint doesn't really help understanding what this is all about. If service is in the name I agree with Petr that servicedelegation makes much more sense. On the API I also do not like to split rules into 2 apis, but I see no other option really. Something like the following makes it clear what you are operating on: ipa servicedelegationtarget-add [principals] ipa servicedelegation-add --members [principals] --targets [targets] Example: ipa servicedelegationtarget-add ipa-ldap ldap/ipa1.example.com ldap/ipa2.example.com This would add ldap/ipa1.example.com at EXAMPLE.COM and ldap/ipa2.example.com at EXAMPLE.COM to cn=ipa-ldap-delegation-targets (note that rule name is shorter than DN and principals are automatically augmented with the REALM part if not provided on the command line) ipa servicedelegation-add ipa-http --targets ipa-ldap This would create the cn=ipa-http-delegation rule and add cn=ipa-ldap-delegation-targets,... to it (note again that the rule name and target name are shortcuts wrt the actual DNs used) ipa servicedelegation-mod ipa-http --add-members HTTP/ipa1.example.com HTTP/ipa2.example.com This would add member principals to cn=ipa-http-delegation The full list of APIs would be: ipa servicedelegation-add [--members principals] [--targets targets] ipa servicedelegation-del ipa servicedelegation-mod [--add-members Ps] [--del-members Ps] [--add-targets Ts] [--del-targets Ts] ipa servicedelegation-show ipa servicedelegation-find [rule] ipa servicedelegtarget-add [--members principals] ipa servicedelegtarget-del ipa servicedelegtarget-mod [--add-members Ps] [--del-members Ps] ipa servicedelegtarget-show ipa servicedelegtarget-find [target] HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Wed May 27 16:36:43 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 27 May 2015 18:36:43 +0200 Subject: [Freeipa-devel] [PATCH] 1112 Add service constraint delegation plugin In-Reply-To: <555CB00B.3080309@redhat.com> References: <555B4696.2070502@redhat.com> <555BA115.5070408@redhat.com> <555CB00B.3080309@redhat.com> Message-ID: <5565F29B.7000507@redhat.com> On 20/05/15 18:02, Rob Crittenden wrote: > Rob Crittenden wrote: >> 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. > > I must be getting rustly. Forgot to include ACIs. Added now. > > rob > > > Thank you. I haven't finished review yet, but I have few notes in case you will modify the patch. Please fix following issues: 1) Patch needs rebase, VERSION conflict 2) + pattern='^[a-zA-Z0-9_.][ a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.-]?$', + pattern_errmsg='may only include letters, numbers, _, -, ., and a space inside', + maxlength=255, If I count correctly, regexp allows only 254 characters, not 255, and this regexp also allows the space at the end of the string. IMHO '^[a-zA-Z0-9_.]([ a-zA-Z0-9_.-]*[a-zA-Z0-9_.-])?$' would work. 3) There are many PEP8 errors, can you fix some of them,? 4) Please use except Exception as e: to be compatible with python 3 5) For new files we stared using shorter license header. # # Copyright (C) 2015 FreeIPA Contributors see COPYING for license # -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Wed May 27 17:15:24 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 27 May 2015 19:15:24 +0200 Subject: [Freeipa-devel] [PATCH] 1112 Add service constraint delegation plugin In-Reply-To: <20150527154613.GS19176@redhat.com> References: <555B4696.2070502@redhat.com> <555BA115.5070408@redhat.com> <555CB00B.3080309@redhat.com> <5565E172.9040206@redhat.com> <5565E4BD.9040209@redhat.com> <20150527154613.GS19176@redhat.com> Message-ID: <5565FBAC.8080604@redhat.com> On 05/27/2015 05:46 PM, Alexander Bokovoy wrote: > On Wed, 27 May 2015, Rob Crittenden wrote: >> Petr Vobornik wrote: >>> On 05/20/2015 06:02 PM, Rob Crittenden wrote: >>>> Rob Crittenden wrote: >>>>> 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. >>>> >>>> I must be getting rustly. Forgot to include ACIs. Added now. >>>> >>>> rob >>>> >>> >>> Thanks for the design[1] and patches. >>> >>> First some high level questions before any unnecessary changes are made. >>> >>> From API point of view wouldn't it be better to distinguish rules and >>> targets by object name so we could avoid usage of the --type option. >>> I.e., why expose internal schema limitations in the API? >>> >>> Type could be implied by the object name and commands can do what they >>> do now. They could even have a common base class if needed. >>> >>> E.g.: >>> >>> servicedelegationrule-add MYRULE >>> servicedelegationrule-find >>> servicedelegationrule-del MYRULE >>> servicedelegationrule-add_member MYRULE --targets={MYTARGET,MYTARGET2} >>> --principals={..,..} >>> servicedelegationrule-remove_member MYRULE >>> --targets={MYTARGET,MYTARGET2} --principals={..,..} >>> >>> servicedelegationtarget-add MYTARGET >>> servicedelegationtarget-find >>> servicedelegationtarget-del MYTARGET >>> servicedelegationtarget-add_member MYTARGET --principals={..,..} >>> servicedelegationtarget-remove_member MYTARGET --principals={..,..} >>> >>> Yes, I used delegation instead of constraint. What is the rationale >>> behind 'constraint'? To me 'constraint' specifies what kind of >>> delegation we want to set but a goal of S4U2 proxy is to allow something >>> which is not allowed by default not to create a new constraint. >>> >>> [1] http://www.freeipa.org/page/V4/Service_Constraint_Delegation >> >> I considered that but we already have this precedent in automember so >> I went with it. This is complex enough with the fake memberPrincipal >> stuff, I don't want to explode it with a baseclass and two subclasses >> as well, plus doubling the number of new API commands. It could tolerated in automember given that hostgroup and group rules have exactly the same schema and purpose. The only difference is a different target. On the other hand, here, the purpose of both types is different. One is a rule, second a target. Separation of the names would tell it to the users. Number of API commands is a topic for different discussion. In short, it could be handled better in CLI and future doc. I don't want to discuss implementation details(complexity) yet. Issue with API is that we are stuck with it and can't change it(much). >> >> Technically this is called constrained delegation. I was trying to >> keep the name short and still descriptive. There is already aci >> delegation which is a completely separate thing. I understand that. The existing delegation might be misleading and should be distinguished from s4u2. But imagine that somebody told you that he created a new "service constraint rule of service A to service B". Since there is no mention of word delegation nor S4U I wouldn't know that it's related to ticket delegation. I would think the *opposite*. That he constrained service A to do something with service B. But a "service delegation rule", "constrained delegation rule" or "ticket delegation rule" says what it is actually about. Rather than avoiding descriptive commands we should improve a speed bash completion. A feeble attempt to remove service from the object name: A question: Even thought the kerberos feature is called S4U (service for user), is it limited to service principals? Services are of course the primary target but in theory they don't have to be, right? > I agree with Rob. There is also a need to address principals which > aren't directly accessible as IPA objects in the framework (think about > trusts, for example). I don't think this part is affected at all. The API's have the same capabilities. -- Petr Vobornik From rcritten at redhat.com Wed May 27 17:27:51 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 27 May 2015 13:27:51 -0400 Subject: [Freeipa-devel] [PATCH] 1112 Add service constraint delegation plugin In-Reply-To: <5565F29B.7000507@redhat.com> References: <555B4696.2070502@redhat.com> <555BA115.5070408@redhat.com> <555CB00B.3080309@redhat.com> <5565F29B.7000507@redhat.com> Message-ID: <5565FE97.6040202@redhat.com> Martin Basti wrote: > On 20/05/15 18:02, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> 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. >> >> I must be getting rustly. Forgot to include ACIs. Added now. >> >> rob >> >> >> > Thank you. > > I haven't finished review yet, but I have few notes in case you will > modify the patch. > > Please fix following issues: > > 1) Patch needs rebase, VERSION conflict > > 2) > + pattern='^[a-zA-Z0-9_.][ a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.-]?$', > + pattern_errmsg='may only include letters, numbers, _, -, ., > and a space inside', > + maxlength=255, > > If I count correctly, regexp allows only 254 characters, not 255, and > this regexp also allows the space at the end of the string. > > IMHO '^[a-zA-Z0-9_.]([ a-zA-Z0-9_.-]*[a-zA-Z0-9_.-])?$' would work. This is a direct copy from many places. I'd file a bug to fix all of them I guess. > 3) > There are many PEP8 errors, can you fix some of them,? Is PEP8 a concern? What kinds of errors do we fix? For example, the current model for defining options generates a slew of indention errors. > 4) > Please use > except Exception as e: to be compatible with python 3 ok > > 5) > For new files we stared using shorter license header. > # > # Copyright (C) 2015 FreeIPA Contributors see COPYING for license > # ok I'll wait and see what falls out of the API review before making any real changes. rob From rcritten at redhat.com Wed May 27 17:38:35 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 27 May 2015 13:38:35 -0400 Subject: [Freeipa-devel] [PATCH] 1112 Add service constraint delegation plugin In-Reply-To: <5565FBAC.8080604@redhat.com> References: <555B4696.2070502@redhat.com> <555BA115.5070408@redhat.com> <555CB00B.3080309@redhat.com> <5565E172.9040206@redhat.com> <5565E4BD.9040209@redhat.com> <20150527154613.GS19176@redhat.com> <5565FBAC.8080604@redhat.com> Message-ID: <5566011B.7070402@redhat.com> Petr Vobornik wrote: > On 05/27/2015 05:46 PM, Alexander Bokovoy wrote: >> On Wed, 27 May 2015, Rob Crittenden wrote: >>> Petr Vobornik wrote: >>>> On 05/20/2015 06:02 PM, Rob Crittenden wrote: >>>>> Rob Crittenden wrote: >>>>>> 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. >>>>> >>>>> I must be getting rustly. Forgot to include ACIs. Added now. >>>>> >>>>> rob >>>>> >>>> >>>> Thanks for the design[1] and patches. >>>> >>>> First some high level questions before any unnecessary changes are >>>> made. >>>> >>>> From API point of view wouldn't it be better to distinguish rules and >>>> targets by object name so we could avoid usage of the --type option. >>>> I.e., why expose internal schema limitations in the API? >>>> >>>> Type could be implied by the object name and commands can do what they >>>> do now. They could even have a common base class if needed. >>>> >>>> E.g.: >>>> >>>> servicedelegationrule-add MYRULE >>>> servicedelegationrule-find >>>> servicedelegationrule-del MYRULE >>>> servicedelegationrule-add_member MYRULE --targets={MYTARGET,MYTARGET2} >>>> --principals={..,..} >>>> servicedelegationrule-remove_member MYRULE >>>> --targets={MYTARGET,MYTARGET2} --principals={..,..} >>>> >>>> servicedelegationtarget-add MYTARGET >>>> servicedelegationtarget-find >>>> servicedelegationtarget-del MYTARGET >>>> servicedelegationtarget-add_member MYTARGET --principals={..,..} >>>> servicedelegationtarget-remove_member MYTARGET --principals={..,..} >>>> >>>> Yes, I used delegation instead of constraint. What is the rationale >>>> behind 'constraint'? To me 'constraint' specifies what kind of >>>> delegation we want to set but a goal of S4U2 proxy is to allow >>>> something >>>> which is not allowed by default not to create a new constraint. >>>> >>>> [1] http://www.freeipa.org/page/V4/Service_Constraint_Delegation >>> >>> I considered that but we already have this precedent in automember so >>> I went with it. This is complex enough with the fake memberPrincipal >>> stuff, I don't want to explode it with a baseclass and two subclasses >>> as well, plus doubling the number of new API commands. > > It could tolerated in automember given that hostgroup and group rules > have exactly the same schema and purpose. The only difference is a > different target. > > On the other hand, here, the purpose of both types is different. One is > a rule, second a target. Separation of the names would tell it to the > users. > > Number of API commands is a topic for different discussion. In short, it > could be handled better in CLI and future doc. > > I don't want to discuss implementation details(complexity) yet. Issue > with API is that we are stuck with it and can't change it(much). > >>> >>> Technically this is called constrained delegation. I was trying to >>> keep the name short and still descriptive. There is already aci >>> delegation which is a completely separate thing. > > I understand that. The existing delegation might be misleading and > should be distinguished from s4u2. But imagine that somebody told you > that he created a new "service constraint rule of service A to service > B". Since there is no mention of word delegation nor S4U I wouldn't know > that it's related to ticket delegation. I would think the *opposite*. > That he constrained service A to do something with service B. But a > "service delegation rule", "constrained delegation rule" or "ticket > delegation rule" says what it is actually about. > > Rather than avoiding descriptive commands we should improve a speed bash > completion. Perhaps, but it still possible to be excessive. > > A feeble attempt to remove service from the object name: > A question: Even thought the kerberos feature is called S4U (service for > user), is it limited to service principals? Services are of course the > primary target but in theory they don't have to be, right? What is the user case for non-services? Sure, you could probably use this to allow paul to get an ldap ticket for dave, but why would you? It would be nice for delegating calendar entries for a personal assistant, for example, but would be an audit nightmare. > >> I agree with Rob. There is also a need to address principals which >> aren't directly accessible as IPA objects in the framework (think about >> trusts, for example). > > I don't think this part is affected at all. The API's have the same > capabilities. > I'm not going to argue too much about this. I imagine that a vast majority of users will never use this at all, and even then probably not more than once or twice, so adding a ton of new commands seems like major overkill to me. rob From mbasti at redhat.com Wed May 27 18:17:17 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 27 May 2015 20:17:17 +0200 Subject: [Freeipa-devel] [PATCH] 1112 Add service constraint delegation plugin In-Reply-To: <5565FE97.6040202@redhat.com> References: <555B4696.2070502@redhat.com> <555BA115.5070408@redhat.com> <555CB00B.3080309@redhat.com> <5565F29B.7000507@redhat.com> <5565FE97.6040202@redhat.com> Message-ID: <55660A2D.1080801@redhat.com> On 27/05/15 19:27, Rob Crittenden wrote: > Martin Basti wrote: >> On 20/05/15 18:02, Rob Crittenden wrote: >>> Rob Crittenden wrote: >>>> 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. >>> >>> I must be getting rustly. Forgot to include ACIs. Added now. >>> >>> rob >>> >>> >>> >> Thank you. >> >> I haven't finished review yet, but I have few notes in case you will >> modify the patch. >> >> Please fix following issues: >> >> 1) Patch needs rebase, VERSION conflict >> >> 2) >> + pattern='^[a-zA-Z0-9_.][ >> a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.-]?$', >> + pattern_errmsg='may only include letters, numbers, _, -, ., >> and a space inside', >> + maxlength=255, >> >> If I count correctly, regexp allows only 254 characters, not 255, and >> this regexp also allows the space at the end of the string. >> >> IMHO '^[a-zA-Z0-9_.]([ a-zA-Z0-9_.-]*[a-zA-Z0-9_.-])?$' would work. > > This is a direct copy from many places. I'd file a bug to fix all of > them I guess. I cannot find the same regexp in current code, there are only patterns without space, so the space issue is only in this patch. Otherwise I agree to file a ticket to fix the length issue. > >> 3) >> There are many PEP8 errors, can you fix some of them,? > > Is PEP8 a concern? What kinds of errors do we fix? For example, the > current model for defining options generates a slew of indention errors. We try to keep PEP8 in new code, mainly indentation, blank lines, too long lines. Yes in test definitions and option definitions, is better to keep the same style, but other parts of code should be PEP8. For example these should be fixed ./ipatests/test_xmlrpc/test_serviceconstraint_plugin.py:37:13: E225 missing whitespace around operator ./ipatests/test_xmlrpc/test_serviceconstraint_plugin.py:39:1: E302 expected 2 blank lines, found 1 ./ipatests/test_xmlrpc/test_serviceconstraint_plugin.py:42:1: E302 expected 2 blank lines, found 1 > >> 4) >> Please use >> except Exception as e: to be compatible with python 3 > > ok > >> >> 5) >> For new files we stared using shorter license header. >> # >> # Copyright (C) 2015 FreeIPA Contributors see COPYING for license >> # > > ok > > I'll wait and see what falls out of the API review before making any > real changes. > > rob > Martin^2 -- Martin Basti From derny at redhat.com Wed May 27 18:41:34 2015 From: derny at redhat.com (Drew Erny) Date: Wed, 27 May 2015 14:41:34 -0400 Subject: [Freeipa-devel] Sudorules user validation help Message-ID: <55660FDE.3030202@redhat.com> Hey, Freeipa-devel, I'm working on ticket #3226 (https://fedorahosted.org/freeipa/ticket/3226) I've identified the problem. The sudorules add user command adds the user validations at the end of it's pre-callback using add_external_pre_callback. However, the "user" plugin pattern-matches a string for the "uid" param, because it only allows certain characters. I've been picking through the codebase and I think I have enough understanding to ask this: What if we changed the user "uid" validation to a standalone "rule" function (you can do that, right? pass in a function as a validation rule?) that would normally just assert that the pattern matches, but could have that pattern matching validation overridden in some cases. I think that's the easiest, cleanest way to change user so that sudorules and other plugins can ignore this validation if necessary (I'm trying to figure out exactly how to implement this without changing any APIs). Am I understanding the plugin params API correctly, and can I do this? Is this the best way to do this? The only other solution I see is to write sudorules-specific code in some plugin-related (either user.py or baseldap.py module, which would create unwanted coupling. Most specifically, this would be a change to the object instantiated at ipalib/plugins/user.py line 467 Thoughts and suggestions? Thanks, Drew Erny derny at redhat.com From jcholast at redhat.com Thu May 28 05:29:17 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 28 May 2015 07:29:17 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <1432734660.3354.53.camel@redhat.com> References: <555F03DB.3090702@redhat.com> <556493D3.8010402@redhat.com> <55659335.2060306@redhat.com> <20150527095322.GM19176@redhat.com> <55659571.8070705@redhat.com> <5565AB70.7020004@redhat.com> <5565ABCF.5090305@redhat.com> <5565B10F.1090802@redhat.com> <1432734188.3243.117.camel@willson.usersys.redhat.com> <5565CAF3.9020903@redhat.com> <1432734660.3354.53.camel@redhat.com> Message-ID: <5566A7AD.6050205@redhat.com> Dne 27.5.2015 v 15:51 Nathaniel McCallum napsal(a): > On Wed, 2015-05-27 at 15:47 +0200, Jan Cholasta wrote: >> Dne 27.5.2015 v 15:43 Simo Sorce napsal(a): >>> On Wed, 2015-05-27 at 13:57 +0200, Jan Cholasta wrote: >>>>>> >>>>>> ipa config-mod --enable-kdcproxy=TRUE >>>>>> ipa config-mod --enable-kdcproxy=FALSE >>>> >>>> I don't like this approach, as it is completely inconsistent with >>>> every >>>> other optional component. There should be *one* way to handle >>>> them >>>> and >>>> there already is one, no need to reinvent the wheel. >>> >>> Sorry Jan, but this is really the correct approach. >> >> I don't think so. >> >>> >>> We want a boolean in LDAP to control whether the IPA Domain allows >>> proxying or not, the code is embedded in the overall framework and >>> has >>> no need for explicit install/uninstall unlike the CA or DNS >>> components. >> >> There is a boolean for every other component/service as well. If you >> want to add new API to manipulate the boolean, fine, but it should be >> >> done in a generic way that works for other components as well. > > As I understand the problem, there is an assumption that an optional > component has a distinct service to start and stop. That is not the > case here. This is just new config for apache. > > Nathaniel > I say that's a wrong assumption. It should not matter whether the service is provided by an actual daemon, or a set of daemons or no daemon, as that is an implementation detail. By installing KDC proxy on IPA server an actual new service is provided to the outside world, which is conceptually the same as adding DNS or CA, so I don't see why it should be handled differently. -- Jan Cholasta From jcholast at redhat.com Thu May 28 05:32:14 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 28 May 2015 07:32:14 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <5565CE55.50303@redhat.com> References: <555F03DB.3090702@redhat.com> <556493D3.8010402@redhat.com> <55659335.2060306@redhat.com> <20150527095322.GM19176@redhat.com> <55659571.8070705@redhat.com> <5565AB70.7020004@redhat.com> <5565ABCF.5090305@redhat.com> <5565B10F.1090802@redhat.com> <1432734188.3243.117.camel@willson.usersys.redhat.com> <5565CAF3.9020903@redhat.com> <1432734660.3354.53.camel@redhat.com> <5565CE55.50303@redhat.com> Message-ID: <5566A85E.1020906@redhat.com> Dne 27.5.2015 v 16:01 Christian Heimes napsal(a): > On 2015-05-27 15:51, Nathaniel McCallum wrote: >> As I understand the problem, there is an assumption that an optional >> component has a distinct service to start and stop. That is not the >> case here. This is just new config for apache. > > More details: > > The KDC Proxy uses the same Apache instance as FreeIPAs Web GUI and > Tomcat. There is no extra service involved. The switch just decides if > https://ipa.example.org/KdcProxy acts as a MS-KKDCP end point or returns > a 404 error. FYI Tomcat does not use the same Apache instance, the Apache instance is configured to proxy requests to Tomcat. If the IPA KDC proxy package is not installed on a replica, then going to /KdcProxy will return 404, right? Why is an additional switch necessary then? > > My patch "0001 Provide Kerberos over HTTP (MS-KKDCP)" has more details. > > Christian > -- Jan Cholasta From jcholast at redhat.com Thu May 28 05:42:16 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 28 May 2015 07:42:16 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <1432734868.3243.121.camel@willson.usersys.redhat.com> References: <555F03DB.3090702@redhat.com> <556493D3.8010402@redhat.com> <55659335.2060306@redhat.com> <20150527095322.GM19176@redhat.com> <55659571.8070705@redhat.com> <5565AB70.7020004@redhat.com> <5565ABCF.5090305@redhat.com> <5565B10F.1090802@redhat.com> <1432734188.3243.117.camel@willson.usersys.redhat.com> <5565CAF3.9020903@redhat.com> <1432734868.3243.121.camel@willson.usersys.redhat.com> Message-ID: <5566AAB8.2050609@redhat.com> Dne 27.5.2015 v 15:54 Simo Sorce napsal(a): > On Wed, 2015-05-27 at 15:47 +0200, Jan Cholasta wrote: >> Dne 27.5.2015 v 15:43 Simo Sorce napsal(a): >>> On Wed, 2015-05-27 at 13:57 +0200, Jan Cholasta wrote: >>>>>> >>>>>> ipa config-mod --enable-kdcproxy=TRUE >>>>>> ipa config-mod --enable-kdcproxy=FALSE >>>> >>>> I don't like this approach, as it is completely inconsistent with >>>> every >>>> other optional component. There should be *one* way to handle them >>>> and >>>> there already is one, no need to reinvent the wheel. >>> >>> Sorry Jan, but this is really the correct approach. >> >> I don't think so. >> >>> >>> We want a boolean in LDAP to control whether the IPA Domain allows >>> proxying or not, the code is embedded in the overall framework and has >>> no need for explicit install/uninstall unlike the CA or DNS components. >> >> There is a boolean for every other component/service as well. If you >> want to add new API to manipulate the boolean, fine, but it should be >> done in a generic way that works for other components as well. > > This is the same as: > ipa config-mod --enable-migration=TRUE > > Why is it a problem ? This is a switch to enable the migrate-ds plugin. I think it's hardly fair to compare it to a whole new component which provides a new service to the outside world. > This is not a separate service. How is it not a separate service? If it's installed, MS-KKDCP is provided to the outside world, and if it's not installed MS-KKDCP is not provided to the outside world. How is this different from, say, DNS? (Besides implementation details, such as what protocols or how many daemons it uses - think about IPA as a black box for a moment.) > > Simo. > -- Jan Cholasta From jcholast at redhat.com Thu May 28 05:43:49 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 28 May 2015 07:43:49 +0200 Subject: [Freeipa-devel] [PATCH] Password vault In-Reply-To: <556558AA.6040107@redhat.com> References: <54E1AF55.3060409@redhat.com> <54EBEB55.6010306@redhat.com> <54F96B22.9050507@redhat.com> <55004D5D.6060300@redhat.com> <550FE5EB.1070606@redhat.com> <551E0AE1.8040500@redhat.com> <553498D1.1020901@redhat.com> <55651209.8020000@redhat.com> <556558AA.6040107@redhat.com> Message-ID: <5566AB15.3070605@redhat.com> Dne 27.5.2015 v 07:39 Jan Cholasta napsal(a): > Dne 27.5.2015 v 02:38 Endi Sukma Dewata napsal(a): >> Please take a look at the attached patch to add vault-archive/retrieve >> commands. >> >> On 4/20/2015 1:12 AM, Jan Cholasta wrote: >>>>>>> 16) You do way too much stuff in vault_add.forward(). Only code that >>>>>>> must be done on the client needs to be there, i.e. handling of the >>>>>>> "data", "text" and "in" options. >>>>>>> >>>>>>> The vault_archive call must be in vault_add.execute(), otherwise >>>>>>> a) we >>>>>>> will be making 2 RPC calls from the client and b) it won't be >>>>>>> called at >>>>>>> all when api.env.in_server is True. >>>>>> >>>>>> This is done by design. The vault_add.forward() generates the salt >>>>>> and >>>>>> the keys. The vault_archive.forward() will encrypt the data. These >>>>>> operations have to be done on the client side to secure the >>>>>> transport of >>>>>> the data from the client through the server and finally to KRA. This >>>>>> mechanism prevents the server from looking at the unencrypted data. >>>>> >>>>> OK, but that does not justify that it's broken in server-side API. It >>>>> can and should be done so that it works the same way on both client >>>>> and >>>>> server. >>>>> >>>>> I think the best solution would be to split the command into two >>>>> commands, server-side vault_archive_raw to archive already encrypted >>>>> data, and client-side vault_archive to encrypt data and archive them >>>>> with vault_archive_raw in its .execute(). Same thing for >>>>> vault_retrieve. >>>> >>>> Actually I think it's better to just merge the add and archive, >>>> reducing >>>> the number of RPC calls. The vault_archive now will support two >>>> types of >>>> operations: >>>> >>>> (a) Archive data into a new vault (it will create the vault just before >>>> archiving the data): >>>> >>>> $ ipa vault-archive testvault --create --in data ... >>>> >>>> (b) Archive data into an existing vault: >>>> >>>> $ ipa vault-archive testvault --in data ... >>>> >>>> The vault_add is now just a wrapper for the vault_archive(a). >>> >>> If that's just an implementation detail, OK. >>> >>> If it's possible to modify existing vault objects using vault-add or >>> create new objects using vault-archive, then NACK. >> >> The vault-archive is now completely separate from vault-add. You can no >> longer archive data while creating a vault: >> >> $ ipa vault-add test >> $ ipa vault-archive test --in secret.bin > > OK. > >> >>>>> BTW, I also think it would be better if there were 2 separate sets of >>>>> commands for binary and textual data >>>>> (vault_{archive,retrieve}_{data,text}) rather than trying to handle >>>>> everything in vault_{archive,retrieve}. >>>> >>>> I don't think we want to provide a separate command of every possible >>>> data type & operation combination. Users would get confused. The >>>> archive >>>> & retrieve commands should be able to handle all current & future data >>>> types with options. >>> >>> A command with two sets of mutually exclusive options is really two >>> commands in disguise, which is a good sign it should be divided into two >>> actual commands. >>> >>> Who are you to say users would get confused? I say they would be more >>> confused by a command with a plethora of mutually exclusive "options". >>> >>> What other possible data types are there? >> >> The patch has been simplified to support only binary data. The data can >> be specified using either of these options: >> >> $ ipa vault-archive test --data >> $ ipa vault-archive test --in >> >> I don't think we want to provide two separate commands for these options >> although they are mutually exclusive, do we? > > No, these are not really 2 different options, but rather 2 forms of the > same option, which for the lack of better support for files in the > framework have to be done as 2 options. > >> >>>>>> The add & archive combination was added for convenience, not for >>>>>> optimization. This way you would be able to archive data into a new >>>>>> vault using a single command. Without this, you'd have to execute two >>>>>> separate commands: add & archive, which will result in 2 RPC calls >>>>>> anyway. >>>>> >>>>> I think I would prefer if it was separate, as that would be consistent >>>>> with other plugins (e.g. for objects with members, we don't allow >>>>> adding >>>>> members directly in -add, you have to use -add-member after -add). >>>> >>>> The vault data is similar to group description, not group members. When >>>> creating a group we can supply the description. If not specified it >>>> will >>>> be blank. Archiving vault data is similar to updating the group >>>> description. >>> >>> It's similar to group members because there are separate commands to >>> manipulate them. >> >> Just because there are separate commands doesn't mean vault data >> (single-valued) is similar to group members (multi-valued). It uses >> separate commands because of the encryption steps involved while >> archiving/retrieving data. > > That was not the point, but whatever. > >> >>> You have to choose one of: >>> >>> a) vault data is settable using vault-add and vault-mod and gettable >>> using vault-mod, vault-show and vault-find >>> >>> b) vault data is settable using vault-archive and gettable using >>> vault-retrieve >>> >>> Anything in between is not permitted. >> >> As mentioned above, the add and archive commands are now separate. >> >>>>>>> 21) vault_archive is not a retrieve operation, it should be based on >>>>>>> LDAPUpdate instead of LDAPRetrieve. Or Command actually, since it >>>>>>> does >>>>>>> not do anything with LDAP. The same applies to vault_retrieve. >>>>>> >>>>>> The vault_archive does not actually modify the LDAP entry because it >>>>>> stores the data in KRA. It is actually an LDAPRetrieve operation >>>>>> because >>>>>> it needs to get the vault info before it can perform the archival >>>>>> operation. Same thing with vault_retrieve. >>>>> >>>>> It is not a LDAPRetrieve operation, because it has different >>>>> semantics. >>>>> Please use Command as base class and either use ldap2 for direct >>>>> LDAP or >>>>> call vault_show instead of hacking around LDAPRetrieve. >>>> >>>> It's been changed to inherit from LDAPQuery instead. >>> >>> NACK, it's not a LDAPQuery operation, because it has different >>> semantics. There is more to a command than executing code, so you should >>> use a correct base class. >> >> Changed to inherit from Command as requested. Now these commands no >> longer have a direct access to the vault object (self.obj) although they >> are accessing vault objects like other vault commands. Also now the >> vault name argument has to be added explicitly on each command. > > You can inherit from crud.Retrieve and crud.Update to get self.obj and > the argument back. > >> >> There are existing commands that inherit from LDAPQuery while doing >> other things too, so the 'semantic' seems to be kind of arbitrarily >> defined and subjective. > > There is a lot of existing stuff in IPA that is bad in one way or > another, but it doesn't mean new code should be bad as well. > >> >>>>>>> 22) vault_archive will break with binary data that is not UTF-8 >>>>>>> encoded >>>>>>> text. >>>>>>> >>>>>>> This is where it occurs: >>>>>>> >>>>>>> + vault_data[u'data'] = unicode(data) >>>>>>> >>>>>>> Generally, don't use unicode() on str values and str() on unicode >>>>>>> values >>>>>>> directly, always use .decode() and .encode(). >>>> >>>> The unicode(s, encoding) is actually equivalent to s.decode(encoding), >>>> so the following code will not solve the problem: >>>> >>>> vault_data[u'data'] = data.decode() >>>> >>>> As you said, decode() will only work if the data being decoded actually >>>> follows the encoding rules (i.e. already UTF-8 encoded). >>>> >>>>>> It needs to be a Unicode because json.dumps() doesn't work with >>>>>> binary >>>>>> data. Fixed by adding base-64 encoding. >>>> >>>> The base-64 encoding is necessary to convert random binaries into ASCII >>>> so it can be decoded into Unicode. Here is the current code: >>>> >>>> vault_data[u'data'] = unicode(base64.b64encode(data)) >>>> >>>> which is equivalent to: >>>> >>>> vault_data[u'data'] = base64.b64encode(data).decode() >>> >>> If you read a little bit further, you would get to the point, which is >>> certainly not calling .decode() without arguments, but *always >>> explicitly specify the encoding*. >> >> Added the explicit encoding name although it's not necessary since the >> data being encoded/decoded is base-64 encoded (i.e. ASCII). > > It may not be necessary but it doesn't hurt either, anyway my main > concern was with the other uses of unicode() in the original patch. > >> >>>>> If something str needs to be unicode, you should use .decode() to >>>>> explicitly specify the encoding, instead of relying on unicode() to >>>>> pick >>>>> the correct one. >>>> >>>> Since we know this is ASCII data we can now specify UTF-8 encoding. >>>> >>>> vault_data[u'data'] = base64.b64encode(data).decode('utf-8') >>>> >>>> But for anything that comes from user input (e.g. filenames, >>>> passwords), >>>> it's better to use the default encoding because that can be configured >>>> by the user. >>> >>> You are confusing user's configured encoding with Python's default >>> encoding. Default encoding in Python isn't derived from user's >>> localization settings. >>> >>> Anyway, anything that comes from user input is already decoded using >>> user's configured encoding when it enters the framework so I don't know >>> why are you even bringing it up here. >> >> It's irrelevant now that the command only supports binary data. > > OK. > >> >>>>> Anyway, I think a better solution than base64 would be to use the >>>>> "raw_unicode_escape" encoding: >>>> >>>> As explained above, base-64 encoding is necessary because random >>>> binaries don't follow any encoding rules. I'd rather not use >>>> raw_unicode_escape because it's not really a text data. >>> >>> The result of decoding binary data using raw_unicode_escape is perfectly >>> valid unicode data which doesn't eat 33% more space like base64 encoded >>> binary does, hence my suggestion. >>> >>> Anyway, it turns out when encoded in JSON, raw_unicode_escape string >>> generally takes more space than base64 encoded string because of JSON >>> escaping, so base64 is indeed better. >> >> Unchanged. It still uses base-64 encoding. > > Right. > >> >>>> Here's how it's >>>> now implemented: >>>> >>>>> if data: >>>>> data = data.decode('raw_unicode_escape') >>>> >>>> Input data is already in binaries, no conversion needed. >>>> >>>>> elif text: >>>>> data = text >>>> >>>> Input text will be converted to binaries with default encoding: >>>> >>>> data = text.encode() >>> >>> See what the default encoding actually is and why you shouldn't rely on >>> it above. >> >> Irrelevant now. >> >>>>> elif input_file: >>>>> with open(input_file, 'rb') as f: >>>>> data = f.read() >>>>> data = data.decode('raw_unicode_escape') >>>> >>>> Input contains binary data, no conversion needed. >>>> >>>>> else: >>>>> data = u'' >>>> >>>> If not specified, the data will be empty string: >>>> >>>> data = '' >>>> >>>> The data needs to be converted into binaries so it can be encrypted >>>> before transport (depending on the vault type): >>>> >>>> data = self.obj.encrypt(data, ...) >>>> >>>>> vault_data[u'data'] = data >>>> >>>> Then for transport the data is base-64 encoded first, then converted >>>> into Unicode: >>>> >>>> vault_data[u'data'] = base64.b64encode(data).decode('utf-8') >> > > If KRA is not installed, vault-archive and vault-retrieve fail with > internal error. On a related note, since KRA is optional, can we move the vaults container to cn=kra,cn=vaults? This is the convetion used by the other optional components (DNS and recently CA). > > > The commands still behave differently based on whether they were called > from API which was initialized with in_server set to True or False. > > > There is no point in exposing the session_key, nonce and vault_data > options in CLI when their value is always overwritten in forward(). > > > Will this always succeed? > > + # deactivate vault record in KRA > + response = kra_client.keys.list_keys( > + client_key_id, pki.key.KeyClient.KEY_STATUS_ACTIVE) > + > + for key_info in response.key_infos: > + kra_client.keys.modify_key_status( > + key_info.get_key_id(), > + pki.key.KeyClient.KEY_STATUS_INACTIVE) > > If not, we might get into an inconsistent state, where the vault is > deleted in LDAP but still active in KRA. (I'm not sure if this is > actually a problem or not.) > -- Jan Cholasta From jcholast at redhat.com Thu May 28 05:46:19 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 28 May 2015 07:46:19 +0200 Subject: [Freeipa-devel] [PATCH] Password vault In-Reply-To: <5566AB15.3070605@redhat.com> References: <54E1AF55.3060409@redhat.com> <54EBEB55.6010306@redhat.com> <54F96B22.9050507@redhat.com> <55004D5D.6060300@redhat.com> <550FE5EB.1070606@redhat.com> <551E0AE1.8040500@redhat.com> <553498D1.1020901@redhat.com> <55651209.8020000@redhat.com> <556558AA.6040107@redhat.com> <5566AB15.3070605@redhat.com> Message-ID: <5566ABAB.7050008@redhat.com> Dne 28.5.2015 v 07:43 Jan Cholasta napsal(a): > Dne 27.5.2015 v 07:39 Jan Cholasta napsal(a): >> Dne 27.5.2015 v 02:38 Endi Sukma Dewata napsal(a): >>> Please take a look at the attached patch to add vault-archive/retrieve >>> commands. >>> >>> On 4/20/2015 1:12 AM, Jan Cholasta wrote: >>>>>>>> 16) You do way too much stuff in vault_add.forward(). Only code >>>>>>>> that >>>>>>>> must be done on the client needs to be there, i.e. handling of the >>>>>>>> "data", "text" and "in" options. >>>>>>>> >>>>>>>> The vault_archive call must be in vault_add.execute(), otherwise >>>>>>>> a) we >>>>>>>> will be making 2 RPC calls from the client and b) it won't be >>>>>>>> called at >>>>>>>> all when api.env.in_server is True. >>>>>>> >>>>>>> This is done by design. The vault_add.forward() generates the salt >>>>>>> and >>>>>>> the keys. The vault_archive.forward() will encrypt the data. These >>>>>>> operations have to be done on the client side to secure the >>>>>>> transport of >>>>>>> the data from the client through the server and finally to KRA. This >>>>>>> mechanism prevents the server from looking at the unencrypted data. >>>>>> >>>>>> OK, but that does not justify that it's broken in server-side API. It >>>>>> can and should be done so that it works the same way on both client >>>>>> and >>>>>> server. >>>>>> >>>>>> I think the best solution would be to split the command into two >>>>>> commands, server-side vault_archive_raw to archive already encrypted >>>>>> data, and client-side vault_archive to encrypt data and archive them >>>>>> with vault_archive_raw in its .execute(). Same thing for >>>>>> vault_retrieve. >>>>> >>>>> Actually I think it's better to just merge the add and archive, >>>>> reducing >>>>> the number of RPC calls. The vault_archive now will support two >>>>> types of >>>>> operations: >>>>> >>>>> (a) Archive data into a new vault (it will create the vault just >>>>> before >>>>> archiving the data): >>>>> >>>>> $ ipa vault-archive testvault --create --in data ... >>>>> >>>>> (b) Archive data into an existing vault: >>>>> >>>>> $ ipa vault-archive testvault --in data ... >>>>> >>>>> The vault_add is now just a wrapper for the vault_archive(a). >>>> >>>> If that's just an implementation detail, OK. >>>> >>>> If it's possible to modify existing vault objects using vault-add or >>>> create new objects using vault-archive, then NACK. >>> >>> The vault-archive is now completely separate from vault-add. You can no >>> longer archive data while creating a vault: >>> >>> $ ipa vault-add test >>> $ ipa vault-archive test --in secret.bin >> >> OK. >> >>> >>>>>> BTW, I also think it would be better if there were 2 separate sets of >>>>>> commands for binary and textual data >>>>>> (vault_{archive,retrieve}_{data,text}) rather than trying to handle >>>>>> everything in vault_{archive,retrieve}. >>>>> >>>>> I don't think we want to provide a separate command of every possible >>>>> data type & operation combination. Users would get confused. The >>>>> archive >>>>> & retrieve commands should be able to handle all current & future data >>>>> types with options. >>>> >>>> A command with two sets of mutually exclusive options is really two >>>> commands in disguise, which is a good sign it should be divided into >>>> two >>>> actual commands. >>>> >>>> Who are you to say users would get confused? I say they would be more >>>> confused by a command with a plethora of mutually exclusive "options". >>>> >>>> What other possible data types are there? >>> >>> The patch has been simplified to support only binary data. The data can >>> be specified using either of these options: >>> >>> $ ipa vault-archive test --data >>> $ ipa vault-archive test --in >>> >>> I don't think we want to provide two separate commands for these options >>> although they are mutually exclusive, do we? >> >> No, these are not really 2 different options, but rather 2 forms of the >> same option, which for the lack of better support for files in the >> framework have to be done as 2 options. >> >>> >>>>>>> The add & archive combination was added for convenience, not for >>>>>>> optimization. This way you would be able to archive data into a new >>>>>>> vault using a single command. Without this, you'd have to execute >>>>>>> two >>>>>>> separate commands: add & archive, which will result in 2 RPC calls >>>>>>> anyway. >>>>>> >>>>>> I think I would prefer if it was separate, as that would be >>>>>> consistent >>>>>> with other plugins (e.g. for objects with members, we don't allow >>>>>> adding >>>>>> members directly in -add, you have to use -add-member after -add). >>>>> >>>>> The vault data is similar to group description, not group members. >>>>> When >>>>> creating a group we can supply the description. If not specified it >>>>> will >>>>> be blank. Archiving vault data is similar to updating the group >>>>> description. >>>> >>>> It's similar to group members because there are separate commands to >>>> manipulate them. >>> >>> Just because there are separate commands doesn't mean vault data >>> (single-valued) is similar to group members (multi-valued). It uses >>> separate commands because of the encryption steps involved while >>> archiving/retrieving data. >> >> That was not the point, but whatever. >> >>> >>>> You have to choose one of: >>>> >>>> a) vault data is settable using vault-add and vault-mod and gettable >>>> using vault-mod, vault-show and vault-find >>>> >>>> b) vault data is settable using vault-archive and gettable using >>>> vault-retrieve >>>> >>>> Anything in between is not permitted. >>> >>> As mentioned above, the add and archive commands are now separate. >>> >>>>>>>> 21) vault_archive is not a retrieve operation, it should be >>>>>>>> based on >>>>>>>> LDAPUpdate instead of LDAPRetrieve. Or Command actually, since it >>>>>>>> does >>>>>>>> not do anything with LDAP. The same applies to vault_retrieve. >>>>>>> >>>>>>> The vault_archive does not actually modify the LDAP entry because it >>>>>>> stores the data in KRA. It is actually an LDAPRetrieve operation >>>>>>> because >>>>>>> it needs to get the vault info before it can perform the archival >>>>>>> operation. Same thing with vault_retrieve. >>>>>> >>>>>> It is not a LDAPRetrieve operation, because it has different >>>>>> semantics. >>>>>> Please use Command as base class and either use ldap2 for direct >>>>>> LDAP or >>>>>> call vault_show instead of hacking around LDAPRetrieve. >>>>> >>>>> It's been changed to inherit from LDAPQuery instead. >>>> >>>> NACK, it's not a LDAPQuery operation, because it has different >>>> semantics. There is more to a command than executing code, so you >>>> should >>>> use a correct base class. >>> >>> Changed to inherit from Command as requested. Now these commands no >>> longer have a direct access to the vault object (self.obj) although they >>> are accessing vault objects like other vault commands. Also now the >>> vault name argument has to be added explicitly on each command. >> >> You can inherit from crud.Retrieve and crud.Update to get self.obj and >> the argument back. >> >>> >>> There are existing commands that inherit from LDAPQuery while doing >>> other things too, so the 'semantic' seems to be kind of arbitrarily >>> defined and subjective. >> >> There is a lot of existing stuff in IPA that is bad in one way or >> another, but it doesn't mean new code should be bad as well. >> >>> >>>>>>>> 22) vault_archive will break with binary data that is not UTF-8 >>>>>>>> encoded >>>>>>>> text. >>>>>>>> >>>>>>>> This is where it occurs: >>>>>>>> >>>>>>>> + vault_data[u'data'] = unicode(data) >>>>>>>> >>>>>>>> Generally, don't use unicode() on str values and str() on unicode >>>>>>>> values >>>>>>>> directly, always use .decode() and .encode(). >>>>> >>>>> The unicode(s, encoding) is actually equivalent to s.decode(encoding), >>>>> so the following code will not solve the problem: >>>>> >>>>> vault_data[u'data'] = data.decode() >>>>> >>>>> As you said, decode() will only work if the data being decoded >>>>> actually >>>>> follows the encoding rules (i.e. already UTF-8 encoded). >>>>> >>>>>>> It needs to be a Unicode because json.dumps() doesn't work with >>>>>>> binary >>>>>>> data. Fixed by adding base-64 encoding. >>>>> >>>>> The base-64 encoding is necessary to convert random binaries into >>>>> ASCII >>>>> so it can be decoded into Unicode. Here is the current code: >>>>> >>>>> vault_data[u'data'] = unicode(base64.b64encode(data)) >>>>> >>>>> which is equivalent to: >>>>> >>>>> vault_data[u'data'] = base64.b64encode(data).decode() >>>> >>>> If you read a little bit further, you would get to the point, which is >>>> certainly not calling .decode() without arguments, but *always >>>> explicitly specify the encoding*. >>> >>> Added the explicit encoding name although it's not necessary since the >>> data being encoded/decoded is base-64 encoded (i.e. ASCII). >> >> It may not be necessary but it doesn't hurt either, anyway my main >> concern was with the other uses of unicode() in the original patch. >> >>> >>>>>> If something str needs to be unicode, you should use .decode() to >>>>>> explicitly specify the encoding, instead of relying on unicode() to >>>>>> pick >>>>>> the correct one. >>>>> >>>>> Since we know this is ASCII data we can now specify UTF-8 encoding. >>>>> >>>>> vault_data[u'data'] = base64.b64encode(data).decode('utf-8') >>>>> >>>>> But for anything that comes from user input (e.g. filenames, >>>>> passwords), >>>>> it's better to use the default encoding because that can be configured >>>>> by the user. >>>> >>>> You are confusing user's configured encoding with Python's default >>>> encoding. Default encoding in Python isn't derived from user's >>>> localization settings. >>>> >>>> Anyway, anything that comes from user input is already decoded using >>>> user's configured encoding when it enters the framework so I don't know >>>> why are you even bringing it up here. >>> >>> It's irrelevant now that the command only supports binary data. >> >> OK. >> >>> >>>>>> Anyway, I think a better solution than base64 would be to use the >>>>>> "raw_unicode_escape" encoding: >>>>> >>>>> As explained above, base-64 encoding is necessary because random >>>>> binaries don't follow any encoding rules. I'd rather not use >>>>> raw_unicode_escape because it's not really a text data. >>>> >>>> The result of decoding binary data using raw_unicode_escape is >>>> perfectly >>>> valid unicode data which doesn't eat 33% more space like base64 encoded >>>> binary does, hence my suggestion. >>>> >>>> Anyway, it turns out when encoded in JSON, raw_unicode_escape string >>>> generally takes more space than base64 encoded string because of JSON >>>> escaping, so base64 is indeed better. >>> >>> Unchanged. It still uses base-64 encoding. >> >> Right. >> >>> >>>>> Here's how it's >>>>> now implemented: >>>>> >>>>>> if data: >>>>>> data = data.decode('raw_unicode_escape') >>>>> >>>>> Input data is already in binaries, no conversion needed. >>>>> >>>>>> elif text: >>>>>> data = text >>>>> >>>>> Input text will be converted to binaries with default encoding: >>>>> >>>>> data = text.encode() >>>> >>>> See what the default encoding actually is and why you shouldn't rely on >>>> it above. >>> >>> Irrelevant now. >>> >>>>>> elif input_file: >>>>>> with open(input_file, 'rb') as f: >>>>>> data = f.read() >>>>>> data = data.decode('raw_unicode_escape') >>>>> >>>>> Input contains binary data, no conversion needed. >>>>> >>>>>> else: >>>>>> data = u'' >>>>> >>>>> If not specified, the data will be empty string: >>>>> >>>>> data = '' >>>>> >>>>> The data needs to be converted into binaries so it can be encrypted >>>>> before transport (depending on the vault type): >>>>> >>>>> data = self.obj.encrypt(data, ...) >>>>> >>>>>> vault_data[u'data'] = data >>>>> >>>>> Then for transport the data is base-64 encoded first, then converted >>>>> into Unicode: >>>>> >>>>> vault_data[u'data'] = base64.b64encode(data).decode('utf-8') >>> >> >> If KRA is not installed, vault-archive and vault-retrieve fail with >> internal error. > > On a related note, since KRA is optional, can we move the vaults > container to cn=kra,cn=vaults? This is the convetion used by the other > optional components (DNS and recently CA). I mean cn=vaults,cn=kra of course. > >> >> >> The commands still behave differently based on whether they were called >> from API which was initialized with in_server set to True or False. >> >> >> There is no point in exposing the session_key, nonce and vault_data >> options in CLI when their value is always overwritten in forward(). >> >> >> Will this always succeed? >> >> + # deactivate vault record in KRA >> + response = kra_client.keys.list_keys( >> + client_key_id, pki.key.KeyClient.KEY_STATUS_ACTIVE) >> + >> + for key_info in response.key_infos: >> + kra_client.keys.modify_key_status( >> + key_info.get_key_id(), >> + pki.key.KeyClient.KEY_STATUS_INACTIVE) >> >> If not, we might get into an inconsistent state, where the vault is >> deleted in LDAP but still active in KRA. (I'm not sure if this is >> actually a problem or not.) >> > > -- Jan Cholasta From jcholast at redhat.com Thu May 28 06:07:11 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 28 May 2015 08:07:11 +0200 Subject: [Freeipa-devel] [PATCH] 1112 Add service constraint delegation plugin In-Reply-To: <5566011B.7070402@redhat.com> References: <555B4696.2070502@redhat.com> <555BA115.5070408@redhat.com> <555CB00B.3080309@redhat.com> <5565E172.9040206@redhat.com> <5565E4BD.9040209@redhat.com> <20150527154613.GS19176@redhat.com> <5565FBAC.8080604@redhat.com> <5566011B.7070402@redhat.com> Message-ID: <5566B08F.1070505@redhat.com> Dne 27.5.2015 v 19:38 Rob Crittenden napsal(a): > Petr Vobornik wrote: >> On 05/27/2015 05:46 PM, Alexander Bokovoy wrote: >>> On Wed, 27 May 2015, Rob Crittenden wrote: >>>> Petr Vobornik wrote: >>>>> On 05/20/2015 06:02 PM, Rob Crittenden wrote: >>>>>> Rob Crittenden wrote: >>>>>>> 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. >>>>>> >>>>>> I must be getting rustly. Forgot to include ACIs. Added now. >>>>>> >>>>>> rob >>>>>> >>>>> >>>>> Thanks for the design[1] and patches. >>>>> >>>>> First some high level questions before any unnecessary changes are >>>>> made. >>>>> >>>>> From API point of view wouldn't it be better to distinguish rules and >>>>> targets by object name so we could avoid usage of the --type option. >>>>> I.e., why expose internal schema limitations in the API? >>>>> >>>>> Type could be implied by the object name and commands can do what they >>>>> do now. They could even have a common base class if needed. >>>>> >>>>> E.g.: >>>>> >>>>> servicedelegationrule-add MYRULE >>>>> servicedelegationrule-find >>>>> servicedelegationrule-del MYRULE >>>>> servicedelegationrule-add_member MYRULE --targets={MYTARGET,MYTARGET2} >>>>> --principals={..,..} >>>>> servicedelegationrule-remove_member MYRULE >>>>> --targets={MYTARGET,MYTARGET2} --principals={..,..} >>>>> >>>>> servicedelegationtarget-add MYTARGET >>>>> servicedelegationtarget-find >>>>> servicedelegationtarget-del MYTARGET >>>>> servicedelegationtarget-add_member MYTARGET --principals={..,..} >>>>> servicedelegationtarget-remove_member MYTARGET --principals={..,..} +1, but I would split servicedelegationrule-{add,remove}-member into separate commands: servicedelegationrule-add-member --principals= servicedelegationrule-remove-member --principals= servicedelegationrule-add-target --targets= servicedelegationrule-remove-target --targets= because one means "services which can delegate" and the other "services to which can be delegated". >>>>> >>>>> Yes, I used delegation instead of constraint. What is the rationale >>>>> behind 'constraint'? To me 'constraint' specifies what kind of >>>>> delegation we want to set but a goal of S4U2 proxy is to allow >>>>> something >>>>> which is not allowed by default not to create a new constraint. >>>>> >>>>> [1] http://www.freeipa.org/page/V4/Service_Constraint_Delegation >>>> >>>> I considered that but we already have this precedent in automember so >>>> I went with it. This is complex enough with the fake memberPrincipal >>>> stuff, I don't want to explode it with a baseclass and two subclasses >>>> as well, plus doubling the number of new API commands. >> >> It could tolerated in automember given that hostgroup and group rules >> have exactly the same schema and purpose. The only difference is a >> different target. >> >> On the other hand, here, the purpose of both types is different. One is >> a rule, second a target. Separation of the names would tell it to the >> users. +1 >> >> Number of API commands is a topic for different discussion. In short, it >> could be handled better in CLI and future doc. >> >> I don't want to discuss implementation details(complexity) yet. Issue >> with API is that we are stuck with it and can't change it(much). I very much agree. >> >>>> >>>> Technically this is called constrained delegation. I was trying to >>>> keep the name short and still descriptive. There is already aci >>>> delegation which is a completely separate thing. >> >> I understand that. The existing delegation might be misleading and >> should be distinguished from s4u2. But imagine that somebody told you >> that he created a new "service constraint rule of service A to service >> B". Since there is no mention of word delegation nor S4U I wouldn't know >> that it's related to ticket delegation. I would think the *opposite*. >> That he constrained service A to do something with service B. But a >> "service delegation rule", "constrained delegation rule" or "ticket >> delegation rule" says what it is actually about. >> >> Rather than avoiding descriptive commands we should improve a speed bash >> completion. > > Perhaps, but it still possible to be excessive. > >> >> A feeble attempt to remove service from the object name: >> A question: Even thought the kerberos feature is called S4U (service for >> user), is it limited to service principals? Services are of course the >> primary target but in theory they don't have to be, right? > > What is the user case for non-services? Sure, you could probably use > this to allow paul to get an ldap ticket for dave, but why would you? It > would be nice for delegating calendar entries for a personal assistant, > for example, but would be an audit nightmare. > >> >>> I agree with Rob. There is also a need to address principals which >>> aren't directly accessible as IPA objects in the framework (think about >>> trusts, for example). >> >> I don't think this part is affected at all. The API's have the same >> capabilities. >> > > I'm not going to argue too much about this. I imagine that a vast > majority of users will never use this at all, and even then probably not > more than once or twice, so adding a ton of new commands seems like > major overkill to me. > > rob > -- Jan Cholasta From lkrispen at redhat.com Thu May 28 06:47:43 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 28 May 2015 08:47:43 +0200 Subject: [Freeipa-devel] Domain level for topology plugin = 2 In-Reply-To: <5565A4C3.5030002@redhat.com> References: <55646331.5050807@redhat.com> <55647F90.506@redhat.com> <5564804B.6080305@redhat.com> <5564841B.4020906@redhat.com> <5565A4C3.5030002@redhat.com> Message-ID: <5566BA0F.1020400@redhat.com> On 05/27/2015 01:04 PM, Martin Kosek wrote: > On 05/26/2015 04:32 PM, Petr Spacek wrote: >> On 26.5.2015 16:16, Martin Kosek wrote: > ... >> If you really want to avoid unforeseen issues rather go and get rid of >> "major.minor" logic we have in the topology plugin right now :-) > Ludwig, I thought we agreed to avoid using major.minor format in the topology > plugin Domain Level implementation, to both avoid confusion of users and to not > ship unused code - right? The user does not see major/minor, so no confusion. All the plugin versions have the format 1.0 or alike and I converted the single integer domain level internally to compare to the plugin version > Thanks, > Martin From jcholast at redhat.com Thu May 28 06:55:57 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 28 May 2015 08:55:57 +0200 Subject: [Freeipa-devel] Domain level for topology plugin = 2 In-Reply-To: <5564841B.4020906@redhat.com> References: <55646331.5050807@redhat.com> <55647F90.506@redhat.com> <5564804B.6080305@redhat.com> <5564841B.4020906@redhat.com> Message-ID: <5566BBFD.9070601@redhat.com> Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): > On 26.5.2015 16:16, Martin Kosek wrote: >> On 05/26/2015 04:13 PM, thierry bordaz wrote: >>> On 05/26/2015 02:12 PM, Petr Spacek wrote: >>>> Hello, >>>> >>>> it came to my mind that domain level for topology plugin should actually be >>>> number 2, not 1. >>>> >>>> We already used number 1 for incompatible changes in DNS tree and I believe >>>> that it is not a good idea to have two places which say 'version 1' but and >>>> actually mean two different things. (DNS tree version 1 + domain level 1) >>>> >>>> Patch is attached. >>>> >>>> >>>> >>> Hello, >>> The fix looks good but that seems strange to have to set the initial version of >>> the topology plugin to 2.0. (IIUC That is the version that will be written in >>> dse.ldif) >>> I would rather expects that topology plugin 1.0, would activate itself if the >>> DomainLevel is 2.0 or more. >>> If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate >>> itself if DomainLevel >= DomainLevel_trigger. >>> >>> Let's wait for Ludwig feedback. >>> >>> thanks >>> thierry >> >> My personal opinion on this is to start with Domain Level 1 regardless. We >> already "solved" the DNS forwarders otherwise, with docs, async updates etc. I >> do not think we will be returning to implementing proper Domain Level support >> for that anyway. >> >> So I rather think that all the "Domain Level starts with 0, 1 is unused, 2 is >> the top one" will cause unforeseen issues I would rather like to avoid. > > I'm more worried about confusion in future. To to me it simply seems easier to > bump one integer now than to document and explain (to users & new developers) > why we have two "ones" which mean something else. > > Code-wise it is just an integer. > > Also, it can simplify logic in future when we decide to do another > incompatible change in DNS tree because we will have only one integer to test > (instead of checking two separate version attribute in DNS tree & domain level). +1, but I think the minimum supported domain level should be 1, not 0, because 0 means the server uses the old DNS schema, which we do not support anymore, right? > > If you really want to avoid unforeseen issues rather go and get rid of > "major.minor" logic we have in the topology plugin right now :-) > -- Jan Cholasta From pspacek at redhat.com Thu May 28 07:05:34 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 28 May 2015 09:05:34 +0200 Subject: [Freeipa-devel] Domain level for topology plugin = 2 In-Reply-To: <5566BBFD.9070601@redhat.com> References: <55646331.5050807@redhat.com> <55647F90.506@redhat.com> <5564804B.6080305@redhat.com> <5564841B.4020906@redhat.com> <5566BBFD.9070601@redhat.com> Message-ID: <5566BE3E.2060104@redhat.com> On 28.5.2015 08:55, Jan Cholasta wrote: > Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): >> On 26.5.2015 16:16, Martin Kosek wrote: >>> On 05/26/2015 04:13 PM, thierry bordaz wrote: >>>> On 05/26/2015 02:12 PM, Petr Spacek wrote: >>>>> Hello, >>>>> >>>>> it came to my mind that domain level for topology plugin should actually be >>>>> number 2, not 1. >>>>> >>>>> We already used number 1 for incompatible changes in DNS tree and I believe >>>>> that it is not a good idea to have two places which say 'version 1' but and >>>>> actually mean two different things. (DNS tree version 1 + domain level 1) >>>>> >>>>> Patch is attached. >>>>> >>>>> >>>>> >>>> Hello, >>>> The fix looks good but that seems strange to have to set the initial >>>> version of >>>> the topology plugin to 2.0. (IIUC That is the version that will be written in >>>> dse.ldif) >>>> I would rather expects that topology plugin 1.0, would activate itself if the >>>> DomainLevel is 2.0 or more. >>>> If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate >>>> itself if DomainLevel >= DomainLevel_trigger. >>>> >>>> Let's wait for Ludwig feedback. >>>> >>>> thanks >>>> thierry >>> >>> My personal opinion on this is to start with Domain Level 1 regardless. We >>> already "solved" the DNS forwarders otherwise, with docs, async updates etc. I >>> do not think we will be returning to implementing proper Domain Level support >>> for that anyway. >>> >>> So I rather think that all the "Domain Level starts with 0, 1 is unused, 2 is >>> the top one" will cause unforeseen issues I would rather like to avoid. >> >> I'm more worried about confusion in future. To to me it simply seems easier to >> bump one integer now than to document and explain (to users & new developers) >> why we have two "ones" which mean something else. >> >> Code-wise it is just an integer. >> >> Also, it can simplify logic in future when we decide to do another >> incompatible change in DNS tree because we will have only one integer to test >> (instead of checking two separate version attribute in DNS tree & domain >> level). > > +1, but I think the minimum supported domain level should be 1, not 0, because > 0 means the server uses the old DNS schema, which we do not support anymore, > right? Good point! -- Petr^2 Spacek From cheimes at redhat.com Thu May 28 07:45:20 2015 From: cheimes at redhat.com (Christian Heimes) Date: Thu, 28 May 2015 09:45:20 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <5566A85E.1020906@redhat.com> References: <555F03DB.3090702@redhat.com> <556493D3.8010402@redhat.com> <55659335.2060306@redhat.com> <20150527095322.GM19176@redhat.com> <55659571.8070705@redhat.com> <5565AB70.7020004@redhat.com> <5565ABCF.5090305@redhat.com> <5565B10F.1090802@redhat.com> <1432734188.3243.117.camel@willson.usersys.redhat.com> <5565CAF3.9020903@redhat.com> <1432734660.3354.53.camel@redhat.com> <5565CE55.50303@redhat.com> <5566A85E.1020906@redhat.com> Message-ID: <5566C790.5060704@redhat.com> On 2015-05-28 07:32, Jan Cholasta wrote: > Dne 27.5.2015 v 16:01 Christian Heimes napsal(a): >> On 2015-05-27 15:51, Nathaniel McCallum wrote: >>> As I understand the problem, there is an assumption that an optional >>> component has a distinct service to start and stop. That is not the >>> case here. This is just new config for apache. >> >> More details: >> >> The KDC Proxy uses the same Apache instance as FreeIPAs Web GUI and >> Tomcat. There is no extra service involved. The switch just decides if >> https://ipa.example.org/KdcProxy acts as a MS-KKDCP end point or returns >> a 404 error. > > FYI Tomcat does not use the same Apache instance, the Apache instance is > configured to proxy requests to Tomcat. > > If the IPA KDC proxy package is not installed on a replica, then going > to /KdcProxy will return 404, right? Why is an additional switch > necessary then? The python-kdcproxy package is a new dependency for the freeipa-server package. It will always get installed with the server. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From jcholast at redhat.com Thu May 28 08:02:12 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 28 May 2015 10:02:12 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <5566C790.5060704@redhat.com> References: <555F03DB.3090702@redhat.com> <556493D3.8010402@redhat.com> <55659335.2060306@redhat.com> <20150527095322.GM19176@redhat.com> <55659571.8070705@redhat.com> <5565AB70.7020004@redhat.com> <5565ABCF.5090305@redhat.com> <5565B10F.1090802@redhat.com> <1432734188.3243.117.camel@willson.usersys.redhat.com> <5565CAF3.9020903@redhat.com> <1432734660.3354.53.camel@redhat.com> <5565CE55.50303@redhat.com> <5566A85E.1020906@redhat.com> <5566C790.5060704@redhat.com> Message-ID: <5566CB84.5070601@redhat.com> Dne 28.5.2015 v 09:45 Christian Heimes napsal(a): > On 2015-05-28 07:32, Jan Cholasta wrote: >> Dne 27.5.2015 v 16:01 Christian Heimes napsal(a): >>> On 2015-05-27 15:51, Nathaniel McCallum wrote: >>>> As I understand the problem, there is an assumption that an optional >>>> component has a distinct service to start and stop. That is not the >>>> case here. This is just new config for apache. >>> >>> More details: >>> >>> The KDC Proxy uses the same Apache instance as FreeIPAs Web GUI and >>> Tomcat. There is no extra service involved. The switch just decides if >>> https://ipa.example.org/KdcProxy acts as a MS-KKDCP end point or returns >>> a 404 error. >> >> FYI Tomcat does not use the same Apache instance, the Apache instance is >> configured to proxy requests to Tomcat. >> >> If the IPA KDC proxy package is not installed on a replica, then going >> to /KdcProxy will return 404, right? Why is an additional switch >> necessary then? > > The python-kdcproxy package is a new dependency for the freeipa-server > package. It will always get installed with the server. Why? None of the IPA core functionality depends on it, so it should be optional. Also the overall trend in IPA is to have everything in subpackages. -- Jan Cholasta From ftweedal at redhat.com Thu May 28 08:13:02 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 28 May 2015 18:13:02 +1000 Subject: [Freeipa-devel] [PATCH 0014] Support multiple user and host certificates In-Reply-To: <5565ED02.6060709@redhat.com> References: <20150527135315.GC24915@dhcp-40-8.bne.redhat.com> <5565ED02.6060709@redhat.com> Message-ID: <20150528081302.GA9628@dhcp-40-8.bne.redhat.com> On Wed, May 27, 2015 at 06:12:50PM +0200, Martin Basti wrote: > On 27/05/15 15:53, Fraser Tweedale wrote: > >This patch adds supports for multiple user / host certificates. No > >schema change is needed ('usercertificate' attribute is already > >multi-value). The revoke-previous-cert behaviour of host-mod and > >user-mod has been removed but revocation behaviour of -del and > >-disable is preserved. > > > >The latest profiles/caacl patchset (0001..0013 v5) depends on this > >patch for correct cert-request behaviour. > > > >There is one design question (or maybe more, let me know): the > >`--out=FILENAME' option to {host,service} show saves ONE certificate > >to the named file. I propose to either: > > > >a) write all certs, suffixing suggested filename with either a > > sequential numerical index, e.g. "cert.pem" becomes > > "cert.pem.1", "cert.pem.2", and so on; or > > > >b) as above, but suffix with serial number and, if there are > > different issues, some issuer-identifying information. > > > >Let me know your thoughts. > > > >Thanks, > >Fraser > > > > > Is there a possible way how to store certificates into one file? > I read about possibilities to have multiple certs in one .pem file, but I'm > not cert guru :) > > I personally vote for serial number in case there are multiple certificates, > if ^ is no possible. > Actually, yeah, we can just write the PEMs to a single file, sequentially. I don't know why I didn't think of that... ?\_(?)_/? > > 1) > + if len(certs) > 0: > > please use only, > if certs: > I have strong feels about this. ``if len(certs) > 0:`` admits fewer bugs than ``if certs:`` , e.g. if 'certs' were bound to a non-length-able object by mistake. Even though we have already iterated ``certs`` at this point in the function, this failure mode is still possible, e.g. if ``certs`` is a generator. Using ``if certs:`` will not fail for a generator, but it will be a silent bug! PEP-8 is wrong on this one. It is better to use the construction that admits fewer errors. Unless it causes lint failure (on f21 it does not) I prefer not to change it. > 2) > You need to re-generate API/ACI.txt in this patch > Good pickup, thanks. > 3) > syntax error: > + for dercert in certs_der > Geez... dunno how I let that one past -_- My bad. > > 4) > command > ipa user-mod ca_user --certificate= > > removes the current certificate from the LDAP, by design. > Should be the old certificate(s) revoked? You removed that part in the code. > > only the --addattr='usercertificate=' appends new value there > Yeah... I was a bit confused about how --addattr=... interacts with options. I understand it now, and yes I think we should revoke certificates that get removed this way. cert-request will use addattr= so no existing certificates will get removed (or revoked). New patch addressing this and other points will arrive on list today. Thanks for reviewing! Fraser > -- > Martin Basti > From cheimes at redhat.com Thu May 28 08:13:33 2015 From: cheimes at redhat.com (Christian Heimes) Date: Thu, 28 May 2015 10:13:33 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <5566CB84.5070601@redhat.com> References: <555F03DB.3090702@redhat.com> <556493D3.8010402@redhat.com> <55659335.2060306@redhat.com> <20150527095322.GM19176@redhat.com> <55659571.8070705@redhat.com> <5565AB70.7020004@redhat.com> <5565ABCF.5090305@redhat.com> <5565B10F.1090802@redhat.com> <1432734188.3243.117.camel@willson.usersys.redhat.com> <5565CAF3.9020903@redhat.com> <1432734660.3354.53.camel@redhat.com> <5565CE55.50303@redhat.com> <5566A85E.1020906@redhat.com> <5566C790.5060704@redhat.com> <5566CB84.5070601@redhat.com> Message-ID: <5566CE2D.3030006@redhat.com> On 2015-05-28 10:02, Jan Cholasta wrote: >> The python-kdcproxy package is a new dependency for the freeipa-server >> package. It will always get installed with the server. > > Why? None of the IPA core functionality depends on it, so it should be > optional. Also the overall trend in IPA is to have everything in > subpackages. We discussed the idea on the internal IPA and Samba team list (KDC proxy for FreeIPA 4.2 on 2015-05-15). My initial design suggested a separate freeipa-server-kdcproxy package. Nathaniel, Nathan and Dmitri were in favor of a new dependency instead of a new subpackage. Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From pspacek at redhat.com Thu May 28 08:16:26 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 28 May 2015 10:16:26 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <5566AAB8.2050609@redhat.com> References: <555F03DB.3090702@redhat.com> <556493D3.8010402@redhat.com> <55659335.2060306@redhat.com> <20150527095322.GM19176@redhat.com> <55659571.8070705@redhat.com> <5565AB70.7020004@redhat.com> <5565ABCF.5090305@redhat.com> <5565B10F.1090802@redhat.com> <1432734188.3243.117.camel@willson.usersys.redhat.com> <5565CAF3.9020903@redhat.com> <1432734868.3243.121.camel@willson.usersys.redhat.com> <5566AAB8.2050609@redhat.com> Message-ID: <5566CEDA.5010701@redhat.com> On 28.5.2015 07:42, Jan Cholasta wrote: > Dne 27.5.2015 v 15:54 Simo Sorce napsal(a): >> On Wed, 2015-05-27 at 15:47 +0200, Jan Cholasta wrote: >>> Dne 27.5.2015 v 15:43 Simo Sorce napsal(a): >>>> On Wed, 2015-05-27 at 13:57 +0200, Jan Cholasta wrote: >>>>>>> >>>>>>> ipa config-mod --enable-kdcproxy=TRUE >>>>>>> ipa config-mod --enable-kdcproxy=FALSE >>>>> >>>>> I don't like this approach, as it is completely inconsistent with >>>>> every >>>>> other optional component. There should be *one* way to handle them >>>>> and >>>>> there already is one, no need to reinvent the wheel. >>>> >>>> Sorry Jan, but this is really the correct approach. >>> >>> I don't think so. >>> >>>> >>>> We want a boolean in LDAP to control whether the IPA Domain allows >>>> proxying or not, the code is embedded in the overall framework and has >>>> no need for explicit install/uninstall unlike the CA or DNS components. >>> >>> There is a boolean for every other component/service as well. If you >>> want to add new API to manipulate the boolean, fine, but it should be >>> done in a generic way that works for other components as well. >> >> This is the same as: >> ipa config-mod --enable-migration=TRUE >> >> Why is it a problem ? > > This is a switch to enable the migrate-ds plugin. I think it's hardly fair to > compare it to a whole new component which provides a new service to the > outside world. > >> This is not a separate service. > > How is it not a separate service? If it's installed, MS-KKDCP is provided to > the outside world, and if it's not installed MS-KKDCP is not provided to the > outside world. How is this different from, say, DNS? (Besides implementation > details, such as what protocols or how many daemons it uses - think about IPA > as a black box for a moment.) I very much agree with Honza - we have per-replica boolean for every service so there is no reason not to have one for kdc proxy, especially when we consider future containerization of services. -- Petr^2 Spacek From mkosek at redhat.com Thu May 28 08:17:39 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 May 2015 10:17:39 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <5566CB84.5070601@redhat.com> References: <555F03DB.3090702@redhat.com> <556493D3.8010402@redhat.com> <55659335.2060306@redhat.com> <20150527095322.GM19176@redhat.com> <55659571.8070705@redhat.com> <5565AB70.7020004@redhat.com> <5565ABCF.5090305@redhat.com> <5565B10F.1090802@redhat.com> <1432734188.3243.117.camel@willson.usersys.redhat.com> <5565CAF3.9020903@redhat.com> <1432734660.3354.53.camel@redhat.com> <5565CE55.50303@redhat.com> <5566A85E.1020906@redhat.com> <5566C790.5060704@redhat.com> <5566CB84.5070601@redhat.com> Message-ID: <5566CF23.90502@redhat.com> On 05/28/2015 10:02 AM, Jan Cholasta wrote: > Dne 28.5.2015 v 09:45 Christian Heimes napsal(a): >> On 2015-05-28 07:32, Jan Cholasta wrote: >>> Dne 27.5.2015 v 16:01 Christian Heimes napsal(a): >>>> On 2015-05-27 15:51, Nathaniel McCallum wrote: >>>>> As I understand the problem, there is an assumption that an optional >>>>> component has a distinct service to start and stop. That is not the >>>>> case here. This is just new config for apache. >>>> >>>> More details: >>>> >>>> The KDC Proxy uses the same Apache instance as FreeIPAs Web GUI and >>>> Tomcat. There is no extra service involved. The switch just decides if >>>> https://ipa.example.org/KdcProxy acts as a MS-KKDCP end point or returns >>>> a 404 error. >>> >>> FYI Tomcat does not use the same Apache instance, the Apache instance is >>> configured to proxy requests to Tomcat. >>> >>> If the IPA KDC proxy package is not installed on a replica, then going >>> to /KdcProxy will return 404, right? Why is an additional switch >>> necessary then? >> >> The python-kdcproxy package is a new dependency for the freeipa-server >> package. It will always get installed with the server. > > Why? None of the IPA core functionality depends on it, so it should be > optional. Also the overall trend in IPA is to have everything in subpackages. Do not look at it as a separate component. It is mostly just a new transport for Kerberos. FreeIPA already provides Kerberos via TCP and UDP. This is a third transport - HTTP. From mkosek at redhat.com Thu May 28 08:19:01 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 May 2015 10:19:01 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <5566A7AD.6050205@redhat.com> References: <555F03DB.3090702@redhat.com> <556493D3.8010402@redhat.com> <55659335.2060306@redhat.com> <20150527095322.GM19176@redhat.com> <55659571.8070705@redhat.com> <5565AB70.7020004@redhat.com> <5565ABCF.5090305@redhat.com> <5565B10F.1090802@redhat.com> <1432734188.3243.117.camel@willson.usersys.redhat.com> <5565CAF3.9020903@redhat.com> <1432734660.3354.53.camel@redhat.com> <5566A7AD.6050205@redhat.com> Message-ID: <5566CF75.1090701@redhat.com> On 05/28/2015 07:29 AM, Jan Cholasta wrote: > Dne 27.5.2015 v 15:51 Nathaniel McCallum napsal(a): >> On Wed, 2015-05-27 at 15:47 +0200, Jan Cholasta wrote: >>> Dne 27.5.2015 v 15:43 Simo Sorce napsal(a): >>>> On Wed, 2015-05-27 at 13:57 +0200, Jan Cholasta wrote: >>>>>>> >>>>>>> ipa config-mod --enable-kdcproxy=TRUE >>>>>>> ipa config-mod --enable-kdcproxy=FALSE >>>>> >>>>> I don't like this approach, as it is completely inconsistent with >>>>> every >>>>> other optional component. There should be *one* way to handle >>>>> them >>>>> and >>>>> there already is one, no need to reinvent the wheel. >>>> >>>> Sorry Jan, but this is really the correct approach. >>> >>> I don't think so. >>> >>>> >>>> We want a boolean in LDAP to control whether the IPA Domain allows >>>> proxying or not, the code is embedded in the overall framework and >>>> has >>>> no need for explicit install/uninstall unlike the CA or DNS >>>> components. >>> >>> There is a boolean for every other component/service as well. If you >>> want to add new API to manipulate the boolean, fine, but it should be >>> >>> done in a generic way that works for other components as well. >> >> As I understand the problem, there is an assumption that an optional >> component has a distinct service to start and stop. That is not the >> case here. This is just new config for apache. >> >> Nathaniel >> > > I say that's a wrong assumption. It should not matter whether the service is > provided by an actual daemon, or a set of daemons or no daemon, as that is an > implementation detail. By installing KDC proxy on IPA server an actual new > service is provided to the outside world, which is conceptually the same as > adding DNS or CA, so I don't see why it should be handled differently. It is not another new service, like DNS or CA. It is another transport for Kerberos, on top of TCP/UDP. Can we please stop bikeshedding here? From mkosek at redhat.com Thu May 28 08:22:46 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 May 2015 10:22:46 +0200 Subject: [Freeipa-devel] New replica installation and topology - we need stable base In-Reply-To: <5565DD42.4020604@redhat.com> References: <5565DBB7.1030304@redhat.com> <5565DD42.4020604@redhat.com> Message-ID: <5566D056.1090702@redhat.com> On 05/27/2015 05:05 PM, Oleg Fayans wrote: > > > On 05/27/2015 04:59 PM, Martin Kosek wrote: >> Hello all, >> >> As FreeIPA 4.2 deadlines are approaching us slowly, there is a concern that not >> all of the new replica install way (replication-package-less) based on Custodia >> would be done and finished in time. >> >> There will be certainly a lot of integration hurdles, in making sure that the >> installed replica can ask for all needed secrets and that the server can >> provide them and ensure proper encryption. >> >> My question is - if we postpone new replica promotion way&Custodia, what is >> needed to make FreeIPA 4.2 replica installation and topology management >> GA-ready and finished? >> >> This is the status of related functions, as I see it: >> >> Domain Levels >> - Done, committed >> - Defaults to Level 1, i.e. Topology plugin powered infra enabled >> >> Topology plugin >> - We have the base plugin and it's installation pushed >> - There is a critical bug that needs to be solved - #5035 > Which actually blocks the testing of the feature. Once it is resolved, > we need several days to properly test the plugin. I anticipate at least > a week, if there will be no other blockers. This does not include WebUI > part of the plugin. Right. I would suggest this bug to be now the top priority for Ludwig. >> - API&UI is in works (Petr Vobornik). We already committed the new server-* >> commands used there. Overall, AFAIU the API should be mostly functionally complete >> - Plugin is enabled during installation, but we still use the simple auth with >> DM password during replica creation process. I think we planned to use GSSAPI, >> no? Is anything else needed in the replica creation process, except fixing #5035? >> >> Given this summary, if we forget about the Custodia parts for a moment, it >> seems to me that the new Topology is almost functionally complete and we only >> miss the management API. Is that correct or we miss some bigger piece? >> >> I am for example not sure if the "IPA masters" hostgroup is needed for Topology >> work without Custodia, I think Ludwig used some other group for authorization >> purposes in Topology. >> >> Thanks. >> > From pvoborni at redhat.com Thu May 28 08:26:03 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 28 May 2015 10:26:03 +0200 Subject: [Freeipa-devel] [PATCH] 1112 Add service constraint delegation plugin In-Reply-To: <55660A2D.1080801@redhat.com> References: <555B4696.2070502@redhat.com> <555BA115.5070408@redhat.com> <555CB00B.3080309@redhat.com> <5565F29B.7000507@redhat.com> <5565FE97.6040202@redhat.com> <55660A2D.1080801@redhat.com> Message-ID: <5566D11B.3070505@redhat.com> On 05/27/2015 08:17 PM, Martin Basti wrote: > On 27/05/15 19:27, Rob Crittenden wrote: >> Martin Basti wrote: >>>> >>> Thank you. >>> >>> I haven't finished review yet, but I have few notes in case you will >>> modify the patch. >>> >>> Please fix following issues: >>> >> >>> 3) >>> There are many PEP8 errors, can you fix some of them,? >> >> Is PEP8 a concern? What kinds of errors do we fix? For example, the >> current model for defining options generates a slew of indention errors. In old modules it's preferred to keep the old indentation style for options(not to mix 2 styles). New modules should use following pep8 compliant style: Str( 'cn', cli_name='name', primary_key=True, label=_('Server name'), doc=_('IPA server hostname'), ), > We try to keep PEP8 in new code, mainly indentation, blank lines, too > long lines. > Yes in test definitions and option definitions, is better to keep the > same style, but other parts of code should be PEP8. > > For example these should be fixed > ./ipatests/test_xmlrpc/test_serviceconstraint_plugin.py:37:13: E225 > missing whitespace around operator > ./ipatests/test_xmlrpc/test_serviceconstraint_plugin.py:39:1: E302 > expected 2 blank lines, found 1 > ./ipatests/test_xmlrpc/test_serviceconstraint_plugin.py:42:1: E302 > expected 2 blank lines, found 1 > >> >> >> I'll wait and see what falls out of the API review before making any >> real changes. >> >> rob >> > > Martin^2 > -- Petr Vobornik From mbasti at redhat.com Thu May 28 08:40:22 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 28 May 2015 10:40:22 +0200 Subject: [Freeipa-devel] [PATCH 0014] Support multiple user and host certificates In-Reply-To: <20150528081302.GA9628@dhcp-40-8.bne.redhat.com> References: <20150527135315.GC24915@dhcp-40-8.bne.redhat.com> <5565ED02.6060709@redhat.com> <20150528081302.GA9628@dhcp-40-8.bne.redhat.com> Message-ID: <5566D476.2050908@redhat.com> On 28/05/15 10:13, Fraser Tweedale wrote: > On Wed, May 27, 2015 at 06:12:50PM +0200, Martin Basti wrote: >> On 27/05/15 15:53, Fraser Tweedale wrote: >>> This patch adds supports for multiple user / host certificates. No >>> schema change is needed ('usercertificate' attribute is already >>> multi-value). The revoke-previous-cert behaviour of host-mod and >>> user-mod has been removed but revocation behaviour of -del and >>> -disable is preserved. >>> >>> The latest profiles/caacl patchset (0001..0013 v5) depends on this >>> patch for correct cert-request behaviour. >>> >>> There is one design question (or maybe more, let me know): the >>> `--out=FILENAME' option to {host,service} show saves ONE certificate >>> to the named file. I propose to either: >>> >>> a) write all certs, suffixing suggested filename with either a >>> sequential numerical index, e.g. "cert.pem" becomes >>> "cert.pem.1", "cert.pem.2", and so on; or >>> >>> b) as above, but suffix with serial number and, if there are >>> different issues, some issuer-identifying information. >>> >>> Let me know your thoughts. >>> >>> Thanks, >>> Fraser >>> >>> >> Is there a possible way how to store certificates into one file? >> I read about possibilities to have multiple certs in one .pem file, but I'm >> not cert guru :) >> >> I personally vote for serial number in case there are multiple certificates, >> if ^ is no possible. >> > Actually, yeah, we can just write the PEMs to a single file, > sequentially. I don't know why I didn't think of that... ?\_(?)_/? > >> 1) >> + if len(certs) > 0: >> >> please use only, >> if certs: >> > I have strong feels about this. ``if len(certs) > 0:`` admits fewer > bugs than ``if certs:`` , e.g. if 'certs' were bound to a > non-length-able object by mistake. Even though we have already > iterated ``certs`` at this point in the function, this failure mode > is still possible, e.g. if ``certs`` is a generator. Using ``if > certs:`` will not fail for a generator, but it will be a silent bug! > > PEP-8 is wrong on this one. It is better to use the construction > that admits fewer errors. Unless it causes lint failure (on f21 it > does not) I prefer not to change it. I still think it should be in PEP8 style. We should avoid these mistakes, not create the code which will detect it. And, I forgot to write, please use except Exception as e: instead except Exception, e to be compatible with python3 >> 2) >> You need to re-generate API/ACI.txt in this patch >> > Good pickup, thanks. > >> 3) >> syntax error: >> + for dercert in certs_der >> > Geez... dunno how I let that one past -_- My bad. > >> 4) >> command >> ipa user-mod ca_user --certificate= >> >> removes the current certificate from the LDAP, by design. >> Should be the old certificate(s) revoked? You removed that part in the code. >> >> only the --addattr='usercertificate=' appends new value there >> > Yeah... I was a bit confused about how --addattr=... interacts with > options. I understand it now, and yes I think we should revoke > certificates that get removed this way. > > cert-request will use addattr= so no existing certificates will get > removed (or revoked). New patch addressing this and other points > will arrive on list today. > > Thanks for reviewing! > Fraser > >> -- >> Martin Basti >> -- Martin Basti From mkosek at redhat.com Thu May 28 08:44:07 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 May 2015 10:44:07 +0200 Subject: [Freeipa-devel] Sudorules user validation help In-Reply-To: <55660FDE.3030202@redhat.com> References: <55660FDE.3030202@redhat.com> Message-ID: <5566D557.9030503@redhat.com> On 05/27/2015 08:41 PM, Drew Erny wrote: > Hey, Freeipa-devel, > > I'm working on ticket #3226 (https://fedorahosted.org/freeipa/ticket/3226) > > I've identified the problem. The sudorules add user command adds the user > validations at the end of it's pre-callback using add_external_pre_callback. > However, the "user" plugin pattern-matches a string for the "uid" param, > because it only allows certain characters. > > I've been picking through the codebase and I think I have enough understanding > to ask this: What if we changed the user "uid" validation to a standalone > "rule" function (you can do that, right? pass in a function as a validation > rule?) that would normally just assert that the pattern matches, but could have > that pattern matching validation overridden in some cases. I think that's the > easiest, cleanest way to change user so that sudorules and other plugins can > ignore this validation if necessary (I'm trying to figure out exactly how to > implement this without changing any APIs). > > Am I understanding the plugin params API correctly, and can I do this? Is this > the best way to do this? > > The only other solution I see is to write sudorules-specific code in some > plugin-related (either user.py or baseldap.py module, which would create > unwanted coupling. > > Most specifically, this would be a change to the object instantiated at > ipalib/plugins/user.py line 467 > > Thoughts and suggestions? I think it would make sense to follow the example with validate_hostname and prepare a function validate_username(username, upn=False, netbios_name=False) [1]. where upn would allow using "@." on top of current validator (i.e. user at Domain.test) and netbios_name would allow the "DOMAIN\user" style. I would just suggest making sure the standard user validation error message is still the same to avoid unnecessary QE fail positives. In add_external_pre_callback you could then just simply call validate_username(user, True, True) just like it is already done with hostname. My 2 cents. Martin [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa380525(v=vs.85).aspx From mkosek at redhat.com Thu May 28 08:46:52 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 May 2015 10:46:52 +0200 Subject: [Freeipa-devel] [PATCH 0014] Support multiple user and host certificates In-Reply-To: <5565ED02.6060709@redhat.com> References: <20150527135315.GC24915@dhcp-40-8.bne.redhat.com> <5565ED02.6060709@redhat.com> Message-ID: <5566D5FC.7090307@redhat.com> On 05/27/2015 06:12 PM, Martin Basti wrote: > On 27/05/15 15:53, Fraser Tweedale wrote: >> This patch adds supports for multiple user / host certificates. No >> schema change is needed ('usercertificate' attribute is already >> multi-value). The revoke-previous-cert behaviour of host-mod and >> user-mod has been removed but revocation behaviour of -del and >> -disable is preserved. >> >> The latest profiles/caacl patchset (0001..0013 v5) depends on this >> patch for correct cert-request behaviour. >> >> There is one design question (or maybe more, let me know): the >> `--out=FILENAME' option to {host,service} show saves ONE certificate >> to the named file. I propose to either: >> >> a) write all certs, suffixing suggested filename with either a >> sequential numerical index, e.g. "cert.pem" becomes >> "cert.pem.1", "cert.pem.2", and so on; or >> >> b) as above, but suffix with serial number and, if there are >> different issues, some issuer-identifying information. >> >> Let me know your thoughts. >> >> Thanks, >> Fraser >> >> > Is there a possible way how to store certificates into one file? > I read about possibilities to have multiple certs in one .pem file, but I'm not > cert guru :) > > I personally vote for serial number in case there are multiple certificates, if > ^ is no possible. > > > 1) > + if len(certs) > 0: > > please use only, > if certs: > > 2) > You need to re-generate API/ACI.txt in this patch > > 3) > syntax error: > + for dercert in certs_der > > > 4) > command > ipa user-mod ca_user --certificate= > > removes the current certificate from the LDAP, by design. > Should be the old certificate(s) revoked? You removed that part in the code. Good question. I think the suggestion was to have a global switch in IPA global config that would configure the policy - whether the certificates removed by this command or by host-del or host-disable are revoked or if they are just removed (my motivation is to avoid behavior regression in case somebody depended on this behavior). > > only the --addattr='usercertificate=' appends new value there > > > From mkosek at redhat.com Thu May 28 08:49:08 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 May 2015 10:49:08 +0200 Subject: [Freeipa-devel] Domain level for topology plugin = 2 In-Reply-To: <5566BE3E.2060104@redhat.com> References: <55646331.5050807@redhat.com> <55647F90.506@redhat.com> <5564804B.6080305@redhat.com> <5564841B.4020906@redhat.com> <5566BBFD.9070601@redhat.com> <5566BE3E.2060104@redhat.com> Message-ID: <5566D684.6080505@redhat.com> On 05/28/2015 09:05 AM, Petr Spacek wrote: > On 28.5.2015 08:55, Jan Cholasta wrote: >> Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): >>> On 26.5.2015 16:16, Martin Kosek wrote: >>>> On 05/26/2015 04:13 PM, thierry bordaz wrote: >>>>> On 05/26/2015 02:12 PM, Petr Spacek wrote: >>>>>> Hello, >>>>>> >>>>>> it came to my mind that domain level for topology plugin should actually be >>>>>> number 2, not 1. >>>>>> >>>>>> We already used number 1 for incompatible changes in DNS tree and I believe >>>>>> that it is not a good idea to have two places which say 'version 1' but and >>>>>> actually mean two different things. (DNS tree version 1 + domain level 1) >>>>>> >>>>>> Patch is attached. >>>>>> >>>>>> >>>>>> >>>>> Hello, >>>>> The fix looks good but that seems strange to have to set the initial >>>>> version of >>>>> the topology plugin to 2.0. (IIUC That is the version that will be written in >>>>> dse.ldif) >>>>> I would rather expects that topology plugin 1.0, would activate itself if the >>>>> DomainLevel is 2.0 or more. >>>>> If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate >>>>> itself if DomainLevel >= DomainLevel_trigger. >>>>> >>>>> Let's wait for Ludwig feedback. >>>>> >>>>> thanks >>>>> thierry >>>> >>>> My personal opinion on this is to start with Domain Level 1 regardless. We >>>> already "solved" the DNS forwarders otherwise, with docs, async updates etc. I >>>> do not think we will be returning to implementing proper Domain Level support >>>> for that anyway. >>>> >>>> So I rather think that all the "Domain Level starts with 0, 1 is unused, 2 is >>>> the top one" will cause unforeseen issues I would rather like to avoid. >>> >>> I'm more worried about confusion in future. To to me it simply seems easier to >>> bump one integer now than to document and explain (to users & new developers) >>> why we have two "ones" which mean something else. >>> >>> Code-wise it is just an integer. >>> >>> Also, it can simplify logic in future when we decide to do another >>> incompatible change in DNS tree because we will have only one integer to test >>> (instead of checking two separate version attribute in DNS tree & domain >>> level). >> >> +1, but I think the minimum supported domain level should be 1, not 0, because >> 0 means the server uses the old DNS schema, which we do not support anymore, >> right? > > Good point! > It may be a good point, but it does not make the situation easier. You still have RHEL/CentOS 6.x IPA out there, where some of them already support the new DNS forwarders and some don't - and neither of them support Domain Levels - i.e. have Domain Level 0. As I said, I still see more complications with this proposals than benefits... From abokovoy at redhat.com Thu May 28 09:12:25 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 28 May 2015 12:12:25 +0300 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <5566CEDA.5010701@redhat.com> References: <20150527095322.GM19176@redhat.com> <55659571.8070705@redhat.com> <5565AB70.7020004@redhat.com> <5565ABCF.5090305@redhat.com> <5565B10F.1090802@redhat.com> <1432734188.3243.117.camel@willson.usersys.redhat.com> <5565CAF3.9020903@redhat.com> <1432734868.3243.121.camel@willson.usersys.redhat.com> <5566AAB8.2050609@redhat.com> <5566CEDA.5010701@redhat.com> Message-ID: <20150528091225.GZ19176@redhat.com> On Thu, 28 May 2015, Petr Spacek wrote: >On 28.5.2015 07:42, Jan Cholasta wrote: >> Dne 27.5.2015 v 15:54 Simo Sorce napsal(a): >>> On Wed, 2015-05-27 at 15:47 +0200, Jan Cholasta wrote: >>>> Dne 27.5.2015 v 15:43 Simo Sorce napsal(a): >>>>> On Wed, 2015-05-27 at 13:57 +0200, Jan Cholasta wrote: >>>>>>>> >>>>>>>> ipa config-mod --enable-kdcproxy=TRUE >>>>>>>> ipa config-mod --enable-kdcproxy=FALSE >>>>>> >>>>>> I don't like this approach, as it is completely inconsistent with >>>>>> every >>>>>> other optional component. There should be *one* way to handle them >>>>>> and >>>>>> there already is one, no need to reinvent the wheel. >>>>> >>>>> Sorry Jan, but this is really the correct approach. >>>> >>>> I don't think so. >>>> >>>>> >>>>> We want a boolean in LDAP to control whether the IPA Domain allows >>>>> proxying or not, the code is embedded in the overall framework and has >>>>> no need for explicit install/uninstall unlike the CA or DNS components. >>>> >>>> There is a boolean for every other component/service as well. If you >>>> want to add new API to manipulate the boolean, fine, but it should be >>>> done in a generic way that works for other components as well. >>> >>> This is the same as: >>> ipa config-mod --enable-migration=TRUE >>> >>> Why is it a problem ? >> >> This is a switch to enable the migrate-ds plugin. I think it's hardly fair to >> compare it to a whole new component which provides a new service to the >> outside world. >> >>> This is not a separate service. >> >> How is it not a separate service? If it's installed, MS-KKDCP is provided to >> the outside world, and if it's not installed MS-KKDCP is not provided to the >> outside world. How is this different from, say, DNS? (Besides implementation >> details, such as what protocols or how many daemons it uses - think about IPA >> as a black box for a moment.) > >I very much agree with Honza - we have per-replica boolean for every service >so there is no reason not to have one for kdc proxy, especially when we >consider future containerization of services. A mere 'me too' here. Note that once updates to RFC 4120 as outlined in https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-00 would be accepted, clients will not be assuming all of replicas serve MS-KKDCP proxies so there will not be need to run them everywhere. Rather, only the servers on a network boundary will need to be advertised. This means we'll eventually get per-replica need as well. It is fine to assume right now that all of them are going to run MS-KKDCP proxy but configuration isn't really going to be global. Additionally, ipa-kdcproxy-manage would need to manipulate _kerberos.$DOMAIN URI DNS records too, so there is more than just switching the boolean here. -- / Alexander Bokovoy From abokovoy at redhat.com Thu May 28 09:14:10 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 28 May 2015 12:14:10 +0300 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <5566CF23.90502@redhat.com> References: <5565ABCF.5090305@redhat.com> <5565B10F.1090802@redhat.com> <1432734188.3243.117.camel@willson.usersys.redhat.com> <5565CAF3.9020903@redhat.com> <1432734660.3354.53.camel@redhat.com> <5565CE55.50303@redhat.com> <5566A85E.1020906@redhat.com> <5566C790.5060704@redhat.com> <5566CB84.5070601@redhat.com> <5566CF23.90502@redhat.com> Message-ID: <20150528091410.GA19176@redhat.com> On Thu, 28 May 2015, Martin Kosek wrote: >On 05/28/2015 10:02 AM, Jan Cholasta wrote: >> Dne 28.5.2015 v 09:45 Christian Heimes napsal(a): >>> On 2015-05-28 07:32, Jan Cholasta wrote: >>>> Dne 27.5.2015 v 16:01 Christian Heimes napsal(a): >>>>> On 2015-05-27 15:51, Nathaniel McCallum wrote: >>>>>> As I understand the problem, there is an assumption that an optional >>>>>> component has a distinct service to start and stop. That is not the >>>>>> case here. This is just new config for apache. >>>>> >>>>> More details: >>>>> >>>>> The KDC Proxy uses the same Apache instance as FreeIPAs Web GUI and >>>>> Tomcat. There is no extra service involved. The switch just decides if >>>>> https://ipa.example.org/KdcProxy acts as a MS-KKDCP end point or returns >>>>> a 404 error. >>>> >>>> FYI Tomcat does not use the same Apache instance, the Apache instance is >>>> configured to proxy requests to Tomcat. >>>> >>>> If the IPA KDC proxy package is not installed on a replica, then going >>>> to /KdcProxy will return 404, right? Why is an additional switch >>>> necessary then? >>> >>> The python-kdcproxy package is a new dependency for the freeipa-server >>> package. It will always get installed with the server. >> >> Why? None of the IPA core functionality depends on it, so it should be >> optional. Also the overall trend in IPA is to have everything in subpackages. > >Do not look at it as a separate component. It is mostly just a new transport >for Kerberos. FreeIPA already provides Kerberos via TCP and UDP. This is a >third transport - HTTP. See my other response. With changes in https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-00 we'll need to manage _kerberos.$DOMAIN URI DNS record (not just TXT one like now) to explicitly report where the proxies are located. This goes beyond just global switch in LDAP and requires ipa-kdcproxy-manage tool. -- / Alexander Bokovoy From mbasti at redhat.com Thu May 28 09:17:17 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 28 May 2015 11:17:17 +0200 Subject: [Freeipa-devel] [PATCH 0014] Support multiple user and host certificates In-Reply-To: <5566D5FC.7090307@redhat.com> References: <20150527135315.GC24915@dhcp-40-8.bne.redhat.com> <5565ED02.6060709@redhat.com> <5566D5FC.7090307@redhat.com> Message-ID: <5566DD1D.7040009@redhat.com> On 28/05/15 10:46, Martin Kosek wrote: > On 05/27/2015 06:12 PM, Martin Basti wrote: >> On 27/05/15 15:53, Fraser Tweedale wrote: >>> This patch adds supports for multiple user / host certificates. No >>> schema change is needed ('usercertificate' attribute is already >>> multi-value). The revoke-previous-cert behaviour of host-mod and >>> user-mod has been removed but revocation behaviour of -del and >>> -disable is preserved. >>> >>> The latest profiles/caacl patchset (0001..0013 v5) depends on this >>> patch for correct cert-request behaviour. >>> >>> There is one design question (or maybe more, let me know): the >>> `--out=FILENAME' option to {host,service} show saves ONE certificate >>> to the named file. I propose to either: >>> >>> a) write all certs, suffixing suggested filename with either a >>> sequential numerical index, e.g. "cert.pem" becomes >>> "cert.pem.1", "cert.pem.2", and so on; or >>> >>> b) as above, but suffix with serial number and, if there are >>> different issues, some issuer-identifying information. >>> >>> Let me know your thoughts. >>> >>> Thanks, >>> Fraser >>> >>> >> Is there a possible way how to store certificates into one file? >> I read about possibilities to have multiple certs in one .pem file, but I'm not >> cert guru :) >> >> I personally vote for serial number in case there are multiple certificates, if >> ^ is no possible. >> >> >> 1) >> + if len(certs) > 0: >> >> please use only, >> if certs: >> >> 2) >> You need to re-generate API/ACI.txt in this patch >> >> 3) >> syntax error: >> + for dercert in certs_der >> >> >> 4) >> command >> ipa user-mod ca_user --certificate= >> >> removes the current certificate from the LDAP, by design. >> Should be the old certificate(s) revoked? You removed that part in the code. > Good question. I think the suggestion was to have a global switch in IPA global > config that would configure the policy - whether the certificates removed by > this command or by host-del or host-disable are revoked or if they are just > removed (my motivation is to avoid behavior regression in case somebody > depended on this behavior). I would prefer to keep the current behavior: revoke the certificate if it was replaced or removed, instead of adding an extra configuration option. This behavior is not regression. >> only the --addattr='usercertificate=' appends new value there >> >> >> -- Martin Basti From ftweedal at redhat.com Thu May 28 09:17:41 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 28 May 2015 19:17:41 +1000 Subject: [Freeipa-devel] [PATCH 0014] Support multiple user and host certificates In-Reply-To: <5566D476.2050908@redhat.com> References: <20150527135315.GC24915@dhcp-40-8.bne.redhat.com> <5565ED02.6060709@redhat.com> <20150528081302.GA9628@dhcp-40-8.bne.redhat.com> <5566D476.2050908@redhat.com> Message-ID: <20150528091741.GC9628@dhcp-40-8.bne.redhat.com> On Thu, May 28, 2015 at 10:40:22AM +0200, Martin Basti wrote: > On 28/05/15 10:13, Fraser Tweedale wrote: > >On Wed, May 27, 2015 at 06:12:50PM +0200, Martin Basti wrote: > >>On 27/05/15 15:53, Fraser Tweedale wrote: > >>>This patch adds supports for multiple user / host certificates. No > >>>schema change is needed ('usercertificate' attribute is already > >>>multi-value). The revoke-previous-cert behaviour of host-mod and > >>>user-mod has been removed but revocation behaviour of -del and > >>>-disable is preserved. > >>> > >>>The latest profiles/caacl patchset (0001..0013 v5) depends on this > >>>patch for correct cert-request behaviour. > >>> > >>>There is one design question (or maybe more, let me know): the > >>>`--out=FILENAME' option to {host,service} show saves ONE certificate > >>>to the named file. I propose to either: > >>> > >>>a) write all certs, suffixing suggested filename with either a > >>> sequential numerical index, e.g. "cert.pem" becomes > >>> "cert.pem.1", "cert.pem.2", and so on; or > >>> > >>>b) as above, but suffix with serial number and, if there are > >>> different issues, some issuer-identifying information. > >>> > >>>Let me know your thoughts. > >>> > >>>Thanks, > >>>Fraser > >>> > >>> > >>Is there a possible way how to store certificates into one file? > >>I read about possibilities to have multiple certs in one .pem file, but I'm > >>not cert guru :) > >> > >>I personally vote for serial number in case there are multiple certificates, > >>if ^ is no possible. > >> > >Actually, yeah, we can just write the PEMs to a single file, > >sequentially. I don't know why I didn't think of that... ?\_(?)_/? > > > >>1) > >>+ if len(certs) > 0: > >> > >>please use only, > >>if certs: > >> > >I have strong feels about this. ``if len(certs) > 0:`` admits fewer > >bugs than ``if certs:`` , e.g. if 'certs' were bound to a > >non-length-able object by mistake. Even though we have already > >iterated ``certs`` at this point in the function, this failure mode > >is still possible, e.g. if ``certs`` is a generator. Using ``if > >certs:`` will not fail for a generator, but it will be a silent bug! > > > >PEP-8 is wrong on this one. It is better to use the construction > >that admits fewer errors. Unless it causes lint failure (on f21 it > >does not) I prefer not to change it. > I still think it should be in PEP8 style. > > We should avoid these mistakes, not create the code which will detect it. > How do you know if you made a mistake? This is not just about me making this change now. If someone in the future comes along and for whatever reasons changes the list to a generator, the diff in isolation may look like a good change, and the reviewer might not notice that the change leads to undesired behaviour elsewhere (outside the diff context). If you have good test coverage, tests might catch the bug. If not, hopefully QE notices the incorrect behaviour before a customer does. The best tool is a type system so you don't get a program if you make a mistake like this. Well, Python doesn't give us that tool but let us not ignore what it *can* do to help us for the sake of adhereing to PEP-8 or saving a few characters. > And, I forgot to write, please use > except Exception as e: instead except Exception, e > to be compatible with python3 > Sure, no problem. > >>2) > >>You need to re-generate API/ACI.txt in this patch > >> > >Good pickup, thanks. > > > >>3) > >>syntax error: > >>+ for dercert in certs_der > >> > >Geez... dunno how I let that one past -_- My bad. > > > >>4) > >>command > >>ipa user-mod ca_user --certificate= > >> > >>removes the current certificate from the LDAP, by design. > >>Should be the old certificate(s) revoked? You removed that part in the code. > >> > >>only the --addattr='usercertificate=' appends new value there > >> > >Yeah... I was a bit confused about how --addattr=... interacts with > >options. I understand it now, and yes I think we should revoke > >certificates that get removed this way. > > > >cert-request will use addattr= so no existing certificates will get > >removed (or revoked). New patch addressing this and other points > >will arrive on list today. > > > >Thanks for reviewing! > >Fraser > > > >>-- > >>Martin Basti > >> > > > -- > Martin Basti > From mbasti at redhat.com Thu May 28 09:48:52 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 28 May 2015 11:48:52 +0200 Subject: [Freeipa-devel] [PATCHES 0001-0013 v5] Profiles and CA ACLs In-Reply-To: <20150527140434.GD24915@dhcp-40-8.bne.redhat.com> References: <555AF9E1.1010606@redhat.com> <20150519115027.GA12806@dhcp-40-8.bne.redhat.com> <555C1E5C.2080707@redhat.com> <20150520055636.GF12806@dhcp-40-8.bne.redhat.com> <555C30FE.4030707@redhat.com> <20150520144106.GH12806@dhcp-40-8.bne.redhat.com> <555DCC96.2050001@redhat.com> <555DD031.8070302@redhat.com> <555DD39C.3070103@redhat.com> <20150526155930.GI13469@dhcp-40-8.bne.redhat.com> <20150527140434.GD24915@dhcp-40-8.bne.redhat.com> Message-ID: <5566E484.7080809@redhat.com> 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 at 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 -- Martin Basti From mkosek at redhat.com Thu May 28 09:52:25 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 May 2015 11:52:25 +0200 Subject: [Freeipa-devel] [PATCH 0014] Support multiple user and host certificates In-Reply-To: <5566DD1D.7040009@redhat.com> References: <20150527135315.GC24915@dhcp-40-8.bne.redhat.com> <5565ED02.6060709@redhat.com> <5566D5FC.7090307@redhat.com> <5566DD1D.7040009@redhat.com> Message-ID: <5566E559.8020709@redhat.com> On 05/28/2015 11:17 AM, Martin Basti wrote: > On 28/05/15 10:46, Martin Kosek wrote: >> On 05/27/2015 06:12 PM, Martin Basti wrote: >>> On 27/05/15 15:53, Fraser Tweedale wrote: >>>> This patch adds supports for multiple user / host certificates. No >>>> schema change is needed ('usercertificate' attribute is already >>>> multi-value). The revoke-previous-cert behaviour of host-mod and >>>> user-mod has been removed but revocation behaviour of -del and >>>> -disable is preserved. >>>> >>>> The latest profiles/caacl patchset (0001..0013 v5) depends on this >>>> patch for correct cert-request behaviour. >>>> >>>> There is one design question (or maybe more, let me know): the >>>> `--out=FILENAME' option to {host,service} show saves ONE certificate >>>> to the named file. I propose to either: >>>> >>>> a) write all certs, suffixing suggested filename with either a >>>> sequential numerical index, e.g. "cert.pem" becomes >>>> "cert.pem.1", "cert.pem.2", and so on; or >>>> >>>> b) as above, but suffix with serial number and, if there are >>>> different issues, some issuer-identifying information. >>>> >>>> Let me know your thoughts. >>>> >>>> Thanks, >>>> Fraser >>>> >>>> >>> Is there a possible way how to store certificates into one file? >>> I read about possibilities to have multiple certs in one .pem file, but I'm not >>> cert guru :) >>> >>> I personally vote for serial number in case there are multiple certificates, if >>> ^ is no possible. >>> >>> >>> 1) >>> + if len(certs) > 0: >>> >>> please use only, >>> if certs: >>> >>> 2) >>> You need to re-generate API/ACI.txt in this patch >>> >>> 3) >>> syntax error: >>> + for dercert in certs_der >>> >>> >>> 4) >>> command >>> ipa user-mod ca_user --certificate= >>> >>> removes the current certificate from the LDAP, by design. >>> Should be the old certificate(s) revoked? You removed that part in the code. >> Good question. I think the suggestion was to have a global switch in IPA global >> config that would configure the policy - whether the certificates removed by >> this command or by host-del or host-disable are revoked or if they are just >> removed (my motivation is to avoid behavior regression in case somebody >> depended on this behavior). > I would prefer to keep the current behavior: revoke the certificate if it was > replaced or removed, instead of adding an extra configuration option. > This behavior is not regression. It is not. However, it is not an ideal behavior also. In FreeIPA 4.2, we are now adding support of certificate profiles, multiple certificates and even certificates for user. With that change, there may be much more certificates in play than now. If we keep revoking all such certificates, it may cause rapid growth of CRLs. This is something I am trying to avoid with this proposal and default to not revoking certificates automatically (which mostly only makes sense if there is a risk that the key is compromised), but have some option to keep the old behavior. Does this make sense? From mbasti at redhat.com Thu May 28 09:58:19 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 28 May 2015 11:58:19 +0200 Subject: [Freeipa-devel] [PATCH 0014] Support multiple user and host certificates In-Reply-To: <20150528091741.GC9628@dhcp-40-8.bne.redhat.com> References: <20150527135315.GC24915@dhcp-40-8.bne.redhat.com> <5565ED02.6060709@redhat.com> <20150528081302.GA9628@dhcp-40-8.bne.redhat.com> <5566D476.2050908@redhat.com> <20150528091741.GC9628@dhcp-40-8.bne.redhat.com> Message-ID: <5566E6BB.2080006@redhat.com> On 28/05/15 11:17, Fraser Tweedale wrote: > On Thu, May 28, 2015 at 10:40:22AM +0200, Martin Basti wrote: >> On 28/05/15 10:13, Fraser Tweedale wrote: >>> On Wed, May 27, 2015 at 06:12:50PM +0200, Martin Basti wrote: >>>> On 27/05/15 15:53, Fraser Tweedale wrote: >>>>> This patch adds supports for multiple user / host certificates. No >>>>> schema change is needed ('usercertificate' attribute is already >>>>> multi-value). The revoke-previous-cert behaviour of host-mod and >>>>> user-mod has been removed but revocation behaviour of -del and >>>>> -disable is preserved. >>>>> >>>>> The latest profiles/caacl patchset (0001..0013 v5) depends on this >>>>> patch for correct cert-request behaviour. >>>>> >>>>> There is one design question (or maybe more, let me know): the >>>>> `--out=FILENAME' option to {host,service} show saves ONE certificate >>>>> to the named file. I propose to either: >>>>> >>>>> a) write all certs, suffixing suggested filename with either a >>>>> sequential numerical index, e.g. "cert.pem" becomes >>>>> "cert.pem.1", "cert.pem.2", and so on; or >>>>> >>>>> b) as above, but suffix with serial number and, if there are >>>>> different issues, some issuer-identifying information. >>>>> >>>>> Let me know your thoughts. >>>>> >>>>> Thanks, >>>>> Fraser >>>>> >>>>> >>>> Is there a possible way how to store certificates into one file? >>>> I read about possibilities to have multiple certs in one .pem file, but I'm >>>> not cert guru :) >>>> >>>> I personally vote for serial number in case there are multiple certificates, >>>> if ^ is no possible. >>>> >>> Actually, yeah, we can just write the PEMs to a single file, >>> sequentially. I don't know why I didn't think of that... ?\_(?)_/? >>> >>>> 1) >>>> + if len(certs) > 0: >>>> >>>> please use only, >>>> if certs: >>>> >>> I have strong feels about this. ``if len(certs) > 0:`` admits fewer >>> bugs than ``if certs:`` , e.g. if 'certs' were bound to a >>> non-length-able object by mistake. Even though we have already >>> iterated ``certs`` at this point in the function, this failure mode >>> is still possible, e.g. if ``certs`` is a generator. Using ``if >>> certs:`` will not fail for a generator, but it will be a silent bug! >>> >>> PEP-8 is wrong on this one. It is better to use the construction >>> that admits fewer errors. Unless it causes lint failure (on f21 it >>> does not) I prefer not to change it. >> I still think it should be in PEP8 style. >> >> We should avoid these mistakes, not create the code which will detect it. >> > How do you know if you made a mistake? This is not just about me > making this change now. If someone in the future comes along and > for whatever reasons changes the list to a generator, the diff in > isolation may look like a good change, and the reviewer might not > notice that the change leads to undesired behaviour elsewhere > (outside the diff context). > > If you have good test coverage, tests might catch the bug. If not, > hopefully QE notices the incorrect behaviour before a customer does. > The best tool is a type system so you don't get a program if you > make a mistake like this. Well, Python doesn't give us that tool > but let us not ignore what it *can* do to help us for the sake of > adhereing to PEP-8 or saving a few characters. Ok then, leave there len() > 0 but to catch these kind of mistakes, we should have asserts everywhere to verify type. > >> And, I forgot to write, please use >> except Exception as e: instead except Exception, e >> to be compatible with python3 >> > Sure, no problem. > >>>> 2) >>>> You need to re-generate API/ACI.txt in this patch >>>> >>> Good pickup, thanks. >>> >>>> 3) >>>> syntax error: >>>> + for dercert in certs_der >>>> >>> Geez... dunno how I let that one past -_- My bad. >>> >>>> 4) >>>> command >>>> ipa user-mod ca_user --certificate= >>>> >>>> removes the current certificate from the LDAP, by design. >>>> Should be the old certificate(s) revoked? You removed that part in the code. >>>> >>>> only the --addattr='usercertificate=' appends new value there >>>> >>> Yeah... I was a bit confused about how --addattr=... interacts with >>> options. I understand it now, and yes I think we should revoke >>> certificates that get removed this way. >>> >>> cert-request will use addattr= so no existing certificates will get >>> removed (or revoked). New patch addressing this and other points >>> will arrive on list today. >>> >>> Thanks for reviewing! >>> Fraser >>> >>>> -- >>>> Martin Basti >>>> >> >> -- >> Martin Basti >> -- Martin Basti From mkosek at redhat.com Thu May 28 09:59:49 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 May 2015 11:59:49 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <20150528091225.GZ19176@redhat.com> References: <20150527095322.GM19176@redhat.com> <55659571.8070705@redhat.com> <5565AB70.7020004@redhat.com> <5565ABCF.5090305@redhat.com> <5565B10F.1090802@redhat.com> <1432734188.3243.117.camel@willson.usersys.redhat.com> <5565CAF3.9020903@redhat.com> <1432734868.3243.121.camel@willson.usersys.redhat.com> <5566AAB8.2050609@redhat.com> <5566CEDA.5010701@redhat.com> <20150528091225.GZ19176@redhat.com> Message-ID: <5566E715.1060307@redhat.com> On 05/28/2015 11:12 AM, Alexander Bokovoy wrote: > On Thu, 28 May 2015, Petr Spacek wrote: >> On 28.5.2015 07:42, Jan Cholasta wrote: >>> Dne 27.5.2015 v 15:54 Simo Sorce napsal(a): >>>> On Wed, 2015-05-27 at 15:47 +0200, Jan Cholasta wrote: >>>>> Dne 27.5.2015 v 15:43 Simo Sorce napsal(a): >>>>>> On Wed, 2015-05-27 at 13:57 +0200, Jan Cholasta wrote: >>>>>>>>> >>>>>>>>> ipa config-mod --enable-kdcproxy=TRUE >>>>>>>>> ipa config-mod --enable-kdcproxy=FALSE >>>>>>> >>>>>>> I don't like this approach, as it is completely inconsistent with >>>>>>> every >>>>>>> other optional component. There should be *one* way to handle them >>>>>>> and >>>>>>> there already is one, no need to reinvent the wheel. >>>>>> >>>>>> Sorry Jan, but this is really the correct approach. >>>>> >>>>> I don't think so. >>>>> >>>>>> >>>>>> We want a boolean in LDAP to control whether the IPA Domain allows >>>>>> proxying or not, the code is embedded in the overall framework and has >>>>>> no need for explicit install/uninstall unlike the CA or DNS components. >>>>> >>>>> There is a boolean for every other component/service as well. If you >>>>> want to add new API to manipulate the boolean, fine, but it should be >>>>> done in a generic way that works for other components as well. >>>> >>>> This is the same as: >>>> ipa config-mod --enable-migration=TRUE >>>> >>>> Why is it a problem ? >>> >>> This is a switch to enable the migrate-ds plugin. I think it's hardly fair to >>> compare it to a whole new component which provides a new service to the >>> outside world. >>> >>>> This is not a separate service. >>> >>> How is it not a separate service? If it's installed, MS-KKDCP is provided to >>> the outside world, and if it's not installed MS-KKDCP is not provided to the >>> outside world. How is this different from, say, DNS? (Besides implementation >>> details, such as what protocols or how many daemons it uses - think about IPA >>> as a black box for a moment.) >> >> I very much agree with Honza - we have per-replica boolean for every service >> so there is no reason not to have one for kdc proxy, especially when we >> consider future containerization of services. > A mere 'me too' here. Note that once updates to RFC 4120 as outlined in > https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-00 > would be accepted, clients will not be assuming all of replicas serve > MS-KKDCP proxies so there will not be need to run them everywhere. > Rather, only the servers on a network boundary will need to be > advertised. This means we'll eventually get per-replica need as well. > > It is fine to assume right now that all of them are going to run > MS-KKDCP proxy but configuration isn't really going to be global. > > Additionally, ipa-kdcproxy-manage would need to manipulate > _kerberos.$DOMAIN URI DNS records too, so there is more than just > switching the boolean here. I see. My question is - if we go this way, what is then the reasonable subset configuration functionality realistic for FreeIPA 4.2 GA? (As we want this feature in for 4.2). Is ipa-kdcproxy-manage doable? What is the proposed API here? ipa-kdcproxy-manage list ipa-kdcproxy-manage enable ipa-kdcproxy-manage disable ? From ftweedal at redhat.com Thu May 28 10:06:16 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 28 May 2015 20:06:16 +1000 Subject: [Freeipa-devel] [PATCH 0014] Support multiple user and host certificates In-Reply-To: <5566E559.8020709@redhat.com> References: <20150527135315.GC24915@dhcp-40-8.bne.redhat.com> <5565ED02.6060709@redhat.com> <5566D5FC.7090307@redhat.com> <5566DD1D.7040009@redhat.com> <5566E559.8020709@redhat.com> Message-ID: <20150528100615.GD9628@dhcp-40-8.bne.redhat.com> On Thu, May 28, 2015 at 11:52:25AM +0200, Martin Kosek wrote: > On 05/28/2015 11:17 AM, Martin Basti wrote: > > On 28/05/15 10:46, Martin Kosek wrote: > >> On 05/27/2015 06:12 PM, Martin Basti wrote: > >>> On 27/05/15 15:53, Fraser Tweedale wrote: > >>>> This patch adds supports for multiple user / host certificates. No > >>>> schema change is needed ('usercertificate' attribute is already > >>>> multi-value). The revoke-previous-cert behaviour of host-mod and > >>>> user-mod has been removed but revocation behaviour of -del and > >>>> -disable is preserved. > >>>> > >>>> The latest profiles/caacl patchset (0001..0013 v5) depends on this > >>>> patch for correct cert-request behaviour. > >>>> > >>>> There is one design question (or maybe more, let me know): the > >>>> `--out=FILENAME' option to {host,service} show saves ONE certificate > >>>> to the named file. I propose to either: > >>>> > >>>> a) write all certs, suffixing suggested filename with either a > >>>> sequential numerical index, e.g. "cert.pem" becomes > >>>> "cert.pem.1", "cert.pem.2", and so on; or > >>>> > >>>> b) as above, but suffix with serial number and, if there are > >>>> different issues, some issuer-identifying information. > >>>> > >>>> Let me know your thoughts. > >>>> > >>>> Thanks, > >>>> Fraser > >>>> > >>>> > >>> Is there a possible way how to store certificates into one file? > >>> I read about possibilities to have multiple certs in one .pem file, but I'm not > >>> cert guru :) > >>> > >>> I personally vote for serial number in case there are multiple certificates, if > >>> ^ is no possible. > >>> > >>> > >>> 1) > >>> + if len(certs) > 0: > >>> > >>> please use only, > >>> if certs: > >>> > >>> 2) > >>> You need to re-generate API/ACI.txt in this patch > >>> > >>> 3) > >>> syntax error: > >>> + for dercert in certs_der > >>> > >>> > >>> 4) > >>> command > >>> ipa user-mod ca_user --certificate= > >>> > >>> removes the current certificate from the LDAP, by design. > >>> Should be the old certificate(s) revoked? You removed that part in the code. > >> Good question. I think the suggestion was to have a global switch in IPA global > >> config that would configure the policy - whether the certificates removed by > >> this command or by host-del or host-disable are revoked or if they are just > >> removed (my motivation is to avoid behavior regression in case somebody > >> depended on this behavior). > > I would prefer to keep the current behavior: revoke the certificate if it was > > replaced or removed, instead of adding an extra configuration option. > > This behavior is not regression. > > It is not. However, it is not an ideal behavior also. In FreeIPA 4.2, we are > now adding support of certificate profiles, multiple certificates and even > certificates for user. > > With that change, there may be much more certificates in play than now. If we > keep revoking all such certificates, it may cause rapid growth of CRLs. This is > something I am trying to avoid with this proposal and default to not revoking > certificates automatically (which mostly only makes sense if there is a risk > that the key is compromised), but have some option to keep the old behavior. > > Does this make sense? > It does make senes. In regards to *this* patch, I will make -mod behave the same as -del and -disable; i.e. the current behaviour i.e. revoke whenever we "forget" a certificate. Any config knobs, command options, etc to govern whether to revoke shall be added in a subsequent patch. Cheers, Fraser From pspacek at redhat.com Thu May 28 10:10:41 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 28 May 2015 12:10:41 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <5566E715.1060307@redhat.com> References: <20150527095322.GM19176@redhat.com> <55659571.8070705@redhat.com> <5565AB70.7020004@redhat.com> <5565ABCF.5090305@redhat.com> <5565B10F.1090802@redhat.com> <1432734188.3243.117.camel@willson.usersys.redhat.com> <5565CAF3.9020903@redhat.com> <1432734868.3243.121.camel@willson.usersys.redhat.com> <5566AAB8.2050609@redhat.com> <5566CEDA.5010701@redhat.com> <20150528091225.GZ19176@redhat.com> <5566E715.1060307@redhat.com> Message-ID: <5566E9A1.70108@redhat.com> On 28.5.2015 11:59, Martin Kosek wrote: > On 05/28/2015 11:12 AM, Alexander Bokovoy wrote: >> On Thu, 28 May 2015, Petr Spacek wrote: >>> On 28.5.2015 07:42, Jan Cholasta wrote: >>>> Dne 27.5.2015 v 15:54 Simo Sorce napsal(a): >>>>> On Wed, 2015-05-27 at 15:47 +0200, Jan Cholasta wrote: >>>>>> Dne 27.5.2015 v 15:43 Simo Sorce napsal(a): >>>>>>> On Wed, 2015-05-27 at 13:57 +0200, Jan Cholasta wrote: >>>>>>>>>> >>>>>>>>>> ipa config-mod --enable-kdcproxy=TRUE >>>>>>>>>> ipa config-mod --enable-kdcproxy=FALSE >>>>>>>> >>>>>>>> I don't like this approach, as it is completely inconsistent with >>>>>>>> every >>>>>>>> other optional component. There should be *one* way to handle them >>>>>>>> and >>>>>>>> there already is one, no need to reinvent the wheel. >>>>>>> >>>>>>> Sorry Jan, but this is really the correct approach. >>>>>> >>>>>> I don't think so. >>>>>> >>>>>>> >>>>>>> We want a boolean in LDAP to control whether the IPA Domain allows >>>>>>> proxying or not, the code is embedded in the overall framework and has >>>>>>> no need for explicit install/uninstall unlike the CA or DNS components. >>>>>> >>>>>> There is a boolean for every other component/service as well. If you >>>>>> want to add new API to manipulate the boolean, fine, but it should be >>>>>> done in a generic way that works for other components as well. >>>>> >>>>> This is the same as: >>>>> ipa config-mod --enable-migration=TRUE >>>>> >>>>> Why is it a problem ? >>>> >>>> This is a switch to enable the migrate-ds plugin. I think it's hardly fair to >>>> compare it to a whole new component which provides a new service to the >>>> outside world. >>>> >>>>> This is not a separate service. >>>> >>>> How is it not a separate service? If it's installed, MS-KKDCP is provided to >>>> the outside world, and if it's not installed MS-KKDCP is not provided to the >>>> outside world. How is this different from, say, DNS? (Besides implementation >>>> details, such as what protocols or how many daemons it uses - think about IPA >>>> as a black box for a moment.) >>> >>> I very much agree with Honza - we have per-replica boolean for every service >>> so there is no reason not to have one for kdc proxy, especially when we >>> consider future containerization of services. >> A mere 'me too' here. Note that once updates to RFC 4120 as outlined in >> https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-00 >> would be accepted, clients will not be assuming all of replicas serve >> MS-KKDCP proxies so there will not be need to run them everywhere. >> Rather, only the servers on a network boundary will need to be >> advertised. This means we'll eventually get per-replica need as well. >> >> It is fine to assume right now that all of them are going to run >> MS-KKDCP proxy but configuration isn't really going to be global. >> >> Additionally, ipa-kdcproxy-manage would need to manipulate >> _kerberos.$DOMAIN URI DNS records too, so there is more than just >> switching the boolean here. > > I see. My question is - if we go this way, what is then the reasonable subset > configuration functionality realistic for FreeIPA 4.2 GA? (As we want this > feature in for 4.2). Is ipa-kdcproxy-manage doable? > > What is the proposed API here? > > ipa-kdcproxy-manage list > ipa-kdcproxy-manage enable > ipa-kdcproxy-manage disable I believe that for 4.2 it is perfectly enough to have per-replica switch in LDAP (enabled by default) and to provide ldapmodify command in docs. User interface can be polished later if we get the design right. -- Petr^2 Spacek From cheimes at redhat.com Thu May 28 10:17:23 2015 From: cheimes at redhat.com (Christian Heimes) Date: Thu, 28 May 2015 12:17:23 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <5566E9A1.70108@redhat.com> References: <20150527095322.GM19176@redhat.com> <55659571.8070705@redhat.com> <5565AB70.7020004@redhat.com> <5565ABCF.5090305@redhat.com> <5565B10F.1090802@redhat.com> <1432734188.3243.117.camel@willson.usersys.redhat.com> <5565CAF3.9020903@redhat.com> <1432734868.3243.121.camel@willson.usersys.redhat.com> <5566AAB8.2050609@redhat.com> <5566CEDA.5010701@redhat.com> <20150528091225.GZ19176@redhat.com> <5566E715.1060307@redhat.com> <5566E9A1.70108@redhat.com> Message-ID: <5566EB33.1050209@redhat.com> On 2015-05-28 12:10, Petr Spacek wrote: >> I see. My question is - if we go this way, what is then the reasonable subset >> configuration functionality realistic for FreeIPA 4.2 GA? (As we want this >> feature in for 4.2). Is ipa-kdcproxy-manage doable? >> >> What is the proposed API here? >> >> ipa-kdcproxy-manage list >> ipa-kdcproxy-manage enable >> ipa-kdcproxy-manage disable > > I believe that for 4.2 it is perfectly enough to have per-replica switch in > LDAP (enabled by default) and to provide ldapmodify command in docs. User > interface can be polished later if we get the design right. For Petr proposal to work we only need an additional ACI and maybe an additional permission. I'm using Apache's keytab for LDAP bin. The principal has no permission to read or search ipaConfigString attributes in the cn=masters tree. A ipa-kdcproxy-manage is more work. I'd have to write the script and implement a HTTP interface to reload all settings. Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From abokovoy at redhat.com Thu May 28 10:27:36 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 28 May 2015 13:27:36 +0300 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <5566EB33.1050209@redhat.com> References: <5565B10F.1090802@redhat.com> <1432734188.3243.117.camel@willson.usersys.redhat.com> <5565CAF3.9020903@redhat.com> <1432734868.3243.121.camel@willson.usersys.redhat.com> <5566AAB8.2050609@redhat.com> <5566CEDA.5010701@redhat.com> <20150528091225.GZ19176@redhat.com> <5566E715.1060307@redhat.com> <5566E9A1.70108@redhat.com> <5566EB33.1050209@redhat.com> Message-ID: <20150528102736.GB19176@redhat.com> On Thu, 28 May 2015, Christian Heimes wrote: >On 2015-05-28 12:10, Petr Spacek wrote: >>> I see. My question is - if we go this way, what is then the reasonable subset >>> configuration functionality realistic for FreeIPA 4.2 GA? (As we want this >>> feature in for 4.2). Is ipa-kdcproxy-manage doable? >>> >>> What is the proposed API here? >>> >>> ipa-kdcproxy-manage list >>> ipa-kdcproxy-manage enable >>> ipa-kdcproxy-manage disable >> >> I believe that for 4.2 it is perfectly enough to have per-replica switch in >> LDAP (enabled by default) and to provide ldapmodify command in docs. User >> interface can be polished later if we get the design right. > >For Petr proposal to work we only need an additional ACI and maybe an >additional permission. I'm using Apache's keytab for LDAP bin. The >principal has no permission to read or search ipaConfigString attributes >in the cn=masters tree. > >A ipa-kdcproxy-manage is more work. I'd have to write the script and >implement a HTTP interface to reload all settings. I'm fine with that for 4.2. We can always add an example of enable/disable via ipa-ldap-updater tool which should be simplest one for admins as it includes template values for domain and IPA master hosts. See https://vda.li/en/posts/2015/01/02/playing-with-freeipa-ipa-ldap-updater/ for examples, this one would be similar to how weak enctypes are enabled: # 20-kdcproxy-enable-on-this-master.update dn: cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX add:ipaConfigString:enabledService # 20-kdcproxy-disable-on-this-master.update dn: cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX remove:ipaConfigString:enabledService -- / Alexander Bokovoy From pvoborni at redhat.com Thu May 28 10:37:10 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 28 May 2015 12:37:10 +0200 Subject: [Freeipa-devel] [PATCHES 0001-0013 v5] Profiles and CA ACLs In-Reply-To: <5566E484.7080809@redhat.com> References: <555AF9E1.1010606@redhat.com> <20150519115027.GA12806@dhcp-40-8.bne.redhat.com> <555C1E5C.2080707@redhat.com> <20150520055636.GF12806@dhcp-40-8.bne.redhat.com> <555C30FE.4030707@redhat.com> <20150520144106.GH12806@dhcp-40-8.bne.redhat.com> <555DCC96.2050001@redhat.com> <555DD031.8070302@redhat.com> <555DD39C.3070103@redhat.com> <20150526155930.GI13469@dhcp-40-8.bne.redhat.com> <20150527140434.GD24915@dhcp-40-8.bne.redhat.com> <5566E484.7080809@redhat.com> Message-ID: <5566EFD6.6090703@redhat.com> On 05/28/2015 11:48 AM, 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. >> I've added it to mkosek/freeipa-master The build was successful on f22 but failed on f21. Should it be successful on f21? https://copr.fedoraproject.org/coprs/mkosek/freeipa-master/build/94540/ -- Petr Vobornik From mkosek at redhat.com Thu May 28 10:46:25 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 May 2015 12:46:25 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <20150528102736.GB19176@redhat.com> References: <5565B10F.1090802@redhat.com> <1432734188.3243.117.camel@willson.usersys.redhat.com> <5565CAF3.9020903@redhat.com> <1432734868.3243.121.camel@willson.usersys.redhat.com> <5566AAB8.2050609@redhat.com> <5566CEDA.5010701@redhat.com> <20150528091225.GZ19176@redhat.com> <5566E715.1060307@redhat.com> <5566E9A1.70108@redhat.com> <5566EB33.1050209@redhat.com> <20150528102736.GB19176@redhat.com> Message-ID: <5566F201.1070008@redhat.com> On 05/28/2015 12:27 PM, Alexander Bokovoy wrote: > On Thu, 28 May 2015, Christian Heimes wrote: >> On 2015-05-28 12:10, Petr Spacek wrote: >>>> I see. My question is - if we go this way, what is then the reasonable subset >>>> configuration functionality realistic for FreeIPA 4.2 GA? (As we want this >>>> feature in for 4.2). Is ipa-kdcproxy-manage doable? >>>> >>>> What is the proposed API here? >>>> >>>> ipa-kdcproxy-manage list >>>> ipa-kdcproxy-manage enable >>>> ipa-kdcproxy-manage disable >>> >>> I believe that for 4.2 it is perfectly enough to have per-replica switch in >>> LDAP (enabled by default) and to provide ldapmodify command in docs. User >>> interface can be polished later if we get the design right. >> >> For Petr proposal to work we only need an additional ACI and maybe an >> additional permission. I'm using Apache's keytab for LDAP bin. The >> principal has no permission to read or search ipaConfigString attributes >> in the cn=masters tree. >> >> A ipa-kdcproxy-manage is more work. I'd have to write the script and >> implement a HTTP interface to reload all settings. > I'm fine with that for 4.2. We can always add an example of > enable/disable via ipa-ldap-updater tool which should be simplest one > for admins as it includes template values for domain and IPA master > hosts. See > https://vda.li/en/posts/2015/01/02/playing-with-freeipa-ipa-ldap-updater/ for > examples, this one would be similar to how weak enctypes are enabled: > > # 20-kdcproxy-enable-on-this-master.update > dn: cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX > add:ipaConfigString:enabledService > > # 20-kdcproxy-disable-on-this-master.update > dn: cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX > remove:ipaConfigString:enabledService I am fine with this too. So if there is not another major disagreement, let us start with enabling KDCPROXY by default during upgrade/install, the new ACI and the per-replica standard configuration. API CLI/UI can come later (4.2.x or 4.3). From cheimes at redhat.com Thu May 28 10:53:42 2015 From: cheimes at redhat.com (Christian Heimes) Date: Thu, 28 May 2015 12:53:42 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <5566F201.1070008@redhat.com> References: <5565B10F.1090802@redhat.com> <1432734188.3243.117.camel@willson.usersys.redhat.com> <5565CAF3.9020903@redhat.com> <1432734868.3243.121.camel@willson.usersys.redhat.com> <5566AAB8.2050609@redhat.com> <5566CEDA.5010701@redhat.com> <20150528091225.GZ19176@redhat.com> <5566E715.1060307@redhat.com> <5566E9A1.70108@redhat.com> <5566EB33.1050209@redhat.com> <20150528102736.GB19176@redhat.com> <5566F201.1070008@redhat.com> Message-ID: <5566F3B6.7020303@redhat.com> On 2015-05-28 12:46, Martin Kosek wrote: > I am fine with this too. So if there is not another major disagreement, let us > start with enabling KDCPROXY by default during upgrade/install, the new ACI and > the per-replica standard configuration. > > API CLI/UI can come later (4.2.x or 4.3). LGTM, too. How should the new ACI work? I see two possible ways: 1) Allow compare/search for ipaConfigString=enabledService for everybody: (targetfilter="(ipaConfigString=enabledService)")(targetattr="ipaConfigString")(version 3.0; acl "Compare enabledService access to masters"; allow(search, compare) userdn = "ldap:///all";) 2) Create a new permission, assign it to all HTTP principals and allow read, compare and search for all ipaConfigString attributes. For the second way I need somebody to walk me through the permission and role system of FreeIPA. Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From tbabej at redhat.com Thu May 28 10:59:57 2015 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 28 May 2015 12:59:57 +0200 Subject: [Freeipa-devel] [PATCHES 326-328] ID Views improvements Message-ID: <5566F52D.5030008@redhat.com> Hi, this couple of patches improves ID Views and ID overrides handling. See commit messages for details. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0326-idviews-Set-dcerpc-detection-flag-properly.patch Type: text/x-patch Size: 1121 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0327-idviews-Allow-users-specify-the-raw-anchor-directly-.patch Type: text/x-patch Size: 3471 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0328-idviews-Remove-ID-overrides-for-permanently-removed-.patch Type: text/x-patch Size: 4682 bytes Desc: not available URL: From ftweedal at redhat.com Thu May 28 11:18:04 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 28 May 2015 21:18:04 +1000 Subject: [Freeipa-devel] [PATCH 0014] Support multiple user and host certificates In-Reply-To: <5565ED02.6060709@redhat.com> References: <20150527135315.GC24915@dhcp-40-8.bne.redhat.com> <5565ED02.6060709@redhat.com> Message-ID: <20150528111804.GA23523@dhcp-40-8.bne.redhat.com> Updated patch attached. Notably restores/adds revocation behaviour to host-mod and service-mod. Thanks, Fraser On Wed, May 27, 2015 at 06:12:50PM +0200, Martin Basti wrote: > On 27/05/15 15:53, Fraser Tweedale wrote: > >This patch adds supports for multiple user / host certificates. No > >schema change is needed ('usercertificate' attribute is already > >multi-value). The revoke-previous-cert behaviour of host-mod and > >user-mod has been removed but revocation behaviour of -del and > >-disable is preserved. > > > >The latest profiles/caacl patchset (0001..0013 v5) depends on this > >patch for correct cert-request behaviour. > > > >There is one design question (or maybe more, let me know): the > >`--out=FILENAME' option to {host,service} show saves ONE certificate > >to the named file. I propose to either: > > > >a) write all certs, suffixing suggested filename with either a > > sequential numerical index, e.g. "cert.pem" becomes > > "cert.pem.1", "cert.pem.2", and so on; or > > > >b) as above, but suffix with serial number and, if there are > > different issues, some issuer-identifying information. > > > >Let me know your thoughts. > > > >Thanks, > >Fraser > > > > > Is there a possible way how to store certificates into one file? > I read about possibilities to have multiple certs in one .pem file, but I'm > not cert guru :) > > I personally vote for serial number in case there are multiple certificates, > if ^ is no possible. > > > 1) > + if len(certs) > 0: > > please use only, > if certs: > > 2) > You need to re-generate API/ACI.txt in this patch > > 3) > syntax error: > + for dercert in certs_der > > > 4) > command > ipa user-mod ca_user --certificate= > > removes the current certificate from the LDAP, by design. > Should be the old certificate(s) revoked? You removed that part in the code. > > only the --addattr='usercertificate=' appends new value there > > -- > Martin Basti > -------------- next part -------------- From 58d301e1c8e6efba68bf6459d51c24c640b67edd Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Wed, 27 May 2015 08:02:08 -0400 Subject: [PATCH] Support multiple host and service certificates Update the framework to support multiple host and service certificates. host-mod and service-mod revoke existing certificates that are not included in the modified entry. Using addattr=certificate=... will result in no certificates being revoked. The existing behaviour of host-disable, host-del, service-disable and service-del (revoke existing certificate) is preserved but now applies to all certificates in the host or service entry. Part of: http://www.freeipa.org/page/V4/User_Certificates --- API.txt | 10 ++--- ipalib/plugins/host.py | 96 ++++++++++++++++++++++++----------------------- ipalib/plugins/service.py | 83 ++++++++++++++++++++++++---------------- 3 files changed, 104 insertions(+), 85 deletions(-) diff --git a/API.txt b/API.txt index da69f32de5c12c0d85a7d61d9027385aa3c0ee05..3cfcf34939a58d6888de8f0a7a6ef0c7779c993e 100644 --- a/API.txt +++ b/API.txt @@ -1812,7 +1812,7 @@ option: Str('nsosversion', attribute=True, cli_name='os', multivalue=False, requ option: Flag('random', attribute=False, autofill=True, cli_name='random', default=False, multivalue=False, required=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Str('setattr*', cli_name='setattr', exclude='webui') -option: Bytes('usercertificate', attribute=True, cli_name='certificate', multivalue=False, required=False) +option: Bytes('usercertificate', attribute=True, cli_name='certificate', multivalue=True, required=False) option: Str('userclass', attribute=True, cli_name='class', multivalue=True, required=False) option: Str('userpassword', attribute=True, cli_name='password', multivalue=False, required=False) option: Str('version?', exclude='webui') @@ -1935,7 +1935,7 @@ option: Flag('pkey_only?', autofill=True, default=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Int('sizelimit?', autofill=False, minvalue=0) option: Int('timelimit?', autofill=False, minvalue=0) -option: Bytes('usercertificate', attribute=True, autofill=False, cli_name='certificate', multivalue=False, query=True, required=False) +option: Bytes('usercertificate', attribute=True, autofill=False, cli_name='certificate', multivalue=True, query=True, required=False) option: Str('userclass', attribute=True, autofill=False, cli_name='class', multivalue=True, query=True, required=False) option: Str('userpassword', attribute=True, autofill=False, cli_name='password', multivalue=False, query=True, required=False) option: Str('version?', exclude='webui') @@ -1966,7 +1966,7 @@ option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui option: Flag('rights', autofill=True, default=False) option: Str('setattr*', cli_name='setattr', exclude='webui') option: Flag('updatedns?', autofill=True, default=False) -option: Bytes('usercertificate', attribute=True, autofill=False, cli_name='certificate', multivalue=False, required=False) +option: Bytes('usercertificate', attribute=True, autofill=False, cli_name='certificate', multivalue=True, required=False) option: Str('userclass', attribute=True, autofill=False, cli_name='class', multivalue=True, required=False) option: Str('userpassword', attribute=True, autofill=False, cli_name='password', multivalue=False, required=False) option: Str('version?', exclude='webui') @@ -3584,7 +3584,7 @@ option: Bool('ipakrbrequirespreauth', attribute=False, cli_name='requires_pre_au 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: Bytes('usercertificate', attribute=True, cli_name='certificate', multivalue=False, required=False) +option: Bytes('usercertificate', attribute=True, cli_name='certificate', multivalue=True, required=False) option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('summary', (, ), None) @@ -3702,7 +3702,7 @@ option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Flag('rights', autofill=True, default=False) option: Str('setattr*', cli_name='setattr', exclude='webui') -option: Bytes('usercertificate', attribute=True, autofill=False, cli_name='certificate', multivalue=False, required=False) +option: Bytes('usercertificate', attribute=True, autofill=False, cli_name='certificate', multivalue=True, required=False) option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('summary', (, ), None) diff --git a/ipalib/plugins/host.py b/ipalib/plugins/host.py index c47439743da45b8629d1b2afbd210d87591784ce..13af9dc4c5e4ce00b4d969bcb0789d0034b2bba7 100644 --- a/ipalib/plugins/host.py +++ b/ipalib/plugins/host.py @@ -493,7 +493,7 @@ class host(LDAPObject): label=_('Random password'), flags=('no_create', 'no_update', 'no_search', 'virtual_attribute'), ), - Bytes('usercertificate?', validate_certificate, + Bytes('usercertificate*', validate_certificate, cli_name='certificate', label=_('Certificate'), doc=_('Base-64 encoded server certificate'), @@ -640,11 +640,11 @@ class host_add(LDAPCreate): entry_attrs['userpassword'] = ipa_generate_password(characters=host_pwd_chars) # save the password so it can be displayed in post_callback setattr(context, 'randompassword', entry_attrs['userpassword']) - cert = options.get('usercertificate') - if cert: - cert = x509.normalize_certificate(cert) + certs = options.get('usercertificate', []) + certs_der = map(x509.normalize_certificate, certs) + for cert in certs_der: x509.verify_cert_subject(ldap, keys[-1], cert) - entry_attrs['usercertificate'] = cert + entry_attrs['usercertificate'] = certs_der entry_attrs['managedby'] = dn entry_attrs['objectclass'].append('ieee802device') entry_attrs['objectclass'].append('ipasshhost') @@ -786,8 +786,7 @@ class host_del(LDAPDelete): entry_attrs = ldap.get_entry(dn, ['usercertificate']) except errors.NotFound: self.obj.handle_not_found(*keys) - cert = entry_attrs.single_value.get('usercertificate') - if cert: + for cert in entry_attrs.get('usercertificate', []): cert = x509.normalize_certificate(cert) try: serial = unicode(x509.get_serial_number(cert, x509.DER)) @@ -864,39 +863,42 @@ class host_mod(LDAPUpdate): if 'krbprincipalaux' not in obj_classes: obj_classes.append('krbprincipalaux') entry_attrs['objectclass'] = obj_classes - cert = x509.normalize_certificate(entry_attrs.get('usercertificate')) - if cert: - if self.api.Command.ca_is_enabled()['result']: - x509.verify_cert_subject(ldap, keys[-1], cert) - entry_attrs_old = ldap.get_entry(dn, ['usercertificate']) - oldcert = entry_attrs_old.single_value.get('usercertificate') - if oldcert: - oldcert = x509.normalize_certificate(oldcert) + + # verify certificates + certs = entry_attrs.get('usercertificate', []) + certs_der = map(x509.normalize_certificate, certs) + for cert in certs_der: + x509.verify_cert_subject(ldap, keys[-1], cert) + + # revoke removed certificates + if self.api.Command.ca_is_enabled()['result']: + entry_attrs_old = ldap.get_entry(dn, ['usercertificate']) + old_certs = entry_attrs_old.get('usercertificate', []) + removed_certs = set(old_certs) - set(certs) + removed_certs_der = map(x509.normalize_certificate, removed_certs) + for cert in removed_certs_der: + try: + serial = unicode(x509.get_serial_number(cert, x509.DER)) try: - serial = x509.get_serial_number(oldcert, x509.DER) - serial = unicode(serial) - try: - result = api.Command['cert_show'](serial)['result'] - if 'revocation_reason' not in result: - try: - api.Command['cert_revoke']( - serial, revocation_reason=4) - except errors.NotImplementedError: - # some CA's might not implement revoke - pass - except errors.NotImplementedError: - # some CA's might not implement revoke - pass - except NSPRError, nsprerr: - if nsprerr.errno == -8183: - # If we can't decode the cert them proceed with - # modifying the host. - self.log.info("Problem decoding certificate %s" % - nsprerr.args[1]) - else: - raise nsprerr - - entry_attrs['usercertificate'] = cert + result = api.Command['cert_show'](serial)['result'] + if 'revocation_reason' not in result: + try: + api.Command['cert_revoke']( + serial, revocation_reason=4) + except errors.NotImplementedError: + # some CA's might not implement revoke + pass + except errors.NotImplementedError: + # some CA's might not implement revoke + pass + except NSPRError, nsprerr: + if nsprerr.errno == -8183: + # If we can't decode the cert them proceed with + # modifying the host. + self.log.info("Problem decoding certificate %s" % + nsprerr.args[1]) + else: + raise nsprerr if options.get('random'): entry_attrs['userpassword'] = ipa_generate_password(characters=host_pwd_chars) @@ -1148,10 +1150,9 @@ class host_disable(LDAPQuery): entry_attrs = ldap.get_entry(dn, ['usercertificate']) except errors.NotFound: self.obj.handle_not_found(*keys) - cert = entry_attrs.single_value.get('usercertificate') - if cert: - if self.api.Command.ca_is_enabled()['result']: - cert = x509.normalize_certificate(cert) + if self.api.Command.ca_is_enabled()['result']: + certs = entry_attrs.get('usercertificate', []) + for cert in map(x509.normalize_certificate, certs): try: serial = unicode(x509.get_serial_number(cert, x509.DER)) try: @@ -1175,10 +1176,11 @@ class host_disable(LDAPQuery): else: raise nsprerr - # Remove the usercertificate altogether - entry_attrs['usercertificate'] = None - ldap.update_entry(entry_attrs) - done_work = True + if certs: + # Remove the usercertificate altogether + entry_attrs['usercertificate'] = None + ldap.update_entry(entry_attrs) + done_work = True self.obj.get_password_attributes(ldap, dn, entry_attrs) if entry_attrs['has_keytab']: diff --git a/ipalib/plugins/service.py b/ipalib/plugins/service.py index b37dc7b4bf56b69df204fd29e9487f1390197bbe..4699751a71dae2cf535e5f278f27b69426493c9f 100644 --- a/ipalib/plugins/service.py +++ b/ipalib/plugins/service.py @@ -437,7 +437,7 @@ class service(LDAPObject): primary_key=True, normalizer=lambda value: normalize_principal(value), ), - Bytes('usercertificate?', validate_certificate, + Bytes('usercertificate*', validate_certificate, cli_name='certificate', label=_('Certificate'), doc=_('Base-64 encoded server certificate'), @@ -503,11 +503,11 @@ class service_add(LDAPCreate): self.obj.validate_ipakrbauthzdata(entry_attrs) - cert = options.get('usercertificate') - if cert: - dercert = x509.normalize_certificate(cert) + certs = options.get('usercertificate', []) + certs_der = map(x509.normalize_certificate, certs) + for dercert in certs_der: x509.verify_cert_subject(ldap, hostname, dercert) - entry_attrs['usercertificate'] = dercert + entry_attrs['usercertificate'] = certs_der if not options.get('force', False): # We know the host exists if we've gotten this far but we @@ -555,9 +555,7 @@ class service_del(LDAPDelete): entry_attrs = ldap.get_entry(dn, ['usercertificate']) except errors.NotFound: self.obj.handle_not_found(*keys) - cert = entry_attrs.get('usercertificate') - if cert: - cert = cert[0] + for cert in entry_attrs.get('usercertificate', []): try: serial = unicode(x509.get_serial_number(cert, x509.DER)) try: @@ -597,25 +595,43 @@ class service_mod(LDAPUpdate): self.obj.validate_ipakrbauthzdata(entry_attrs) - if 'usercertificate' in options: - (service, hostname, realm) = split_principal(keys[-1]) - cert = options.get('usercertificate') - if cert: - dercert = x509.normalize_certificate(cert) - x509.verify_cert_subject(ldap, hostname, dercert) + (service, hostname, realm) = split_principal(keys[-1]) + + # verify certificates + certs = options.get('usercertificate', []) + certs_der = map(x509.normalize_certificate, certs) + for dercert in certs_der: + x509.verify_cert_subject(ldap, hostname, dercert) + + # revoke removed certificates + if self.api.Command.ca_is_enabled()['result']: + entry_attrs_old = ldap.get_entry(dn, ['usercertificate']) + old_certs = entry_attrs_old.get('usercertificate', []) + removed_certs = set(old_certs) - set(certs) + removed_certs_der = map(x509.normalize_certificate, removed_certs) + for cert in removed_certs_der: try: - entry_attrs_old = ldap.get_entry(dn, ['usercertificate']) - except errors.NotFound: - self.obj.handle_not_found(*keys) - if 'usercertificate' in entry_attrs_old: - # FIXME: what to do here? do we revoke the old cert? - fmt = 'entry already has a certificate, serial number: %s' % ( - x509.get_serial_number(entry_attrs_old['usercertificate'][0], x509.DER) - ) - raise errors.GenericError(format=fmt) - entry_attrs['usercertificate'] = dercert - else: - entry_attrs['usercertificate'] = None + serial = unicode(x509.get_serial_number(cert, x509.DER)) + try: + result = api.Command['cert_show'](serial)['result'] + if 'revocation_reason' not in result: + try: + api.Command['cert_revoke']( + serial, revocation_reason=4) + except errors.NotImplementedError: + # some CA's might not implement revoke + pass + except errors.NotImplementedError: + # some CA's might not implement revoke + pass + except NSPRError, nsprerr: + if nsprerr.errno == -8183: + # If we can't decode the cert them proceed with + # modifying the host. + self.log.info("Problem decoding certificate %s" % + nsprerr.args[1]) + else: + raise nsprerr update_krbticketflags(ldap, entry_attrs, attrs_list, options, True) @@ -815,9 +831,9 @@ class service_disable(LDAPQuery): # See if we do any work at all here and if not raise an exception done_work = False - if 'usercertificate' in entry_attrs: - if self.api.Command.ca_is_enabled()['result']: - cert = x509.normalize_certificate(entry_attrs.get('usercertificate')[0]) + if self.api.Command.ca_is_enabled()['result']: + certs = entry_attrs.get('usercertificate', []) + for cert in map(x509.normalize_certificate, certs): try: serial = unicode(x509.get_serial_number(cert, x509.DER)) try: @@ -839,10 +855,11 @@ class service_disable(LDAPQuery): else: raise nsprerr - # Remove the usercertificate altogether - entry_attrs['usercertificate'] = None - ldap.update_entry(entry_attrs) - done_work = True + if len(certs) > 0: + # Remove the usercertificate altogether + entry_attrs['usercertificate'] = None + ldap.update_entry(entry_attrs) + done_work = True self.obj.get_password_attributes(ldap, dn, entry_attrs) if entry_attrs['has_keytab']: -- 2.1.0 From mbasti at redhat.com Thu May 28 11:29:31 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 28 May 2015 13:29:31 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <5566F3B6.7020303@redhat.com> References: <5565B10F.1090802@redhat.com> <1432734188.3243.117.camel@willson.usersys.redhat.com> <5565CAF3.9020903@redhat.com> <1432734868.3243.121.camel@willson.usersys.redhat.com> <5566AAB8.2050609@redhat.com> <5566CEDA.5010701@redhat.com> <20150528091225.GZ19176@redhat.com> <5566E715.1060307@redhat.com> <5566E9A1.70108@redhat.com> <5566EB33.1050209@redhat.com> <20150528102736.GB19176@redhat.com> <5566F201.1070008@redhat.com> <5566F3B6.7020303@redhat.com> Message-ID: <5566FC1B.5090407@redhat.com> On 28/05/15 12:53, Christian Heimes wrote: > On 2015-05-28 12:46, Martin Kosek wrote: >> I am fine with this too. So if there is not another major disagreement, let us >> start with enabling KDCPROXY by default during upgrade/install, the new ACI and >> the per-replica standard configuration. >> >> API CLI/UI can come later (4.2.x or 4.3). > LGTM, too. > > How should the new ACI work? I see two possible ways: > > 1) Allow compare/search for ipaConfigString=enabledService for everybody: > > (targetfilter="(ipaConfigString=enabledService)")(targetattr="ipaConfigString")(version > 3.0; acl "Compare enabledService access to masters"; allow(search, > compare) userdn = "ldap:///all";) > > 2) Create a new permission, assign it to all HTTP principals and allow > read, compare and search for all ipaConfigString attributes. > > For the second way I need somebody to walk me through the permission and > role system of FreeIPA. 3) Or we can create a new keytab for KDC proxy, and add permission only for this service > > Christian > > > -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Thu May 28 11:30:40 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 28 May 2015 13:30:40 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <5566F3B6.7020303@redhat.com> References: <5565B10F.1090802@redhat.com> <1432734188.3243.117.camel@willson.usersys.redhat.com> <5565CAF3.9020903@redhat.com> <1432734868.3243.121.camel@willson.usersys.redhat.com> <5566AAB8.2050609@redhat.com> <5566CEDA.5010701@redhat.com> <20150528091225.GZ19176@redhat.com> <5566E715.1060307@redhat.com> <5566E9A1.70108@redhat.com> <5566EB33.1050209@redhat.com> <20150528102736.GB19176@redhat.com> <5566F201.1070008@redhat.com> <5566F3B6.7020303@redhat.com> Message-ID: <5566FC60.2040109@redhat.com> Dne 28.5.2015 v 12:53 Christian Heimes napsal(a): > On 2015-05-28 12:46, Martin Kosek wrote: >> I am fine with this too. So if there is not another major disagreement, let us >> start with enabling KDCPROXY by default during upgrade/install, the new ACI and >> the per-replica standard configuration. >> >> API CLI/UI can come later (4.2.x or 4.3). > > LGTM, too. > > How should the new ACI work? I see two possible ways: > > 1) Allow compare/search for ipaConfigString=enabledService for everybody: > > (targetfilter="(ipaConfigString=enabledService)")(targetattr="ipaConfigString")(version > 3.0; acl "Compare enabledService access to masters"; allow(search, > compare) userdn = "ldap:///all";) > > 2) Create a new permission, assign it to all HTTP principals and allow > read, compare and search for all ipaConfigString attributes. > > For the second way I need somebody to walk me through the permission and > role system of FreeIPA. > > Christian So, will it be a separate component with its own freeipa-server-kdcproxy subpackage and installer or will it be a sub-component of KDC (as Martin suggested) and part of the core freeipa-server package? -- Jan Cholasta From pspacek at redhat.com Thu May 28 11:33:27 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 28 May 2015 13:33:27 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <5566F3B6.7020303@redhat.com> References: <5565B10F.1090802@redhat.com> <1432734188.3243.117.camel@willson.usersys.redhat.com> <5565CAF3.9020903@redhat.com> <1432734868.3243.121.camel@willson.usersys.redhat.com> <5566AAB8.2050609@redhat.com> <5566CEDA.5010701@redhat.com> <20150528091225.GZ19176@redhat.com> <5566E715.1060307@redhat.com> <5566E9A1.70108@redhat.com> <5566EB33.1050209@redhat.com> <20150528102736.GB19176@redhat.com> <5566F201.1070008@redhat.com> <5566F3B6.7020303@redhat.com> Message-ID: <5566FD07.9060204@redhat.com> On 28.5.2015 12:53, Christian Heimes wrote: > On 2015-05-28 12:46, Martin Kosek wrote: >> I am fine with this too. So if there is not another major disagreement, >> let us start with enabling KDCPROXY by default during upgrade/install, >> the new ACI and the per-replica standard configuration. >> >> API CLI/UI can come later (4.2.x or 4.3). > > LGTM, too. > > How should the new ACI work? I see two possible ways: > > 1) Allow compare/search for ipaConfigString=enabledService for > everybody: > > (targetfilter="(ipaConfigString=enabledService)")(targetattr="ipaConfigString")(version > > 3.0; acl "Compare enabledService access to masters"; allow(search, > compare) userdn = "ldap:///all";) > > 2) Create a new permission, assign it to all HTTP principals and allow > read, compare and search for all ipaConfigString attributes. I like option 2 - a new permission like "Read configuration of IPA services". > For the second way I need somebody to walk me through the permission and > role system of FreeIPA. Unfortunately I did not use the new system myself so I do not have particular steps to share. Please see design pages here: http://www.freeipa.org/page/V3/Permissions_V2 http://www.freeipa.org/page/V3/Permissions_V2/tests ... and contact Petr Viktorin . The new permission system is his child :-) I hope this helps. -- Petr^2 Spacek From cheimes at redhat.com Thu May 28 11:56:36 2015 From: cheimes at redhat.com (Christian Heimes) Date: Thu, 28 May 2015 13:56:36 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <5566FC60.2040109@redhat.com> References: <5565B10F.1090802@redhat.com> <1432734188.3243.117.camel@willson.usersys.redhat.com> <5565CAF3.9020903@redhat.com> <1432734868.3243.121.camel@willson.usersys.redhat.com> <5566AAB8.2050609@redhat.com> <5566CEDA.5010701@redhat.com> <20150528091225.GZ19176@redhat.com> <5566E715.1060307@redhat.com> <5566E9A1.70108@redhat.com> <5566EB33.1050209@redhat.com> <20150528102736.GB19176@redhat.com> <5566F201.1070008@redhat.com> <5566F3B6.7020303@redhat.com> <5566FC60.2040109@redhat.com> Message-ID: <55670274.10907@redhat.com> On 2015-05-28 13:30, Jan Cholasta wrote: > Dne 28.5.2015 v 12:53 Christian Heimes napsal(a): >> On 2015-05-28 12:46, Martin Kosek wrote: >>> I am fine with this too. So if there is not another major >>> disagreement, let us >>> start with enabling KDCPROXY by default during upgrade/install, the >>> new ACI and >>> the per-replica standard configuration. >>> >>> API CLI/UI can come later (4.2.x or 4.3). >> >> LGTM, too. >> >> How should the new ACI work? I see two possible ways: >> >> 1) Allow compare/search for ipaConfigString=enabledService for everybody: >> >> (targetfilter="(ipaConfigString=enabledService)")(targetattr="ipaConfigString")(version >> >> 3.0; acl "Compare enabledService access to masters"; allow(search, >> compare) userdn = "ldap:///all";) >> >> 2) Create a new permission, assign it to all HTTP principals and allow >> read, compare and search for all ipaConfigString attributes. >> >> For the second way I need somebody to walk me through the permission and >> role system of FreeIPA. >> >> Christian > > So, will it be a separate component with its own freeipa-server-kdcproxy > subpackage and installer or will it be a sub-component of KDC (as Martin > suggested) and part of the core freeipa-server package? For now I'm in favor of a sub-component as part of the freeipa-server package. Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From jcholast at redhat.com Thu May 28 11:59:58 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 28 May 2015 13:59:58 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <55670274.10907@redhat.com> References: <5565B10F.1090802@redhat.com> <1432734188.3243.117.camel@willson.usersys.redhat.com> <5565CAF3.9020903@redhat.com> <1432734868.3243.121.camel@willson.usersys.redhat.com> <5566AAB8.2050609@redhat.com> <5566CEDA.5010701@redhat.com> <20150528091225.GZ19176@redhat.com> <5566E715.1060307@redhat.com> <5566E9A1.70108@redhat.com> <5566EB33.1050209@redhat.com> <20150528102736.GB19176@redhat.com> <5566F201.1070008@redhat.com> <5566F3B6.7020303@redhat.com> <5566FC60.2040109@redhat.com> <55670274.10907@redhat.com> Message-ID: <5567033E.7050901@redhat.com> Dne 28.5.2015 v 13:56 Christian Heimes napsal(a): > On 2015-05-28 13:30, Jan Cholasta wrote: >> Dne 28.5.2015 v 12:53 Christian Heimes napsal(a): >>> On 2015-05-28 12:46, Martin Kosek wrote: >>>> I am fine with this too. So if there is not another major >>>> disagreement, let us >>>> start with enabling KDCPROXY by default during upgrade/install, the >>>> new ACI and >>>> the per-replica standard configuration. >>>> >>>> API CLI/UI can come later (4.2.x or 4.3). >>> >>> LGTM, too. >>> >>> How should the new ACI work? I see two possible ways: >>> >>> 1) Allow compare/search for ipaConfigString=enabledService for everybody: >>> >>> (targetfilter="(ipaConfigString=enabledService)")(targetattr="ipaConfigString")(version >>> >>> 3.0; acl "Compare enabledService access to masters"; allow(search, >>> compare) userdn = "ldap:///all";) >>> >>> 2) Create a new permission, assign it to all HTTP principals and allow >>> read, compare and search for all ipaConfigString attributes. >>> >>> For the second way I need somebody to walk me through the permission and >>> role system of FreeIPA. >>> >>> Christian >> >> So, will it be a separate component with its own freeipa-server-kdcproxy >> subpackage and installer or will it be a sub-component of KDC (as Martin >> suggested) and part of the core freeipa-server package? > > For now I'm in favor of a sub-component as part of the freeipa-server > package. OK, then I'm fine with ipa-kdcproxy-manage, but instead of adding a new service entry for KDC proxy, you can just add a flag to the KDC service entry, like ipaConfigString=kdcProxyEnabled. -- Jan Cholasta From cheimes at redhat.com Thu May 28 12:06:04 2015 From: cheimes at redhat.com (Christian Heimes) Date: Thu, 28 May 2015 14:06:04 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <5566FC1B.5090407@redhat.com> References: <5565B10F.1090802@redhat.com> <1432734188.3243.117.camel@willson.usersys.redhat.com> <5565CAF3.9020903@redhat.com> <1432734868.3243.121.camel@willson.usersys.redhat.com> <5566AAB8.2050609@redhat.com> <5566CEDA.5010701@redhat.com> <20150528091225.GZ19176@redhat.com> <5566E715.1060307@redhat.com> <5566E9A1.70108@redhat.com> <5566EB33.1050209@redhat.com> <20150528102736.GB19176@redhat.com> <5566F201.1070008@redhat.com> <5566F3B6.7020303@redhat.com> <5566FC1B.5090407@redhat.com> Message-ID: <556704AC.4050502@redhat.com> On 2015-05-28 13:29, Martin Basti wrote: > On 28/05/15 12:53, Christian Heimes wrote: >> On 2015-05-28 12:46, Martin Kosek wrote: >>> I am fine with this too. So if there is not another major disagreement, let us >>> start with enabling KDCPROXY by default during upgrade/install, the new ACI and >>> the per-replica standard configuration. >>> >>> API CLI/UI can come later (4.2.x or 4.3). >> LGTM, too. >> >> How should the new ACI work? I see two possible ways: >> >> 1) Allow compare/search for ipaConfigString=enabledService for everybody: >> >> (targetfilter="(ipaConfigString=enabledService)")(targetattr="ipaConfigString")(version >> 3.0; acl "Compare enabledService access to masters"; allow(search, >> compare) userdn = "ldap:///all";) >> >> 2) Create a new permission, assign it to all HTTP principals and allow >> read, compare and search for all ipaConfigString attributes. >> >> For the second way I need somebody to walk me through the permission and >> role system of FreeIPA. > > 3) Or we can create a new keytab for KDC proxy, and add permission only > for this service The new keytab must be readable by the Apache process.Therefore a new keytab doesn't give us extra security. It separates the kdcproxy service from the IPA webgui. Is that your goal? Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From mbasti at redhat.com Thu May 28 12:08:28 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 28 May 2015 14:08:28 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <556704AC.4050502@redhat.com> References: <5565B10F.1090802@redhat.com> <1432734188.3243.117.camel@willson.usersys.redhat.com> <5565CAF3.9020903@redhat.com> <1432734868.3243.121.camel@willson.usersys.redhat.com> <5566AAB8.2050609@redhat.com> <5566CEDA.5010701@redhat.com> <20150528091225.GZ19176@redhat.com> <5566E715.1060307@redhat.com> <5566E9A1.70108@redhat.com> <5566EB33.1050209@redhat.com> <20150528102736.GB19176@redhat.com> <5566F201.1070008@redhat.com> <5566F3B6.7020303@redhat.com> <5566FC1B.5090407@redhat.com> <556704AC.4050502@redhat.com> Message-ID: <5567053C.4050601@redhat.com> On 28/05/15 14:06, Christian Heimes wrote: > On 2015-05-28 13:29, Martin Basti wrote: >> On 28/05/15 12:53, Christian Heimes wrote: >>> On 2015-05-28 12:46, Martin Kosek wrote: >>>> I am fine with this too. So if there is not another major disagreement, let us >>>> start with enabling KDCPROXY by default during upgrade/install, the new ACI and >>>> the per-replica standard configuration. >>>> >>>> API CLI/UI can come later (4.2.x or 4.3). >>> LGTM, too. >>> >>> How should the new ACI work? I see two possible ways: >>> >>> 1) Allow compare/search for ipaConfigString=enabledService for everybody: >>> >>> (targetfilter="(ipaConfigString=enabledService)")(targetattr="ipaConfigString")(version >>> 3.0; acl "Compare enabledService access to masters"; allow(search, >>> compare) userdn = "ldap:///all";) >>> >>> 2) Create a new permission, assign it to all HTTP principals and allow >>> read, compare and search for all ipaConfigString attributes. >>> >>> For the second way I need somebody to walk me through the permission and >>> role system of FreeIPA. >> 3) Or we can create a new keytab for KDC proxy, and add permission only >> for this service > The new keytab must be readable by the Apache process.Therefore a new > keytab doesn't give us extra security. It separates the kdcproxy service > from the IPA webgui. Is that your goal? > > Christian > OK, then nevermind :-) Martin^2 -- Martin Basti From pspacek at redhat.com Thu May 28 12:11:57 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 28 May 2015 14:11:57 +0200 Subject: [Freeipa-devel] Domain level for topology plugin = 2 In-Reply-To: <5566D684.6080505@redhat.com> References: <55646331.5050807@redhat.com> <55647F90.506@redhat.com> <5564804B.6080305@redhat.com> <5564841B.4020906@redhat.com> <5566BBFD.9070601@redhat.com> <5566BE3E.2060104@redhat.com> <5566D684.6080505@redhat.com> Message-ID: <5567060D.5010202@redhat.com> On 28.5.2015 10:49, Martin Kosek wrote: > On 05/28/2015 09:05 AM, Petr Spacek wrote: >> On 28.5.2015 08:55, Jan Cholasta wrote: >>> Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): >>>> On 26.5.2015 16:16, Martin Kosek wrote: >>>>> On 05/26/2015 04:13 PM, thierry bordaz wrote: >>>>>> On 05/26/2015 02:12 PM, Petr Spacek wrote: >>>>>>> Hello, >>>>>>> >>>>>>> it came to my mind that domain level for topology plugin should actually be >>>>>>> number 2, not 1. >>>>>>> >>>>>>> We already used number 1 for incompatible changes in DNS tree and I believe >>>>>>> that it is not a good idea to have two places which say 'version 1' but and >>>>>>> actually mean two different things. (DNS tree version 1 + domain level 1) >>>>>>> >>>>>>> Patch is attached. >>>>>>> >>>>>>> >>>>>>> >>>>>> Hello, >>>>>> The fix looks good but that seems strange to have to set the initial >>>>>> version of >>>>>> the topology plugin to 2.0. (IIUC That is the version that will be written in >>>>>> dse.ldif) >>>>>> I would rather expects that topology plugin 1.0, would activate itself if the >>>>>> DomainLevel is 2.0 or more. >>>>>> If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate >>>>>> itself if DomainLevel >= DomainLevel_trigger. >>>>>> >>>>>> Let's wait for Ludwig feedback. >>>>>> >>>>>> thanks >>>>>> thierry >>>>> >>>>> My personal opinion on this is to start with Domain Level 1 regardless. We >>>>> already "solved" the DNS forwarders otherwise, with docs, async updates etc. I >>>>> do not think we will be returning to implementing proper Domain Level support >>>>> for that anyway. >>>>> >>>>> So I rather think that all the "Domain Level starts with 0, 1 is unused, 2 is >>>>> the top one" will cause unforeseen issues I would rather like to avoid. >>>> >>>> I'm more worried about confusion in future. To to me it simply seems easier to >>>> bump one integer now than to document and explain (to users & new developers) >>>> why we have two "ones" which mean something else. >>>> >>>> Code-wise it is just an integer. >>>> >>>> Also, it can simplify logic in future when we decide to do another >>>> incompatible change in DNS tree because we will have only one integer to test >>>> (instead of checking two separate version attribute in DNS tree & domain >>>> level). >>> >>> +1, but I think the minimum supported domain level should be 1, not 0, because >>> 0 means the server uses the old DNS schema, which we do not support anymore, >>> right? >> >> Good point! >> > > It may be a good point, but it does not make the situation easier. You still > have RHEL/CentOS 6.x IPA out there, where some of them already support the new > DNS forwarders and some don't - and neither of them support Domain Levels - > i.e. have Domain Level 0. > > As I said, I still see more complications with this proposals than benefits... I would argue that it actually helps. If domain level = 1 then we can be *sure* that all replicas support the new DNS semantics. If domain level = 0 then we know nothing (because of patched RHEL 6) and it is a warning sign for diagnostic tools and also us when it comes to debugging. -- Petr^2 Spacek From pspacek at redhat.com Thu May 28 12:29:25 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 28 May 2015 14:29:25 +0200 Subject: [Freeipa-devel] [PATCH 0014] Support multiple user and host certificates In-Reply-To: <20150528100615.GD9628@dhcp-40-8.bne.redhat.com> References: <20150527135315.GC24915@dhcp-40-8.bne.redhat.com> <5565ED02.6060709@redhat.com> <5566D5FC.7090307@redhat.com> <5566DD1D.7040009@redhat.com> <5566E559.8020709@redhat.com> <20150528100615.GD9628@dhcp-40-8.bne.redhat.com> Message-ID: <55670A25.1000307@redhat.com> On 28.5.2015 12:06, Fraser Tweedale wrote: > On Thu, May 28, 2015 at 11:52:25AM +0200, Martin Kosek wrote: >> On 05/28/2015 11:17 AM, Martin Basti wrote: >>> On 28/05/15 10:46, Martin Kosek wrote: >>>> On 05/27/2015 06:12 PM, Martin Basti wrote: >>>>> On 27/05/15 15:53, Fraser Tweedale wrote: >>>>>> This patch adds supports for multiple user / host certificates. No >>>>>> schema change is needed ('usercertificate' attribute is already >>>>>> multi-value). The revoke-previous-cert behaviour of host-mod and >>>>>> user-mod has been removed but revocation behaviour of -del and >>>>>> -disable is preserved. >>>>>> >>>>>> The latest profiles/caacl patchset (0001..0013 v5) depends on this >>>>>> patch for correct cert-request behaviour. >>>>>> >>>>>> There is one design question (or maybe more, let me know): the >>>>>> `--out=FILENAME' option to {host,service} show saves ONE certificate >>>>>> to the named file. I propose to either: >>>>>> >>>>>> a) write all certs, suffixing suggested filename with either a >>>>>> sequential numerical index, e.g. "cert.pem" becomes >>>>>> "cert.pem.1", "cert.pem.2", and so on; or >>>>>> >>>>>> b) as above, but suffix with serial number and, if there are >>>>>> different issues, some issuer-identifying information. >>>>>> >>>>>> Let me know your thoughts. >>>>>> >>>>>> Thanks, >>>>>> Fraser >>>>>> >>>>>> >>>>> Is there a possible way how to store certificates into one file? >>>>> I read about possibilities to have multiple certs in one .pem file, but I'm not >>>>> cert guru :) >>>>> >>>>> I personally vote for serial number in case there are multiple certificates, if >>>>> ^ is no possible. >>>>> >>>>> >>>>> 1) >>>>> + if len(certs) > 0: >>>>> >>>>> please use only, >>>>> if certs: >>>>> >>>>> 2) >>>>> You need to re-generate API/ACI.txt in this patch >>>>> >>>>> 3) >>>>> syntax error: >>>>> + for dercert in certs_der >>>>> >>>>> >>>>> 4) >>>>> command >>>>> ipa user-mod ca_user --certificate= >>>>> >>>>> removes the current certificate from the LDAP, by design. >>>>> Should be the old certificate(s) revoked? You removed that part in the code. >>>> Good question. I think the suggestion was to have a global switch in IPA global >>>> config that would configure the policy - whether the certificates removed by >>>> this command or by host-del or host-disable are revoked or if they are just >>>> removed (my motivation is to avoid behavior regression in case somebody >>>> depended on this behavior). >>> I would prefer to keep the current behavior: revoke the certificate if it was >>> replaced or removed, instead of adding an extra configuration option. >>> This behavior is not regression. >> >> It is not. However, it is not an ideal behavior also. In FreeIPA 4.2, we are >> now adding support of certificate profiles, multiple certificates and even >> certificates for user. >> >> With that change, there may be much more certificates in play than now. If we >> keep revoking all such certificates, it may cause rapid growth of CRLs. This is >> something I am trying to avoid with this proposal and default to not revoking >> certificates automatically (which mostly only makes sense if there is a risk >> that the key is compromised), but have some option to keep the old behavior. >> >> Does this make sense? I would like to see some data to support the decision not to revoke certs by default. Are there some facts to base the decision on? Or just hand-wavy reasoning? Sure, huge CRL may be bad, but not revoking certs may be even worse. E.g. when older backup files are stolen (in the information sense, i.e. copied without anyone noticing it) - attacker might get valid certs despite the fact that the old cert is never used (because it was rotated right after the backup). IMHO this behavior should be configurable and default to 'revoke'. We should ship FreeIPA with secure defaults and let users to lower the standards if they wish/need. Petr^2 Spacek > It does make senes. > > In regards to *this* patch, I will make -mod behave the same as -del > and -disable; i.e. the current behaviour i.e. revoke whenever we > "forget" a certificate. > > Any config knobs, command options, etc to govern whether to revoke > shall be added in a subsequent patch. From mbasti at redhat.com Thu May 28 12:42:53 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 28 May 2015 14:42:53 +0200 Subject: [Freeipa-devel] [PATCHES 0001-0013 v5] Profiles and CA ACLs In-Reply-To: <5566E484.7080809@redhat.com> References: <555AF9E1.1010606@redhat.com> <20150519115027.GA12806@dhcp-40-8.bne.redhat.com> <555C1E5C.2080707@redhat.com> <20150520055636.GF12806@dhcp-40-8.bne.redhat.com> <555C30FE.4030707@redhat.com> <20150520144106.GH12806@dhcp-40-8.bne.redhat.com> <555DCC96.2050001@redhat.com> <555DD031.8070302@redhat.com> <555DD39C.3070103@redhat.com> <20150526155930.GI13469@dhcp-40-8.bne.redhat.com> <20150527140434.GD24915@dhcp-40-8.bne.redhat.com> <5566E484.7080809@redhat.com> Message-ID: <55670D4D.9080302@redhat.com> 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 at 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 Basti From mbabinsk at redhat.com Thu May 28 12:43:17 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 28 May 2015 14:43:17 +0200 Subject: [Freeipa-devel] [PATCH 0039] ipa-kdb: common function to get key encodings/salt types Message-ID: <55670D65.5040904@redhat.com> A small improvement upon simo's fix for https://fedorahosted.org/freeipa/ticket/4914 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0039-ipa-kdb-common-function-to-get-key-encodings-salt-ty.patch Type: text/x-patch Size: 6357 bytes Desc: not available URL: From mbasti at redhat.com Thu May 28 12:51:14 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 28 May 2015 14:51:14 +0200 Subject: [Freeipa-devel] [PATCH 0014] Support multiple user and host certificates In-Reply-To: <55670A25.1000307@redhat.com> References: <20150527135315.GC24915@dhcp-40-8.bne.redhat.com> <5565ED02.6060709@redhat.com> <5566D5FC.7090307@redhat.com> <5566DD1D.7040009@redhat.com> <5566E559.8020709@redhat.com> <20150528100615.GD9628@dhcp-40-8.bne.redhat.com> <55670A25.1000307@redhat.com> Message-ID: <55670F42.8060001@redhat.com> On 28/05/15 14:29, Petr Spacek wrote: > On 28.5.2015 12:06, Fraser Tweedale wrote: >> On Thu, May 28, 2015 at 11:52:25AM +0200, Martin Kosek wrote: >>> On 05/28/2015 11:17 AM, Martin Basti wrote: >>>> On 28/05/15 10:46, Martin Kosek wrote: >>>>> On 05/27/2015 06:12 PM, Martin Basti wrote: >>>>>> On 27/05/15 15:53, Fraser Tweedale wrote: >>>>>>> This patch adds supports for multiple user / host certificates. No >>>>>>> schema change is needed ('usercertificate' attribute is already >>>>>>> multi-value). The revoke-previous-cert behaviour of host-mod and >>>>>>> user-mod has been removed but revocation behaviour of -del and >>>>>>> -disable is preserved. >>>>>>> >>>>>>> The latest profiles/caacl patchset (0001..0013 v5) depends on this >>>>>>> patch for correct cert-request behaviour. >>>>>>> >>>>>>> There is one design question (or maybe more, let me know): the >>>>>>> `--out=FILENAME' option to {host,service} show saves ONE certificate >>>>>>> to the named file. I propose to either: >>>>>>> >>>>>>> a) write all certs, suffixing suggested filename with either a >>>>>>> sequential numerical index, e.g. "cert.pem" becomes >>>>>>> "cert.pem.1", "cert.pem.2", and so on; or >>>>>>> >>>>>>> b) as above, but suffix with serial number and, if there are >>>>>>> different issues, some issuer-identifying information. >>>>>>> >>>>>>> Let me know your thoughts. >>>>>>> >>>>>>> Thanks, >>>>>>> Fraser >>>>>>> >>>>>>> >>>>>> Is there a possible way how to store certificates into one file? >>>>>> I read about possibilities to have multiple certs in one .pem file, but I'm not >>>>>> cert guru :) >>>>>> >>>>>> I personally vote for serial number in case there are multiple certificates, if >>>>>> ^ is no possible. >>>>>> >>>>>> >>>>>> 1) >>>>>> + if len(certs) > 0: >>>>>> >>>>>> please use only, >>>>>> if certs: >>>>>> >>>>>> 2) >>>>>> You need to re-generate API/ACI.txt in this patch >>>>>> >>>>>> 3) >>>>>> syntax error: >>>>>> + for dercert in certs_der >>>>>> >>>>>> >>>>>> 4) >>>>>> command >>>>>> ipa user-mod ca_user --certificate= >>>>>> >>>>>> removes the current certificate from the LDAP, by design. >>>>>> Should be the old certificate(s) revoked? You removed that part in the code. >>>>> Good question. I think the suggestion was to have a global switch in IPA global >>>>> config that would configure the policy - whether the certificates removed by >>>>> this command or by host-del or host-disable are revoked or if they are just >>>>> removed (my motivation is to avoid behavior regression in case somebody >>>>> depended on this behavior). >>>> I would prefer to keep the current behavior: revoke the certificate if it was >>>> replaced or removed, instead of adding an extra configuration option. >>>> This behavior is not regression. >>> It is not. However, it is not an ideal behavior also. In FreeIPA 4.2, we are >>> now adding support of certificate profiles, multiple certificates and even >>> certificates for user. >>> >>> With that change, there may be much more certificates in play than now. If we >>> keep revoking all such certificates, it may cause rapid growth of CRLs. This is >>> something I am trying to avoid with this proposal and default to not revoking >>> certificates automatically (which mostly only makes sense if there is a risk >>> that the key is compromised), but have some option to keep the old behavior. >>> >>> Does this make sense? > I would like to see some data to support the decision not to revoke certs by > default. Are there some facts to base the decision on? Or just hand-wavy > reasoning? > > Sure, huge CRL may be bad, but not revoking certs may be even worse. E.g. when > older backup files are stolen (in the information sense, i.e. copied without > anyone noticing it) - attacker might get valid certs despite the fact that the > old cert is never used (because it was rotated right after the backup). > > IMHO this behavior should be configurable and default to 'revoke'. We should > ship FreeIPA with secure defaults and let users to lower the standards if they > wish/need. > > Petr^2 Spacek +1 would be enought to have just option in the command --revoke-cert=true, with true as default, instead of global configuration? Martin^2 > >> It does make senes. >> >> In regards to *this* patch, I will make -mod behave the same as -del >> and -disable; i.e. the current behaviour i.e. revoke whenever we >> "forget" a certificate. >> >> Any config knobs, command options, etc to govern whether to revoke >> shall be added in a subsequent patch. -- Martin Basti From ssorce at redhat.com Thu May 28 12:55:09 2015 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 28 May 2015 08:55:09 -0400 Subject: [Freeipa-devel] [PATCH 0039] ipa-kdb: common function to get key encodings/salt types In-Reply-To: <55670D65.5040904@redhat.com> References: <55670D65.5040904@redhat.com> Message-ID: <1432817709.19096.119.camel@willson.usersys.redhat.com> On Thu, 2015-05-28 at 14:43 +0200, Martin Babinsky wrote: > A small improvement upon simo's fix for > https://fedorahosted.org/freeipa/ticket/4914 > > -- > Martin^3 Babinsky LGTM. Simo. From simo at redhat.com Thu May 28 13:06:44 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 28 May 2015 09:06:44 -0400 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <5566AAB8.2050609@redhat.com> References: <555F03DB.3090702@redhat.com> <556493D3.8010402@redhat.com> <55659335.2060306@redhat.com> <20150527095322.GM19176@redhat.com> <55659571.8070705@redhat.com> <5565AB70.7020004@redhat.com> <5565ABCF.5090305@redhat.com> <5565B10F.1090802@redhat.com> <1432734188.3243.117.camel@willson.usersys.redhat.com> <5565CAF3.9020903@redhat.com> <1432734868.3243.121.camel@willson.usersys.redhat.com> <5566AAB8.2050609@redhat.com> Message-ID: <1432818404.19096.125.camel@willson.usersys.redhat.com> On Thu, 2015-05-28 at 07:42 +0200, Jan Cholasta wrote: > Dne 27.5.2015 v 15:54 Simo Sorce napsal(a): > > On Wed, 2015-05-27 at 15:47 +0200, Jan Cholasta wrote: > >> Dne 27.5.2015 v 15:43 Simo Sorce napsal(a): > >>> On Wed, 2015-05-27 at 13:57 +0200, Jan Cholasta wrote: > >>>>>> > >>>>>> ipa config-mod --enable-kdcproxy=TRUE > >>>>>> ipa config-mod --enable-kdcproxy=FALSE > >>>> > >>>> I don't like this approach, as it is completely inconsistent with > >>>> every > >>>> other optional component. There should be *one* way to handle them > >>>> and > >>>> there already is one, no need to reinvent the wheel. > >>> > >>> Sorry Jan, but this is really the correct approach. > >> > >> I don't think so. > >> > >>> > >>> We want a boolean in LDAP to control whether the IPA Domain allows > >>> proxying or not, the code is embedded in the overall framework and has > >>> no need for explicit install/uninstall unlike the CA or DNS components. > >> > >> There is a boolean for every other component/service as well. If you > >> want to add new API to manipulate the boolean, fine, but it should be > >> done in a generic way that works for other components as well. > > > > This is the same as: > > ipa config-mod --enable-migration=TRUE > > > > Why is it a problem ? > > This is a switch to enable the migrate-ds plugin. I think it's hardly > fair to compare it to a whole new component which provides a new service > to the outside world. Well, this is the problem, I guess there is a perception issue. The KDC Proxy is basically nothing more than adding a new protocol to the KDC. It doesn't really do anything special but getting packets on HTTPS and sending them to the KDC over TCP. SO I think that for this specific case the KDC Proxy really is comparable to migration mode (actually simpler than migration). > > This is not a separate service. > > How is it not a separate service? If it's installed, MS-KKDCP is > provided to the outside world, and if it's not installed MS-KKDCP is not > provided to the outside world. If the migration plugin is installed the service is provided, if it is not installed it is not provided, it is conceptually the same. Yes there is code involved, but we plan to have the proxy always provided. There is no plan to have it as a removable component, you can only enable or disable it, like for migration. > How is this different from, say, DNS? > (Besides implementation details, such as what protocols or how many > daemons it uses - think about IPA as a black box for a moment.) It is completely different in size and scope, the KDCProxy really is just an enabler to reach the KDC over a different protocol, it is not a whole new protocol and service. In the end it is a matter of perspective, I think most of the people that have been dealing with it think it is much like migration and not an entire new service like DNS. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Thu May 28 13:26:53 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 28 May 2015 09:26:53 -0400 Subject: [Freeipa-devel] Domain level for topology plugin = 2 In-Reply-To: <5567060D.5010202@redhat.com> References: <55646331.5050807@redhat.com> <55647F90.506@redhat.com> <5564804B.6080305@redhat.com> <5564841B.4020906@redhat.com> <5566BBFD.9070601@redhat.com> <5566BE3E.2060104@redhat.com> <5566D684.6080505@redhat.com> <5567060D.5010202@redhat.com> Message-ID: <1432819613.19096.138.camel@willson.usersys.redhat.com> On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote: > On 28.5.2015 10:49, Martin Kosek wrote: > > On 05/28/2015 09:05 AM, Petr Spacek wrote: > >> On 28.5.2015 08:55, Jan Cholasta wrote: > >>> Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): > >>>> On 26.5.2015 16:16, Martin Kosek wrote: > >>>>> On 05/26/2015 04:13 PM, thierry bordaz wrote: > >>>>>> On 05/26/2015 02:12 PM, Petr Spacek wrote: > >>>>>>> Hello, > >>>>>>> > >>>>>>> it came to my mind that domain level for topology plugin should actually be > >>>>>>> number 2, not 1. > >>>>>>> > >>>>>>> We already used number 1 for incompatible changes in DNS tree and I believe > >>>>>>> that it is not a good idea to have two places which say 'version 1' but and > >>>>>>> actually mean two different things. (DNS tree version 1 + domain level 1) > >>>>>>> > >>>>>>> Patch is attached. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> Hello, > >>>>>> The fix looks good but that seems strange to have to set the initial > >>>>>> version of > >>>>>> the topology plugin to 2.0. (IIUC That is the version that will be written in > >>>>>> dse.ldif) > >>>>>> I would rather expects that topology plugin 1.0, would activate itself if the > >>>>>> DomainLevel is 2.0 or more. > >>>>>> If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate > >>>>>> itself if DomainLevel >= DomainLevel_trigger. > >>>>>> > >>>>>> Let's wait for Ludwig feedback. > >>>>>> > >>>>>> thanks > >>>>>> thierry > >>>>> > >>>>> My personal opinion on this is to start with Domain Level 1 regardless. We > >>>>> already "solved" the DNS forwarders otherwise, with docs, async updates etc. I > >>>>> do not think we will be returning to implementing proper Domain Level support > >>>>> for that anyway. > >>>>> > >>>>> So I rather think that all the "Domain Level starts with 0, 1 is unused, 2 is > >>>>> the top one" will cause unforeseen issues I would rather like to avoid. > >>>> > >>>> I'm more worried about confusion in future. To to me it simply seems easier to > >>>> bump one integer now than to document and explain (to users & new developers) > >>>> why we have two "ones" which mean something else. > >>>> > >>>> Code-wise it is just an integer. > >>>> > >>>> Also, it can simplify logic in future when we decide to do another > >>>> incompatible change in DNS tree because we will have only one integer to test > >>>> (instead of checking two separate version attribute in DNS tree & domain > >>>> level). > >>> > >>> +1, but I think the minimum supported domain level should be 1, not 0, because > >>> 0 means the server uses the old DNS schema, which we do not support anymore, > >>> right? > >> > >> Good point! > >> > > > > It may be a good point, but it does not make the situation easier. You still > > have RHEL/CentOS 6.x IPA out there, where some of them already support the new > > DNS forwarders and some don't - and neither of them support Domain Levels - > > i.e. have Domain Level 0. > > > > As I said, I still see more complications with this proposals than benefits... > > I would argue that it actually helps. > > If domain level = 1 then we can be *sure* that all replicas support the new > DNS semantics. > > If domain level = 0 then we know nothing (because of patched RHEL 6) and it is > a warning sign for diagnostic tools and also us when it comes to debugging. First of all a domain level is something we change *RARELY*, and it is a whole number and it is an all or nothing thing. I do not understand why plugin versions matter at all, plugin version have nothing to do with domain levels. Each plugin *whatever* the version MUST always support at least 2 levels, because every domain you have will have to go through a domain_level transition when a new domain level comes out. Finally no single developer should be allowed to decide on anew domain level, this must be a well ponder team decision as all plugins that need to change behavior based on domain level will be affected so a thorough review of what changes are needed across all plugins must be done every time someone propose a change that requires a domain level bump. Last but not least we should consider domain levels as something that changes *very* slowly, because otherwise you'll have to support many domain levels within any plugins that have to change behavior according to the domain level. I would say that the domain level should not change more frequently than once a year or so. It would be too much code churn to do otherwise. So for now domain_level should be set to 0. And the topology plugin will be enabled only when we turn it to 1. However we shouldn't turn it to 1 until we have the replica promotion code at least, because only then we can make full use of the topology plugins. The DNS mess is unfixable, unless Petr you volunteer to backport code to change the behavior of the DNS based on the domain level, if that's the case then you can tie old behavior to level 0 and new behavior to level >= 1, but I do not think you want to do that given we already have "level 0" servers that sport the new code and changed the data in the directory, so let's just ignore DNS for the purpose of this discussion, except for nothing that once we finally switch to level 1 then all servers must be running with the newer DNS schema and older is not supported. Ah, I almost forgot, there is no "domain level for XYZ plugin", the domain level is one for the whole server, I want to make it very clear, because the title and part of the discussion seem to imply that you have per-plugin domain levels. If anything like that actually exist in the topology plugin code it must be ripped out now, plugin version and domain level are completely disjointed things and no correlation should or can exist, the only thing that can exist is whether the server, as a whole, supports a specific domain level or not. So once we decide domain level X comes to existence we basically freeze what it means and any new development that may require a domain level bump risk being delayed until we are ready for a new domain level bump, which should not happen very often. So let's make it very clear what level 1 means because the next release will then support only 0 and 1, and once a new version will come out with support for "level 2" we want be able to use any of the features tied to level 2 until all servers in the next release have been upgraded, and that may be a years long process, so we can't just churn domain level numbers as we need to support working on older levels for extended periods. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Thu May 28 13:28:35 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 28 May 2015 09:28:35 -0400 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <20150528091410.GA19176@redhat.com> References: <5565ABCF.5090305@redhat.com> <5565B10F.1090802@redhat.com> <1432734188.3243.117.camel@willson.usersys.redhat.com> <5565CAF3.9020903@redhat.com> <1432734660.3354.53.camel@redhat.com> <5565CE55.50303@redhat.com> <5566A85E.1020906@redhat.com> <5566C790.5060704@redhat.com> <5566CB84.5070601@redhat.com> <5566CF23.90502@redhat.com> <20150528091410.GA19176@redhat.com> Message-ID: <1432819715.19096.139.camel@willson.usersys.redhat.com> On Thu, 2015-05-28 at 12:14 +0300, Alexander Bokovoy wrote: > On Thu, 28 May 2015, Martin Kosek wrote: > >On 05/28/2015 10:02 AM, Jan Cholasta wrote: > >> Dne 28.5.2015 v 09:45 Christian Heimes napsal(a): > >>> On 2015-05-28 07:32, Jan Cholasta wrote: > >>>> Dne 27.5.2015 v 16:01 Christian Heimes napsal(a): > >>>>> On 2015-05-27 15:51, Nathaniel McCallum wrote: > >>>>>> As I understand the problem, there is an assumption that an optional > >>>>>> component has a distinct service to start and stop. That is not the > >>>>>> case here. This is just new config for apache. > >>>>> > >>>>> More details: > >>>>> > >>>>> The KDC Proxy uses the same Apache instance as FreeIPAs Web GUI and > >>>>> Tomcat. There is no extra service involved. The switch just decides if > >>>>> https://ipa.example.org/KdcProxy acts as a MS-KKDCP end point or returns > >>>>> a 404 error. > >>>> > >>>> FYI Tomcat does not use the same Apache instance, the Apache instance is > >>>> configured to proxy requests to Tomcat. > >>>> > >>>> If the IPA KDC proxy package is not installed on a replica, then going > >>>> to /KdcProxy will return 404, right? Why is an additional switch > >>>> necessary then? > >>> > >>> The python-kdcproxy package is a new dependency for the freeipa-server > >>> package. It will always get installed with the server. > >> > >> Why? None of the IPA core functionality depends on it, so it should be > >> optional. Also the overall trend in IPA is to have everything in subpackages. > > > >Do not look at it as a separate component. It is mostly just a new transport > >for Kerberos. FreeIPA already provides Kerberos via TCP and UDP. This is a > >third transport - HTTP. > See my other response. With changes in https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-00 > we'll need to manage _kerberos.$DOMAIN URI DNS record (not just TXT one > like now) to explicitly report where the proxies are located. This goes > beyond just global switch in LDAP and requires ipa-kdcproxy-manage tool. Not really, we'll use the enable/disable switch to find out which DNS records to publish, like we do for SRV records now, not special tool is needed for now. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Thu May 28 13:28:50 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 May 2015 15:28:50 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <1432818404.19096.125.camel@willson.usersys.redhat.com> References: <555F03DB.3090702@redhat.com> <556493D3.8010402@redhat.com> <55659335.2060306@redhat.com> <20150527095322.GM19176@redhat.com> <55659571.8070705@redhat.com> <5565AB70.7020004@redhat.com> <5565ABCF.5090305@redhat.com> <5565B10F.1090802@redhat.com> <1432734188.3243.117.camel@willson.usersys.redhat.com> <5565CAF3.9020903@redhat.com> <1432734868.3243.121.camel@willson.usersys.redhat.com> <5566AAB8.2050609@redhat.com> <1432818404.19096.125.camel@willson.usersys.redhat.com> Message-ID: <55671812.6040704@redhat.com> On 05/28/2015 03:06 PM, Simo Sorce wrote: > On Thu, 2015-05-28 at 07:42 +0200, Jan Cholasta wrote: >> Dne 27.5.2015 v 15:54 Simo Sorce napsal(a): >>> On Wed, 2015-05-27 at 15:47 +0200, Jan Cholasta wrote: >>>> Dne 27.5.2015 v 15:43 Simo Sorce napsal(a): >>>>> On Wed, 2015-05-27 at 13:57 +0200, Jan Cholasta wrote: >>>>>>>> >>>>>>>> ipa config-mod --enable-kdcproxy=TRUE >>>>>>>> ipa config-mod --enable-kdcproxy=FALSE >>>>>> >>>>>> I don't like this approach, as it is completely inconsistent with >>>>>> every >>>>>> other optional component. There should be *one* way to handle them >>>>>> and >>>>>> there already is one, no need to reinvent the wheel. >>>>> >>>>> Sorry Jan, but this is really the correct approach. >>>> >>>> I don't think so. >>>> >>>>> >>>>> We want a boolean in LDAP to control whether the IPA Domain allows >>>>> proxying or not, the code is embedded in the overall framework and has >>>>> no need for explicit install/uninstall unlike the CA or DNS components. >>>> >>>> There is a boolean for every other component/service as well. If you >>>> want to add new API to manipulate the boolean, fine, but it should be >>>> done in a generic way that works for other components as well. >>> >>> This is the same as: >>> ipa config-mod --enable-migration=TRUE >>> >>> Why is it a problem ? >> >> This is a switch to enable the migrate-ds plugin. I think it's hardly >> fair to compare it to a whole new component which provides a new service >> to the outside world. > > Well, this is the problem, I guess there is a perception issue. The KDC > Proxy is basically nothing more than adding a new protocol to the KDC. > It doesn't really do anything special but getting packets on HTTPS and > sending them to the KDC over TCP. > SO I think that for this specific case the KDC Proxy really is > comparable to migration mode (actually simpler than migration). > >>> This is not a separate service. >> >> How is it not a separate service? If it's installed, MS-KKDCP is >> provided to the outside world, and if it's not installed MS-KKDCP is not >> provided to the outside world. > > If the migration plugin is installed the service is provided, if it is > not installed it is not provided, it is conceptually the same. Yes there > is code involved, but we plan to have the proxy always provided. There > is no plan to have it as a removable component, you can only enable or > disable it, like for migration. > >> How is this different from, say, DNS? >> (Besides implementation details, such as what protocols or how many >> daemons it uses - think about IPA as a black box for a moment.) > > It is completely different in size and scope, the KDCProxy really is > just an enabler to reach the KDC over a different protocol, it is not a > whole new protocol and service. > > In the end it is a matter of perspective, I think most of the people > that have been dealing with it think it is much like migration and not > an entire new service like DNS. In the end, Alexander had a good point that there will be some needed associated configuration changes in DNS, when the KdcProxy is enabled/disabled: http://www.redhat.com/archives/freeipa-devel/2015-May/msg00522.html In which case, we may want to end up with more complicated API/CLI (ipa-kdcproxy-manage) than just config-mod command. We now mostly settled to per replica configuration, postponing powerful API/CLI for later: http://www.redhat.com/archives/freeipa-devel/2015-May/msg00535.html Martin From simo at redhat.com Thu May 28 13:30:49 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 28 May 2015 09:30:49 -0400 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <5566E9A1.70108@redhat.com> References: <20150527095322.GM19176@redhat.com> <55659571.8070705@redhat.com> <5565AB70.7020004@redhat.com> <5565ABCF.5090305@redhat.com> <5565B10F.1090802@redhat.com> <1432734188.3243.117.camel@willson.usersys.redhat.com> <5565CAF3.9020903@redhat.com> <1432734868.3243.121.camel@willson.usersys.redhat.com> <5566AAB8.2050609@redhat.com> <5566CEDA.5010701@redhat.com> <20150528091225.GZ19176@redhat.com> <5566E715.1060307@redhat.com> <5566E9A1.70108@redhat.com> Message-ID: <1432819849.19096.141.camel@willson.usersys.redhat.com> On Thu, 2015-05-28 at 12:10 +0200, Petr Spacek wrote: > On 28.5.2015 11:59, Martin Kosek wrote: > > On 05/28/2015 11:12 AM, Alexander Bokovoy wrote: > >> On Thu, 28 May 2015, Petr Spacek wrote: > >>> On 28.5.2015 07:42, Jan Cholasta wrote: > >>>> Dne 27.5.2015 v 15:54 Simo Sorce napsal(a): > >>>>> On Wed, 2015-05-27 at 15:47 +0200, Jan Cholasta wrote: > >>>>>> Dne 27.5.2015 v 15:43 Simo Sorce napsal(a): > >>>>>>> On Wed, 2015-05-27 at 13:57 +0200, Jan Cholasta wrote: > >>>>>>>>>> > >>>>>>>>>> ipa config-mod --enable-kdcproxy=TRUE > >>>>>>>>>> ipa config-mod --enable-kdcproxy=FALSE > >>>>>>>> > >>>>>>>> I don't like this approach, as it is completely inconsistent with > >>>>>>>> every > >>>>>>>> other optional component. There should be *one* way to handle them > >>>>>>>> and > >>>>>>>> there already is one, no need to reinvent the wheel. > >>>>>>> > >>>>>>> Sorry Jan, but this is really the correct approach. > >>>>>> > >>>>>> I don't think so. > >>>>>> > >>>>>>> > >>>>>>> We want a boolean in LDAP to control whether the IPA Domain allows > >>>>>>> proxying or not, the code is embedded in the overall framework and has > >>>>>>> no need for explicit install/uninstall unlike the CA or DNS components. > >>>>>> > >>>>>> There is a boolean for every other component/service as well. If you > >>>>>> want to add new API to manipulate the boolean, fine, but it should be > >>>>>> done in a generic way that works for other components as well. > >>>>> > >>>>> This is the same as: > >>>>> ipa config-mod --enable-migration=TRUE > >>>>> > >>>>> Why is it a problem ? > >>>> > >>>> This is a switch to enable the migrate-ds plugin. I think it's hardly fair to > >>>> compare it to a whole new component which provides a new service to the > >>>> outside world. > >>>> > >>>>> This is not a separate service. > >>>> > >>>> How is it not a separate service? If it's installed, MS-KKDCP is provided to > >>>> the outside world, and if it's not installed MS-KKDCP is not provided to the > >>>> outside world. How is this different from, say, DNS? (Besides implementation > >>>> details, such as what protocols or how many daemons it uses - think about IPA > >>>> as a black box for a moment.) > >>> > >>> I very much agree with Honza - we have per-replica boolean for every service > >>> so there is no reason not to have one for kdc proxy, especially when we > >>> consider future containerization of services. > >> A mere 'me too' here. Note that once updates to RFC 4120 as outlined in > >> https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-00 > >> would be accepted, clients will not be assuming all of replicas serve > >> MS-KKDCP proxies so there will not be need to run them everywhere. > >> Rather, only the servers on a network boundary will need to be > >> advertised. This means we'll eventually get per-replica need as well. > >> > >> It is fine to assume right now that all of them are going to run > >> MS-KKDCP proxy but configuration isn't really going to be global. > >> > >> Additionally, ipa-kdcproxy-manage would need to manipulate > >> _kerberos.$DOMAIN URI DNS records too, so there is more than just > >> switching the boolean here. > > > > I see. My question is - if we go this way, what is then the reasonable subset > > configuration functionality realistic for FreeIPA 4.2 GA? (As we want this > > feature in for 4.2). Is ipa-kdcproxy-manage doable? > > > > What is the proposed API here? > > > > ipa-kdcproxy-manage list > > ipa-kdcproxy-manage enable > > ipa-kdcproxy-manage disable > > I believe that for 4.2 it is perfectly enough to have per-replica switch in > LDAP (enabled by default) and to provide ldapmodify command in docs. User > interface can be polished later if we get the design right. For 4.2 is actually perfectly fine to have a global switch. If someone wants to pick and choose they can disable the embedded proxy and explicitly install one where they want. Let's not complicate simple things please. Later on, if we want, it will be simple enough to add per replica switches which will be checked only if the proxy is globally enabled with the current switch. Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Thu May 28 13:35:25 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 28 May 2015 15:35:25 +0200 Subject: [Freeipa-devel] [PATCH 429] replica-install: Allow install on top of already configured client In-Reply-To: <55649609.2020203@redhat.com> References: <555CA7E7.6050808@redhat.com> <55649609.2020203@redhat.com> Message-ID: <5567199D.7010100@redhat.com> Dne 26.5.2015 v 17:49 Jan Cholasta napsal(a): > Dne 20.5.2015 v 17:27 Jan Cholasta napsal(a): >> Hi, >> >> the attached patch implements the initial bits for >> . >> >> Test by running ipa-client-install and then ipa-replica-install on the >> same host. > > Updated patch attached. Another update, patch attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-429.2-replica-install-Allow-install-on-top-of-already-conf.patch Type: text/x-patch Size: 13532 bytes Desc: not available URL: From cheimes at redhat.com Thu May 28 13:35:53 2015 From: cheimes at redhat.com (Christian Heimes) Date: Thu, 28 May 2015 15:35:53 +0200 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <55671812.6040704@redhat.com> References: <555F03DB.3090702@redhat.com> <556493D3.8010402@redhat.com> <55659335.2060306@redhat.com> <20150527095322.GM19176@redhat.com> <55659571.8070705@redhat.com> <5565AB70.7020004@redhat.com> <5565ABCF.5090305@redhat.com> <5565B10F.1090802@redhat.com> <1432734188.3243.117.camel@willson.usersys.redhat.com> <5565CAF3.9020903@redhat.com> <1432734868.3243.121.camel@willson.usersys.redhat.com> <5566AAB8.2050609@redhat.com> <1432818404.19096.125.camel@willson.usersys.redhat.com> <55671812.6040704@redhat.com> Message-ID: <556719B9.1040104@redhat.com> On 2015-05-28 15:28, Martin Kosek wrote: > In the end, Alexander had a good point that there will be some needed > associated configuration changes in DNS, when the KdcProxy is enabled/disabled: > > http://www.redhat.com/archives/freeipa-devel/2015-May/msg00522.html > > In which case, we may want to end up with more complicated API/CLI > (ipa-kdcproxy-manage) than just config-mod command. We now mostly settled to > per replica configuration, postponing powerful API/CLI for later: > > http://www.redhat.com/archives/freeipa-devel/2015-May/msg00535.html Thanks Martin, Rob gave me some feedback on IRC, too. I'm going to sum up the decisions and my plans for ACI/permission in a new thread. Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From derny at redhat.com Thu May 28 13:40:10 2015 From: derny at redhat.com (Drew Erny) Date: Thu, 28 May 2015 09:40:10 -0400 Subject: [Freeipa-devel] Sudorules user validation help In-Reply-To: <5566D557.9030503@redhat.com> References: <55660FDE.3030202@redhat.com> <5566D557.9030503@redhat.com> Message-ID: <55671ABA.9090709@redhat.com> OK, I see now what you mean by that. That is a simpler solution. I'll do it that way. On 05/28/2015 04:44 AM, Martin Kosek wrote: > On 05/27/2015 08:41 PM, Drew Erny wrote: >> Hey, Freeipa-devel, >> >> I'm working on ticket #3226 (https://fedorahosted.org/freeipa/ticket/3226) >> >> I've identified the problem. The sudorules add user command adds the user >> validations at the end of it's pre-callback using add_external_pre_callback. >> However, the "user" plugin pattern-matches a string for the "uid" param, >> because it only allows certain characters. >> >> I've been picking through the codebase and I think I have enough understanding >> to ask this: What if we changed the user "uid" validation to a standalone >> "rule" function (you can do that, right? pass in a function as a validation >> rule?) that would normally just assert that the pattern matches, but could have >> that pattern matching validation overridden in some cases. I think that's the >> easiest, cleanest way to change user so that sudorules and other plugins can >> ignore this validation if necessary (I'm trying to figure out exactly how to >> implement this without changing any APIs). >> >> Am I understanding the plugin params API correctly, and can I do this? Is this >> the best way to do this? >> >> The only other solution I see is to write sudorules-specific code in some >> plugin-related (either user.py or baseldap.py module, which would create >> unwanted coupling. >> >> Most specifically, this would be a change to the object instantiated at >> ipalib/plugins/user.py line 467 >> >> Thoughts and suggestions? > I think it would make sense to follow the example with validate_hostname and > prepare a function validate_username(username, upn=False, netbios_name=False) [1]. > > where upn would allow using "@." on top of current validator (i.e. > user at Domain.test) and netbios_name would allow the "DOMAIN\user" style. I would > just suggest making sure the standard user validation error message is still > the same to avoid unnecessary QE fail positives. > > In add_external_pre_callback you could then just simply call > > validate_username(user, True, True) > > just like it is already done with hostname. > > My 2 cents. > > Martin > > [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa380525(v=vs.85).aspx From mkosek at redhat.com Thu May 28 13:43:02 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 May 2015 15:43:02 +0200 Subject: [Freeipa-devel] [PATCH 0014] Support multiple user and host certificates In-Reply-To: <55670A25.1000307@redhat.com> References: <20150527135315.GC24915@dhcp-40-8.bne.redhat.com> <5565ED02.6060709@redhat.com> <5566D5FC.7090307@redhat.com> <5566DD1D.7040009@redhat.com> <5566E559.8020709@redhat.com> <20150528100615.GD9628@dhcp-40-8.bne.redhat.com> <55670A25.1000307@redhat.com> Message-ID: <55671B66.8080004@redhat.com> On 05/28/2015 02:29 PM, Petr Spacek wrote: > On 28.5.2015 12:06, Fraser Tweedale wrote: >> On Thu, May 28, 2015 at 11:52:25AM +0200, Martin Kosek wrote: >>> On 05/28/2015 11:17 AM, Martin Basti wrote: >>>> On 28/05/15 10:46, Martin Kosek wrote: >>>>> On 05/27/2015 06:12 PM, Martin Basti wrote: >>>>>> On 27/05/15 15:53, Fraser Tweedale wrote: >>>>>>> This patch adds supports for multiple user / host certificates. No >>>>>>> schema change is needed ('usercertificate' attribute is already >>>>>>> multi-value). The revoke-previous-cert behaviour of host-mod and >>>>>>> user-mod has been removed but revocation behaviour of -del and >>>>>>> -disable is preserved. >>>>>>> >>>>>>> The latest profiles/caacl patchset (0001..0013 v5) depends on this >>>>>>> patch for correct cert-request behaviour. >>>>>>> >>>>>>> There is one design question (or maybe more, let me know): the >>>>>>> `--out=FILENAME' option to {host,service} show saves ONE certificate >>>>>>> to the named file. I propose to either: >>>>>>> >>>>>>> a) write all certs, suffixing suggested filename with either a >>>>>>> sequential numerical index, e.g. "cert.pem" becomes >>>>>>> "cert.pem.1", "cert.pem.2", and so on; or >>>>>>> >>>>>>> b) as above, but suffix with serial number and, if there are >>>>>>> different issues, some issuer-identifying information. >>>>>>> >>>>>>> Let me know your thoughts. >>>>>>> >>>>>>> Thanks, >>>>>>> Fraser >>>>>>> >>>>>>> >>>>>> Is there a possible way how to store certificates into one file? >>>>>> I read about possibilities to have multiple certs in one .pem file, but I'm not >>>>>> cert guru :) >>>>>> >>>>>> I personally vote for serial number in case there are multiple certificates, if >>>>>> ^ is no possible. >>>>>> >>>>>> >>>>>> 1) >>>>>> + if len(certs) > 0: >>>>>> >>>>>> please use only, >>>>>> if certs: >>>>>> >>>>>> 2) >>>>>> You need to re-generate API/ACI.txt in this patch >>>>>> >>>>>> 3) >>>>>> syntax error: >>>>>> + for dercert in certs_der >>>>>> >>>>>> >>>>>> 4) >>>>>> command >>>>>> ipa user-mod ca_user --certificate= >>>>>> >>>>>> removes the current certificate from the LDAP, by design. >>>>>> Should be the old certificate(s) revoked? You removed that part in the code. >>>>> Good question. I think the suggestion was to have a global switch in IPA global >>>>> config that would configure the policy - whether the certificates removed by >>>>> this command or by host-del or host-disable are revoked or if they are just >>>>> removed (my motivation is to avoid behavior regression in case somebody >>>>> depended on this behavior). >>>> I would prefer to keep the current behavior: revoke the certificate if it was >>>> replaced or removed, instead of adding an extra configuration option. >>>> This behavior is not regression. >>> >>> It is not. However, it is not an ideal behavior also. In FreeIPA 4.2, we are >>> now adding support of certificate profiles, multiple certificates and even >>> certificates for user. >>> >>> With that change, there may be much more certificates in play than now. If we >>> keep revoking all such certificates, it may cause rapid growth of CRLs. This is >>> something I am trying to avoid with this proposal and default to not revoking >>> certificates automatically (which mostly only makes sense if there is a risk >>> that the key is compromised), but have some option to keep the old behavior. >>> >>> Does this make sense? > > I would like to see some data to support the decision not to revoke certs by > default. Are there some facts to base the decision on? Or just hand-wavy > reasoning? What facts would you like to hear? If we are speaking from bugs, we already know that large CRL lists caused lot of grief to deployments with bug host/service turnaround. I do not have more data than this, besides my expectation that there may be much more certificates tracked by FreeIPA than in the past and we need to deal with it. > Sure, huge CRL may be bad, but not revoking certs may be even worse. E.g. when > older backup files are stolen (in the information sense, i.e. copied without > anyone noticing it) - attacker might get valid certs despite the fact that the > old cert is never used (because it was rotated right after the backup). I am not convinced that this is a valid point. We cannot assume that FreeIPA administrator leaks certificate keys and try to magically fix that by this policy. Such fault backup can leak even when the host/service still exists. This is about what makes most sense for certificate handling, what is the secure behavior and a behavior that most administrators would expect (thus the default). Are you sure revoking all deleted certificates is the expected behavior? In my mind, certificates are being revoked from more serious reasons - when employee "leaves" a company, machine (or it's backup) is compromised, etc. But in that case admin would use cert-revoke command. Let me also CC Rob - do we know why FreeIPA was implemented to revoke all service/host certificates by default on deletion/disable? > IMHO this behavior should be configurable and default to 'revoke'. We should > ship FreeIPA with secure defaults and let users to lower the standards if they > wish/need. > > Petr^2 Spacek From mkosek at redhat.com Thu May 28 13:47:17 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 May 2015 15:47:17 +0200 Subject: [Freeipa-devel] New replica installation and topology - we need stable base In-Reply-To: <5565DBB7.1030304@redhat.com> References: <5565DBB7.1030304@redhat.com> Message-ID: <55671C65.3020406@redhat.com> On 05/27/2015 04:59 PM, Martin Kosek wrote: ... > Domain Levels > - Done, committed > - Defaults to Level 1, i.e. Topology plugin powered infra enabled With respect to related Simo's response in http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html Would we want to enable Topology (i.e. Domain Level 1) even if Replica promotion is not done? I thought we do as I see those as orthogonal features. Replica promotion would take advantage of the Topology plugin, but it does not mean you cannot benefit from Topology plugin without it. You can still use the API to see/manage the topology and set replication settings with it. You do not need Replica Promotion for that... From lkrispen at redhat.com Thu May 28 13:54:32 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 28 May 2015 15:54:32 +0200 Subject: [Freeipa-devel] Domain level for topology plugin = 2 In-Reply-To: <1432819613.19096.138.camel@willson.usersys.redhat.com> References: <55646331.5050807@redhat.com> <55647F90.506@redhat.com> <5564804B.6080305@redhat.com> <5564841B.4020906@redhat.com> <5566BBFD.9070601@redhat.com> <5566BE3E.2060104@redhat.com> <5566D684.6080505@redhat.com> <5567060D.5010202@redhat.com> <1432819613.19096.138.camel@willson.usersys.redhat.com> Message-ID: <55671E18.8020807@redhat.com> On 05/28/2015 03:26 PM, Simo Sorce wrote: > On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote: >> On 28.5.2015 10:49, Martin Kosek wrote: >>> On 05/28/2015 09:05 AM, Petr Spacek wrote: >>>> On 28.5.2015 08:55, Jan Cholasta wrote: >>>>> Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): >>>>>> On 26.5.2015 16:16, Martin Kosek wrote: >>>>>>> On 05/26/2015 04:13 PM, thierry bordaz wrote: >>>>>>>> On 05/26/2015 02:12 PM, Petr Spacek wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> it came to my mind that domain level for topology plugin should actually be >>>>>>>>> number 2, not 1. >>>>>>>>> >>>>>>>>> We already used number 1 for incompatible changes in DNS tree and I believe >>>>>>>>> that it is not a good idea to have two places which say 'version 1' but and >>>>>>>>> actually mean two different things. (DNS tree version 1 + domain level 1) >>>>>>>>> >>>>>>>>> Patch is attached. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Hello, >>>>>>>> The fix looks good but that seems strange to have to set the initial >>>>>>>> version of >>>>>>>> the topology plugin to 2.0. (IIUC That is the version that will be written in >>>>>>>> dse.ldif) >>>>>>>> I would rather expects that topology plugin 1.0, would activate itself if the >>>>>>>> DomainLevel is 2.0 or more. >>>>>>>> If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate >>>>>>>> itself if DomainLevel >= DomainLevel_trigger. >>>>>>>> >>>>>>>> Let's wait for Ludwig feedback. >>>>>>>> >>>>>>>> thanks >>>>>>>> thierry >>>>>>> My personal opinion on this is to start with Domain Level 1 regardless. We >>>>>>> already "solved" the DNS forwarders otherwise, with docs, async updates etc. I >>>>>>> do not think we will be returning to implementing proper Domain Level support >>>>>>> for that anyway. >>>>>>> >>>>>>> So I rather think that all the "Domain Level starts with 0, 1 is unused, 2 is >>>>>>> the top one" will cause unforeseen issues I would rather like to avoid. >>>>>> I'm more worried about confusion in future. To to me it simply seems easier to >>>>>> bump one integer now than to document and explain (to users & new developers) >>>>>> why we have two "ones" which mean something else. >>>>>> >>>>>> Code-wise it is just an integer. >>>>>> >>>>>> Also, it can simplify logic in future when we decide to do another >>>>>> incompatible change in DNS tree because we will have only one integer to test >>>>>> (instead of checking two separate version attribute in DNS tree & domain >>>>>> level). >>>>> +1, but I think the minimum supported domain level should be 1, not 0, because >>>>> 0 means the server uses the old DNS schema, which we do not support anymore, >>>>> right? >>>> Good point! >>>> >>> It may be a good point, but it does not make the situation easier. You still >>> have RHEL/CentOS 6.x IPA out there, where some of them already support the new >>> DNS forwarders and some don't - and neither of them support Domain Levels - >>> i.e. have Domain Level 0. >>> >>> As I said, I still see more complications with this proposals than benefits... >> I would argue that it actually helps. >> >> If domain level = 1 then we can be *sure* that all replicas support the new >> DNS semantics. >> >> If domain level = 0 then we know nothing (because of patched RHEL 6) and it is >> a warning sign for diagnostic tools and also us when it comes to debugging. > First of all a domain level is something we change *RARELY*, and it is > a whole number and it is an all or nothing thing. > > I do not understand why plugin versions matter at all, plugin version > have nothing to do with domain levels. Each plugin *whatever* the > version MUST always support at least 2 levels, because every domain you > have will have to go through a domain_level transition when a new domain > level comes out. > > Finally no single developer should be allowed to decide on anew domain > level, this must be a well ponder team decision as all plugins that need > to change behavior based on domain level will be affected so a thorough > review of what changes are needed across all plugins must be done every > time someone propose a change that requires a domain level bump. > > Last but not least we should consider domain levels as something that > changes *very* slowly, because otherwise you'll have to support many > domain levels within any plugins that have to change behavior according > to the domain level. > I would say that the domain level should not change more frequently than > once a year or so. It would be too much code churn to do otherwise. > > So for now domain_level should be set to 0. And the topology plugin will > be enabled only when we turn it to 1. However we shouldn't turn it to 1 > until we have the replica promotion code at least, because only then we > can make full use of the topology plugins. > > The DNS mess is unfixable, unless Petr you volunteer to backport code to > change the behavior of the DNS based on the domain level, if that's the > case then you can tie old behavior to level 0 and new behavior to level >> = 1, but I do not think you want to do that given we already have > "level 0" servers that sport the new code and changed the data in the > directory, so let's just ignore DNS for the purpose of this discussion, > except for nothing that once we finally switch to level 1 then all > servers must be running with the newer DNS schema and older is not > supported. > > Ah, I almost forgot, there is no "domain level for XYZ plugin", the > domain level is one for the whole server, I want to make it very clear, > because the title and part of the discussion seem to imply that you have > per-plugin domain levels. If anything like that actually exist in the > topology plugin code it must be ripped out now, plugin version and > domain level are completely disjointed things and no correlation should > or can exist, the only thing that can exist is whether the server, as a > whole, supports a specific domain level or not. > > So once we decide domain level X comes to existence we basically freeze > what it means and any new development that may require a domain level > bump risk being delayed until we are ready for a new domain level bump, > which should not happen very often. > > So let's make it very clear what level 1 means because the next release > will then support only 0 and 1, and once a new version will come out > with support for "level 2" we want be able to use any of the features > tied to level 2 until all servers in the next release have been > upgraded, and that may be a years long process, so we can't just churn > domain level numbers as we need to support working on older levels for > extended periods. Hi Simo, you say the topology plugin should only activate itself if the domain level is >= 1, at the moment this is done by checking if plugin_version (1.0) >= domain_level (1). If you want a different method/fields for decision, how do you want it handled ? > > Simo. > From simo at redhat.com Thu May 28 13:52:43 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 28 May 2015 09:52:43 -0400 Subject: [Freeipa-devel] Domain level for topology plugin = 2 In-Reply-To: <55671AA7.6040002@redhat.com> References: <55646331.5050807@redhat.com> <55647F90.506@redhat.com> <5564804B.6080305@redhat.com> <5564841B.4020906@redhat.com> <5566BBFD.9070601@redhat.com> <5566BE3E.2060104@redhat.com> <5566D684.6080505@redhat.com> <5567060D.5010202@redhat.com> <1432819613.19096.138.camel@willson.usersys.redhat.com> <55671AA7.6040002@redhat.com> Message-ID: <1432821163.19096.146.camel@willson.usersys.redhat.com> On Thu, 2015-05-28 at 15:39 +0200, Oleg Fayans wrote: > > On 05/28/2015 03:26 PM, Simo Sorce wrote: > > On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote: > >> On 28.5.2015 10:49, Martin Kosek wrote: > >>> On 05/28/2015 09:05 AM, Petr Spacek wrote: > >>>> On 28.5.2015 08:55, Jan Cholasta wrote: > >>>>> Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): > >>>>>> On 26.5.2015 16:16, Martin Kosek wrote: > >>>>>>> On 05/26/2015 04:13 PM, thierry bordaz wrote: > >>>>>>>> On 05/26/2015 02:12 PM, Petr Spacek wrote: > >>>>>>>>> Hello, > >>>>>>>>> > >>>>>>>>> it came to my mind that domain level for topology plugin should actually be > >>>>>>>>> number 2, not 1. > >>>>>>>>> > >>>>>>>>> We already used number 1 for incompatible changes in DNS tree and I believe > >>>>>>>>> that it is not a good idea to have two places which say 'version 1' but and > >>>>>>>>> actually mean two different things. (DNS tree version 1 + domain level 1) > >>>>>>>>> > >>>>>>>>> Patch is attached. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> Hello, > >>>>>>>> The fix looks good but that seems strange to have to set the initial > >>>>>>>> version of > >>>>>>>> the topology plugin to 2.0. (IIUC That is the version that will be written in > >>>>>>>> dse.ldif) > >>>>>>>> I would rather expects that topology plugin 1.0, would activate itself if the > >>>>>>>> DomainLevel is 2.0 or more. > >>>>>>>> If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate > >>>>>>>> itself if DomainLevel >= DomainLevel_trigger. > >>>>>>>> > >>>>>>>> Let's wait for Ludwig feedback. > >>>>>>>> > >>>>>>>> thanks > >>>>>>>> thierry > >>>>>>> My personal opinion on this is to start with Domain Level 1 regardless. We > >>>>>>> already "solved" the DNS forwarders otherwise, with docs, async updates etc. I > >>>>>>> do not think we will be returning to implementing proper Domain Level support > >>>>>>> for that anyway. > >>>>>>> > >>>>>>> So I rather think that all the "Domain Level starts with 0, 1 is unused, 2 is > >>>>>>> the top one" will cause unforeseen issues I would rather like to avoid. > >>>>>> I'm more worried about confusion in future. To to me it simply seems easier to > >>>>>> bump one integer now than to document and explain (to users & new developers) > >>>>>> why we have two "ones" which mean something else. > >>>>>> > >>>>>> Code-wise it is just an integer. > >>>>>> > >>>>>> Also, it can simplify logic in future when we decide to do another > >>>>>> incompatible change in DNS tree because we will have only one integer to test > >>>>>> (instead of checking two separate version attribute in DNS tree & domain > >>>>>> level). > >>>>> +1, but I think the minimum supported domain level should be 1, not 0, because > >>>>> 0 means the server uses the old DNS schema, which we do not support anymore, > >>>>> right? > >>>> Good point! > >>>> > >>> It may be a good point, but it does not make the situation easier. You still > >>> have RHEL/CentOS 6.x IPA out there, where some of them already support the new > >>> DNS forwarders and some don't - and neither of them support Domain Levels - > >>> i.e. have Domain Level 0. > >>> > >>> As I said, I still see more complications with this proposals than benefits... > >> I would argue that it actually helps. > >> > >> If domain level = 1 then we can be *sure* that all replicas support the new > >> DNS semantics. > >> > >> If domain level = 0 then we know nothing (because of patched RHEL 6) and it is > >> a warning sign for diagnostic tools and also us when it comes to debugging. > > First of all a domain level is something we change *RARELY*, and it is > > a whole number and it is an all or nothing thing. > > > > I do not understand why plugin versions matter at all, plugin version > > have nothing to do with domain levels. Each plugin *whatever* the > > version MUST always support at least 2 levels, because every domain you > > have will have to go through a domain_level transition when a new domain > > level comes out. > > > > Finally no single developer should be allowed to decide on anew domain > > level, this must be a well ponder team decision as all plugins that need > > to change behavior based on domain level will be affected so a thorough > > review of what changes are needed across all plugins must be done every > > time someone propose a change that requires a domain level bump. > > > > Last but not least we should consider domain levels as something that > > changes *very* slowly, because otherwise you'll have to support many > > domain levels within any plugins that have to change behavior according > > to the domain level. > > I would say that the domain level should not change more frequently than > > once a year or so. It would be too much code churn to do otherwise. > > > > So for now domain_level should be set to 0. And the topology plugin will > > be enabled only when we turn it to 1. However we shouldn't turn it to 1 > > until we have the replica promotion code at least, because only then we > > can make full use of the topology plugins. > Does that mean, that by default domain level must be set to 0 and only > raised manually by the identity admin? Yes, the domain level is established by the first server you install, and CANNOT be raise automatically by a replica, it must be always manually raised by the admin. Moreover the code that raises *MUST* check that all server are capable of handling the new domain level or refuse to raise the level. This means all servers must publish the range of domain levels they support, a missing range means only level 0 is supported. > In the official FreeIPA documentation we explicitly require software > version of replicas to be not below the > corresponding version of master. That means that replicas will in all > cases support this feature. Or did I get it all wrong? What it means is that replicas must support the domain level version of the domain in order to join. It is another reason we want the replica promotion code as this code will also check the domain level is suitable and refuse to continue if the domain level is not supported. It will have to spit an error like: "Domain Level too old, please upgrade your domain to at least level 'X' before trying to join this server" Note: I've put freeipa-devel back in CC as this is useful information for all developers. Simo. > > The DNS mess is unfixable, unless Petr you volunteer to backport code to > > change the behavior of the DNS based on the domain level, if that's the > > case then you can tie old behavior to level 0 and new behavior to level > >> = 1, but I do not think you want to do that given we already have > > "level 0" servers that sport the new code and changed the data in the > > directory, so let's just ignore DNS for the purpose of this discussion, > > except for nothing that once we finally switch to level 1 then all > > servers must be running with the newer DNS schema and older is not > > supported. > > > > Ah, I almost forgot, there is no "domain level for XYZ plugin", the > > domain level is one for the whole server, I want to make it very clear, > > because the title and part of the discussion seem to imply that you have > > per-plugin domain levels. If anything like that actually exist in the > > topology plugin code it must be ripped out now, plugin version and > > domain level are completely disjointed things and no correlation should > > or can exist, the only thing that can exist is whether the server, as a > > whole, supports a specific domain level or not. > > > > So once we decide domain level X comes to existence we basically freeze > > what it means and any new development that may require a domain level > > bump risk being delayed until we are ready for a new domain level bump, > > which should not happen very often. > > > > So let's make it very clear what level 1 means because the next release > > will then support only 0 and 1, and once a new version will come out > > with support for "level 2" we want be able to use any of the features > > tied to level 2 until all servers in the next release have been > > upgraded, and that may be a years long process, so we can't just churn > > domain level numbers as we need to support working on older levels for > > extended periods. > > > > Simo. > > > -- Simo Sorce * Red Hat, Inc * New York From lkrispen at redhat.com Thu May 28 13:57:40 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 28 May 2015 15:57:40 +0200 Subject: [Freeipa-devel] New replica installation and topology - we need stable base In-Reply-To: <55671C65.3020406@redhat.com> References: <5565DBB7.1030304@redhat.com> <55671C65.3020406@redhat.com> Message-ID: <55671ED4.3000800@redhat.com> On 05/28/2015 03:47 PM, Martin Kosek wrote: > On 05/27/2015 04:59 PM, Martin Kosek wrote: > ... >> Domain Levels >> - Done, committed >> - Defaults to Level 1, i.e. Topology plugin powered infra enabled > With respect to related Simo's response in > http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html > > Would we want to enable Topology (i.e. Domain Level 1) even if Replica > promotion is not done? who is we ? I thought there is an api to set the domain-level and the admin decides if, or do you mean to have it by default during installation ? > I thought we do as I see those as orthogonal features. > Replica promotion would take advantage of the Topology plugin, but it does not > mean you cannot benefit from Topology plugin without it. > > You can still use the API to see/manage the topology and set replication > settings with it. You do not need Replica Promotion for that... well, it is not just for viewing, you restrict management to use the ipa-toplogy commands From ssorce at redhat.com Thu May 28 13:57:08 2015 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 28 May 2015 09:57:08 -0400 Subject: [Freeipa-devel] [PATCH 0014] Support multiple user and host certificates In-Reply-To: <55671B66.8080004@redhat.com> References: <20150527135315.GC24915@dhcp-40-8.bne.redhat.com> <5565ED02.6060709@redhat.com> <5566D5FC.7090307@redhat.com> <5566DD1D.7040009@redhat.com> <5566E559.8020709@redhat.com> <20150528100615.GD9628@dhcp-40-8.bne.redhat.com> <55670A25.1000307@redhat.com> <55671B66.8080004@redhat.com> Message-ID: <1432821428.19096.149.camel@willson.usersys.redhat.com> On Thu, 2015-05-28 at 15:43 +0200, Martin Kosek wrote: > On 05/28/2015 02:29 PM, Petr Spacek wrote: > > On 28.5.2015 12:06, Fraser Tweedale wrote: > >> On Thu, May 28, 2015 at 11:52:25AM +0200, Martin Kosek wrote: > >>> On 05/28/2015 11:17 AM, Martin Basti wrote: > >>>> On 28/05/15 10:46, Martin Kosek wrote: > >>>>> On 05/27/2015 06:12 PM, Martin Basti wrote: > >>>>>> On 27/05/15 15:53, Fraser Tweedale wrote: > >>>>>>> This patch adds supports for multiple user / host certificates. No > >>>>>>> schema change is needed ('usercertificate' attribute is already > >>>>>>> multi-value). The revoke-previous-cert behaviour of host-mod and > >>>>>>> user-mod has been removed but revocation behaviour of -del and > >>>>>>> -disable is preserved. > >>>>>>> > >>>>>>> The latest profiles/caacl patchset (0001..0013 v5) depends on this > >>>>>>> patch for correct cert-request behaviour. > >>>>>>> > >>>>>>> There is one design question (or maybe more, let me know): the > >>>>>>> `--out=FILENAME' option to {host,service} show saves ONE certificate > >>>>>>> to the named file. I propose to either: > >>>>>>> > >>>>>>> a) write all certs, suffixing suggested filename with either a > >>>>>>> sequential numerical index, e.g. "cert.pem" becomes > >>>>>>> "cert.pem.1", "cert.pem.2", and so on; or > >>>>>>> > >>>>>>> b) as above, but suffix with serial number and, if there are > >>>>>>> different issues, some issuer-identifying information. > >>>>>>> > >>>>>>> Let me know your thoughts. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Fraser > >>>>>>> > >>>>>>> > >>>>>> Is there a possible way how to store certificates into one file? > >>>>>> I read about possibilities to have multiple certs in one .pem file, but I'm not > >>>>>> cert guru :) > >>>>>> > >>>>>> I personally vote for serial number in case there are multiple certificates, if > >>>>>> ^ is no possible. > >>>>>> > >>>>>> > >>>>>> 1) > >>>>>> + if len(certs) > 0: > >>>>>> > >>>>>> please use only, > >>>>>> if certs: > >>>>>> > >>>>>> 2) > >>>>>> You need to re-generate API/ACI.txt in this patch > >>>>>> > >>>>>> 3) > >>>>>> syntax error: > >>>>>> + for dercert in certs_der > >>>>>> > >>>>>> > >>>>>> 4) > >>>>>> command > >>>>>> ipa user-mod ca_user --certificate= > >>>>>> > >>>>>> removes the current certificate from the LDAP, by design. > >>>>>> Should be the old certificate(s) revoked? You removed that part in the code. > >>>>> Good question. I think the suggestion was to have a global switch in IPA global > >>>>> config that would configure the policy - whether the certificates removed by > >>>>> this command or by host-del or host-disable are revoked or if they are just > >>>>> removed (my motivation is to avoid behavior regression in case somebody > >>>>> depended on this behavior). > >>>> I would prefer to keep the current behavior: revoke the certificate if it was > >>>> replaced or removed, instead of adding an extra configuration option. > >>>> This behavior is not regression. > >>> > >>> It is not. However, it is not an ideal behavior also. In FreeIPA 4.2, we are > >>> now adding support of certificate profiles, multiple certificates and even > >>> certificates for user. > >>> > >>> With that change, there may be much more certificates in play than now. If we > >>> keep revoking all such certificates, it may cause rapid growth of CRLs. This is > >>> something I am trying to avoid with this proposal and default to not revoking > >>> certificates automatically (which mostly only makes sense if there is a risk > >>> that the key is compromised), but have some option to keep the old behavior. > >>> > >>> Does this make sense? > > > > I would like to see some data to support the decision not to revoke certs by > > default. Are there some facts to base the decision on? Or just hand-wavy > > reasoning? > > What facts would you like to hear? If we are speaking from bugs, we already > know that large CRL lists caused lot of grief to deployments with bug > host/service turnaround. I do not have more data than this, besides my > expectation that there may be much more certificates tracked by FreeIPA than in > the past and we need to deal with it. > > > Sure, huge CRL may be bad, but not revoking certs may be even worse. E.g. when > > older backup files are stolen (in the information sense, i.e. copied without > > anyone noticing it) - attacker might get valid certs despite the fact that the > > old cert is never used (because it was rotated right after the backup). > > I am not convinced that this is a valid point. We cannot assume that FreeIPA > administrator leaks certificate keys and try to magically fix that by this > policy. Such fault backup can leak even when the host/service still exists. > > This is about what makes most sense for certificate handling, what is the > secure behavior and a behavior that most administrators would expect (thus the > default). Are you sure revoking all deleted certificates is the expected > behavior? In my mind, certificates are being revoked from more serious reasons > - when employee "leaves" a company, machine (or it's backup) is compromised, > etc. But in that case admin would use cert-revoke command. > > Let me also CC Rob - do we know why FreeIPA was implemented to revoke all > service/host certificates by default on deletion/disable? +1 Martin, by default you assume minimally competent admins that do not leak private key. If you cannot assume that then you have already lost, revoking certs will help nothing as there are a ton of certs and keytabs that can be used by an attacker and are still valid then. In general Revocations are used when there is a real chance a private key have been compromised because they are costly. Simo. From lkrispen at redhat.com Thu May 28 14:01:26 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 28 May 2015 16:01:26 +0200 Subject: [Freeipa-devel] Domain level for topology plugin = 2 In-Reply-To: <1432821163.19096.146.camel@willson.usersys.redhat.com> References: <55646331.5050807@redhat.com> <55647F90.506@redhat.com> <5564804B.6080305@redhat.com> <5564841B.4020906@redhat.com> <5566BBFD.9070601@redhat.com> <5566BE3E.2060104@redhat.com> <5566D684.6080505@redhat.com> <5567060D.5010202@redhat.com> <1432819613.19096.138.camel@willson.usersys.redhat.com> <55671AA7.6040002@redhat.com> <1432821163.19096.146.camel@willson.usersys.redhat.com> Message-ID: <55671FB6.6050104@redhat.com> On 05/28/2015 03:52 PM, Simo Sorce wrote: > On Thu, 2015-05-28 at 15:39 +0200, Oleg Fayans wrote: >> On 05/28/2015 03:26 PM, Simo Sorce wrote: >>> On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote: >>>> On 28.5.2015 10:49, Martin Kosek wrote: >>>>> On 05/28/2015 09:05 AM, Petr Spacek wrote: >>>>>> On 28.5.2015 08:55, Jan Cholasta wrote: >>>>>>> Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): >>>>>>>> On 26.5.2015 16:16, Martin Kosek wrote: >>>>>>>>> On 05/26/2015 04:13 PM, thierry bordaz wrote: >>>>>>>>>> On 05/26/2015 02:12 PM, Petr Spacek wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> it came to my mind that domain level for topology plugin should actually be >>>>>>>>>>> number 2, not 1. >>>>>>>>>>> >>>>>>>>>>> We already used number 1 for incompatible changes in DNS tree and I believe >>>>>>>>>>> that it is not a good idea to have two places which say 'version 1' but and >>>>>>>>>>> actually mean two different things. (DNS tree version 1 + domain level 1) >>>>>>>>>>> >>>>>>>>>>> Patch is attached. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> The fix looks good but that seems strange to have to set the initial >>>>>>>>>> version of >>>>>>>>>> the topology plugin to 2.0. (IIUC That is the version that will be written in >>>>>>>>>> dse.ldif) >>>>>>>>>> I would rather expects that topology plugin 1.0, would activate itself if the >>>>>>>>>> DomainLevel is 2.0 or more. >>>>>>>>>> If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate >>>>>>>>>> itself if DomainLevel >= DomainLevel_trigger. >>>>>>>>>> >>>>>>>>>> Let's wait for Ludwig feedback. >>>>>>>>>> >>>>>>>>>> thanks >>>>>>>>>> thierry >>>>>>>>> My personal opinion on this is to start with Domain Level 1 regardless. We >>>>>>>>> already "solved" the DNS forwarders otherwise, with docs, async updates etc. I >>>>>>>>> do not think we will be returning to implementing proper Domain Level support >>>>>>>>> for that anyway. >>>>>>>>> >>>>>>>>> So I rather think that all the "Domain Level starts with 0, 1 is unused, 2 is >>>>>>>>> the top one" will cause unforeseen issues I would rather like to avoid. >>>>>>>> I'm more worried about confusion in future. To to me it simply seems easier to >>>>>>>> bump one integer now than to document and explain (to users & new developers) >>>>>>>> why we have two "ones" which mean something else. >>>>>>>> >>>>>>>> Code-wise it is just an integer. >>>>>>>> >>>>>>>> Also, it can simplify logic in future when we decide to do another >>>>>>>> incompatible change in DNS tree because we will have only one integer to test >>>>>>>> (instead of checking two separate version attribute in DNS tree & domain >>>>>>>> level). >>>>>>> +1, but I think the minimum supported domain level should be 1, not 0, because >>>>>>> 0 means the server uses the old DNS schema, which we do not support anymore, >>>>>>> right? >>>>>> Good point! >>>>>> >>>>> It may be a good point, but it does not make the situation easier. You still >>>>> have RHEL/CentOS 6.x IPA out there, where some of them already support the new >>>>> DNS forwarders and some don't - and neither of them support Domain Levels - >>>>> i.e. have Domain Level 0. >>>>> >>>>> As I said, I still see more complications with this proposals than benefits... >>>> I would argue that it actually helps. >>>> >>>> If domain level = 1 then we can be *sure* that all replicas support the new >>>> DNS semantics. >>>> >>>> If domain level = 0 then we know nothing (because of patched RHEL 6) and it is >>>> a warning sign for diagnostic tools and also us when it comes to debugging. >>> First of all a domain level is something we change *RARELY*, and it is >>> a whole number and it is an all or nothing thing. >>> >>> I do not understand why plugin versions matter at all, plugin version >>> have nothing to do with domain levels. Each plugin *whatever* the >>> version MUST always support at least 2 levels, because every domain you >>> have will have to go through a domain_level transition when a new domain >>> level comes out. >>> >>> Finally no single developer should be allowed to decide on anew domain >>> level, this must be a well ponder team decision as all plugins that need >>> to change behavior based on domain level will be affected so a thorough >>> review of what changes are needed across all plugins must be done every >>> time someone propose a change that requires a domain level bump. >>> >>> Last but not least we should consider domain levels as something that >>> changes *very* slowly, because otherwise you'll have to support many >>> domain levels within any plugins that have to change behavior according >>> to the domain level. >>> I would say that the domain level should not change more frequently than >>> once a year or so. It would be too much code churn to do otherwise. >>> >>> So for now domain_level should be set to 0. And the topology plugin will >>> be enabled only when we turn it to 1. However we shouldn't turn it to 1 >>> until we have the replica promotion code at least, because only then we >>> can make full use of the topology plugins. >> Does that mean, that by default domain level must be set to 0 and only >> raised manually by the identity admin? > Yes, the domain level is established by the first server you install, > and CANNOT be raise automatically by a replica, it must be always > manually raised by the admin. yes, for the first time it is raised, but if you install a new replica it will be initialized from an existing replica in the domain and teh domain level is in the shared tree, so the new replica will have it automatically > Moreover the code that raises *MUST* check > that all server are capable of handling the new domain level or refuse > to raise the level. > This means all servers must publish the range of domain levels they > support, a missing range means only level 0 is supported. > >> In the official FreeIPA documentation we explicitly require software >> version of replicas to be not below the >> corresponding version of master. That means that replicas will in all >> cases support this feature. Or did I get it all wrong? > What it means is that replicas must support the domain level version of > the domain in order to join. It is another reason we want the replica > promotion code as this code will also check the domain level is suitable > and refuse to continue if the domain level is not supported. > > It will have to spit an error like: "Domain Level too old, please > upgrade your domain to at least level 'X' before trying to join this > server" > > Note: I've put freeipa-devel back in CC as this is useful information > for all developers. > > Simo. > >>> The DNS mess is unfixable, unless Petr you volunteer to backport code to >>> change the behavior of the DNS based on the domain level, if that's the >>> case then you can tie old behavior to level 0 and new behavior to level >>>> = 1, but I do not think you want to do that given we already have >>> "level 0" servers that sport the new code and changed the data in the >>> directory, so let's just ignore DNS for the purpose of this discussion, >>> except for nothing that once we finally switch to level 1 then all >>> servers must be running with the newer DNS schema and older is not >>> supported. >>> >>> Ah, I almost forgot, there is no "domain level for XYZ plugin", the >>> domain level is one for the whole server, I want to make it very clear, >>> because the title and part of the discussion seem to imply that you have >>> per-plugin domain levels. If anything like that actually exist in the >>> topology plugin code it must be ripped out now, plugin version and >>> domain level are completely disjointed things and no correlation should >>> or can exist, the only thing that can exist is whether the server, as a >>> whole, supports a specific domain level or not. >>> >>> So once we decide domain level X comes to existence we basically freeze >>> what it means and any new development that may require a domain level >>> bump risk being delayed until we are ready for a new domain level bump, >>> which should not happen very often. >>> >>> So let's make it very clear what level 1 means because the next release >>> will then support only 0 and 1, and once a new version will come out >>> with support for "level 2" we want be able to use any of the features >>> tied to level 2 until all servers in the next release have been >>> upgraded, and that may be a years long process, so we can't just churn >>> domain level numbers as we need to support working on older levels for >>> extended periods. >>> >>> Simo. >>> > From ssorce at redhat.com Thu May 28 14:00:07 2015 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 28 May 2015 10:00:07 -0400 Subject: [Freeipa-devel] New replica installation and topology - we need stable base In-Reply-To: <55671C65.3020406@redhat.com> References: <5565DBB7.1030304@redhat.com> <55671C65.3020406@redhat.com> Message-ID: <1432821607.19096.152.camel@willson.usersys.redhat.com> On Thu, 2015-05-28 at 15:47 +0200, Martin Kosek wrote: > On 05/27/2015 04:59 PM, Martin Kosek wrote: > ... > > Domain Levels > > - Done, committed > > - Defaults to Level 1, i.e. Topology plugin powered infra enabled > > With respect to related Simo's response in > http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html > > Would we want to enable Topology (i.e. Domain Level 1) even if Replica > promotion is not done? I thought we do as I see those as orthogonal features. > Replica promotion would take advantage of the Topology plugin, but it does not > mean you cannot benefit from Topology plugin without it. > > You can still use the API to see/manage the topology and set replication > settings with it. You do not need Replica Promotion for that... You cannot move for domain level 0 to 1 automatically anyway. So this is a moot point to some degree. In general we need to have the code that checks for the domain level version to be able to change the level, so we need new code in replicas to publish the supported domain level version and code in the install patchs to check that we can actually join a domain given its current domain level status. These checks are absolutely a critical blocker to enable the whole domain-level feature. Simo. From pspacek at redhat.com Thu May 28 14:00:09 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 28 May 2015 16:00:09 +0200 Subject: [Freeipa-devel] [PATCH 0014] Support multiple user and host certificates In-Reply-To: <55671B66.8080004@redhat.com> References: <20150527135315.GC24915@dhcp-40-8.bne.redhat.com> <5565ED02.6060709@redhat.com> <5566D5FC.7090307@redhat.com> <5566DD1D.7040009@redhat.com> <5566E559.8020709@redhat.com> <20150528100615.GD9628@dhcp-40-8.bne.redhat.com> <55670A25.1000307@redhat.com> <55671B66.8080004@redhat.com> Message-ID: <55671F69.7050603@redhat.com> On 28.5.2015 15:43, Martin Kosek wrote: > On 05/28/2015 02:29 PM, Petr Spacek wrote: >> On 28.5.2015 12:06, Fraser Tweedale wrote: >>> On Thu, May 28, 2015 at 11:52:25AM +0200, Martin Kosek wrote: >>>> On 05/28/2015 11:17 AM, Martin Basti wrote: >>>>> On 28/05/15 10:46, Martin Kosek wrote: >>>>>> On 05/27/2015 06:12 PM, Martin Basti wrote: >>>>>>> On 27/05/15 15:53, Fraser Tweedale wrote: >>>>>>>> This patch adds supports for multiple user / host certificates. No >>>>>>>> schema change is needed ('usercertificate' attribute is already >>>>>>>> multi-value). The revoke-previous-cert behaviour of host-mod and >>>>>>>> user-mod has been removed but revocation behaviour of -del and >>>>>>>> -disable is preserved. >>>>>>>> >>>>>>>> The latest profiles/caacl patchset (0001..0013 v5) depends on this >>>>>>>> patch for correct cert-request behaviour. >>>>>>>> >>>>>>>> There is one design question (or maybe more, let me know): the >>>>>>>> `--out=FILENAME' option to {host,service} show saves ONE certificate >>>>>>>> to the named file. I propose to either: >>>>>>>> >>>>>>>> a) write all certs, suffixing suggested filename with either a >>>>>>>> sequential numerical index, e.g. "cert.pem" becomes >>>>>>>> "cert.pem.1", "cert.pem.2", and so on; or >>>>>>>> >>>>>>>> b) as above, but suffix with serial number and, if there are >>>>>>>> different issues, some issuer-identifying information. >>>>>>>> >>>>>>>> Let me know your thoughts. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Fraser >>>>>>>> >>>>>>>> >>>>>>> Is there a possible way how to store certificates into one file? >>>>>>> I read about possibilities to have multiple certs in one .pem file, but I'm not >>>>>>> cert guru :) >>>>>>> >>>>>>> I personally vote for serial number in case there are multiple certificates, if >>>>>>> ^ is no possible. >>>>>>> >>>>>>> >>>>>>> 1) >>>>>>> + if len(certs) > 0: >>>>>>> >>>>>>> please use only, >>>>>>> if certs: >>>>>>> >>>>>>> 2) >>>>>>> You need to re-generate API/ACI.txt in this patch >>>>>>> >>>>>>> 3) >>>>>>> syntax error: >>>>>>> + for dercert in certs_der >>>>>>> >>>>>>> >>>>>>> 4) >>>>>>> command >>>>>>> ipa user-mod ca_user --certificate= >>>>>>> >>>>>>> removes the current certificate from the LDAP, by design. >>>>>>> Should be the old certificate(s) revoked? You removed that part in the code. >>>>>> Good question. I think the suggestion was to have a global switch in IPA global >>>>>> config that would configure the policy - whether the certificates removed by >>>>>> this command or by host-del or host-disable are revoked or if they are just >>>>>> removed (my motivation is to avoid behavior regression in case somebody >>>>>> depended on this behavior). >>>>> I would prefer to keep the current behavior: revoke the certificate if it was >>>>> replaced or removed, instead of adding an extra configuration option. >>>>> This behavior is not regression. >>>> >>>> It is not. However, it is not an ideal behavior also. In FreeIPA 4.2, we are >>>> now adding support of certificate profiles, multiple certificates and even >>>> certificates for user. >>>> >>>> With that change, there may be much more certificates in play than now. If we >>>> keep revoking all such certificates, it may cause rapid growth of CRLs. This is >>>> something I am trying to avoid with this proposal and default to not revoking >>>> certificates automatically (which mostly only makes sense if there is a risk >>>> that the key is compromised), but have some option to keep the old behavior. >>>> >>>> Does this make sense? >> >> I would like to see some data to support the decision not to revoke certs by >> default. Are there some facts to base the decision on? Or just hand-wavy >> reasoning? > > What facts would you like to hear? If we are speaking from bugs, we already > know that large CRL lists caused lot of grief to deployments with bug > host/service turnaround. "We had bugs about big CRLs" is good enough. I wanted to be sure that this is not a premature optimization. > I do not have more data than this, besides my > expectation that there may be much more certificates tracked by FreeIPA than in > the past and we need to deal with it. > >> Sure, huge CRL may be bad, but not revoking certs may be even worse. E.g. when >> older backup files are stolen (in the information sense, i.e. copied without >> anyone noticing it) - attacker might get valid certs despite the fact that the >> old cert is never used (because it was rotated right after the backup). > > I am not convinced that this is a valid point. We cannot assume that FreeIPA > administrator leaks certificate keys and try to magically fix that by this > policy. Such fault backup can leak even when the host/service still exists. > > This is about what makes most sense for certificate handling, what is the > secure behavior and a behavior that most administrators would expect (thus the > default). Are you sure revoking all deleted certificates is the expected > behavior? In my mind, certificates are being revoked from more serious reasons > - when employee "leaves" a company, machine (or it's backup) is compromised, > etc. But in that case admin would use cert-revoke command. > > Let me also CC Rob - do we know why FreeIPA was implemented to revoke all > service/host certificates by default on deletion/disable? I'm curious too. My expectation is that if admin deletes a user then the user cannot use his password for authentication anymore, even if admin did not use user-lock command prior the deletion. So the same behavior for certs seems quite natural for me. Anyway, the information above that it causes real problems is good enough for me. Thank you for your patience with me. Petr^2 Spacek >> IMHO this behavior should be configurable and default to 'revoke'. We should >> ship FreeIPA with secure defaults and let users to lower the standards if they >> wish/need. >> >> Petr^2 Spacek From mkosek at redhat.com Thu May 28 14:00:34 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 May 2015 16:00:34 +0200 Subject: [Freeipa-devel] New replica installation and topology - we need stable base In-Reply-To: <55671ED4.3000800@redhat.com> References: <5565DBB7.1030304@redhat.com> <55671C65.3020406@redhat.com> <55671ED4.3000800@redhat.com> Message-ID: <55671F82.50304@redhat.com> On 05/28/2015 03:57 PM, Ludwig Krispenz wrote: > > On 05/28/2015 03:47 PM, Martin Kosek wrote: >> On 05/27/2015 04:59 PM, Martin Kosek wrote: >> ... >>> Domain Levels >>> - Done, committed >>> - Defaults to Level 1, i.e. Topology plugin powered infra enabled >> With respect to related Simo's response in >> http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html >> >> Would we want to enable Topology (i.e. Domain Level 1) even if Replica >> promotion is not done? > who is we ? I thought there is an api to set the domain-level and the admin > decides if, or do you mean to have it by default during installation ? The question here is if Topology plugin (i.e. Domain Level 1) shall be enabled during new FreeIPA 4.2 installation or if would be still disabled and only enabled by domain-level-set request. >> I thought we do as I see those as orthogonal features. >> Replica promotion would take advantage of the Topology plugin, but it does not >> mean you cannot benefit from Topology plugin without it. >> >> You can still use the API to see/manage the topology and set replication >> settings with it. You do not need Replica Promotion for that... > well, it is not just for viewing, you restrict management to use the > ipa-toplogy commands Right. From mkosek at redhat.com Thu May 28 14:02:02 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 May 2015 16:02:02 +0200 Subject: [Freeipa-devel] New replica installation and topology - we need stable base In-Reply-To: <1432821607.19096.152.camel@willson.usersys.redhat.com> References: <5565DBB7.1030304@redhat.com> <55671C65.3020406@redhat.com> <1432821607.19096.152.camel@willson.usersys.redhat.com> Message-ID: <55671FDA.8030301@redhat.com> On 05/28/2015 04:00 PM, Simo Sorce wrote: > On Thu, 2015-05-28 at 15:47 +0200, Martin Kosek wrote: >> On 05/27/2015 04:59 PM, Martin Kosek wrote: >> ... >>> Domain Levels >>> - Done, committed >>> - Defaults to Level 1, i.e. Topology plugin powered infra enabled >> >> With respect to related Simo's response in >> http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html >> >> Would we want to enable Topology (i.e. Domain Level 1) even if Replica >> promotion is not done? I thought we do as I see those as orthogonal features. >> Replica promotion would take advantage of the Topology plugin, but it does not >> mean you cannot benefit from Topology plugin without it. >> >> You can still use the API to see/manage the topology and set replication >> settings with it. You do not need Replica Promotion for that... > > You cannot move for domain level 0 to 1 automatically anyway. So this is > a moot point to some degree. In general we need to have the code that > checks for the domain level version to be able to change the level, so > we need new code in replicas to publish the supported domain level > version and code in the install patchs to check that we can actually > join a domain given its current domain level status. > > These checks are absolutely a critical blocker to enable the whole > domain-level feature. All the functionality you describe and the checks should be already there. I was really only asking about the default domain level for *new* installations Old/upgraded FreeIPA will be on the Domain Level 0 of course. From lkrispen at redhat.com Thu May 28 14:04:32 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 28 May 2015 16:04:32 +0200 Subject: [Freeipa-devel] New replica installation and topology - we need stable base In-Reply-To: <55671F82.50304@redhat.com> References: <5565DBB7.1030304@redhat.com> <55671C65.3020406@redhat.com> <55671ED4.3000800@redhat.com> <55671F82.50304@redhat.com> Message-ID: <55672070.60606@redhat.com> On 05/28/2015 04:00 PM, Martin Kosek wrote: > On 05/28/2015 03:57 PM, Ludwig Krispenz wrote: >> On 05/28/2015 03:47 PM, Martin Kosek wrote: >>> On 05/27/2015 04:59 PM, Martin Kosek wrote: >>> ... >>>> Domain Levels >>>> - Done, committed >>>> - Defaults to Level 1, i.e. Topology plugin powered infra enabled >>> With respect to related Simo's response in >>> http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html >>> >>> Would we want to enable Topology (i.e. Domain Level 1) even if Replica >>> promotion is not done? >> who is we ? I thought there is an api to set the domain-level and the admin >> decides if, or do you mean to have it by default during installation ? > The question here is if Topology plugin (i.e. Domain Level 1) shall be enabled > during new FreeIPA 4.2 installation or if would be still disabled and only > enabled by domain-level-set request. I'm with Simo, this shoul be a deliberate action by an admin, based upon the info that all servers support this domain level > >>> I thought we do as I see those as orthogonal features. >>> Replica promotion would take advantage of the Topology plugin, but it does not >>> mean you cannot benefit from Topology plugin without it. >>> >>> You can still use the API to see/manage the topology and set replication >>> settings with it. You do not need Replica Promotion for that... >> well, it is not just for viewing, you restrict management to use the >> ipa-toplogy commands > Right. > From jcholast at redhat.com Thu May 28 14:02:54 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 28 May 2015 16:02:54 +0200 Subject: [Freeipa-devel] New replica installation and topology - we need stable base In-Reply-To: <1432821607.19096.152.camel@willson.usersys.redhat.com> References: <5565DBB7.1030304@redhat.com> <55671C65.3020406@redhat.com> <1432821607.19096.152.camel@willson.usersys.redhat.com> Message-ID: <5567200E.7090105@redhat.com> Dne 28.5.2015 v 16:00 Simo Sorce napsal(a): > On Thu, 2015-05-28 at 15:47 +0200, Martin Kosek wrote: >> On 05/27/2015 04:59 PM, Martin Kosek wrote: >> ... >>> Domain Levels >>> - Done, committed >>> - Defaults to Level 1, i.e. Topology plugin powered infra enabled >> >> With respect to related Simo's response in >> http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html >> >> Would we want to enable Topology (i.e. Domain Level 1) even if Replica >> promotion is not done? I thought we do as I see those as orthogonal features. >> Replica promotion would take advantage of the Topology plugin, but it does not >> mean you cannot benefit from Topology plugin without it. >> >> You can still use the API to see/manage the topology and set replication >> settings with it. You do not need Replica Promotion for that... > > You cannot move for domain level 0 to 1 automatically anyway. So this is > a moot point to some degree. In general we need to have the code that > checks for the domain level version to be able to change the level, so > we need new code in replicas to publish the supported domain level > version and code in the install patchs to check that we can actually > join a domain given its current domain level status. > > These checks are absolutely a critical blocker to enable the whole > domain-level feature. IIUC this is already done, see commit f3010498af2a4b98512d219b8e09101176c172fe. -- Jan Cholasta From mkosek at redhat.com Thu May 28 14:04:38 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 May 2015 16:04:38 +0200 Subject: [Freeipa-devel] New replica installation and topology - we need stable base In-Reply-To: <55672070.60606@redhat.com> References: <5565DBB7.1030304@redhat.com> <55671C65.3020406@redhat.com> <55671ED4.3000800@redhat.com> <55671F82.50304@redhat.com> <55672070.60606@redhat.com> Message-ID: <55672076.4020103@redhat.com> On 05/28/2015 04:04 PM, Ludwig Krispenz wrote: > > On 05/28/2015 04:00 PM, Martin Kosek wrote: >> On 05/28/2015 03:57 PM, Ludwig Krispenz wrote: >>> On 05/28/2015 03:47 PM, Martin Kosek wrote: >>>> On 05/27/2015 04:59 PM, Martin Kosek wrote: >>>> ... >>>>> Domain Levels >>>>> - Done, committed >>>>> - Defaults to Level 1, i.e. Topology plugin powered infra enabled >>>> With respect to related Simo's response in >>>> http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html >>>> >>>> Would we want to enable Topology (i.e. Domain Level 1) even if Replica >>>> promotion is not done? >>> who is we ? I thought there is an api to set the domain-level and the admin >>> decides if, or do you mean to have it by default during installation ? >> The question here is if Topology plugin (i.e. Domain Level 1) shall be enabled >> during new FreeIPA 4.2 installation or if would be still disabled and only >> enabled by domain-level-set request. > I'm with Simo, this shoul be a deliberate action by an admin, based upon the > info that all servers support this domain level Guys, I am really talking about *new* FreeIPA server installation, not upgrades. If you are installing FreeIPA 4.2 server, you already know that *all* servers support Topology as we do not allow installing replica with older version than a server. What do I miss here? >>>> I thought we do as I see those as orthogonal features. >>>> Replica promotion would take advantage of the Topology plugin, but it does not >>>> mean you cannot benefit from Topology plugin without it. >>>> >>>> You can still use the API to see/manage the topology and set replication >>>> settings with it. You do not need Replica Promotion for that... >>> well, it is not just for viewing, you restrict management to use the >>> ipa-toplogy commands >> Right. >> > From pspacek at redhat.com Thu May 28 14:05:10 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 28 May 2015 16:05:10 +0200 Subject: [Freeipa-devel] Domain level for topology plugin = 2 In-Reply-To: <1432819613.19096.138.camel@willson.usersys.redhat.com> References: <55646331.5050807@redhat.com> <55647F90.506@redhat.com> <5564804B.6080305@redhat.com> <5564841B.4020906@redhat.com> <5566BBFD.9070601@redhat.com> <5566BE3E.2060104@redhat.com> <5566D684.6080505@redhat.com> <5567060D.5010202@redhat.com> <1432819613.19096.138.camel@willson.usersys.redhat.com> Message-ID: <55672096.1080005@redhat.com> On 28.5.2015 15:26, Simo Sorce wrote: > On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote: >> On 28.5.2015 10:49, Martin Kosek wrote: >>> On 05/28/2015 09:05 AM, Petr Spacek wrote: >>>> On 28.5.2015 08:55, Jan Cholasta wrote: >>>>> Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): >>>>>> On 26.5.2015 16:16, Martin Kosek wrote: >>>>>>> On 05/26/2015 04:13 PM, thierry bordaz wrote: >>>>>>>> On 05/26/2015 02:12 PM, Petr Spacek wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> it came to my mind that domain level for topology plugin should actually be >>>>>>>>> number 2, not 1. >>>>>>>>> >>>>>>>>> We already used number 1 for incompatible changes in DNS tree and I believe >>>>>>>>> that it is not a good idea to have two places which say 'version 1' but and >>>>>>>>> actually mean two different things. (DNS tree version 1 + domain level 1) >>>>>>>>> >>>>>>>>> Patch is attached. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Hello, >>>>>>>> The fix looks good but that seems strange to have to set the initial >>>>>>>> version of >>>>>>>> the topology plugin to 2.0. (IIUC That is the version that will be written in >>>>>>>> dse.ldif) >>>>>>>> I would rather expects that topology plugin 1.0, would activate itself if the >>>>>>>> DomainLevel is 2.0 or more. >>>>>>>> If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate >>>>>>>> itself if DomainLevel >= DomainLevel_trigger. >>>>>>>> >>>>>>>> Let's wait for Ludwig feedback. >>>>>>>> >>>>>>>> thanks >>>>>>>> thierry >>>>>>> >>>>>>> My personal opinion on this is to start with Domain Level 1 regardless. We >>>>>>> already "solved" the DNS forwarders otherwise, with docs, async updates etc. I >>>>>>> do not think we will be returning to implementing proper Domain Level support >>>>>>> for that anyway. >>>>>>> >>>>>>> So I rather think that all the "Domain Level starts with 0, 1 is unused, 2 is >>>>>>> the top one" will cause unforeseen issues I would rather like to avoid. >>>>>> >>>>>> I'm more worried about confusion in future. To to me it simply seems easier to >>>>>> bump one integer now than to document and explain (to users & new developers) >>>>>> why we have two "ones" which mean something else. >>>>>> >>>>>> Code-wise it is just an integer. >>>>>> >>>>>> Also, it can simplify logic in future when we decide to do another >>>>>> incompatible change in DNS tree because we will have only one integer to test >>>>>> (instead of checking two separate version attribute in DNS tree & domain >>>>>> level). >>>>> >>>>> +1, but I think the minimum supported domain level should be 1, not 0, because >>>>> 0 means the server uses the old DNS schema, which we do not support anymore, >>>>> right? >>>> >>>> Good point! >>>> >>> >>> It may be a good point, but it does not make the situation easier. You still >>> have RHEL/CentOS 6.x IPA out there, where some of them already support the new >>> DNS forwarders and some don't - and neither of them support Domain Levels - >>> i.e. have Domain Level 0. >>> >>> As I said, I still see more complications with this proposals than benefits... >> >> I would argue that it actually helps. >> >> If domain level = 1 then we can be *sure* that all replicas support the new >> DNS semantics. >> >> If domain level = 0 then we know nothing (because of patched RHEL 6) and it is >> a warning sign for diagnostic tools and also us when it comes to debugging. > > First of all a domain level is something we change *RARELY*, and it is > a whole number and it is an all or nothing thing. > > I do not understand why plugin versions matter at all, plugin version > have nothing to do with domain levels. Each plugin *whatever* the > version MUST always support at least 2 levels, because every domain you > have will have to go through a domain_level transition when a new domain > level comes out. > > Finally no single developer should be allowed to decide on anew domain > level, this must be a well ponder team decision as all plugins that need > to change behavior based on domain level will be affected so a thorough > review of what changes are needed across all plugins must be done every > time someone propose a change that requires a domain level bump. > > Last but not least we should consider domain levels as something that > changes *very* slowly, because otherwise you'll have to support many > domain levels within any plugins that have to change behavior according > to the domain level. > I would say that the domain level should not change more frequently than > once a year or so. It would be too much code churn to do otherwise. > > So for now domain_level should be set to 0. And the topology plugin will > be enabled only when we turn it to 1. However we shouldn't turn it to 1 > until we have the replica promotion code at least, because only then we > can make full use of the topology plugins. > > The DNS mess is unfixable, unless Petr you volunteer to backport code to > change the behavior of the DNS based on the domain level, if that's the > case then you can tie old behavior to level 0 and new behavior to level >> = 1, but I do not think you want to do that given we already have > "level 0" servers that sport the new code and changed the data in the > directory, so let's just ignore DNS for the purpose of this discussion, > except for nothing that once we finally switch to level 1 then all > servers must be running with the newer DNS schema and older is not > supported. > > Ah, I almost forgot, there is no "domain level for XYZ plugin", the > domain level is one for the whole server, I want to make it very clear, > because the title and part of the discussion seem to imply that you have > per-plugin domain levels. If anything like that actually exist in the > topology plugin code it must be ripped out now, plugin version and > domain level are completely disjointed things and no correlation should > or can exist, the only thing that can exist is whether the server, as a > whole, supports a specific domain level or not. > > So once we decide domain level X comes to existence we basically freeze > what it means and any new development that may require a domain level > bump risk being delayed until we are ready for a new domain level bump, > which should not happen very often. > > So let's make it very clear what level 1 means because the next release > will then support only 0 and 1, and once a new version will come out > with support for "level 2" we want be able to use any of the features > tied to level 2 until all servers in the next release have been > upgraded, and that may be a years long process, so we can't just churn > domain level numbers as we need to support working on older levels for > extended periods. I do not see a problem with using level = 2 for topology plugin but whatever. Be it as Simo designed. -- Petr^2 Spacek From ssorce at redhat.com Thu May 28 14:07:09 2015 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 28 May 2015 10:07:09 -0400 Subject: [Freeipa-devel] New replica installation and topology - we need stable base In-Reply-To: <55671FDA.8030301@redhat.com> References: <5565DBB7.1030304@redhat.com> <55671C65.3020406@redhat.com> <1432821607.19096.152.camel@willson.usersys.redhat.com> <55671FDA.8030301@redhat.com> Message-ID: <1432822029.19096.154.camel@willson.usersys.redhat.com> On Thu, 2015-05-28 at 16:02 +0200, Martin Kosek wrote: > On 05/28/2015 04:00 PM, Simo Sorce wrote: > > On Thu, 2015-05-28 at 15:47 +0200, Martin Kosek wrote: > >> On 05/27/2015 04:59 PM, Martin Kosek wrote: > >> ... > >>> Domain Levels > >>> - Done, committed > >>> - Defaults to Level 1, i.e. Topology plugin powered infra enabled > >> > >> With respect to related Simo's response in > >> http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html > >> > >> Would we want to enable Topology (i.e. Domain Level 1) even if Replica > >> promotion is not done? I thought we do as I see those as orthogonal features. > >> Replica promotion would take advantage of the Topology plugin, but it does not > >> mean you cannot benefit from Topology plugin without it. > >> > >> You can still use the API to see/manage the topology and set replication > >> settings with it. You do not need Replica Promotion for that... > > > > You cannot move for domain level 0 to 1 automatically anyway. So this is > > a moot point to some degree. In general we need to have the code that > > checks for the domain level version to be able to change the level, so > > we need new code in replicas to publish the supported domain level > > version and code in the install patchs to check that we can actually > > join a domain given its current domain level status. > > > > These checks are absolutely a critical blocker to enable the whole > > domain-level feature. > > All the functionality you describe and the checks should be already there. I > was really only asking about the default domain level for *new* installations > > Old/upgraded FreeIPA will be on the Domain Level 0 of course. I think new installation should be on 1 but only if we have decided and finalized what "level 1" is. Simo. From lkrispen at redhat.com Thu May 28 14:14:28 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 28 May 2015 16:14:28 +0200 Subject: [Freeipa-devel] New replica installation and topology - we need stable base In-Reply-To: <55672076.4020103@redhat.com> References: <5565DBB7.1030304@redhat.com> <55671C65.3020406@redhat.com> <55671ED4.3000800@redhat.com> <55671F82.50304@redhat.com> <55672070.60606@redhat.com> <55672076.4020103@redhat.com> Message-ID: <556722C4.8070805@redhat.com> On 05/28/2015 04:04 PM, Martin Kosek wrote: > On 05/28/2015 04:04 PM, Ludwig Krispenz wrote: >> On 05/28/2015 04:00 PM, Martin Kosek wrote: >>> On 05/28/2015 03:57 PM, Ludwig Krispenz wrote: >>>> On 05/28/2015 03:47 PM, Martin Kosek wrote: >>>>> On 05/27/2015 04:59 PM, Martin Kosek wrote: >>>>> ... >>>>>> Domain Levels >>>>>> - Done, committed >>>>>> - Defaults to Level 1, i.e. Topology plugin powered infra enabled >>>>> With respect to related Simo's response in >>>>> http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html >>>>> >>>>> Would we want to enable Topology (i.e. Domain Level 1) even if Replica >>>>> promotion is not done? >>>> who is we ? I thought there is an api to set the domain-level and the admin >>>> decides if, or do you mean to have it by default during installation ? >>> The question here is if Topology plugin (i.e. Domain Level 1) shall be enabled >>> during new FreeIPA 4.2 installation or if would be still disabled and only >>> enabled by domain-level-set request. >> I'm with Simo, this shoul be a deliberate action by an admin, based upon the >> info that all servers support this domain level > Guys, I am really talking about *new* FreeIPA server installation, not > upgrades. If you are installing FreeIPA 4.2 server, you already know that *all* > servers support Topology as we do not allow installing replica with older > version than a server. > > What do I miss here? well, I was not sure where in the install process you would set the domain level. If you create a 4.2 replica from a 4.1 server and in the instance creation of the 4.2 replica you set the domain level automatically, it depends on when it is done what side effects it will have. but maybe I miss that this already is handled > >>>>> I thought we do as I see those as orthogonal features. >>>>> Replica promotion would take advantage of the Topology plugin, but it does not >>>>> mean you cannot benefit from Topology plugin without it. >>>>> >>>>> You can still use the API to see/manage the topology and set replication >>>>> settings with it. You do not need Replica Promotion for that... >>>> well, it is not just for viewing, you restrict management to use the >>>> ipa-toplogy commands >>> Right. >>> From mkosek at redhat.com Thu May 28 14:14:50 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 May 2015 16:14:50 +0200 Subject: [Freeipa-devel] New replica installation and topology - we need stable base In-Reply-To: <1432822029.19096.154.camel@willson.usersys.redhat.com> References: <5565DBB7.1030304@redhat.com> <55671C65.3020406@redhat.com> <1432821607.19096.152.camel@willson.usersys.redhat.com> <55671FDA.8030301@redhat.com> <1432822029.19096.154.camel@willson.usersys.redhat.com> Message-ID: <556722DA.7010703@redhat.com> On 05/28/2015 04:07 PM, Simo Sorce wrote: > On Thu, 2015-05-28 at 16:02 +0200, Martin Kosek wrote: >> On 05/28/2015 04:00 PM, Simo Sorce wrote: >>> On Thu, 2015-05-28 at 15:47 +0200, Martin Kosek wrote: >>>> On 05/27/2015 04:59 PM, Martin Kosek wrote: >>>> ... >>>>> Domain Levels >>>>> - Done, committed >>>>> - Defaults to Level 1, i.e. Topology plugin powered infra enabled >>>> >>>> With respect to related Simo's response in >>>> http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html >>>> >>>> Would we want to enable Topology (i.e. Domain Level 1) even if Replica >>>> promotion is not done? I thought we do as I see those as orthogonal features. >>>> Replica promotion would take advantage of the Topology plugin, but it does not >>>> mean you cannot benefit from Topology plugin without it. >>>> >>>> You can still use the API to see/manage the topology and set replication >>>> settings with it. You do not need Replica Promotion for that... >>> >>> You cannot move for domain level 0 to 1 automatically anyway. So this is >>> a moot point to some degree. In general we need to have the code that >>> checks for the domain level version to be able to change the level, so >>> we need new code in replicas to publish the supported domain level >>> version and code in the install patchs to check that we can actually >>> join a domain given its current domain level status. >>> >>> These checks are absolutely a critical blocker to enable the whole >>> domain-level feature. >> >> All the functionality you describe and the checks should be already there. I >> was really only asking about the default domain level for *new* installations >> >> Old/upgraded FreeIPA will be on the Domain Level 0 of course. > > I think new installation should be on 1 but only if we have decided and > finalized what "level 1" is. > > Simo. > In my mind, Domain Level 1 means: - Topology plugins is activated for all replicas and manages the agreements - All changes to topology can be only made via topology-* commands - ipa-replica-manage connect|disconnect are not allowed Martin From mkosek at redhat.com Thu May 28 14:15:48 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 May 2015 16:15:48 +0200 Subject: [Freeipa-devel] New replica installation and topology - we need stable base In-Reply-To: <556722C4.8070805@redhat.com> References: <5565DBB7.1030304@redhat.com> <55671C65.3020406@redhat.com> <55671ED4.3000800@redhat.com> <55671F82.50304@redhat.com> <55672070.60606@redhat.com> <55672076.4020103@redhat.com> <556722C4.8070805@redhat.com> Message-ID: <55672314.7050702@redhat.com> On 05/28/2015 04:14 PM, Ludwig Krispenz wrote: > > On 05/28/2015 04:04 PM, Martin Kosek wrote: >> On 05/28/2015 04:04 PM, Ludwig Krispenz wrote: >>> On 05/28/2015 04:00 PM, Martin Kosek wrote: >>>> On 05/28/2015 03:57 PM, Ludwig Krispenz wrote: >>>>> On 05/28/2015 03:47 PM, Martin Kosek wrote: >>>>>> On 05/27/2015 04:59 PM, Martin Kosek wrote: >>>>>> ... >>>>>>> Domain Levels >>>>>>> - Done, committed >>>>>>> - Defaults to Level 1, i.e. Topology plugin powered infra enabled >>>>>> With respect to related Simo's response in >>>>>> http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html >>>>>> >>>>>> Would we want to enable Topology (i.e. Domain Level 1) even if Replica >>>>>> promotion is not done? >>>>> who is we ? I thought there is an api to set the domain-level and the admin >>>>> decides if, or do you mean to have it by default during installation ? >>>> The question here is if Topology plugin (i.e. Domain Level 1) shall be enabled >>>> during new FreeIPA 4.2 installation or if would be still disabled and only >>>> enabled by domain-level-set request. >>> I'm with Simo, this shoul be a deliberate action by an admin, based upon the >>> info that all servers support this domain level >> Guys, I am really talking about *new* FreeIPA server installation, not >> upgrades. If you are installing FreeIPA 4.2 server, you already know that *all* >> servers support Topology as we do not allow installing replica with older >> version than a server. >> >> What do I miss here? > well, I was not sure where in the install process you would set the domain > level. If you create > a 4.2 replica from a 4.1 server and in the instance creation of the 4.2 replica > you set the domain level automatically, > it depends on when it is done what side effects it will have. but maybe I miss > that this already is handled In the use case you described, the Domain Level should be set to 0 (i.e. no automatic raise) >> >>>>>> I thought we do as I see those as orthogonal features. >>>>>> Replica promotion would take advantage of the Topology plugin, but it >>>>>> does not >>>>>> mean you cannot benefit from Topology plugin without it. >>>>>> >>>>>> You can still use the API to see/manage the topology and set replication >>>>>> settings with it. You do not need Replica Promotion for that... >>>>> well, it is not just for viewing, you restrict management to use the >>>>> ipa-toplogy commands >>>> Right. >>>> > From ssorce at redhat.com Thu May 28 14:15:54 2015 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 28 May 2015 10:15:54 -0400 Subject: [Freeipa-devel] New replica installation and topology - we need stable base In-Reply-To: <5567200E.7090105@redhat.com> References: <5565DBB7.1030304@redhat.com> <55671C65.3020406@redhat.com> <1432821607.19096.152.camel@willson.usersys.redhat.com> <5567200E.7090105@redhat.com> Message-ID: <1432822554.19096.155.camel@willson.usersys.redhat.com> On Thu, 2015-05-28 at 16:02 +0200, Jan Cholasta wrote: > f3010498af2a4b98512d219b8e09101176c172fe. This is perfect! Thanks a lot. From ssorce at redhat.com Thu May 28 14:17:03 2015 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 28 May 2015 10:17:03 -0400 Subject: [Freeipa-devel] New replica installation and topology - we need stable base In-Reply-To: <55672076.4020103@redhat.com> References: <5565DBB7.1030304@redhat.com> <55671C65.3020406@redhat.com> <55671ED4.3000800@redhat.com> <55671F82.50304@redhat.com> <55672070.60606@redhat.com> <55672076.4020103@redhat.com> Message-ID: <1432822623.19096.156.camel@willson.usersys.redhat.com> On Thu, 2015-05-28 at 16:04 +0200, Martin Kosek wrote: > On 05/28/2015 04:04 PM, Ludwig Krispenz wrote: > > > > On 05/28/2015 04:00 PM, Martin Kosek wrote: > >> On 05/28/2015 03:57 PM, Ludwig Krispenz wrote: > >>> On 05/28/2015 03:47 PM, Martin Kosek wrote: > >>>> On 05/27/2015 04:59 PM, Martin Kosek wrote: > >>>> ... > >>>>> Domain Levels > >>>>> - Done, committed > >>>>> - Defaults to Level 1, i.e. Topology plugin powered infra enabled > >>>> With respect to related Simo's response in > >>>> http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html > >>>> > >>>> Would we want to enable Topology (i.e. Domain Level 1) even if Replica > >>>> promotion is not done? > >>> who is we ? I thought there is an api to set the domain-level and the admin > >>> decides if, or do you mean to have it by default during installation ? > >> The question here is if Topology plugin (i.e. Domain Level 1) shall be enabled > >> during new FreeIPA 4.2 installation or if would be still disabled and only > >> enabled by domain-level-set request. > > I'm with Simo, this shoul be a deliberate action by an admin, based upon the > > info that all servers support this domain level > > Guys, I am really talking about *new* FreeIPA server installation, not > upgrades. If you are installing FreeIPA 4.2 server, you already know that *all* > servers support Topology as we do not allow installing replica with older > version than a server. > > What do I miss here? I think the only thing that may be missing is that the current installer still does the dance of using SSL and then later transitioning to GSSAPI, I am not sure the topology plugin copes with that. Ludwig, can you comment ? Simo. From lkrispen at redhat.com Thu May 28 14:21:36 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 28 May 2015 16:21:36 +0200 Subject: [Freeipa-devel] New replica installation and topology - we need stable base In-Reply-To: <1432822623.19096.156.camel@willson.usersys.redhat.com> References: <5565DBB7.1030304@redhat.com> <55671C65.3020406@redhat.com> <55671ED4.3000800@redhat.com> <55671F82.50304@redhat.com> <55672070.60606@redhat.com> <55672076.4020103@redhat.com> <1432822623.19096.156.camel@willson.usersys.redhat.com> Message-ID: <55672470.2080807@redhat.com> On 05/28/2015 04:17 PM, Simo Sorce wrote: > On Thu, 2015-05-28 at 16:04 +0200, Martin Kosek wrote: >> On 05/28/2015 04:04 PM, Ludwig Krispenz wrote: >>> On 05/28/2015 04:00 PM, Martin Kosek wrote: >>>> On 05/28/2015 03:57 PM, Ludwig Krispenz wrote: >>>>> On 05/28/2015 03:47 PM, Martin Kosek wrote: >>>>>> On 05/27/2015 04:59 PM, Martin Kosek wrote: >>>>>> ... >>>>>>> Domain Levels >>>>>>> - Done, committed >>>>>>> - Defaults to Level 1, i.e. Topology plugin powered infra enabled >>>>>> With respect to related Simo's response in >>>>>> http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html >>>>>> >>>>>> Would we want to enable Topology (i.e. Domain Level 1) even if Replica >>>>>> promotion is not done? >>>>> who is we ? I thought there is an api to set the domain-level and the admin >>>>> decides if, or do you mean to have it by default during installation ? >>>> The question here is if Topology plugin (i.e. Domain Level 1) shall be enabled >>>> during new FreeIPA 4.2 installation or if would be still disabled and only >>>> enabled by domain-level-set request. >>> I'm with Simo, this shoul be a deliberate action by an admin, based upon the >>> info that all servers support this domain level >> Guys, I am really talking about *new* FreeIPA server installation, not >> upgrades. If you are installing FreeIPA 4.2 server, you already know that *all* >> servers support Topology as we do not allow installing replica with older >> version than a server. >> >> What do I miss here? > I think the only thing that may be missing is that the current installer > still does the dance of using SSL and then later transitioning to > GSSAPI, I am not sure the topology plugin copes with that. yes, it works with the current installer (except for bugs) > > Ludwig, can you comment ? > > Simo. > From ofayans at redhat.com Thu May 28 14:23:52 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 28 May 2015 16:23:52 +0200 Subject: [Freeipa-devel] Domain level for topology plugin = 2 In-Reply-To: <1432821163.19096.146.camel@willson.usersys.redhat.com> References: <55646331.5050807@redhat.com> <55647F90.506@redhat.com> <5564804B.6080305@redhat.com> <5564841B.4020906@redhat.com> <5566BBFD.9070601@redhat.com> <5566BE3E.2060104@redhat.com> <5566D684.6080505@redhat.com> <5567060D.5010202@redhat.com> <1432819613.19096.138.camel@willson.usersys.redhat.com> <55671AA7.6040002@redhat.com> <1432821163.19096.146.camel@willson.usersys.redhat.com> Message-ID: <556724F8.3090200@redhat.com> Hi Simo, On 05/28/2015 03:52 PM, Simo Sorce wrote: > On Thu, 2015-05-28 at 15:39 +0200, Oleg Fayans wrote: >> On 05/28/2015 03:26 PM, Simo Sorce wrote: >>> On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote: >>>> On 28.5.2015 10:49, Martin Kosek wrote: >>>>> On 05/28/2015 09:05 AM, Petr Spacek wrote: >>>>>> On 28.5.2015 08:55, Jan Cholasta wrote: >>>>>>> Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): >>>>>>>> On 26.5.2015 16:16, Martin Kosek wrote: >>>>>>>>> On 05/26/2015 04:13 PM, thierry bordaz wrote: >>>>>>>>>> On 05/26/2015 02:12 PM, Petr Spacek wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> it came to my mind that domain level for topology plugin should actually be >>>>>>>>>>> number 2, not 1. >>>>>>>>>>> >>>>>>>>>>> We already used number 1 for incompatible changes in DNS tree and I believe >>>>>>>>>>> that it is not a good idea to have two places which say 'version 1' but and >>>>>>>>>>> actually mean two different things. (DNS tree version 1 + domain level 1) >>>>>>>>>>> >>>>>>>>>>> Patch is attached. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> The fix looks good but that seems strange to have to set the initial >>>>>>>>>> version of >>>>>>>>>> the topology plugin to 2.0. (IIUC That is the version that will be written in >>>>>>>>>> dse.ldif) >>>>>>>>>> I would rather expects that topology plugin 1.0, would activate itself if the >>>>>>>>>> DomainLevel is 2.0 or more. >>>>>>>>>> If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate >>>>>>>>>> itself if DomainLevel >= DomainLevel_trigger. >>>>>>>>>> >>>>>>>>>> Let's wait for Ludwig feedback. >>>>>>>>>> >>>>>>>>>> thanks >>>>>>>>>> thierry >>>>>>>>> My personal opinion on this is to start with Domain Level 1 regardless. We >>>>>>>>> already "solved" the DNS forwarders otherwise, with docs, async updates etc. I >>>>>>>>> do not think we will be returning to implementing proper Domain Level support >>>>>>>>> for that anyway. >>>>>>>>> >>>>>>>>> So I rather think that all the "Domain Level starts with 0, 1 is unused, 2 is >>>>>>>>> the top one" will cause unforeseen issues I would rather like to avoid. >>>>>>>> I'm more worried about confusion in future. To to me it simply seems easier to >>>>>>>> bump one integer now than to document and explain (to users & new developers) >>>>>>>> why we have two "ones" which mean something else. >>>>>>>> >>>>>>>> Code-wise it is just an integer. >>>>>>>> >>>>>>>> Also, it can simplify logic in future when we decide to do another >>>>>>>> incompatible change in DNS tree because we will have only one integer to test >>>>>>>> (instead of checking two separate version attribute in DNS tree & domain >>>>>>>> level). >>>>>>> +1, but I think the minimum supported domain level should be 1, not 0, because >>>>>>> 0 means the server uses the old DNS schema, which we do not support anymore, >>>>>>> right? >>>>>> Good point! >>>>>> >>>>> It may be a good point, but it does not make the situation easier. You still >>>>> have RHEL/CentOS 6.x IPA out there, where some of them already support the new >>>>> DNS forwarders and some don't - and neither of them support Domain Levels - >>>>> i.e. have Domain Level 0. >>>>> >>>>> As I said, I still see more complications with this proposals than benefits... >>>> I would argue that it actually helps. >>>> >>>> If domain level = 1 then we can be *sure* that all replicas support the new >>>> DNS semantics. >>>> >>>> If domain level = 0 then we know nothing (because of patched RHEL 6) and it is >>>> a warning sign for diagnostic tools and also us when it comes to debugging. >>> First of all a domain level is something we change *RARELY*, and it is >>> a whole number and it is an all or nothing thing. >>> >>> I do not understand why plugin versions matter at all, plugin version >>> have nothing to do with domain levels. Each plugin *whatever* the >>> version MUST always support at least 2 levels, because every domain you >>> have will have to go through a domain_level transition when a new domain >>> level comes out. >>> >>> Finally no single developer should be allowed to decide on anew domain >>> level, this must be a well ponder team decision as all plugins that need >>> to change behavior based on domain level will be affected so a thorough >>> review of what changes are needed across all plugins must be done every >>> time someone propose a change that requires a domain level bump. >>> >>> Last but not least we should consider domain levels as something that >>> changes *very* slowly, because otherwise you'll have to support many >>> domain levels within any plugins that have to change behavior according >>> to the domain level. >>> I would say that the domain level should not change more frequently than >>> once a year or so. It would be too much code churn to do otherwise. >>> >>> So for now domain_level should be set to 0. And the topology plugin will >>> be enabled only when we turn it to 1. However we shouldn't turn it to 1 >>> until we have the replica promotion code at least, because only then we >>> can make full use of the topology plugins. >> Does that mean, that by default domain level must be set to 0 and only >> raised manually by the identity admin? > Yes, the domain level is established by the first server you install, > and CANNOT be raise automatically by a replica, it must be always > manually raised by the admin. Moreover the code that raises *MUST* check > that all server are capable of handling the new domain level or refuse > to raise the level. > This means all servers must publish the range of domain levels they > support, a missing range means only level 0 is supported. Thank you, this at last clarifies most of the use-cases. The only question that remains: what will happen if an admin (for whatever dumb reason) decides to downgrade the FreeIPA version to 4.1 (that does not support domain levels) on the master of the domain that has domain level = 1? Do replicas preserve the information of the topology? Do they delete this info from DS together with the record about the domain level? Should we support such scenario at all? > >> In the official FreeIPA documentation we explicitly require software >> version of replicas to be not below the >> corresponding version of master. That means that replicas will in all >> cases support this feature. Or did I get it all wrong? > What it means is that replicas must support the domain level version of > the domain in order to join. It is another reason we want the replica > promotion code as this code will also check the domain level is suitable > and refuse to continue if the domain level is not supported. > > It will have to spit an error like: "Domain Level too old, please > upgrade your domain to at least level 'X' before trying to join this > server" > > Note: I've put freeipa-devel back in CC as this is useful information > for all developers. > > Simo. > >>> The DNS mess is unfixable, unless Petr you volunteer to backport code to >>> change the behavior of the DNS based on the domain level, if that's the >>> case then you can tie old behavior to level 0 and new behavior to level >>>> = 1, but I do not think you want to do that given we already have >>> "level 0" servers that sport the new code and changed the data in the >>> directory, so let's just ignore DNS for the purpose of this discussion, >>> except for nothing that once we finally switch to level 1 then all >>> servers must be running with the newer DNS schema and older is not >>> supported. >>> >>> Ah, I almost forgot, there is no "domain level for XYZ plugin", the >>> domain level is one for the whole server, I want to make it very clear, >>> because the title and part of the discussion seem to imply that you have >>> per-plugin domain levels. If anything like that actually exist in the >>> topology plugin code it must be ripped out now, plugin version and >>> domain level are completely disjointed things and no correlation should >>> or can exist, the only thing that can exist is whether the server, as a >>> whole, supports a specific domain level or not. >>> >>> So once we decide domain level X comes to existence we basically freeze >>> what it means and any new development that may require a domain level >>> bump risk being delayed until we are ready for a new domain level bump, >>> which should not happen very often. >>> >>> So let's make it very clear what level 1 means because the next release >>> will then support only 0 and 1, and once a new version will come out >>> with support for "level 2" we want be able to use any of the features >>> tied to level 2 until all servers in the next release have been >>> upgraded, and that may be a years long process, so we can't just churn >>> domain level numbers as we need to support working on older levels for >>> extended periods. >>> >>> Simo. >>> > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- An HTML attachment was scrubbed... URL: From derny at redhat.com Thu May 28 14:27:22 2015 From: derny at redhat.com (Drew Erny) Date: Thu, 28 May 2015 10:27:22 -0400 Subject: [Freeipa-devel] Sudorules user validation help In-Reply-To: <55671ABA.9090709@redhat.com> References: <55660FDE.3030202@redhat.com> <5566D557.9030503@redhat.com> <55671ABA.9090709@redhat.com> Message-ID: <556725CA.6020709@redhat.com> In the ticket, however, it's stated that if the user wants to use any combination of weird characters, they should be able to. Would it be better to just define a function like def validate_username(username, ignore_pattern=False): and have it ignore all username validation? On 05/28/2015 09:40 AM, Drew Erny wrote: > OK, I see now what you mean by that. That is a simpler solution. I'll > do it that way. > > On 05/28/2015 04:44 AM, Martin Kosek wrote: >> On 05/27/2015 08:41 PM, Drew Erny wrote: >>> Hey, Freeipa-devel, >>> >>> I'm working on ticket #3226 >>> (https://fedorahosted.org/freeipa/ticket/3226) >>> >>> I've identified the problem. The sudorules add user command adds the >>> user >>> validations at the end of it's pre-callback using >>> add_external_pre_callback. >>> However, the "user" plugin pattern-matches a string for the "uid" >>> param, >>> because it only allows certain characters. >>> >>> I've been picking through the codebase and I think I have enough >>> understanding >>> to ask this: What if we changed the user "uid" validation to a >>> standalone >>> "rule" function (you can do that, right? pass in a function as a >>> validation >>> rule?) that would normally just assert that the pattern matches, but >>> could have >>> that pattern matching validation overridden in some cases. I think >>> that's the >>> easiest, cleanest way to change user so that sudorules and other >>> plugins can >>> ignore this validation if necessary (I'm trying to figure out >>> exactly how to >>> implement this without changing any APIs). >>> >>> Am I understanding the plugin params API correctly, and can I do >>> this? Is this >>> the best way to do this? >>> >>> The only other solution I see is to write sudorules-specific code in >>> some >>> plugin-related (either user.py or baseldap.py module, which would >>> create >>> unwanted coupling. >>> >>> Most specifically, this would be a change to the object instantiated at >>> ipalib/plugins/user.py line 467 >>> >>> Thoughts and suggestions? >> I think it would make sense to follow the example with >> validate_hostname and >> prepare a function validate_username(username, upn=False, >> netbios_name=False) [1]. >> >> where upn would allow using "@." on top of current validator (i.e. >> user at Domain.test) and netbios_name would allow the "DOMAIN\user" >> style. I would >> just suggest making sure the standard user validation error message >> is still >> the same to avoid unnecessary QE fail positives. >> >> In add_external_pre_callback you could then just simply call >> >> validate_username(user, True, True) >> >> just like it is already done with hostname. >> >> My 2 cents. >> >> Martin >> >> [1] >> https://msdn.microsoft.com/en-us/library/windows/desktop/aa380525(v=vs.85).aspx > From jcholast at redhat.com Thu May 28 14:28:41 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 28 May 2015 16:28:41 +0200 Subject: [Freeipa-devel] [PATCH 430-433] Move ipa-server-* into modules Message-ID: <55672619.5080908@redhat.com> Hi, the attached patches move ipa-server-install, ipa-replica-install and ipa-server-upgrade into modules. This is part of . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-430-install-Make-a-package-out-of-ipaserver.install.serv.patch Type: text/x-patch Size: 101416 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-431-install-Move-ipa-server-install-code-into-a-module.patch Type: text/x-patch Size: 93577 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-432-install-Move-ipa-replica-install-code-into-a-module.patch Type: text/x-patch Size: 50346 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-433-install-Move-ipa-server-upgrade-code-into-a-module.patch Type: text/x-patch Size: 9030 bytes Desc: not available URL: From simo at redhat.com Thu May 28 14:29:01 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 28 May 2015 10:29:01 -0400 Subject: [Freeipa-devel] Domain level for topology plugin = 2 In-Reply-To: <556724F8.3090200@redhat.com> References: <55646331.5050807@redhat.com> <55647F90.506@redhat.com> <5564804B.6080305@redhat.com> <5564841B.4020906@redhat.com> <5566BBFD.9070601@redhat.com> <5566BE3E.2060104@redhat.com> <5566D684.6080505@redhat.com> <5567060D.5010202@redhat.com> <1432819613.19096.138.camel@willson.usersys.redhat.com> <55671AA7.6040002@redhat.com> <1432821163.19096.146.camel@willson.usersys.redhat.com> <556724F8.3090200@redhat.com> Message-ID: <1432823341.19096.160.camel@willson.usersys.redhat.com> On Thu, 2015-05-28 at 16:23 +0200, Oleg Fayans wrote: > Hi Simo, > > On 05/28/2015 03:52 PM, Simo Sorce wrote: > > On Thu, 2015-05-28 at 15:39 +0200, Oleg Fayans wrote: > >> On 05/28/2015 03:26 PM, Simo Sorce wrote: > >>> On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote: > >>>> On 28.5.2015 10:49, Martin Kosek wrote: > >>>>> On 05/28/2015 09:05 AM, Petr Spacek wrote: > >>>>>> On 28.5.2015 08:55, Jan Cholasta wrote: > >>>>>>> Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): > >>>>>>>> On 26.5.2015 16:16, Martin Kosek wrote: > >>>>>>>>> On 05/26/2015 04:13 PM, thierry bordaz wrote: > >>>>>>>>>> On 05/26/2015 02:12 PM, Petr Spacek wrote: > >>>>>>>>>>> Hello, > >>>>>>>>>>> > >>>>>>>>>>> it came to my mind that domain level for topology plugin should actually be > >>>>>>>>>>> number 2, not 1. > >>>>>>>>>>> > >>>>>>>>>>> We already used number 1 for incompatible changes in DNS tree and I believe > >>>>>>>>>>> that it is not a good idea to have two places which say 'version 1' but and > >>>>>>>>>>> actually mean two different things. (DNS tree version 1 + domain level 1) > >>>>>>>>>>> > >>>>>>>>>>> Patch is attached. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> Hello, > >>>>>>>>>> The fix looks good but that seems strange to have to set the initial > >>>>>>>>>> version of > >>>>>>>>>> the topology plugin to 2.0. (IIUC That is the version that will be written in > >>>>>>>>>> dse.ldif) > >>>>>>>>>> I would rather expects that topology plugin 1.0, would activate itself if the > >>>>>>>>>> DomainLevel is 2.0 or more. > >>>>>>>>>> If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate > >>>>>>>>>> itself if DomainLevel >= DomainLevel_trigger. > >>>>>>>>>> > >>>>>>>>>> Let's wait for Ludwig feedback. > >>>>>>>>>> > >>>>>>>>>> thanks > >>>>>>>>>> thierry > >>>>>>>>> My personal opinion on this is to start with Domain Level 1 regardless. We > >>>>>>>>> already "solved" the DNS forwarders otherwise, with docs, async updates etc. I > >>>>>>>>> do not think we will be returning to implementing proper Domain Level support > >>>>>>>>> for that anyway. > >>>>>>>>> > >>>>>>>>> So I rather think that all the "Domain Level starts with 0, 1 is unused, 2 is > >>>>>>>>> the top one" will cause unforeseen issues I would rather like to avoid. > >>>>>>>> I'm more worried about confusion in future. To to me it simply seems easier to > >>>>>>>> bump one integer now than to document and explain (to users & new developers) > >>>>>>>> why we have two "ones" which mean something else. > >>>>>>>> > >>>>>>>> Code-wise it is just an integer. > >>>>>>>> > >>>>>>>> Also, it can simplify logic in future when we decide to do another > >>>>>>>> incompatible change in DNS tree because we will have only one integer to test > >>>>>>>> (instead of checking two separate version attribute in DNS tree & domain > >>>>>>>> level). > >>>>>>> +1, but I think the minimum supported domain level should be 1, not 0, because > >>>>>>> 0 means the server uses the old DNS schema, which we do not support anymore, > >>>>>>> right? > >>>>>> Good point! > >>>>>> > >>>>> It may be a good point, but it does not make the situation easier. You still > >>>>> have RHEL/CentOS 6.x IPA out there, where some of them already support the new > >>>>> DNS forwarders and some don't - and neither of them support Domain Levels - > >>>>> i.e. have Domain Level 0. > >>>>> > >>>>> As I said, I still see more complications with this proposals than benefits... > >>>> I would argue that it actually helps. > >>>> > >>>> If domain level = 1 then we can be *sure* that all replicas support the new > >>>> DNS semantics. > >>>> > >>>> If domain level = 0 then we know nothing (because of patched RHEL 6) and it is > >>>> a warning sign for diagnostic tools and also us when it comes to debugging. > >>> First of all a domain level is something we change *RARELY*, and it is > >>> a whole number and it is an all or nothing thing. > >>> > >>> I do not understand why plugin versions matter at all, plugin version > >>> have nothing to do with domain levels. Each plugin *whatever* the > >>> version MUST always support at least 2 levels, because every domain you > >>> have will have to go through a domain_level transition when a new domain > >>> level comes out. > >>> > >>> Finally no single developer should be allowed to decide on anew domain > >>> level, this must be a well ponder team decision as all plugins that need > >>> to change behavior based on domain level will be affected so a thorough > >>> review of what changes are needed across all plugins must be done every > >>> time someone propose a change that requires a domain level bump. > >>> > >>> Last but not least we should consider domain levels as something that > >>> changes *very* slowly, because otherwise you'll have to support many > >>> domain levels within any plugins that have to change behavior according > >>> to the domain level. > >>> I would say that the domain level should not change more frequently than > >>> once a year or so. It would be too much code churn to do otherwise. > >>> > >>> So for now domain_level should be set to 0. And the topology plugin will > >>> be enabled only when we turn it to 1. However we shouldn't turn it to 1 > >>> until we have the replica promotion code at least, because only then we > >>> can make full use of the topology plugins. > >> Does that mean, that by default domain level must be set to 0 and only > >> raised manually by the identity admin? > > Yes, the domain level is established by the first server you install, > > and CANNOT be raise automatically by a replica, it must be always > > manually raised by the admin. Moreover the code that raises *MUST* check > > that all server are capable of handling the new domain level or refuse > > to raise the level. > > This means all servers must publish the range of domain levels they > > support, a missing range means only level 0 is supported. > Thank you, this at last clarifies most of the use-cases. > The only question that remains: what will happen if an admin (for > whatever dumb reason) decides to downgrade the FreeIPA version to 4.1 (that does not support domain > levels) on the master of the domain that has domain level = 1? Do replicas preserve the information > of the topology? Do they delete this info from DS together with the record about the domain > level? Should we support such scenario at all? We do not support downgrades, probably everything will explode on the server if you even try :-) We just change so much not only in the directory but also in local configuration. I think in recent discussions we also said the updater will check what is the current version and just bail out on applying anything on "downgrades". So nothing would be changed in the directory and Freeipa should just fail to start (or worse). -- Simo Sorce * Red Hat, Inc * New York From cheimes at redhat.com Thu May 28 14:34:56 2015 From: cheimes at redhat.com (Christian Heimes) Date: Thu, 28 May 2015 16:34:56 +0200 Subject: [Freeipa-devel] KDC proxy implementation specs Message-ID: <55672790.6060206@redhat.com> Hello, thanks you for your input. The former thread has 58 messages in total. Since last Friday we have came to an agreement in most points. I like to some up our decisions and focus on some minor details. decisions --------- python-kdcproxy will be installed as a dependency of freeipa-server. There won't be a separate freeipa-server-kdcproxy package. That may or may not change in the future. The decision is out of scope for 4.2.0. [1] KDC proxy support will be enabled by default. The config files and LDAP settings will be created by ipa-server-install, ipa-server-upgrade and ipa-replica-install. The enabled/disabled switch will be stored per-replica in the cn=masters,cn=ipa,cn=etc tree. An API and CLI tool for management is postponed. [2] For now we settle for some doc examples that use the ipa-ldap-updater as suggested by Alex. [3] open for discussion ------------------- Jan has suggested to ipaConfigString=kdcProxyEnabled in cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc instead of ipaConfigString=enabledService in cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. It makes sense to me. After all MS-KKDCP is just another transport for the KDC. [4] Martin Basti suggested a different keytab and principal for kdcproxy. [5] The keytab is only required for GSSAPI bind to lookup the state of the enabled/disabled switch. The current patch uses the same keytab as webgui. A new principal separates kdcproxy more cleanly and allows for fine-grained ACIs. It is also more future proof. In the future we may want to move kdcproxy from an Apache WSGI app to a separate service. A dedicated Twisted or asyncio daemon could handle more load. A separate keytab is easy to implement, too. I looked at the code in HTTPInstance.__create_http_keytab(). For the ACI I plan to add a new permission 'System: Read IPA Config String' and make the principal a direct memberOf of it. We don't have service roles yet. cn=roles,cn=accounts look like end user roles to me. The new ACI in cn=masters,cn=ipa,cn=etc will grant read, search and compare permission: (targetfilter = "(objectClass=nsContainer)")(targetattr = "cn || objectClass || ipaConfigString")(version 3.0; acl "Read IPA Config String"; allow (read, search, compare) groupdn = "ldap:///cn=System: Read IPA Config String,cn=permissions,cn=pbac,dc=ipa,dc=example";) I should be able to modify and test my patch in a matter of a couple of hours. Christian [1] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00535.html [2] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00555.html [3] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00533.html [4] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00543.html [5] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00539.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From mbasti at redhat.com Thu May 28 14:40:06 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 28 May 2015 16:40:06 +0200 Subject: [Freeipa-devel] Domain level for topology plugin = 2 In-Reply-To: <1432823341.19096.160.camel@willson.usersys.redhat.com> References: <55646331.5050807@redhat.com> <55647F90.506@redhat.com> <5564804B.6080305@redhat.com> <5564841B.4020906@redhat.com> <5566BBFD.9070601@redhat.com> <5566BE3E.2060104@redhat.com> <5566D684.6080505@redhat.com> <5567060D.5010202@redhat.com> <1432819613.19096.138.camel@willson.usersys.redhat.com> <55671AA7.6040002@redhat.com> <1432821163.19096.146.camel@willson.usersys.redhat.com> <556724F8.3090200@redhat.com> <1432823341.19096.160.camel@willson.usersys.redhat.com> Message-ID: <556728C6.8060806@redhat.com> On 28/05/15 16:29, Simo Sorce wrote: > On Thu, 2015-05-28 at 16:23 +0200, Oleg Fayans wrote: >> Hi Simo, >> >> On 05/28/2015 03:52 PM, Simo Sorce wrote: >>> On Thu, 2015-05-28 at 15:39 +0200, Oleg Fayans wrote: >>>> On 05/28/2015 03:26 PM, Simo Sorce wrote: >>>>> On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote: >>>>>> On 28.5.2015 10:49, Martin Kosek wrote: >>>>>>> On 05/28/2015 09:05 AM, Petr Spacek wrote: >>>>>>>> On 28.5.2015 08:55, Jan Cholasta wrote: >>>>>>>>> Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): >>>>>>>>>> On 26.5.2015 16:16, Martin Kosek wrote: >>>>>>>>>>> On 05/26/2015 04:13 PM, thierry bordaz wrote: >>>>>>>>>>>> On 05/26/2015 02:12 PM, Petr Spacek wrote: >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> >>>>>>>>>>>>> it came to my mind that domain level for topology plugin should actually be >>>>>>>>>>>>> number 2, not 1. >>>>>>>>>>>>> >>>>>>>>>>>>> We already used number 1 for incompatible changes in DNS tree and I believe >>>>>>>>>>>>> that it is not a good idea to have two places which say 'version 1' but and >>>>>>>>>>>>> actually mean two different things. (DNS tree version 1 + domain level 1) >>>>>>>>>>>>> >>>>>>>>>>>>> Patch is attached. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Hello, >>>>>>>>>>>> The fix looks good but that seems strange to have to set the initial >>>>>>>>>>>> version of >>>>>>>>>>>> the topology plugin to 2.0. (IIUC That is the version that will be written in >>>>>>>>>>>> dse.ldif) >>>>>>>>>>>> I would rather expects that topology plugin 1.0, would activate itself if the >>>>>>>>>>>> DomainLevel is 2.0 or more. >>>>>>>>>>>> If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate >>>>>>>>>>>> itself if DomainLevel >= DomainLevel_trigger. >>>>>>>>>>>> >>>>>>>>>>>> Let's wait for Ludwig feedback. >>>>>>>>>>>> >>>>>>>>>>>> thanks >>>>>>>>>>>> thierry >>>>>>>>>>> My personal opinion on this is to start with Domain Level 1 regardless. We >>>>>>>>>>> already "solved" the DNS forwarders otherwise, with docs, async updates etc. I >>>>>>>>>>> do not think we will be returning to implementing proper Domain Level support >>>>>>>>>>> for that anyway. >>>>>>>>>>> >>>>>>>>>>> So I rather think that all the "Domain Level starts with 0, 1 is unused, 2 is >>>>>>>>>>> the top one" will cause unforeseen issues I would rather like to avoid. >>>>>>>>>> I'm more worried about confusion in future. To to me it simply seems easier to >>>>>>>>>> bump one integer now than to document and explain (to users & new developers) >>>>>>>>>> why we have two "ones" which mean something else. >>>>>>>>>> >>>>>>>>>> Code-wise it is just an integer. >>>>>>>>>> >>>>>>>>>> Also, it can simplify logic in future when we decide to do another >>>>>>>>>> incompatible change in DNS tree because we will have only one integer to test >>>>>>>>>> (instead of checking two separate version attribute in DNS tree & domain >>>>>>>>>> level). >>>>>>>>> +1, but I think the minimum supported domain level should be 1, not 0, because >>>>>>>>> 0 means the server uses the old DNS schema, which we do not support anymore, >>>>>>>>> right? >>>>>>>> Good point! >>>>>>>> >>>>>>> It may be a good point, but it does not make the situation easier. You still >>>>>>> have RHEL/CentOS 6.x IPA out there, where some of them already support the new >>>>>>> DNS forwarders and some don't - and neither of them support Domain Levels - >>>>>>> i.e. have Domain Level 0. >>>>>>> >>>>>>> As I said, I still see more complications with this proposals than benefits... >>>>>> I would argue that it actually helps. >>>>>> >>>>>> If domain level = 1 then we can be *sure* that all replicas support the new >>>>>> DNS semantics. >>>>>> >>>>>> If domain level = 0 then we know nothing (because of patched RHEL 6) and it is >>>>>> a warning sign for diagnostic tools and also us when it comes to debugging. >>>>> First of all a domain level is something we change *RARELY*, and it is >>>>> a whole number and it is an all or nothing thing. >>>>> >>>>> I do not understand why plugin versions matter at all, plugin version >>>>> have nothing to do with domain levels. Each plugin *whatever* the >>>>> version MUST always support at least 2 levels, because every domain you >>>>> have will have to go through a domain_level transition when a new domain >>>>> level comes out. >>>>> >>>>> Finally no single developer should be allowed to decide on anew domain >>>>> level, this must be a well ponder team decision as all plugins that need >>>>> to change behavior based on domain level will be affected so a thorough >>>>> review of what changes are needed across all plugins must be done every >>>>> time someone propose a change that requires a domain level bump. >>>>> >>>>> Last but not least we should consider domain levels as something that >>>>> changes *very* slowly, because otherwise you'll have to support many >>>>> domain levels within any plugins that have to change behavior according >>>>> to the domain level. >>>>> I would say that the domain level should not change more frequently than >>>>> once a year or so. It would be too much code churn to do otherwise. >>>>> >>>>> So for now domain_level should be set to 0. And the topology plugin will >>>>> be enabled only when we turn it to 1. However we shouldn't turn it to 1 >>>>> until we have the replica promotion code at least, because only then we >>>>> can make full use of the topology plugins. >>>> Does that mean, that by default domain level must be set to 0 and only >>>> raised manually by the identity admin? >>> Yes, the domain level is established by the first server you install, >>> and CANNOT be raise automatically by a replica, it must be always >>> manually raised by the admin. Moreover the code that raises *MUST* check >>> that all server are capable of handling the new domain level or refuse >>> to raise the level. >>> This means all servers must publish the range of domain levels they >>> support, a missing range means only level 0 is supported. >> Thank you, this at last clarifies most of the use-cases. >> The only question that remains: what will happen if an admin (for >> whatever dumb reason) decides to downgrade the FreeIPA version to 4.1 (that does not support domain >> levels) on the master of the domain that has domain level = 1? Do replicas preserve the information >> of the topology? Do they delete this info from DS together with the record about the domain >> level? Should we support such scenario at all? > We do not support downgrades, probably everything will explode on the > server if you even try :-) > > We just change so much not only in the directory but also in local > configuration. I think in recent discussions we also said the updater > will check what is the current version and just bail out on applying > anything on "downgrades". So nothing would be changed in the directory > and Freeipa should just fail to start (or worse). > > Actually, IPA 4-1 has old upgrade script, so it will be possible to run upgrade and break server. -- Martin Basti From simo at redhat.com Thu May 28 14:46:19 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 28 May 2015 10:46:19 -0400 Subject: [Freeipa-devel] Domain level for topology plugin = 2 In-Reply-To: <55671E18.8020807@redhat.com> References: <55646331.5050807@redhat.com> <55647F90.506@redhat.com> <5564804B.6080305@redhat.com> <5564841B.4020906@redhat.com> <5566BBFD.9070601@redhat.com> <5566BE3E.2060104@redhat.com> <5566D684.6080505@redhat.com> <5567060D.5010202@redhat.com> <1432819613.19096.138.camel@willson.usersys.redhat.com> <55671E18.8020807@redhat.com> Message-ID: <1432824379.19096.164.camel@willson.usersys.redhat.com> On Thu, 2015-05-28 at 15:54 +0200, Ludwig Krispenz wrote: > On 05/28/2015 03:26 PM, Simo Sorce wrote: > > On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote: > >> On 28.5.2015 10:49, Martin Kosek wrote: > >>> On 05/28/2015 09:05 AM, Petr Spacek wrote: > >>>> On 28.5.2015 08:55, Jan Cholasta wrote: > >>>>> Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): > >>>>>> On 26.5.2015 16:16, Martin Kosek wrote: > >>>>>>> On 05/26/2015 04:13 PM, thierry bordaz wrote: > >>>>>>>> On 05/26/2015 02:12 PM, Petr Spacek wrote: > >>>>>>>>> Hello, > >>>>>>>>> > >>>>>>>>> it came to my mind that domain level for topology plugin should actually be > >>>>>>>>> number 2, not 1. > >>>>>>>>> > >>>>>>>>> We already used number 1 for incompatible changes in DNS tree and I believe > >>>>>>>>> that it is not a good idea to have two places which say 'version 1' but and > >>>>>>>>> actually mean two different things. (DNS tree version 1 + domain level 1) > >>>>>>>>> > >>>>>>>>> Patch is attached. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> Hello, > >>>>>>>> The fix looks good but that seems strange to have to set the initial > >>>>>>>> version of > >>>>>>>> the topology plugin to 2.0. (IIUC That is the version that will be written in > >>>>>>>> dse.ldif) > >>>>>>>> I would rather expects that topology plugin 1.0, would activate itself if the > >>>>>>>> DomainLevel is 2.0 or more. > >>>>>>>> If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate > >>>>>>>> itself if DomainLevel >= DomainLevel_trigger. > >>>>>>>> > >>>>>>>> Let's wait for Ludwig feedback. > >>>>>>>> > >>>>>>>> thanks > >>>>>>>> thierry > >>>>>>> My personal opinion on this is to start with Domain Level 1 regardless. We > >>>>>>> already "solved" the DNS forwarders otherwise, with docs, async updates etc. I > >>>>>>> do not think we will be returning to implementing proper Domain Level support > >>>>>>> for that anyway. > >>>>>>> > >>>>>>> So I rather think that all the "Domain Level starts with 0, 1 is unused, 2 is > >>>>>>> the top one" will cause unforeseen issues I would rather like to avoid. > >>>>>> I'm more worried about confusion in future. To to me it simply seems easier to > >>>>>> bump one integer now than to document and explain (to users & new developers) > >>>>>> why we have two "ones" which mean something else. > >>>>>> > >>>>>> Code-wise it is just an integer. > >>>>>> > >>>>>> Also, it can simplify logic in future when we decide to do another > >>>>>> incompatible change in DNS tree because we will have only one integer to test > >>>>>> (instead of checking two separate version attribute in DNS tree & domain > >>>>>> level). > >>>>> +1, but I think the minimum supported domain level should be 1, not 0, because > >>>>> 0 means the server uses the old DNS schema, which we do not support anymore, > >>>>> right? > >>>> Good point! > >>>> > >>> It may be a good point, but it does not make the situation easier. You still > >>> have RHEL/CentOS 6.x IPA out there, where some of them already support the new > >>> DNS forwarders and some don't - and neither of them support Domain Levels - > >>> i.e. have Domain Level 0. > >>> > >>> As I said, I still see more complications with this proposals than benefits... > >> I would argue that it actually helps. > >> > >> If domain level = 1 then we can be *sure* that all replicas support the new > >> DNS semantics. > >> > >> If domain level = 0 then we know nothing (because of patched RHEL 6) and it is > >> a warning sign for diagnostic tools and also us when it comes to debugging. > > First of all a domain level is something we change *RARELY*, and it is > > a whole number and it is an all or nothing thing. > > > > I do not understand why plugin versions matter at all, plugin version > > have nothing to do with domain levels. Each plugin *whatever* the > > version MUST always support at least 2 levels, because every domain you > > have will have to go through a domain_level transition when a new domain > > level comes out. > > > > Finally no single developer should be allowed to decide on anew domain > > level, this must be a well ponder team decision as all plugins that need > > to change behavior based on domain level will be affected so a thorough > > review of what changes are needed across all plugins must be done every > > time someone propose a change that requires a domain level bump. > > > > Last but not least we should consider domain levels as something that > > changes *very* slowly, because otherwise you'll have to support many > > domain levels within any plugins that have to change behavior according > > to the domain level. > > I would say that the domain level should not change more frequently than > > once a year or so. It would be too much code churn to do otherwise. > > > > So for now domain_level should be set to 0. And the topology plugin will > > be enabled only when we turn it to 1. However we shouldn't turn it to 1 > > until we have the replica promotion code at least, because only then we > > can make full use of the topology plugins. > > > > The DNS mess is unfixable, unless Petr you volunteer to backport code to > > change the behavior of the DNS based on the domain level, if that's the > > case then you can tie old behavior to level 0 and new behavior to level > >> = 1, but I do not think you want to do that given we already have > > "level 0" servers that sport the new code and changed the data in the > > directory, so let's just ignore DNS for the purpose of this discussion, > > except for nothing that once we finally switch to level 1 then all > > servers must be running with the newer DNS schema and older is not > > supported. > > > > Ah, I almost forgot, there is no "domain level for XYZ plugin", the > > domain level is one for the whole server, I want to make it very clear, > > because the title and part of the discussion seem to imply that you have > > per-plugin domain levels. If anything like that actually exist in the > > topology plugin code it must be ripped out now, plugin version and > > domain level are completely disjointed things and no correlation should > > or can exist, the only thing that can exist is whether the server, as a > > whole, supports a specific domain level or not. > > > > So once we decide domain level X comes to existence we basically freeze > > what it means and any new development that may require a domain level > > bump risk being delayed until we are ready for a new domain level bump, > > which should not happen very often. > > > > So let's make it very clear what level 1 means because the next release > > will then support only 0 and 1, and once a new version will come out > > with support for "level 2" we want be able to use any of the features > > tied to level 2 until all servers in the next release have been > > upgraded, and that may be a years long process, so we can't just churn > > domain level numbers as we need to support working on older levels for > > extended periods. > Hi Simo, > > you say the topology plugin should only activate itself if the domain > level is >= 1, at the moment this is done > by checking if plugin_version (1.0) >= domain_level (1). I do not understand what this means. > If you want a different method/fields for decision, how do you want it > handled ? I do not see why you need to check for the topology plugin version, what you need is a "min_domain_level" version for now and just check: if domain_level >= min_domain_level: do stuff In the future we may grow more complex requirements and activate 'parts' of the plugin based on the domain level, so you could have something like: if domain_level >= min_domain_level: do basic stuff if domain_level >= feature_X_min_domain_level: enable feature X So a general topology plugin version is not really interesting, the code above may still be there in version 5.0 of the topology plugin. We need a general minimum domain level version and then in future per-feature minimum domain level checks. Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Thu May 28 14:48:45 2015 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 28 May 2015 10:48:45 -0400 Subject: [Freeipa-devel] KDC proxy implementation specs In-Reply-To: <55672790.6060206@redhat.com> References: <55672790.6060206@redhat.com> Message-ID: <1432824525.2618.7.camel@redhat.com> On Thu, 2015-05-28 at 16:34 +0200, Christian Heimes wrote: > Hello, > > thanks you for your input. The former thread has 58 messages in > total. > Since last Friday we have came to an agreement in most points. I like > to > some up our decisions and focus on some minor details. > > decisions > --------- > > python-kdcproxy will be installed as a dependency of freeipa-server. > There won't be a separate freeipa-server-kdcproxy package. That may > or > may not change in the future. The decision is out of scope for 4.2.0. > [1] > > KDC proxy support will be enabled by default. The config files and > LDAP > settings will be created by ipa-server-install, ipa-server-upgrade > and > ipa-replica-install. > > The enabled/disabled switch will be stored per-replica in the > cn=masters,cn=ipa,cn=etc tree. An API and CLI tool for management is > postponed. [2] For now we settle for some doc examples that use the > ipa-ldap-updater as suggested by Alex. [3] > > > open for discussion > ------------------- > > Jan has suggested to ipaConfigString=kdcProxyEnabled in > cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc instead of > ipaConfigString=enabledService in > cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. It makes sense to me. > After all MS-KKDCP is just another transport for the KDC. [4] There may be a security concern here if we aren't careful. I think I'm in favor of KDCPROXY since it is a different application. > Martin Basti suggested a different keytab and principal for kdcproxy. > [5] The keytab is only required for GSSAPI bind to lookup the state > of > the enabled/disabled switch. The current patch uses the same keytab > as > webgui. > A new principal separates kdcproxy more cleanly and allows for > fine-grained ACIs. It is also more future proof. It may also have auditing benefits now that we are beginning to think about the A in FreeIPA. > In the future we may > want to move kdcproxy from an Apache WSGI app to a separate service. > A > dedicated Twisted or asyncio daemon could handle more load. > A separate keytab is easy to implement, too. I looked at the code in > HTTPInstance.__create_http_keytab(). An apache module would also provide similar benefits. I'm not sure I necessarily want to stick with python here if we're optimizing for performance. Another option would be to add it to the KDC itself and proxy through Apache like we do for Tomcat. MIT might like that option. > For the ACI I plan to add a new permission 'System: Read IPA Config > String' and make the principal a direct memberOf of it. We don't have > service roles yet. cn=roles,cn=accounts look like end user roles to > me. > The new ACI in cn=masters,cn=ipa,cn=etc will grant read, search and > compare permission: > > (targetfilter = "(objectClass=nsContainer)")(targetattr = "cn || > objectClass || ipaConfigString")(version 3.0; acl "Read IPA Config > String"; allow (read, search, compare) groupdn = "ldap:///cn=System: > Read IPA Config String,cn=permissions,cn=pbac,dc=ipa,dc=example";) > > > I should be able to modify and test my patch in a matter of a couple > of > hours. > > Christian > > [1] > http://www.redhat.com/archives/freeipa-devel/2015-May/msg00535.html > [2] > http://www.redhat.com/archives/freeipa-devel/2015-May/msg00555.html > [3] > http://www.redhat.com/archives/freeipa-devel/2015-May/msg00533.html > [4] > http://www.redhat.com/archives/freeipa-devel/2015-May/msg00543.html > [5] > http://www.redhat.com/archives/freeipa-devel/2015-May/msg00539.html > > -- > 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 From simo at redhat.com Thu May 28 14:49:24 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 28 May 2015 10:49:24 -0400 Subject: [Freeipa-devel] Domain level for topology plugin = 2 In-Reply-To: <1432824379.19096.164.camel@willson.usersys.redhat.com> References: <55646331.5050807@redhat.com> <55647F90.506@redhat.com> <5564804B.6080305@redhat.com> <5564841B.4020906@redhat.com> <5566BBFD.9070601@redhat.com> <5566BE3E.2060104@redhat.com> <5566D684.6080505@redhat.com> <5567060D.5010202@redhat.com> <1432819613.19096.138.camel@willson.usersys.redhat.com> <55671E18.8020807@redhat.com> <1432824379.19096.164.camel@willson.usersys.redhat.com> Message-ID: <1432824564.19096.166.camel@willson.usersys.redhat.com> On Thu, 2015-05-28 at 10:46 -0400, Simo Sorce wrote: > On Thu, 2015-05-28 at 15:54 +0200, Ludwig Krispenz wrote: > > On 05/28/2015 03:26 PM, Simo Sorce wrote: > > > On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote: > > >> On 28.5.2015 10:49, Martin Kosek wrote: > > >>> On 05/28/2015 09:05 AM, Petr Spacek wrote: > > >>>> On 28.5.2015 08:55, Jan Cholasta wrote: > > >>>>> Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): > > >>>>>> On 26.5.2015 16:16, Martin Kosek wrote: > > >>>>>>> On 05/26/2015 04:13 PM, thierry bordaz wrote: > > >>>>>>>> On 05/26/2015 02:12 PM, Petr Spacek wrote: > > >>>>>>>>> Hello, > > >>>>>>>>> > > >>>>>>>>> it came to my mind that domain level for topology plugin should actually be > > >>>>>>>>> number 2, not 1. > > >>>>>>>>> > > >>>>>>>>> We already used number 1 for incompatible changes in DNS tree and I believe > > >>>>>>>>> that it is not a good idea to have two places which say 'version 1' but and > > >>>>>>>>> actually mean two different things. (DNS tree version 1 + domain level 1) > > >>>>>>>>> > > >>>>>>>>> Patch is attached. > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>> Hello, > > >>>>>>>> The fix looks good but that seems strange to have to set the initial > > >>>>>>>> version of > > >>>>>>>> the topology plugin to 2.0. (IIUC That is the version that will be written in > > >>>>>>>> dse.ldif) > > >>>>>>>> I would rather expects that topology plugin 1.0, would activate itself if the > > >>>>>>>> DomainLevel is 2.0 or more. > > >>>>>>>> If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate > > >>>>>>>> itself if DomainLevel >= DomainLevel_trigger. > > >>>>>>>> > > >>>>>>>> Let's wait for Ludwig feedback. > > >>>>>>>> > > >>>>>>>> thanks > > >>>>>>>> thierry > > >>>>>>> My personal opinion on this is to start with Domain Level 1 regardless. We > > >>>>>>> already "solved" the DNS forwarders otherwise, with docs, async updates etc. I > > >>>>>>> do not think we will be returning to implementing proper Domain Level support > > >>>>>>> for that anyway. > > >>>>>>> > > >>>>>>> So I rather think that all the "Domain Level starts with 0, 1 is unused, 2 is > > >>>>>>> the top one" will cause unforeseen issues I would rather like to avoid. > > >>>>>> I'm more worried about confusion in future. To to me it simply seems easier to > > >>>>>> bump one integer now than to document and explain (to users & new developers) > > >>>>>> why we have two "ones" which mean something else. > > >>>>>> > > >>>>>> Code-wise it is just an integer. > > >>>>>> > > >>>>>> Also, it can simplify logic in future when we decide to do another > > >>>>>> incompatible change in DNS tree because we will have only one integer to test > > >>>>>> (instead of checking two separate version attribute in DNS tree & domain > > >>>>>> level). > > >>>>> +1, but I think the minimum supported domain level should be 1, not 0, because > > >>>>> 0 means the server uses the old DNS schema, which we do not support anymore, > > >>>>> right? > > >>>> Good point! > > >>>> > > >>> It may be a good point, but it does not make the situation easier. You still > > >>> have RHEL/CentOS 6.x IPA out there, where some of them already support the new > > >>> DNS forwarders and some don't - and neither of them support Domain Levels - > > >>> i.e. have Domain Level 0. > > >>> > > >>> As I said, I still see more complications with this proposals than benefits... > > >> I would argue that it actually helps. > > >> > > >> If domain level = 1 then we can be *sure* that all replicas support the new > > >> DNS semantics. > > >> > > >> If domain level = 0 then we know nothing (because of patched RHEL 6) and it is > > >> a warning sign for diagnostic tools and also us when it comes to debugging. > > > First of all a domain level is something we change *RARELY*, and it is > > > a whole number and it is an all or nothing thing. > > > > > > I do not understand why plugin versions matter at all, plugin version > > > have nothing to do with domain levels. Each plugin *whatever* the > > > version MUST always support at least 2 levels, because every domain you > > > have will have to go through a domain_level transition when a new domain > > > level comes out. > > > > > > Finally no single developer should be allowed to decide on anew domain > > > level, this must be a well ponder team decision as all plugins that need > > > to change behavior based on domain level will be affected so a thorough > > > review of what changes are needed across all plugins must be done every > > > time someone propose a change that requires a domain level bump. > > > > > > Last but not least we should consider domain levels as something that > > > changes *very* slowly, because otherwise you'll have to support many > > > domain levels within any plugins that have to change behavior according > > > to the domain level. > > > I would say that the domain level should not change more frequently than > > > once a year or so. It would be too much code churn to do otherwise. > > > > > > So for now domain_level should be set to 0. And the topology plugin will > > > be enabled only when we turn it to 1. However we shouldn't turn it to 1 > > > until we have the replica promotion code at least, because only then we > > > can make full use of the topology plugins. > > > > > > The DNS mess is unfixable, unless Petr you volunteer to backport code to > > > change the behavior of the DNS based on the domain level, if that's the > > > case then you can tie old behavior to level 0 and new behavior to level > > >> = 1, but I do not think you want to do that given we already have > > > "level 0" servers that sport the new code and changed the data in the > > > directory, so let's just ignore DNS for the purpose of this discussion, > > > except for nothing that once we finally switch to level 1 then all > > > servers must be running with the newer DNS schema and older is not > > > supported. > > > > > > Ah, I almost forgot, there is no "domain level for XYZ plugin", the > > > domain level is one for the whole server, I want to make it very clear, > > > because the title and part of the discussion seem to imply that you have > > > per-plugin domain levels. If anything like that actually exist in the > > > topology plugin code it must be ripped out now, plugin version and > > > domain level are completely disjointed things and no correlation should > > > or can exist, the only thing that can exist is whether the server, as a > > > whole, supports a specific domain level or not. > > > > > > So once we decide domain level X comes to existence we basically freeze > > > what it means and any new development that may require a domain level > > > bump risk being delayed until we are ready for a new domain level bump, > > > which should not happen very often. > > > > > > So let's make it very clear what level 1 means because the next release > > > will then support only 0 and 1, and once a new version will come out > > > with support for "level 2" we want be able to use any of the features > > > tied to level 2 until all servers in the next release have been > > > upgraded, and that may be a years long process, so we can't just churn > > > domain level numbers as we need to support working on older levels for > > > extended periods. > > Hi Simo, > > > > you say the topology plugin should only activate itself if the domain > > level is >= 1, at the moment this is done > > by checking if plugin_version (1.0) >= domain_level (1). > > I do not understand what this means. > > > If you want a different method/fields for decision, how do you want it > > handled ? > > I do not see why you need to check for the topology plugin version, what > you need is a "min_domain_level" version for now and just check: > if domain_level >= min_domain_level: > do stuff > > In the future we may grow more complex requirements and activate 'parts' > of the plugin based on the domain level, so you could have something > like: > > if domain_level >= min_domain_level: > do basic stuff > if domain_level >= feature_X_min_domain_level: > enable feature X > > > So a general topology plugin version is not really interesting, the code > above may still be there in version 5.0 of the topology plugin. > We need a general minimum domain level version and then in future > per-feature minimum domain level checks. Let me add, care needs to be taken to think and understand what happens at the moment the domain level is raised across a domain. Until the new level attribute is replicated across the domain some servers may temporarily still have the previous level behavior, so graceful handling of errors should any communication between servers depend on the domain level will be necessary. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Thu May 28 14:53:59 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 28 May 2015 10:53:59 -0400 Subject: [Freeipa-devel] KDC proxy implementation specs In-Reply-To: <1432824525.2618.7.camel@redhat.com> References: <55672790.6060206@redhat.com> <1432824525.2618.7.camel@redhat.com> Message-ID: <1432824839.19096.170.camel@willson.usersys.redhat.com> On Thu, 2015-05-28 at 10:48 -0400, Nathaniel McCallum wrote: > On Thu, 2015-05-28 at 16:34 +0200, Christian Heimes wrote: > > Hello, > > > > thanks you for your input. The former thread has 58 messages in > > total. > > Since last Friday we have came to an agreement in most points. I like > > to > > some up our decisions and focus on some minor details. > > > > decisions > > --------- > > > > python-kdcproxy will be installed as a dependency of freeipa-server. > > There won't be a separate freeipa-server-kdcproxy package. That may > > or > > may not change in the future. The decision is out of scope for 4.2.0. > > [1] > > > > KDC proxy support will be enabled by default. The config files and > > LDAP > > settings will be created by ipa-server-install, ipa-server-upgrade > > and > > ipa-replica-install. > > > > The enabled/disabled switch will be stored per-replica in the > > cn=masters,cn=ipa,cn=etc tree. An API and CLI tool for management is > > postponed. [2] For now we settle for some doc examples that use the > > ipa-ldap-updater as suggested by Alex. [3] > > > > > > open for discussion > > ------------------- > > > > Jan has suggested to ipaConfigString=kdcProxyEnabled in > > cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc instead of > > ipaConfigString=enabledService in > > cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. It makes sense to me. > > After all MS-KKDCP is just another transport for the KDC. [4] > > There may be a security concern here if we aren't careful. I think I'm > in favor of KDCPROXY since it is a different application. > > > Martin Basti suggested a different keytab and principal for kdcproxy. > > [5] The keytab is only required for GSSAPI bind to lookup the state > > of > > the enabled/disabled switch. The current patch uses the same keytab > > as > > webgui. > > A new principal separates kdcproxy more cleanly and allows for > > fine-grained ACIs. It is also more future proof. > > It may also have auditing benefits now that we are beginning to think > about the A in FreeIPA. We can't have 2 different keytabs with the same principal name. If we need privilege separation we'll have to work on integrating GSS-Proxy and give the keytab only to GSS-Proxy leaving it off the hands of both the framework, the proxy, and apache itself. Although to be honest I do not see why the proxy need access to the keytab at all, can we simply run it as a wsgi application under a different user and prevent it from accessing the apache keytab at all ? > > In the future we may > > want to move kdcproxy from an Apache WSGI app to a separate service. > > A > > dedicated Twisted or asyncio daemon could handle more load. > > A separate keytab is easy to implement, too. I looked at the code in > > HTTPInstance.__create_http_keytab(). > > An apache module would also provide similar benefits. I'm not sure I > necessarily want to stick with python here if we're optimizing for > performance. Another option would be to add it to the KDC itself and > proxy through Apache like we do for Tomcat. MIT might like that option. What do we need the keytab for ? Is it just in order to authenticate and read if the service is enabled ? Can we make that information available anonymously ? > > For the ACI I plan to add a new permission 'System: Read IPA Config > > String' and make the principal a direct memberOf of it. We don't have > > service roles yet. cn=roles,cn=accounts look like end user roles to > > me. > > The new ACI in cn=masters,cn=ipa,cn=etc will grant read, search and > > compare permission: > > > > (targetfilter = "(objectClass=nsContainer)")(targetattr = "cn || > > objectClass || ipaConfigString")(version 3.0; acl "Read IPA Config > > String"; allow (read, search, compare) groupdn = "ldap:///cn=System: > > Read IPA Config String,cn=permissions,cn=pbac,dc=ipa,dc=example";) > > > > > > I should be able to modify and test my patch in a matter of a couple > > of > > hours. > > > > Christian > > > > [1] > > http://www.redhat.com/archives/freeipa-devel/2015-May/msg00535.html > > [2] > > http://www.redhat.com/archives/freeipa-devel/2015-May/msg00555.html > > [3] > > http://www.redhat.com/archives/freeipa-devel/2015-May/msg00533.html > > [4] > > http://www.redhat.com/archives/freeipa-devel/2015-May/msg00543.html > > [5] > > http://www.redhat.com/archives/freeipa-devel/2015-May/msg00539.html > > > > -- > > 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 > -- Simo Sorce * Red Hat, Inc * New York From lkrispen at redhat.com Thu May 28 14:59:35 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 28 May 2015 16:59:35 +0200 Subject: [Freeipa-devel] Domain level for topology plugin = 2 In-Reply-To: <1432824379.19096.164.camel@willson.usersys.redhat.com> References: <55646331.5050807@redhat.com> <55647F90.506@redhat.com> <5564804B.6080305@redhat.com> <5564841B.4020906@redhat.com> <5566BBFD.9070601@redhat.com> <5566BE3E.2060104@redhat.com> <5566D684.6080505@redhat.com> <5567060D.5010202@redhat.com> <1432819613.19096.138.camel@willson.usersys.redhat.com> <55671E18.8020807@redhat.com> <1432824379.19096.164.camel@willson.usersys.redhat.com> Message-ID: <55672D57.7040308@redhat.com> On 05/28/2015 04:46 PM, Simo Sorce wrote: > On Thu, 2015-05-28 at 15:54 +0200, Ludwig Krispenz wrote: >> On 05/28/2015 03:26 PM, Simo Sorce wrote: >>> On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote: >>>> On 28.5.2015 10:49, Martin Kosek wrote: >>>>> On 05/28/2015 09:05 AM, Petr Spacek wrote: >>>>>> On 28.5.2015 08:55, Jan Cholasta wrote: >>>>>>> Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): >>>>>>>> On 26.5.2015 16:16, Martin Kosek wrote: >>>>>>>>> On 05/26/2015 04:13 PM, thierry bordaz wrote: >>>>>>>>>> On 05/26/2015 02:12 PM, Petr Spacek wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> it came to my mind that domain level for topology plugin should actually be >>>>>>>>>>> number 2, not 1. >>>>>>>>>>> >>>>>>>>>>> We already used number 1 for incompatible changes in DNS tree and I believe >>>>>>>>>>> that it is not a good idea to have two places which say 'version 1' but and >>>>>>>>>>> actually mean two different things. (DNS tree version 1 + domain level 1) >>>>>>>>>>> >>>>>>>>>>> Patch is attached. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> The fix looks good but that seems strange to have to set the initial >>>>>>>>>> version of >>>>>>>>>> the topology plugin to 2.0. (IIUC That is the version that will be written in >>>>>>>>>> dse.ldif) >>>>>>>>>> I would rather expects that topology plugin 1.0, would activate itself if the >>>>>>>>>> DomainLevel is 2.0 or more. >>>>>>>>>> If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate >>>>>>>>>> itself if DomainLevel >= DomainLevel_trigger. >>>>>>>>>> >>>>>>>>>> Let's wait for Ludwig feedback. >>>>>>>>>> >>>>>>>>>> thanks >>>>>>>>>> thierry >>>>>>>>> My personal opinion on this is to start with Domain Level 1 regardless. We >>>>>>>>> already "solved" the DNS forwarders otherwise, with docs, async updates etc. I >>>>>>>>> do not think we will be returning to implementing proper Domain Level support >>>>>>>>> for that anyway. >>>>>>>>> >>>>>>>>> So I rather think that all the "Domain Level starts with 0, 1 is unused, 2 is >>>>>>>>> the top one" will cause unforeseen issues I would rather like to avoid. >>>>>>>> I'm more worried about confusion in future. To to me it simply seems easier to >>>>>>>> bump one integer now than to document and explain (to users & new developers) >>>>>>>> why we have two "ones" which mean something else. >>>>>>>> >>>>>>>> Code-wise it is just an integer. >>>>>>>> >>>>>>>> Also, it can simplify logic in future when we decide to do another >>>>>>>> incompatible change in DNS tree because we will have only one integer to test >>>>>>>> (instead of checking two separate version attribute in DNS tree & domain >>>>>>>> level). >>>>>>> +1, but I think the minimum supported domain level should be 1, not 0, because >>>>>>> 0 means the server uses the old DNS schema, which we do not support anymore, >>>>>>> right? >>>>>> Good point! >>>>>> >>>>> It may be a good point, but it does not make the situation easier. You still >>>>> have RHEL/CentOS 6.x IPA out there, where some of them already support the new >>>>> DNS forwarders and some don't - and neither of them support Domain Levels - >>>>> i.e. have Domain Level 0. >>>>> >>>>> As I said, I still see more complications with this proposals than benefits... >>>> I would argue that it actually helps. >>>> >>>> If domain level = 1 then we can be *sure* that all replicas support the new >>>> DNS semantics. >>>> >>>> If domain level = 0 then we know nothing (because of patched RHEL 6) and it is >>>> a warning sign for diagnostic tools and also us when it comes to debugging. >>> First of all a domain level is something we change *RARELY*, and it is >>> a whole number and it is an all or nothing thing. >>> >>> I do not understand why plugin versions matter at all, plugin version >>> have nothing to do with domain levels. Each plugin *whatever* the >>> version MUST always support at least 2 levels, because every domain you >>> have will have to go through a domain_level transition when a new domain >>> level comes out. >>> >>> Finally no single developer should be allowed to decide on anew domain >>> level, this must be a well ponder team decision as all plugins that need >>> to change behavior based on domain level will be affected so a thorough >>> review of what changes are needed across all plugins must be done every >>> time someone propose a change that requires a domain level bump. >>> >>> Last but not least we should consider domain levels as something that >>> changes *very* slowly, because otherwise you'll have to support many >>> domain levels within any plugins that have to change behavior according >>> to the domain level. >>> I would say that the domain level should not change more frequently than >>> once a year or so. It would be too much code churn to do otherwise. >>> >>> So for now domain_level should be set to 0. And the topology plugin will >>> be enabled only when we turn it to 1. However we shouldn't turn it to 1 >>> until we have the replica promotion code at least, because only then we >>> can make full use of the topology plugins. >>> >>> The DNS mess is unfixable, unless Petr you volunteer to backport code to >>> change the behavior of the DNS based on the domain level, if that's the >>> case then you can tie old behavior to level 0 and new behavior to level >>>> = 1, but I do not think you want to do that given we already have >>> "level 0" servers that sport the new code and changed the data in the >>> directory, so let's just ignore DNS for the purpose of this discussion, >>> except for nothing that once we finally switch to level 1 then all >>> servers must be running with the newer DNS schema and older is not >>> supported. >>> >>> Ah, I almost forgot, there is no "domain level for XYZ plugin", the >>> domain level is one for the whole server, I want to make it very clear, >>> because the title and part of the discussion seem to imply that you have >>> per-plugin domain levels. If anything like that actually exist in the >>> topology plugin code it must be ripped out now, plugin version and >>> domain level are completely disjointed things and no correlation should >>> or can exist, the only thing that can exist is whether the server, as a >>> whole, supports a specific domain level or not. >>> >>> So once we decide domain level X comes to existence we basically freeze >>> what it means and any new development that may require a domain level >>> bump risk being delayed until we are ready for a new domain level bump, >>> which should not happen very often. >>> >>> So let's make it very clear what level 1 means because the next release >>> will then support only 0 and 1, and once a new version will come out >>> with support for "level 2" we want be able to use any of the features >>> tied to level 2 until all servers in the next release have been >>> upgraded, and that may be a years long process, so we can't just churn >>> domain level numbers as we need to support working on older levels for >>> extended periods. >> Hi Simo, >> >> you say the topology plugin should only activate itself if the domain >> level is >= 1, at the moment this is done >> by checking if plugin_version (1.0) >= domain_level (1). > I do not understand what this means > >> If you want a different method/fields for decision, how do you want it >> handled ? > I do not see why you need to check for the topology plugin version, what > you need is a "min_domain_level" version for now and just check: > if domain_level >= min_domain_level: > do stuff but right now installation sets ipaMinDomainLevel: 0 ipaMaxDomainLevel: 1 in the master entry, so we would always do stuff. > > In the future we may grow more complex requirements and activate 'parts' > of the plugin based on the domain level, so you could have something > like: > > if domain_level >= min_domain_level: > do basic stuff > if domain_level >= feature_X_min_domain_level: > enable feature X > > > So a general topology plugin version is not really interesting, the code > above may still be there in version 5.0 of the topology plugin. > We need a general minimum domain level version and then in future > per-feature minimum domain level checks. > > Simo. > > From ssorce at redhat.com Thu May 28 14:57:39 2015 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 28 May 2015 10:57:39 -0400 Subject: [Freeipa-devel] New replica installation and topology - we need stable base In-Reply-To: <556722DA.7010703@redhat.com> References: <5565DBB7.1030304@redhat.com> <55671C65.3020406@redhat.com> <1432821607.19096.152.camel@willson.usersys.redhat.com> <55671FDA.8030301@redhat.com> <1432822029.19096.154.camel@willson.usersys.redhat.com> <556722DA.7010703@redhat.com> Message-ID: <1432825059.19096.172.camel@willson.usersys.redhat.com> On Thu, 2015-05-28 at 16:14 +0200, Martin Kosek wrote: > On 05/28/2015 04:07 PM, Simo Sorce wrote: > > On Thu, 2015-05-28 at 16:02 +0200, Martin Kosek wrote: > >> On 05/28/2015 04:00 PM, Simo Sorce wrote: > >>> On Thu, 2015-05-28 at 15:47 +0200, Martin Kosek wrote: > >>>> On 05/27/2015 04:59 PM, Martin Kosek wrote: > >>>> ... > >>>>> Domain Levels > >>>>> - Done, committed > >>>>> - Defaults to Level 1, i.e. Topology plugin powered infra enabled > >>>> > >>>> With respect to related Simo's response in > >>>> http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html > >>>> > >>>> Would we want to enable Topology (i.e. Domain Level 1) even if Replica > >>>> promotion is not done? I thought we do as I see those as orthogonal features. > >>>> Replica promotion would take advantage of the Topology plugin, but it does not > >>>> mean you cannot benefit from Topology plugin without it. > >>>> > >>>> You can still use the API to see/manage the topology and set replication > >>>> settings with it. You do not need Replica Promotion for that... > >>> > >>> You cannot move for domain level 0 to 1 automatically anyway. So this is > >>> a moot point to some degree. In general we need to have the code that > >>> checks for the domain level version to be able to change the level, so > >>> we need new code in replicas to publish the supported domain level > >>> version and code in the install patchs to check that we can actually > >>> join a domain given its current domain level status. > >>> > >>> These checks are absolutely a critical blocker to enable the whole > >>> domain-level feature. > >> > >> All the functionality you describe and the checks should be already there. I > >> was really only asking about the default domain level for *new* installations > >> > >> Old/upgraded FreeIPA will be on the Domain Level 0 of course. > > > > I think new installation should be on 1 but only if we have decided and > > finalized what "level 1" is. > > > > Simo. > > > > In my mind, Domain Level 1 means: > > - Topology plugins is activated for all replicas and manages the agreements > - All changes to topology can be only made via topology-* commands > - ipa-replica-manage connect|disconnect are not allowed Ok, if we want to restrict it to this then fine. In my original plan level 1 also meant the KISS/Custodia service is available on all master. If not then we cannot depend on it and we cannot fully finish the work on replica promotion w/o requiring the replica package anymore. Simo. From mkosek at redhat.com Thu May 28 14:58:53 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 May 2015 16:58:53 +0200 Subject: [Freeipa-devel] Sudorules user validation help In-Reply-To: <556725CA.6020709@redhat.com> References: <55660FDE.3030202@redhat.com> <5566D557.9030503@redhat.com> <55671ABA.9090709@redhat.com> <556725CA.6020709@redhat.com> Message-ID: <55672D2D.6050806@redhat.com> On 05/28/2015 04:27 PM, Drew Erny wrote: > In the ticket, however, it's stated that if the user wants to use any > combination of weird characters, they should be able to. Would it be better to > just define a function like > > def validate_username(username, ignore_pattern=False): > > and have it ignore all username validation? Tough question. FreeIPA in general tries to sanitize user input and does not allow everything user wants and try to advise the best practices, as we see it. In your case, if we allow only the 2 mentioned user login formats, it should work for AD use case just fine and add some level of sanity check of the user name. BTW, given we run an LDAP search later on this user name, isn't there a possibility of "LDAP injection" if we choose to allow all characters, including "(" and ")"? :-) In any case, if we choose to ignore the pattern, we do not need the extra validator function at all. We would just skip validation in the pre callback if a user is being added. > > On 05/28/2015 09:40 AM, Drew Erny wrote: >> OK, I see now what you mean by that. That is a simpler solution. I'll do it >> that way. >> >> On 05/28/2015 04:44 AM, Martin Kosek wrote: >>> On 05/27/2015 08:41 PM, Drew Erny wrote: >>>> Hey, Freeipa-devel, >>>> >>>> I'm working on ticket #3226 (https://fedorahosted.org/freeipa/ticket/3226) >>>> >>>> I've identified the problem. The sudorules add user command adds the user >>>> validations at the end of it's pre-callback using add_external_pre_callback. >>>> However, the "user" plugin pattern-matches a string for the "uid" param, >>>> because it only allows certain characters. >>>> >>>> I've been picking through the codebase and I think I have enough understanding >>>> to ask this: What if we changed the user "uid" validation to a standalone >>>> "rule" function (you can do that, right? pass in a function as a validation >>>> rule?) that would normally just assert that the pattern matches, but could >>>> have >>>> that pattern matching validation overridden in some cases. I think that's the >>>> easiest, cleanest way to change user so that sudorules and other plugins can >>>> ignore this validation if necessary (I'm trying to figure out exactly how to >>>> implement this without changing any APIs). >>>> >>>> Am I understanding the plugin params API correctly, and can I do this? Is this >>>> the best way to do this? >>>> >>>> The only other solution I see is to write sudorules-specific code in some >>>> plugin-related (either user.py or baseldap.py module, which would create >>>> unwanted coupling. >>>> >>>> Most specifically, this would be a change to the object instantiated at >>>> ipalib/plugins/user.py line 467 >>>> >>>> Thoughts and suggestions? >>> I think it would make sense to follow the example with validate_hostname and >>> prepare a function validate_username(username, upn=False, >>> netbios_name=False) [1]. >>> >>> where upn would allow using "@." on top of current validator (i.e. >>> user at Domain.test) and netbios_name would allow the "DOMAIN\user" style. I would >>> just suggest making sure the standard user validation error message is still >>> the same to avoid unnecessary QE fail positives. >>> >>> In add_external_pre_callback you could then just simply call >>> >>> validate_username(user, True, True) >>> >>> just like it is already done with hostname. >>> >>> My 2 cents. >>> >>> Martin >>> >>> [1] >>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa380525(v=vs.85).aspx >> > From cheimes at redhat.com Thu May 28 15:00:21 2015 From: cheimes at redhat.com (Christian Heimes) Date: Thu, 28 May 2015 17:00:21 +0200 Subject: [Freeipa-devel] KDC proxy implementation specs In-Reply-To: <1432824839.19096.170.camel@willson.usersys.redhat.com> References: <55672790.6060206@redhat.com> <1432824525.2618.7.camel@redhat.com> <1432824839.19096.170.camel@willson.usersys.redhat.com> Message-ID: <55672D85.1060501@redhat.com> On 2015-05-28 16:53, Simo Sorce wrote: > We can't have 2 different keytabs with the same principal name. > If we need privilege separation we'll have to work on integrating > GSS-Proxy and give the keytab only to GSS-Proxy leaving it off the hands > of both the framework, the proxy, and apache itself. I had a different principal like KDCPROXY/fqdn at realm in mind. > Although to be honest I do not see why the proxy need access to the > keytab at all, can we simply run it as a wsgi application under a > different user and prevent it from accessing the apache keytab at all ? Yes, mod_wsgi is able to run a WSGI app as a different user: https://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess A different user needs another location for the ccache and perhaps additional SELinux rules. > What do we need the keytab for ? > Is it just in order to authenticate and read if the service is enabled ? > Can we make that information available anonymously ? Yes, the information is not available for anon bind. It doesn't feel right to disclose the settings to the public. Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From mkosek at redhat.com Thu May 28 15:01:30 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 May 2015 17:01:30 +0200 Subject: [Freeipa-devel] New replica installation and topology - we need stable base In-Reply-To: <1432825059.19096.172.camel@willson.usersys.redhat.com> References: <5565DBB7.1030304@redhat.com> <55671C65.3020406@redhat.com> <1432821607.19096.152.camel@willson.usersys.redhat.com> <55671FDA.8030301@redhat.com> <1432822029.19096.154.camel@willson.usersys.redhat.com> <556722DA.7010703@redhat.com> <1432825059.19096.172.camel@willson.usersys.redhat.com> Message-ID: <55672DCA.5010706@redhat.com> On 05/28/2015 04:57 PM, Simo Sorce wrote: > On Thu, 2015-05-28 at 16:14 +0200, Martin Kosek wrote: >> On 05/28/2015 04:07 PM, Simo Sorce wrote: >>> On Thu, 2015-05-28 at 16:02 +0200, Martin Kosek wrote: >>>> On 05/28/2015 04:00 PM, Simo Sorce wrote: >>>>> On Thu, 2015-05-28 at 15:47 +0200, Martin Kosek wrote: >>>>>> On 05/27/2015 04:59 PM, Martin Kosek wrote: >>>>>> ... >>>>>>> Domain Levels >>>>>>> - Done, committed >>>>>>> - Defaults to Level 1, i.e. Topology plugin powered infra enabled >>>>>> >>>>>> With respect to related Simo's response in >>>>>> http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html >>>>>> >>>>>> Would we want to enable Topology (i.e. Domain Level 1) even if Replica >>>>>> promotion is not done? I thought we do as I see those as orthogonal features. >>>>>> Replica promotion would take advantage of the Topology plugin, but it does not >>>>>> mean you cannot benefit from Topology plugin without it. >>>>>> >>>>>> You can still use the API to see/manage the topology and set replication >>>>>> settings with it. You do not need Replica Promotion for that... >>>>> >>>>> You cannot move for domain level 0 to 1 automatically anyway. So this is >>>>> a moot point to some degree. In general we need to have the code that >>>>> checks for the domain level version to be able to change the level, so >>>>> we need new code in replicas to publish the supported domain level >>>>> version and code in the install patchs to check that we can actually >>>>> join a domain given its current domain level status. >>>>> >>>>> These checks are absolutely a critical blocker to enable the whole >>>>> domain-level feature. >>>> >>>> All the functionality you describe and the checks should be already there. I >>>> was really only asking about the default domain level for *new* installations >>>> >>>> Old/upgraded FreeIPA will be on the Domain Level 0 of course. >>> >>> I think new installation should be on 1 but only if we have decided and >>> finalized what "level 1" is. >>> >>> Simo. >>> >> >> In my mind, Domain Level 1 means: >> >> - Topology plugins is activated for all replicas and manages the agreements >> - All changes to topology can be only made via topology-* commands >> - ipa-replica-manage connect|disconnect are not allowed > > Ok, if we want to restrict it to this then fine. > In my original plan level 1 also meant the KISS/Custodia service is > available on all master. If not then we cannot depend on it and we > cannot fully finish the work on replica promotion w/o requiring the > replica package anymore. The Custodia/Replica promotion will depend on Topology plugin to be there, but I do not think we necessarily need to make it a new Domain Level just for it. During "ipa-replica-install", the installer can simply check if Custodia is accessible on remote server and bail out if it is not accessible and it does not have the replica file. Martin From simo at redhat.com Thu May 28 15:02:21 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 28 May 2015 11:02:21 -0400 Subject: [Freeipa-devel] Domain level for topology plugin = 2 In-Reply-To: <556728C6.8060806@redhat.com> References: <55646331.5050807@redhat.com> <55647F90.506@redhat.com> <5564804B.6080305@redhat.com> <5564841B.4020906@redhat.com> <5566BBFD.9070601@redhat.com> <5566BE3E.2060104@redhat.com> <5566D684.6080505@redhat.com> <5567060D.5010202@redhat.com> <1432819613.19096.138.camel@willson.usersys.redhat.com> <55671AA7.6040002@redhat.com> <1432821163.19096.146.camel@willson.usersys.redhat.com> <556724F8.3090200@redhat.com> <1432823341.19096.160.camel@willson.usersys.redhat.com> <556728C6.8060806@redhat.com> Message-ID: <1432825341.19096.173.camel@willson.usersys.redhat.com> On Thu, 2015-05-28 at 16:40 +0200, Martin Basti wrote: > On 28/05/15 16:29, Simo Sorce wrote: > > On Thu, 2015-05-28 at 16:23 +0200, Oleg Fayans wrote: > >> Hi Simo, > >> > >> On 05/28/2015 03:52 PM, Simo Sorce wrote: > >>> On Thu, 2015-05-28 at 15:39 +0200, Oleg Fayans wrote: > >>>> On 05/28/2015 03:26 PM, Simo Sorce wrote: > >>>>> On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote: > >>>>>> On 28.5.2015 10:49, Martin Kosek wrote: > >>>>>>> On 05/28/2015 09:05 AM, Petr Spacek wrote: > >>>>>>>> On 28.5.2015 08:55, Jan Cholasta wrote: > >>>>>>>>> Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): > >>>>>>>>>> On 26.5.2015 16:16, Martin Kosek wrote: > >>>>>>>>>>> On 05/26/2015 04:13 PM, thierry bordaz wrote: > >>>>>>>>>>>> On 05/26/2015 02:12 PM, Petr Spacek wrote: > >>>>>>>>>>>>> Hello, > >>>>>>>>>>>>> > >>>>>>>>>>>>> it came to my mind that domain level for topology plugin should actually be > >>>>>>>>>>>>> number 2, not 1. > >>>>>>>>>>>>> > >>>>>>>>>>>>> We already used number 1 for incompatible changes in DNS tree and I believe > >>>>>>>>>>>>> that it is not a good idea to have two places which say 'version 1' but and > >>>>>>>>>>>>> actually mean two different things. (DNS tree version 1 + domain level 1) > >>>>>>>>>>>>> > >>>>>>>>>>>>> Patch is attached. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> Hello, > >>>>>>>>>>>> The fix looks good but that seems strange to have to set the initial > >>>>>>>>>>>> version of > >>>>>>>>>>>> the topology plugin to 2.0. (IIUC That is the version that will be written in > >>>>>>>>>>>> dse.ldif) > >>>>>>>>>>>> I would rather expects that topology plugin 1.0, would activate itself if the > >>>>>>>>>>>> DomainLevel is 2.0 or more. > >>>>>>>>>>>> If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate > >>>>>>>>>>>> itself if DomainLevel >= DomainLevel_trigger. > >>>>>>>>>>>> > >>>>>>>>>>>> Let's wait for Ludwig feedback. > >>>>>>>>>>>> > >>>>>>>>>>>> thanks > >>>>>>>>>>>> thierry > >>>>>>>>>>> My personal opinion on this is to start with Domain Level 1 regardless. We > >>>>>>>>>>> already "solved" the DNS forwarders otherwise, with docs, async updates etc. I > >>>>>>>>>>> do not think we will be returning to implementing proper Domain Level support > >>>>>>>>>>> for that anyway. > >>>>>>>>>>> > >>>>>>>>>>> So I rather think that all the "Domain Level starts with 0, 1 is unused, 2 is > >>>>>>>>>>> the top one" will cause unforeseen issues I would rather like to avoid. > >>>>>>>>>> I'm more worried about confusion in future. To to me it simply seems easier to > >>>>>>>>>> bump one integer now than to document and explain (to users & new developers) > >>>>>>>>>> why we have two "ones" which mean something else. > >>>>>>>>>> > >>>>>>>>>> Code-wise it is just an integer. > >>>>>>>>>> > >>>>>>>>>> Also, it can simplify logic in future when we decide to do another > >>>>>>>>>> incompatible change in DNS tree because we will have only one integer to test > >>>>>>>>>> (instead of checking two separate version attribute in DNS tree & domain > >>>>>>>>>> level). > >>>>>>>>> +1, but I think the minimum supported domain level should be 1, not 0, because > >>>>>>>>> 0 means the server uses the old DNS schema, which we do not support anymore, > >>>>>>>>> right? > >>>>>>>> Good point! > >>>>>>>> > >>>>>>> It may be a good point, but it does not make the situation easier. You still > >>>>>>> have RHEL/CentOS 6.x IPA out there, where some of them already support the new > >>>>>>> DNS forwarders and some don't - and neither of them support Domain Levels - > >>>>>>> i.e. have Domain Level 0. > >>>>>>> > >>>>>>> As I said, I still see more complications with this proposals than benefits... > >>>>>> I would argue that it actually helps. > >>>>>> > >>>>>> If domain level = 1 then we can be *sure* that all replicas support the new > >>>>>> DNS semantics. > >>>>>> > >>>>>> If domain level = 0 then we know nothing (because of patched RHEL 6) and it is > >>>>>> a warning sign for diagnostic tools and also us when it comes to debugging. > >>>>> First of all a domain level is something we change *RARELY*, and it is > >>>>> a whole number and it is an all or nothing thing. > >>>>> > >>>>> I do not understand why plugin versions matter at all, plugin version > >>>>> have nothing to do with domain levels. Each plugin *whatever* the > >>>>> version MUST always support at least 2 levels, because every domain you > >>>>> have will have to go through a domain_level transition when a new domain > >>>>> level comes out. > >>>>> > >>>>> Finally no single developer should be allowed to decide on anew domain > >>>>> level, this must be a well ponder team decision as all plugins that need > >>>>> to change behavior based on domain level will be affected so a thorough > >>>>> review of what changes are needed across all plugins must be done every > >>>>> time someone propose a change that requires a domain level bump. > >>>>> > >>>>> Last but not least we should consider domain levels as something that > >>>>> changes *very* slowly, because otherwise you'll have to support many > >>>>> domain levels within any plugins that have to change behavior according > >>>>> to the domain level. > >>>>> I would say that the domain level should not change more frequently than > >>>>> once a year or so. It would be too much code churn to do otherwise. > >>>>> > >>>>> So for now domain_level should be set to 0. And the topology plugin will > >>>>> be enabled only when we turn it to 1. However we shouldn't turn it to 1 > >>>>> until we have the replica promotion code at least, because only then we > >>>>> can make full use of the topology plugins. > >>>> Does that mean, that by default domain level must be set to 0 and only > >>>> raised manually by the identity admin? > >>> Yes, the domain level is established by the first server you install, > >>> and CANNOT be raise automatically by a replica, it must be always > >>> manually raised by the admin. Moreover the code that raises *MUST* check > >>> that all server are capable of handling the new domain level or refuse > >>> to raise the level. > >>> This means all servers must publish the range of domain levels they > >>> support, a missing range means only level 0 is supported. > >> Thank you, this at last clarifies most of the use-cases. > >> The only question that remains: what will happen if an admin (for > >> whatever dumb reason) decides to downgrade the FreeIPA version to 4.1 (that does not support domain > >> levels) on the master of the domain that has domain level = 1? Do replicas preserve the information > >> of the topology? Do they delete this info from DS together with the record about the domain > >> level? Should we support such scenario at all? > > We do not support downgrades, probably everything will explode on the > > server if you even try :-) > > > > We just change so much not only in the directory but also in local > > configuration. I think in recent discussions we also said the updater > > will check what is the current version and just bail out on applying > > anything on "downgrades". So nothing would be changed in the directory > > and Freeipa should just fail to start (or worse). > > > > > Actually, IPA 4-1 has old upgrade script, so it will be possible to run > upgrade and break server. Yep, the upgrade thing is for the future, older servers will just break all. Again downgrades are not supported. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Thu May 28 15:03:43 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 May 2015 17:03:43 +0200 Subject: [Freeipa-devel] Domain level for topology plugin = 2 In-Reply-To: <55672D57.7040308@redhat.com> References: <55646331.5050807@redhat.com> <55647F90.506@redhat.com> <5564804B.6080305@redhat.com> <5564841B.4020906@redhat.com> <5566BBFD.9070601@redhat.com> <5566BE3E.2060104@redhat.com> <5566D684.6080505@redhat.com> <5567060D.5010202@redhat.com> <1432819613.19096.138.camel@willson.usersys.redhat.com> <55671E18.8020807@redhat.com> <1432824379.19096.164.camel@willson.usersys.redhat.com> <55672D57.7040308@redhat.com> Message-ID: <55672E4F.30801@redhat.com> On 05/28/2015 04:59 PM, Ludwig Krispenz wrote: > > On 05/28/2015 04:46 PM, Simo Sorce wrote: >> On Thu, 2015-05-28 at 15:54 +0200, Ludwig Krispenz wrote: >>> On 05/28/2015 03:26 PM, Simo Sorce wrote: >>>> On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote: >>>>> On 28.5.2015 10:49, Martin Kosek wrote: >>>>>> On 05/28/2015 09:05 AM, Petr Spacek wrote: >>>>>>> On 28.5.2015 08:55, Jan Cholasta wrote: >>>>>>>> Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): >>>>>>>>> On 26.5.2015 16:16, Martin Kosek wrote: >>>>>>>>>> On 05/26/2015 04:13 PM, thierry bordaz wrote: >>>>>>>>>>> On 05/26/2015 02:12 PM, Petr Spacek wrote: >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> it came to my mind that domain level for topology plugin should >>>>>>>>>>>> actually be >>>>>>>>>>>> number 2, not 1. >>>>>>>>>>>> >>>>>>>>>>>> We already used number 1 for incompatible changes in DNS tree and I >>>>>>>>>>>> believe >>>>>>>>>>>> that it is not a good idea to have two places which say 'version 1' >>>>>>>>>>>> but and >>>>>>>>>>>> actually mean two different things. (DNS tree version 1 + domain >>>>>>>>>>>> level 1) >>>>>>>>>>>> >>>>>>>>>>>> Patch is attached. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> The fix looks good but that seems strange to have to set the initial >>>>>>>>>>> version of >>>>>>>>>>> the topology plugin to 2.0. (IIUC That is the version that will be >>>>>>>>>>> written in >>>>>>>>>>> dse.ldif) >>>>>>>>>>> I would rather expects that topology plugin 1.0, would activate >>>>>>>>>>> itself if the >>>>>>>>>>> DomainLevel is 2.0 or more. >>>>>>>>>>> If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then >>>>>>>>>>> activate >>>>>>>>>>> itself if DomainLevel >= DomainLevel_trigger. >>>>>>>>>>> >>>>>>>>>>> Let's wait for Ludwig feedback. >>>>>>>>>>> >>>>>>>>>>> thanks >>>>>>>>>>> thierry >>>>>>>>>> My personal opinion on this is to start with Domain Level 1 >>>>>>>>>> regardless. We >>>>>>>>>> already "solved" the DNS forwarders otherwise, with docs, async >>>>>>>>>> updates etc. I >>>>>>>>>> do not think we will be returning to implementing proper Domain Level >>>>>>>>>> support >>>>>>>>>> for that anyway. >>>>>>>>>> >>>>>>>>>> So I rather think that all the "Domain Level starts with 0, 1 is >>>>>>>>>> unused, 2 is >>>>>>>>>> the top one" will cause unforeseen issues I would rather like to avoid. >>>>>>>>> I'm more worried about confusion in future. To to me it simply seems >>>>>>>>> easier to >>>>>>>>> bump one integer now than to document and explain (to users & new >>>>>>>>> developers) >>>>>>>>> why we have two "ones" which mean something else. >>>>>>>>> >>>>>>>>> Code-wise it is just an integer. >>>>>>>>> >>>>>>>>> Also, it can simplify logic in future when we decide to do another >>>>>>>>> incompatible change in DNS tree because we will have only one integer >>>>>>>>> to test >>>>>>>>> (instead of checking two separate version attribute in DNS tree & domain >>>>>>>>> level). >>>>>>>> +1, but I think the minimum supported domain level should be 1, not 0, >>>>>>>> because >>>>>>>> 0 means the server uses the old DNS schema, which we do not support >>>>>>>> anymore, >>>>>>>> right? >>>>>>> Good point! >>>>>>> >>>>>> It may be a good point, but it does not make the situation easier. You still >>>>>> have RHEL/CentOS 6.x IPA out there, where some of them already support >>>>>> the new >>>>>> DNS forwarders and some don't - and neither of them support Domain Levels - >>>>>> i.e. have Domain Level 0. >>>>>> >>>>>> As I said, I still see more complications with this proposals than >>>>>> benefits... >>>>> I would argue that it actually helps. >>>>> >>>>> If domain level = 1 then we can be *sure* that all replicas support the new >>>>> DNS semantics. >>>>> >>>>> If domain level = 0 then we know nothing (because of patched RHEL 6) and >>>>> it is >>>>> a warning sign for diagnostic tools and also us when it comes to debugging. >>>> First of all a domain level is something we change *RARELY*, and it is >>>> a whole number and it is an all or nothing thing. >>>> >>>> I do not understand why plugin versions matter at all, plugin version >>>> have nothing to do with domain levels. Each plugin *whatever* the >>>> version MUST always support at least 2 levels, because every domain you >>>> have will have to go through a domain_level transition when a new domain >>>> level comes out. >>>> >>>> Finally no single developer should be allowed to decide on anew domain >>>> level, this must be a well ponder team decision as all plugins that need >>>> to change behavior based on domain level will be affected so a thorough >>>> review of what changes are needed across all plugins must be done every >>>> time someone propose a change that requires a domain level bump. >>>> >>>> Last but not least we should consider domain levels as something that >>>> changes *very* slowly, because otherwise you'll have to support many >>>> domain levels within any plugins that have to change behavior according >>>> to the domain level. >>>> I would say that the domain level should not change more frequently than >>>> once a year or so. It would be too much code churn to do otherwise. >>>> >>>> So for now domain_level should be set to 0. And the topology plugin will >>>> be enabled only when we turn it to 1. However we shouldn't turn it to 1 >>>> until we have the replica promotion code at least, because only then we >>>> can make full use of the topology plugins. >>>> >>>> The DNS mess is unfixable, unless Petr you volunteer to backport code to >>>> change the behavior of the DNS based on the domain level, if that's the >>>> case then you can tie old behavior to level 0 and new behavior to level >>>>> = 1, but I do not think you want to do that given we already have >>>> "level 0" servers that sport the new code and changed the data in the >>>> directory, so let's just ignore DNS for the purpose of this discussion, >>>> except for nothing that once we finally switch to level 1 then all >>>> servers must be running with the newer DNS schema and older is not >>>> supported. >>>> >>>> Ah, I almost forgot, there is no "domain level for XYZ plugin", the >>>> domain level is one for the whole server, I want to make it very clear, >>>> because the title and part of the discussion seem to imply that you have >>>> per-plugin domain levels. If anything like that actually exist in the >>>> topology plugin code it must be ripped out now, plugin version and >>>> domain level are completely disjointed things and no correlation should >>>> or can exist, the only thing that can exist is whether the server, as a >>>> whole, supports a specific domain level or not. >>>> >>>> So once we decide domain level X comes to existence we basically freeze >>>> what it means and any new development that may require a domain level >>>> bump risk being delayed until we are ready for a new domain level bump, >>>> which should not happen very often. >>>> >>>> So let's make it very clear what level 1 means because the next release >>>> will then support only 0 and 1, and once a new version will come out >>>> with support for "level 2" we want be able to use any of the features >>>> tied to level 2 until all servers in the next release have been >>>> upgraded, and that may be a years long process, so we can't just churn >>>> domain level numbers as we need to support working on older levels for >>>> extended periods. >>> Hi Simo, >>> >>> you say the topology plugin should only activate itself if the domain >>> level is >= 1, at the moment this is done >>> by checking if plugin_version (1.0) >= domain_level (1). >> I do not understand what this means >> >>> If you want a different method/fields for decision, how do you want it >>> handled ? >> I do not see why you need to check for the topology plugin version, what >> you need is a "min_domain_level" version for now and just check: >> if domain_level >= min_domain_level: >> do stuff > but right now installation sets > ipaMinDomainLevel: 0 > ipaMaxDomainLevel: 1 > > in the master entry, so we would always do stuff. Topology should not care about these settings at all, this is only for domainlevel API to validate if the level can be raised or not. Topology plugin should be only checking the effective Domain Level in cn=ipa,cn=etc,SUFFIX. >> >> In the future we may grow more complex requirements and activate 'parts' >> of the plugin based on the domain level, so you could have something >> like: >> >> if domain_level >= min_domain_level: >> do basic stuff >> if domain_level >= feature_X_min_domain_level: >> enable feature X >> >> >> So a general topology plugin version is not really interesting, the code >> above may still be there in version 5.0 of the topology plugin. >> We need a general minimum domain level version and then in future >> per-feature minimum domain level checks. >> >> Simo. >> >> > From simo at redhat.com Thu May 28 15:07:10 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 28 May 2015 11:07:10 -0400 Subject: [Freeipa-devel] Domain level for topology plugin = 2 In-Reply-To: <55672D57.7040308@redhat.com> References: <55646331.5050807@redhat.com> <55647F90.506@redhat.com> <5564804B.6080305@redhat.com> <5564841B.4020906@redhat.com> <5566BBFD.9070601@redhat.com> <5566BE3E.2060104@redhat.com> <5566D684.6080505@redhat.com> <5567060D.5010202@redhat.com> <1432819613.19096.138.camel@willson.usersys.redhat.com> <55671E18.8020807@redhat.com> <1432824379.19096.164.camel@willson.usersys.redhat.com> <55672D57.7040308@redhat.com> Message-ID: <1432825630.19096.177.camel@willson.usersys.redhat.com> On Thu, 2015-05-28 at 16:59 +0200, Ludwig Krispenz wrote: > On 05/28/2015 04:46 PM, Simo Sorce wrote: > > On Thu, 2015-05-28 at 15:54 +0200, Ludwig Krispenz wrote: > >> On 05/28/2015 03:26 PM, Simo Sorce wrote: > >>> On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote: > >>>> On 28.5.2015 10:49, Martin Kosek wrote: > >>>>> On 05/28/2015 09:05 AM, Petr Spacek wrote: > >>>>>> On 28.5.2015 08:55, Jan Cholasta wrote: > >>>>>>> Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): > >>>>>>>> On 26.5.2015 16:16, Martin Kosek wrote: > >>>>>>>>> On 05/26/2015 04:13 PM, thierry bordaz wrote: > >>>>>>>>>> On 05/26/2015 02:12 PM, Petr Spacek wrote: > >>>>>>>>>>> Hello, > >>>>>>>>>>> > >>>>>>>>>>> it came to my mind that domain level for topology plugin should actually be > >>>>>>>>>>> number 2, not 1. > >>>>>>>>>>> > >>>>>>>>>>> We already used number 1 for incompatible changes in DNS tree and I believe > >>>>>>>>>>> that it is not a good idea to have two places which say 'version 1' but and > >>>>>>>>>>> actually mean two different things. (DNS tree version 1 + domain level 1) > >>>>>>>>>>> > >>>>>>>>>>> Patch is attached. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> Hello, > >>>>>>>>>> The fix looks good but that seems strange to have to set the initial > >>>>>>>>>> version of > >>>>>>>>>> the topology plugin to 2.0. (IIUC That is the version that will be written in > >>>>>>>>>> dse.ldif) > >>>>>>>>>> I would rather expects that topology plugin 1.0, would activate itself if the > >>>>>>>>>> DomainLevel is 2.0 or more. > >>>>>>>>>> If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate > >>>>>>>>>> itself if DomainLevel >= DomainLevel_trigger. > >>>>>>>>>> > >>>>>>>>>> Let's wait for Ludwig feedback. > >>>>>>>>>> > >>>>>>>>>> thanks > >>>>>>>>>> thierry > >>>>>>>>> My personal opinion on this is to start with Domain Level 1 regardless. We > >>>>>>>>> already "solved" the DNS forwarders otherwise, with docs, async updates etc. I > >>>>>>>>> do not think we will be returning to implementing proper Domain Level support > >>>>>>>>> for that anyway. > >>>>>>>>> > >>>>>>>>> So I rather think that all the "Domain Level starts with 0, 1 is unused, 2 is > >>>>>>>>> the top one" will cause unforeseen issues I would rather like to avoid. > >>>>>>>> I'm more worried about confusion in future. To to me it simply seems easier to > >>>>>>>> bump one integer now than to document and explain (to users & new developers) > >>>>>>>> why we have two "ones" which mean something else. > >>>>>>>> > >>>>>>>> Code-wise it is just an integer. > >>>>>>>> > >>>>>>>> Also, it can simplify logic in future when we decide to do another > >>>>>>>> incompatible change in DNS tree because we will have only one integer to test > >>>>>>>> (instead of checking two separate version attribute in DNS tree & domain > >>>>>>>> level). > >>>>>>> +1, but I think the minimum supported domain level should be 1, not 0, because > >>>>>>> 0 means the server uses the old DNS schema, which we do not support anymore, > >>>>>>> right? > >>>>>> Good point! > >>>>>> > >>>>> It may be a good point, but it does not make the situation easier. You still > >>>>> have RHEL/CentOS 6.x IPA out there, where some of them already support the new > >>>>> DNS forwarders and some don't - and neither of them support Domain Levels - > >>>>> i.e. have Domain Level 0. > >>>>> > >>>>> As I said, I still see more complications with this proposals than benefits... > >>>> I would argue that it actually helps. > >>>> > >>>> If domain level = 1 then we can be *sure* that all replicas support the new > >>>> DNS semantics. > >>>> > >>>> If domain level = 0 then we know nothing (because of patched RHEL 6) and it is > >>>> a warning sign for diagnostic tools and also us when it comes to debugging. > >>> First of all a domain level is something we change *RARELY*, and it is > >>> a whole number and it is an all or nothing thing. > >>> > >>> I do not understand why plugin versions matter at all, plugin version > >>> have nothing to do with domain levels. Each plugin *whatever* the > >>> version MUST always support at least 2 levels, because every domain you > >>> have will have to go through a domain_level transition when a new domain > >>> level comes out. > >>> > >>> Finally no single developer should be allowed to decide on anew domain > >>> level, this must be a well ponder team decision as all plugins that need > >>> to change behavior based on domain level will be affected so a thorough > >>> review of what changes are needed across all plugins must be done every > >>> time someone propose a change that requires a domain level bump. > >>> > >>> Last but not least we should consider domain levels as something that > >>> changes *very* slowly, because otherwise you'll have to support many > >>> domain levels within any plugins that have to change behavior according > >>> to the domain level. > >>> I would say that the domain level should not change more frequently than > >>> once a year or so. It would be too much code churn to do otherwise. > >>> > >>> So for now domain_level should be set to 0. And the topology plugin will > >>> be enabled only when we turn it to 1. However we shouldn't turn it to 1 > >>> until we have the replica promotion code at least, because only then we > >>> can make full use of the topology plugins. > >>> > >>> The DNS mess is unfixable, unless Petr you volunteer to backport code to > >>> change the behavior of the DNS based on the domain level, if that's the > >>> case then you can tie old behavior to level 0 and new behavior to level > >>>> = 1, but I do not think you want to do that given we already have > >>> "level 0" servers that sport the new code and changed the data in the > >>> directory, so let's just ignore DNS for the purpose of this discussion, > >>> except for nothing that once we finally switch to level 1 then all > >>> servers must be running with the newer DNS schema and older is not > >>> supported. > >>> > >>> Ah, I almost forgot, there is no "domain level for XYZ plugin", the > >>> domain level is one for the whole server, I want to make it very clear, > >>> because the title and part of the discussion seem to imply that you have > >>> per-plugin domain levels. If anything like that actually exist in the > >>> topology plugin code it must be ripped out now, plugin version and > >>> domain level are completely disjointed things and no correlation should > >>> or can exist, the only thing that can exist is whether the server, as a > >>> whole, supports a specific domain level or not. > >>> > >>> So once we decide domain level X comes to existence we basically freeze > >>> what it means and any new development that may require a domain level > >>> bump risk being delayed until we are ready for a new domain level bump, > >>> which should not happen very often. > >>> > >>> So let's make it very clear what level 1 means because the next release > >>> will then support only 0 and 1, and once a new version will come out > >>> with support for "level 2" we want be able to use any of the features > >>> tied to level 2 until all servers in the next release have been > >>> upgraded, and that may be a years long process, so we can't just churn > >>> domain level numbers as we need to support working on older levels for > >>> extended periods. > >> Hi Simo, > >> > >> you say the topology plugin should only activate itself if the domain > >> level is >= 1, at the moment this is done > >> by checking if plugin_version (1.0) >= domain_level (1). > > I do not understand what this means > > > >> If you want a different method/fields for decision, how do you want it > >> handled ? > > I do not see why you need to check for the topology plugin version, what > > you need is a "min_domain_level" version for now and just check: > > if domain_level >= min_domain_level: > > do stuff > but right now installation sets > ipaMinDomainLevel: 0 > ipaMaxDomainLevel: 1 > > in the master entry, so we would always do stuff. I think there is some confusion here. The values above are the min/max of what the *server* supports as a whole. You do not look at those values in the topology plugin. In the plugin you have internal values, in the code, that tells you what the plugin supports. Of course the global server values must reflect what all the plugins actually support, but that's something we need to coordinate among developers for now, not an automatic mechanism. However it would be cool to have some conventions about how we express supported versions in the code so we can build a script that parses the tree and check all components match what we declare as supported in the global values. Simo. -- Simo Sorce * Red Hat, Inc * New York From cheimes at redhat.com Thu May 28 15:07:56 2015 From: cheimes at redhat.com (Christian Heimes) Date: Thu, 28 May 2015 17:07:56 +0200 Subject: [Freeipa-devel] KDC proxy implementation specs In-Reply-To: <1432824525.2618.7.camel@redhat.com> References: <55672790.6060206@redhat.com> <1432824525.2618.7.camel@redhat.com> Message-ID: <55672F4C.702@redhat.com> On 2015-05-28 16:48, Nathaniel McCallum wrote: > An apache module would also provide similar benefits. I'm not sure I > necessarily want to stick with python here if we're optimizing for > performance. Another option would be to add it to the KDC itself and > proxy through Apache like we do for Tomcat. MIT might like that option. For that kind of network code Python is really fast enough. An event driven framework like asyncio or Twisted can handle lots of connections simultaneous. We aren't speaking about several GBit/sec where zero-copy is required. I'm more worried about Apache than Python. Apache is tuned for the needs of the webui, e.g. prefork MPM. Let's see how it works out in a production system. Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From npmccallum at redhat.com Thu May 28 15:09:31 2015 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 28 May 2015 11:09:31 -0400 Subject: [Freeipa-devel] KDC proxy implementation specs In-Reply-To: <55672F4C.702@redhat.com> References: <55672790.6060206@redhat.com> <1432824525.2618.7.camel@redhat.com> <55672F4C.702@redhat.com> Message-ID: <1432825771.2618.12.camel@redhat.com> On Thu, 2015-05-28 at 17:07 +0200, Christian Heimes wrote: > On 2015-05-28 16:48, Nathaniel McCallum wrote: > > An apache module would also provide similar benefits. I'm not sure > > I > > necessarily want to stick with python here if we're optimizing for > > performance. Another option would be to add it to the KDC itself > > and > > proxy through Apache like we do for Tomcat. MIT might like that > > option. > > For that kind of network code Python is really fast enough. An event > driven framework like asyncio or Twisted can handle lots of > connections > simultaneous. We aren't speaking about several GBit/sec where zero > -copy > is required. > > I'm more worried about Apache than Python. Apache is tuned for the > needs > of the webui, e.g. prefork MPM. Let's see how it works out in a > production system. Right. And the KDC could just parse the messages directly. I agree. Let's wait and see. Nathaniel From simo at redhat.com Thu May 28 15:10:44 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 28 May 2015 11:10:44 -0400 Subject: [Freeipa-devel] KDC proxy implementation specs In-Reply-To: <55672D85.1060501@redhat.com> References: <55672790.6060206@redhat.com> <1432824525.2618.7.camel@redhat.com> <1432824839.19096.170.camel@willson.usersys.redhat.com> <55672D85.1060501@redhat.com> Message-ID: <1432825844.19096.180.camel@willson.usersys.redhat.com> On Thu, 2015-05-28 at 17:00 +0200, Christian Heimes wrote: > On 2015-05-28 16:53, Simo Sorce wrote: > > We can't have 2 different keytabs with the same principal name. > > If we need privilege separation we'll have to work on integrating > > GSS-Proxy and give the keytab only to GSS-Proxy leaving it off the hands > > of both the framework, the proxy, and apache itself. > > I had a different principal like KDCPROXY/fqdn at realm in mind. > > > Although to be honest I do not see why the proxy need access to the > > keytab at all, can we simply run it as a wsgi application under a > > different user and prevent it from accessing the apache keytab at all ? > > Yes, mod_wsgi is able to run a WSGI app as a different user: > > https://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess > > A different user needs another location for the ccache and perhaps > additional SELinux rules. If you are using the keytab only to acquire credentials to access ldap you could use a memory ccache and not have to deal with locations: KRB5CCNAME=MEMORY:kdcproxy_ > > What do we need the keytab for ? > > Is it just in order to authenticate and read if the service is enabled ? > > Can we make that information available anonymously ? > > Yes, the information is not available for anon bind. It doesn't feel > right to disclose the settings to the public. Another option is to use ldapi and external auth, I forgot if we allow automatic binding for no-root users though. Rob, do you remember ? Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu May 28 15:13:02 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 28 May 2015 11:13:02 -0400 Subject: [Freeipa-devel] KDC proxy implementation specs In-Reply-To: <1432825844.19096.180.camel@willson.usersys.redhat.com> References: <55672790.6060206@redhat.com> <1432824525.2618.7.camel@redhat.com> <1432824839.19096.170.camel@willson.usersys.redhat.com> <55672D85.1060501@redhat.com> <1432825844.19096.180.camel@willson.usersys.redhat.com> Message-ID: <5567307E.4080005@redhat.com> Simo Sorce wrote: > On Thu, 2015-05-28 at 17:00 +0200, Christian Heimes wrote: >> On 2015-05-28 16:53, Simo Sorce wrote: >>> We can't have 2 different keytabs with the same principal name. >>> If we need privilege separation we'll have to work on integrating >>> GSS-Proxy and give the keytab only to GSS-Proxy leaving it off the hands >>> of both the framework, the proxy, and apache itself. >> >> I had a different principal like KDCPROXY/fqdn at realm in mind. >> >>> Although to be honest I do not see why the proxy need access to the >>> keytab at all, can we simply run it as a wsgi application under a >>> different user and prevent it from accessing the apache keytab at all ? >> >> Yes, mod_wsgi is able to run a WSGI app as a different user: >> >> https://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess >> >> A different user needs another location for the ccache and perhaps >> additional SELinux rules. > > If you are using the keytab only to acquire credentials to access ldap > you could use a memory ccache and not have to deal with locations: > KRB5CCNAME=MEMORY:kdcproxy_ > >>> What do we need the keytab for ? >>> Is it just in order to authenticate and read if the service is enabled ? >>> Can we make that information available anonymously ? >> >> Yes, the information is not available for anon bind. It doesn't feel >> right to disclose the settings to the public. > > Another option is to use ldapi and external auth, I forgot if we allow > automatic binding for no-root users though. > > Rob, > do you remember ? AFAIK we have no rules other than root -> DM. rob From cheimes at redhat.com Thu May 28 15:13:52 2015 From: cheimes at redhat.com (Christian Heimes) Date: Thu, 28 May 2015 17:13:52 +0200 Subject: [Freeipa-devel] KDC proxy implementation specs In-Reply-To: <1432825844.19096.180.camel@willson.usersys.redhat.com> References: <55672790.6060206@redhat.com> <1432824525.2618.7.camel@redhat.com> <1432824839.19096.170.camel@willson.usersys.redhat.com> <55672D85.1060501@redhat.com> <1432825844.19096.180.camel@willson.usersys.redhat.com> Message-ID: <556730B0.3000402@redhat.com> On 2015-05-28 17:10, Simo Sorce wrote: > On Thu, 2015-05-28 at 17:00 +0200, Christian Heimes wrote: >> On 2015-05-28 16:53, Simo Sorce wrote: >>> We can't have 2 different keytabs with the same principal name. >>> If we need privilege separation we'll have to work on integrating >>> GSS-Proxy and give the keytab only to GSS-Proxy leaving it off the hands >>> of both the framework, the proxy, and apache itself. >> >> I had a different principal like KDCPROXY/fqdn at realm in mind. >> >>> Although to be honest I do not see why the proxy need access to the >>> keytab at all, can we simply run it as a wsgi application under a >>> different user and prevent it from accessing the apache keytab at all ? >> >> Yes, mod_wsgi is able to run a WSGI app as a different user: >> >> https://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess >> >> A different user needs another location for the ccache and perhaps >> additional SELinux rules. > > If you are using the keytab only to acquire credentials to access ldap > you could use a memory ccache and not have to deal with locations: > KRB5CCNAME=MEMORY:kdcproxy_ Oh nice, I wasn't aware about the MEMORY scheme. Is that supported on older versions of RHEL, too? >>> What do we need the keytab for ? >>> Is it just in order to authenticate and read if the service is enabled ? >>> Can we make that information available anonymously ? >> >> Yes, the information is not available for anon bind. It doesn't feel >> right to disclose the settings to the public. > > Another option is to use ldapi and external auth, I forgot if we allow > automatic binding for no-root users though. No, been there, tried it, failed. It works as root but not as Apache user or my test user. Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From lkrispen at redhat.com Thu May 28 15:18:45 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 28 May 2015 17:18:45 +0200 Subject: [Freeipa-devel] Domain level for topology plugin = 2 In-Reply-To: <55672E4F.30801@redhat.com> References: <55646331.5050807@redhat.com> <55647F90.506@redhat.com> <5564804B.6080305@redhat.com> <5564841B.4020906@redhat.com> <5566BBFD.9070601@redhat.com> <5566BE3E.2060104@redhat.com> <5566D684.6080505@redhat.com> <5567060D.5010202@redhat.com> <1432819613.19096.138.camel@willson.usersys.redhat.com> <55671E18.8020807@redhat.com> <1432824379.19096.164.camel@willson.usersys.redhat.com> <55672D57.7040308@redhat.com> <55672E4F.30801@redhat.com> Message-ID: <556731D5.4070507@redhat.com> On 05/28/2015 05:03 PM, Martin Kosek wrote: > On 05/28/2015 04:59 PM, Ludwig Krispenz wrote: >> On 05/28/2015 04:46 PM, Simo Sorce wrote: >>> On Thu, 2015-05-28 at 15:54 +0200, Ludwig Krispenz wrote: >>>> On 05/28/2015 03:26 PM, Simo Sorce wrote: >>>>> On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote: >>>>>> On 28.5.2015 10:49, Martin Kosek wrote: >>>>>>> On 05/28/2015 09:05 AM, Petr Spacek wrote: >>>>>>>> On 28.5.2015 08:55, Jan Cholasta wrote: >>>>>>>>> Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): >>>>>>>>>> On 26.5.2015 16:16, Martin Kosek wrote: >>>>>>>>>>> On 05/26/2015 04:13 PM, thierry bordaz wrote: >>>>>>>>>>>> On 05/26/2015 02:12 PM, Petr Spacek wrote: >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> >>>>>>>>>>>>> it came to my mind that domain level for topology plugin should >>>>>>>>>>>>> actually be >>>>>>>>>>>>> number 2, not 1. >>>>>>>>>>>>> >>>>>>>>>>>>> We already used number 1 for incompatible changes in DNS tree and I >>>>>>>>>>>>> believe >>>>>>>>>>>>> that it is not a good idea to have two places which say 'version 1' >>>>>>>>>>>>> but and >>>>>>>>>>>>> actually mean two different things. (DNS tree version 1 + domain >>>>>>>>>>>>> level 1) >>>>>>>>>>>>> >>>>>>>>>>>>> Patch is attached. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Hello, >>>>>>>>>>>> The fix looks good but that seems strange to have to set the initial >>>>>>>>>>>> version of >>>>>>>>>>>> the topology plugin to 2.0. (IIUC That is the version that will be >>>>>>>>>>>> written in >>>>>>>>>>>> dse.ldif) >>>>>>>>>>>> I would rather expects that topology plugin 1.0, would activate >>>>>>>>>>>> itself if the >>>>>>>>>>>> DomainLevel is 2.0 or more. >>>>>>>>>>>> If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then >>>>>>>>>>>> activate >>>>>>>>>>>> itself if DomainLevel >= DomainLevel_trigger. >>>>>>>>>>>> >>>>>>>>>>>> Let's wait for Ludwig feedback. >>>>>>>>>>>> >>>>>>>>>>>> thanks >>>>>>>>>>>> thierry >>>>>>>>>>> My personal opinion on this is to start with Domain Level 1 >>>>>>>>>>> regardless. We >>>>>>>>>>> already "solved" the DNS forwarders otherwise, with docs, async >>>>>>>>>>> updates etc. I >>>>>>>>>>> do not think we will be returning to implementing proper Domain Level >>>>>>>>>>> support >>>>>>>>>>> for that anyway. >>>>>>>>>>> >>>>>>>>>>> So I rather think that all the "Domain Level starts with 0, 1 is >>>>>>>>>>> unused, 2 is >>>>>>>>>>> the top one" will cause unforeseen issues I would rather like to avoid. >>>>>>>>>> I'm more worried about confusion in future. To to me it simply seems >>>>>>>>>> easier to >>>>>>>>>> bump one integer now than to document and explain (to users & new >>>>>>>>>> developers) >>>>>>>>>> why we have two "ones" which mean something else. >>>>>>>>>> >>>>>>>>>> Code-wise it is just an integer. >>>>>>>>>> >>>>>>>>>> Also, it can simplify logic in future when we decide to do another >>>>>>>>>> incompatible change in DNS tree because we will have only one integer >>>>>>>>>> to test >>>>>>>>>> (instead of checking two separate version attribute in DNS tree & domain >>>>>>>>>> level). >>>>>>>>> +1, but I think the minimum supported domain level should be 1, not 0, >>>>>>>>> because >>>>>>>>> 0 means the server uses the old DNS schema, which we do not support >>>>>>>>> anymore, >>>>>>>>> right? >>>>>>>> Good point! >>>>>>>> >>>>>>> It may be a good point, but it does not make the situation easier. You still >>>>>>> have RHEL/CentOS 6.x IPA out there, where some of them already support >>>>>>> the new >>>>>>> DNS forwarders and some don't - and neither of them support Domain Levels - >>>>>>> i.e. have Domain Level 0. >>>>>>> >>>>>>> As I said, I still see more complications with this proposals than >>>>>>> benefits... >>>>>> I would argue that it actually helps. >>>>>> >>>>>> If domain level = 1 then we can be *sure* that all replicas support the new >>>>>> DNS semantics. >>>>>> >>>>>> If domain level = 0 then we know nothing (because of patched RHEL 6) and >>>>>> it is >>>>>> a warning sign for diagnostic tools and also us when it comes to debugging. >>>>> First of all a domain level is something we change *RARELY*, and it is >>>>> a whole number and it is an all or nothing thing. >>>>> >>>>> I do not understand why plugin versions matter at all, plugin version >>>>> have nothing to do with domain levels. Each plugin *whatever* the >>>>> version MUST always support at least 2 levels, because every domain you >>>>> have will have to go through a domain_level transition when a new domain >>>>> level comes out. >>>>> >>>>> Finally no single developer should be allowed to decide on anew domain >>>>> level, this must be a well ponder team decision as all plugins that need >>>>> to change behavior based on domain level will be affected so a thorough >>>>> review of what changes are needed across all plugins must be done every >>>>> time someone propose a change that requires a domain level bump. >>>>> >>>>> Last but not least we should consider domain levels as something that >>>>> changes *very* slowly, because otherwise you'll have to support many >>>>> domain levels within any plugins that have to change behavior according >>>>> to the domain level. >>>>> I would say that the domain level should not change more frequently than >>>>> once a year or so. It would be too much code churn to do otherwise. >>>>> >>>>> So for now domain_level should be set to 0. And the topology plugin will >>>>> be enabled only when we turn it to 1. However we shouldn't turn it to 1 >>>>> until we have the replica promotion code at least, because only then we >>>>> can make full use of the topology plugins. >>>>> >>>>> The DNS mess is unfixable, unless Petr you volunteer to backport code to >>>>> change the behavior of the DNS based on the domain level, if that's the >>>>> case then you can tie old behavior to level 0 and new behavior to level >>>>>> = 1, but I do not think you want to do that given we already have >>>>> "level 0" servers that sport the new code and changed the data in the >>>>> directory, so let's just ignore DNS for the purpose of this discussion, >>>>> except for nothing that once we finally switch to level 1 then all >>>>> servers must be running with the newer DNS schema and older is not >>>>> supported. >>>>> >>>>> Ah, I almost forgot, there is no "domain level for XYZ plugin", the >>>>> domain level is one for the whole server, I want to make it very clear, >>>>> because the title and part of the discussion seem to imply that you have >>>>> per-plugin domain levels. If anything like that actually exist in the >>>>> topology plugin code it must be ripped out now, plugin version and >>>>> domain level are completely disjointed things and no correlation should >>>>> or can exist, the only thing that can exist is whether the server, as a >>>>> whole, supports a specific domain level or not. >>>>> >>>>> So once we decide domain level X comes to existence we basically freeze >>>>> what it means and any new development that may require a domain level >>>>> bump risk being delayed until we are ready for a new domain level bump, >>>>> which should not happen very often. >>>>> >>>>> So let's make it very clear what level 1 means because the next release >>>>> will then support only 0 and 1, and once a new version will come out >>>>> with support for "level 2" we want be able to use any of the features >>>>> tied to level 2 until all servers in the next release have been >>>>> upgraded, and that may be a years long process, so we can't just churn >>>>> domain level numbers as we need to support working on older levels for >>>>> extended periods. >>>> Hi Simo, >>>> >>>> you say the topology plugin should only activate itself if the domain >>>> level is >= 1, at the moment this is done >>>> by checking if plugin_version (1.0) >= domain_level (1). >>> I do not understand what this means >>> >>>> If you want a different method/fields for decision, how do you want it >>>> handled ? >>> I do not see why you need to check for the topology plugin version, what >>> you need is a "min_domain_level" version for now and just check: >>> if domain_level >= min_domain_level: >>> do stuff >> but right now installation sets >> ipaMinDomainLevel: 0 >> ipaMaxDomainLevel: 1 >> >> in the master entry, so we would always do stuff. > Topology should not care about these settings at all, this is only for > domainlevel API to validate if the level can be raised or not. Topology plugin > should be only checking the effective Domain Level in cn=ipa,cn=etc,SUFFIX. and then ? it reads domain level to be say 1, what is the trigger. now I am confused, Simo say it should not compare it to the plugin version, you say it should not compare to the server level, so what ? hard code on domain level 1? > >>> In the future we may grow more complex requirements and activate 'parts' >>> of the plugin based on the domain level, so you could have something >>> like: >>> >>> if domain_level >= min_domain_level: >>> do basic stuff >>> if domain_level >= feature_X_min_domain_level: >>> enable feature X >>> >>> >>> So a general topology plugin version is not really interesting, the code >>> above may still be there in version 5.0 of the topology plugin. >>> We need a general minimum domain level version and then in future >>> per-feature minimum domain level checks. >>> >>> Simo. >>> >>> From simo at redhat.com Thu May 28 15:30:33 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 28 May 2015 11:30:33 -0400 Subject: [Freeipa-devel] KDC proxy implementation specs In-Reply-To: <556730B0.3000402@redhat.com> References: <55672790.6060206@redhat.com> <1432824525.2618.7.camel@redhat.com> <1432824839.19096.170.camel@willson.usersys.redhat.com> <55672D85.1060501@redhat.com> <1432825844.19096.180.camel@willson.usersys.redhat.com> <556730B0.3000402@redhat.com> Message-ID: <1432827033.19096.196.camel@willson.usersys.redhat.com> On Thu, 2015-05-28 at 17:13 +0200, Christian Heimes wrote: > On 2015-05-28 17:10, Simo Sorce wrote: > > On Thu, 2015-05-28 at 17:00 +0200, Christian Heimes wrote: > >> On 2015-05-28 16:53, Simo Sorce wrote: > >>> We can't have 2 different keytabs with the same principal name. > >>> If we need privilege separation we'll have to work on integrating > >>> GSS-Proxy and give the keytab only to GSS-Proxy leaving it off the hands > >>> of both the framework, the proxy, and apache itself. > >> > >> I had a different principal like KDCPROXY/fqdn at realm in mind. > >> > >>> Although to be honest I do not see why the proxy need access to the > >>> keytab at all, can we simply run it as a wsgi application under a > >>> different user and prevent it from accessing the apache keytab at all ? > >> > >> Yes, mod_wsgi is able to run a WSGI app as a different user: > >> > >> https://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess > >> > >> A different user needs another location for the ccache and perhaps > >> additional SELinux rules. > > > > If you are using the keytab only to acquire credentials to access ldap > > you could use a memory ccache and not have to deal with locations: > > KRB5CCNAME=MEMORY:kdcproxy_ > > Oh nice, I wasn't aware about the MEMORY scheme. Is that supported on > older versions of RHEL, too? Yes, it has been there for a long while. > >>> What do we need the keytab for ? > >>> Is it just in order to authenticate and read if the service is enabled ? > >>> Can we make that information available anonymously ? > >> > >> Yes, the information is not available for anon bind. It doesn't feel > >> right to disclose the settings to the public. > > > > Another option is to use ldapi and external auth, I forgot if we allow > > automatic binding for no-root users though. > > No, been there, tried it, failed. It works as root but not as Apache > user or my test user. Maybe we can enable it in cn=config, need to check what's needed, but it may be worth, if all you need is to read a few entries. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Thu May 28 15:35:13 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 28 May 2015 11:35:13 -0400 Subject: [Freeipa-devel] Domain level for topology plugin = 2 In-Reply-To: <556731D5.4070507@redhat.com> References: <55646331.5050807@redhat.com> <55647F90.506@redhat.com> <5564804B.6080305@redhat.com> <5564841B.4020906@redhat.com> <5566BBFD.9070601@redhat.com> <5566BE3E.2060104@redhat.com> <5566D684.6080505@redhat.com> <5567060D.5010202@redhat.com> <1432819613.19096.138.camel@willson.usersys.redhat.com> <55671E18.8020807@redhat.com> <1432824379.19096.164.camel@willson.usersys.redhat.com> <55672D57.7040308@redhat.com> <55672E4F.30801@redhat.com> <556731D5.4070507@redhat.com> Message-ID: <1432827313.19096.201.camel@willson.usersys.redhat.com> On Thu, 2015-05-28 at 17:18 +0200, Ludwig Krispenz wrote: > On 05/28/2015 05:03 PM, Martin Kosek wrote: > > On 05/28/2015 04:59 PM, Ludwig Krispenz wrote: > >> On 05/28/2015 04:46 PM, Simo Sorce wrote: > >>> On Thu, 2015-05-28 at 15:54 +0200, Ludwig Krispenz wrote: > >>>> On 05/28/2015 03:26 PM, Simo Sorce wrote: > >>>>> On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote: > >>>>>> On 28.5.2015 10:49, Martin Kosek wrote: > >>>>>>> On 05/28/2015 09:05 AM, Petr Spacek wrote: > >>>>>>>> On 28.5.2015 08:55, Jan Cholasta wrote: > >>>>>>>>> Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): > >>>>>>>>>> On 26.5.2015 16:16, Martin Kosek wrote: > >>>>>>>>>>> On 05/26/2015 04:13 PM, thierry bordaz wrote: > >>>>>>>>>>>> On 05/26/2015 02:12 PM, Petr Spacek wrote: > >>>>>>>>>>>>> Hello, > >>>>>>>>>>>>> > >>>>>>>>>>>>> it came to my mind that domain level for topology plugin should > >>>>>>>>>>>>> actually be > >>>>>>>>>>>>> number 2, not 1. > >>>>>>>>>>>>> > >>>>>>>>>>>>> We already used number 1 for incompatible changes in DNS tree and I > >>>>>>>>>>>>> believe > >>>>>>>>>>>>> that it is not a good idea to have two places which say 'version 1' > >>>>>>>>>>>>> but and > >>>>>>>>>>>>> actually mean two different things. (DNS tree version 1 + domain > >>>>>>>>>>>>> level 1) > >>>>>>>>>>>>> > >>>>>>>>>>>>> Patch is attached. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> Hello, > >>>>>>>>>>>> The fix looks good but that seems strange to have to set the initial > >>>>>>>>>>>> version of > >>>>>>>>>>>> the topology plugin to 2.0. (IIUC That is the version that will be > >>>>>>>>>>>> written in > >>>>>>>>>>>> dse.ldif) > >>>>>>>>>>>> I would rather expects that topology plugin 1.0, would activate > >>>>>>>>>>>> itself if the > >>>>>>>>>>>> DomainLevel is 2.0 or more. > >>>>>>>>>>>> If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then > >>>>>>>>>>>> activate > >>>>>>>>>>>> itself if DomainLevel >= DomainLevel_trigger. > >>>>>>>>>>>> > >>>>>>>>>>>> Let's wait for Ludwig feedback. > >>>>>>>>>>>> > >>>>>>>>>>>> thanks > >>>>>>>>>>>> thierry > >>>>>>>>>>> My personal opinion on this is to start with Domain Level 1 > >>>>>>>>>>> regardless. We > >>>>>>>>>>> already "solved" the DNS forwarders otherwise, with docs, async > >>>>>>>>>>> updates etc. I > >>>>>>>>>>> do not think we will be returning to implementing proper Domain Level > >>>>>>>>>>> support > >>>>>>>>>>> for that anyway. > >>>>>>>>>>> > >>>>>>>>>>> So I rather think that all the "Domain Level starts with 0, 1 is > >>>>>>>>>>> unused, 2 is > >>>>>>>>>>> the top one" will cause unforeseen issues I would rather like to avoid. > >>>>>>>>>> I'm more worried about confusion in future. To to me it simply seems > >>>>>>>>>> easier to > >>>>>>>>>> bump one integer now than to document and explain (to users & new > >>>>>>>>>> developers) > >>>>>>>>>> why we have two "ones" which mean something else. > >>>>>>>>>> > >>>>>>>>>> Code-wise it is just an integer. > >>>>>>>>>> > >>>>>>>>>> Also, it can simplify logic in future when we decide to do another > >>>>>>>>>> incompatible change in DNS tree because we will have only one integer > >>>>>>>>>> to test > >>>>>>>>>> (instead of checking two separate version attribute in DNS tree & domain > >>>>>>>>>> level). > >>>>>>>>> +1, but I think the minimum supported domain level should be 1, not 0, > >>>>>>>>> because > >>>>>>>>> 0 means the server uses the old DNS schema, which we do not support > >>>>>>>>> anymore, > >>>>>>>>> right? > >>>>>>>> Good point! > >>>>>>>> > >>>>>>> It may be a good point, but it does not make the situation easier. You still > >>>>>>> have RHEL/CentOS 6.x IPA out there, where some of them already support > >>>>>>> the new > >>>>>>> DNS forwarders and some don't - and neither of them support Domain Levels - > >>>>>>> i.e. have Domain Level 0. > >>>>>>> > >>>>>>> As I said, I still see more complications with this proposals than > >>>>>>> benefits... > >>>>>> I would argue that it actually helps. > >>>>>> > >>>>>> If domain level = 1 then we can be *sure* that all replicas support the new > >>>>>> DNS semantics. > >>>>>> > >>>>>> If domain level = 0 then we know nothing (because of patched RHEL 6) and > >>>>>> it is > >>>>>> a warning sign for diagnostic tools and also us when it comes to debugging. > >>>>> First of all a domain level is something we change *RARELY*, and it is > >>>>> a whole number and it is an all or nothing thing. > >>>>> > >>>>> I do not understand why plugin versions matter at all, plugin version > >>>>> have nothing to do with domain levels. Each plugin *whatever* the > >>>>> version MUST always support at least 2 levels, because every domain you > >>>>> have will have to go through a domain_level transition when a new domain > >>>>> level comes out. > >>>>> > >>>>> Finally no single developer should be allowed to decide on anew domain > >>>>> level, this must be a well ponder team decision as all plugins that need > >>>>> to change behavior based on domain level will be affected so a thorough > >>>>> review of what changes are needed across all plugins must be done every > >>>>> time someone propose a change that requires a domain level bump. > >>>>> > >>>>> Last but not least we should consider domain levels as something that > >>>>> changes *very* slowly, because otherwise you'll have to support many > >>>>> domain levels within any plugins that have to change behavior according > >>>>> to the domain level. > >>>>> I would say that the domain level should not change more frequently than > >>>>> once a year or so. It would be too much code churn to do otherwise. > >>>>> > >>>>> So for now domain_level should be set to 0. And the topology plugin will > >>>>> be enabled only when we turn it to 1. However we shouldn't turn it to 1 > >>>>> until we have the replica promotion code at least, because only then we > >>>>> can make full use of the topology plugins. > >>>>> > >>>>> The DNS mess is unfixable, unless Petr you volunteer to backport code to > >>>>> change the behavior of the DNS based on the domain level, if that's the > >>>>> case then you can tie old behavior to level 0 and new behavior to level > >>>>>> = 1, but I do not think you want to do that given we already have > >>>>> "level 0" servers that sport the new code and changed the data in the > >>>>> directory, so let's just ignore DNS for the purpose of this discussion, > >>>>> except for nothing that once we finally switch to level 1 then all > >>>>> servers must be running with the newer DNS schema and older is not > >>>>> supported. > >>>>> > >>>>> Ah, I almost forgot, there is no "domain level for XYZ plugin", the > >>>>> domain level is one for the whole server, I want to make it very clear, > >>>>> because the title and part of the discussion seem to imply that you have > >>>>> per-plugin domain levels. If anything like that actually exist in the > >>>>> topology plugin code it must be ripped out now, plugin version and > >>>>> domain level are completely disjointed things and no correlation should > >>>>> or can exist, the only thing that can exist is whether the server, as a > >>>>> whole, supports a specific domain level or not. > >>>>> > >>>>> So once we decide domain level X comes to existence we basically freeze > >>>>> what it means and any new development that may require a domain level > >>>>> bump risk being delayed until we are ready for a new domain level bump, > >>>>> which should not happen very often. > >>>>> > >>>>> So let's make it very clear what level 1 means because the next release > >>>>> will then support only 0 and 1, and once a new version will come out > >>>>> with support for "level 2" we want be able to use any of the features > >>>>> tied to level 2 until all servers in the next release have been > >>>>> upgraded, and that may be a years long process, so we can't just churn > >>>>> domain level numbers as we need to support working on older levels for > >>>>> extended periods. > >>>> Hi Simo, > >>>> > >>>> you say the topology plugin should only activate itself if the domain > >>>> level is >= 1, at the moment this is done > >>>> by checking if plugin_version (1.0) >= domain_level (1). > >>> I do not understand what this means > >>> > >>>> If you want a different method/fields for decision, how do you want it > >>>> handled ? > >>> I do not see why you need to check for the topology plugin version, what > >>> you need is a "min_domain_level" version for now and just check: > >>> if domain_level >= min_domain_level: > >>> do stuff > >> but right now installation sets > >> ipaMinDomainLevel: 0 > >> ipaMaxDomainLevel: 1 > >> > >> in the master entry, so we would always do stuff. > > Topology should not care about these settings at all, this is only for > > domainlevel API to validate if the level can be raised or not. Topology plugin > > should be only checking the effective Domain Level in cn=ipa,cn=etc,SUFFIX. > and then ? it reads domain level to be say 1, what is the trigger. > now I am confused, Simo say it should not compare it to the plugin > version, you say it should not compare to the server level, > > so what ? hard code on domain level 1? In the plugin you should have this variable as a global (for the plugin) int topology_min_domain_level = 1 You *know* the plugin can activate only if domain_level is 1, it is ok to hard code it, once we release the code we will never change this. The plugin will be forever and ever enabled only if the global domain level you read from cn=ipa,cn=etc,SUFFIX is >= 1 It doesn't matter if in 2025 we are at topology plugin version 7.0 and the domain level supported are now 0 through 42, you will still enable the basic behavior at domain level >= 1 Later on additional features may be conditional on other domain levels, and eventually we may even become incompatible with domain level 1 and require a higher level, but that will always be something you know statically in the code, you will never have a reason or a way to dynamically change domain level support within the plugin. Simo. -- Simo Sorce * Red Hat, Inc * New York From lkrispen at redhat.com Thu May 28 15:53:23 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 28 May 2015 17:53:23 +0200 Subject: [Freeipa-devel] Domain level for topology plugin = 2 In-Reply-To: <1432827313.19096.201.camel@willson.usersys.redhat.com> References: <55646331.5050807@redhat.com> <55647F90.506@redhat.com> <5564804B.6080305@redhat.com> <5564841B.4020906@redhat.com> <5566BBFD.9070601@redhat.com> <5566BE3E.2060104@redhat.com> <5566D684.6080505@redhat.com> <5567060D.5010202@redhat.com> <1432819613.19096.138.camel@willson.usersys.redhat.com> <55671E18.8020807@redhat.com> <1432824379.19096.164.camel@willson.usersys.redhat.com> <55672D57.7040308@redhat.com> <55672E4F.30801@redhat.com> <556731D5.4070507@redhat.com> <1432827313.19096.201.camel@willson.usersys.redhat.com> Message-ID: <556739F3.2060605@redhat.com> On 05/28/2015 05:35 PM, Simo Sorce wrote: > On Thu, 2015-05-28 at 17:18 +0200, Ludwig Krispenz wrote: >> On 05/28/2015 05:03 PM, Martin Kosek wrote: >>> On 05/28/2015 04:59 PM, Ludwig Krispenz wrote: >>>> On 05/28/2015 04:46 PM, Simo Sorce wrote: >>>>> On Thu, 2015-05-28 at 15:54 +0200, Ludwig Krispenz wrote: >>>>>> On 05/28/2015 03:26 PM, Simo Sorce wrote: >>>>>>> On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote: >>>>>>>> On 28.5.2015 10:49, Martin Kosek wrote: >>>>>>>>> On 05/28/2015 09:05 AM, Petr Spacek wrote: >>>>>>>>>> On 28.5.2015 08:55, Jan Cholasta wrote: >>>>>>>>>>> Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): >>>>>>>>>>>> On 26.5.2015 16:16, Martin Kosek wrote: >>>>>>>>>>>>> On 05/26/2015 04:13 PM, thierry bordaz wrote: >>>>>>>>>>>>>> On 05/26/2015 02:12 PM, Petr Spacek wrote: >>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> it came to my mind that domain level for topology plugin should >>>>>>>>>>>>>>> actually be >>>>>>>>>>>>>>> number 2, not 1. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We already used number 1 for incompatible changes in DNS tree and I >>>>>>>>>>>>>>> believe >>>>>>>>>>>>>>> that it is not a good idea to have two places which say 'version 1' >>>>>>>>>>>>>>> but and >>>>>>>>>>>>>>> actually mean two different things. (DNS tree version 1 + domain >>>>>>>>>>>>>>> level 1) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Patch is attached. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>> The fix looks good but that seems strange to have to set the initial >>>>>>>>>>>>>> version of >>>>>>>>>>>>>> the topology plugin to 2.0. (IIUC That is the version that will be >>>>>>>>>>>>>> written in >>>>>>>>>>>>>> dse.ldif) >>>>>>>>>>>>>> I would rather expects that topology plugin 1.0, would activate >>>>>>>>>>>>>> itself if the >>>>>>>>>>>>>> DomainLevel is 2.0 or more. >>>>>>>>>>>>>> If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then >>>>>>>>>>>>>> activate >>>>>>>>>>>>>> itself if DomainLevel >= DomainLevel_trigger. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Let's wait for Ludwig feedback. >>>>>>>>>>>>>> >>>>>>>>>>>>>> thanks >>>>>>>>>>>>>> thierry >>>>>>>>>>>>> My personal opinion on this is to start with Domain Level 1 >>>>>>>>>>>>> regardless. We >>>>>>>>>>>>> already "solved" the DNS forwarders otherwise, with docs, async >>>>>>>>>>>>> updates etc. I >>>>>>>>>>>>> do not think we will be returning to implementing proper Domain Level >>>>>>>>>>>>> support >>>>>>>>>>>>> for that anyway. >>>>>>>>>>>>> >>>>>>>>>>>>> So I rather think that all the "Domain Level starts with 0, 1 is >>>>>>>>>>>>> unused, 2 is >>>>>>>>>>>>> the top one" will cause unforeseen issues I would rather like to avoid. >>>>>>>>>>>> I'm more worried about confusion in future. To to me it simply seems >>>>>>>>>>>> easier to >>>>>>>>>>>> bump one integer now than to document and explain (to users & new >>>>>>>>>>>> developers) >>>>>>>>>>>> why we have two "ones" which mean something else. >>>>>>>>>>>> >>>>>>>>>>>> Code-wise it is just an integer. >>>>>>>>>>>> >>>>>>>>>>>> Also, it can simplify logic in future when we decide to do another >>>>>>>>>>>> incompatible change in DNS tree because we will have only one integer >>>>>>>>>>>> to test >>>>>>>>>>>> (instead of checking two separate version attribute in DNS tree & domain >>>>>>>>>>>> level). >>>>>>>>>>> +1, but I think the minimum supported domain level should be 1, not 0, >>>>>>>>>>> because >>>>>>>>>>> 0 means the server uses the old DNS schema, which we do not support >>>>>>>>>>> anymore, >>>>>>>>>>> right? >>>>>>>>>> Good point! >>>>>>>>>> >>>>>>>>> It may be a good point, but it does not make the situation easier. You still >>>>>>>>> have RHEL/CentOS 6.x IPA out there, where some of them already support >>>>>>>>> the new >>>>>>>>> DNS forwarders and some don't - and neither of them support Domain Levels - >>>>>>>>> i.e. have Domain Level 0. >>>>>>>>> >>>>>>>>> As I said, I still see more complications with this proposals than >>>>>>>>> benefits... >>>>>>>> I would argue that it actually helps. >>>>>>>> >>>>>>>> If domain level = 1 then we can be *sure* that all replicas support the new >>>>>>>> DNS semantics. >>>>>>>> >>>>>>>> If domain level = 0 then we know nothing (because of patched RHEL 6) and >>>>>>>> it is >>>>>>>> a warning sign for diagnostic tools and also us when it comes to debugging. >>>>>>> First of all a domain level is something we change *RARELY*, and it is >>>>>>> a whole number and it is an all or nothing thing. >>>>>>> >>>>>>> I do not understand why plugin versions matter at all, plugin version >>>>>>> have nothing to do with domain levels. Each plugin *whatever* the >>>>>>> version MUST always support at least 2 levels, because every domain you >>>>>>> have will have to go through a domain_level transition when a new domain >>>>>>> level comes out. >>>>>>> >>>>>>> Finally no single developer should be allowed to decide on anew domain >>>>>>> level, this must be a well ponder team decision as all plugins that need >>>>>>> to change behavior based on domain level will be affected so a thorough >>>>>>> review of what changes are needed across all plugins must be done every >>>>>>> time someone propose a change that requires a domain level bump. >>>>>>> >>>>>>> Last but not least we should consider domain levels as something that >>>>>>> changes *very* slowly, because otherwise you'll have to support many >>>>>>> domain levels within any plugins that have to change behavior according >>>>>>> to the domain level. >>>>>>> I would say that the domain level should not change more frequently than >>>>>>> once a year or so. It would be too much code churn to do otherwise. >>>>>>> >>>>>>> So for now domain_level should be set to 0. And the topology plugin will >>>>>>> be enabled only when we turn it to 1. However we shouldn't turn it to 1 >>>>>>> until we have the replica promotion code at least, because only then we >>>>>>> can make full use of the topology plugins. >>>>>>> >>>>>>> The DNS mess is unfixable, unless Petr you volunteer to backport code to >>>>>>> change the behavior of the DNS based on the domain level, if that's the >>>>>>> case then you can tie old behavior to level 0 and new behavior to level >>>>>>>> = 1, but I do not think you want to do that given we already have >>>>>>> "level 0" servers that sport the new code and changed the data in the >>>>>>> directory, so let's just ignore DNS for the purpose of this discussion, >>>>>>> except for nothing that once we finally switch to level 1 then all >>>>>>> servers must be running with the newer DNS schema and older is not >>>>>>> supported. >>>>>>> >>>>>>> Ah, I almost forgot, there is no "domain level for XYZ plugin", the >>>>>>> domain level is one for the whole server, I want to make it very clear, >>>>>>> because the title and part of the discussion seem to imply that you have >>>>>>> per-plugin domain levels. If anything like that actually exist in the >>>>>>> topology plugin code it must be ripped out now, plugin version and >>>>>>> domain level are completely disjointed things and no correlation should >>>>>>> or can exist, the only thing that can exist is whether the server, as a >>>>>>> whole, supports a specific domain level or not. >>>>>>> >>>>>>> So once we decide domain level X comes to existence we basically freeze >>>>>>> what it means and any new development that may require a domain level >>>>>>> bump risk being delayed until we are ready for a new domain level bump, >>>>>>> which should not happen very often. >>>>>>> >>>>>>> So let's make it very clear what level 1 means because the next release >>>>>>> will then support only 0 and 1, and once a new version will come out >>>>>>> with support for "level 2" we want be able to use any of the features >>>>>>> tied to level 2 until all servers in the next release have been >>>>>>> upgraded, and that may be a years long process, so we can't just churn >>>>>>> domain level numbers as we need to support working on older levels for >>>>>>> extended periods. >>>>>> Hi Simo, >>>>>> >>>>>> you say the topology plugin should only activate itself if the domain >>>>>> level is >= 1, at the moment this is done >>>>>> by checking if plugin_version (1.0) >= domain_level (1). >>>>> I do not understand what this means >>>>> >>>>>> If you want a different method/fields for decision, how do you want it >>>>>> handled ? >>>>> I do not see why you need to check for the topology plugin version, what >>>>> you need is a "min_domain_level" version for now and just check: >>>>> if domain_level >= min_domain_level: >>>>> do stuff >>>> but right now installation sets >>>> ipaMinDomainLevel: 0 >>>> ipaMaxDomainLevel: 1 >>>> >>>> in the master entry, so we would always do stuff. >>> Topology should not care about these settings at all, this is only for >>> domainlevel API to validate if the level can be raised or not. Topology plugin >>> should be only checking the effective Domain Level in cn=ipa,cn=etc,SUFFIX. >> and then ? it reads domain level to be say 1, what is the trigger. >> now I am confused, Simo say it should not compare it to the plugin >> version, you say it should not compare to the server level, >> >> so what ? hard code on domain level 1? > In the plugin you should have this variable as a global (for the plugin) > > int topology_min_domain_level = 1 > > You *know* the plugin can activate only if domain_level is 1, it is ok > to hard code it, once we release the code we will never change this. > The plugin will be forever and ever enabled only if the global domain > level you read from cn=ipa,cn=etc,SUFFIX is >= 1 this is ok, if we all agree only this thread started suggesting that the plugin should only start when it is >= 2 and have level 1 for the DNS stuff - so, even if this wasn't valid, sometimes it could help to have a config value to compare to. but I am fine with hard coding it in the plugin to 1 > > It doesn't matter if in 2025 we are at topology plugin version 7.0 and > the domain level supported are now 0 through 42, you will still enable > the basic behavior at domain level >= 1 > > Later on additional features may be conditional on other domain levels, > and eventually we may even become incompatible with domain level 1 and > require a higher level, but that will always be something you know > statically in the code, you will never have a reason or a way to > dynamically change domain level support within the plugin. > > Simo. > From mhonek at redhat.com Thu May 28 15:58:13 2015 From: mhonek at redhat.com (Matus Honek) Date: Thu, 28 May 2015 11:58:13 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0377-0382] Synchronize changes from LDAP after reconnect In-Reply-To: <5565BDAC.7070806@redhat.com> References: <5565BDAC.7070806@redhat.com> Message-ID: <1005260903.6114507.1432828693773.JavaMail.zimbra@redhat.com> Hi, functionality seems to work fine. I have not checked the code thoroughly. Kind of a test is attached (requires setting named's ldap connection appropriately). ACK Mat?? Hon?k ----- Original Message ----- From: "Petr Spacek" To: thozza at redhat.com, "Matus Honek" Cc: freeipa-devel at redhat.com Sent: Wednesday, May 27, 2015 2:50:52 PM Subject: [PATCH 0377-0382] Synchronize changes from LDAP after reconnect Hello, https://fedorahosted.org/bind-dyndb-ldap/ticket/128 Previously records deleted when connection to LDAP server was down were not synchronized properly. It should work now. I use this command to simulate broken connections and connection re-establishment: $ socat tcp-listen:3899,reuseaddr,fork tcp-connect:localhost:389 It should be enough to add "ldap://$(hostname):3899" as LDAP URI to /etc/named.conf and then simulate changes by killing and restarting socat. Let me know if you need any assistance! -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: test-resync-on-unavailability.sh Type: application/x-shellscript Size: 1230 bytes Desc: not available URL: From abokovoy at redhat.com Thu May 28 18:09:48 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 28 May 2015 21:09:48 +0300 Subject: [Freeipa-devel] Sudorules user validation help In-Reply-To: <55672D2D.6050806@redhat.com> References: <55660FDE.3030202@redhat.com> <5566D557.9030503@redhat.com> <55671ABA.9090709@redhat.com> <556725CA.6020709@redhat.com> <55672D2D.6050806@redhat.com> Message-ID: <20150528180948.GF19176@redhat.com> On Thu, 28 May 2015, Martin Kosek wrote: >On 05/28/2015 04:27 PM, Drew Erny wrote: >> In the ticket, however, it's stated that if the user wants to use any >> combination of weird characters, they should be able to. Would it be better to >> just define a function like >> >> def validate_username(username, ignore_pattern=False): >> >> and have it ignore all username validation? > >Tough question. FreeIPA in general tries to sanitize user input and does not >allow everything user wants and try to advise the best practices, as we see it. > >In your case, if we allow only the 2 mentioned user login formats, it should >work for AD use case just fine and add some level of sanity check of the user >name. BTW, given we run an LDAP search later on this user name, isn't there a >possibility of "LDAP injection" if we choose to allow all characters, including >"(" and ")"? :-) > >In any case, if we choose to ignore the pattern, we do not need the extra >validator function at all. We would just skip validation in the pre callback if >a user is being added. I still think we should run the validator exactly for the reasons outlined above. There are few limiting factors for Active Directory and Linux environments -- while user and group objects names are specified in 'cn' attirbute in Active Directory, in POSIX environment we get the real name from sAMAccountName attribute for users: * Certain characters in the Relative Distinguished Names of objects must be escaped using the backslash, "\", escape character. The characters that must be escaped are: , \ # + < > ; " = In addition, any leading or trailing spaces in the RDN must be escaped. * The following characters are not allowed in sAMAccountName values: " [ ] : ; | = + * ? < > / \ , * In Windows Server 2003 domains and above, if you do not assign a value for sAMAccountName, the system will create a semi-random value for your. This value will be similar to: $KJK000-H4GJL6AQOV1I * The schema allows 256 characters in sAMAccountName values. However, the system limits sAMAccountName to 20 characters for user and group objects and 16 characters for computer objects. As you can see, group names may have "(" and ")", also "!" and few more characters which you have to escape properly before making them part of the LDAP filter. Additionally, we actually have to allow UTF-8 characters, not just ASCII as syntax for DirectoryString (OID 1.3.6.1.4.1.1466.115.121.1.15) requires that. > >> >> On 05/28/2015 09:40 AM, Drew Erny wrote: >>> OK, I see now what you mean by that. That is a simpler solution. I'll do it >>> that way. >>> >>> On 05/28/2015 04:44 AM, Martin Kosek wrote: >>>> On 05/27/2015 08:41 PM, Drew Erny wrote: >>>>> Hey, Freeipa-devel, >>>>> >>>>> I'm working on ticket #3226 (https://fedorahosted.org/freeipa/ticket/3226) >>>>> >>>>> I've identified the problem. The sudorules add user command adds the user >>>>> validations at the end of it's pre-callback using add_external_pre_callback. >>>>> However, the "user" plugin pattern-matches a string for the "uid" param, >>>>> because it only allows certain characters. >>>>> >>>>> I've been picking through the codebase and I think I have enough understanding >>>>> to ask this: What if we changed the user "uid" validation to a standalone >>>>> "rule" function (you can do that, right? pass in a function as a validation >>>>> rule?) that would normally just assert that the pattern matches, but could >>>>> have >>>>> that pattern matching validation overridden in some cases. I think that's the >>>>> easiest, cleanest way to change user so that sudorules and other plugins can >>>>> ignore this validation if necessary (I'm trying to figure out exactly how to >>>>> implement this without changing any APIs). >>>>> >>>>> Am I understanding the plugin params API correctly, and can I do this? Is this >>>>> the best way to do this? >>>>> >>>>> The only other solution I see is to write sudorules-specific code in some >>>>> plugin-related (either user.py or baseldap.py module, which would create >>>>> unwanted coupling. >>>>> >>>>> Most specifically, this would be a change to the object instantiated at >>>>> ipalib/plugins/user.py line 467 >>>>> >>>>> Thoughts and suggestions? >>>> I think it would make sense to follow the example with validate_hostname and >>>> prepare a function validate_username(username, upn=False, >>>> netbios_name=False) [1]. >>>> >>>> where upn would allow using "@." on top of current validator (i.e. >>>> user at Domain.test) and netbios_name would allow the "DOMAIN\user" style. I would >>>> just suggest making sure the standard user validation error message is still >>>> the same to avoid unnecessary QE fail positives. >>>> >>>> In add_external_pre_callback you could then just simply call >>>> >>>> validate_username(user, True, True) >>>> >>>> just like it is already done with hostname. >>>> >>>> My 2 cents. >>>> >>>> Martin >>>> >>>> [1] >>>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa380525(v=vs.85).aspx >>> >> > >-- >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 -- / Alexander Bokovoy From derny at redhat.com Thu May 28 18:16:39 2015 From: derny at redhat.com (Drew Erny) Date: Thu, 28 May 2015 14:16:39 -0400 Subject: [Freeipa-devel] Sudorules user validation help In-Reply-To: <20150528180948.GF19176@redhat.com> References: <55660FDE.3030202@redhat.com> <5566D557.9030503@redhat.com> <55671ABA.9090709@redhat.com> <556725CA.6020709@redhat.com> <55672D2D.6050806@redhat.com> <20150528180948.GF19176@redhat.com> Message-ID: <55675B87.9010900@redhat.com> Ok, so should I write a regex that matches that broader pattern, and only allow sudorules users to be added that follow those broader restrictions? On 05/28/2015 02:09 PM, Alexander Bokovoy wrote: > On Thu, 28 May 2015, Martin Kosek wrote: >> On 05/28/2015 04:27 PM, Drew Erny wrote: >>> In the ticket, however, it's stated that if the user wants to use any >>> combination of weird characters, they should be able to. Would it be >>> better to >>> just define a function like >>> >>> def validate_username(username, ignore_pattern=False): >>> >>> and have it ignore all username validation? >> >> Tough question. FreeIPA in general tries to sanitize user input and >> does not >> allow everything user wants and try to advise the best practices, as >> we see it. >> >> In your case, if we allow only the 2 mentioned user login formats, it >> should >> work for AD use case just fine and add some level of sanity check of >> the user >> name. BTW, given we run an LDAP search later on this user name, isn't >> there a >> possibility of "LDAP injection" if we choose to allow all characters, >> including >> "(" and ")"? :-) >> >> In any case, if we choose to ignore the pattern, we do not need the >> extra >> validator function at all. We would just skip validation in the pre >> callback if >> a user is being added. > I still think we should run the validator exactly for the reasons > outlined above. There are few limiting factors for Active Directory and > Linux environments -- while user and group objects names are specified > in 'cn' attirbute in Active Directory, in POSIX environment we get the > real name from sAMAccountName attribute for users: > > * Certain characters in the Relative Distinguished Names of objects must > be escaped using the backslash, "\", escape character. The characters > that must be escaped are: > , \ # + < > ; " = > In addition, any leading or trailing spaces in the RDN must be escaped. > > * The following characters are not allowed in sAMAccountName values: > " [ ] : ; | = + * ? < > / \ , > > * In Windows Server 2003 domains and above, if you do not assign a > value for sAMAccountName, the system will create a semi-random value for > your. This value will be similar to: > $KJK000-H4GJL6AQOV1I > > * The schema allows 256 characters in sAMAccountName values. However, > the system limits sAMAccountName to 20 characters for user and group > objects and > 16 characters for computer objects. > As you can see, group names may have "(" and ")", also "!" and few more > characters which you have to escape properly before making them part of > the LDAP filter. > > Additionally, we actually have to allow UTF-8 characters, not just > ASCII as syntax for DirectoryString (OID 1.3.6.1.4.1.1466.115.121.1.15) > requires that. > >> >>> >>> On 05/28/2015 09:40 AM, Drew Erny wrote: >>>> OK, I see now what you mean by that. That is a simpler solution. >>>> I'll do it >>>> that way. >>>> >>>> On 05/28/2015 04:44 AM, Martin Kosek wrote: >>>>> On 05/27/2015 08:41 PM, Drew Erny wrote: >>>>>> Hey, Freeipa-devel, >>>>>> >>>>>> I'm working on ticket #3226 >>>>>> (https://fedorahosted.org/freeipa/ticket/3226) >>>>>> >>>>>> I've identified the problem. The sudorules add user command adds >>>>>> the user >>>>>> validations at the end of it's pre-callback using >>>>>> add_external_pre_callback. >>>>>> However, the "user" plugin pattern-matches a string for the "uid" >>>>>> param, >>>>>> because it only allows certain characters. >>>>>> >>>>>> I've been picking through the codebase and I think I have enough >>>>>> understanding >>>>>> to ask this: What if we changed the user "uid" validation to a >>>>>> standalone >>>>>> "rule" function (you can do that, right? pass in a function as a >>>>>> validation >>>>>> rule?) that would normally just assert that the pattern matches, >>>>>> but could >>>>>> have >>>>>> that pattern matching validation overridden in some cases. I >>>>>> think that's the >>>>>> easiest, cleanest way to change user so that sudorules and other >>>>>> plugins can >>>>>> ignore this validation if necessary (I'm trying to figure out >>>>>> exactly how to >>>>>> implement this without changing any APIs). >>>>>> >>>>>> Am I understanding the plugin params API correctly, and can I do >>>>>> this? Is this >>>>>> the best way to do this? >>>>>> >>>>>> The only other solution I see is to write sudorules-specific code >>>>>> in some >>>>>> plugin-related (either user.py or baseldap.py module, which would >>>>>> create >>>>>> unwanted coupling. >>>>>> >>>>>> Most specifically, this would be a change to the object >>>>>> instantiated at >>>>>> ipalib/plugins/user.py line 467 >>>>>> >>>>>> Thoughts and suggestions? >>>>> I think it would make sense to follow the example with >>>>> validate_hostname and >>>>> prepare a function validate_username(username, upn=False, >>>>> netbios_name=False) [1]. >>>>> >>>>> where upn would allow using "@." on top of current validator (i.e. >>>>> user at Domain.test) and netbios_name would allow the "DOMAIN\user" >>>>> style. I would >>>>> just suggest making sure the standard user validation error >>>>> message is still >>>>> the same to avoid unnecessary QE fail positives. >>>>> >>>>> In add_external_pre_callback you could then just simply call >>>>> >>>>> validate_username(user, True, True) >>>>> >>>>> just like it is already done with hostname. >>>>> >>>>> My 2 cents. >>>>> >>>>> Martin >>>>> >>>>> [1] >>>>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa380525(v=vs.85).aspx >>>>> >>>> >>> >> >> -- >> 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 > From mkosek at redhat.com Thu May 28 19:29:39 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 May 2015 21:29:39 +0200 Subject: [Freeipa-devel] Domain level for topology plugin = 2 In-Reply-To: <556739F3.2060605@redhat.com> References: <55646331.5050807@redhat.com> <55647F90.506@redhat.com> <5564804B.6080305@redhat.com> <5564841B.4020906@redhat.com> <5566BBFD.9070601@redhat.com> <5566BE3E.2060104@redhat.com> <5566D684.6080505@redhat.com> <5567060D.5010202@redhat.com> <1432819613.19096.138.camel@willson.usersys.redhat.com> <55671E18.8020807@redhat.com> <1432824379.19096.164.camel@willson.usersys.redhat.com> <55672D57.7040308@redhat.com> <55672E4F.30801@redhat.com> <556731D5.4070507@redhat.com> <1432827313.19096.201.camel@willson.usersys.redhat.com> <556739F3.2060605@redhat.com> Message-ID: <55676CA3.4040505@redhat.com> On 05/28/2015 05:53 PM, Ludwig Krispenz wrote: > > On 05/28/2015 05:35 PM, Simo Sorce wrote: >> On Thu, 2015-05-28 at 17:18 +0200, Ludwig Krispenz wrote: >>> On 05/28/2015 05:03 PM, Martin Kosek wrote: >>>> On 05/28/2015 04:59 PM, Ludwig Krispenz wrote: >>>>> On 05/28/2015 04:46 PM, Simo Sorce wrote: >>>>>> On Thu, 2015-05-28 at 15:54 +0200, Ludwig Krispenz wrote: >>>>>>> On 05/28/2015 03:26 PM, Simo Sorce wrote: >>>>>>>> On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote: >>>>>>>>> On 28.5.2015 10:49, Martin Kosek wrote: >>>>>>>>>> On 05/28/2015 09:05 AM, Petr Spacek wrote: >>>>>>>>>>> On 28.5.2015 08:55, Jan Cholasta wrote: >>>>>>>>>>>> Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): >>>>>>>>>>>>> On 26.5.2015 16:16, Martin Kosek wrote: >>>>>>>>>>>>>> On 05/26/2015 04:13 PM, thierry bordaz wrote: >>>>>>>>>>>>>>> On 05/26/2015 02:12 PM, Petr Spacek wrote: >>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> it came to my mind that domain level for topology plugin should >>>>>>>>>>>>>>>> actually be >>>>>>>>>>>>>>>> number 2, not 1. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> We already used number 1 for incompatible changes in DNS tree >>>>>>>>>>>>>>>> and I >>>>>>>>>>>>>>>> believe >>>>>>>>>>>>>>>> that it is not a good idea to have two places which say >>>>>>>>>>>>>>>> 'version 1' >>>>>>>>>>>>>>>> but and >>>>>>>>>>>>>>>> actually mean two different things. (DNS tree version 1 + domain >>>>>>>>>>>>>>>> level 1) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Patch is attached. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>> The fix looks good but that seems strange to have to set the >>>>>>>>>>>>>>> initial >>>>>>>>>>>>>>> version of >>>>>>>>>>>>>>> the topology plugin to 2.0. (IIUC That is the version that will be >>>>>>>>>>>>>>> written in >>>>>>>>>>>>>>> dse.ldif) >>>>>>>>>>>>>>> I would rather expects that topology plugin 1.0, would activate >>>>>>>>>>>>>>> itself if the >>>>>>>>>>>>>>> DomainLevel is 2.0 or more. >>>>>>>>>>>>>>> If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 >>>>>>>>>>>>>>> then >>>>>>>>>>>>>>> activate >>>>>>>>>>>>>>> itself if DomainLevel >= DomainLevel_trigger. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Let's wait for Ludwig feedback. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> thanks >>>>>>>>>>>>>>> thierry >>>>>>>>>>>>>> My personal opinion on this is to start with Domain Level 1 >>>>>>>>>>>>>> regardless. We >>>>>>>>>>>>>> already "solved" the DNS forwarders otherwise, with docs, async >>>>>>>>>>>>>> updates etc. I >>>>>>>>>>>>>> do not think we will be returning to implementing proper Domain >>>>>>>>>>>>>> Level >>>>>>>>>>>>>> support >>>>>>>>>>>>>> for that anyway. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So I rather think that all the "Domain Level starts with 0, 1 is >>>>>>>>>>>>>> unused, 2 is >>>>>>>>>>>>>> the top one" will cause unforeseen issues I would rather like to >>>>>>>>>>>>>> avoid. >>>>>>>>>>>>> I'm more worried about confusion in future. To to me it simply seems >>>>>>>>>>>>> easier to >>>>>>>>>>>>> bump one integer now than to document and explain (to users & new >>>>>>>>>>>>> developers) >>>>>>>>>>>>> why we have two "ones" which mean something else. >>>>>>>>>>>>> >>>>>>>>>>>>> Code-wise it is just an integer. >>>>>>>>>>>>> >>>>>>>>>>>>> Also, it can simplify logic in future when we decide to do another >>>>>>>>>>>>> incompatible change in DNS tree because we will have only one integer >>>>>>>>>>>>> to test >>>>>>>>>>>>> (instead of checking two separate version attribute in DNS tree & >>>>>>>>>>>>> domain >>>>>>>>>>>>> level). >>>>>>>>>>>> +1, but I think the minimum supported domain level should be 1, not 0, >>>>>>>>>>>> because >>>>>>>>>>>> 0 means the server uses the old DNS schema, which we do not support >>>>>>>>>>>> anymore, >>>>>>>>>>>> right? >>>>>>>>>>> Good point! >>>>>>>>>>> >>>>>>>>>> It may be a good point, but it does not make the situation easier. >>>>>>>>>> You still >>>>>>>>>> have RHEL/CentOS 6.x IPA out there, where some of them already support >>>>>>>>>> the new >>>>>>>>>> DNS forwarders and some don't - and neither of them support Domain >>>>>>>>>> Levels - >>>>>>>>>> i.e. have Domain Level 0. >>>>>>>>>> >>>>>>>>>> As I said, I still see more complications with this proposals than >>>>>>>>>> benefits... >>>>>>>>> I would argue that it actually helps. >>>>>>>>> >>>>>>>>> If domain level = 1 then we can be *sure* that all replicas support >>>>>>>>> the new >>>>>>>>> DNS semantics. >>>>>>>>> >>>>>>>>> If domain level = 0 then we know nothing (because of patched RHEL 6) and >>>>>>>>> it is >>>>>>>>> a warning sign for diagnostic tools and also us when it comes to >>>>>>>>> debugging. >>>>>>>> First of all a domain level is something we change *RARELY*, and it is >>>>>>>> a whole number and it is an all or nothing thing. >>>>>>>> >>>>>>>> I do not understand why plugin versions matter at all, plugin version >>>>>>>> have nothing to do with domain levels. Each plugin *whatever* the >>>>>>>> version MUST always support at least 2 levels, because every domain you >>>>>>>> have will have to go through a domain_level transition when a new domain >>>>>>>> level comes out. >>>>>>>> >>>>>>>> Finally no single developer should be allowed to decide on anew domain >>>>>>>> level, this must be a well ponder team decision as all plugins that need >>>>>>>> to change behavior based on domain level will be affected so a thorough >>>>>>>> review of what changes are needed across all plugins must be done every >>>>>>>> time someone propose a change that requires a domain level bump. >>>>>>>> >>>>>>>> Last but not least we should consider domain levels as something that >>>>>>>> changes *very* slowly, because otherwise you'll have to support many >>>>>>>> domain levels within any plugins that have to change behavior according >>>>>>>> to the domain level. >>>>>>>> I would say that the domain level should not change more frequently than >>>>>>>> once a year or so. It would be too much code churn to do otherwise. >>>>>>>> >>>>>>>> So for now domain_level should be set to 0. And the topology plugin will >>>>>>>> be enabled only when we turn it to 1. However we shouldn't turn it to 1 >>>>>>>> until we have the replica promotion code at least, because only then we >>>>>>>> can make full use of the topology plugins. >>>>>>>> >>>>>>>> The DNS mess is unfixable, unless Petr you volunteer to backport code to >>>>>>>> change the behavior of the DNS based on the domain level, if that's the >>>>>>>> case then you can tie old behavior to level 0 and new behavior to level >>>>>>>>> = 1, but I do not think you want to do that given we already have >>>>>>>> "level 0" servers that sport the new code and changed the data in the >>>>>>>> directory, so let's just ignore DNS for the purpose of this discussion, >>>>>>>> except for nothing that once we finally switch to level 1 then all >>>>>>>> servers must be running with the newer DNS schema and older is not >>>>>>>> supported. >>>>>>>> >>>>>>>> Ah, I almost forgot, there is no "domain level for XYZ plugin", the >>>>>>>> domain level is one for the whole server, I want to make it very clear, >>>>>>>> because the title and part of the discussion seem to imply that you have >>>>>>>> per-plugin domain levels. If anything like that actually exist in the >>>>>>>> topology plugin code it must be ripped out now, plugin version and >>>>>>>> domain level are completely disjointed things and no correlation should >>>>>>>> or can exist, the only thing that can exist is whether the server, as a >>>>>>>> whole, supports a specific domain level or not. >>>>>>>> >>>>>>>> So once we decide domain level X comes to existence we basically freeze >>>>>>>> what it means and any new development that may require a domain level >>>>>>>> bump risk being delayed until we are ready for a new domain level bump, >>>>>>>> which should not happen very often. >>>>>>>> >>>>>>>> So let's make it very clear what level 1 means because the next release >>>>>>>> will then support only 0 and 1, and once a new version will come out >>>>>>>> with support for "level 2" we want be able to use any of the features >>>>>>>> tied to level 2 until all servers in the next release have been >>>>>>>> upgraded, and that may be a years long process, so we can't just churn >>>>>>>> domain level numbers as we need to support working on older levels for >>>>>>>> extended periods. >>>>>>> Hi Simo, >>>>>>> >>>>>>> you say the topology plugin should only activate itself if the domain >>>>>>> level is >= 1, at the moment this is done >>>>>>> by checking if plugin_version (1.0) >= domain_level (1). >>>>>> I do not understand what this means >>>>>> >>>>>>> If you want a different method/fields for decision, how do you want it >>>>>>> handled ? >>>>>> I do not see why you need to check for the topology plugin version, what >>>>>> you need is a "min_domain_level" version for now and just check: >>>>>> if domain_level >= min_domain_level: >>>>>> do stuff >>>>> but right now installation sets >>>>> ipaMinDomainLevel: 0 >>>>> ipaMaxDomainLevel: 1 >>>>> >>>>> in the master entry, so we would always do stuff. >>>> Topology should not care about these settings at all, this is only for >>>> domainlevel API to validate if the level can be raised or not. Topology plugin >>>> should be only checking the effective Domain Level in cn=ipa,cn=etc,SUFFIX. >>> and then ? it reads domain level to be say 1, what is the trigger. >>> now I am confused, Simo say it should not compare it to the plugin >>> version, you say it should not compare to the server level, >>> >>> so what ? hard code on domain level 1? >> In the plugin you should have this variable as a global (for the plugin) >> >> int topology_min_domain_level = 1 >> >> You *know* the plugin can activate only if domain_level is 1, it is ok >> to hard code it, once we release the code we will never change this. >> The plugin will be forever and ever enabled only if the global domain >> level you read from cn=ipa,cn=etc,SUFFIX is >= 1 > this is ok, if we all agree > only this thread started suggesting that the plugin should only start when it > is >= 2 > and have level 1 for the DNS stuff - so, even if this wasn't valid, sometimes > it could help to have a config value to compare to. > > but I am fine with hard coding it in the plugin to 1 +1, please do (the critical bug still has priority though). I fully agree what Simo wrote in this thread. >> >> It doesn't matter if in 2025 we are at topology plugin version 7.0 and >> the domain level supported are now 0 through 42, you will still enable >> the basic behavior at domain level >= 1 >> >> Later on additional features may be conditional on other domain levels, >> and eventually we may even become incompatible with domain level 1 and >> require a higher level, but that will always be something you know >> statically in the code, you will never have a reason or a way to >> dynamically change domain level support within the plugin. >> >> Simo. >> > From derny at redhat.com Thu May 28 19:47:28 2015 From: derny at redhat.com (Drew Erny) Date: Thu, 28 May 2015 15:47:28 -0400 Subject: [Freeipa-devel] Testing Migration Message-ID: <556770D0.7090803@redhat.com> Hi, freeipa-devel, More newbie questions. I have what I believe to be a fix for Ticket #2547 (https://fedorahosted.org/freeipa/ticket/2547) written, but I need to test this fix. I need to migrate an LDAP database that is in the previously expected for (all users and groups under 1 level) and migrate an LDAP database that is in a nested form where there might be many sub-ou's to search for users and groups. I need to make sure the outcome of both migrations is the same. What would be the best way to go about this, more specifically than "set up two LDAP server and migrate them". Like, what tools are available to help me get this set up? Also, how can I preserve my work so that next time we have to modify migration code, it can be easily tested? Should I spin up VMs and save the images? Also, I can just send a patch if someone feels so utterly confident in the codebase that they can tell if the thing I've done is right or wrong just by looking at it. Thanks, Drew Erny derny at redhat.com From rcritten at redhat.com Thu May 28 21:20:47 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 28 May 2015 17:20:47 -0400 Subject: [Freeipa-devel] Testing Migration In-Reply-To: <556770D0.7090803@redhat.com> References: <556770D0.7090803@redhat.com> Message-ID: <556786AF.7030608@redhat.com> Drew Erny wrote: > Hi, freeipa-devel, > > More newbie questions. I have what I believe to be a fix for Ticket > #2547 (https://fedorahosted.org/freeipa/ticket/2547) written, but I need > to test this fix. I need to migrate an LDAP database that is in the > previously expected for (all users and groups under 1 level) and migrate > an LDAP database that is in a nested form where there might be many > sub-ou's to search for users and groups. I need to make sure the outcome > of both migrations is the same. > > What would be the best way to go about this, more specifically than "set > up two LDAP server and migrate them". Like, what tools are available to > help me get this set up? Also, how can I preserve my work so that next > time we have to modify migration code, it can be easily tested? Should I > spin up VMs and save the images? > > Also, I can just send a patch if someone feels so utterly confident in > the codebase that they can tell if the thing I've done is right or wrong > just by looking at it. I'm pretty sure the 389-ds team has scripts to generate test users and groups in ldif format. I'd ask them for it. I'd use this to seed an openldap server install, then migrate from that. You can learn how to setup openldap at https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/ch-Directory_Servers.html#s1-OpenLDAP I believe migration testing is something that is missing in the in-tree tests (ipatests). Perhaps a test could be made that fires up an openldap server on an unprivileged port and either generates a bunch of users/groups and imports it or uses a pre-canned ldif (one is slow but more random, the other faster but runs the risk of missign things). rob From ftweedal at redhat.com Fri May 29 04:17:54 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 29 May 2015 14:17:54 +1000 Subject: [Freeipa-devel] [PATCHES 0001-0013 v5] Profiles and CA ACLs In-Reply-To: <55670D4D.9080302@redhat.com> References: <20150520055636.GF12806@dhcp-40-8.bne.redhat.com> <555C30FE.4030707@redhat.com> <20150520144106.GH12806@dhcp-40-8.bne.redhat.com> <555DCC96.2050001@redhat.com> <555DD031.8070302@redhat.com> <555DD39C.3070103@redhat.com> <20150526155930.GI13469@dhcp-40-8.bne.redhat.com> <20150527140434.GD24915@dhcp-40-8.bne.redhat.com> <5566E484.7080809@redhat.com> <55670D4D.9080302@redhat.com> Message-ID: <20150529041754.GE23523@dhcp-40-8.bne.redhat.com> 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 at 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 From jcholast at redhat.com Fri May 29 06:02:26 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 29 May 2015 08:02:26 +0200 Subject: [Freeipa-devel] KDC proxy implementation specs In-Reply-To: <1432824525.2618.7.camel@redhat.com> References: <55672790.6060206@redhat.com> <1432824525.2618.7.camel@redhat.com> Message-ID: <556800F2.5070206@redhat.com> Dne 28.5.2015 v 16:48 Nathaniel McCallum napsal(a): > On Thu, 2015-05-28 at 16:34 +0200, Christian Heimes wrote: >> Jan has suggested to ipaConfigString=kdcProxyEnabled in >> cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc instead of >> ipaConfigString=enabledService in >> cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. It makes sense to me. >> After all MS-KKDCP is just another transport for the KDC. [4] > > There may be a security concern here if we aren't careful. I think I'm > in favor of KDCPROXY since it is a different application. What concern would that be? It has been already established that KDC proxy is not a different application, but rather a subcomponent of KDC in the other thread. -- Jan Cholasta From npmccallum at redhat.com Fri May 29 06:07:31 2015 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 29 May 2015 02:07:31 -0400 Subject: [Freeipa-devel] KDC proxy implementation specs In-Reply-To: <556800F2.5070206@redhat.com> References: <55672790.6060206@redhat.com> <1432824525.2618.7.camel@redhat.com> <556800F2.5070206@redhat.com> Message-ID: <1432879651.2527.7.camel@redhat.com> On Fri, 2015-05-29 at 08:02 +0200, Jan Cholasta wrote: > Dne 28.5.2015 v 16:48 Nathaniel McCallum napsal(a): > > On Thu, 2015-05-28 at 16:34 +0200, Christian Heimes wrote: > > > Jan has suggested to ipaConfigString=kdcProxyEnabled in > > > cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc instead of > > > ipaConfigString=enabledService in > > > cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. It makes sense to > > > me. > > > After all MS-KKDCP is just another transport for the KDC. [4] > > > > There may be a security concern here if we aren't careful. I think > > I'm > > in favor of KDCPROXY since it is a different application. > > What concern would that be? It has been already established that KDC > proxy is not a different application, but rather a subcomponent of > KDC > in the other thread. Accidental exposure of something else in cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc. My fear comes from the fact that in order to make this work we have to expose stuff in cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc to apache. These kind of cross -domain security allowances always raises red flags for me. Don't cross the streams... it would be bad. :) Nathaniel From ftweedal at redhat.com Fri May 29 06:08:06 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 29 May 2015 16:08:06 +1000 Subject: [Freeipa-devel] [PATCHES 0001-0013 v5] Profiles and CA ACLs In-Reply-To: <5566EFD6.6090703@redhat.com> References: <20150520055636.GF12806@dhcp-40-8.bne.redhat.com> <555C30FE.4030707@redhat.com> <20150520144106.GH12806@dhcp-40-8.bne.redhat.com> <555DCC96.2050001@redhat.com> <555DD031.8070302@redhat.com> <555DD39C.3070103@redhat.com> <20150526155930.GI13469@dhcp-40-8.bne.redhat.com> <20150527140434.GD24915@dhcp-40-8.bne.redhat.com> <5566E484.7080809@redhat.com> <5566EFD6.6090703@redhat.com> Message-ID: <20150529060352.GF23523@dhcp-40-8.bne.redhat.com> On Thu, May 28, 2015 at 12:37:10PM +0200, Petr Vobornik wrote: > On 05/28/2015 11:48 AM, 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. > >> > > I've added it to mkosek/freeipa-master > > The build was successful on f22 but failed on f21. Should it be successful > on f21? > > https://copr.fedoraproject.org/coprs/mkosek/freeipa-master/build/94540/ > -- > Petr Vobornik It needs updated tomcat packages available from updates-testing repo: http://download.fedoraproject.org/pub/fedora/linux/updates/testing/$releasever/$basearch/ Thanks, Fraser From jcholast at redhat.com Fri May 29 06:11:55 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 29 May 2015 08:11:55 +0200 Subject: [Freeipa-devel] KDC proxy implementation specs In-Reply-To: <1432879651.2527.7.camel@redhat.com> References: <55672790.6060206@redhat.com> <1432824525.2618.7.camel@redhat.com> <556800F2.5070206@redhat.com> <1432879651.2527.7.camel@redhat.com> Message-ID: <5568032B.4000808@redhat.com> Dne 29.5.2015 v 08:07 Nathaniel McCallum napsal(a): > On Fri, 2015-05-29 at 08:02 +0200, Jan Cholasta wrote: >> Dne 28.5.2015 v 16:48 Nathaniel McCallum napsal(a): >>> On Thu, 2015-05-28 at 16:34 +0200, Christian Heimes wrote: >>>> Jan has suggested to ipaConfigString=kdcProxyEnabled in >>>> cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc instead of >>>> ipaConfigString=enabledService in >>>> cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. It makes sense to >>>> me. >>>> After all MS-KKDCP is just another transport for the KDC. [4] >>> >>> There may be a security concern here if we aren't careful. I think >>> I'm >>> in favor of KDCPROXY since it is a different application. >> >> What concern would that be? It has been already established that KDC >> proxy is not a different application, but rather a subcomponent of >> KDC >> in the other thread. > > Accidental exposure of something else in > cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc. My fear comes from the fact > that in order to make this work we have to expose stuff in > cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc to apache. These kind of cross > -domain security allowances always raises red flags for me. Well, the only exposed thing would be ipaConfigString, which always has an "enabledService" value for KDC and optionally would have "kdcProxyEnabled" value if KDC proxy is enabled. IMO if someone wants to put something sensitive in there, they should use a different attribute anyway. > > Don't cross the streams... it would be bad. :) Unless Zuul comes into the picture. > > Nathaniel > -- Jan Cholasta From npmccallum at redhat.com Fri May 29 06:15:04 2015 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 29 May 2015 02:15:04 -0400 Subject: [Freeipa-devel] KDC proxy implementation specs In-Reply-To: <5568032B.4000808@redhat.com> References: <55672790.6060206@redhat.com> <1432824525.2618.7.camel@redhat.com> <556800F2.5070206@redhat.com> <1432879651.2527.7.camel@redhat.com> <5568032B.4000808@redhat.com> Message-ID: <1432880104.2527.10.camel@redhat.com> On Fri, 2015-05-29 at 08:11 +0200, Jan Cholasta wrote: > Dne 29.5.2015 v 08:07 Nathaniel McCallum napsal(a): > > On Fri, 2015-05-29 at 08:02 +0200, Jan Cholasta wrote: > > > Dne 28.5.2015 v 16:48 Nathaniel McCallum napsal(a): > > > > On Thu, 2015-05-28 at 16:34 +0200, Christian Heimes wrote: > > > > > Jan has suggested to ipaConfigString=kdcProxyEnabled in > > > > > cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc instead of > > > > > ipaConfigString=enabledService in > > > > > cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. It makes sense > > > > > to > > > > > me. > > > > > After all MS-KKDCP is just another transport for the KDC. [4] > > > > > > > > There may be a security concern here if we aren't careful. I > > > > think > > > > I'm > > > > in favor of KDCPROXY since it is a different application. > > > > > > What concern would that be? It has been already established that > > > KDC > > > proxy is not a different application, but rather a subcomponent > > > of > > > KDC > > > in the other thread. > > > > Accidental exposure of something else in > > cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc. My fear comes from the > > fact > > that in order to make this work we have to expose stuff in > > cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc to apache. These kind of > > cross > > -domain security allowances always raises red flags for me. > > Well, the only exposed thing would be ipaConfigString, which always > has > an "enabledService" value for KDC and optionally would have > "kdcProxyEnabled" value if KDC proxy is enabled. IMO if someone wants > to > put something sensitive in there, they should use a different > attribute > anyway. So say we now. Then, five years from now, when this conversation is a distant memory (if that), someone will think it is a good idea to do something stupid. :) > > Don't cross the streams... it would be bad. :) > > Unless Zuul comes into the picture. Is Zuul the intern in 2020 that exposes bad stuff? Nathaniel From lslebodn at redhat.com Fri May 29 07:23:57 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 29 May 2015 09:23:57 +0200 Subject: [Freeipa-devel] [PATCH 0245] Fix uniqueness plugins vol. 2 In-Reply-To: <55524E7F.7050403@redhat.com> References: <55522905.505@redhat.com> <55524E7F.7050403@redhat.com> Message-ID: <20150529072357.GD17442@mail.corp.redhat.com> On (12/05/15 21:03), 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 > >From df2f521473a7e4f2438f675e4328ee59c8cf4617 Mon Sep 17 00:00:00 2001 >From: Martin Basti >Date: Tue, 12 May 2015 18:11:07 +0200 >Subject: [PATCH] Server Upgrade: Fix uniqueness plugins > >Due previous changes (in master branch only) the uniqueness plugins >became misconfigured. > >After this patch: >* whole $SUFFIX will be checked by unique plugins >* just staged users are exluded from check > >This reverts some changes in commit >52b7101c1148618d5c8e2ec25576cc7ad3e9b7bb > >Since 389-ds-base 1.3.4.a1 new attribute 'uniqueness-exclude-subtrees' >can be used. > >https://fedorahosted.org/freeipa/ticket/4921 >--- > freeipa.spec.in | 6 +++--- > install/share/unique-attributes.ldif | 12 ++++++------ > install/updates/10-uniqueness.update | 20 ++++++-------------- > 3 files changed, 15 insertions(+), 23 deletions(-) > >diff --git a/freeipa.spec.in b/freeipa.spec.in >index 2bf14ef9e14f96b3100d45dd47d749b6bc3b4816..73736455655a100a2febef8e86db2c5a2f2419c9 100644 >--- a/freeipa.spec.in >+++ b/freeipa.spec.in >@@ -34,7 +34,7 @@ Source0: freeipa-%{version}.tar.gz > BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) > > %if ! %{ONLY_CLIENT} >-BuildRequires: 389-ds-base-devel >= 1.3.3.9 >+BuildRequires: 389-ds-base-devel >= 1.3.4.a1 Please revert this change. FreeIPA can be built 1.3.3.9 as well. and it block scanning pacakge with static analysers even on fedora-rawhide. I managed to build pacakges with 389-ds-base 1.3.3.9. It should be sufficient to have Requires for 1.3.4.a1. > BuildRequires: svrcore-devel > BuildRequires: policycoreutils >= 2.1.12-5 > BuildRequires: systemd-units >@@ -109,7 +109,7 @@ Group: System Environment/Base > Requires: %{name}-python = %{version}-%{release} > Requires: %{name}-client = %{version}-%{release} > Requires: %{name}-admintools = %{version}-%{release} >-Requires: 389-ds-base >= 1.3.3.9 >+Requires: 389-ds-base >= 1.3.4.a1 > Requires: openldap-clients > 2.4.35-4 > Requires: nss >= 3.14.3-12.0 > Requires: nss-tools >= 3.14.3-12.0 >@@ -144,7 +144,7 @@ Requires: zip > Requires: policycoreutils >= 2.1.12-5 > Requires: tar > Requires(pre): certmonger >= 0.76.8 >-Requires(pre): 389-ds-base >= 1.3.3.9 >+Requires(pre): 389-ds-base >= 1.3.4.a1 > Requires: fontawesome-fonts > Requires: open-sans-fonts > Requires: openssl LS From mkosek at redhat.com Fri May 29 07:47:17 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 29 May 2015 09:47:17 +0200 Subject: [Freeipa-devel] Testing Migration In-Reply-To: <556770D0.7090803@redhat.com> References: <556770D0.7090803@redhat.com> Message-ID: <55681985.80803@redhat.com> On 05/28/2015 09:47 PM, Drew Erny wrote: > Hi, freeipa-devel, > > More newbie questions. I have what I believe to be a fix for Ticket #2547 > (https://fedorahosted.org/freeipa/ticket/2547) written, but I need to test this > fix. I need to migrate an LDAP database that is in the previously expected for > (all users and groups under 1 level) and migrate an LDAP database that is in a > nested form where there might be many sub-ou's to search for users and groups. > I need to make sure the outcome of both migrations is the same. > > What would be the best way to go about this, more specifically than "set up two > LDAP server and migrate them". Like, what tools are available to help me get > this set up? Also, how can I preserve my work so that next time we have to > modify migration code, it can be easily tested? Should I spin up VMs and save > the images? > > Also, I can just send a patch if someone feels so utterly confident in the > codebase that they can tell if the thing I've done is right or wrong just by > looking at it. > > Thanks, > > Drew Erny > derny at redhat.com > For #2547, I would not complicate the issue more then necessary. I would suggest starting 2 FreeIPA servers, one for your patch, other for migrating from. In second FreeIPA server, add couple users and groups and then try to migrate it, you can use my command in https://www.freeipa.org/page/Howto/Migration#Migrating_from_other_FreeIPA_to_FreeIPA You can easily test scope BASE and ONELINE in that scenario. If you want to make sure that the scope is properly set, you can also simply check dirsrv access log and see if the right scope is used for the migration LDAP search. Martin From mbasti at redhat.com Fri May 29 07:52:42 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 29 May 2015 09:52:42 +0200 Subject: [Freeipa-devel] [PATCH 430-433] Move ipa-server-* into modules In-Reply-To: <55672619.5080908@redhat.com> References: <55672619.5080908@redhat.com> Message-ID: <55681ACA.3070606@redhat.com> On 28/05/15 16:28, Jan Cholasta wrote: > Hi, > > the attached patches move ipa-server-install, ipa-replica-install and > ipa-server-upgrade into modules. This is part of > . > > Honza > ACK -- Martin Basti From jcholast at redhat.com Fri May 29 08:01:05 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 29 May 2015 10:01:05 +0200 Subject: [Freeipa-devel] [PATCH 430-433] Move ipa-server-* into modules In-Reply-To: <55681ACA.3070606@redhat.com> References: <55672619.5080908@redhat.com> <55681ACA.3070606@redhat.com> Message-ID: <55681CC1.30202@redhat.com> Dne 29.5.2015 v 09:52 Martin Basti napsal(a): > On 28/05/15 16:28, Jan Cholasta wrote: >> Hi, >> >> the attached patches move ipa-server-install, ipa-replica-install and >> ipa-server-upgrade into modules. This is part of >> . >> >> Honza >> > ACK Thanks. Pushed to master: f451af9a5a6618b6c8d24b28ca8d06fd109487dd -- Jan Cholasta From jcholast at redhat.com Fri May 29 08:21:10 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 29 May 2015 10:21:10 +0200 Subject: [Freeipa-devel] Attention: ipa-server-install, ipa-replica-install and ipa-upgradeconfig code was moved Message-ID: <55682176.4000207@redhat.com> Hi, the code of ipa-server-install, ipa-replica-install and ipa-upgradeconfig was moved to modules in ipaserver in these commits: * 027515230a93a7a60983d3eca26a97a0d9c3610e Server Upgrade: Move code from ipa-upgradeconfig to separate module * 5a7b153ad238ebdf8aa3c85fdf5c308640d8457b install: Make a package out of ipaserver.install.server * 6dabe6ebb28c9972cedc3fb7cc1e59ddd8e5e5b6 install: Move ipa-server-install code into a module * 3cb42e33c06fb66702ecfd34ddcad9b548f23132 install: Move ipa-replica-install code into a module * f451af9a5a6618b6c8d24b28ca8d06fd109487dd install: Move ipa-server-upgrade code into a module If you made modifications to any of these scripts in your patches, you will need to rebase them as follows: * ipa-server-install install code was moved to install_check() and install() functions in ipaserver/install/server/install.py * ipa-server-install uninstall code was moved to uninstall_check() and uninstall() functions in ipaserver/install/server/install.py * ipa-replica-install code was moved to install_check() and install() functions in ipaserver/install/server/replicainstall.py * ipa-upgradeconfig code was moved to upgrade_check() and upgrade() functions in ipaserver/install/server/upgrade.py The {install,upgrade}_check() functions do the checks that are done before the operation and function {install,upgrade}() do the actual operation. If you have any questions, feel free to reply to this mail or ask me personally. Honza -- Jan Cholasta From mbasti at redhat.com Fri May 29 08:33:33 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 29 May 2015 10:33:33 +0200 Subject: [Freeipa-devel] [PATCH 02261] Revert 389 DS BuildRequires version In-Reply-To: <20150529072357.GD17442@mail.corp.redhat.com> References: <55522905.505@redhat.com> <55524E7F.7050403@redhat.com> <20150529072357.GD17442@mail.corp.redhat.com> Message-ID: <5568245D.2050806@redhat.com> On 29/05/15 09:23, Lukas Slebodnik wrote: > On (12/05/15 21:03), 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 >> > >From df2f521473a7e4f2438f675e4328ee59c8cf4617 Mon Sep 17 00:00:00 2001 >> From: Martin Basti >> Date: Tue, 12 May 2015 18:11:07 +0200 >> Subject: [PATCH] Server Upgrade: Fix uniqueness plugins >> >> Due previous changes (in master branch only) the uniqueness plugins >> became misconfigured. >> >> After this patch: >> * whole $SUFFIX will be checked by unique plugins >> * just staged users are exluded from check >> >> This reverts some changes in commit >> 52b7101c1148618d5c8e2ec25576cc7ad3e9b7bb >> >> Since 389-ds-base 1.3.4.a1 new attribute 'uniqueness-exclude-subtrees' >> can be used. >> >> https://fedorahosted.org/freeipa/ticket/4921 >> --- >> freeipa.spec.in | 6 +++--- >> install/share/unique-attributes.ldif | 12 ++++++------ >> install/updates/10-uniqueness.update | 20 ++++++-------------- >> 3 files changed, 15 insertions(+), 23 deletions(-) >> >> diff --git a/freeipa.spec.in b/freeipa.spec.in >> index 2bf14ef9e14f96b3100d45dd47d749b6bc3b4816..73736455655a100a2febef8e86db2c5a2f2419c9 100644 >> --- a/freeipa.spec.in >> +++ b/freeipa.spec.in >> @@ -34,7 +34,7 @@ Source0: freeipa-%{version}.tar.gz >> BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) >> >> %if ! %{ONLY_CLIENT} >> -BuildRequires: 389-ds-base-devel >= 1.3.3.9 >> +BuildRequires: 389-ds-base-devel >= 1.3.4.a1 > Please revert this change. FreeIPA can be built 1.3.3.9 as well. > and it block scanning pacakge with static analysers even on fedora-rawhide. > > I managed to build pacakges with 389-ds-base 1.3.3.9. > It should be sufficient to have Requires for 1.3.4.a1. > > > >> BuildRequires: svrcore-devel >> BuildRequires: policycoreutils >= 2.1.12-5 >> BuildRequires: systemd-units >> @@ -109,7 +109,7 @@ Group: System Environment/Base >> Requires: %{name}-python = %{version}-%{release} >> Requires: %{name}-client = %{version}-%{release} >> Requires: %{name}-admintools = %{version}-%{release} >> -Requires: 389-ds-base >= 1.3.3.9 >> +Requires: 389-ds-base >= 1.3.4.a1 >> Requires: openldap-clients > 2.4.35-4 >> Requires: nss >= 3.14.3-12.0 >> Requires: nss-tools >= 3.14.3-12.0 >> @@ -144,7 +144,7 @@ Requires: zip >> Requires: policycoreutils >= 2.1.12-5 >> Requires: tar >> Requires(pre): certmonger >= 0.76.8 >> -Requires(pre): 389-ds-base >= 1.3.3.9 >> +Requires(pre): 389-ds-base >= 1.3.4.a1 >> Requires: fontawesome-fonts >> Requires: open-sans-fonts >> Requires: openssl > LS Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0261-Revert-389-DS-BuildRequires-version-to-1.3.3.9.patch Type: text/x-patch Size: 851 bytes Desc: not available URL: From mkosek at redhat.com Fri May 29 08:38:41 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 29 May 2015 10:38:41 +0200 Subject: [Freeipa-devel] #4905: [RFE] Allow Kerberos authentication for users with certificates on smart cards (pkinit) Message-ID: <55682591.1020907@redhat.com> Hello all, I would like to discuss the scope needed for ticket 4905 [1]. This is mostly question for Sumit as he is working on the SSSD SC support. The main minimal target is to allow SSSD get a ticket for a user once he authenticates with his SC with certificates tracked in FreeIPA as agreed in [2]. Sumit, Simo or others, what changes are required in order to do this? In [1], I so far identified: * Support of Smart Cards in SSSD (?upstream ticket) * API/CLI for configuring the trusted CA certificate in KDC (related - #616) as the base. What else is needed? Any krb5.conf changes on the server/clients? Or even generating the certs/keys as mentioned in [3]? In current code base, we still have the disabled pkinit plugin [4], but I assume this is not what we want. Thanks for help and advise. Based on what is found out in this thread, we will see what's realistic for FreeIPA 4.2 or FreeIPA 4.2.x. [1] https://fedorahosted.org/freeipa/ticket/4905 [2] http://www.freeipa.org/page/V4/User_Certificates [3] https://fedorahosted.org/freeipa/ticket/55#comment:3 [4] https://git.fedorahosted.org/cgit/freeipa.git/tree/ipalib/plugins/pkinit.py -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From lslebodn at redhat.com Fri May 29 08:43:48 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 29 May 2015 10:43:48 +0200 Subject: [Freeipa-devel] [PATCH 02261] Revert 389 DS BuildRequires version In-Reply-To: <5568245D.2050806@redhat.com> References: <55522905.505@redhat.com> <55524E7F.7050403@redhat.com> <20150529072357.GD17442@mail.corp.redhat.com> <5568245D.2050806@redhat.com> Message-ID: <20150529084348.GE17442@mail.corp.redhat.com> On (29/05/15 10:33), Martin Basti wrote: >On 29/05/15 09:23, Lukas Slebodnik wrote: >>On (12/05/15 21:03), 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 >>> >>>From df2f521473a7e4f2438f675e4328ee59c8cf4617 Mon Sep 17 00:00:00 2001 >>>From: Martin Basti >>>Date: Tue, 12 May 2015 18:11:07 +0200 >>>Subject: [PATCH] Server Upgrade: Fix uniqueness plugins >>> >>>Due previous changes (in master branch only) the uniqueness plugins >>>became misconfigured. >>> >>>After this patch: >>>* whole $SUFFIX will be checked by unique plugins >>>* just staged users are exluded from check >>> >>>This reverts some changes in commit >>>52b7101c1148618d5c8e2ec25576cc7ad3e9b7bb >>> >>>Since 389-ds-base 1.3.4.a1 new attribute 'uniqueness-exclude-subtrees' >>>can be used. >>> >>>https://fedorahosted.org/freeipa/ticket/4921 >>>--- >>>freeipa.spec.in | 6 +++--- >>>install/share/unique-attributes.ldif | 12 ++++++------ >>>install/updates/10-uniqueness.update | 20 ++++++-------------- >>>3 files changed, 15 insertions(+), 23 deletions(-) >>> >>>diff --git a/freeipa.spec.in b/freeipa.spec.in >>>index 2bf14ef9e14f96b3100d45dd47d749b6bc3b4816..73736455655a100a2febef8e86db2c5a2f2419c9 100644 >>>--- a/freeipa.spec.in >>>+++ b/freeipa.spec.in >>>@@ -34,7 +34,7 @@ Source0: freeipa-%{version}.tar.gz >>>BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) >>> >>>%if ! %{ONLY_CLIENT} >>>-BuildRequires: 389-ds-base-devel >= 1.3.3.9 >>>+BuildRequires: 389-ds-base-devel >= 1.3.4.a1 >>Please revert this change. FreeIPA can be built 1.3.3.9 as well. >>and it block scanning pacakge with static analysers even on fedora-rawhide. >> >>I managed to build pacakges with 389-ds-base 1.3.3.9. >>It should be sufficient to have Requires for 1.3.4.a1. >> >> >> >>>BuildRequires: svrcore-devel >>>BuildRequires: policycoreutils >= 2.1.12-5 >>>BuildRequires: systemd-units >>>@@ -109,7 +109,7 @@ Group: System Environment/Base >>>Requires: %{name}-python = %{version}-%{release} >>>Requires: %{name}-client = %{version}-%{release} >>>Requires: %{name}-admintools = %{version}-%{release} >>>-Requires: 389-ds-base >= 1.3.3.9 >>>+Requires: 389-ds-base >= 1.3.4.a1 >>>Requires: openldap-clients > 2.4.35-4 >>>Requires: nss >= 3.14.3-12.0 >>>Requires: nss-tools >= 3.14.3-12.0 >>>@@ -144,7 +144,7 @@ Requires: zip >>>Requires: policycoreutils >= 2.1.12-5 >>>Requires: tar >>>Requires(pre): certmonger >= 0.76.8 >>>-Requires(pre): 389-ds-base >= 1.3.3.9 >>>+Requires(pre): 389-ds-base >= 1.3.4.a1 >>>Requires: fontawesome-fonts >>>Requires: open-sans-fonts >>>Requires: openssl >>LS >Patch attached. > >-- >Martin Basti > >From 58e24b762c78f995d44ebf89e995df2360e9c055 Mon Sep 17 00:00:00 2001 >From: Martin Basti >Date: Fri, 29 May 2015 10:29:15 +0200 >Subject: [PATCH] Revert 389-DS BuildRequires version to 1.3.3.9 > >--- > freeipa.spec.in | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/freeipa.spec.in b/freeipa.spec.in >index 7dc576256865fb04b3f322b2094a5e3ece7776a5..d2943547bf4d967bac031b02eb74ab4693cb9872 100644 >--- a/freeipa.spec.in >+++ b/freeipa.spec.in >@@ -34,7 +34,7 @@ Source0: freeipa-%{version}.tar.gz > BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) > > %if ! %{ONLY_CLIENT} >-BuildRequires: 389-ds-base-devel >= 1.3.4.a1 >+BuildRequires: 389-ds-base-devel >= 1.3.3.9 > BuildRequires: svrcore-devel > BuildRequires: policycoreutils >= 2.1.12-5 > BuildRequires: systemd-units Thank you. rpms can be built on fedora-rawhide ACK LS From lkrispen at redhat.com Fri May 29 08:56:31 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 29 May 2015 10:56:31 +0200 Subject: [Freeipa-devel] [PATCH 02261] Revert 389 DS BuildRequires version In-Reply-To: <5568245D.2050806@redhat.com> References: <55522905.505@redhat.com> <55524E7F.7050403@redhat.com> <20150529072357.GD17442@mail.corp.redhat.com> <5568245D.2050806@redhat.com> Message-ID: <556829BF.8050402@redhat.com> Hi, the topology plugin relies on a change in DS to be able to mark replication agreements, this fix is in master and will be in 1.3.3.11 (but I think it is not yet out) Ludwig On 05/29/2015 10:33 AM, Martin Basti wrote: > On 29/05/15 09:23, Lukas Slebodnik wrote: >> On (12/05/15 21:03), 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 >>> >> >From df2f521473a7e4f2438f675e4328ee59c8cf4617 Mon Sep 17 00:00:00 2001 >>> From: Martin Basti >>> Date: Tue, 12 May 2015 18:11:07 +0200 >>> Subject: [PATCH] Server Upgrade: Fix uniqueness plugins >>> >>> Due previous changes (in master branch only) the uniqueness plugins >>> became misconfigured. >>> >>> After this patch: >>> * whole $SUFFIX will be checked by unique plugins >>> * just staged users are exluded from check >>> >>> This reverts some changes in commit >>> 52b7101c1148618d5c8e2ec25576cc7ad3e9b7bb >>> >>> Since 389-ds-base 1.3.4.a1 new attribute 'uniqueness-exclude-subtrees' >>> can be used. >>> >>> https://fedorahosted.org/freeipa/ticket/4921 >>> --- >>> freeipa.spec.in | 6 +++--- >>> install/share/unique-attributes.ldif | 12 ++++++------ >>> install/updates/10-uniqueness.update | 20 ++++++-------------- >>> 3 files changed, 15 insertions(+), 23 deletions(-) >>> >>> diff --git a/freeipa.spec.in b/freeipa.spec.in >>> index >>> 2bf14ef9e14f96b3100d45dd47d749b6bc3b4816..73736455655a100a2febef8e86db2c5a2f2419c9 >>> 100644 >>> --- a/freeipa.spec.in >>> +++ b/freeipa.spec.in >>> @@ -34,7 +34,7 @@ Source0: freeipa-%{version}.tar.gz >>> BuildRoot: >>> %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) >>> >>> %if ! %{ONLY_CLIENT} >>> -BuildRequires: 389-ds-base-devel >= 1.3.3.9 >>> +BuildRequires: 389-ds-base-devel >= 1.3.4.a1 >> Please revert this change. FreeIPA can be built 1.3.3.9 as well. >> and it block scanning pacakge with static analysers even on >> fedora-rawhide. >> >> I managed to build pacakges with 389-ds-base 1.3.3.9. >> It should be sufficient to have Requires for 1.3.4.a1. >> >> >> >>> BuildRequires: svrcore-devel >>> BuildRequires: policycoreutils >= 2.1.12-5 >>> BuildRequires: systemd-units >>> @@ -109,7 +109,7 @@ Group: System Environment/Base >>> Requires: %{name}-python = %{version}-%{release} >>> Requires: %{name}-client = %{version}-%{release} >>> Requires: %{name}-admintools = %{version}-%{release} >>> -Requires: 389-ds-base >= 1.3.3.9 >>> +Requires: 389-ds-base >= 1.3.4.a1 >>> Requires: openldap-clients > 2.4.35-4 >>> Requires: nss >= 3.14.3-12.0 >>> Requires: nss-tools >= 3.14.3-12.0 >>> @@ -144,7 +144,7 @@ Requires: zip >>> Requires: policycoreutils >= 2.1.12-5 >>> Requires: tar >>> Requires(pre): certmonger >= 0.76.8 >>> -Requires(pre): 389-ds-base >= 1.3.3.9 >>> +Requires(pre): 389-ds-base >= 1.3.4.a1 >>> Requires: fontawesome-fonts >>> Requires: open-sans-fonts >>> Requires: openssl >> LS > Patch attached. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cheimes at redhat.com Fri May 29 09:10:58 2015 From: cheimes at redhat.com (Christian Heimes) Date: Fri, 29 May 2015 11:10:58 +0200 Subject: [Freeipa-devel] KDC proxy implementation specs In-Reply-To: <1432879651.2527.7.camel@redhat.com> References: <55672790.6060206@redhat.com> <1432824525.2618.7.camel@redhat.com> <556800F2.5070206@redhat.com> <1432879651.2527.7.camel@redhat.com> Message-ID: <55682D22.9070109@redhat.com> On 2015-05-29 08:07, Nathaniel McCallum wrote: > On Fri, 2015-05-29 at 08:02 +0200, Jan Cholasta wrote: >> Dne 28.5.2015 v 16:48 Nathaniel McCallum napsal(a): >>> On Thu, 2015-05-28 at 16:34 +0200, Christian Heimes wrote: >>>> Jan has suggested to ipaConfigString=kdcProxyEnabled in >>>> cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc instead of >>>> ipaConfigString=enabledService in >>>> cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. It makes sense to >>>> me. >>>> After all MS-KKDCP is just another transport for the KDC. [4] >>> >>> There may be a security concern here if we aren't careful. I think >>> I'm >>> in favor of KDCPROXY since it is a different application. >> >> What concern would that be? It has been already established that KDC >> proxy is not a different application, but rather a subcomponent of >> KDC >> in the other thread. > > Accidental exposure of something else in > cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc. My fear comes from the fact > that in order to make this work we have to expose stuff in > cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc to apache. These kind of cross > -domain security allowances always raises red flags for me. I don't need read permission for all ipaConfigString attributes. In fact search and compare for (ipaConfigString=kdcProxyEnabled) is just about enough. Of course I have to name the permission differently. But that is the least of my problems. :) Your key master, Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From mbasti at redhat.com Fri May 29 09:17:10 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 29 May 2015 11:17:10 +0200 Subject: [Freeipa-devel] Testing Migration In-Reply-To: <556770D0.7090803@redhat.com> References: <556770D0.7090803@redhat.com> Message-ID: <55682E96.4010009@redhat.com> On 28/05/15 21:47, Drew Erny wrote: > Hi, freeipa-devel, > > More newbie questions. I have what I believe to be a fix for Ticket > #2547 (https://fedorahosted.org/freeipa/ticket/2547) written, but I > need to test this fix. I need to migrate an LDAP database that is in > the previously expected for (all users and groups under 1 level) and > migrate an LDAP database that is in a nested form where there might be > many sub-ou's to search for users and groups. I need to make sure the > outcome of both migrations is the same. > > What would be the best way to go about this, more specifically than > "set up two LDAP server and migrate them". Like, what tools are > available to help me get this set up? Also, how can I preserve my work > so that next time we have to modify migration code, it can be easily > tested? Should I spin up VMs and save the images? > > Also, I can just send a patch if someone feels so utterly confident in > the codebase that they can tell if the thing I've done is right or > wrong just by looking at it. > > Thanks, > > Drew Erny > derny at redhat.com > As a tool to browse DIT, I recommend the Apache directory studio (respectively plugin in eclipse) :) -- Martin Basti From mbasti at redhat.com Fri May 29 09:21:52 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 29 May 2015 11:21:52 +0200 Subject: [Freeipa-devel] [PATCHES 0001-0013 v5] Profiles and CA ACLs In-Reply-To: <20150529041754.GE23523@dhcp-40-8.bne.redhat.com> References: <20150520055636.GF12806@dhcp-40-8.bne.redhat.com> <555C30FE.4030707@redhat.com> <20150520144106.GH12806@dhcp-40-8.bne.redhat.com> <555DCC96.2050001@redhat.com> <555DD031.8070302@redhat.com> <555DD39C.3070103@redhat.com> <20150526155930.GI13469@dhcp-40-8.bne.redhat.com> <20150527140434.GD24915@dhcp-40-8.bne.redhat.com> <5566E484.7080809@redhat.com> <55670D4D.9080302@redhat.com> <20150529041754.GE23523@dhcp-40-8.bne.redhat.com> Message-ID: <55682FB0.1030807@redhat.com> 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 at 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. :-( -- Martin Basti From sbose at redhat.com Fri May 29 09:26:05 2015 From: sbose at redhat.com (Sumit Bose) Date: Fri, 29 May 2015 11:26:05 +0200 Subject: [Freeipa-devel] #4905: [RFE] Allow Kerberos authentication for users with certificates on smart cards (pkinit) In-Reply-To: <55682591.1020907@redhat.com> References: <55682591.1020907@redhat.com> Message-ID: <20150529092605.GE3943@p.redhat.com> On Fri, May 29, 2015 at 10:38:41AM +0200, Martin Kosek wrote: > Hello all, > > I would like to discuss the scope needed for ticket 4905 [1]. This is mostly > question for Sumit as he is working on the SSSD SC support. The main minimal > target is to allow SSSD get a ticket for a user once he authenticates with > his SC with certificates tracked in FreeIPA as agreed in [2]. > > Sumit, Simo or others, what changes are required in order to do this? In > [1], I so far identified: > > * Support of Smart Cards in SSSD (?upstream ticket) > * API/CLI for configuring the trusted CA certificate in KDC (related - #616) > > as the base. What else is needed? Any krb5.conf changes on the > server/clients? Or even generating the certs/keys as mentioned in [3]? currently I would say krb5.conf both on IPA clients and servers already have all the needed entries. > > In current code base, we still have the disabled pkinit plugin [4], but I > assume this is not what we want. I think this is only for anonymous pkinit. The general pkinit preauth plugin is automatically available as long as the krb5-pkinit package is installed. The package contains both client and server side of the plugin, so it must be available on IPA clients and servers. > > Thanks for help and advise. Based on what is found out in this thread, we > will see what's realistic for FreeIPA 4.2 or FreeIPA 4.2.x. My understanding is that the current version of the MIT Kerberos pkinit plugin needs a id-pkinit-san entry in the Subject Alternatives Names of the certificate with the Kerberos principal of the given user. I think it would be good to add this entry to user certificates IPA generates on its own. The pkinit RFC 4556 mentioned that the KDC can do the mapping between the certificate and the user principal on its own. But given that afaik there is currently no support for this scheme in the MIT pkinit plugin and hence it would require enhancements in the MIT code and maybe in the IPA KDB backend as well I think the support for certificates without a id-pkinit-san entry is out-of-scope for 4.2. Nevertheless client side authentication would still work only the user will not have a valid Kerberos TGT after logging in. HTH bye, Sumit > > [1] https://fedorahosted.org/freeipa/ticket/4905 > [2] http://www.freeipa.org/page/V4/User_Certificates > [3] https://fedorahosted.org/freeipa/ticket/55#comment:3 > [4] https://git.fedorahosted.org/cgit/freeipa.git/tree/ipalib/plugins/pkinit.py > > -- > Martin Kosek > Supervisor, Software Engineering - Identity Management Team > Red Hat Inc. From ofayans at redhat.com Fri May 29 09:28:38 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 29 May 2015 11:28:38 +0200 Subject: [Freeipa-devel] topology + domainlevels + testing Message-ID: <55683146.4090400@redhat.com> Hi all, Is there already a separate testplan for Domain Levels feature? If not, should I probably take care of domainlevel-specific testcases in the scope of the Topology testplan, since these features are closely correlated right now? Another question: I think it could be a nice idea to have a special field in the wiki header of design pages displaying the link to the corresponding testplan page (somewhere between "Ticket" and "Target version", for example). WDYT? -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From lslebodn at redhat.com Fri May 29 09:50:44 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 29 May 2015 11:50:44 +0200 Subject: [Freeipa-devel] [PATCH 02261] Revert 389 DS BuildRequires version In-Reply-To: <556829BF.8050402@redhat.com> References: <55522905.505@redhat.com> <55524E7F.7050403@redhat.com> <20150529072357.GD17442@mail.corp.redhat.com> <5568245D.2050806@redhat.com> <556829BF.8050402@redhat.com> Message-ID: <20150529095043.GF17442@mail.corp.redhat.com> On (29/05/15 10:56), Ludwig Krispenz wrote: >Hi, > >the topology plugin relies on a change in DS to be able to mark replication >agreements, this fix is in master and will be in 1.3.3.11 (but I think it is >not yet out) Do you mean a built time dependency or run time dependency? Because I didn't have any problem to build ipa master with 1.3.3.9 LS From ofayans at redhat.com Fri May 29 10:01:53 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 29 May 2015 12:01:53 +0200 Subject: [Freeipa-devel] topology* commands not exported through ipalib.api.Command Message-ID: <55683911.5010307@redhat.com> Hi Ludwig, Should topology plugin export it's commands through ipalib.api? Currently when I import ipalib.api and inspect available commands in api.Command, there are no topology-specific commands. The full list of commands currently exported through the API is attached -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- _NameSpace__map _NameSpace__members _NameSpace__names _NameSpace__sort _ReadOnly__locked __call__ __class__ __contains__ __delattr__ __dict__ __doc__ __format__ __getattribute__ __getitem__ __hash__ __init__ __islocked__ __iter__ __len__ __lock__ __module__ __new__ __reduce__ __reduce_ex__ __repr__ __setattr__ __sizeof__ __str__ __subclasshook__ __todict__ __weakref__ aci_add aci_del aci_find aci_mod aci_rename aci_show adtrust_is_enabled automember_add automember_add_condition automember_default_group_remove automember_default_group_set automember_default_group_show automember_del automember_find automember_mod automember_rebuild automember_remove_condition automember_show automountkey_add automountkey_del automountkey_find automountkey_mod automountkey_show automountlocation_add automountlocation_del automountlocation_find automountlocation_import automountlocation_show automountlocation_tofiles automountmap_add automountmap_add_indirect automountmap_del automountmap_find automountmap_mod automountmap_show batch ca_is_enabled cert_find cert_remove_hold cert_request cert_revoke cert_show cert_status compat_is_enabled config_mod config_show console cosentry_add cosentry_del cosentry_find cosentry_mod cosentry_show delegation_add delegation_del delegation_find delegation_mod delegation_show dns_is_enabled dns_resolve dnsconfig_mod dnsconfig_show dnsforwardzone_add dnsforwardzone_add_permission dnsforwardzone_del dnsforwardzone_disable dnsforwardzone_enable dnsforwardzone_find dnsforwardzone_mod dnsforwardzone_remove_permission dnsforwardzone_show dnsrecord_add dnsrecord_del dnsrecord_delentry dnsrecord_find dnsrecord_mod dnsrecord_show dnszone_add dnszone_add_permission dnszone_del dnszone_disable dnszone_enable dnszone_find dnszone_mod dnszone_remove_permission dnszone_show domainlevel_get domainlevel_set env group_add group_add_member group_del group_detach group_find group_mod group_remove_member group_show hbacrule_add hbacrule_add_host hbacrule_add_service hbacrule_add_sourcehost hbacrule_add_user hbacrule_del hbacrule_disable hbacrule_enable hbacrule_find hbacrule_mod hbacrule_remove_host hbacrule_remove_service hbacrule_remove_sourcehost hbacrule_remove_user hbacrule_show hbacsvc_add hbacsvc_del hbacsvc_find hbacsvc_mod hbacsvc_show hbacsvcgroup_add hbacsvcgroup_add_member hbacsvcgroup_del hbacsvcgroup_find hbacsvcgroup_mod hbacsvcgroup_remove_member hbacsvcgroup_show hbactest help host_add host_add_managedby host_allow_create_keytab host_allow_retrieve_keytab host_del host_disable host_disallow_create_keytab host_disallow_retrieve_keytab host_find host_mod host_remove_managedby host_show hostgroup_add hostgroup_add_member hostgroup_del hostgroup_find hostgroup_mod hostgroup_remove_member hostgroup_show i18n_messages idoverridegroup_add idoverridegroup_del idoverridegroup_find idoverridegroup_mod idoverridegroup_show idoverrideuser_add idoverrideuser_del idoverrideuser_find idoverrideuser_mod idoverrideuser_show idrange_add idrange_del idrange_find idrange_mod idrange_show idview_add idview_apply idview_del idview_find idview_mod idview_show idview_unapply json_metadata krbtpolicy_mod krbtpolicy_reset krbtpolicy_show migrate_ds netgroup_add netgroup_add_member netgroup_del netgroup_find netgroup_mod netgroup_remove_member netgroup_show otpconfig_mod otpconfig_show otptoken_add otptoken_add_managedby otptoken_add_yubikey otptoken_del otptoken_find otptoken_mod otptoken_remove_managedby otptoken_show otptoken_sync passwd permission_add permission_add_member permission_add_noaci permission_del permission_find permission_mod permission_remove_member permission_show ping pkinit_anonymous plugins privilege_add privilege_add_member privilege_add_permission privilege_del privilege_find privilege_mod privilege_remove_member privilege_remove_permission privilege_show pwpolicy_add pwpolicy_del pwpolicy_find pwpolicy_mod pwpolicy_show radiusproxy_add radiusproxy_del radiusproxy_find radiusproxy_mod radiusproxy_show realmdomains_mod realmdomains_show role_add role_add_member role_add_privilege role_del role_find role_mod role_remove_member role_remove_privilege role_show selfservice_add selfservice_del selfservice_find selfservice_mod selfservice_show selinuxusermap_add selinuxusermap_add_host selinuxusermap_add_user selinuxusermap_del selinuxusermap_disable selinuxusermap_enable selinuxusermap_find selinuxusermap_mod selinuxusermap_remove_host selinuxusermap_remove_user selinuxusermap_show server_find server_show service_add service_add_host service_allow_create_keytab service_allow_retrieve_keytab service_del service_disable service_disallow_create_keytab service_disallow_retrieve_keytab service_find service_mod service_remove_host service_show show_mappings sidgen_was_run stageuser_activate stageuser_add stageuser_del stageuser_find stageuser_mod stageuser_show sudocmd_add sudocmd_del sudocmd_find sudocmd_mod sudocmd_show sudocmdgroup_add sudocmdgroup_add_member sudocmdgroup_del sudocmdgroup_find sudocmdgroup_mod sudocmdgroup_remove_member sudocmdgroup_show sudorule_add sudorule_add_allow_command sudorule_add_deny_command sudorule_add_host sudorule_add_option sudorule_add_runasgroup sudorule_add_runasuser sudorule_add_user sudorule_del sudorule_disable sudorule_enable sudorule_find sudorule_mod sudorule_remove_allow_command sudorule_remove_deny_command sudorule_remove_host sudorule_remove_option sudorule_remove_runasgroup sudorule_remove_runasuser sudorule_remove_user sudorule_show trust_add trust_del trust_fetch_domains trust_find trust_mod trust_resolve trust_show trustconfig_mod trustconfig_show trustdomain_add trustdomain_del trustdomain_disable trustdomain_enable trustdomain_find trustdomain_mod user_add user_del user_disable user_enable user_find user_mod user_show user_status user_undel user_unlock vault_add vault_del vault_find vault_mod vault_show From mkosek at redhat.com Fri May 29 10:02:21 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 29 May 2015 12:02:21 +0200 Subject: [Freeipa-devel] topology + domainlevels + testing In-Reply-To: <55683146.4090400@redhat.com> References: <55683146.4090400@redhat.com> Message-ID: <5568392D.3060303@redhat.com> On 05/29/2015 11:28 AM, Oleg Fayans wrote: > Hi all, > > Is there already a separate testplan for Domain Levels feature? If not, > should I probably take care of domainlevel-specific testcases in the > scope of the Topology testplan, since these features are closely > correlated right now? > > Another question: I think it could be a nice idea to have a special > field in the wiki header of design pages displaying the link to the > corresponding testplan page (somewhere between "Ticket" and "Target > version", for example). WDYT? Good idea. I can add that. Please give me some example of such "couple" (design, test case) so that I can test it. From mkosek at redhat.com Fri May 29 10:05:31 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 29 May 2015 12:05:31 +0200 Subject: [Freeipa-devel] topology* commands not exported through ipalib.api.Command In-Reply-To: <55683911.5010307@redhat.com> References: <55683911.5010307@redhat.com> Message-ID: <556839EB.5010708@redhat.com> On 05/29/2015 12:01 PM, Oleg Fayans wrote: > Hi Ludwig, > > Should topology plugin export it's commands through ipalib.api? > Currently when I import ipalib.api and inspect available commands in > api.Command, there are no topology-specific commands. The full list of > commands currently exported through the API is attached I do not think the topology API itself was committed to master, yet. Martin From ofayans at redhat.com Fri May 29 10:06:02 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 29 May 2015 12:06:02 +0200 Subject: [Freeipa-devel] topology + domainlevels + testing In-Reply-To: <5568392D.3060303@redhat.com> References: <55683146.4090400@redhat.com> <5568392D.3060303@redhat.com> Message-ID: <55683A0A.6070704@redhat.com> Examples are 1. http://www.freeipa.org/page/V4/Manage_replication_topology http://www.freeipa.org/page/Www.freeipa.org/page/V4/replication_topology/Test_plan 2. http://www.freeipa.org/page/V4/User_Life-Cycle_Management http://www.freeipa.org/page/V4/User_Life-Cycle_Management/Test_Plan On 05/29/2015 12:02 PM, Martin Kosek wrote: > On 05/29/2015 11:28 AM, Oleg Fayans wrote: >> Hi all, >> >> Is there already a separate testplan for Domain Levels feature? If not, >> should I probably take care of domainlevel-specific testcases in the >> scope of the Topology testplan, since these features are closely >> correlated right now? >> >> Another question: I think it could be a nice idea to have a special >> field in the wiki header of design pages displaying the link to the >> corresponding testplan page (somewhere between "Ticket" and "Target >> version", for example). WDYT? > > Good idea. I can add that. Please give me some example of such > "couple" (design, test case) so that I can test it. > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From ofayans at redhat.com Fri May 29 10:06:51 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 29 May 2015 12:06:51 +0200 Subject: [Freeipa-devel] topology* commands not exported through ipalib.api.Command In-Reply-To: <556839EB.5010708@redhat.com> References: <55683911.5010307@redhat.com> <556839EB.5010708@redhat.com> Message-ID: <55683A3B.10005@redhat.com> Hi Martin, Thanks for the clarification! On 05/29/2015 12:05 PM, Martin Kosek wrote: > On 05/29/2015 12:01 PM, Oleg Fayans wrote: >> Hi Ludwig, >> >> Should topology plugin export it's commands through ipalib.api? >> Currently when I import ipalib.api and inspect available commands in >> api.Command, there are no topology-specific commands. The full list of >> commands currently exported through the API is attached > > I do not think the topology API itself was committed to master, yet. > > Martin -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mkosek at redhat.com Fri May 29 10:07:39 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 29 May 2015 12:07:39 +0200 Subject: [Freeipa-devel] topology* commands not exported through ipalib.api.Command In-Reply-To: <55683A3B.10005@redhat.com> References: <55683911.5010307@redhat.com> <556839EB.5010708@redhat.com> <55683A3B.10005@redhat.com> Message-ID: <55683A6B.7030403@redhat.com> On 05/29/2015 12:06 PM, Oleg Fayans wrote: > Hi Martin, > > Thanks for the clarification! > > On 05/29/2015 12:05 PM, Martin Kosek wrote: >> On 05/29/2015 12:01 PM, Oleg Fayans wrote: >>> Hi Ludwig, >>> >>> Should topology plugin export it's commands through ipalib.api? >>> Currently when I import ipalib.api and inspect available commands in >>> api.Command, there are no topology-specific commands. The full list of >>> commands currently exported through the API is attached >> >> I do not think the topology API itself was committed to master, yet. >> >> Martin > I would suggest checking with Petr Vobornik, he should have the latest CLI&UI implementation. From mkosek at redhat.com Fri May 29 10:10:24 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 29 May 2015 12:10:24 +0200 Subject: [Freeipa-devel] #4905: [RFE] Allow Kerberos authentication for users with certificates on smart cards (pkinit) In-Reply-To: <20150529092605.GE3943@p.redhat.com> References: <55682591.1020907@redhat.com> <20150529092605.GE3943@p.redhat.com> Message-ID: <55683B10.6020207@redhat.com> On 05/29/2015 11:26 AM, Sumit Bose wrote: > On Fri, May 29, 2015 at 10:38:41AM +0200, Martin Kosek wrote: >> Hello all, >> >> I would like to discuss the scope needed for ticket 4905 [1]. This is mostly >> question for Sumit as he is working on the SSSD SC support. The main minimal >> target is to allow SSSD get a ticket for a user once he authenticates with >> his SC with certificates tracked in FreeIPA as agreed in [2]. >> >> Sumit, Simo or others, what changes are required in order to do this? In >> [1], I so far identified: >> >> * Support of Smart Cards in SSSD (?upstream ticket) >> * API/CLI for configuring the trusted CA certificate in KDC (related - #616) >> >> as the base. What else is needed? Any krb5.conf changes on the >> server/clients? Or even generating the certs/keys as mentioned in [3]? > > currently I would say krb5.conf both on IPA clients and servers already > have all the needed entries. Doesn't FreeIPA KDC need a list of CAs issuing the Smart Cards that it can trust? >> In current code base, we still have the disabled pkinit plugin [4], but I >> assume this is not what we want. > > I think this is only for anonymous pkinit. The general pkinit preauth > plugin is automatically available as long as the krb5-pkinit package is > installed. The package contains both client and server side of the > plugin, so it must be available on IPA clients and servers. Ok. This can be added to Requires, that's a simple change. >> Thanks for help and advise. Based on what is found out in this thread, we >> will see what's realistic for FreeIPA 4.2 or FreeIPA 4.2.x. > > My understanding is that the current version of the MIT Kerberos pkinit > plugin needs a id-pkinit-san entry in the Subject Alternatives Names of > the certificate with the Kerberos principal of the given user. > > I think it would be good to add this entry to user certificates IPA > generates on its own. The pkinit RFC 4556 mentioned that the KDC can do > the mapping between the certificate and the user principal on its own. Can SSSD aid the mapping anyhow? It will know what is the user principal, based on FreeIPA special mapping. > But given that afaik there is currently no support for this scheme in > the MIT pkinit plugin and hence it would require enhancements in the MIT > code and maybe in the IPA KDB backend as well I think the support for > certificates without a id-pkinit-san entry is out-of-scope for 4.2. I see. > Nevertheless client side authentication would still work only the user > will not have a valid Kerberos TGT after logging in. > > HTH > > bye, > Sumit > >> >> [1] https://fedorahosted.org/freeipa/ticket/4905 >> [2] http://www.freeipa.org/page/V4/User_Certificates >> [3] https://fedorahosted.org/freeipa/ticket/55#comment:3 >> [4] https://git.fedorahosted.org/cgit/freeipa.git/tree/ipalib/plugins/pkinit.py >> >> -- >> Martin Kosek >> Supervisor, Software Engineering - Identity Management Team >> Red Hat Inc. From mkosek at redhat.com Fri May 29 10:20:57 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 29 May 2015 12:20:57 +0200 Subject: [Freeipa-devel] topology + domainlevels + testing In-Reply-To: <55683A0A.6070704@redhat.com> References: <55683146.4090400@redhat.com> <5568392D.3060303@redhat.com> <55683A0A.6070704@redhat.com> Message-ID: <55683D89.8020009@redhat.com> Done - I updated the template - there is new "test_plan" attribute. On 05/29/2015 12:06 PM, Oleg Fayans wrote: > Examples are > 1. > http://www.freeipa.org/page/V4/Manage_replication_topology > http://www.freeipa.org/page/Www.freeipa.org/page/V4/replication_topology/Test_plan I had to move that page to proper location, I do not know why there was "freeipa.org" in it. http://www.freeipa.org/page/V4/Manage_replication_topology > 2. > http://www.freeipa.org/page/V4/User_Life-Cycle_Management > http://www.freeipa.org/page/V4/User_Life-Cycle_Management/Test_Plan Updated too. Martin > On 05/29/2015 12:02 PM, Martin Kosek wrote: >> On 05/29/2015 11:28 AM, Oleg Fayans wrote: >>> Hi all, >>> >>> Is there already a separate testplan for Domain Levels feature? If not, >>> should I probably take care of domainlevel-specific testcases in the >>> scope of the Topology testplan, since these features are closely >>> correlated right now? >>> >>> Another question: I think it could be a nice idea to have a special >>> field in the wiki header of design pages displaying the link to the >>> corresponding testplan page (somewhere between "Ticket" and "Target >>> version", for example). WDYT? >> >> Good idea. I can add that. Please give me some example of such >> "couple" (design, test case) so that I can test it. From ofayans at redhat.com Fri May 29 10:22:17 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 29 May 2015 12:22:17 +0200 Subject: [Freeipa-devel] topology + domainlevels + testing In-Reply-To: <55683D89.8020009@redhat.com> References: <55683146.4090400@redhat.com> <5568392D.3060303@redhat.com> <55683A0A.6070704@redhat.com> <55683D89.8020009@redhat.com> Message-ID: <55683DD9.9060509@redhat.com> Thank you! On 05/29/2015 12:20 PM, Martin Kosek wrote: > Done - I updated the template - there is new "test_plan" attribute. > > On 05/29/2015 12:06 PM, Oleg Fayans wrote: >> Examples are >> 1. >> http://www.freeipa.org/page/V4/Manage_replication_topology >> http://www.freeipa.org/page/Www.freeipa.org/page/V4/replication_topology/Test_plan >> > > I had to move that page to proper location, I do not know why there > was "freeipa.org" in it. > > http://www.freeipa.org/page/V4/Manage_replication_topology > >> 2. >> http://www.freeipa.org/page/V4/User_Life-Cycle_Management >> http://www.freeipa.org/page/V4/User_Life-Cycle_Management/Test_Plan > > Updated too. > > Martin > >> On 05/29/2015 12:02 PM, Martin Kosek wrote: >>> On 05/29/2015 11:28 AM, Oleg Fayans wrote: >>>> Hi all, >>>> >>>> Is there already a separate testplan for Domain Levels feature? If >>>> not, >>>> should I probably take care of domainlevel-specific testcases in the >>>> scope of the Topology testplan, since these features are closely >>>> correlated right now? >>>> >>>> Another question: I think it could be a nice idea to have a special >>>> field in the wiki header of design pages displaying the link to the >>>> corresponding testplan page (somewhere between "Ticket" and "Target >>>> version", for example). WDYT? >>> >>> Good idea. I can add that. Please give me some example of such >>> "couple" (design, test case) so that I can test it. > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From sbose at redhat.com Fri May 29 10:33:22 2015 From: sbose at redhat.com (Sumit Bose) Date: Fri, 29 May 2015 12:33:22 +0200 Subject: [Freeipa-devel] #4905: [RFE] Allow Kerberos authentication for users with certificates on smart cards (pkinit) In-Reply-To: <55683B10.6020207@redhat.com> References: <55682591.1020907@redhat.com> <20150529092605.GE3943@p.redhat.com> <55683B10.6020207@redhat.com> Message-ID: <20150529103322.GG3943@p.redhat.com> On Fri, May 29, 2015 at 12:10:24PM +0200, Martin Kosek wrote: > On 05/29/2015 11:26 AM, Sumit Bose wrote: > >On Fri, May 29, 2015 at 10:38:41AM +0200, Martin Kosek wrote: > >>Hello all, > >> > >>I would like to discuss the scope needed for ticket 4905 [1]. This is mostly > >>question for Sumit as he is working on the SSSD SC support. The main minimal > >>target is to allow SSSD get a ticket for a user once he authenticates with > >>his SC with certificates tracked in FreeIPA as agreed in [2]. > >> > >>Sumit, Simo or others, what changes are required in order to do this? In > >>[1], I so far identified: > >> > >>* Support of Smart Cards in SSSD (?upstream ticket) > >>* API/CLI for configuring the trusted CA certificate in KDC (related - #616) > >> > >>as the base. What else is needed? Any krb5.conf changes on the > >>server/clients? Or even generating the certs/keys as mentioned in [3]? > > > >currently I would say krb5.conf both on IPA clients and servers already > >have all the needed entries. > > Doesn't FreeIPA KDC need a list of CAs issuing the Smart Cards that it can trust? in general yes. If there are certificate which are not created by the IPA CA and have the id-pkinit-san entry we currently would need a pkinit_anchors in krb5.conf pointing to the CA cert. But I guess this should go into the documentation because the cert of the other CA might not be available at installation time. Since we have to touch the Kerberos pkinit code anyway to support certificates without the id-pkinit-san entry we might add other ways to make the CA cert available, e.g. by storing it at some place in the directory tree. > > >>In current code base, we still have the disabled pkinit plugin [4], but I > >>assume this is not what we want. > > > >I think this is only for anonymous pkinit. The general pkinit preauth > >plugin is automatically available as long as the krb5-pkinit package is > >installed. The package contains both client and server side of the > >plugin, so it must be available on IPA clients and servers. > > Ok. This can be added to Requires, that's a simple change. > > >>Thanks for help and advise. Based on what is found out in this thread, we > >>will see what's realistic for FreeIPA 4.2 or FreeIPA 4.2.x. > > > >My understanding is that the current version of the MIT Kerberos pkinit > >plugin needs a id-pkinit-san entry in the Subject Alternatives Names of > >the certificate with the Kerberos principal of the given user. > > > >I think it would be good to add this entry to user certificates IPA > >generates on its own. The pkinit RFC 4556 mentioned that the KDC can do > >the mapping between the certificate and the user principal on its own. > > Can SSSD aid the mapping anyhow? It will know what is the user principal, > based on FreeIPA special mapping. Sure, as soon as the 'Certificate Identity Mapping' is specified I can implement the lookups in SSSD which do not require that the certificate is stored in the directory tree. We have to determine what would be the best way for the KDC/pkinit plugin to access SSSD for this. Currently only InfoPipe/D-BUS supports certificate lookups which might not be the best choice here. HTH bye, Sumit > > >But given that afaik there is currently no support for this scheme in > >the MIT pkinit plugin and hence it would require enhancements in the MIT > >code and maybe in the IPA KDB backend as well I think the support for > >certificates without a id-pkinit-san entry is out-of-scope for 4.2. > > I see. > > >Nevertheless client side authentication would still work only the user > >will not have a valid Kerberos TGT after logging in. > > > >HTH > > > >bye, > >Sumit > > > >> > >>[1] https://fedorahosted.org/freeipa/ticket/4905 > >>[2] http://www.freeipa.org/page/V4/User_Certificates > >>[3] https://fedorahosted.org/freeipa/ticket/55#comment:3 > >>[4] https://git.fedorahosted.org/cgit/freeipa.git/tree/ipalib/plugins/pkinit.py > >> > >>-- > >>Martin Kosek > >>Supervisor, Software Engineering - Identity Management Team > >>Red Hat Inc. > From mkosek at redhat.com Fri May 29 10:54:13 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 29 May 2015 12:54:13 +0200 Subject: [Freeipa-devel] #4905: [RFE] Allow Kerberos authentication for users with certificates on smart cards (pkinit) In-Reply-To: <20150529103322.GG3943@p.redhat.com> References: <55682591.1020907@redhat.com> <20150529092605.GE3943@p.redhat.com> <55683B10.6020207@redhat.com> <20150529103322.GG3943@p.redhat.com> Message-ID: <55684555.2060602@redhat.com> On 05/29/2015 12:33 PM, Sumit Bose wrote: > On Fri, May 29, 2015 at 12:10:24PM +0200, Martin Kosek wrote: >> On 05/29/2015 11:26 AM, Sumit Bose wrote: >>> On Fri, May 29, 2015 at 10:38:41AM +0200, Martin Kosek wrote: >>>> Hello all, >>>> >>>> I would like to discuss the scope needed for ticket 4905 [1]. This is mostly >>>> question for Sumit as he is working on the SSSD SC support. The main minimal >>>> target is to allow SSSD get a ticket for a user once he authenticates with >>>> his SC with certificates tracked in FreeIPA as agreed in [2]. >>>> >>>> Sumit, Simo or others, what changes are required in order to do this? In >>>> [1], I so far identified: >>>> >>>> * Support of Smart Cards in SSSD (?upstream ticket) >>>> * API/CLI for configuring the trusted CA certificate in KDC (related - #616) >>>> >>>> as the base. What else is needed? Any krb5.conf changes on the >>>> server/clients? Or even generating the certs/keys as mentioned in [3]? >>> >>> currently I would say krb5.conf both on IPA clients and servers already >>> have all the needed entries. >> >> Doesn't FreeIPA KDC need a list of CAs issuing the Smart Cards that it can trust? > > in general yes. If there are certificate which are not created by the > IPA CA and have the id-pkinit-san entry we currently would need a > pkinit_anchors in krb5.conf pointing to the CA cert. This would need to be set on all IPA masters or the clients too? Would it be possible to update our KDC driver to tell KDC what is the location of these certs or anyhow feed it with the certs when they are available? > But I guess this > should go into the documentation because the cert of the other CA might > not be available at installation time. Right, it wouldn't be. We would need to have an API to add/remove those external CA certificates. > > Since we have to touch the Kerberos pkinit code anyway to support > certificates without the id-pkinit-san entry we might add other ways to > make the CA cert available, e.g. by storing it at some place in the > directory tree. Would the id-pkinit-san entry be needed if we implement the client lookup within SSSD? > >> >>>> In current code base, we still have the disabled pkinit plugin [4], but I >>>> assume this is not what we want. >>> >>> I think this is only for anonymous pkinit. The general pkinit preauth >>> plugin is automatically available as long as the krb5-pkinit package is >>> installed. The package contains both client and server side of the >>> plugin, so it must be available on IPA clients and servers. >> >> Ok. This can be added to Requires, that's a simple change. >> >>>> Thanks for help and advise. Based on what is found out in this thread, we >>>> will see what's realistic for FreeIPA 4.2 or FreeIPA 4.2.x. >>> >>> My understanding is that the current version of the MIT Kerberos pkinit >>> plugin needs a id-pkinit-san entry in the Subject Alternatives Names of >>> the certificate with the Kerberos principal of the given user. >>> >>> I think it would be good to add this entry to user certificates IPA >>> generates on its own. The pkinit RFC 4556 mentioned that the KDC can do >>> the mapping between the certificate and the user principal on its own. >> >> Can SSSD aid the mapping anyhow? It will know what is the user principal, >> based on FreeIPA special mapping. > > Sure, as soon as the 'Certificate Identity Mapping' is specified I can > implement the lookups in SSSD which do not require that the certificate > is stored in the directory tree. We have to determine what would be the > best way for the KDC/pkinit plugin to access SSSD for this. Currently > only InfoPipe/D-BUS supports certificate lookups which might not be the > best choice here. I see, thanks. In any case what you wrote above does seem as something post 4.2. > > HTH > > bye, > Sumit > >> >>> But given that afaik there is currently no support for this scheme in >>> the MIT pkinit plugin and hence it would require enhancements in the MIT >>> code and maybe in the IPA KDB backend as well I think the support for >>> certificates without a id-pkinit-san entry is out-of-scope for 4.2. >> >> I see. >> >>> Nevertheless client side authentication would still work only the user >>> will not have a valid Kerberos TGT after logging in. >>> >>> HTH >>> >>> bye, >>> Sumit >>> >>>> >>>> [1] https://fedorahosted.org/freeipa/ticket/4905 >>>> [2] http://www.freeipa.org/page/V4/User_Certificates >>>> [3] https://fedorahosted.org/freeipa/ticket/55#comment:3 >>>> [4] https://git.fedorahosted.org/cgit/freeipa.git/tree/ipalib/plugins/pkinit.py >>>> >>>> -- >>>> Martin Kosek >>>> Supervisor, Software Engineering - Identity Management Team >>>> Red Hat Inc. >> From mkosek at redhat.com Fri May 29 11:03:46 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 29 May 2015 13:03:46 +0200 Subject: [Freeipa-devel] [PATCHES 0001-0013 v5] Profiles and CA ACLs In-Reply-To: <55682FB0.1030807@redhat.com> References: <20150520055636.GF12806@dhcp-40-8.bne.redhat.com> <555C30FE.4030707@redhat.com> <20150520144106.GH12806@dhcp-40-8.bne.redhat.com> <555DCC96.2050001@redhat.com> <555DD031.8070302@redhat.com> <555DD39C.3070103@redhat.com> <20150526155930.GI13469@dhcp-40-8.bne.redhat.com> <20150527140434.GD24915@dhcp-40-8.bne.redhat.com> <5566E484.7080809@redhat.com> <55670D4D.9080302@redhat.com> <20150529041754.GE23523@dhcp-40-8.bne.redhat.com> <55682FB0.1030807@redhat.com> Message-ID: <55684792.3070006@redhat.com> 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 at 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 From mkosek at redhat.com Fri May 29 11:05:11 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 29 May 2015 13:05:11 +0200 Subject: [Freeipa-devel] [PATCH 429] replica-install: Allow install on top of already configured client In-Reply-To: <5567199D.7010100@redhat.com> References: <555CA7E7.6050808@redhat.com> <55649609.2020203@redhat.com> <5567199D.7010100@redhat.com> Message-ID: <556847E7.7090805@redhat.com> On 05/28/2015 03:35 PM, Jan Cholasta wrote: > Dne 26.5.2015 v 17:49 Jan Cholasta napsal(a): >> Dne 20.5.2015 v 17:27 Jan Cholasta napsal(a): >>> Hi, >>> >>> the attached patch implements the initial bits for >>> . >>> >>> Test by running ipa-client-install and then ipa-replica-install on the >>> same host. >> >> Updated patch attached. > > Another update, patch attached. AFAIK, the patch is good. But as I discussed with guys offline, I would not push this patch to FreeIPA 4.2 unless we are certain that the whole replica promotion (with Custodia related work) is complete and pushed - replica promotion without custodia integration does not have much value. This may mean postponing the work to 4.3, I am aware of that. From mkubik at redhat.com Fri May 29 12:20:31 2015 From: mkubik at redhat.com (Milan Kubik) Date: Fri, 29 May 2015 14:20:31 +0200 Subject: [Freeipa-devel] Fix password changes via kadmin In-Reply-To: <5565D9D3.6000105@redhat.com> References: <1428274413.19641.118.camel@willson.usersys.redhat.com> <5562E1FA.3050001@redhat.com> <5565C5E6.9060005@redhat.com> <1432734430.3243.118.camel@willson.usersys.redhat.com> <20150527135516.GQ19176@redhat.com> <5565D5CF.9000108@redhat.com> <5565D9D3.6000105@redhat.com> Message-ID: <5568598F.10008@redhat.com> On 05/27/2015 04:50 PM, Martin Babinsky wrote: > On 05/27/2015 04:33 PM, Martin Kosek wrote: >> On 05/27/2015 03:55 PM, Alexander Bokovoy wrote: >>> On Wed, 27 May 2015, Simo Sorce wrote: >>>> On Wed, 2015-05-27 at 15:25 +0200, Martin Babinsky wrote: >>>>> On 05/25/2015 10:48 AM, Martin Babinsky wrote: >>>>>> On 04/06/2015 12:53 AM, Simo Sorce wrote: >>>>>>> Fix for bug 4914. >>>>>>> >>>>>>> I've tested it locally and seem to do exactly what is needed. I >>>>>>> couldn't >>>>>>> detect any side effects, except that if you use kadmin to get a >>>>>>> randomized password for a service then you'll get a key for all >>>>>>> supported types (currently aes256, aes128, des3, rc4, camellia128, >>>>>>> camellia256) instead of just the default ones (aes256, aes128, >>>>>>> des3, >>>>>>> rc4) if you do not specify enctypes. I think that is fine, we use >>>>>>> ipa-getkeytab anyway in the normal course of business and that >>>>>>> one uses >>>>>>> a different code path. >>>>>>> >>>>>>> Simo. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> Hi Simo, >>>>>> >>>>>> the patch works as expected. >>>>>> >>>>>> My only gripe is with the duplicate code in >>>>>> 'daemons/ipa-kdb/ipa_kdb.c' >>>>>> between lines 389 and 455. It could be made into a single >>>>>> function to >>>>>> get key encoding/salt types from LDAP (see my feeble and untested >>>>>> attempt which I attached). >>>>>> >>>>>> >>>>>> >>>>> ACK. >>>>> >>>>> I will then send the patch fixing duplicate code separately once I >>>>> consult it with somebody more skilled in C than myself. >>>>> >>>> >>>> Thanks, added your reviewed-by and pushed to master. >>>> >>>> Martin, should we push this to other branches too ? >>> I think we also need this in 4.1 so that it can go to Fedora, Debian, >>> and RHEL releases. >> >> 4.2 will be released soon, but if you are confident about the patch >> so that it >> does not break stuff, we may add it to 4.1.x too, given the positive >> impact. >> > I actually tested it also with 4.1 branch with no problem. > Hello, there is actually a problem with this patch. I built it on both branches (to be sure) and the patch causes the ipa-server-install fail during the provisioning of directory server keytab [1] on *Fedora 21*. The failure is reproducible. Martin was able to reproduce it on F21. Apparently Martin only tested the patch on F22 where it doesn't cause any (immediately visible) problems. [1]: http://paste.fedoraproject.org/226915/90153914/ Milan From sbose at redhat.com Fri May 29 13:08:21 2015 From: sbose at redhat.com (Sumit Bose) Date: Fri, 29 May 2015 15:08:21 +0200 Subject: [Freeipa-devel] #4905: [RFE] Allow Kerberos authentication for users with certificates on smart cards (pkinit) In-Reply-To: <55684555.2060602@redhat.com> References: <55682591.1020907@redhat.com> <20150529092605.GE3943@p.redhat.com> <55683B10.6020207@redhat.com> <20150529103322.GG3943@p.redhat.com> <55684555.2060602@redhat.com> Message-ID: <20150529130821.GI3943@p.redhat.com> On Fri, May 29, 2015 at 12:54:13PM +0200, Martin Kosek wrote: > On 05/29/2015 12:33 PM, Sumit Bose wrote: > >On Fri, May 29, 2015 at 12:10:24PM +0200, Martin Kosek wrote: > >>On 05/29/2015 11:26 AM, Sumit Bose wrote: > >>>On Fri, May 29, 2015 at 10:38:41AM +0200, Martin Kosek wrote: > >>>>Hello all, > >>>> > >>>>I would like to discuss the scope needed for ticket 4905 [1]. This is mostly > >>>>question for Sumit as he is working on the SSSD SC support. The main minimal > >>>>target is to allow SSSD get a ticket for a user once he authenticates with > >>>>his SC with certificates tracked in FreeIPA as agreed in [2]. > >>>> > >>>>Sumit, Simo or others, what changes are required in order to do this? In > >>>>[1], I so far identified: > >>>> > >>>>* Support of Smart Cards in SSSD (?upstream ticket) > >>>>* API/CLI for configuring the trusted CA certificate in KDC (related - #616) > >>>> > >>>>as the base. What else is needed? Any krb5.conf changes on the > >>>>server/clients? Or even generating the certs/keys as mentioned in [3]? > >>> > >>>currently I would say krb5.conf both on IPA clients and servers already > >>>have all the needed entries. > >> > >>Doesn't FreeIPA KDC need a list of CAs issuing the Smart Cards that it can trust? > > > >in general yes. If there are certificate which are not created by the > >IPA CA and have the id-pkinit-san entry we currently would need a > >pkinit_anchors in krb5.conf pointing to the CA cert. > > This would need to be set on all IPA masters or the clients too? Would it be > possible to update our KDC driver to tell KDC what is the location of these > certs or anyhow feed it with the certs when they are available? After reading the man pages again it looks that pkinit_anchors is only needed to validate the certificate of the KDC itself. As long as this is issued by the IPA CA all should be fine. The user certificates are checked by the pkinit plugin via OpenSSL with the help of the CA certs that are accessible to OpenSSL. So if the user certificate is signed by a CA which is currently not known it has to be distributed to all hosts. But I checked the IPA install code as well and realized that there is 'options.setup_pkinit = False' in ipa-server-install. I will check at the beginning of next week if this can be removed. > > >But I guess this > >should go into the documentation because the cert of the other CA might > >not be available at installation time. > > Right, it wouldn't be. We would need to have an API to add/remove those > external CA certificates. > > > > >Since we have to touch the Kerberos pkinit code anyway to support > >certificates without the id-pkinit-san entry we might add other ways to > >make the CA cert available, e.g. by storing it at some place in the > >directory tree. > > Would the id-pkinit-san entry be needed if we implement the client lookup > within SSSD? no > > > > >> > >>>>In current code base, we still have the disabled pkinit plugin [4], but I > >>>>assume this is not what we want. > >>> > >>>I think this is only for anonymous pkinit. The general pkinit preauth > >>>plugin is automatically available as long as the krb5-pkinit package is > >>>installed. The package contains both client and server side of the > >>>plugin, so it must be available on IPA clients and servers. > >> > >>Ok. This can be added to Requires, that's a simple change. > >> > >>>>Thanks for help and advise. Based on what is found out in this thread, we > >>>>will see what's realistic for FreeIPA 4.2 or FreeIPA 4.2.x. > >>> > >>>My understanding is that the current version of the MIT Kerberos pkinit > >>>plugin needs a id-pkinit-san entry in the Subject Alternatives Names of > >>>the certificate with the Kerberos principal of the given user. > >>> > >>>I think it would be good to add this entry to user certificates IPA > >>>generates on its own. The pkinit RFC 4556 mentioned that the KDC can do > >>>the mapping between the certificate and the user principal on its own. > >> > >>Can SSSD aid the mapping anyhow? It will know what is the user principal, > >>based on FreeIPA special mapping. > > > >Sure, as soon as the 'Certificate Identity Mapping' is specified I can > >implement the lookups in SSSD which do not require that the certificate > >is stored in the directory tree. We have to determine what would be the > >best way for the KDC/pkinit plugin to access SSSD for this. Currently > >only InfoPipe/D-BUS supports certificate lookups which might not be the > >best choice here. > > I see, thanks. In any case what you wrote above does seem as something post 4.2. yes. My plan would be to add everything what is needed to make SSSD work with what is already available in MIT Kerberos first and then try to enhance the pkinit plugin. bye, Sumit > > > > >HTH > > > >bye, > >Sumit > > > >> > >>>But given that afaik there is currently no support for this scheme in > >>>the MIT pkinit plugin and hence it would require enhancements in the MIT > >>>code and maybe in the IPA KDB backend as well I think the support for > >>>certificates without a id-pkinit-san entry is out-of-scope for 4.2. > >> > >>I see. > >> > >>>Nevertheless client side authentication would still work only the user > >>>will not have a valid Kerberos TGT after logging in. > >>> > >>>HTH > >>> > >>>bye, > >>>Sumit > >>> > >>>> > >>>>[1] https://fedorahosted.org/freeipa/ticket/4905 > >>>>[2] http://www.freeipa.org/page/V4/User_Certificates > >>>>[3] https://fedorahosted.org/freeipa/ticket/55#comment:3 > >>>>[4] https://git.fedorahosted.org/cgit/freeipa.git/tree/ipalib/plugins/pkinit.py > >>>> > >>>>-- > >>>>Martin Kosek > >>>>Supervisor, Software Engineering - Identity Management Team > >>>>Red Hat Inc. > >> > From simo at redhat.com Fri May 29 13:30:34 2015 From: simo at redhat.com (Simo Sorce) Date: Fri, 29 May 2015 09:30:34 -0400 Subject: [Freeipa-devel] Fix password changes via kadmin In-Reply-To: <5568598F.10008@redhat.com> References: <1428274413.19641.118.camel@willson.usersys.redhat.com> <5562E1FA.3050001@redhat.com> <5565C5E6.9060005@redhat.com> <1432734430.3243.118.camel@willson.usersys.redhat.com> <20150527135516.GQ19176@redhat.com> <5565D5CF.9000108@redhat.com> <5565D9D3.6000105@redhat.com> <5568598F.10008@redhat.com> Message-ID: <1432906234.19096.217.camel@willson.usersys.redhat.com> On Fri, 2015-05-29 at 14:20 +0200, Milan Kubik wrote: > On 05/27/2015 04:50 PM, Martin Babinsky wrote: > > On 05/27/2015 04:33 PM, Martin Kosek wrote: > >> On 05/27/2015 03:55 PM, Alexander Bokovoy wrote: > >>> On Wed, 27 May 2015, Simo Sorce wrote: > >>>> On Wed, 2015-05-27 at 15:25 +0200, Martin Babinsky wrote: > >>>>> On 05/25/2015 10:48 AM, Martin Babinsky wrote: > >>>>>> On 04/06/2015 12:53 AM, Simo Sorce wrote: > >>>>>>> Fix for bug 4914. > >>>>>>> > >>>>>>> I've tested it locally and seem to do exactly what is needed. I > >>>>>>> couldn't > >>>>>>> detect any side effects, except that if you use kadmin to get a > >>>>>>> randomized password for a service then you'll get a key for all > >>>>>>> supported types (currently aes256, aes128, des3, rc4, camellia128, > >>>>>>> camellia256) instead of just the default ones (aes256, aes128, > >>>>>>> des3, > >>>>>>> rc4) if you do not specify enctypes. I think that is fine, we use > >>>>>>> ipa-getkeytab anyway in the normal course of business and that > >>>>>>> one uses > >>>>>>> a different code path. > >>>>>>> > >>>>>>> Simo. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> Hi Simo, > >>>>>> > >>>>>> the patch works as expected. > >>>>>> > >>>>>> My only gripe is with the duplicate code in > >>>>>> 'daemons/ipa-kdb/ipa_kdb.c' > >>>>>> between lines 389 and 455. It could be made into a single > >>>>>> function to > >>>>>> get key encoding/salt types from LDAP (see my feeble and untested > >>>>>> attempt which I attached). > >>>>>> > >>>>>> > >>>>>> > >>>>> ACK. > >>>>> > >>>>> I will then send the patch fixing duplicate code separately once I > >>>>> consult it with somebody more skilled in C than myself. > >>>>> > >>>> > >>>> Thanks, added your reviewed-by and pushed to master. > >>>> > >>>> Martin, should we push this to other branches too ? > >>> I think we also need this in 4.1 so that it can go to Fedora, Debian, > >>> and RHEL releases. > >> > >> 4.2 will be released soon, but if you are confident about the patch > >> so that it > >> does not break stuff, we may add it to 4.1.x too, given the positive > >> impact. > >> > > I actually tested it also with 4.1 branch with no problem. > > > Hello, > > there is actually a problem with this patch. > > I built it on both branches (to be sure) and the patch causes the > ipa-server-install fail during the provisioning of directory server > keytab [1] on *Fedora 21*. > The failure is reproducible. Martin was able to reproduce it on F21. > Apparently Martin only tested the patch on F22 where it doesn't cause > any (immediately visible) problems. > > [1]: http://paste.fedoraproject.org/226915/90153914/ Thanks for specifying it happens only on F21, I have been testing on F22 too and couldn't reproduce. I will try to take a look ASAP. Simo. -- Simo Sorce * Red Hat, Inc * New York From lkrispen at redhat.com Fri May 29 14:44:12 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 29 May 2015 16:44:12 +0200 Subject: [Freeipa-devel] [PATCH 0007] replica install fails with domain level 1 Message-ID: <55687B3C.4070303@redhat.com> This is a patch for the two issues reported in ticket #5035 https://fedorahosted.org/freeipa/ticket/5035 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-lkrispen-0007-replica-install-fails-with-domain-level-1.patch Type: text/x-patch Size: 3025 bytes Desc: not available URL: From cheimes at redhat.com Fri May 29 14:54:27 2015 From: cheimes at redhat.com (Christian Heimes) Date: Fri, 29 May 2015 16:54:27 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Provide Kerberos over HTTP (MS-KKDCP) In-Reply-To: <5565C3AF.1070509@redhat.com> References: <5565C3AF.1070509@redhat.com> Message-ID: <55687DA3.5090501@redhat.com> Changes since patch 1: - Further simplify krb ticket code Simo has pointed out that KRB5_CLIENT_KTNAME and MEMORY ccache are sufficient for the GSSAPI. http://k5wiki.kerberos.org/wiki/Projects/Keytab_initiation - switch is now in ipaConfigString=kdcProxyEnabled of cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc - add service principal KDCPROXY - add own keytab /etc/ipa/kdcproxy/kdcproxy.keytab - add permission 'System: Read IPA Masters KDC Proxy' - add privilege 'IPA Masters KDC Proxy Readers' - add ipa-ldap-updater scripts to enable/disable KDC Proxy - Create a separate user and group account The KDC Proxy WSGI app now uses a separate user account to run the daemon process. The keytab is only readable by that user, too. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-cheimes-0001-2-Provide-Kerberos-over-HTTP-MS-KKDCP.patch Type: text/x-patch Size: 48305 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From simo at redhat.com Fri May 29 15:27:28 2015 From: simo at redhat.com (Simo Sorce) Date: Fri, 29 May 2015 11:27:28 -0400 Subject: [Freeipa-devel] [PATCH] Fixup fix for 4914 Message-ID: <1432913248.19096.222.camel@willson.usersys.redhat.com> The patches for ticket 4914 worked fine on Fedora 22 (and in general any system that was updated to krb5 1.13) however they fail in Fedora 21 and similar because of a bug in one of the libkrb5 functions used in the new code. The bug is fixed in 1.13 but not in older versions as it causes side effects in kadmin output. The attached patch takes care of using a replacement function if we detect at runtime that the library in use does not have the fixes present in 1.13. This allows us the freedom to backport or not the 1.13 fix. Unfortunately I am running out of time today so I could not test it, but I still wanted to put it out there to get this fixed asap. Milan, or Martin, can you please test it ? Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-523-1-Add-compatibility-function-for-older-libkrb5.patch Type: text/x-patch Size: 3649 bytes Desc: not available URL: From abokovoy at redhat.com Fri May 29 15:59:20 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 29 May 2015 18:59:20 +0300 Subject: [Freeipa-devel] [PATCH] Fixup fix for 4914 In-Reply-To: <1432913248.19096.222.camel@willson.usersys.redhat.com> References: <1432913248.19096.222.camel@willson.usersys.redhat.com> Message-ID: <20150529155920.GK19176@redhat.com> On Fri, 29 May 2015, Simo Sorce wrote: >The patches for ticket 4914 worked fine on Fedora 22 (and in general any >system that was updated to krb5 1.13) however they fail in Fedora 21 and >similar because of a bug in one of the libkrb5 functions used in the new >code. The bug is fixed in 1.13 but not in older versions as it causes >side effects in kadmin output. > >The attached patch takes care of using a replacement function if we >detect at runtime that the library in use does not have the fixes >present in 1.13. This allows us the freedom to backport or not the 1.13 >fix. > >Unfortunately I am running out of time today so I could not test it, but >I still wanted to put it out there to get this fixed asap. > >Milan, or Martin, can you please test it ? > >Simo. > >-- >Simo Sorce * Red Hat, Inc * New York >>From ea7811f7d11b68a34dc357d0e0dcb7d81c7f65c8 Mon Sep 17 00:00:00 2001 >From: Simo Sorce >Date: Fri, 29 May 2015 11:18:17 -0400 >Subject: [PATCH] Add compatibility function for older libkrb5 > >Before krb5 1.13 the krb5_salttype_to_string() function was returning >incorrect names (display names of some kind instead of the names >used by the rest of the library to map saltname to the salt type >integer number). >This patch adds a function that checks at runtime if we have a working >function and uses a fallback map updated to the salt types known up >to 1.12, this allows us to use the library provided function in >following releases where new salt types may emerge. > >Signed-off-by: Simo Sorce >--- > util/ipa_krb5.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 60 insertions(+), 1 deletion(-) > >diff --git a/util/ipa_krb5.c b/util/ipa_krb5.c >index 65e10dd401edf6b54988fc4bfa5a2e08789b7b75..d6992c561830ff682ede3a156ad9efbfff701432 100644 >--- a/util/ipa_krb5.c >+++ b/util/ipa_krb5.c >@@ -1075,6 +1075,65 @@ int create_keys(krb5_context krbctx, > return nkeys; > } > >+/* in older versions of libkrb5 the krb5_salttype_to_string() function is >+ * faulty and returns strings that do not match the expected format. >+ * Later version of krb5 were fixed to return the proper string. >+ * Do lazy detection the first time the function is invoked to determine >+ * if we can use the library provided function or if we have to use a >+ * fallback map which includes the salt types known up to krb5 1.12 (the >+ * fault is fixed upstream in 1.13). */ >+static int ipa_salttype_to_string(krb5_int32 salttype, >+ char *buffer, size_t buflen) >+{ >+ static int faulty_function = -1; >+ >+ static const struct { >+ krb5_int32 salttype; >+ const char *name; >+ } fallback_map[] = { >+ { KRB5_KDB_SALTTYPE_NORMAL, "normal" }, >+ { KRB5_KDB_SALTTYPE_V4, "v4" }, >+ { KRB5_KDB_SALTTYPE_NOREALM, "norealm" }, >+ { KRB5_KDB_SALTTYPE_ONLYREALM, "onlyrealm" }, >+ { KRB5_KDB_SALTTYPE_SPECIAL, "speacial" }, There is a typo in 'special' in the KRB5_KDB_SALTTYPE_SPECIAL entry. It needs to be fixed before we get this ACKed. >+ { KRB5_KDB_SALTTYPE_AFS3, "afs3" }, >+ { -1, NULL } >+ }; >+ >+ if (faulty_function == -1) { >+ /* haven't checked yet, let's find out */ >+ char testbuf[100]; >+ size_t len = 100; >+ int ret; >+ >+ ret = krb5_salttype_to_string(KRB5_KDB_SALTTYPE_NORMAL, testbuf, len); >+ if (ret) return ret; >+ >+ if (strcmp(buffer, "normal") == 0) { >+ faulty_function = 0; >+ } else { >+ faulty_function = 1; >+ } >+ } >+ >+ if (faulty_function == 0) { >+ return krb5_salttype_to_string(salttype, buffer, buflen); >+ } else { >+ size_t len; >+ int i; >+ for (i = 0; fallback_map[i].name != NULL; i++) { >+ if (salttype == fallback_map[i].salttype) break; >+ } >+ if (fallback_map[i].name == NULL) return EINVAL; >+ >+ len = strlen(fallback_map[i].name); >+ if (len >= buflen) return ENOMEM; >+ >+ memcpy(buffer, fallback_map[i].name, len + 1); >+ return 0; >+ } >+} >+ > int ipa_kstuples_to_string(krb5_key_salt_tuple *kst, int n_kst, char **str) > { > char *buf = NULL; >@@ -1130,7 +1189,7 @@ int ipa_kstuples_to_string(krb5_key_salt_tuple *kst, int n_kst, char **str) > buf[buf_cur + len] = ':'; > len++; > >- ret = krb5_salttype_to_string(kst[i].ks_salttype, >+ ret = ipa_salttype_to_string(kst[i].ks_salttype, > &buf[buf_cur + len], buf_avail - len); > if (ret == ENOMEM) { > i--; >-- >2.4.1 > >-- >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 -- / Alexander Bokovoy From simo at redhat.com Fri May 29 16:01:50 2015 From: simo at redhat.com (Simo Sorce) Date: Fri, 29 May 2015 12:01:50 -0400 Subject: [Freeipa-devel] [PATCH] Fixup fix for 4914 In-Reply-To: <20150529155920.GK19176@redhat.com> References: <1432913248.19096.222.camel@willson.usersys.redhat.com> <20150529155920.GK19176@redhat.com> Message-ID: <1432915310.19096.223.camel@willson.usersys.redhat.com> On Fri, 2015-05-29 at 18:59 +0300, Alexander Bokovoy wrote: > On Fri, 29 May 2015, Simo Sorce wrote: > >The patches for ticket 4914 worked fine on Fedora 22 (and in general any > >system that was updated to krb5 1.13) however they fail in Fedora 21 and > >similar because of a bug in one of the libkrb5 functions used in the new > >code. The bug is fixed in 1.13 but not in older versions as it causes > >side effects in kadmin output. > > > >The attached patch takes care of using a replacement function if we > >detect at runtime that the library in use does not have the fixes > >present in 1.13. This allows us the freedom to backport or not the 1.13 > >fix. > > > >Unfortunately I am running out of time today so I could not test it, but > >I still wanted to put it out there to get this fixed asap. > > > >Milan, or Martin, can you please test it ? > > > >Simo. > > > >-- > >Simo Sorce * Red Hat, Inc * New York > > >>From ea7811f7d11b68a34dc357d0e0dcb7d81c7f65c8 Mon Sep 17 00:00:00 2001 > >From: Simo Sorce > >Date: Fri, 29 May 2015 11:18:17 -0400 > >Subject: [PATCH] Add compatibility function for older libkrb5 > > > >Before krb5 1.13 the krb5_salttype_to_string() function was returning > >incorrect names (display names of some kind instead of the names > >used by the rest of the library to map saltname to the salt type > >integer number). > >This patch adds a function that checks at runtime if we have a working > >function and uses a fallback map updated to the salt types known up > >to 1.12, this allows us to use the library provided function in > >following releases where new salt types may emerge. > > > >Signed-off-by: Simo Sorce > >--- > > util/ipa_krb5.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++- > > 1 file changed, 60 insertions(+), 1 deletion(-) > > > >diff --git a/util/ipa_krb5.c b/util/ipa_krb5.c > >index 65e10dd401edf6b54988fc4bfa5a2e08789b7b75..d6992c561830ff682ede3a156ad9efbfff701432 100644 > >--- a/util/ipa_krb5.c > >+++ b/util/ipa_krb5.c > >@@ -1075,6 +1075,65 @@ int create_keys(krb5_context krbctx, > > return nkeys; > > } > > > >+/* in older versions of libkrb5 the krb5_salttype_to_string() function is > >+ * faulty and returns strings that do not match the expected format. > >+ * Later version of krb5 were fixed to return the proper string. > >+ * Do lazy detection the first time the function is invoked to determine > >+ * if we can use the library provided function or if we have to use a > >+ * fallback map which includes the salt types known up to krb5 1.12 (the > >+ * fault is fixed upstream in 1.13). */ > >+static int ipa_salttype_to_string(krb5_int32 salttype, > >+ char *buffer, size_t buflen) > >+{ > >+ static int faulty_function = -1; > >+ > >+ static const struct { > >+ krb5_int32 salttype; > >+ const char *name; > >+ } fallback_map[] = { > >+ { KRB5_KDB_SALTTYPE_NORMAL, "normal" }, > >+ { KRB5_KDB_SALTTYPE_V4, "v4" }, > >+ { KRB5_KDB_SALTTYPE_NOREALM, "norealm" }, > >+ { KRB5_KDB_SALTTYPE_ONLYREALM, "onlyrealm" }, > >+ { KRB5_KDB_SALTTYPE_SPECIAL, "speacial" }, > There is a typo in 'special' in the KRB5_KDB_SALTTYPE_SPECIAL entry. > > It needs to be fixed before we get this ACKed. Sigh, and I re-read the list 3 times because this was the most obvious error I could do ... the only consolation is that testing would have failed immediately. Thanks a lot! I'll send a new patch in minutes Simo. > >+ { KRB5_KDB_SALTTYPE_AFS3, "afs3" }, > >+ { -1, NULL } > >+ }; > >+ > >+ if (faulty_function == -1) { > >+ /* haven't checked yet, let's find out */ > >+ char testbuf[100]; > >+ size_t len = 100; > >+ int ret; > >+ > >+ ret = krb5_salttype_to_string(KRB5_KDB_SALTTYPE_NORMAL, testbuf, len); > >+ if (ret) return ret; > >+ > >+ if (strcmp(buffer, "normal") == 0) { > >+ faulty_function = 0; > >+ } else { > >+ faulty_function = 1; > >+ } > >+ } > >+ > >+ if (faulty_function == 0) { > >+ return krb5_salttype_to_string(salttype, buffer, buflen); > >+ } else { > >+ size_t len; > >+ int i; > >+ for (i = 0; fallback_map[i].name != NULL; i++) { > >+ if (salttype == fallback_map[i].salttype) break; > >+ } > >+ if (fallback_map[i].name == NULL) return EINVAL; > >+ > >+ len = strlen(fallback_map[i].name); > >+ if (len >= buflen) return ENOMEM; > >+ > >+ memcpy(buffer, fallback_map[i].name, len + 1); > >+ return 0; > >+ } > >+} > >+ > > int ipa_kstuples_to_string(krb5_key_salt_tuple *kst, int n_kst, char **str) > > { > > char *buf = NULL; > >@@ -1130,7 +1189,7 @@ int ipa_kstuples_to_string(krb5_key_salt_tuple *kst, int n_kst, char **str) > > buf[buf_cur + len] = ':'; > > len++; > > > >- ret = krb5_salttype_to_string(kst[i].ks_salttype, > >+ ret = ipa_salttype_to_string(kst[i].ks_salttype, > > &buf[buf_cur + len], buf_avail - len); > > if (ret == ENOMEM) { > > i--; > >-- > >2.4.1 > > > > >-- > >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 > > -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri May 29 16:03:34 2015 From: simo at redhat.com (Simo Sorce) Date: Fri, 29 May 2015 12:03:34 -0400 Subject: [Freeipa-devel] [PATCH] Fixup fix for 4914 In-Reply-To: <1432915310.19096.223.camel@willson.usersys.redhat.com> References: <1432913248.19096.222.camel@willson.usersys.redhat.com> <20150529155920.GK19176@redhat.com> <1432915310.19096.223.camel@willson.usersys.redhat.com> Message-ID: <1432915414.19096.224.camel@willson.usersys.redhat.com> New patch attached. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-523-2-Add-compatibility-function-for-older-libkrb5.patch Type: text/x-patch Size: 3648 bytes Desc: not available URL: From mkubik at redhat.com Fri May 29 20:08:39 2015 From: mkubik at redhat.com (Milan Kubik) Date: Fri, 29 May 2015 22:08:39 +0200 Subject: [Freeipa-devel] [PATCH] Fixup fix for 4914 In-Reply-To: <1432915414.19096.224.camel@willson.usersys.redhat.com> References: <1432913248.19096.222.camel@willson.usersys.redhat.com> <20150529155920.GK19176@redhat.com> <1432915310.19096.223.camel@willson.usersys.redhat.com> <1432915414.19096.224.camel@willson.usersys.redhat.com> Message-ID: <5568C747.7060808@redhat.com> On 05/29/2015 06:03 PM, Simo Sorce wrote: > New patch attached. > > Simo. > > > > Hi, thanks for the quick fix. With the patch applied, the server was able to install. ACK Thanks, Milan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Fri May 29 21:23:43 2015 From: ayoung at redhat.com (Adam Young) Date: Fri, 29 May 2015 17:23:43 -0400 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <5566A7AD.6050205@redhat.com> References: <555F03DB.3090702@redhat.com> <556493D3.8010402@redhat.com> <55659335.2060306@redhat.com> <20150527095322.GM19176@redhat.com> <55659571.8070705@redhat.com> <5565AB70.7020004@redhat.com> <5565ABCF.5090305@redhat.com> <5565B10F.1090802@redhat.com> <1432734188.3243.117.camel@willson.usersys.redhat.com> <5565CAF3.9020903@redhat.com> <1432734660.3354.53.camel@redhat.com> <5566A7AD.6050205@redhat.com> Message-ID: <5568D8DF.7080602@redhat.com> On 05/28/2015 01:29 AM, Jan Cholasta wrote: > Dne 27.5.2015 v 15:51 Nathaniel McCallum napsal(a): >> On Wed, 2015-05-27 at 15:47 +0200, Jan Cholasta wrote: >>> Dne 27.5.2015 v 15:43 Simo Sorce napsal(a): >>>> On Wed, 2015-05-27 at 13:57 +0200, Jan Cholasta wrote: >>>>>>> >>>>>>> ipa config-mod --enable-kdcproxy=TRUE >>>>>>> ipa config-mod --enable-kdcproxy=FALSE >>>>> >>>>> I don't like this approach, as it is completely inconsistent with >>>>> every >>>>> other optional component. There should be *one* way to handle >>>>> them >>>>> and >>>>> there already is one, no need to reinvent the wheel. >>>> >>>> Sorry Jan, but this is really the correct approach. >>> >>> I don't think so. >>> >>>> >>>> We want a boolean in LDAP to control whether the IPA Domain allows >>>> proxying or not, the code is embedded in the overall framework and >>>> has >>>> no need for explicit install/uninstall unlike the CA or DNS >>>> components. >>> >>> There is a boolean for every other component/service as well. If you >>> want to add new API to manipulate the boolean, fine, but it should be >>> >>> done in a generic way that works for other components as well. >> >> As I understand the problem, there is an assumption that an optional >> component has a distinct service to start and stop. That is not the >> case here. This is just new config for apache. >> >> Nathaniel >> > > I say that's a wrong assumption. It should not matter whether the > service is provided by an actual daemon, or a set of daemons or no > daemon, as that is an implementation detail. By installing KDC proxy > on IPA server an actual new service is provided to the outside world, > which is conceptually the same as adding DNS or CA, so I don't see why > it should be handled differently. > Depends on if you consider it a different service from Kerberos. It is just a different protocol, and in the HTTP world would have been handled by a content type. That said, I could see the argument that the proxy is designed primarily to run in the DMZ, not where the IPA server is normally deployed, and the setup of the proxy really should be considered an architectual design decision. Deploying it on the same host as the IPA server doesn't really serve the main use case. From simo at redhat.com Sat May 30 14:39:10 2015 From: simo at redhat.com (Simo Sorce) Date: Sat, 30 May 2015 10:39:10 -0400 Subject: [Freeipa-devel] Kerberos over HTTPS (KDC proxy) In-Reply-To: <5568D8DF.7080602@redhat.com> References: <555F03DB.3090702@redhat.com> <556493D3.8010402@redhat.com> <55659335.2060306@redhat.com> <20150527095322.GM19176@redhat.com> <55659571.8070705@redhat.com> <5565AB70.7020004@redhat.com> <5565ABCF.5090305@redhat.com> <5565B10F.1090802@redhat.com> <1432734188.3243.117.camel@willson.usersys.redhat.com> <5565CAF3.9020903@redhat.com> <1432734660.3354.53.camel@redhat.com> <5566A7AD.6050205@redhat.com> <5568D8DF.7080602@redhat.com> Message-ID: <1432996750.19096.234.camel@willson.usersys.redhat.com> On Fri, 2015-05-29 at 17:23 -0400, Adam Young wrote: > On 05/28/2015 01:29 AM, Jan Cholasta wrote: > > Dne 27.5.2015 v 15:51 Nathaniel McCallum napsal(a): > >> On Wed, 2015-05-27 at 15:47 +0200, Jan Cholasta wrote: > >>> Dne 27.5.2015 v 15:43 Simo Sorce napsal(a): > >>>> On Wed, 2015-05-27 at 13:57 +0200, Jan Cholasta wrote: > >>>>>>> > >>>>>>> ipa config-mod --enable-kdcproxy=TRUE > >>>>>>> ipa config-mod --enable-kdcproxy=FALSE > >>>>> > >>>>> I don't like this approach, as it is completely inconsistent with > >>>>> every > >>>>> other optional component. There should be *one* way to handle > >>>>> them > >>>>> and > >>>>> there already is one, no need to reinvent the wheel. > >>>> > >>>> Sorry Jan, but this is really the correct approach. > >>> > >>> I don't think so. > >>> > >>>> > >>>> We want a boolean in LDAP to control whether the IPA Domain allows > >>>> proxying or not, the code is embedded in the overall framework and > >>>> has > >>>> no need for explicit install/uninstall unlike the CA or DNS > >>>> components. > >>> > >>> There is a boolean for every other component/service as well. If you > >>> want to add new API to manipulate the boolean, fine, but it should be > >>> > >>> done in a generic way that works for other components as well. > >> > >> As I understand the problem, there is an assumption that an optional > >> component has a distinct service to start and stop. That is not the > >> case here. This is just new config for apache. > >> > >> Nathaniel > >> > > > > I say that's a wrong assumption. It should not matter whether the > > service is provided by an actual daemon, or a set of daemons or no > > daemon, as that is an implementation detail. By installing KDC proxy > > on IPA server an actual new service is provided to the outside world, > > which is conceptually the same as adding DNS or CA, so I don't see why > > it should be handled differently. > > > > Depends on if you consider it a different service from Kerberos. It is > just a different protocol, and in the HTTP world would have been handled > by a content type. > > That said, I could see the argument that the proxy is designed primarily > to run in the DMZ, not where the IPA server is normally deployed, and > the setup of the proxy really should be considered an architectual > design decision. Deploying it on the same host as the IPA server > doesn't really serve the main use case. It really depends on how you define the main use case which is really dependent on the deployment. For example, in some deployments MS-KKDCP can be used as a privacy enhancing tool and always used instead of TCP/UDP as the HTTPS channel will prevent an observer from seeing fields that are normally plain text in the raw kerberos protocol, like principal names. So I wouldn't characterize this transport as DMZ-only, and wouldn't assume there is only one use case. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Sat May 30 16:26:49 2015 From: simo at redhat.com (Simo Sorce) Date: Sat, 30 May 2015 12:26:49 -0400 Subject: [Freeipa-devel] [PATCH] Fixup fix for 4914 In-Reply-To: <5568C747.7060808@redhat.com> References: <1432913248.19096.222.camel@willson.usersys.redhat.com> <20150529155920.GK19176@redhat.com> <1432915310.19096.223.camel@willson.usersys.redhat.com> <1432915414.19096.224.camel@willson.usersys.redhat.com> <5568C747.7060808@redhat.com> Message-ID: <1433003209.19096.235.camel@willson.usersys.redhat.com> On Fri, 2015-05-29 at 22:08 +0200, Milan Kubik wrote: > On 05/29/2015 06:03 PM, Simo Sorce wrote: > > New patch attached. > > > > Simo. > > > > > > > > > Hi, > > thanks for the quick fix. With the patch applied, the server was able to > install. > > ACK Thanks, Pushed to master and ipa-4-1 Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Sun May 31 02:07:48 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Sat, 30 May 2015 22:07:48 -0400 Subject: [Freeipa-devel] [PATCH] 1112 Add service constraint delegation plugin In-Reply-To: <5566D11B.3070505@redhat.com> References: <555B4696.2070502@redhat.com> <555BA115.5070408@redhat.com> <555CB00B.3080309@redhat.com> <5565F29B.7000507@redhat.com> <5565FE97.6040202@redhat.com> <55660A2D.1080801@redhat.com> <5566D11B.3070505@redhat.com> Message-ID: <556A6CF4.5010603@redhat.com> Petr Vobornik wrote: > On 05/27/2015 08:17 PM, Martin Basti wrote: >> On 27/05/15 19:27, Rob Crittenden wrote: >>> Martin Basti wrote: >>>>> >>>> Thank you. >>>> >>>> I haven't finished review yet, but I have few notes in case you will >>>> modify the patch. >>>> >>>> Please fix following issues: >>>> >>> >>>> 3) >>>> There are many PEP8 errors, can you fix some of them,? >>> >>> Is PEP8 a concern? What kinds of errors do we fix? For example, the >>> current model for defining options generates a slew of indention errors. > > In old modules it's preferred to keep the old indentation style for > options(not to mix 2 styles). New modules should use following pep8 > compliant style: > Str( > 'cn', > cli_name='name', > primary_key=True, > label=_('Server name'), > doc=_('IPA server hostname'), > ), > >> We try to keep PEP8 in new code, mainly indentation, blank lines, too >> long lines. >> Yes in test definitions and option definitions, is better to keep the >> same style, but other parts of code should be PEP8. >> >> For example these should be fixed >> ./ipatests/test_xmlrpc/test_serviceconstraint_plugin.py:37:13: E225 >> missing whitespace around operator >> ./ipatests/test_xmlrpc/test_serviceconstraint_plugin.py:39:1: E302 >> expected 2 blank lines, found 1 >> ./ipatests/test_xmlrpc/test_serviceconstraint_plugin.py:42:1: E302 >> expected 2 blank lines, found 1 >> >>> >>> >>> I'll wait and see what falls out of the API review before making any >>> real changes. >>> >>> rob Updated API and addressed Martin's concerns. The regex must have been a bad copy/paste, it is fixed now. The design page has been updated as well. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1112-4-Add-plugin-to-manage-service-constraint-delegations.patch Type: text/x-diff Size: 57212 bytes Desc: not available URL: