Re: [Freeipa-devel] [PATCH 0254] Server Upgrade: Wait until DS is ready after restart
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 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] Password vault
Dne 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/hostname@realm, so with the
current code they will be considered a service and will have a service
container.
Do you want to add a new cn=hosts container just for hosts? Unless we
have a specific reason (i.e. use case) I don't see a need to add
specific code for hosts now, or at least until we get the core vault
functionality working.
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
--
Manage your subscription for the
Re: [Freeipa-devel] [PATCH 0254] Server Upgrade: Wait until DS is ready after restart
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 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Fix password changes via kadmin
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
From 455ee89dc8d449732e7f27c6c5ccd542963bd74e Mon Sep 17 00:00:00 2001
From: Martin Babinsky mbabi...@redhat.com
Date: Fri, 22 May 2015 17:23:00 +0200
Subject: [PATCH] common function to get salt types from LDAP
---
daemons/ipa-kdb/ipa_kdb.c | 129 +-
daemons/ipa-kdb/ipa_kdb.h | 2 +
2 files changed, 60 insertions(+), 71 deletions(-)
diff --git a/daemons/ipa-kdb/ipa_kdb.c b/daemons/ipa-kdb/ipa_kdb.c
index fff35c9c9b4cf0a1c7fd9a4e13d1029aa01160c3..3cbd19a2e78aee53e7f24dd97a4704641d1b8d61 100644
--- a/daemons/ipa-kdb/ipa_kdb.c
+++ b/daemons/ipa-kdb/ipa_kdb.c
@@ -317,19 +317,66 @@ ipadb_get_global_config(struct ipadb_context *ipactx)
return ipactx-config;
}
-int ipadb_get_connection(struct ipadb_context *ipactx)
+int ipadb_get_salt_types(struct ipadb_context *ipactx,
+ LDAPMessage *entry, char *attr,
+ krb5_key_salt_tuple *encs, int n_encs)
{
struct berval **vals = NULL;
-struct timeval tv = { 5, 0 };
-LDAPMessage *res = NULL;
-LDAPMessage *first;
+char **cvals = NULL;
+int c = 0;
+int i;
+int ret = 0;
krb5_key_salt_tuple *kst;
int n_kst;
+
+vals = ldap_get_values_len(ipactx-lcontext, entry, attr);
+if (!vals || !vals[0]) {
+goto done;
+}
+
+for (c = 0; vals[c]; c++) /* count */ ;
+cvals = calloc(c, sizeof(char *));
+if (!cvals) {
+ret = ENOMEM;
+goto done;
+}
+for (i = 0; i c; i++) {
+cvals[i] = strndup(vals[i]-bv_val, vals[i]-bv_len);
+if (!cvals[i]) {
+ret = ENOMEM;
+goto done;
+}
+}
+
+ret = parse_bval_key_salt_tuples(ipactx-kcontext,
+ (const char * const *)cvals, c,
+ kst, n_kst);
+if (ret) {
+goto done;
+}
+
+if (encs) {
+free(encs);
+}
+encs = kst;
+n_encs = n_kst;
+
+done:
+ldap_value_free_len(vals);
+for (i = 0; i c cvals[i]; i++) {
+free(cvals[i]);
+}
+free(cvals);
+return ret;
+}
+
+int ipadb_get_connection(struct ipadb_context *ipactx)
+{
+struct timeval tv = { 5, 0 };
+LDAPMessage *res = NULL;
+LDAPMessage *first;
int ret;
int v3;
-int i;
-char **cvals = NULL;
-int c = 0;
if (!ipactx-uri) {
return EINVAL;
@@ -386,74 +433,20 @@ int ipadb_get_connection(struct ipadb_context *ipactx)
/* defaults first, this is used to tell what default enc:salts to use
* for kadmin password changes */
-vals = ldap_get_values_len(ipactx-lcontext, first,
- krbDefaultEncSaltTypes);
-if (!vals || !vals[0]) {
-goto done;
-}
-
-for (c = 0; vals[c]; c++) /* count */ ;
-cvals = calloc(c, sizeof(char *));
-if (!cvals) {
-ret = ENOMEM;
-goto done;
-}
-for (i = 0; i c; i++) {
-cvals[i] = strndup(vals[i]-bv_val, vals[i]-bv_len);
-if (!cvals[i]) {
-ret = ENOMEM;
-goto done;
-}
-}
-
-ret = parse_bval_key_salt_tuples(ipactx-kcontext,
- (const char * const *)cvals, c,
- kst, n_kst);
+ret = ipadb_get_salt_types(ipactx, first, krbDefaultEncSaltTypes,
+ ipactx-def_encs, ipactx-n_def_encs);
if (ret) {
goto done;
}
-if (ipactx-def_encs) {
-free(ipactx-def_encs);
-}
-ipactx-def_encs = kst;
-ipactx-n_def_encs = n_kst;
-
/* supported enc salt types, use to tell kadmin what to accept
* but also to detect if kadmin is requesting the default set */
-vals = ldap_get_values_len(ipactx-lcontext, first,
- krbSupportedEncSaltTypes);
-if (!vals || !vals[0]) {
-goto done;
-}
-
-for (c = 0; vals[c]; c++) /* count */ ;
-cvals = calloc(c, sizeof(char *));
-if (!cvals) {
-ret = ENOMEM;
-goto done;
-}
-for (i = 0; i c; i++) {
-cvals[i] =
[Freeipa-devel] using pyhbac for CA ACLs
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
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0257] ULC: Fix: Upgrade for stage user admins failed
On 05/22/2015 05:59 PM, Martin Basti wrote: Patch attached. Thanks for patch. Works for me, ACK. -- David Kupka -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0339-0363] Implement meta-database
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. 32b5764969c64eac9c1783098b35025e99ff 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 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0325] Add Domain Level feature
On 05/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 From 156f730231e72a8ddb0613600b24b358a1271e0c Mon Sep 17 00:00:00 2001 From: Tomas Babej tba...@redhat.com Date: Thu, 14 May 2015 10:49:55 +0200 Subject: [PATCH] Add Domain Level feature https://fedorahosted.org/freeipa/ticket/5018 --- ACI.txt| 2 + API.txt| 9 ++ install/share/72domainlevels.ldif | 6 + install/share/Makefile.am | 2 + install/share/domainlevel.ldif | 7 ++ install/tools/ipa-replica-install | 32 - install/tools/ipa-server-install | 22 +++- install/updates/72-domainlevels.update | 14 +++ install/updates/Makefile.am| 1 + ipalib/constants.py| 3 + ipalib/errors.py | 16 +++ ipalib/plugins/domainlevel.py | 132 + ipaserver/install/dsinstance.py| 12 +- ipaserver/install/ldapupdate.py| 5 + .../install/plugins/update_managed_permissions.py | 11 +- 15 files changed, 263 insertions(+), 11 deletions(-) create mode 100644 install/share/72domainlevels.ldif create mode 100644 install/share/domainlevel.ldif create mode 100644 install/updates/72-domainlevels.update create mode 100644 ipalib/plugins/domainlevel.py diff --git a/ACI.txt b/ACI.txt index bf539892910f14ebc3fbee88a72d2b57c0d1327b..1e4eb0f5a75e44a3c56dffe7df1655a9f0a1db87 100644 --- a/ACI.txt +++ b/ACI.txt @@ -323,6 +323,8 @@ aci: (targetattr = cn || createtimestamp || dnahostname || dnaportnum || dnarem dn: ou=profile,dc=ipa,dc=example aci: (targetattr = attributemap || authenticationmethod || bindtimelimit || cn || createtimestamp || credentiallevel ||
Re: [Freeipa-devel] using pyhbac for CA ACLs
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
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] using pyhbac for CA ACLs
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
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] using pyhbac for CA ACLs
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?
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] using pyhbac for CA ACLs
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
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0259] Server Upgrade: Wait until DS is ready after restart
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 From 12df8e64ca2c63eec6bb3267b0377e6cb420b3e6 Mon Sep 17 00:00:00 2001 From: Martin Basti mba...@redhat.com 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 | 41 ipaserver/install/upgradeinstance.py | 3 ++- 2 files changed, 29 insertions(+), 15 deletions(-) diff --git a/ipaplatform/redhat/services.py b/ipaplatform/redhat/services.py index 565bf1fdef27e9a780ad2e2638b5051a95782bd2..4df353fabe6d9e7b9fdd97a314b4f3a0c64a5c21 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=,
Re: [Freeipa-devel] [PATCH 0048] fix ipa help command output errors
On 22/05/15 17:40, Gabe Alford wrote: On Fri, May 22, 2015 at 9:01 AM, Martin Basti mba...@redhat.com mailto:mba...@redhat.com 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 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0321] Update and standardize copyright headers; introduce AUTHORS file
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 pspa...@redhat.com 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 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] Yet another user certificates/Smart Card thread
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 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0321] Update and standardize copyright headers; introduce AUTHORS file
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 pspa...@redhat.com 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 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] using pyhbac for CA ACLs
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
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH 0260] Server Upgrade: fix the remove statement
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
From 0b23dd82c194809dfae0d541172751d6e4999143 Mon Sep 17 00:00:00 2001
From: Martin Basti mba...@redhat.com
Date: Mon, 25 May 2015 14:57:04 +0200
Subject: [PATCH] Server Upgrade: fix remove statement
If value does not exists then do not update entry. Otherwise, together with
nonexistent entry, the LDAP decode error will be raised.
https://fedorahosted.org/freeipa/ticket/4904
---
ipaserver/install/ldapupdate.py | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/ipaserver/install/ldapupdate.py b/ipaserver/install/ldapupdate.py
index 2f5bcc748eb546b4dad7e1aeeb7a2882a40d8d35..5fca37695f1da76b76f7c545fe8d1a5dccab90cb 100644
--- a/ipaserver/install/ldapupdate.py
+++ b/ipaserver/install/ldapupdate.py
@@ -648,9 +648,10 @@ class LDAPUpdate:
entry_values.remove(update_value)
except ValueError:
self.warning(remove: '%s' not in %s, update_value, attr)
-pass
-entry[attr] = entry_values
-self.debug('remove: updated value %s', safe_output(attr, entry_values))
+else:
+entry[attr] = entry_values
+self.debug('remove: updated value %s', safe_output(
+attr, entry_values))
elif action == 'add':
self.debug(add: '%s' to %s, current value %s, safe_output(attr, update_value), attr, safe_output(attr, entry_values))
# Remove it, ignoring errors so we can blindly add it later
--
2.1.0
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Yet another user certificates/Smart Card thread
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 https://www.redhat.com/archives/freeipa-devel/2015-May/msg00198.html. 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 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0259] Server Upgrade: Wait until DS is ready after restart
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 mba...@redhat.com 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
[Freeipa-devel] Replication Topology plugin issues
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. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Yet another user certificates/Smart Card thread
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 https://www.redhat.com/archives/freeipa-devel/2015-May/msg00198.html. 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 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA:
Re: [Freeipa-devel] Yet another user certificates/Smart Card thread
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 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Yet another user certificates/Smart Card thread
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 https://www.redhat.com/archives/freeipa-devel/2015-May/msg00198.html.
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
Re: [Freeipa-devel] [PATCH 0258] Server Upgrade: move code from ipa-upgrade config into separate module
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 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Yet another user certificates/Smart Card thread
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/msg1.html HTH, Martin -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Yet another user certificates/Smart Card thread
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 https://www.redhat.com/archives/freeipa-devel/2015-May/msg00198.html.
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
Re: [Freeipa-devel] [PATCH] 0178 Fix AD trusts in Fedora 22
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 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0258] Server Upgrade: move code from ipa-upgrade config into separate module
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 From 021bcf3ee911b472425a8ca4931570d5154100b5 Mon Sep 17 00:00:00 2001 From: Martin Basti mba...@redhat.com Date: Fri, 22 May 2015 17:38:16 +0200 Subject: [PATCH] Server Upgrade: Move code from ipa-upgradeconfig to separate module This also prevent the script ipa-upgradeconfig execute upgrading. Upgrade of services is called from ipa-server-upgrade https://fedorahosted.org/freeipa/ticket/4904 --- install/tools/ipa-upgradeconfig| 1412 +--- ipaserver/install/ipa_server_upgrade.py| 15 +- .../install/server.py | 105 +- 3 files changed, 30 insertions(+), 1502 deletions(-) copy install/tools/ipa-upgradeconfig = ipaserver/install/server.py (94%) mode change 100755 = 100644 diff --git a/install/tools/ipa-upgradeconfig b/install/tools/ipa-upgradeconfig index dfef1e0aa8b1507b7aa4907e9b688ce99253b87c..43292966a29c9077443913bdda1c81aa3de06a10 100755 --- a/install/tools/ipa-upgradeconfig +++ b/install/tools/ipa-upgradeconfig @@ -19,1417 +19,9 @@ # You should have received a copy of the GNU General Public License # along with this program. If not, see http://www.gnu.org/licenses/. - -Upgrade configuration files to a newer template. - - import sys -import re -import os -import shutil -import pwd -import fileinput -import ConfigParser -import grp -from ipalib import api -import SSSDConfig -import ipalib.util -import ipalib.errors -from ipaplatform import services -from ipaplatform.tasks import tasks -from ipapython import ipautil, sysrestore, version, certdb -from ipapython.config import IPAOptionParser -from ipapython.ipa_log_manager import * -from ipapython import certmonger -from ipapython import dogtag -from ipaplatform.paths import paths -from ipaserver.install import installutils -from ipaserver.install import dsinstance -from ipaserver.install import httpinstance -from ipaserver.install import memcacheinstance -from ipaserver.install import bindinstance -from ipaserver.install import service -from ipaserver.install import cainstance -from ipaserver.install import certs -from ipaserver.install import otpdinstance -from ipaserver.install import sysupgrade -from ipaserver.install import dnskeysyncinstance - - -def parse_options(): -parser = IPAOptionParser(version=version.VERSION) -parser.add_option(-d, --debug, dest=debug, action=store_true, - default=False, help=print debugging information) -parser.add_option(-q, --quiet, dest=quiet, - action=store_true, - default=False, help=Output only errors) - -options, args = parser.parse_args() -safe_options = parser.get_safe_opts(options) - -return safe_options, options - -class KpasswdInstance(service.SimpleServiceInstance): -def __init__(self): -service.SimpleServiceInstance.__init__(self, ipa_kpasswd) - -def uninstall_ipa_kpasswd(): - -We can't use the full service uninstaller because that will attempt -to stop and disable the service which by now doesn't exist. We just -want to clean up sysrestore.state to remove all references to -ipa_kpasswd. - -ipa_kpasswd = KpasswdInstance() - -running = ipa_kpasswd.restore_state(running) -enabled = not ipa_kpasswd.restore_state(enabled) - -if enabled is not None and not enabled: -ipa_kpasswd.remove() - -def backup_file(filename, ext): -Make a backup of filename using ext as the extension. Do not overwrite - previous backups. -if not os.path.isabs(filename): -raise ValueError(Absolute path required) - -backupfile = filename + .bak -(reldir, file) = os.path.split(filename) - -while os.path.exists(backupfile): -backupfile = backupfile + . + str(ext) - -try: -shutil.copy2(filename, backupfile) -except IOError, e: -if e.errno == 2: # No such file or directory -pass -else: -raise e - -def update_conf(sub_dict, filename, template_filename): -template = ipautil.template_file(template_filename, sub_dict) -fd = open(filename, w) -fd.write(template) -fd.close() - -def find_hostname(): -Find the hostname currently configured in ipa-rewrite.conf -filename=paths.HTTPD_IPA_REWRITE_CONF - -if not ipautil.file_exists(filename): -return None - -pattern = ^[\s#]*.*https:\/\/([A-Za-z0-9\.\-]*)\/.* -p = re.compile(pattern) -for line in fileinput.input(filename): -if p.search(line): -fileinput.close() -return p.search(line).group(1) -fileinput.close() - -raise RuntimeError(Unable to determine the fully qualified hostname from %s % filename) - -def find_autoredirect(fqdn): - -When
Re: [Freeipa-devel] [PATCH 0325] Add Domain Level feature
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. From 7930e267f4c513a6b2059a6c99d69155c1452c49 Mon Sep 17 00:00:00 2001 From: Tomas Babej tba...@redhat.com Date: Thu, 14 May 2015 10:49:55 +0200 Subject: [PATCH] Add Domain Level feature https://fedorahosted.org/freeipa/ticket/5018 --- ACI.txt| 2 + API.txt| 9 ++ install/share/72domainlevels.ldif | 6 + install/share/Makefile.am | 2 + install/share/domainlevel.ldif | 7 ++ install/tools/ipa-replica-install | 32 - install/tools/ipa-server-install | 22 +++- install/updates/72-domainlevels.update | 14 +++ install/updates/Makefile.am| 1 + ipalib/constants.py| 3 + ipalib/errors.py | 16 +++ ipalib/plugins/domainlevel.py | 132 + ipaserver/install/dsinstance.py| 12 +- ipaserver/install/ldapupdate.py| 5 + .../install/plugins/update_managed_permissions.py | 11 +- 15 files changed, 263 insertions(+), 11 deletions(-) create mode 100644 install/share/72domainlevels.ldif create mode 100644 install/share/domainlevel.ldif create mode 100644 install/updates/72-domainlevels.update create mode 100644 ipalib/plugins/domainlevel.py diff --git a/ACI.txt b/ACI.txt index bf539892910f14ebc3fbee88a72d2b57c0d1327b..1e4eb0f5a75e44a3c56dffe7df1655a9f0a1db87 100644 --- a/ACI.txt +++ b/ACI.txt @@ -323,6 +323,8 @@ aci: (targetattr = cn || createtimestamp || dnahostname || dnaportnum || dnarem dn: ou=profile,dc=ipa,dc=example aci: (targetattr = attributemap
Re: [Freeipa-devel] [PATCH 0259] Server Upgrade: Wait until DS is ready after restart
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 mba...@redhat.com 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
Re: [Freeipa-devel] [PATCH 0036] merge KRA installation machinery to a single module
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 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0036] merge KRA installation machinery to a single module
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 From bbc4fbf6831eeecb1b423fcb717db1097dc3e35b Mon Sep 17 00:00:00 2001 From: Martin Babinsky mbabi...@redhat.com Date: Fri, 15 May 2015 19:02:22 +0200 Subject: [PATCH] merge KRA installation machinery to a single module This is a prerequisite to further refactoring of KRA install/uninstall functionality in all IPA install scripts. https://fedorahosted.org/freeipa/ticket/4468 --- install/tools/ipa-replica-install| 21 - install/tools/ipa-server-install | 29 +--- ipaserver/install/ipa_kra_install.py | 83 ++- ipaserver/install/kra.py | 85 4 files changed, 118 insertions(+), 100 deletions(-) create mode 100644 ipaserver/install/kra.py diff --git a/install/tools/ipa-replica-install b/install/tools/ipa-replica-install index f68cc8cf4722264ecea2f1f50de3aa245be24ef9..c75848b1ada91254a41245df240ede24c477d5b1 100755 --- a/install/tools/ipa-replica-install +++ b/install/tools/ipa-replica-install @@ -37,10 +37,10 @@ from ipaserver.install import memcacheinstance, dnskeysyncinstance from ipaserver.install import otpdinstance from ipaserver.install.replication import replica_conn_check, ReplicationManager from ipaserver.install.installutils import ( -create_replica_config, read_replica_info_kra_enabled, private_ccache) +create_replica_config, private_ccache) from ipaserver.plugins.ldap2 import ldap2 from ipaserver.install import cainstance -from ipaserver.install import krainstance +from ipaserver.install import kra from ipaserver.install import dns as dns_installer from ipalib import api, create_api, errors, util, certstore, x509 from ipalib.constants import CACERT @@ -473,12 +473,12 @@ def main(): config.setup_kra = options.setup_kra if config.setup_kra: -if not config.setup_ca: -print CA must be installed with the KRA -sys.exit(1) -if not read_replica_info_kra_enabled(config.dir): -print KRA is not installed on the master system -sys.exit(1) +try: +kra.install_check(config, options, False, + dogtag.install_constants.DOGTAG_VERSION) +except RuntimeError as e: +print str(e) +exit(1) installutils.verify_fqdn(config.master_host_name, options.no_host_dns) @@ -660,10 +660,7 @@ def main(): ds.apply_updates() if options.setup_kra: -kra = krainstance.install_replica_kra(config) -service.print_msg(Restarting the directory server) -ds.restart() -kra.enable_client_auth_to_db(kra.dogtag_constants.KRA_CS_CFG_PATH) +kra.install(config, options, dirman_password) else: service.print_msg(Restarting the directory server) ds.restart() diff --git a/install/tools/ipa-server-install b/install/tools/ipa-server-install index cb6e1abe2016c0f8cefc35b1d685373f05b3ef89..9bb8955dc15d1682edf33d7652de0829771267f3 100755 --- a/install/tools/ipa-server-install +++ b/install/tools/ipa-server-install @@ -53,13 +53,13 @@ from ipaserver.install import httpinstance from ipaserver.install import ntpinstance from ipaserver.install import certs from ipaserver.install import cainstance -from ipaserver.install import krainstance from ipaserver.install import memcacheinstance from ipaserver.install import otpdinstance from ipaserver.install import sysupgrade from ipaserver.install import replication from ipaserver.install import dns as dns_installer from ipaserver.install import service, installutils +from ipaserver.install import kra from ipapython import version from ipapython import certmonger from ipapython import ipaldap @@ -577,11 +577,7 @@ def uninstall(): if cads_instance.is_configured(): cads_instance.uninstall() -kra_instance = krainstance.KRAInstance( -api.env.realm, dogtag_constants=dogtag_constants) -kra_instance.stop_tracking_certificates() -if kra_instance.is_installed(): -kra_instance.uninstall() +kra.uninstall() ca_instance = cainstance.CAInstance( api.env.realm, certs.NSS_DIR, dogtag_constants=dogtag_constants) @@ -1036,6 +1032,14 @@ def main(): else: admin_password = options.admin_password +if setup_kra: +try: +kra.install_check(None, options, False, + dogtag.install_constants.DOGTAG_VERSION) +
[Freeipa-devel] [PATCH] 496 Fix typo in ipa-server-upgrade man page
Pushed to master (oneliner): d0a330aa1ce250da3ab552f6517945c7cf871ad1 -- Martin Kosek mko...@redhat.com Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From c0642ba63f41d269d3208bf9fc69da0503aff3fa Mon Sep 17 00:00:00 2001 From: Martin Kosek mko...@redhat.com Date: Tue, 26 May 2015 07:52:50 +0200 Subject: [PATCH] Fix typo in ipa-server-upgrade man page --- install/tools/man/ipa-server-upgrade.1 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/install/tools/man/ipa-server-upgrade.1 b/install/tools/man/ipa-server-upgrade.1 index b3d89bde766d9fa0042a7a4d0f533cb2b7d26948..cbbdc590171bff0a88b67bcf1de961fd783ac35c 100644 --- a/install/tools/man/ipa-server-upgrade.1 +++ b/install/tools/man/ipa-server-upgrade.1 @@ -18,7 +18,7 @@ ipa\-server\-upgrade will: .SH OPTIONS .TP -\fB\-\-skip\-version-\check\fR +\fB\-\-skip\-version\-check\fR Skip version check. WARNING: this option may break your system .TP \fB\-\-force\fR -- 2.1.0 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Yet another user certificates/Smart Card thread
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 https://www.redhat.com/archives/freeipa-devel/2015-May/msg00198.html.
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
--
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
