LDAP beschadigd na update Ubuntu 10.04 - 10.10

[Verwijderd]

Gisteren heb ik mijn Ubuntu server geupdate van versie 10.04 naar 10.10. Dit was nodig vanwege een aantal problemen met 10.04.
Nu is er een nieuw probleem ontstaan.
De LDAP server werkt ineens niet meer.
Het schijnt wederom een "foutje" te zijn van de ontwikkelaars (evenals het niet meer werken van een flink aantal WiFi kaarten etc... (!) ). Er is sprake van een database upgrade die niet goed wordt opgepakt, als ik het ingewikkelde verhaal goed begrijp.

Er zijn oplossingen beschikbaar op Internet maar geen enkele oplossing is goed genoeg. Het werkt niet en het blijft niet werken. In mijn netwerk gebruik ik de LDAP server voor meerdere dingen, dus een werkende LDAP functie is wel wenselijk.

Downgraden is geen optie want dan ontstaan er een stuk of tien nieuwe problemen.

Kan iemand mij aan een aantoonbaar werkende oplossing helpen?

[fikkie_84]

Als je wat meer uitleg kan geven over het daadwerkelijke probleem denk ik dat je beter kans maakt om iemand te vinden die je kan helpen.
Welke versie van ldap had je en naar wat heb je geupgrade?
Welke bugmelding heb je gevonden over "foutje" van de ontwikkelaars.
laat je ldap anders eens lopen in een debug mode en kijk naar je log files.
heb je een slapcat -l gedaan voor je deze upgrade deed en/of je /etc bewaart?
Kun je terugvallen op backups?
En als laatste opmerking, waarom zou je een server voorzien van een niet lts versie?

[Verwijderd]

LDAP versie was de standaard versie van Lucid (OpenLDAP 2.4.21). Huidige versie is de standaard versie van Maverick (OpenLDAP 2.4.23).

Bugmelding is bijvoorbeeld deze:
https://bugs.launchpad.ne...urce/openldap/+bug/658227

De daar voorgestelde oplossing werkt domweg niet.

LDAP draaien in debug mode lukt niet want slapd wil gewoon niet meer installeren.

Ik gebruik een niet LTS versie omdat de kwaliteit van de LTS versie (Lucid) ook om te janken is.
CUPS is werkelijk (...) met peren en de ondersteuning van wireless is sinds Lucid ook waardeloos.
En die ondersteuning van RaLink wireless dongles werkt in Ubuntu Maverick trouwens nog steeds niet.

En voordat er een wijsneus komt die me gaat vertellen: "dan compileer jezelf toch even weer de kernel".
Nee, dat doe ik niet. De ontwikkelaars zorgen er maar voor dat ze een goed product afleveren (ook al is het gratis) en niet een product dat na 3 releases nog steeds dezelfde fouten vertoond.

[blaataaps]

"Werkt domweg niet" en "wil gewoon niet meer installeren", dat zijn ook de details die de package managers geven als je het probeert, of geven ze ook nog echte foutmeldingen?

[fikkie_84]

Verwijderd schreef op zaterdag 12 maart 2011 @ 18:32:
LDAP versie was de standaard versie van Lucid (OpenLDAP 2.4.21). Huidige versie is de standaard versie van Maverick (OpenLDAP 2.4.23).

Bugmelding is bijvoorbeeld deze:
https://bugs.launchpad.ne...urce/openldap/+bug/658227

De daar voorgestelde oplossing werkt domweg niet.

LDAP draaien in debug mode lukt niet want slapd wil gewoon niet meer installeren.

Ik gebruik een niet LTS versie omdat de kwaliteit van de LTS versie (Lucid) ook om te janken is.
CUPS is werkelijk (...) met peren en de ondersteuning van wireless is sinds Lucid ook waardeloos.
En die ondersteuning van ts werkt in Ubuntu Maverick trouwens nog steeds niet.

En voordat er een wijsneus komt die me gaat vertellen: "dan compileer jezelf toch even weer de kernel".
Nee, dat doe ik niet. De ontwikkelaars zorgen er maar voor dat ze een goed product afleveren (ook al is het gratis) en niet een product dat na 3 releases nog steeds dezelfde fouten vertoond.

