FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 11-23-2010, 03:33 PM
Chris Adams
 
Default Urgent: today's F14 catastrophe with openldap-servers update

Once upon a time, Jan Vcelak <jvcelak@redhat.com> said:
> Am I allowed to write some additional output in %pre/%post scriptlets? And
> shall I use stdout or stderr? I haven't found it in guidelines.

No, because there's no telling where it will go.

> This is the problem: The database migration could take a really long time. I
> have testing data with 56 entries (nodes) - exporting (slapcat) is quite fast,
> but importing (slapadd) takes around 10 seconds.

This is usually a problem of improper (or missing) DB_CONFIG (the
openldap-servers package should probably include one in /var/lib/ldap,
not just a sample in a directory where nobody will look).

Also, you can use the "-q" option to speed up slapadd (since you should
have a consistent database already).

--
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-23-2010, 04:11 PM
Jan Vcelak
 
Default Urgent: today's F14 catastrophe with openldap-servers update

On Tuesday 23 November 2010 17:30:31, Jesse Keating wrote:
> Why was this update made on F14 in the first place?

I admit, that this was a slight violation of the rules. This is my defence:
There vere no changes between 2.4.22 and 2.4.23, only bugfixes (according to
upstream changelog). The last critical change was switching from OpenSSL to
Mozilla NSS. And these changes were already in F14.

Quite a lot of issues sliped trough our fingers during the testday [1]. And I
really tought, merging master into f14 will not break anything and make fixing
these TLS bugs easier.

I didn't notice this database migration problem. I don't know why, as I tested
it, but it happend. And I was confident, that the migration will be needed
only when minor version changes. The update even passed updates-testing
process [2]. (It seems most people are using only openldap-clients.)

I'm sorry. The fix is ready. I will build it in a while.

Jan

[1] https://fedoraproject.org/wiki/Test_Day:2010-10-14_OpenLDAP/NSS
[2] https://admin.fedoraproject.org/updates/openldap-2.4.23-3.fc14
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-23-2010, 04:11 PM
Jan Vcelak
 
Default Urgent: today's F14 catastrophe with openldap-servers update

On Tuesday 23 November 2010 17:33:40, Chris Adams wrote:
> Also, you can use the "-q" option to speed up slapadd (since you should
> have a consistent database already).

Thanks! This helps.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-23-2010, 04:21 PM
Ralf Corsepius
 
Default Urgent: today's F14 catastrophe with openldap-servers update

On 11/23/2010 05:30 PM, Jesse Keating wrote:
> On 11/23/10 5:55 AM, Jan Vcelak wrote:
>> Hi!
>>
>> Currently, the upgrade process in openldap looks like this:
>> * during db4 package upgrade run db_upgrade (%triggerin and %triggerun)
>> * if minor version of openldap changes (e.g. 2.3 -> 2.4), export the database,
>> delete it and import it back (which is recommended by maintanence guide, as
>> Panu mentioned)
>>
>> We didn't wanted to do the export+import during each upgrade, as it takes
>> quite a long time if you have large database. But it seems that current
>> process doesn't work and that doing it every time will be the safest way.
>> (Maybe we can ignore epoch changes.)
>>
>> Thanks for suggestions. I will fix it today and push an update.
>>
>> Patric, thank you for reporting this. And sorry for the difficulties.
>
> Why was this update made on F14 in the first place?
>
IMO, this is the wrong question.

The better questions would be - How could it happen, this package made
it into updates, dispite all this QA bureaucracy is in place?

Ralf
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-23-2010, 04:30 PM
Adam Williamson
 
Default Urgent: today's F14 catastrophe with openldap-servers update

On Tue, 2010-11-23 at 18:21 +0100, Ralf Corsepius wrote:

> > Why was this update made on F14 in the first place?
> >
> IMO, this is the wrong question.
>
> The better questions would be - How could it happen, this package made
> it into updates, dispite all this QA bureaucracy is in place?

Remember, critpath testing is intended to ensure that *critical path
functionality* is not broken. The LDAP functionality that's critpath is
_client_ functionality, not server functionality: if you run in an LDAP
environment you need the openldap client functionality to log in.

So it was the client functionality that was tested by those who approved
the update, mostly:

"jhrozek - 2010-11-18 13:24:44
This update fixed both #652315 and #652304 for me. So far no
regressions." (they're both client-side bugs)

"jlaska (proventesters) - 2010-11-18 21:16:59
I've tested the client in my existing SSSD setup. I've done some *basic*
testing of slapd and related binaries to ensure they can survive basic
execution"

I've said before that the critpath process does not ensure, nor does it
aim to ensure, that nothing that goes through the critpath testing ever
has problems, or regressions; what it aims to ensure is that the
critical path functionality isn't broken. Of course, given the laws of
Murphy and Sod, even this is not a guarantee, it's just what the process
aims for.

