Re: slapd dying, what next?

[Bryan J. Maupin]

Well, I went ahead and built just the minimal tcmalloc (and upgraded it 
to 1.5 while I was at it), since that seemed to be something that needed 
to be fixed anyway.  I installed it to one of our replica servers, and 
it ran for about 3 days, and then slapd died again this morning.


So next I'm gonna upgrade to 2.4.21.  I'll probably do it on just one of 
our replica servers for now.


1. A 2.4.21 replica should work fine with a 2.4.19 master, correct?
2. On the machine I upgrade, can I just stop slapd, upgrade, and start 
slapd again, or should I slapcat/slapadd?


Thanks!

Quanah Gibson-Mount escribió:
--On Wednesday, January 20, 2010 8:39 AM -0600 Bryan J. Maupin 
bmau...@uta.edu wrote:


  

We're running on RHEL 5.4, with Heimdal 1.2.1-3, OpenSSL 0.9.8k,
Cyrus-SASL 2.1.23, BDB 4.7.25 (with patches), libunwind 0.99 (for Google
tcmalloc), Google tcmalloc 1.3.



libunwind is not required for tcmalloc, you must be building it incorrectly.

  

1. Is there any useful information that can be obtained from these log
entries, or do we simply need to change to a more verbose log level and
wait for slapd to die again?
2. If we need to change our log level, what is a suggested level?  Right
now we're using loglevel sync stats.  Would it be wise to change the
log level to -1 (any)?  These are production servers, and I imagine
that'd be a huge performance hit.
3. Also, we're logging asynchronously at the moment.  Should we disable
this while debugging?



I would suggest you

(a) Upgrade to 2.4.21
(b) Fix your tcmalloc build
(c) If the problem still occurs, run slapd under gdb so you can get a 
backtrace of some kind.


Make sure your OpenLDAP build, etc, has debugging symbols.

--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration
  

LDAP/Kerberos client config

[Jaap Winius]

Hi all,

Now that I'm satisfied with my OpenLDAP/Kerberos server configuration,  
I'm attempting to devise a suitable (Debian lenny) client setup for it.


Although I hear that it may not be the best approach, I'm currently  
pursuing a client configuration that includes kstart, libnss-ldap,  
nscd and libpam-ldap. At the moment I'm happy with all of it except  
libnss-ldap.


Kstart has no problem obtaining an initial Kerberos ticket, but I  
can't get libnss-ldap to use it to access the DIT. So far my  
libnss-ldap.conf looks like:


   base dc=example,dc=com
   uri ldap://ldapks1.example.com/
   ldap_version 3
   rootuse_sasl yes
   krb5_ccname FILE:/tmp/krb5cc_0

Any idea what I might be missing?

Thanks,

Jaap

Ppolicy, password lockout status

[Radosław Antoniuk]

Hi,

Quick question. How is it possible to check the account lock status?
I've configured the ppolicy according to the guide, the lock is
working, the account is locked.
And now how can I find out which accounts are currently locked out?

-- 
Best regards,
Radek Antoniuk
w: www.radek.org.pl

Re: Ppolicy, password lockout status

[Radosław Antoniuk]

On Mon, Jan 25, 2010 at 10:51 PM, Radosław Antoniuk
radek.anton...@gmail.com wrote:
 Hi,

 Quick question. How is it possible to check the account lock status?
 I've configured the ppolicy according to the guide, the lock is
 working, the account is locked.
 And now how can I find out which accounts are currently locked out?


Ok, found it, one has to do a search with the filter
'(pwdAccountLockedTime=*)' .
The interesting thing is that the query returns proper objects (the
locked ones) but it does not list the pwdAccountLockedTime attribute.
Anybody knows why?

Thanks,

Radek