Waarom werkt de oplossing niet?
Heb je deze wel gedraait op een 10.04 en met een backup van je ldap configuratie of heb je de oplossing proberen te draaien onder de 10.10 release?

Ik snap ook even niet wat een wireless device te maken heeft me een server upgrade of gaat het hier om een desktop die ook als server dienst doet?

[jbhc]

Ik snap niet helemaal waarom je zo boos bent op Ubuntu. Je kunt natuurlijk ook gewoon redhat linux of windows server aanschaffen ook kun je trouwens gewoon betaalde support krijgen bij ubuntu:

http://www.ubuntu.com/business/services/server

Kost wat maar dan heb je ook een helpdesk die je kunt bellen voor dit soort problemen. Zoals bij alles krijg je waar je voor betaald.

Boos worden omdat een draadloze netwerkkaart in je server niet meer werkt is natuurlijk helemaal humor


Dus als je nou eerst eens een knappe topic start maakt die aan de regels voldoet en precies uitlegt wat het probleem is kan iemand je misschien helpen.

[ Voor 33% gewijzigd door jbhc op 13-03-2011 02:23 ]

[Verwijderd]

https://bugs.launchpad.ne...urce/openldap/+bug/658227

Daarin staat wat het algemene probleem is en wat ook het probleem bij mij is (een verandering in de onderliggende database structuur). Zelfs de foutmelding is letterlijk hetzelfde.
Ik zie niet in wat daar verder nog aan uit te leggen is.
De daar besproken oplossing heb ik toegepast op Ubuntu 10.10 zoals gesuggereerd wordt in comment #21 in die thread. Bovendien heb ik natuurlijk ook geen Ubuntu 10.04 meer want de rest van de upgrade doet het wel prima.

apt-get install db4.7-util

Dat leidt tot:

dpkg: fout bij afhandelen van slapd (--configure):
subproces installed post-installation script gaf een foutwaarde 1 terug
Fouten gevonden tijdens behandelen van:
slapd
E: Sub-process /usr/bin/dpkg returned an error code (1)

Goed dat zal wel te maken hebben met het database probleem. db4.7-util lijkt wel goed te installeren. Dit negeren we en werken verder.

cd ldap

Werkt alleen alleen als je eerst sudo su doet... OK, dat is niet echt een probleem.

db4.7_checkpoint -1

leidt tot:

db4.7_checkpoint: Program version 4.7 doesn't match environment version 4.8
db4.7_checkpoint: DB_ENV->open: DB_VERSION_MISMATCH: Database environment version mismatch

db4.7_recover

leidt tot:
db4.7_recover: Program version 4.7 doesn't match environment version 4.8
db4.7_recover: Unacceptable log file log.0000000001: unsupported log version 16
db4.7_recover: Invalid log file: log.0000000001: Invalid argument
db4.7_recover: PANIC: Invalid argument
db4.7_recover: process-private: unable to find environment
db4.7_recover: DB_ENV->open: DB_RUNRECOVERY: Fatal error, run database recovery


Dus: die workaround werkt op een of andere manier niet echt goed.
Die "unacceptable" log file is er trouwens wel maar daar staat geen leesbare tekst in en deze heeft bovendien een omvang van 10 MB. Niet echt geschikt om hier te tonen.

En ik ben niet boos op Ubuntu in het algemeen maar op de lakse houding van de ontwikkelaars.
In het geval van de falende wireless: Men is "vergeten" bepaalde essentiele bestanden mee te compileren. En schijnbaar is men dat drie kernel releases later (in 2.6.35 werkt het nog steeds niet) nog steeds vergeten.
In het geval van LDAP: Men heeft een verandering in de database structuur doorgevoerd die niet goed wordt opgepakt bij de upgrade.

Dit zijn gewoon vermijdbare fouten die je vindt als je uitgebreid test.

[ Voor 11% gewijzigd door Verwijderd op 13-03-2011 13:07 ]

