Urgent: today's F14 catastrophe with openldap-servers update

[Patrick Monnerat]

While applying today's updates on a machine running a slapd server, the
following error occurred:

Stopping slapd: [  OK  ]
Checking configuration files for slapd: [FAILED]
bdb(dc=linuxdev,dc=datasphere,dc=ch): Build signature doesn't match
environment
bdb_db_open: database "dc=linuxdev,dc=datasphere,dc=ch" cannot be
opened, err -30971. Restore from backup!
backend_startup_one (type=bdb,
suffix="dc=linuxdev,dc=datasphere,dc=ch"): bi_db_open failed! (-30971)
slap_startup failed (test would succeed using the -u switch)
stale lock files may be present in /var/lib/ldap[WARNING]
/var/lib/ldap /
/

as a result, the ldap server is not running anymore, I cannot start it
manually and I have no recent backup.

I cannot even use slapcat (after update) on the current data.

This is quite urgent since ldap data are heavily used by our
applications.
Please help !

Thanks

Patrick

[Michal Schmidt]

On Tue, 23 Nov 2010 11:11:13 +0100 Patrick MONNERAT wrote:
>  While applying today's updates on a machine running a slapd
> server,
>  the following error occurred: [...] 
Have you reported it as a bug against the openldap package?
Have you tried yum downgrade to the previous version?

Michal

[Patrick Monnerat]

On Tue, 2010-11-23 at 11:23 +0100, Michal Schmidt wrote:
>  On Tue, 23 Nov 2010 11:11:13 +0100 Patrick MONNERAT wrote:
>  > While applying today's updates on a machine running a slapd server,
>  > the following error occurred: [...]
>  
>  Have you reported it as a bug against the openldap package? 
Not yet: I'm really
busy trying to restore the production environment...
>  Have you tried yum downgrade to the previous version? 
I've
just done it: seems successful at first glance.
>  
>  Michal

[Paul Howarth]

On 23/11/10 10:11, Patrick MONNERAT wrote:
>  While applying today's updates on a machine running a slapd
> server, the
>  following error occurred:
>
>  Stopping slapd: [  OK  ]
>  Checking configuration files for slapd: [FAILED]
>  bdb(dc=linuxdev,dc=datasphere,dc=ch): Build signature doesn't match
>  environment
>  bdb_db_open: database "dc=linuxdev,dc=datasphere,dc=ch" cannot be
>  opened, err -30971. Restore from backup!
>  backend_startup_one (type=bdb,
>  suffix="dc=linuxdev,dc=datasphere,dc=ch"): bi_db_open failed! (-30971)
>  slap_startup failed (test would succeed using the -u switch)
>  stale lock files may be present in /var/lib/ldap[WARNING]
>  /var/lib/ldap /
>  /
>
>  as a result, the ldap server is not running anymore, I cannot start it
>  manually and I have no recent backup.
>
>  I cannot even use slapcat (after update) on the current data.
>
>  This is quite urgent since ldap data are heavily used by our
>  applications.
>  Please help ! 
Just had the same thing happen to me.

Worked around it by doing:

# yum downgrade openldap openldap-servers openldap-clients
# slapcat > my.ldif
# yum update openldap openldap-servers openldap-clients

Remove contents of /var/lib/ldap except DB_CONFIG

# slapadd < my.ldif
# chown ldap:ldap /var/lib/ldap/*
# restorecon -rvF /var/lib/ldap
# service slapd start

It came back up OK.

Looks like the new openldap is built against a different BerkeleyDB than 
the old one.

Paul.

[Panu Matilainen]

On Tue, 23 Nov 2010, Paul Howarth wrote:

