[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Really confusing responses (was: Re: Can't slapadd ldif file)

Hash: SHA1

Phil Dibowitz wanted us to know:

>OK, the first one is relatively simple. In order to make the migrate_all 
>script finish successfully I have to comment out the two lines where it 
>'imports' the 'protocols.' If I don't, I get:

Yes, the + signs create havoc.  I don't import much more than users and
groups.  The rest of that crap I leave in files.

>Now two observations here: one is the ++ which is obviously causing 
>ldap_add to have a cow, puke, convulse, and die a horrible painful 
>death. However, there are other areas where the script seemed smart. 
>Because I've seen stuff scroll be that's like:
>adding new entry "cn=bla\+\+,ou=......"
>So what's up with this one?

It's a series of scripts.  One is written better than the next.  That's
about all I can guess.

>Second "issue" is that the scripts include a 'passwd' migration but not 
>"shadow" migration. Now my ultimate goal is to centralize user 

First if you don't have this, add it:
if [ "X$ETC_SHADOW" = "X" ]; then

Then find the line that looks roughly like this in migrate_all_online.sh:
echo "Migrating users..."
$PERL -I${INSTDIR} ${INSTDIR}migrate_passwd.pl          $ETC_PASSWD >> $DB

And make it look like:
echo "Migrating users..."
$PERL -I${INSTDIR} ${INSTDIR}migrate_passwd.pl          $ETC_PASSWD >> $DB

Because in migrate_passwd.pl is this snippet of code:
    open(SHADOW, $ENV{ETC_SHADOW}) || return;

>Lastly, right after a run the migrate scripts (even if they're 
>completely successfuly), I can't run slapcat, or I get,
>slapcat: could not open database.

Is the ldap server still running?  If so, stop it.  Then slapcat should
work.  Never run slap* utilities while the ldap server process is

>At a guess I'd say ldap is holding new info in memory and the DB files 
>have been marked as 'not valid' or something.

First guess is that if you ran the offline tools, you were doing it as
root and all of the resulting files are owned by root so the ldap server
(which normally runs as user ldap) can't open them properly.

Another guess is that you have two versions of ldap installed, each
compiled against different versions of database.

I'd put money on the first though.  (That's never happened to me.
No........ :)

>If I restart the ldap server, I *can* use slapcat again. I assume this 
>is normal, but I thought I'd mention it just incase.

Almost certainly the directory files are owned by the wrong user.  But
again, DO NOT use the slap* tools while the ldap server (slapd) is

Good luck.
- -- 
Blue skies...		Todd
| Get a bigger hammer!   |  Two things prevent you from having    |
| http://www.mrball.net  |  sex with women:  sunlight & sobriety  |
| http://faq.mrball.net  |                          --Tom Leykis  |
   Linux kernel 2.4.19-16mdk   1 user,  load average: 0.01, 0.02, 0.00
Version: GnuPG v1.0.7 (GNU/Linux)