[Verwijderd]

Dump de inhoud van je LDAP directory naar een bestand (LDIF), verwijder OpenLDAP, upgrade en installeer OpenLDAP weer. Daarna kun je de boel weer configureren en je LDIF importeren.

In Debian Squeeze ging dat ook zo hoerig.

Mocht het niet gaan dan moet je waarschijnlijk handmatig de database files converteren.

[ Voor 16% gewijzigd door Verwijderd op 13-03-2011 13:05 ]

[Verwijderd]

@Cheatah:
De upgrade is al gedaan.
OpenLDAP installeren gaat dus niet (althans waar het gaat om slapd), dus kennelijk moet ik eerst OpenLDAP helemaal weghalen.

Ik ga denk ik maar even voor de "moeilijke" methode; een verse installatie van OpenLDAP zonder achterblijvende rotzooi van de mislukte conversiepoging.

Hoe dump je de inhoud van LDAP naar LDIF (zonder een werkende OpenLDAP)?
Want ik wil de inhoud wel graag behouden.

[Verwijderd]

Dat slapd niet start is helder. De vraag is of slapcat nog werkt

Slapcat dumpt dus simpelweg alle data in LDIF formaat maar heeft de daemon niet nodig omdat de rauwe databasefiles worden gelezen.

[ Voor 50% gewijzigd door Verwijderd op 13-03-2011 13:13 ]

[Verwijderd]

Volgens mij heb ik slapcat nog niet eerder gebruikt. Ik heb de LDAP server aanvankelijk opgezet m.b.v. een uitleg op Internet.
Heb je een voorbeeld?

[mhaket]

http://lmgtfy.com/?q=slapcat

[Verwijderd]

slapcat

[Verwijderd]

Werkt niet.
Vraagt om een configuratie bestand.

[blaataaps]

En er zit geen manpage bij? De werking is helemaal geheim gehouden en staat nergens op internet? De exacte foutmelding is ook geheim?

[Verwijderd]

Die manpage heeft het over slapd.conf, dat bestand is er dus niet meer.

[jbhc]

Als het echt niet lukt en het moet werken kun je natuurlijk altijd de backup nog terug zetten die je natuurlijk hebt gemaakt voordat je een distro upgrade deed

Is het trouwens een idee om voor alle commando's die je geeft sudo te zetten?

[ Voor 20% gewijzigd door jbhc op 13-03-2011 15:17 ]

[Verwijderd]

OK, ik zal de moderator niet langer uitdagen met vage opmerkingen.

@jbhc: Nee, helaas sudo gebruiken maakt geen verschil.
Overigens heb ik nu wel uitgevonden dat als je in de workaround daar waar 4.7 staat dit vervangt door 4.8 dat dan opeens de LDAP server wel weer wil starten, alleen klaagt ie dan dat er "no such object" is. Dat komt natuurlijk omdat de inhoud beschadigd is.

Overigens heb ik een serie databestanden gevonden die kennelijk automatisch zijn gemaakt voor de upgrade (tenminste dat concludeer ik op basis van de timestamp).

Het zijn: __db.001 t/m __db.006, DB_CONFIG, dn2id.bdb, id2entry.bdb, objectClass.bdb en verder nog log0000000001.
In dn2id.bdb en id2entry.bdb kom ik informatie tegen die ik herken als zijnde de voormalige data van de server.
Vormen deze 11 bestanden een complete backup en is deze backup terug te zetten?
Volgens Google hebben in elk geval de .bdb bestanden van doen met de LDAP database.
Het nadeel is alleen dat deze bestanden dan kennelijk zijn van het oudere versie 2.4.21 formaat i.p.v. het nieuwere versie 2.4.23 formaat.

Intussen is slapd nog steeds niet geinstalleerd. Als ik de backup even tijdelijk weghaal en probeer slapd te installeren dan wordt de foutmelding die ik hier:
Verwijderd in "LDAP beschadigd na update Ubuntu 10.04 -..."
noemde anders. Ik zie nu:

