Quanah Gibson-Mount wrote:

--On Wednesday, January 20, 2010 11:50 AM -0600 sgmayo@mail.bloomfield.k12.mo.us wrote:

...

Is my db corrupted possibly after the electric outage? If so, is there a fix to run on it or will I just have to have a backup of it?

Thanks for any info.

I suggest looking into the "db_recover" command that matches with the version of BDB that your OpenLDAP is linked against. I'm not certain why you didn't spend some time trying to get error messages from slapd after rebooting, certainly nss_ldap isn't going to provide anything useful about why LDAP fails to start.

Thanks. I will look at the db_recover. I actually could not find any log files on slapd unless I am looking for the wrong thing.

I looked in /var/log, /var/lib/ldap, /var/run/openldap and other places, but could not find any logs. I checked the ldap.conf and slapd.conf file also to see if it had the location of where they were, but all I saw was a 256 log level.

Thanks again.

Quanah Gibson-Mount wrote:

--On Wednesday, January 20, 2010 12:28 PM -0600 sgmayo@mail.bloomfield.k12.mo.us wrote:

...

Quanah Gibson-Mount wrote:

...

--On Wednesday, January 20, 2010 11:50 AM -0600 sgmayo@mail.bloomfield.k12.mo.us wrote:

...

Is my db corrupted possibly after the electric outage? If so, is there a fix to run on it or will I just have to have a backup of it?

Thanks for any info.

I suggest looking into the "db_recover" command that matches with the version of BDB that your OpenLDAP is linked against. I'm not certain why you didn't spend some time trying to get error messages from slapd after rebooting, certainly nss_ldap isn't going to provide anything useful about why LDAP fails to start.

Thanks. I will look at the db_recover. I actually could not find any log files on slapd unless I am looking for the wrong thing.

I looked in /var/log, /var/lib/ldap, /var/run/openldap and other places, but could not find any logs. I checked the ldap.conf and slapd.conf file also to see if it had the location of where they were, but all I saw was a 256 log level.

Read the slapd man page

Specifically read up on the -d option for setting a debug level at startup for help with things like when slapd won't actually start up all the way.

Will do. I had found some old notes about doing a 'slapd -d 1' to start in debugging mode or something and I had done that, but it has been at the 'slapd starting' line ever since. I'll give it 15 minutes or so while I read up on the man page and see what it says. I am guessing this is the same place it hangs while actually rebooting the server.

Hopefully I can get this going today so everyone can get back to work. :)

Thanks again.

Quanah Gibson-Mount wrote:

--On Wednesday, January 20, 2010 7:42 PM +0100 Jaap Winius jwinius@umrk.nl wrote:

...

Irrelevant. What is preventing slapd from starting up? If the loglevel statement in your slapd.conf is still set to "none", comment it out, or set it to something more helpful (like 256), restart slapd and see what shows up in the syslog. If that doesn't give you enough information, increase the loglevel until it tells you why it's not starting up.

No amount of adjusting the loglevel in slapd.conf/slapd-config is going to help you get information on why slapd won't start if it never gets far enough to open syslog. Which is why I've suggested using slapd level debugging.

But most likely, the db simply needs to be recovered via the db_recover command, which I've already pointed Scott at.

Well..you were right. The '-1' got me a bit more info. :)

Here is what it says, I am guessing that this means it is up and listening alright.

slapd starting daemon: added 4r listener=(nil) daemon: added 7r listener=0x81451d8 daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=zero

Going to do the db_recover now and see what happens I guess.

Thank you so much for the help.

Quoting sgmayo@mail.bloomfield.k12.mo.us:

Quanah Gibson-Mount wrote:

...

No amount of adjusting the loglevel in slapd.conf/slapd-config is going to help you get information on why slapd won't start if it never gets far enough to open syslog. Which is why I've suggested using slapd level debugging.

Well..you were right. The '-1' got me a bit more info. :)

Quanah is correct, of course; if slapd keeps dying before it can ever write anything to a log, adjusting the loglevel won't help.

Here is what it says, I am guessing that this means it is up and listening alright.

If it's up, you should be able to see it with something like "ps ax". If you can see it, test that it's listening with "nmap localhost" (the output should include something like "389/tcp open ldap"). If it's listening, test if it responds to queries like "ldapsearch -x -LLL".

Also, even without slapd running, does the output from "slapcat" show anything familiar? If so, your database may not be the problem (if it is anyway, perhaps simply re-indexing would fix things, but that's more of a guess).

I've also just learned that Fedora doesn't maintain a /var/log/syslog by default. If you want to know where usual standard log outputs are being sent, check your log configuration (/etc/syslog.conf, or /etc/rsyslog.conf, or whatever it is on Fedora). With Debian, the stuff that slapd sends to my syslog is because of this line in /etc/rsyslog.conf:

*.*;auth,authpriv.none -/var/log/syslog

Thinking more broadly, have you checked that all of the server's filesystems were mounted properly after booting up? Or, if they're all mounted, maybe one critical to slapd is read-only, or has no free space for some reason.

Cheers,

Jaap

On Thu, Jan 21, 2010 at 6:02 AM, Todd Reed treed@astate.edu wrote:

I'm a little confused with implementing the memberOf overlay. I've seen some articles talk about the slapd.conf file; others are talking about an ldif file, etc. Two questions keep coming to my head everytime.

I have an Ubuntu box with OpenLDAP installed via apt-get. I need to utilize the memberOf attribute.

1. Based on my installation method (OpenLDAP from apt-get), what is the

suggested method to use to obtain the memberOf functionality?

2. Will I need to create an LDIF file for every group I have or create

in the future? Is there something I could do in the schema to always include the memberOf in the every user I create for any group?

Hi,

I think that the example in the docs is clear enough if you think it over :)