(You can look at this as ammo for the other side, too: the maintainer
did a version bump that looked perfectly reasonable to him, as he
explained at length...yet it turns out to have a significant problem.
This is a good example of why, if you want a truly stable release
process, you don't do even updates that look perfectly safe unless
they're really needed, and you test the updates as far as is practical.)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-23-2010, 05:13 PM
Panu Matilainen
 
Default Urgent: today's F14 catastrophe with openldap-servers update

On Tue, 23 Nov 2010, Ralf Corsepius wrote:

> On 11/23/2010 05:30 PM, Jesse Keating wrote:
>> On 11/23/10 5:55 AM, Jan Vcelak wrote:
>>> Hi!
>>>
>>> Currently, the upgrade process in openldap looks like this:
>>> * during db4 package upgrade run db_upgrade (%triggerin and %triggerun)
>>> * if minor version of openldap changes (e.g. 2.3 -> 2.4), export the database,
>>> delete it and import it back (which is recommended by maintanence guide, as
>>> Panu mentioned)
>>>
>>> We didn't wanted to do the export+import during each upgrade, as it takes
>>> quite a long time if you have large database. But it seems that current
>>> process doesn't work and that doing it every time will be the safest way.
>>> (Maybe we can ignore epoch changes.)
>>>
>>> Thanks for suggestions. I will fix it today and push an update.
>>>
>>> Patric, thank you for reporting this. And sorry for the difficulties.
>>
>> Why was this update made on F14 in the first place?
>>
> IMO, this is the wrong question.
>
> The better questions would be - How could it happen, this package made
> it into updates, dispite all this QA bureaucracy is in place?

Like Adam already pointed out, it appears that it was mostly the client
parts that got tested. Bodhi makes no difference between simple packages
vs those that have half a dozen different subpackages consisting of wildly
different functionality (such as client and server parts) that need
completely different testing methods. Requiring separate
acks/karma/whatever for each sub-package would be a huge overkill in most
cases but then there are cases like this...

Another related thing is that Berkeley DB which openldap uses is
notoriously picky about getting updated. I'm fairly certain openldap does
not update their bundled BDB version to prevent issues like this on minor
updates, and AFAICT (based on a quick lookaround at the changelogs etc) in
this case it was this fix to comply with our own policies (no bundled
libraries) that bit us when synced with rawhide version:

* Fri Aug 27 2010 Jan Vcelak <jvcelak@redhat.com> 2.4.23-1
- rebase to 2.4.23
- embeded db4 library removed

- Panu -
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-23-2010, 05:36 PM
Jan Vcelak
 
Default Urgent: today's F14 catastrophe with openldap-servers update

On Tuesday 23 November 2010 19:13:09, Panu Matilainen wrote:
> Another related thing is that Berkeley DB which openldap uses is
> notoriously picky about getting updated. I'm fairly certain openldap does
> not update their bundled BDB version to prevent issues like this on minor
> updates, and AFAICT (based on a quick lookaround at the changelogs etc) in
> this case it was this fix to comply with our own policies (no bundled
> libraries) that bit us when synced with rawhide version:
>
> * Fri Aug 27 2010 Jan Vcelak <jvcelak@redhat.com> 2.4.23-1
> - rebase to 2.4.23
> - embeded db4 library removed
>
> - Panu -

You are right. My fault. :-(
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-23-2010, 05:42 PM
Panu Matilainen
 
Default Urgent: today's F14 catastrophe with openldap-servers update

On Tue, 23 Nov 2010, Jan Vcelak wrote:

> On Tuesday 23 November 2010 19:13:09, Panu Matilainen wrote:
>> Another related thing is that Berkeley DB which openldap uses is
>> notoriously picky about getting updated. I'm fairly certain openldap does
>> not update their bundled BDB version to prevent issues like this on minor
>> updates, and AFAICT (based on a quick lookaround at the changelogs etc) in
>> this case it was this fix to comply with our own policies (no bundled
>> libraries) that bit us when synced with rawhide version:
>>
>> * Fri Aug 27 2010 Jan Vcelak <jvcelak@redhat.com> 2.4.23-1
>> - rebase to 2.4.23
>> - embeded db4 library removed
>>
>> - Panu -
>
> You are right. My fault. :-(

Mind you, I certainly didn't mean the above as pointing fingers or
blaming, but more as an example of one generic pitfall: It's incredibly
easy to forget / overlook one tiny little change which one did several
months ago ... and have it come biting when applied to a different
release, even if it's just F x-1 like here.

- Panu -
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-24-2010, 12:54 AM
Ben Boeckel
 
Default Urgent: today's F14 catastrophe with openldap-servers update

Jan Vcelak <jvcelak@redhat.com> wrote:
> This is the problem: The database migration could take a really long time. I
> have testing data with 56 entries (nodes) - exporting (slapcat) is quite fast,
> but importing (slapadd) takes around 10 seconds.

Hmm. I've seen selinux-policy-targeted take longer than this on
upgrades. SELinux is a little more obvious that it's doing something on
upgrade (and after looking at the spec file[1], I'd not sure whether I'd
have rather not known ), but I don't think it'd be unheard of.

--Ben

[1]http://pkgs.fedoraproject.org/gitweb/?p=selinux-policy.git;a=blob;f=selinux-policy.spec

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-24-2010, 01:28 AM
Ralf Corsepius
 
Default Urgent: today's F14 catastrophe with openldap-servers update

On 11/23/2010 07:36 PM, Jan Vcelak wrote:
> On Tuesday 23 November 2010 19:13:09, Panu Matilainen wrote:
>> Another related thing is that Berkeley DB which openldap uses is
>> notoriously picky about getting updated. I'm fairly certain openldap does
>> not update their bundled BDB version to prevent issues like this on minor
>> updates, and AFAICT (based on a quick lookaround at the changelogs etc) in
>> this case it was this fix to comply with our own policies (no bundled
>> libraries) that bit us when synced with rawhide version:
>>
>> * Fri Aug 27 2010 Jan Vcelak<jvcelak@redhat.com> 2.4.23-1
>> - rebase to 2.4.23
>> - embeded db4 library removed
>>
>> - Panu -
>
> You are right. My fault. :-(

No, it's not your fault (Or at least only partially). A functional QA
would catch such kind of breakages.

Ralf



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 04:52 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org