Instellen van slapd (2.4.23-0ubuntu3.4) ...
Backing up /etc/ldap/slapd.d/ in /var/backups/slapd-2.4.21-0ubuntu5.3... done.
Moving old database directories to /var/backups:
- directory dc=mijnserver,dc=local... done.
Loading from /var/backups/slapd-2.4.21-0ubuntu5.3:
- directory dc=mijnserver,dc=local... failed.

Loading the database from the LDIF dump failed with the following
error while running slapadd:
/var/backups/slapd-2.4.21-0ubuntu5.3/dc=mijnserver,dc=local.ldif: No such file or directory
dpkg: fout bij afhandelen van slapd (--configure):
subproces installed post-installation script gaf een foutwaarde 1 terug
E: Sub-process /usr/bin/dpkg returned an error code (1)

Kennelijk denkt het programma dat de backup een ldif hoort te zijn of zo?

[ Voor 35% gewijzigd door Verwijderd op 14-03-2011 02:00 ]

[Raven]

Verwijderd schreef op zondag 13 maart 2011 @ 12:58:
En ik ben niet boos op Ubuntu in het algemeen maar op de lakse houding van de ontwikkelaars.
In het geval van de falende wireless: Men is "vergeten" bepaalde essentiele bestanden mee te compileren. En schijnbaar is men dat drie kernel releases later (in 2.6.35 werkt het nog steeds niet) nog steeds vergeten.
In het geval van LDAP: Men heeft een verandering in de database structuur doorgevoerd die niet goed wordt opgepakt bij de upgrade.

Dit zijn gewoon vermijdbare fouten die je vindt als je uitgebreid test.

nieuws: Linux-kernel 2.6.38 met 'wonder patch' vrijgegeven
"De kernel bevat verbeterde wifi-drivers voor Atheros-, Broadcom-, Intel-, Ralink- en Realtek-chipsets."

Lost dat jouw probleem op?

[Verwijderd]

@Raven:
Ik wacht eerst even af wat voor reacties er hier op T.net verschijnen over de nieuwe kernel.
Als er geen serieuze nieuwe problemen worden gevonden zal ik het eens testen.
Vooralsnog werkt wireless wel, maar uitsluitend o.b.v. een Karmic kernel en dat is een beetje verouderd dus.

Momenteel heeft het LDAP probleem nog aandacht nodig, alleen heb ik even weinig tijd ervoor.
Dat schiet dus nog niet echt op.

[Rainmaker]

Had je de configuratie voor de LDAP server in een cn=config tree gezet, of had je een "standaard" slapd.conf?

Voor een cn=config opstelling moet je namelijk slapcat2.4 gebruiken (op redhat, ligt een beetje aan de RPM's / DEB's die je gebruikt).

Anders kun je ook nog een database recovery proberen:

code:

slapd_db_recover2.4 -h /var/lib/ldap2.4

en hierna slapcat2.4'en

En er is ook nog een slapd_db_upgrade2.4 waarmee je (in principe) juist de database zou moeten kunnen upgraden (ik heb het nooit gebruikt, maar je kunt het proberen).

[Verwijderd]

@Rainmaker:

Bedankt voor je antwoord.

Sorry voor de late reactie, maar er waren wat andere dingen belangrijker zodoende ben ik hier niet eerder aan toegekomen.
De LDAP server staat inderdaad in een cn=config tree.

Die recovery methode klinkt veelbelovend want ik heb zo te zien een complete backup, maar ik heb nog niet eerder een recovery moeten doen.
Ik heb nu feitelijk een 2.4.21 database configuratie met een 2.4.23 LDAP server.
Gaat dat werken?

(En ik gebruik overigens Ubuntu 10.10)

[Rainmaker]

De versie van LDAP maakt niet zo gek veel uit, het gaat om je BDB versie in deze.

Mocht het allemaal niet lukken, is er altijd nog een uitweg; zet een VM op met 10.04 (juiste BDB / OpenLDAP versie), dan slapcat'ten en slapadd'en.

[Keeper of the Keys]

Debian (en daarmee Ubuntu) heeft al een tijd geleden de switch naar cn=config standaard (en automatisch) gemaakt.

