Re: [Freeipa-devel] [PATCHES] 0197-0204 Installing without a CA, with custom SSL certs
On 03/21/2013 05:39 PM, Petr Viktorin wrote:
[...]
another thing: When drafting the feature page, I realized the
--{http,dirsrv}_pin options are unfortunate. Giving the passwords in command
line options is unsafe.
I'd like to replace them with --{http,dirsrv}-pin-file, with prompting if
they're not given.
How is that different from -p DM_PASSWORD and -a ADMIN_PASSWORD? They also
cannot be read from file. I think these options would cause inconsistency with
the rest of our password options in ipa-{server,client,replica}-install. It
also seems as inconvenience to me as you need to prepare this artificial file
before running ipa-server-install...
I think it would be better to address this consistently in the future with
configuration file instead of options, something like pkispawn uses.
Martin
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNS update mechanism: news about update authorization
On 1.3.2013 16:15, Petr Spacek wrote: On 1.3.2013 15:39, Simo Sorce wrote: On Fri, 2013-03-01 at 15:29 +0100, Petr Spacek wrote: Hello list, we would like to share some news about DNS update mechanism: - It is possible to allow particular principal to update all records in a zone. - It is possible to allow clients to update own PTR records. PTR update can be authenticated and authorized by source IP address of the TCP connection from the client. E.g. client with IP address 192.0.2.31 is able to modify only PTR record with name 31.0.2.192.in-addr.arpa., nothing else. See examples in following how-to: http://freeipa.org/page/Dynamic_updates_with_GSS-TSIG#Dynamic_update_policy Simo pointed to fact that TCP authenticated update requests can be more secure than current approach with PTR synchronization magic (done inside bind-dyndb-ldap). Unfortunately, it is not possible to combine TCP authentication with GSS-TSIG signature. BIND's ACL check mechanism stops at first match, so it is not possible to combine multiple requirements. 'tcp-self' rule ignores request signature completely. Implementation of (TCP signed) requirement will require patching BIND. I don't like that idea, because we will deviate from plain BIND docs and it will cause confusion. We can propose a change and send patches to ISC. It should be possible to implement new 'tcp-signed-self' mechanism with only few lines of code. The question is how it should behave: Is *any* signature enough? I.e. anybody with valid Kerberos ticket is allowed to do tcp-self update? Should be at least a host/ principal, otherwise a mere user could change the PTR record, would be even better if we can match the fqdn int the host/ principal to the content of the PTR record. So if you sign with principal for host/foo.bar.baz and come from 10.11.22.33 then you can only create a PTR record of 10.11.22.33 - foo.bar.baz Should we implement configurable realm check? I.e. the update will be allowed only if the update is signed by principal from specified Kerberos realm? This too would be nice but not as important. How it should work with Kerberos trusts? You would prevent principals from a trusted domain to update DNS entries. Checking for the REALM part should be optional. Also, it should be possible to implement more strict check: Updated name in reverse zone (e.g. 31.0.2.192.in-addr.arpa.) has to match client's IP address and *at the same time* name stored to PTR record has to match name in client's principal. Example: - client's IP address: 192.0.2.31 - client's principal: host/client.example@trusted.example.com Yeah I should have read the whole message trough before starting replying :-) This particular client is allowed only to add record: 31.0.2.192.in-addr.arpa. IN PTR client.example.com. Question is how to authorize record deletion. I tend to allow all delete operations for (reverse) name matching client's IP address. Yes this would be ok, worst case the PTR is lost. Again I would allow only by principals of the type host/* or maybe DNS/* not from every principal. I agree. We could imitate krb5-self semantics: Service part is hardcoded to 'host/' and REALM part is configurable: 'grant IPA.EXAMPLE.COM tcp-krb5-self;' Variant for AD machines: 'grant AD.EXAMPLE.COM tcp-ms-self;' AD variant will match names machine$@AD.EXAMPLE.COM. News from ISC: Evan Hunt replied that ISC can include our patches with this functionality. I created ticket covering this task: https://fedorahosted.org/bind-dyndb-ldap/ticket/112 -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0127] Remove orphaned function declaration from ldap_helper.h
Hello, Remove orphaned function declaration from ldap_helper.h. -- Petr^2 Spacek From 9129f3963c8a7d603c02c5a8ea1ce3f08182541f Mon Sep 17 00:00:00 2001 From: Petr Spacek pspa...@redhat.com Date: Fri, 22 Mar 2013 13:04:29 +0100 Subject: [PATCH] Remove orphaned function declaration from ldap_helper.h. Signed-off-by: Petr Spacek pspa...@redhat.com --- src/ldap_helper.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/src/ldap_helper.h b/src/ldap_helper.h index fe54687fa1e8ec16d83105e08e1a17cdec68614e..2eb7c7600f45542d92f01dbc878f4862606ade8a 100644 --- a/src/ldap_helper.h +++ b/src/ldap_helper.h @@ -94,9 +94,6 @@ isc_result_t write_to_ldap(dns_name_t *owner, ldap_instance_t *ldap_inst, isc_result_t remove_from_ldap(dns_name_t *owner, ldap_instance_t *ldap_inst, dns_rdatalist_t *rdlist, isc_boolean_t delete_node); -/* Get cache associated with ldap_inst */ -ldap_cache_t *ldap_instance_getcache(ldap_instance_t *ldap_inst); - settings_set_t * ldap_instance_getsettings_local(ldap_instance_t *ldap_inst); #endif /* !_LD_LDAP_HELPER_H_ */ -- 1.7.11.7 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [RFE] CA-less install
The design page for CA-less installation with user-provided SSL certs is available at http://freeipa.org/page/V3/CA-less_install. I've also copied it to this mail. Does it answer all your questions? -- Petr³ __NOTOC__ = Overview = IPA will support installing without an embedded Certificate Authority, with user-provided SSL certificates for the HTTP and Directory servers. = Use Cases = # User installs IPA using the --http_pkcs, --dirsrv_pkcs, --http_pin, --dirsrv_pin, --root-ca-file options, giving appropriate certificates. # IPA installs and works normally, excluding the certificate management operaions # User creates a replica using --http_pkcs, --dirsrv_pkcs, --http_pin, --dirsrv_pin options to ipa-replica-prepare # Replica works normally, excluding certificate management operaions = Design= To install without a CA, the following options must be provided to ipa-server-install: * --http_pkcs: a PKCS#12 file containing the HTTP server certificate * --dirsrv_pkcs: a PKCS#12 file containing the Directory server certificate * --http_pin: password for the file given in --http_pkcs * --dirsrv_pin: password for the file given in --dirsrv_pkcs * --root-ca-file: a PEM file containing the root CA certificate Each of the PKCS#12 files must contain exactly one certificate with a private key. This will be used as the server certificate. It must also contain certificates of any intermediate CAs. It may contain any number of other certificates without matching private keys. The two PKCS#12 files may (and often will) be the same. The certificates must be valid as server certs for the given host. The PEM file given by --root-ca-file must contain exactly one certificate. This cert will be trusted as a root CA on the IPA server and all clients. Both server certs must be signed by this CA (possibly via a trust chain). It will be available in tt/etc/ipa/ca.crt/tt and in the cACertificate attribute of cn=CACert,cn=ipa,cn=etc,$SUFFIX in LDAP, just like the IPA CA cert in Dogtag-based installations. These options are incompatible with --external-ca. To install a replica, following options must be provided to ipa-replica-prepare: * --http_pkcs * --dirsrv_pkcs * --http_pin * --dirsrv_pin The root CA is taken from the existing master. All apply as in the ipa-server-install case. == Why --root-ca-file? == IPA requires the user to specify the root CA to be trusted. This done to ensure that all replicas and clients trust the IPA certificates, no matter what their initial configuration is. Theoretically the CA certificate could be extracted from PKCS#12 files, but to ensure transparency and the administrator's control when it comes to trusting a root CA, it must always be specified explicitly. In the future it might be possible to trust more than one CA in this way. = Certificate management FAQ = == How to check what format files are? == Use the handy ttfile/tt command. PEM files show up as such: $ file /etc/ipa/ca.crt /etc/ipa/ca.crt: PEM certificate PKCS#12 files show up as just data: $ file dirsrv.p12 dirsrv.p12: data To check a PKCS#12 file, you need to know the password: $ pk12util -l dirsrv.p12 Enter password for PKCS12 file: Certificate(has private key): ... Certificate: ... Key(shrouded): ... == How many certs are there in a file? == For PKCS#12 files, use ttpk12util -l/tt (see previous section). For PEM files, simply open the file in a pager or text editor and count the number of blocks. A certificate will look like this: $ cat /etc/ipa/ca.crt -BEGIN CERTIFICATE- MIIDuzCCAqOgAwIBAgIBATANBgkqhkiG9w0BAQsFADBFMSMwIQYDVQQKExpJRE0u TEFCLkVORy5CUlEuUkVESEFULkNPTTEeMBwGA1UEAxMVQ2VydGlmaWNhdGUgQXV0 aG9yaXR5MB4XDTEzMDMyMDE3MDQxNFoXDTMzMDMyMDE3MDQxNFowRTEjMCEGA1UE ChMaSURNLkxBQi5FTkcuQlJRLlJFREhBVC5DT00xHjAcBgNVBAMTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZi pF9Dz5O1rVTRnwIdttHl0sKpHeRqzi/S7bnAFh3Jb2UxzFmHTpgQFKqq72mYatpL O0BPc47IGh9gwGZNLcEaNCf7zYCbqBJso8RV6SxbHSEdo+JuSYhMxVasKQcojqeY /wx11A4NSQAco6mBZz255llZqMQcJVMW4T8aioUd19Yh35CM9vr6l6dgUnvA9fAF TOl144yfF8AjvF1hIAePjLyl+Y/xxh1U2j5hF4z7ZeUGHKVZR9pQ62kbM7TgAR6Y YLGpis44JPfgRVkDGEkc7Vzpct1D4Iz7/oGMV+0kbJbz+9DSIHWY10QTtf9mNQNn xKGa3wCf5u8ctfmms8cCAwEAAaOBtTCBsjAfBgNVHSMEGDAWgBQCHF1DVeHg3kUG VRm/j0f9eji6nzAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBxjAdBgNV HQ4EFgQUAhxdQ1Xh4N5FBlUZv49H/Xo4up8wTwYIKwYBBQUHAQEEQzBBMD8GCCsG AQUFBzABhjNodHRwOi8vdm0tMDg0LmlkbS5sYWIuZW5nLmJycS5yZWRoYXQuY29t OjgwL2NhL29jc3AwDQYJKoZIhvcNAQELBQADggEBAB3+or2Q/aPO4ZMBE4Q6xCMV 09ESAXXT/0DLakAt28ljy1wWKVR3d54TxZJ4DEcYgbxDa1A87DZW8sn+LM4Uwap9 DUyHA0mhBjROe6NXgJQl9aZ7IeE1ht+pw/n+JR2sg3ccYHvQjRcEZj2OPQuavyPn hwokDc3FVarlsQcrtfePG3e8TQXAnpSxV+KAMBEp4yib5nrkNZZoU+nqMI0ftXrk rP5q0SaEBEjC4+AoYje4Bv3+8RKT1kwBMkTL8eRRuWZmKvOy9sCnnFfU4HMMkPTK
Re: [Freeipa-devel] DNS update mechanism: news about update authorization
On Fri, 2013-03-22 at 10:04 +0100, Petr Spacek wrote: News from ISC: Evan Hunt replied that ISC can include our patches with this functionality. I created ticket covering this task: https://fedorahosted.org/bind-dyndb-ldap/ticket/112 Excellent! Thanks a lot. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] CA-less install
On 03/22/2013 08:10 AM, Petr Viktorin wrote: The design page for CA-less installation with user-provided SSL certs is available at http://freeipa.org/page/V3/CA-less_install. I've also copied it to this mail. Does it answer all your questions? Petr, It answers a lot of questions. However isn't the whole goal to be able to use external CA we do not have control of as a part of the trust chain? I might very well confuse things so bear with me. Say I have a public CA X I want to use as the root of my trust chain so that I do not need to distribute certificates to all my clients. I can't create a sub CA using externa-ca because it will cost me a lot of money. But I can create a PKI pair for just two servers (HTTP and DS) much cheaper. Is this the assumption? Is this really how this works? Is it really easy to get a CRS signed by a public CA X? Other comments: what are the implications on the certmonger and cert rotation. I assume certmonger will be turn off. It should then be documented that we will not track or warn about the cert expiration. In future for the KDC pkinit support we will need yet another cert for the KDC, you do nto need to implement it now but please consider this in the design. Page misses you as an author. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] CA-less install
Dmitri Pal wrote: On 03/22/2013 08:10 AM, Petr Viktorin wrote: The design page for CA-less installation with user-provided SSL certs is available at http://freeipa.org/page/V3/CA-less_install. I've also copied it to this mail. Does it answer all your questions? Petr, It answers a lot of questions. However isn't the whole goal to be able to use external CA we do not have control of as a part of the trust chain? I might very well confuse things so bear with me. Say I have a public CA X I want to use as the root of my trust chain so that I do not need to distribute certificates to all my clients. I can't create a sub CA using externa-ca because it will cost me a lot of money. But I can create a PKI pair for just two servers (HTTP and DS) much cheaper. Is this the assumption? Is this really how this works? Is it really easy to get a CRS signed by a public CA X? Yes, it really can be that easy. Most of the requests in this area have involved using wildcard certs which are slightly more complex to get, but you can get free SSL server certs from StartSSL in less than 30 minutes (providing you can prove you manage the domain you're requesting certs for). I imagine that most will use the same cert for both services, rather than getting separate certs. Other comments: what are the implications on the certmonger and cert rotation. I assume certmonger will be turn off. It should then be documented that we will not track or warn about the cert expiration. Right, we won't be able to leverage certmonger. Users will be on their own to handle renewal. In future for the KDC pkinit support we will need yet another cert for the KDC, you do nto need to implement it now but please consider this in the design. This is a grey area. I don't know if the public CAs will issue this kind of cert. A survey would be required to find out. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] CA-less install
On 03/22/2013 01:32 PM, Dmitri Pal wrote: On 03/22/2013 08:10 AM, Petr Viktorin wrote: The design page for CA-less installation with user-provided SSL certs is available at http://freeipa.org/page/V3/CA-less_install. I've also copied it to this mail. Does it answer all your questions? Petr, It answers a lot of questions. However isn't the whole goal to be able to use external CA we do not have control of as a part of the trust chain? I might very well confuse things so bear with me. Say I have a public CA X I want to use as the root of my trust chain so that I do not need to distribute certificates to all my clients. I can't create a sub CA using externa-ca because it will cost me a lot of money. But I can create a PKI pair for just two servers (HTTP and DS) much cheaper. Is this the assumption? Is this really how this works? Is it really easy to get a CRS signed by a public CA X? IMO one case is that there's a single corporate (not necessarily public) CA, with a policy that it will not sign subordinate CA certs, but it can sign server certs? Your case works too. Yes, server CSRs are easier to get signed than CA ones. (Do you mean globally trusted when you say public? With a globally trusted CA you can pretty much impersonate anybody on the Internet.) Someone familiar with certification policies should chime in if you need more details. I've learned a lot about the technical details but policies are another thing. Other comments: what are the implications on the certmonger and cert rotation. I assume certmonger will be turn off. It should then be documented that we will not track or warn about the cert expiration. Yes, Certmonger is not installed, cert rotation must be handled manually. I've udated the page. In future for the KDC pkinit support we will need yet another cert for the KDC, you do nto need to implement it now but please consider this in the design. Added to the page. Page misses you as an author. Added. I've also added an author section to [[Feature template]] so I remember next time. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 270 Load extension.js after UI AMD modules.
On 03/21/2013 04:56 PM, Petr Vobornik wrote: This patch is a fix for upcoming ipa-3-1 minor release. Loading of extension.js was removed with introduction of AMD modules. This patch returns the feature to avoid regressions. In 3.2 it will be handled differently (multiple plugins). ACK, works fine. Pushed to ipa-3-1. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 255 Added Web UI support for service PAC type option: NONE
On 02/08/2013 02:27 PM, Petr Vobornik wrote: Checkbox for NONE option was added. https://fedorahosted.org/freeipa/ticket/3404 Patches for master and 3.1 branch attached. I pushed this version to ipa-3-1 branch only as a hotfix for upcoming 3.1 release so that users can set NONE option via UI. The right solution should be chosen and pushed to master branch. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0128] Fix crash caused by 'zonesub' match-type in update ACL
Hello,
Fix crash caused by 'zonesub' match-type in update ACL.
Next patchset will improve overall error handling in ACL processing.
--
Petr^2 Spacek
From 5f8481da390298a2bc8616abae3b8aca3d432bfe Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Fri, 22 Mar 2013 13:54:39 +0100
Subject: [PATCH] Fix crash caused by 'zonesub' match-type in update ACL.
Signed-off-by: Petr Spacek pspa...@redhat.com
---
src/acl.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/src/acl.c b/src/acl.c
index f95cf431b6363d82085e9cfec7e6c1d6ddd45d7a..f08b7019eaa8c4893c800c4629a1d5fd4223dd0c 100644
--- a/src/acl.c
+++ b/src/acl.c
@@ -208,6 +208,7 @@ get_match_type(const cfg_obj_t *obj)
MATCH(name, DNS_SSUMATCHTYPE_NAME);
MATCH(subdomain, DNS_SSUMATCHTYPE_SUBDOMAIN);
+ MATCH(zonesub, DNS_SSUMATCHTYPE_SUBDOMAIN);
MATCH(wildcard, DNS_SSUMATCHTYPE_WILDCARD);
MATCH(self, DNS_SSUMATCHTYPE_SELF);
#if defined(DNS_SSUMATCHTYPE_SELFSUB) defined(DNS_SSUMATCHTYPE_SELFWILD)
@@ -246,8 +247,16 @@ get_fixed_name(const cfg_obj_t *obj, const char *name, dns_fixedname_t *fname)
REQUIRE(fname != NULL);
+ if (!cfg_obj_istuple(obj)) {
+ log_bug(configuration object is not a tuple);
+ return ISC_R_UNEXPECTED;
+ }
obj = cfg_tuple_get(obj, name);
+
+ if (!cfg_obj_isstring(obj))
+ return ISC_R_NOTFOUND;
str = cfg_obj_asstring(obj);
+
len = strlen(str);
isc_buffer_init(buf, str, len);
@@ -417,7 +426,19 @@ acl_configure_zone_ssutable(const char *policy_str, dns_zone_t *zone)
match_type = get_match_type(stmt);
CHECK(get_fixed_name(stmt, identity, fident));
- CHECK(get_fixed_name(stmt, name, fname));
+
+ /* Use zone name for 'zonesub' match type */
+ result = get_fixed_name(stmt, name, fname);
+ if (result == ISC_R_NOTFOUND
+ match_type == DNS_SSUMATCHTYPE_SUBDOMAIN) {
+ dns_fixedname_init(fname);
+ dns_name_copy(dns_zone_getorigin(zone),
+ dns_fixedname_name(fname),
+ fname.buffer);
+ }
+ else if (result != ISC_R_SUCCESS)
+ goto cleanup;
+
CHECK(get_types(mctx, stmt, types, n));
if (match_type == DNS_SSUMATCHTYPE_WILDCARD
--
1.7.11.7
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 118] [WIP] Add 389 DS plugin for special idnsSOASerial attribute handling
On 03/13/2013 04:50 PM, Martin Kosek wrote: On 03/12/2013 03:38 PM, Petr Spacek wrote: On 12.3.2013 10:40, Martin Kosek wrote: On 03/11/2013 04:58 PM, Petr Spacek wrote: Hello list! My first patch for FreeIPA is attached :-) I managed to add new 389 DS plugin to build system, but the LDAP magic in installer and updater is too much for my brain. Could somebody show me how installer and updater should add new object to cn=config ? Plugin configuration is static (example is in comments in ipa_dns.c). This patch implements minimal necessary support for idnsSOASerial replication. I investigating more advanced techniques, but I still see problems with locking and so on. Anyway, this patch should be sufficient for now. Commit message: Add 389 DS plugin for special idnsSOASerial attribute handling Default value 1 is added to replicated idnsZone objects if idnsSOASerial attribute is missing. https://fedorahosted.org/freeipa/ticket/3347 I did not review the actual plugin yet, I just added a code to configure this plugin during new install and upgrade. Patch attached. Just in daemons/ipa-slapi-plugins/ipa-dns/Makefile.am I noticed some copypaste errors: +libipa_uuid_la_LIBADD = \ libipa_uuid?? +$(LDAP_LIBS)\ +$(UUID_LIBS)\ +$(NULL) + +EXTRA_DIST =\ +$(app_DATA)\not defined, not needed (I will add it in my patch) +$(NULL) + Fixed version is attached. Sending a rebased version of my installer/updater patch. Martin ACK for the DS plugin. My patch 384-2 was acked on IRC by Rob. Pushed both to master, ipa-3-1. Thanks, Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0128] Fix crash caused by 'zonesub' match-type in update ACL
On 22.3.2013 14:26, Petr Spacek wrote:
Hello,
Fix crash caused by 'zonesub' match-type in update ACL.
Next patchset will improve overall error handling in ACL processing.
I forgot to check return value from dns_name_copy(). Fixed patch is attached.
--
Petr^2 Spacek
From a76a7a2899e1e8b4335c012271f607e438ef0218 Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Fri, 22 Mar 2013 13:54:39 +0100
Subject: [PATCH] Fix crash caused by 'zonesub' match-type in update ACL.
Signed-off-by: Petr Spacek pspa...@redhat.com
---
src/acl.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/src/acl.c b/src/acl.c
index f95cf431b6363d82085e9cfec7e6c1d6ddd45d7a..ed3bdebcc027f3f5b7b2e9e084cf328ed4f6b1dd 100644
--- a/src/acl.c
+++ b/src/acl.c
@@ -208,6 +208,7 @@ get_match_type(const cfg_obj_t *obj)
MATCH(name, DNS_SSUMATCHTYPE_NAME);
MATCH(subdomain, DNS_SSUMATCHTYPE_SUBDOMAIN);
+ MATCH(zonesub, DNS_SSUMATCHTYPE_SUBDOMAIN);
MATCH(wildcard, DNS_SSUMATCHTYPE_WILDCARD);
MATCH(self, DNS_SSUMATCHTYPE_SELF);
#if defined(DNS_SSUMATCHTYPE_SELFSUB) defined(DNS_SSUMATCHTYPE_SELFWILD)
@@ -246,8 +247,16 @@ get_fixed_name(const cfg_obj_t *obj, const char *name, dns_fixedname_t *fname)
REQUIRE(fname != NULL);
+ if (!cfg_obj_istuple(obj)) {
+ log_bug(configuration object is not a tuple);
+ return ISC_R_UNEXPECTED;
+ }
obj = cfg_tuple_get(obj, name);
+
+ if (!cfg_obj_isstring(obj))
+ return ISC_R_NOTFOUND;
str = cfg_obj_asstring(obj);
+
len = strlen(str);
isc_buffer_init(buf, str, len);
@@ -417,7 +426,19 @@ acl_configure_zone_ssutable(const char *policy_str, dns_zone_t *zone)
match_type = get_match_type(stmt);
CHECK(get_fixed_name(stmt, identity, fident));
- CHECK(get_fixed_name(stmt, name, fname));
+
+ /* Use zone name for 'zonesub' match type */
+ result = get_fixed_name(stmt, name, fname);
+ if (result == ISC_R_NOTFOUND
+ match_type == DNS_SSUMATCHTYPE_SUBDOMAIN) {
+ dns_fixedname_init(fname);
+ CHECK(dns_name_copy(dns_zone_getorigin(zone),
+ dns_fixedname_name(fname),
+ fname.buffer));
+ }
+ else if (result != ISC_R_SUCCESS)
+ goto cleanup;
+
CHECK(get_types(mctx, stmt, types, n));
if (match_type == DNS_SSUMATCHTYPE_WILDCARD
--
1.7.11.7
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 267 Filter groups by type (normal, posix, external)
On 03/21/2013 06:10 PM, Petr Vobornik wrote:
On 03/21/2013 05:10 PM, Martin Kosek wrote:
On 03/16/2013 03:32 AM, Endi Sukma Dewata wrote:
On 3/12/2013 11:28 AM, Petr Vobornik wrote:
Here's a patch for filtering groups by type.
Design page: http://www.freeipa.org/page/V3/Filtering_groups_by_type
The interface is:
StrEnum('type?',
cli_name='type',
label=_('Type'),
doc=_('Group type'),
values=(u'posix', u'normal', u'external'),
),
I have two design questions.
1. Is --type the right option name?
Fine by me, it matches the label and description.
2. Is `normal` the right name for non-posix, non-external group? The
default group type (when adding group) is posix. Should the name be
something else: `simple`, `plain`, `ordinary`?
We also use 'normal' in the group adder dialog, so it's consistent. Other
options are 'basic', 'standard', 'regular'.
I didn't want to create an option for each type. IMO it brings more
complexity.
Maybe the group-add/mod command should use the same --type option?
https://fedorahosted.org/freeipa/ticket/3483
ACK from me, but maybe others might have some comments.
I am just thinking about if the new API is right. For example, when we add an
external group, we use ipa group-add --external. But when we search for
external groups, we suddenly use
# ipa group-find --type=external
and not
# ipa group-find --external
or
# ipa group-find --nonposix
Wouldn't that cause confusion? I am looking for same second opinion on this
one.
I also did not like normal group type very much, maybe we should just call
it
nonposix? As that's the option you use when you are creating such group:
# ipa group-add --nonposix foo
Otherwise, the patch looks good functionally.
Martin
I have to note that external group is also non-posix. Following command is
valid:
# ipa group-add foo --desc=a --external --nonposix
By that logic
# ipa group-find --nonposix
Would also list external groups.
I fine with renaming 'normal' to something better (will also require Web UI
change), but it is not 'nonposix'.
I think this logic is flawed as well. Then you could say that posix group is
also nonposix, because it contains the same objectclasses as nonpoxis group +
posixGroup objectclass.
nonposix is the term we already use (see --nonposix), not something
artificial or new, so I would not be afraid of it.
Martin
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 396 Fix structured DNS record output
On 03/21/2013 03:01 PM, Martin Kosek wrote: Recent LDAP refactoring replaced entry_attrs regular dict with normalized keys (i.e. lowercase) with LDAPEntry instance which keys may not be normalized. This broke CND command output when --structured and --all options were used. Force lowercase normalization of the LDAPEntry keys in DNS plugin structured format postprocessing. Also add a missing test for DNS record structured output. https://fedorahosted.org/freeipa/ticket/3526 ACK, it works well now. The test is critical to prevent future regressions. The planned DNSEntry type-checking will prevent putting dicts in entries; we may need to use plain dicts for the output. The question will be where to convert them from entries. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0009 Use default NETBIOS name in unattended ipa-adtrust-install
On 03/22/2013 03:03 PM, Tomas Babej wrote: On 03/21/2013 01:58 PM, Ana Krivokapic wrote: Hello, Unattended ipa-adtrust-install used to fail if --netbios option was not provided. This patches fixes this, so that instead of failing the default NETBIOS name is used. https://fedorahosted.org/freeipa/ticket/3497 ACK, works as expected. Tomas Pushed to master, ipa-3-1. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 122 Enable SASL mapping fallback
Hi,
this patch enables SASL mapping fallback in IPA DS instance, see
https://fedorahosted.org/freeipa/ticket/3330. Automated replication
recovery and external user mapping is not part of the patch.
In order to test this, you need 389-ds-base 1.3.1 packages with patches
from https://fedorahosted.org/389/ticket/534 including the last patch,
which is not yet in git.
Honza
--
Jan Cholasta
From 2e16ca6a5c8c60f59bd8cb4e5eb75bb51ca0fa03 Mon Sep 17 00:00:00 2001
From: Jan Cholasta jchol...@redhat.com
Date: Fri, 22 Mar 2013 11:15:51 +0100
Subject: [PATCH] Enable SASL mapping fallback.
Assign a default priority of 10 to our SASL mappings.
https://fedorahosted.org/freeipa/ticket/3330
---
freeipa.spec.in | 8 ++--
install/share/Makefile.am| 1 +
install/share/sasl-mapping-fallback.ldif | 4
install/updates/10-config.update | 10 ++
ipaserver/install/dsinstance.py | 4
ipaserver/install/krbinstance.py | 5 +++--
6 files changed, 28 insertions(+), 4 deletions(-)
create mode 100644 install/share/sasl-mapping-fallback.ldif
diff --git a/freeipa.spec.in b/freeipa.spec.in
index 1a39064..11f1abc 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -19,7 +19,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.0
+BuildRequires: 389-ds-base-devel = 1.3.1
BuildRequires: svrcore-devel
BuildRequires: /usr/share/selinux/devel/Makefile
BuildRequires: policycoreutils = %{POLICYCOREUTILSVER}
@@ -86,7 +86,7 @@ Requires: %{name}-python = %{version}-%{release}
Requires: %{name}-client = %{version}-%{release}
Requires: %{name}-admintools = %{version}-%{release}
Requires: %{name}-server-selinux = %{version}-%{release}
-Requires: 389-ds-base = 1.3.0
+Requires: 389-ds-base = 1.3.1
Requires: openldap-clients
Requires: nss
Requires: nss-tools
@@ -769,6 +769,10 @@ fi
%ghost %attr(0644,root,apache) %config(noreplace) %{_sysconfdir}/ipa/ca.crt
%changelog
+* Fri Mar 22 2013 Jan Cholasta jchol...@redhat.com - 3.0.99-15
+- Bump minimum version of 389-ds-base to 1.3.1 for SASL mapping priority
+ support.
+
* Tue Jan 29 2013 Petr Viktorin pvikt...@redhat.com - 3.0.99-14
- Use ipa-ldap-updater --quiet instead of redirecting to /dev/null
diff --git a/install/share/Makefile.am b/install/share/Makefile.am
index f8f9b74..20bf99f 100644
--- a/install/share/Makefile.am
+++ b/install/share/Makefile.am
@@ -62,6 +62,7 @@ app_DATA =\
replica-s4u2proxy.ldif \
copy-schema-to-ca.py \
upload-cacert.ldif \
+ sasl-mapping-fallback.ldif \
$(NULL)
EXTRA_DIST =\
diff --git a/install/share/sasl-mapping-fallback.ldif b/install/share/sasl-mapping-fallback.ldif
new file mode 100644
index 000..ef7f1cc
--- /dev/null
+++ b/install/share/sasl-mapping-fallback.ldif
@@ -0,0 +1,4 @@
+dn: cn=config
+changetype: modify
+replace: nsslapd-sasl-mapping-fallback
+nsslapd-sasl-mapping-fallback: on
diff --git a/install/updates/10-config.update b/install/updates/10-config.update
index e377689..c631b2c 100644
--- a/install/updates/10-config.update
+++ b/install/updates/10-config.update
@@ -47,3 +47,13 @@ only:nsslapd-minssf-exclude-rootdse:on
# POSIX winsync plugin
dn: cn=ipa-winsync,cn=plugins,cn=config
only: nsslapd-pluginPrecedence: 60
+
+# Enable SASL mapping fallback
+dn: cn=config
+only:nsslapd-sasl-mapping-fallback: on
+
+dn: cn=Full Principal,cn=mapping,cn=sasl,cn=config
+addifnew:nsSaslMapPriority: 10
+
+dn: cn=Name Only,cn=mapping,cn=sasl,cn=config
+addifnew:nsSaslMapPriority: 10
diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py
index c744c9c..02c1e02 100644
--- a/ipaserver/install/dsinstance.py
+++ b/ipaserver/install/dsinstance.py
@@ -211,6 +211,7 @@ class DsInstance(service.Service):
self.step(configuring certmap.conf, self.__certmap_conf)
self.step(configure autobind for root, self.__root_autobind)
self.step(configure new location for managed entries, self.__repoint_managed_entries)
+self.step(enable SASL mapping fallback, self.__enable_sasl_mapping_fallback)
self.step(restarting directory server, self.__restart_instance)
def __common_post_setup(self):
@@ -617,6 +618,9 @@ class DsInstance(service.Service):
def __enable_ldapi(self):
self._ldap_mod(ldapi.ldif, self.sub_dict)
+def __enable_sasl_mapping_fallback(self):
+self._ldap_mod(sasl-mapping-fallback.ldif, self.sub_dict)
+
def add_hbac(self):
self._ldap_mod(default-hbac.ldif, self.sub_dict)
diff --git a/ipaserver/install/krbinstance.py b/ipaserver/install/krbinstance.py
index 51c5427..9a73a5c 100644
--- a/ipaserver/install/krbinstance.py
+++ b/ipaserver/install/krbinstance.py
@@ -280,6 +280,7 @@ class KrbInstance(service.Service):
nsSaslMapRegexString=['\(.*\)@\(.*\)'],
Re: [Freeipa-devel] [PATCH] 396 Fix structured DNS record output
On 03/22/2013 03:04 PM, Petr Viktorin wrote: On 03/21/2013 03:01 PM, Martin Kosek wrote: Recent LDAP refactoring replaced entry_attrs regular dict with normalized keys (i.e. lowercase) with LDAPEntry instance which keys may not be normalized. This broke CND command output when --structured and --all options were used. Force lowercase normalization of the LDAPEntry keys in DNS plugin structured format postprocessing. Also add a missing test for DNS record structured output. https://fedorahosted.org/freeipa/ticket/3526 ACK, it works well now. The test is critical to prevent future regressions. The planned DNSEntry type-checking will prevent putting dicts in entries; we may need to use plain dicts for the output. The question will be where to convert them from entries. Right, this use case adds another level of complexity to this future refactoring. Pushed to master. Thanks, Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0041] Add logging to join command
On 03/13/2013 03:05 PM, Tomas Babej wrote: Hi, The following is mentioned in the server log now: - existence of host entry (if it already does exist) - missing krbprincipalname and its new value (if there was no principal name set) https://fedorahosted.org/freeipa/ticket/3481 Tomas Here is what I get first trying to re-enroll a wiped host first using admin username/password, and then using a saved keytab. The first succeeded, the second didn't. [Fri Mar 22 16:17:14.338411 2013] [:error] [pid 21335] ipa: INFO: Host entry for vm-084.idm.lab.eng.brq.redhat.com already exists [Fri Mar 22 16:17:14.367564 2013] [:error] [pid 21335] ipa: INFO: ad...@idm.lab.eng.brq.redhat.com: join(u'vm-084.idm.lab.eng.brq.redhat.com', nshardwareplatform=u'x86_64', nsosversion=u'3.7.4-204.fc18.x86_64', version=u'2.51'): SUCCESS [Fri Mar 22 16:17:35.395626 2013] [:error] [pid 21336] ipa: INFO: Host entry for vm-084.idm.lab.eng.brq.redhat.com already exists [Fri Mar 22 16:17:35.420830 2013] [:error] [pid 21336] ipa: INFO: host/vm-084.idm.lab.eng.brq.redhat@idm.lab.eng.brq.redhat.com: join(u'vm-084.idm.lab.eng.brq.redhat.com', nshardwareplatform=u'x86_64', nsosversion=u'3.7.4-204.fc18.x86_64', version=u'2.51'): SUCCESS [Fri Mar 22 16:17:38.729304 2013] [:error] [pid 21335] ipa: INFO: host/vm-084.idm.lab.eng.brq.redhat@idm.lab.eng.brq.redhat.com: host_mod(u'vm-084.idm.lab.eng.brq.redhat.com', random=False, ipasshpubkey=([...], [...]), rights=False, updatedns=False, all=False, raw=False, version=u'2.54'): SUCCESS [Fri Mar 22 16:17:41.763080 2013] [:error] [pid 21336] ipa: INFO: host/vm-084.idm.lab.eng.brq.redhat@idm.lab.eng.brq.redhat.com: cert_request([...], principal=u'host/vm-084.idm.lab.eng.brq.redhat@idm.lab.eng.brq.redhat.com', add=True, version=u'2.51'): SUCCESS I can see what's going on, but I don't think the admin would be much wiser seeing this. Would we want so say something like Host entry for X already exists; joining may fail on the client side to explain what's going on? ACK from a technical perspective. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0041] Add logging to join command
On 03/22/2013 04:51 PM, Petr Viktorin wrote: On 03/13/2013 03:05 PM, Tomas Babej wrote: Hi, The following is mentioned in the server log now: - existence of host entry (if it already does exist) - missing krbprincipalname and its new value (if there was no principal name set) https://fedorahosted.org/freeipa/ticket/3481 Tomas Here is what I get first trying to re-enroll a wiped host first using admin username/password, and then using a saved keytab. The first succeeded, the second didn't. Correction: The first failed, the second succeeded. Sorry for the confusion. [Fri Mar 22 16:17:14.338411 2013] [:error] [pid 21335] ipa: INFO: Host entry for vm-084.idm.lab.eng.brq.redhat.com already exists [Fri Mar 22 16:17:14.367564 2013] [:error] [pid 21335] ipa: INFO: ad...@idm.lab.eng.brq.redhat.com: join(u'vm-084.idm.lab.eng.brq.redhat.com', nshardwareplatform=u'x86_64', nsosversion=u'3.7.4-204.fc18.x86_64', version=u'2.51'): SUCCESS [Fri Mar 22 16:17:35.395626 2013] [:error] [pid 21336] ipa: INFO: Host entry for vm-084.idm.lab.eng.brq.redhat.com already exists [Fri Mar 22 16:17:35.420830 2013] [:error] [pid 21336] ipa: INFO: host/vm-084.idm.lab.eng.brq.redhat@idm.lab.eng.brq.redhat.com: join(u'vm-084.idm.lab.eng.brq.redhat.com', nshardwareplatform=u'x86_64', nsosversion=u'3.7.4-204.fc18.x86_64', version=u'2.51'): SUCCESS [Fri Mar 22 16:17:38.729304 2013] [:error] [pid 21335] ipa: INFO: host/vm-084.idm.lab.eng.brq.redhat@idm.lab.eng.brq.redhat.com: host_mod(u'vm-084.idm.lab.eng.brq.redhat.com', random=False, ipasshpubkey=([...], [...]), rights=False, updatedns=False, all=False, raw=False, version=u'2.54'): SUCCESS [Fri Mar 22 16:17:41.763080 2013] [:error] [pid 21336] ipa: INFO: host/vm-084.idm.lab.eng.brq.redhat@idm.lab.eng.brq.redhat.com: cert_request([...], principal=u'host/vm-084.idm.lab.eng.brq.redhat@idm.lab.eng.brq.redhat.com', add=True, version=u'2.51'): SUCCESS I can see what's going on, but I don't think the admin would be much wiser seeing this. Would we want so say something like Host entry for X already exists; joining may fail on the client side to explain what's going on? ACK from a technical perspective. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0041] Add logging to join command
On 03/22/2013 04:51 PM, Petr Viktorin wrote:
On 03/13/2013 03:05 PM, Tomas Babej wrote:
Hi,
The following is mentioned in the server log now:
- existence of host entry (if it already does exist)
- missing krbprincipalname and its new value (if there was no
principal name set)
https://fedorahosted.org/freeipa/ticket/3481
Tomas
Here is what I get first trying to re-enroll a wiped host first using
admin username/password, and then using a saved keytab.
The first succeeded, the second didn't.
We discussed this with Petr, this is a typo and actually happend in
reversed (and correct) order :)
[Fri Mar 22 16:17:14.338411 2013] [:error] [pid 21335] ipa: INFO: Host
entry for vm-084.idm.lab.eng.brq.redhat.com already exists
[Fri Mar 22 16:17:14.367564 2013] [:error] [pid 21335] ipa: INFO:
ad...@idm.lab.eng.brq.redhat.com:
join(u'vm-084.idm.lab.eng.brq.redhat.com',
nshardwareplatform=u'x86_64', nsosversion=u'3.7.4-204.fc18.x86_64',
version=u'2.51'): SUCCESS
[Fri Mar 22 16:17:35.395626 2013] [:error] [pid 21336] ipa: INFO: Host
entry for vm-084.idm.lab.eng.brq.redhat.com already exists
[Fri Mar 22 16:17:35.420830 2013] [:error] [pid 21336] ipa: INFO:
host/vm-084.idm.lab.eng.brq.redhat@idm.lab.eng.brq.redhat.com:
join(u'vm-084.idm.lab.eng.brq.redhat.com',
nshardwareplatform=u'x86_64', nsosversion=u'3.7.4-204.fc18.x86_64',
version=u'2.51'): SUCCESS
[Fri Mar 22 16:17:38.729304 2013] [:error] [pid 21335] ipa: INFO:
host/vm-084.idm.lab.eng.brq.redhat@idm.lab.eng.brq.redhat.com:
host_mod(u'vm-084.idm.lab.eng.brq.redhat.com', random=False,
ipasshpubkey=([...], [...]), rights=False, updatedns=False, all=False,
raw=False, version=u'2.54'): SUCCESS
[Fri Mar 22 16:17:41.763080 2013] [:error] [pid 21336] ipa: INFO:
host/vm-084.idm.lab.eng.brq.redhat@idm.lab.eng.brq.redhat.com:
cert_request([...],
principal=u'host/vm-084.idm.lab.eng.brq.redhat@idm.lab.eng.brq.redhat.com',
add=True, version=u'2.51'): SUCCESS
I can see what's going on, but I don't think the admin would be much
wiser seeing this.
Would we want so say something like Host entry for X already exists;
joining may fail on the client side to explain what's going on?
I agree with the proposal. Sending updated patch, here's the diff:
diff --git a/ipaserver/plugins/join.py b/ipaserver/plugins/join.py
index 86d6674..3b66805 100644
--- a/ipaserver/plugins/join.py
+++ b/ipaserver/plugins/join.py
@@ -101,7 +101,9 @@ class join(Command):
dn = attrs_list['dn']
# No error raised so far means that host entry exists
-self.log.info('Host entry for %s already exists', hostname)
+self.log.info('Host entry for %s already exists, '
+ 'joining may fail on the client side '
+ 'if not forced', hostname)
# If no principal name is set yet we need to try to add
# one.
ACK from a technical perspective.
Attached.
Tomas
From 6e2ec40056f65aa75b761e752942f70f823a7736 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Wed, 13 Mar 2013 14:47:03 +0100
Subject: [PATCH] Add logging to join command
The following is mentioned in the log now:
- existence of host entry (if it already does exist)
- missing krbprincipalname and its new value (if there was no
principal name set)
https://fedorahosted.org/freeipa/ticket/3481
---
ipaserver/plugins/join.py | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/ipaserver/plugins/join.py b/ipaserver/plugins/join.py
index 6ea02b2e1b7105c7865602c601f11231dd2b64b1..86d6674c10add529e7e2ca04cc588a1b50004655 100644
--- a/ipaserver/plugins/join.py
+++ b/ipaserver/plugins/join.py
@@ -23,12 +23,13 @@ Joining an IPA domain
import krbV
-from ipalib import api, util
+from ipalib import api
from ipalib import Command, Str
from ipalib import errors
from ipalib import _
from ipaserver.install import installutils
+
def get_realm():
Returns the default kerberos realm configured for this server.
@@ -37,6 +38,7 @@ def get_realm():
return unicode(krbctx.default_realm)
+
def validate_host(ugettext, cn):
Require at least one dot in the hostname (to support localhost.localdomain)
@@ -46,6 +48,7 @@ def validate_host(ugettext, cn):
return 'Fully-qualified hostname required'
return None
+
class join(Command):
Join an IPA domain
@@ -59,7 +62,8 @@ class join(Command):
#normalizer=lamda value: value.lower(),
),
)
-takes_options= (
+
+takes_options = (
Str('realm',
doc=_(The IPA realm),
default_from=lambda: get_realm(),
@@ -90,33 +94,41 @@ class join(Command):
assert 'cn' not in kw
ldap = self.api.Backend.ldap2
-host = None
try:
# First see if the host exists
kw = {'fqdn': hostname, 'all': True}
attrs_list =
Re: [Freeipa-devel] [PATCH 0042] Allow host re-enrollment using delegation
On 03/18/2013 02:49 PM, Tomas Babej wrote: On 03/18/2013 02:46 PM, Tomas Babej wrote: Hi, A new option --force-join has been added to ipa-client-install. It forces the host enrollment even if the host entry exists. Old certificate is revoked, new certificate and ssh key pair generated. See the relevant design for the re-enrollment part: http://freeipa.org/page/V3/Client_install_using_keytab --force-join is not mentioned there. Since you're adding a new option, you need to document it. https://fedorahosted.org/freeipa/ticket/3482 Tomas A-and the patch itself. The patch itself works fine. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0041] Add logging to join command
On 03/22/2013 05:10 PM, Tomas Babej wrote:
On 03/22/2013 04:51 PM, Petr Viktorin wrote:
On 03/13/2013 03:05 PM, Tomas Babej wrote:
Hi,
The following is mentioned in the server log now:
- existence of host entry (if it already does exist)
- missing krbprincipalname and its new value (if there was no
principal name set)
https://fedorahosted.org/freeipa/ticket/3481
Tomas
Here is what I get first trying to re-enroll a wiped host first using
admin username/password, and then using a saved keytab.
The first succeeded, the second didn't.
We discussed this with Petr, this is a typo and actually happend in
reversed (and correct) order :)
[Fri Mar 22 16:17:14.338411 2013] [:error] [pid 21335] ipa: INFO:
Host entry for vm-084.idm.lab.eng.brq.redhat.com already exists
[Fri Mar 22 16:17:14.367564 2013] [:error] [pid 21335] ipa: INFO:
ad...@idm.lab.eng.brq.redhat.com:
join(u'vm-084.idm.lab.eng.brq.redhat.com',
nshardwareplatform=u'x86_64', nsosversion=u'3.7.4-204.fc18.x86_64',
version=u'2.51'): SUCCESS
[Fri Mar 22 16:17:35.395626 2013] [:error] [pid 21336] ipa: INFO:
Host entry for vm-084.idm.lab.eng.brq.redhat.com already exists
[Fri Mar 22 16:17:35.420830 2013] [:error] [pid 21336] ipa: INFO:
host/vm-084.idm.lab.eng.brq.redhat@idm.lab.eng.brq.redhat.com:
join(u'vm-084.idm.lab.eng.brq.redhat.com',
nshardwareplatform=u'x86_64', nsosversion=u'3.7.4-204.fc18.x86_64',
version=u'2.51'): SUCCESS
[Fri Mar 22 16:17:38.729304 2013] [:error] [pid 21335] ipa: INFO:
host/vm-084.idm.lab.eng.brq.redhat@idm.lab.eng.brq.redhat.com:
host_mod(u'vm-084.idm.lab.eng.brq.redhat.com', random=False,
ipasshpubkey=([...], [...]), rights=False, updatedns=False,
all=False, raw=False, version=u'2.54'): SUCCESS
[Fri Mar 22 16:17:41.763080 2013] [:error] [pid 21336] ipa: INFO:
host/vm-084.idm.lab.eng.brq.redhat@idm.lab.eng.brq.redhat.com:
cert_request([...],
principal=u'host/vm-084.idm.lab.eng.brq.redhat@idm.lab.eng.brq.redhat.com',
add=True, version=u'2.51'): SUCCESS
I can see what's going on, but I don't think the admin would be much
wiser seeing this.
Would we want so say something like Host entry for X already exists;
joining may fail on the client side to explain what's going on?
I agree with the proposal. Sending updated patch, here's the diff:
diff --git a/ipaserver/plugins/join.py b/ipaserver/plugins/join.py
index 86d6674..3b66805 100644
--- a/ipaserver/plugins/join.py
+++ b/ipaserver/plugins/join.py
@@ -101,7 +101,9 @@ class join(Command):
dn = attrs_list['dn']
# No error raised so far means that host entry exists
-self.log.info('Host entry for %s already exists', hostname)
+self.log.info('Host entry for %s already exists, '
+ 'joining may fail on the client side '
+ 'if not forced', hostname)
# If no principal name is set yet we need to try to add
# one.
ACK from a technical perspective.
Attached.
Tomas
I sent the wrong patch (the previous one) last time. Sorry for the
confusion.
Tomas
From 55fe90af3452f77f7dcf4fe98ecb974340d2565f Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Wed, 13 Mar 2013 14:47:03 +0100
Subject: [PATCH] Add logging to join command
The following is mentioned in the log now:
- existence of host entry (if it already does exist)
- missing krbprincipalname and its new value (if there was no
principal name set)
https://fedorahosted.org/freeipa/ticket/3481
---
ipaserver/plugins/join.py | 26 --
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/ipaserver/plugins/join.py b/ipaserver/plugins/join.py
index 6ea02b2e1b7105c7865602c601f11231dd2b64b1..3b668053c5d275c53da0c897fb4f82442a725564 100644
--- a/ipaserver/plugins/join.py
+++ b/ipaserver/plugins/join.py
@@ -23,12 +23,13 @@ Joining an IPA domain
import krbV
-from ipalib import api, util
+from ipalib import api
from ipalib import Command, Str
from ipalib import errors
from ipalib import _
from ipaserver.install import installutils
+
def get_realm():
Returns the default kerberos realm configured for this server.
@@ -37,6 +38,7 @@ def get_realm():
return unicode(krbctx.default_realm)
+
def validate_host(ugettext, cn):
Require at least one dot in the hostname (to support localhost.localdomain)
@@ -46,6 +48,7 @@ def validate_host(ugettext, cn):
return 'Fully-qualified hostname required'
return None
+
class join(Command):
Join an IPA domain
@@ -59,7 +62,8 @@ class join(Command):
#normalizer=lamda value: value.lower(),
),
)
-takes_options= (
+
+takes_options = (
Str('realm',
doc=_(The IPA realm),
default_from=lambda: get_realm(),
@@ -90,33 +94,43 @@ class join(Command):
assert 'cn' not in kw
ldap = self.api.Backend.ldap2
-host = None
try:
Re: [Freeipa-devel] [PATCH 0042] Allow host re-enrollment using delegation
Petr Viktorin wrote: On 03/18/2013 02:49 PM, Tomas Babej wrote: On 03/18/2013 02:46 PM, Tomas Babej wrote: Hi, A new option --force-join has been added to ipa-client-install. It forces the host enrollment even if the host entry exists. Old certificate is revoked, new certificate and ssh key pair generated. See the relevant design for the re-enrollment part: http://freeipa.org/page/V3/Client_install_using_keytab --force-join is not mentioned there. Since you're adding a new option, you need to document it. What is the difference between force-join and force? All force does is let the install continue if the join fails, so if we're forcing join to succeed too... https://fedorahosted.org/freeipa/ticket/3482 Tomas A-and the patch itself. The patch itself works fine. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0042] Allow host re-enrollment using delegation
On Fri 22 Mar 2013 05:54:12 PM CET, Rob Crittenden wrote: Petr Viktorin wrote: On 03/18/2013 02:49 PM, Tomas Babej wrote: On 03/18/2013 02:46 PM, Tomas Babej wrote: Hi, A new option --force-join has been added to ipa-client-install. It forces the host enrollment even if the host entry exists. Old certificate is revoked, new certificate and ssh key pair generated. See the relevant design for the re-enrollment part: http://freeipa.org/page/V3/Client_install_using_keytab --force-join is not mentioned there. Since you're adding a new option, you need to document it. What is the difference between force-join and force? All force does is let the install continue if the join fails, so if we're forcing join to succeed too... There's more of different behaviour in ipa-client-install with --force option: - in case of install error, changes are not rolled back - in unattended mode, using --force allows to retrieve the CA cert using HTTP - Kerberos and LDAP settings are forced I'm not against merging the options, It just seemed to me as though they provide support for slightly different use cases. Though, man page for ipa-client-install says about --force option the following: Force the settings even if errors occur. https://fedorahosted.org/freeipa/ticket/3482 Tomas A-and the patch itself. The patch itself works fine. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
