Re: [Freeipa-devel] [PATCH 0024] Add OTP support to ipalib CLI
On 16.12.2013 18:01, Nathaniel McCallum wrote:
On Mon, 2013-12-16 at 17:31 +0100, Jan Cholasta wrote:
Please rename _normalize_owner to _convert_owner and vice versa, to
match the convention used in other plugins (sorry for noticing this
earlier).
Fixed.
This bit in otptoken_add should be replaced by a call to
_normalize_owner (after the rename):
+# Resolve the user's dn
+owner = entry_attrs.get('ipatokenowner', None)
+if owner is not None:
+owner = self.api.Object.user.get_dn(owner)
+entry_attrs['ipatokenowner'] = owner
Fixed.
ipalib/plugins/otptoken.py:230: [E0602(undefined-variable),
otptoken_add.pre_callback] Undefined variable 'owner')
ipalib/plugins/otptoken.py:232: [E0602(undefined-variable),
otptoken_add.pre_callback] Undefined variable 'owner')
(just put a owner = entry_attrs.get('ipatokenowner') line somewhere in
there)
You do the conversion from uid to DN in otptoken_find twice:
+_convert_owner(self.api.Object.user, kwargs)
+return super(otptoken_find, self).pre_callback(ldap, filters,
*args, **kwargs)
+
+def args_options_2_entry(self, *args, **options):
+o = 'ipatokenowner'
+if o in options:
+options[o] = self.api.Object.user.get_dn(options[o])
I would suggest to do it only in args_options_2_entry like this (again,
after the rename):
def args_options_2_entry(self, *args, **options):
entry = super(otptoken_find, self).args_options_2_entry(*args,
**options)
_convert_owner(self.api.Object.user, entry)
return entry
Fixed.
Thanks. Also sorry for misleading you to use _convert_owner here, I see
you did the right thing and used _normalize_owner.
The patch needs a rebase (for the sake of ipapermlocation default value).
Fixed.
Nathaniel
--
Jan Cholasta
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0026] Enable building in C99 mode
On Tue, Dec 17, 2013 at 08:19:09AM +0100, Jan Cholasta wrote: Hi, On 16.12.2013 22:12, Nathaniel McCallum wrote: Patch attached. Care to elaborate? There's no ticket or explanation why this is beneficial or necessary. We had a short chat with Nathaniel yesterday on IRC about which C standards we, as a project, allow. I think this patch is a result of that discussion. SSSD has had -std=gnu99 in the default CFLAGS for more than a year now. I think we can safely support C99 and its features now, it's almost 2014 and all major compilers support the features we care about. But I think this change should go hand-in-hand with amending http://www.freeipa.org/page/Coding_Style For instance, would variable-length arrays considered OK? (I would vote yes), would intermingled code and declarations be considered OK (I personally dislike these), etc? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0026] Enable building in C99 mode
On 17.12.2013 10:12, Jakub Hrozek wrote: On Tue, Dec 17, 2013 at 08:19:09AM +0100, Jan Cholasta wrote: Hi, On 16.12.2013 22:12, Nathaniel McCallum wrote: Patch attached. Care to elaborate? There's no ticket or explanation why this is beneficial or necessary. We had a short chat with Nathaniel yesterday on IRC about which C standards we, as a project, allow. I think this patch is a result of that discussion. SSSD has had -std=gnu99 in the default CFLAGS for more than a year now. I think we can safely support C99 and its features now, it's almost 2014 and all major compilers support the features we care about. But I think this change should go hand-in-hand with amending http://www.freeipa.org/page/Coding_Style For instance, would variable-length arrays considered OK? (I would vote yes), Please no. You can't catch the error if the memory allocation fails for whatever reason and the process will killed by OS. (There is a question if you want to handle memory allocation failures at all, of course.) would intermingled code and declarations be considered OK (I personally dislike these), etc? Neither do I :-) -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0346 permission_find: Do not fail for ipasearchrecordslimit=-1
On 12/16/2013 04:55 PM, Jan Cholasta wrote: Hi, On 16.12.2013 16:46, Petr Viktorin wrote: Hello, Honza found a failure in the new permission plugin when ipasearchrecordslimit is set to -1. Here is a fix. Judging from LDAPSearch.find_entries, it seems that 0 also means unlimited, so I think if len(entries) max_entries 0 might be safer here. Fixed. I think it's clearer to spell this out since it's not really comparing the same quantity. -- Petr³ From e2dedadbfc7967e8c472e1d33c249de75e53507c Mon Sep 17 00:00:00 2001 From: Petr Viktorin pvikt...@redhat.com Date: Mon, 16 Dec 2013 16:11:33 +0100 Subject: [PATCH] permission_find: Do not fail for ipasearchrecordslimit=-1 ipasearchrecordslimit can be -1, which means unlimited. The permission_find post_callback failed in this case in legacy permission handling. Do not fail in this case. --- ipalib/plugins/permission.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/ipalib/plugins/permission.py b/ipalib/plugins/permission.py index 345faa896c942007f0ab58fb03dbe769c700ce08..fef640c37bc34f53376fad3a1b943bb37f677167 100644 --- a/ipalib/plugins/permission.py +++ b/ipalib/plugins/permission.py @@ -891,11 +891,12 @@ def post_callback(self, ldap, entries, truncated, *args, **options): for entry in legacy_entries: if entry.single_value['cn'] in nonlegacy_names: continue -if len(entries) max_entries: +if max_entries 0 and len(entries) max_entries: # We've over the limit, pop the last entry and set # truncated flag # (this is easier to do than checking before adding # the entry to results) +# (max_entries = 0 means unlimited) entries.pop() truncated = True break -- 1.8.3.1 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0026] Enable building in C99 mode
On Tue, Dec 17, 2013 at 10:29:03AM +0100, Petr Spacek wrote: On 17.12.2013 10:12, Jakub Hrozek wrote: On Tue, Dec 17, 2013 at 08:19:09AM +0100, Jan Cholasta wrote: Hi, On 16.12.2013 22:12, Nathaniel McCallum wrote: Patch attached. Care to elaborate? There's no ticket or explanation why this is beneficial or necessary. We had a short chat with Nathaniel yesterday on IRC about which C standards we, as a project, allow. I think this patch is a result of that discussion. SSSD has had -std=gnu99 in the default CFLAGS for more than a year now. I think we can safely support C99 and its features now, it's almost 2014 and all major compilers support the features we care about. But I think this change should go hand-in-hand with amending http://www.freeipa.org/page/Coding_Style For instance, would variable-length arrays considered OK? (I would vote yes), Please no. You can't catch the error if the memory allocation fails for whatever reason and the process will killed by OS. (There is a question if you want to handle memory allocation failures at all, of course.) I thought that variable length arrays were allocated on the stack? So yes, you need to be careful and only allow use VLAs when you absolutely know that the value is small and you don't run past the stack size. But that's not really what I wanted to discuss now, I mostly wanted to bring up that if we allow some extra language features, we should agree on whether it's OK to use all of them. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0346 permission_find: Do not fail for ipasearchrecordslimit=-1
On 17.12.2013 10:54, Petr Viktorin wrote: On 12/16/2013 04:55 PM, Jan Cholasta wrote: Hi, On 16.12.2013 16:46, Petr Viktorin wrote: Hello, Honza found a failure in the new permission plugin when ipasearchrecordslimit is set to -1. Here is a fix. Judging from LDAPSearch.find_entries, it seems that 0 also means unlimited, so I think if len(entries) max_entries 0 might be safer here. Fixed. I think it's clearer to spell this out since it's not really comparing the same quantity. ACK. -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0346 permission_find: Do not fail for ipasearchrecordslimit=-1
On 12/17/2013 11:08 AM, Jan Cholasta wrote: On 17.12.2013 10:54, Petr Viktorin wrote: On 12/16/2013 04:55 PM, Jan Cholasta wrote: Hi, On 16.12.2013 16:46, Petr Viktorin wrote: Hello, Honza found a failure in the new permission plugin when ipasearchrecordslimit is set to -1. Here is a fix. Judging from LDAPSearch.find_entries, it seems that 0 also means unlimited, so I think if len(entries) max_entries 0 might be safer here. Fixed. I think it's clearer to spell this out since it's not really comparing the same quantity. ACK. Thanks! Pushed to master: 1a9beac1bebc7d9b0207053a7eb6d775cae590d1 -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0026] Enable building in C99 mode
On Tue, 2013-12-17 at 08:19 +0100, Jan Cholasta wrote: Hi, On 16.12.2013 22:12, Nathaniel McCallum wrote: Patch attached. Care to elaborate? There's no ticket or explanation why this is beneficial or necessary. It enables compiling with C99 features, which I personally find very beneficial. I am using these features (incomplete initializers and for-loop declarations) in my DS plugin code. It is 2014 after all, and most recent compilers support C11 at this point (certainly all the ones we care to support)... Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0026] Enable building in C99 mode
On Tue, 2013-12-17 at 10:29 +0100, Petr Spacek wrote: On 17.12.2013 10:12, Jakub Hrozek wrote: On Tue, Dec 17, 2013 at 08:19:09AM +0100, Jan Cholasta wrote: Hi, On 16.12.2013 22:12, Nathaniel McCallum wrote: Patch attached. Care to elaborate? There's no ticket or explanation why this is beneficial or necessary. We had a short chat with Nathaniel yesterday on IRC about which C standards we, as a project, allow. I think this patch is a result of that discussion. SSSD has had -std=gnu99 in the default CFLAGS for more than a year now. I think we can safely support C99 and its features now, it's almost 2014 and all major compilers support the features we care about. But I think this change should go hand-in-hand with amending http://www.freeipa.org/page/Coding_Style For instance, would variable-length arrays considered OK? (I would vote yes), Please no. You can't catch the error if the memory allocation fails for whatever reason and the process will killed by OS. (There is a question if you want to handle memory allocation failures at all, of course.) I think this can be reasonably be used with appropriately documented caution. would intermingled code and declarations be considered OK (I personally dislike these), etc? Neither do I :-) +1, with the exception of declarations at the beginning of the block, which I find useful (I know this isn't C99). Features that I don't want to live without: 1. Standard struct initializers 2. Compound literals 3. For-loop declarations 4. Standard bool type Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0024] Add OTP support to ipalib CLI
On Tue, 2013-12-17 at 09:36 +0100, Jan Cholasta wrote:
On 16.12.2013 18:01, Nathaniel McCallum wrote:
On Mon, 2013-12-16 at 17:31 +0100, Jan Cholasta wrote:
Please rename _normalize_owner to _convert_owner and vice versa, to
match the convention used in other plugins (sorry for noticing this
earlier).
Fixed.
This bit in otptoken_add should be replaced by a call to
_normalize_owner (after the rename):
+# Resolve the user's dn
+owner = entry_attrs.get('ipatokenowner', None)
+if owner is not None:
+owner = self.api.Object.user.get_dn(owner)
+entry_attrs['ipatokenowner'] = owner
Fixed.
ipalib/plugins/otptoken.py:230: [E0602(undefined-variable),
otptoken_add.pre_callback] Undefined variable 'owner')
ipalib/plugins/otptoken.py:232: [E0602(undefined-variable),
otptoken_add.pre_callback] Undefined variable 'owner')
(just put a owner = entry_attrs.get('ipatokenowner') line somewhere in
there)
Fixed, with: owner = entry_attrs.get('ipatokenowner', None)
Nathaniel
From 407c46e5e7c02e6c4bdd9b5c648c116c22f213c3 Mon Sep 17 00:00:00 2001
From: Nathaniel McCallum npmccal...@redhat.com
Date: Tue, 1 Oct 2013 14:26:38 -0400
Subject: [PATCH] Add OTP support to ipalib CLI
https://fedorahosted.org/freeipa/ticket/3368
---
API.txt| 101 +-
VERSION| 2 +-
freeipa.spec.in| 2 +
ipalib/plugins/config.py | 2 +-
ipalib/plugins/otptoken.py | 329 +
ipalib/plugins/user.py | 10 +-
6 files changed, 439 insertions(+), 7 deletions(-)
create mode 100644 ipalib/plugins/otptoken.py
diff --git a/API.txt b/API.txt
index 342d7ed6e41b32c1e3695df1eb89b481f9baf48e..3bb1b76ac9a53449d46979d554cce556d21e1323 100644
--- a/API.txt
+++ b/API.txt
@@ -524,7 +524,7 @@ option: Int('ipasearchrecordslimit', attribute=True, autofill=False, cli_name='s
option: Int('ipasearchtimelimit', attribute=True, autofill=False, cli_name='searchtimelimit', minvalue=-1, multivalue=False, required=False)
option: Str('ipaselinuxusermapdefault', attribute=True, autofill=False, cli_name='ipaselinuxusermapdefault', multivalue=False, required=False)
option: Str('ipaselinuxusermaporder', attribute=True, autofill=False, cli_name='ipaselinuxusermaporder', multivalue=False, required=False)
-option: StrEnum('ipauserauthtype', attribute=True, autofill=False, cli_name='user_auth_type', csv=True, multivalue=True, required=False, values=(u'password', u'radius'))
+option: StrEnum('ipauserauthtype', attribute=True, autofill=False, cli_name='user_auth_type', csv=True, multivalue=True, required=False, values=(u'password', u'radius', u'otp'))
option: Str('ipauserobjectclasses', attribute=True, autofill=False, cli_name='userobjectclasses', csv=True, multivalue=True, required=False)
option: IA5Str('ipausersearchfields', attribute=True, autofill=False, cli_name='usersearch', multivalue=False, required=False)
option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui')
@@ -2219,6 +2219,99 @@ option: Str('version?', exclude='webui')
output: Entry('result', type 'dict', Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None))
output: Output('summary', (type 'unicode', type 'NoneType'), None)
output: Output('value', type 'unicode', None)
+command: otptoken_add
+args: 1,20,3
+arg: Str('ipatokenuniqueid', attribute=True, cli_name='id', multivalue=False, primary_key=True, required=False)
+option: Str('addattr*', cli_name='addattr', exclude='webui')
+option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
+option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False)
+option: Bool('ipatokendisabled', attribute=True, cli_name='disabled', multivalue=False, required=False)
+option: Str('ipatokenmodel', attribute=True, cli_name='model', multivalue=False, required=False)
+option: Str('ipatokennotafter', attribute=True, cli_name='not_after', multivalue=False, required=False)
+option: Str('ipatokennotbefore', attribute=True, cli_name='not_before', multivalue=False, required=False)
+option: StrEnum('ipatokenotpalgorithm', attribute=True, cli_name='algo', multivalue=False, required=False, values=(u'sha1', u'sha256', u'sha384', u'sha512'))
+option: IntEnum('ipatokenotpdigits', attribute=True, cli_name='digits', multivalue=False, required=False, values=(6, 8))
+option: OTPTokenKey('ipatokenotpkey', attribute=True, cli_name='key', multivalue=False, required=False)
+option: Str('ipatokenowner', attribute=True, cli_name='owner', multivalue=False, required=False)
+option: Str('ipatokenserial', attribute=True, cli_name='serial', multivalue=False, required=False)
+option: Int('ipatokentotpclockoffset', attribute=True, cli_name='offset', multivalue=False, required=False)
+option: Int('ipatokentotptimestep', attribute=True, cli_name='interval', minvalue=5, multivalue=False, required=False)
Re: [Freeipa-devel] [PATCH 0026] Enable building in C99 mode
On Tue, 2013-12-17 at 08:47 -0500, Nathaniel McCallum wrote: On Tue, 2013-12-17 at 10:29 +0100, Petr Spacek wrote: On 17.12.2013 10:12, Jakub Hrozek wrote: On Tue, Dec 17, 2013 at 08:19:09AM +0100, Jan Cholasta wrote: Hi, On 16.12.2013 22:12, Nathaniel McCallum wrote: Patch attached. Care to elaborate? There's no ticket or explanation why this is beneficial or necessary. We had a short chat with Nathaniel yesterday on IRC about which C standards we, as a project, allow. I think this patch is a result of that discussion. SSSD has had -std=gnu99 in the default CFLAGS for more than a year now. I think we can safely support C99 and its features now, it's almost 2014 and all major compilers support the features we care about. But I think this change should go hand-in-hand with amending http://www.freeipa.org/page/Coding_Style For instance, would variable-length arrays considered OK? (I would vote yes), Please no. You can't catch the error if the memory allocation fails for whatever reason and the process will killed by OS. (There is a question if you want to handle memory allocation failures at all, of course.) I think this can be reasonably be used with appropriately documented caution. +1 would intermingled code and declarations be considered OK (I personally dislike these), etc? Neither do I :-) +1, with the exception of declarations at the beginning of the block, which I find useful (I know this isn't C99). +1, although in general declarations in blocks should really be sparse and only for very local very temporary variables, and generally *not* for pointers that hold the only reference to allocated memory (as then a goto error statement will not be possible as the variable is out of context and can't be freed in the exception handling part of the code after the label). Features that I don't want to live without: 1. Standard struct initializers 2. Compound literals 3. For-loop declarations 4. Standard bool type I am pretty much +1 on C99 as the minimum common denominator for our code. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0026] Enable building in C99 mode
On 17.12.2013 14:38, Nathaniel McCallum wrote: On Tue, 2013-12-17 at 08:19 +0100, Jan Cholasta wrote: Hi, On 16.12.2013 22:12, Nathaniel McCallum wrote: Patch attached. Care to elaborate? There's no ticket or explanation why this is beneficial or necessary. It enables compiling with C99 features, which I personally find very beneficial. I am using these features (incomplete initializers and for-loop declarations) in my DS plugin code. It is 2014 after all, and most recent compilers support C11 at this point (certainly all the ones we care to support)... Nathaniel Can you put something like this explanation in the commit message please? -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Update: Re: Fedora 20 Release
On 12/16/2013 08:07 AM, Petr Spacek wrote: Hello list, we have to decide what we will do with 389-ds-base package in Fedora 20. Currently, we know about following problems: Schema problems: https://fedorahosted.org/389/ticket/47631 (regression) Fixed. Referential Integrity: https://fedorahosted.org/389/ticket/47621 (new functionality) https://fedorahosted.org/389/ticket/47624 (regression) Fixed. Replication: https://fedorahosted.org/389/ticket/47632 (?) Cannot reproduce. Closed as WORKSFORME. Stability: https://bugzilla.redhat.com/show_bug.cgi?id=1041732 Fixed. https://fedorahosted.org/389/ticket/47629 (we are not sure if the syncrepl really plays some role or not) We are still trying to determine the cause, and if this is related to the use of syncrepl. If it turns out to be related to syncrepl, I would like to release 1.3.2.9 in F20, and just disable the use of syncrepl in 389 clients. Is everyone ok with this? One option is to fix 1.3.2.x as quickly as possible. Another option is to build 1.3.1.x for F20 with Epoch == 1 and release it as quickly as possible. The problem with downgrade to 1.3.1.x is that it requires manual change in dse.ldif file. You have to disable 'content synchronization' (syncrepl) and 'whoami' plugins which are not in 1.3.1.x packages but were added and enabled by 1.3.2.x packages. In our tests, the downgraded DS server starts and works after manual dse.ldif correction (but be careful - we didn't test replication). Here is the main problem: 389-ds-base 1.3.2.8 is baked to Fedora 20 ISO images and there is not way how to replace it there. It means that somebody can do F19-F20 upgrade from ISO and *then* upgrade from repos will break his DS configuration (because of new plugins...). Simo thinks that this is a reason why 'downgrade package' with 1.3.1.x inevitably needs automated script which will purge two missing plugins from dse.ldif. Nathan, is it manageable before Christmas? One or either way? Is you think that the downgrade is safe from data format perspective? (I mean DB format upgrades etc.?) ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Update: Re: Fedora 20 Release
On 17.12.2013 17:40, Alexander Bokovoy wrote: On Tue, 17 Dec 2013, Rich Megginson wrote: On 12/16/2013 08:07 AM, Petr Spacek wrote: Hello list, we have to decide what we will do with 389-ds-base package in Fedora 20. Currently, we know about following problems: Schema problems: https://fedorahosted.org/389/ticket/47631 (regression) Fixed. Referential Integrity: https://fedorahosted.org/389/ticket/47621 (new functionality) https://fedorahosted.org/389/ticket/47624 (regression) Fixed. Replication: https://fedorahosted.org/389/ticket/47632 (?) Cannot reproduce. Closed as WORKSFORME. Stability: https://bugzilla.redhat.com/show_bug.cgi?id=1041732 Fixed. https://fedorahosted.org/389/ticket/47629 (we are not sure if the syncrepl really plays some role or not) We are still trying to determine the cause, and if this is related to the use of syncrepl. If it turns out to be related to syncrepl, I would like to release 1.3.2.9 in F20, and just disable the use of syncrepl in 389 clients. Is everyone ok with this? It works for me. Fine for me. Once you get update out, we can issue FreeIPA update that requires new 389-ds-base and slapi-nis (slapi-nis was already released so we cannot combine all three packages in the same update). I'm not sure that we need/want to release a freeipa package with new requires. Users just need to upgrade all packages as usual. (Note that users will not get the new freeipa package with new requires until they run yum upgrade anyway, so I don't see a big value in new release.) -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Update: Re: Fedora 20 Release
On 12/17/2013 11:35 AM, Rich Megginson wrote: On 12/16/2013 08:07 AM, Petr Spacek wrote: Hello list, we have to decide what we will do with 389-ds-base package in Fedora 20. Currently, we know about following problems: Schema problems: https://fedorahosted.org/389/ticket/47631 (regression) Fixed. Referential Integrity: https://fedorahosted.org/389/ticket/47621 (new functionality) https://fedorahosted.org/389/ticket/47624 (regression) Fixed. Replication: https://fedorahosted.org/389/ticket/47632 (?) Cannot reproduce. Closed as WORKSFORME. Stability: https://bugzilla.redhat.com/show_bug.cgi?id=1041732 Fixed. https://fedorahosted.org/389/ticket/47629 (we are not sure if the syncrepl really plays some role or not) We are still trying to determine the cause, and if this is related to the use of syncrepl. If it turns out to be related to syncrepl, I would like to release 1.3.2.9 in F20, and just disable the use of syncrepl in 389 clients. Is everyone ok with this? Rich I found a crash in 1.3.2 and 1.3.1. This should go into 1.3.2.9(or a 1.3.2.10). One option is to fix 1.3.2.x as quickly as possible. Another option is to build 1.3.1.x for F20 with Epoch == 1 and release it as quickly as possible. The problem with downgrade to 1.3.1.x is that it requires manual change in dse.ldif file. You have to disable 'content synchronization' (syncrepl) and 'whoami' plugins which are not in 1.3.1.x packages but were added and enabled by 1.3.2.x packages. In our tests, the downgraded DS server starts and works after manual dse.ldif correction (but be careful - we didn't test replication). Here is the main problem: 389-ds-base 1.3.2.8 is baked to Fedora 20 ISO images and there is not way how to replace it there. It means that somebody can do F19-F20 upgrade from ISO and *then* upgrade from repos will break his DS configuration (because of new plugins...). Simo thinks that this is a reason why 'downgrade package' with 1.3.1.x inevitably needs automated script which will purge two missing plugins from dse.ldif. Nathan, is it manageable before Christmas? One or either way? Is you think that the downgrade is safe from data format perspective? (I mean DB format upgrades etc.?) -- Mark Reynolds 389 Development Team Red Hat, Inc mreyno...@redhat.com ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Update: Re: Fedora 20 Release
On 12/17/2013 11:19 AM, Mark Reynolds wrote: On 12/17/2013 11:35 AM, Rich Megginson wrote: On 12/16/2013 08:07 AM, Petr Spacek wrote: Hello list, we have to decide what we will do with 389-ds-base package in Fedora 20. Currently, we know about following problems: Schema problems: https://fedorahosted.org/389/ticket/47631 (regression) Fixed. Referential Integrity: https://fedorahosted.org/389/ticket/47621 (new functionality) https://fedorahosted.org/389/ticket/47624 (regression) Fixed. Replication: https://fedorahosted.org/389/ticket/47632 (?) Cannot reproduce. Closed as WORKSFORME. Stability: https://bugzilla.redhat.com/show_bug.cgi?id=1041732 Fixed. https://fedorahosted.org/389/ticket/47629 (we are not sure if the syncrepl really plays some role or not) We are still trying to determine the cause, and if this is related to the use of syncrepl. If it turns out to be related to syncrepl, I would like to release 1.3.2.9 in F20, and just disable the use of syncrepl in 389 clients. Is everyone ok with this? Rich I found a crash in 1.3.2 and 1.3.1. This should go into 1.3.2.9(or a 1.3.2.10). Ok. One option is to fix 1.3.2.x as quickly as possible. Another option is to build 1.3.1.x for F20 with Epoch == 1 and release it as quickly as possible. The problem with downgrade to 1.3.1.x is that it requires manual change in dse.ldif file. You have to disable 'content synchronization' (syncrepl) and 'whoami' plugins which are not in 1.3.1.x packages but were added and enabled by 1.3.2.x packages. In our tests, the downgraded DS server starts and works after manual dse.ldif correction (but be careful - we didn't test replication). Here is the main problem: 389-ds-base 1.3.2.8 is baked to Fedora 20 ISO images and there is not way how to replace it there. It means that somebody can do F19-F20 upgrade from ISO and *then* upgrade from repos will break his DS configuration (because of new plugins...). Simo thinks that this is a reason why 'downgrade package' with 1.3.1.x inevitably needs automated script which will purge two missing plugins from dse.ldif. Nathan, is it manageable before Christmas? One or either way? Is you think that the downgrade is safe from data format perspective? (I mean DB format upgrades etc.?) ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Update: Re: Fedora 20 Release
On 12/17/2013 11:23 AM, Rich Megginson wrote: On 12/17/2013 11:19 AM, Mark Reynolds wrote: On 12/17/2013 11:35 AM, Rich Megginson wrote: On 12/16/2013 08:07 AM, Petr Spacek wrote: Hello list, we have to decide what we will do with 389-ds-base package in Fedora 20. Currently, we know about following problems: Schema problems: https://fedorahosted.org/389/ticket/47631 (regression) Fixed. Referential Integrity: https://fedorahosted.org/389/ticket/47621 (new functionality) https://fedorahosted.org/389/ticket/47624 (regression) Fixed. Replication: https://fedorahosted.org/389/ticket/47632 (?) Cannot reproduce. Closed as WORKSFORME. Stability: https://bugzilla.redhat.com/show_bug.cgi?id=1041732 Fixed. https://fedorahosted.org/389/ticket/47629 (we are not sure if the syncrepl really plays some role or not) We are still trying to determine the cause, and if this is related to the use of syncrepl. If it turns out to be related to syncrepl, I would like to release 1.3.2.9 in F20, and just disable the use of syncrepl in 389 clients. Is everyone ok with this? Rich I found a crash in 1.3.2 and 1.3.1. This should go into 1.3.2.9(or a 1.3.2.10). Ok. 389-ds-base-1.3.2.9 is now in Fedora 20 updates testing. Please test and give karma. This release fixes everything except https://fedorahosted.org/389/ticket/47629 random crash in send_ldap_search_entry_ext(), which, in my testing, appears to be related to syncrepl, and therefore imo should not hold up the release of 1.3.2.9 into Fedora 20. One option is to fix 1.3.2.x as quickly as possible. Another option is to build 1.3.1.x for F20 with Epoch == 1 and release it as quickly as possible. The problem with downgrade to 1.3.1.x is that it requires manual change in dse.ldif file. You have to disable 'content synchronization' (syncrepl) and 'whoami' plugins which are not in 1.3.1.x packages but were added and enabled by 1.3.2.x packages. In our tests, the downgraded DS server starts and works after manual dse.ldif correction (but be careful - we didn't test replication). Here is the main problem: 389-ds-base 1.3.2.8 is baked to Fedora 20 ISO images and there is not way how to replace it there. It means that somebody can do F19-F20 upgrade from ISO and *then* upgrade from repos will break his DS configuration (because of new plugins...). Simo thinks that this is a reason why 'downgrade package' with 1.3.1.x inevitably needs automated script which will purge two missing plugins from dse.ldif. Nathan, is it manageable before Christmas? One or either way? Is you think that the downgrade is safe from data format perspective? (I mean DB format upgrades etc.?) ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