Ik moest een tijdje geleden iets veranderen en in eerste instantie snapte ik niet waar mijn slapd.conf heen was.

Hoe dan ook heb je gecheckt of het upgrade script niet toevallig een ldif heeft gemaakt in /var/backups/slapd-2.4*.
Op mijn server zie ik dat het voor sommige upgrades is aangemaakt en voor anderen niet, waarschijnlijk afhankelijk van het risico...

(Ik zie ook dat ik al met ldap bezig ben sinds 2.2 en eigenlijk nooit problemen gehad met upgrades, het enige probleem dat ik heb gehad was toen ik besloot een ander management programma te gebruiken dat een andere structuur wilde in mijn database)

[Verwijderd]

In /var/backups/slapd-2.4* bevinden zich wel een paar ldif's maar die bevatten zo te zien geen informatie over de data, maar alleen over de structuur en rechten.

Zoals ik hierboven al schreef is er wel een soort backup in de zin van een aantal bestanden:
__db.001 t/m __db.006, DB_CONFIG, dn2id.bdb, id2entry.bdb, objectClass.bdb en verder nog log0000000001

Ik weet alleen niet of die terug te zetten zijn naar een bruikbare vorm.

De VM methode zal vast wel werken, maar daar schiet ik weinig mee op. Het probleem ontstaat, voorzover ik begrijp uit de informatie op internet, door een programmeerfout in Ubuntu 10.04. In de VM gaat dus hetzelfde probleem opnieuw optreden. Verder blijft natuurlijk het probleem hoe krijg ik dan de oorspronkelijke gegevens in de VM want er is immers geen gangbare backup.

[ Voor 8% gewijzigd door Verwijderd op 03-04-2011 17:39 ]

[Keeper of the Keys]

Wat ik begrijp uit de bugreport is dat de upgrade in eerste instantie niet de db goed update, maar de huidige status is "fix released" dat betekent voor zover ik het begrijp dat als je het in een VM nog eens doet de upgrade nu wel zou moeten werken.

Verder kun je ook in plaats van de upgrade de VM een werkende Lucid LDAP server laten zijn en de Maverick LDAP server via syncrepl de hele db laten binnen-trekken, of op de VM met slapcat de db dumpen en op Meverick de db binnenhalen met slapadd of met ldapadd.

[Verwijderd]

Ja, dat fixed released moet je kennelijk ook met een korrel zout nemen.
Het is zogenaamd in oktober 2010 al gefixed en in maart 2011 gaat het dus nog steeds fout.
Het zal wel fixed released zijn in Engelstalige versie of zo, maar zeer zeker niet in een Nederlandse versie.

Anyway, maakt ook niet uit.

Alle goede en welwillende adviezen hier ten spijt, maar ik schiet hier even niets mee op.
Ik heb hierboven meerdere keren genoemd dat er een kennelijke backup is die bestaat uit de genoemde bestanden. Kan iemand inderdaad bevestigen dat dit een bruikbare backup is.
Als het een bruikbare backup is kan ik de andere adviezen overwegen. Is het geen bruikbare backup dan is het einde verhaal en moet ik sowieso opnieuw beginnen en dan hoeven de andere adviezen dus ook niet meer.

Voor de duidelijkheid: ik begon ooit begonnen met LDAP omdat het me handig leek, en dat is het ook, de technische achtergrond heb ik me nog niet in verdiept.

[ Voor 9% gewijzigd door Verwijderd op 05-04-2011 18:49 ]

[Verwijderd]

Ja, het is een bruikbare backup. Ik heb hem ook gebruikt om te restoren op een server met dezelfde (oude) versie, en met slapcat een export te maken om te importeren in de nieuwe versie.

[Verwijderd]

OK dan. Inmiddels weer tijd gevonden om het probleem te tackelen en het is zowaar gelukt.
Intussen heb ik ook zoveel gerotzooid dat ik niet exact meer weet wat er allemaal is gebeurd, maar ik zal kort beschrijven wat het verschil maakt want dit kan misschien iemand anders helpen.