>  On 23/11/10 10:11, Patrick MONNERAT wrote:
> > While applying today's updates on a machine running a slapd server, the
> > following error occurred:
> >
> > Stopping slapd: [  OK  ]
> > Checking configuration files for slapd: [FAILED]
> > bdb(dc=linuxdev,dc=datasphere,dc=ch): Build signature doesn't match
> > environment
> > bdb_db_open: database "dc=linuxdev,dc=datasphere,dc=ch" cannot be
> > opened, err -30971. Restore from backup!
> > backend_startup_one (type=bdb,
> > suffix="dc=linuxdev,dc=datasphere,dc=ch"): bi_db_open failed! (-30971)
> > slap_startup failed (test would succeed using the -u switch)
> > stale lock files may be present in /var/lib/ldap[WARNING]
> > /var/lib/ldap /
> > /
> >
> > as a result, the ldap server is not running anymore, I cannot start it
> > manually and I have no recent backup.
> >
> > I cannot even use slapcat (after update) on the current data.
> >
> > This is quite urgent since ldap data are heavily used by our
> > applications.
> > Please help !
>
>  Just had the same thing happen to me.
>
>  Worked around it by doing:
>
>  # yum downgrade openldap openldap-servers openldap-clients
>  # slapcat > my.ldif
>  # yum update openldap openldap-servers openldap-clients
>
>  Remove contents of /var/lib/ldap except DB_CONFIG
>
>  # slapadd < my.ldif
>  # chown ldap:ldap /var/lib/ldap/*
>  # restorecon -rvF /var/lib/ldap
>  # service slapd start
>
>  It came back up OK.
>
>  Looks like the new openldap is built against a different BerkeleyDB than
>  the old one. 
Yup, Berkeley DB is picky about its environment. It should be sufficient 
to to do 'rm -f /var/lib/ldap/__db.*; service slapd start' to recover 
from the upgrade.

 	- Panu -

[Panu Matilainen]

On Tue, 23 Nov 2010, Panu Matilainen wrote:

>  On Tue, 23 Nov 2010, Paul Howarth wrote:
>
> > On 23/11/10 10:11, Patrick MONNERAT wrote:
> >> While applying today's updates on a machine running a slapd server, the
> >> following error occurred:
> >>
> >> Stopping slapd: [  OK  ]
> >> Checking configuration files for slapd: [FAILED]
> >> bdb(dc=linuxdev,dc=datasphere,dc=ch): Build signature doesn't match
> >> environment
> >> bdb_db_open: database "dc=linuxdev,dc=datasphere,dc=ch" cannot be
> >> opened, err -30971. Restore from backup!
> >> backend_startup_one (type=bdb,
> >> suffix="dc=linuxdev,dc=datasphere,dc=ch"): bi_db_open failed! (-30971)
> >> slap_startup failed (test would succeed using the -u switch)
> >> stale lock files may be present in /var/lib/ldap[WARNING]
> >> /var/lib/ldap /
> >> /
> >>
> >> as a result, the ldap server is not running anymore, I cannot start it
> >> manually and I have no recent backup.
> >>
> >> I cannot even use slapcat (after update) on the current data.
> >>
> >> This is quite urgent since ldap data are heavily used by our
> >> applications.
> >> Please help !
> >
> > Just had the same thing happen to me.
> >
> > Worked around it by doing:
> >
> > # yum downgrade openldap openldap-servers openldap-clients
> > # slapcat > my.ldif
> > # yum update openldap openldap-servers openldap-clients
> >
> > Remove contents of /var/lib/ldap except DB_CONFIG
> >
> > # slapadd < my.ldif
> > # chown ldap:ldap /var/lib/ldap/*
> > # restorecon -rvF /var/lib/ldap
> > # service slapd start
> >
> > It came back up OK.
> >
> > Looks like the new openldap is built against a different BerkeleyDB than
> > the old one.
>
>  Yup, Berkeley DB is picky about its environment. It should be sufficient
>  to to do 'rm -f /var/lib/ldap/__db.*; service slapd start' to recover
>  from the upgrade. 
...but just in case: I'm not at all familiar with openldap specifics.
The openldap maintenance guide has the correct procedure for upgrades:
http://www.openldap.org/doc/admin24/maintenance.html (which is basically 
the steps explained by Paul above)

 	- Panu -

