1 (edited by blinden 2011-01-26 04:32:13)

Topic: LDAP start failure

rebooted server, and on reboot, LDAP errors out.  Getting in syslog:


Jan 25 15:18:56 mail postfix/smtpd[2687]: warning: problem talking to service rewrite: Connection reset by peer
Jan 25 15:18:56 mail postfix/smtpd[2566]: warning: problem talking to service rewrite: Success
Jan 25 15:18:56 mail postfix/master[2235]: warning: process /usr/lib/postfix/trivial-rewrite pid 2922 exit status 1
Jan 25 15:18:56 mail postfix/master[2235]: warning: /usr/lib/postfix/trivial-rewrite: bad command startup -- throttling
Jan 25 15:18:56 mail postfix/smtpd[2552]: warning: problem talking to service rewrite: Connection reset by peer
Jan 25 15:18:56 mail postfix/smtpd[2666]: warning: problem talking to service rewrite: Success
Jan 25 15:18:56 mail postfix/master[2235]: warning: process /usr/lib/postfix/trivial-rewrite pid 2923 exit status 1
Jan 25 15:18:56 mail postfix/smtpd[2817]: warning: problem talking to service rewrite: Connection reset by peer
Jan 25 15:18:56 mail postfix/smtpd[2815]: warning: problem talking to service rewrite: Success
Jan 25 15:18:56 mail postfix/master[2235]: warning: process /usr/lib/postfix/trivial-rewrite pid 2924 exit status 1

And when I go to start slapd:
Starting OpenLDAP: slapd - failed.
The operation failed but no output was produced. For hints on what went
wrong please refer to the system's logfiles (e.g. /var/log/syslog) or
try running the daemon in Debug mode like via "slapd -d 16383" (warning:
this will create copious output).

Below, you can find the command line options used by this script to
run slapd. Do not forget to specify those options if you
want to look to debugging output:
  slapd -h 'ldap:/// ldapi:///' -g openldap -u openldap -f /etc/ldap/slapd.conf

When I run in that debug mode, I get a LOT of output, as expected, I do notice this line:

/etc/ldap/slapd.d: line 1: warning: cannot assess the validity of the ACL scope within backend naming context

Since last reboot, I did generate new SSL keys and I changed domain of the system from a test domain to a live domain, so Ithink the problem lies somewhere therein.

2 (edited by blinden 2011-01-26 06:19:54)

Re: LDAP start failure

I wonder if this is a permissions problem on the SSL, what should the ownership and permissions look like for iRedMail.key and iRedMail_CA.pem?


**EDIT**
Well, the permissions look okay, 444, 400 for the cert and key.  both of them are showing as root/root, is the correct?

Also, when I try to do an openssl with -showcerts I get a connection refused error "errno=111"

3

Re: LDAP start failure

Sorry, 3rd post. I edit my existing post for updates, but major changes in status I make new post.

I'm sure it's a problem with the SSL now, because I commented out the lines:


#TLSCACertificateFile /etc/ssl/certs/iRedMail_CA.pem
#TLSCertificateFile /etc/ssl/certs/iRedMail_CA.pem
#TLSCertificateKeyFile /etc/ssl/private/iRedMail.key

in slapd.conf and it started up.  So, now what? unfortunately I'm not very familiar with SSL, and I'm far less familiar with LDAP, this is actually teh first time I've ever used it.

4

Re: LDAP start failure

Set "loglevel 256" in slapd.conf, restart it, and paste detail log in its log file.

Also, in your first post:

/etc/ldap/slapd.d: line 1: warning: cannot assess the validity of the ACL scope within backend naming context

iRedMail uses slapd.conf instead of slapd.d.

5

Re: LDAP start failure

blinden wrote:

**EDIT**
Well, the permissions look okay, 444, 400 for the cert and key.  both of them are showing as root/root, is the correct

Try to make them both 444.

The best way is 400, then grant "read" permission to ldap/apache/dovecot/postfix users with "setfacl", but let's try both 444 first.

6

Re: LDAP start failure

ZhangHuangbin wrote:
blinden wrote:

**EDIT**
Well, the permissions look okay, 444, 400 for the cert and key.  both of them are showing as root/root, is the correct

Try to make them both 444.

The best way is 400, then grant "read" permission to ldap/apache/dovecot/postfix users with "setfacl", but let's try both 444 first.

Works with both as 444, going to leave it be for now and deal with it in the morning, spent a tiring amount of time trying to sort this out today.  Thanks for the advice.