De groep bestanden die ik eerder genoemd heb vormen inderdaad een complete backup (bedankt voor de tip Cheatah!).

Je doet nu dit:
- Stop eerst de LDAP server voorzover deze werkt.
- De folder waar de niet werkende bestanden staan gooi je volledig leeg. In mijn geval is dat /var/lib/ldap.
- De werkende backup zet je nu terug in deze folder. Opgelet: als de backup ergens anders staat gaat het kennelijk niet werken. Dit zal wel een inkoppertje zijn, maar het heeft behoorlijk lang geduurd voordat ik het in de gaten had.

- Doe nu:
1) apt-get install db4.X-util (waarbij 4.X staat voor het versienummer van je LDAP database. Op dit moment is dat 4.8 (of de iets oudere 4.7). Je merkt het vrij snel aan evt. foutmeldingen of je de juiste versie hebt.
2) cd /var/lib/ldap, alleen als je nog niet in die map was.
3) db4.X_dump id2entry.bdb (of in elk geval een bestand met een bdb extensie)
Bovenstaande hoort een stroom data te produceren en geen versie mismatch. Als je de versie mismatch krijgt moet je dus een andere versie van de utils hebben.

Tenslotte doe je:
4) db4.X_recover -v

Daarna kan je de LDAP server weer starten en zou het moeten werken.


Iedereen die meegedacht heeft bedankt voor de moeite en de tips.

[CAPSLOCK2000]

tnx voor de update

[Verwijderd]

Graag gedaan.

Toch blijkt de recovery procedure niet helemaal de definitieve oplossing te zijn.
Recoveren krijgt de server wel weer aan de gang, maar slapcatten gaat op allerlei manieren fout met een lading foutmeldingen die er op neerkomen dat er toch nog sprake is van een versie mismatch tussen de server en de database. Bovendien blijkt de recovery een paar bestanden weg te halen die je toch nodig hebt.

Inmiddels heb ik een (nogal oud) script gevonden op Internet die er voor lijkt te zorgen dat de server weer werkt en dat bovendien de versie mismatch wordt opgelost.

Het script ziet er als volgt uit:

#!/usr/bin/env bash

# Appears to fix the following errors when running slaptest:
# bdb_db_open: database "dc=yourdomain,dc=local": db_open(/var/lib/ldap/id2entry.bdb) failed: No such file or directory (2).
# backend_startup_one (type=bdb, suffix="dc=yourdomain,dc=local"): bi_db_open failed! (2)

# Assumes you have customized the following configuration files:
# - /etc/openldap/slapd.conf
# - /etc/openldap/ldap.conf

# Default settings are work on Red Hat based distros currently:
SERVICE_NAME=slapd
LDAP_LIB_DIR=/var/lib/ldap
LDAP_RUN_DIR=/var/run/openldap
LDAP_PID_FILE=${LDAP_RUN_DIR}/${SERVICE_NAME}.pid
LDAP_ARG_FILE=${LDAP_RUN_DIR}/${SERVICE_NAME}.args
LDAP_DATA_FILES="__db.001 __db.002 __db.003 __db.004 __db.005 __db.006 alock"
LDAP_USER=openldap
LDAP_GROUP=openldap
SYS_RUN_DIR=/var/run
SYS_PID_FILE=${SYS_RUN_DIR}/${SERVICE_NAME}.pid

# Start of execution flow
sudo service ${SERVICE_NAME} stop

# Remove screwed up BDB files from OpenLDAP data directory
for f in ${LDAP_DATA_FILES};
do
path=${LDAP_LIB_DIR}/${f};
[ -f ${path} ]; sudo -u ${LDAP_USER} rm ${path};
done

# Make sure the DB_CONFIG file and any log files remaining have the correct ownership
sudo chown -R ${LDAP_USER}:${LDAP_GROUP} ${LDAP_LIB_DIR}

sudo service ${SERVICE_NAME} start


Dat is gebaseerd op het voorbeeld hier: https://gist.github.com/612203
En het bevat een paar aanpassingen die ik heb gemaakt om het werkend te krijgen onder Ubuntu.