[Jan Vcelak]

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.

Jan

--
Jan Včelák
Base Operating Systems Brno
Red Hat Inc.

[Patrick Monnerat]

On Tue, 2010-11-23 at 14:55 +0100, Jan Vcelak wrote:

>  Patric, thank you for reporting this. And sorry for the difficulties.
You're welcome. And never mind for the difficulties: I understand your
trouble and I wouldn't be in such a sh... myself !

I succeeded in restoring the LDAP usability by downgrading to 2.4.22-7,
but I have to wait until after 16:00 UTC for the DB migration (after
production use stops).

Many thanks to all who helped.

Cheers,
Patrick

[Jesse Keating]

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?

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Jan Vcelak]

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

[Ralf Corsepius]

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

[Adam Williamson]

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

[Panu Matilainen]

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(a)redhat.com&gt; 2.4.23-1
- rebase to 2.4.23
- embeded db4 library removed

 	- Panu -

[Jan Vcelak]

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(a)redhat.com&gt; 2.4.23-1
>  - rebase to 2.4.23
>  - embeded db4 library removed
>  
>   	- Panu - 
You are right. My fault. :-(

[Panu Matilainen]

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(a)redhat.com&gt; 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 -

[Ralf Corsepius]

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(a)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

[Matej Cepl]

Dne 24.11.2010 03:28, Ralf Corsepius napsal(a):
>  No, it's not your fault (Or at least only partially). A
> functional QA 
>  would catch such kind of breakages. 
Yes, but functional QA would require more manpower than Fedora QA
currently has.

Matěj

[Ralf Corsepius]

On 11/24/2010 10:45 AM, Matej Cepl wrote:
>  Dne 24.11.2010 03:28, Ralf Corsepius napsal(a):
> > No, it's not your fault (Or at least only partially). A functional QA
> > would catch such kind of breakages.
>
>  Yes, but functional QA would require more manpower than Fedora QA
>  currently has. 
That's one perspective.

Another one is: The approach having been taken is 
non-feasible/impractiable/unsuiteable.

Ralf

[Michael Schwendt]

On Wed, 24 Nov 2010 11:03:41 +0100, Ralf wrote:

>  On 11/24/2010 10:45 AM, Matej Cepl wrote:
>  > Dne 24.11.2010 03:28, Ralf Corsepius napsal(a):
>  >> No, it's not your fault (Or at least only partially). A functional QA
>  >> would catch such kind of breakages.
>  >
>  > Yes, but functional QA would require more manpower than Fedora QA
>  > currently has.
>  
>  That's one perspective.
>  
>  Another one is: The approach having been taken is 
>  non-feasible/impractiable/unsuiteable. 
True. The appropriate action now would be to move the openldap package
onto a special QA list, which restricts the update acceptance criteria
further, so the openldap-servers must be tested, too. Especially if
the updates trigger database maintenance jobs.

[Jesse Keating]

On 11/23/2010 06:28 PM, Ralf Corsepius wrote:
>  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(a)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
>  
>  
>   
Fedora(.us) has never had what you would call a "functional QA".
Efforts are underway, and have been for a while.  Until in place, we
rely upon humans, first line of humans we rely upon is the maintainer.
Mistakes happen, and the approaches thus far are trying to provide a
window of opportunity to discover such mistakes, until such time as the
automated QA system can discover them for us, or at least provide hints
that there might be a mistake.

My original question was not an attempt to place blame, rather an
attempt to discover the scenario in which this mistake made it through,
so that we can use this info in further design attempts for QA.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Jan Vcelak]

Related question to other developers:

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.

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.

Imagine you have a large database. I would like to inform the user, that the 
database migration is in progress. Do you have some ideas?

Jan

[Alex Hudson]