http://www.openldap.org/doc/admin24/overlays.html#Member%20Of%20Configuratio...

On Thu, Jan 21, 2010 at 6:26 PM, Todd Reed treed@astate.edu wrote:

Ok, I think I’m on the path, but still have not reached my destination.

I already have OpenLDAP up and running, but I need to add the memberOf overlay. From what I’ve read, the slapd.conf is being depricated. When I did my install, I never used the slapd.conf file and configured all the options LDIF ldapadds (sudo ldapadd -Y EXTERNAL -H ldapi:/// -f base.ldif).

Hi,

Well, maybe it is depreciated, but I won't touch it again by the time it is properly documented in the guide. It's not funny guessing the LDIFF structure to do something that was doable in slapd.conf within minutes.

Would I create a LDIF file with the memberOf configs, and if so, what would

that file look like,

Or, should I use the slapd.conf and do a “moduleload memberof.la” as a global setting? If I do this, will I overwrite any of my other changes that are not in this file (which may have been configured from the LDIFs)

I have went back to file-based config. If you do so, configuring memberof is as simple as reading the guide. (which again, should have proper examples for db-based config if somebody is depreceating it already :) )

Radek

On Thu, Jan 21, 2010 at 1:01 AM, alexs@ulgsm.ru wrote:

• sgmayo@mail.bloomfield.k12.mo.us sgmayo@mail.bloomfield.k12.mo.us [2010-01-20 11:50:12 -0600]:

...

Everything has been running fine for months.  We had a power outage this morning and I restarted my servers and things still seemed to be fine.  A bit later network drives could not be reached and so on.  I tried restarting LDAP and Samba, but it seems after the LDAP daemon was stopped, it could not restart.  I decided to reboot the server just in case and now the server just hangs while starting services.  This is a Fedora 10, so I booted with the CD to recovery mode so I could see logs.  Here is what my message log looks like.

Jan 20 11:27:56 school1 rpc.statd[1522] nss_ldap: failed to bind to LDAP server ldap://127.0.0.1 Can't contact LDAP server Jan 20 11:27:56 school1 rpc.statd[1522] nss_ldap: failed to bind to LDAP server ldap://10.0.0.100 Can't contact LDAP server Jan 20 11:27:56 school1 rpc.statd[1522] nss_ldap: reconnecting to LDAP server (sleeping 64 seconds)... Jan 20 11:29:00 school1 rpc.statd[1522] nss_ldap: failed to bind to LDAP server ldap://127.0.0.1 Can't contact LDAP server Jan 20 11:29:00 school1 rpc.statd[1522] nss_ldap: failed to bind to LDAP server ldap://10.0.0.100 Can't contact LDAP server Jan 20 11:29:00 school1 rpc.statd[1522] nss_ldap: could not search LDAP server - Server is unavailable Jan 20 11:29:00 school1 rpc.statd[1522] nss_ldap: failed to bind to LDAP server ldap://127.0.0.1 Can't contact LDAP server Jan 20 11:29:00 school1 rpc.statd[1522] nss_ldap: failed to bind to LDAP server ldap://10.0.0.100 Can't contact LDAP server Jan 20 11:29:00 school1 rpc.statd[1522] nss_ldap: reconnecting to LDAP server (sleeping 4 seconds)... Jan 20 11:29:04 school1 rpc.statd[1522] nss_ldap: failed to bind to LDAP server ldap://127.0.0.1 Can't contact LDAP server Jan 20 11:29:04 school1 rpc.statd[1522] nss_ldap: failed to bind to LDAP server ldap://10.0.0.100 Can't contact LDAP server Jan 20 11:29:04 school1 rpc.statd[1522] nss_ldap: reconnecting to LDAP server (sleeping 8 seconds)... Jan 20 11:29:12 school1 rpc.statd[1522] nss_ldap: failed to bind to LDAP server ldap://127.0.0.1 Can't contact LDAP server Jan 20 11:29:12 school1 rpc.statd[1522] nss_ldap: failed to bind to LDAP server ldap://10.0.0.100 Can't contact LDAP server Jan 20 11:29:12 school1 rpc.statd[1522] nss_ldap: reconnecting to LDAP server (sleeping 16 seconds)...

It is old nss trouble. spald is starting from ldap user, but user cant be resolved while slapd not running. And slapd cant be rinning while user not resolved.

In yours nss_ldap.conf put this bind_policy soft

usualy helps.

...

The 10.0.0.100 and 127.0.0.1 are the same server and is the one that LDAP is sitting on so it is not trying to contact another server with the 10.0.0.100.

Is my db corrupted possibly after the electric outage?  If so, is there a fix to run on it or will I just have to have a backup of it?

Thanks for any info.

-- Scott Mayo - System Administrator Bloomfield Schools PH: 573-568-5669  FA: 573-568-4565

Question: Because it reverses the logical flow of conversation. Answer: Why is putting a reply at the top of the message frowned upon?

-- alexs

Many documents I have read suggest that your ldap server should not use ldap authentication from itself. I agree with this. Not all OS's implement LDAP authentication exactly the same. Also not all operating systems start resources in the same order.

In this case setting 'bind_policy soft ' will probably help you get through a startup. Behind the scenes processes start are starting up, are looking up UID's and GID's your name server switch.

In any case always try a reboot and make sure your system can startup whatever. Sometimes these things 'seem' to be working until a reboot.