On Tue, 2010-11-23 at 17:09 +0100, Jan Vcelak 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.
>  
>  Imagine you have a large database. I would like to inform the user, that the 
>  database migration is in progress. Do you have some ideas? 
I would have thought this was exactly the kind of task that shouldn't
happen during a stable release?

Cheers

Alex.


--
This message was scanned by Better Hosted and is believed to be clean.
http://www.betterhosted.com

[Jon Masters]

On Tue, 2010-11-23 at 17:09 +0100, Jan Vcelak wrote:

>  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. 
I was always told "no output allowed", which is sad. Sure, it might not
be seen in all cases. What would be cool is if there were some way to
indicate to RPM that progress was being made (some kind of incrementing
counter, or whatever) that could be pushed up to higher level stuff,
like PackageKit. I don't think there's anything today.

Jon.

[Chris Adams]

Once upon a time, Jan Vcelak <jvcelak(a)redhat.com&gt; 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(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Jan Vcelak]

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.

[Ben Boeckel]

Jan Vcelak <jvcelak(a)redhat.com&gt; 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=sel...

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/23/2010 08:54 PM, Ben Boeckel wrote:
>  Jan Vcelak <jvcelak(a)redhat.com&gt; 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=sel...
>   
SELinux is just relabeling the labels that have changed between the
previous and next release.  It attempts to find the least common
denominator.  But sometimes it could end up doing the equivalent of

restorecon -R -v /usr


> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkztD7sACgkQrlYvE4MpobNjlwCfai5eeCkhtcJzMQi+R6YUkWzF
> uQ8AnAmGOiLAzErBDHEv7NvTVyaif5I7
> =b/aB
> -----END PGP SIGNATURE-----

update for openldap available

[Jan Vcelak]

Just submitted to updates-testing. Please, test.

656257 - Upgrade from 2.4.22-7 to 2.4.23-3 breaks slapd
655899 - outdated list of overlays in slapd.conf
652822 - ldapsearch -Z hangs server if starttls fails

Jan

update for openldap available

[Patrick Monnerat]

On Tue, 2010-11-23 at 18:51 +0100, Jan Vcelak wrote:
>  Just submitted to updates-testing. Please, test.
>  
>  656257 - Upgrade from 2.4.22-7 to 2.4.23-3 breaks slapd
>  655899 - outdated list of overlays in slapd.conf
>  652822 - ldapsearch -Z hangs server if starttls fails
>  
>  Jan 
Many thanks Jan, it works.

I have downloaded your new files from koji and installed them with rpm
-F: perfect and the conversion was quite fast (I have a bit more than 3K
records in the DB).

Cheers,
Patrick

update for openldap available

[Radek Vokal]

On 11/23/2010 06:51 PM, Jan Vcelak wrote:
>  Just submitted to updates-testing. Please, test.
>
>  656257 - Upgrade from 2.4.22-7 to 2.4.23-3 breaks slapd
>  655899 - outdated list of overlays in slapd.conf
>  652822 - ldapsearch -Z hangs server if starttls fails
>
>  Jan 
Honzo, dik za rychlou reakci a perfektni komunikaci na f-develu! :)

Radek

-- 
Radek Vokál <rvokal(a)redhat.com&gt;
Engineering Manager - Base Operating Systems Brno

Office: [phone]
Mobile: [phone]
Red Hat Inc.                               http://cz.redhat.com

update for openldap available

[Matej Cepl]

Dne 24.11.2010 12:24, Radek Vokál napsal(a):
>  On 11/23/2010 06:51 PM, Jan Vcelak wrote:
> > Just submitted to updates-testing. Please, test.
> >
> > 656257 - Upgrade from 2.4.22-7 to 2.4.23-3 breaks slapd
> > 655899 - outdated list of overlays in slapd.conf
> > 652822 - ldapsearch -Z hangs server if starttls fails
> >
>  Honzo, dik za rychlou reakci a perfektni komunikaci na f-develu! :) 
Just a preliminary warning that Czech is going to be an official
language of the Fedora project. :)

Matěj