2.3.39 syncrepl lost connection
by Francis Swasey
I have a strange problem that is causing me to go nuts.
I have five servers all on RHEL v4, all with OpenLDAP 2.3.39 (locally
built RPM). The master server is a VMWare guest, one of the replicas is
a blade, the other three are 2U boxes.
Twice now two of the four replicas have stopped updating at around
2:45am. It was not the same two both times (although the blade was one
of them both times).
All five servers have loglevel set to "stats sync".
There was nothing logged on either end about any network error and my
networking folks have looked at all the logs for all the ports involved
and found nothing. Although, my first thought was something in the
network because we just moved these to a brand new data center.
The fix both times so far has been to recycle slapd on the two replicas
and they get caught up in minutes.
The syncrepl config on the replicas is for refreshAndPersist and does a
retry every 30 seconds -- so, if the replica knew the connection had
dropped, it should have restarted it.
We run a command via nagios (nrpe) on each replica every five minutes
that compares the contextcsn of the replica and the master. I see those
connections/queries in the logs on the master continuing and nagios
eventually yells that we're dreadfully behind on the replicas.
Has anyone seen something like this before -- or have a suggestion of a
method of figuring out why/where the connection is getting broken?
Thanks,
--
Frank Swasey | http://www.uvm.edu/~fcs
Sr Systems Administrator | Always remember: You are UNIQUE,
University of Vermont | just like everyone else.
"I am not young enough to know everything." - Oscar Wilde (1854-1900)
15 years, 2 months
Having an issue with SSF
by Pat Riehecky
I am trying to take advantage of the localSSF option in OpenLDAP 2.4.
This system will only allow one user to login and I like to leave a door
for me to get back in if I forget the admin password.
My goal is to get the local socket running with no security and require
anyone using a TCP connection to use TLS with at least a 3DES cypher. I
would prefer updates happen over a higher grade encyption, but eh....
In doing so I have put the following in my slapd.conf
.....
localSSF 0
sasl-secprops noplain,noanonymous,minssf=112
security ssf=112 update_ssf=128 simple_bind=112 tls=112
#######################################################################
# Specific Backend Directives for hdb:
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
backend hdb
......
It seems I have done something a great deal wrong. The system is now
enforcing strong authentication over ldapi:/// this is the exact
opposite of my plan.
What on earth did I do wrong?
Pat
Debian Etch, packages from sid.
15 years, 2 months
Running slapd as a non-root user
by Bill Sterns
I'm currently running OpenLDAP 2.4.6 using SSL/TLS via OpenSSL 0.9.8b and Berkeley DB 4.6.21, which I built and installed from source as root. I'd like to be able to run slapd as a non-root user, as I've seen other packaged OpenLDAP distributions do in the past. However, when I try to run it as a non-root user, OpenLDAP does not have permission to access various things, such as slapd.conf, the back-end database files, and the directory to create its pid file when it starts up. I've tinkered with the file/group ownership and permissions for these files, and I've managed to get it running as a non-root user, but I'm not sure if this is the ideal way to do it. Is there a recommended way to do this?
This is what I get when I initially try to run slapd as a non-root user:
# /usr/local/libexec/slapd -d 256 -u openldap -h ldaps:///
@(#) $OpenLDAP: slapd 2.4.6 (Jan 29 2008 18:42:36) $
bill@bill1:/home/bill/openldap-2.4.6/servers/slapd
could not open config file "/usr/local/etc/openldap/slapd.conf": Permission denied (13)
slapd stopped.
connections_destroy: nothing to destroy.
Here's what I've done to run slapd as a non-root user:
1. Created user/group of openldap/openldap, put the openldap user in the openldap group
2. Ran: chgrp openldap slapd.conf # This was originally owned by the group "other"
3. Ran: chmod 640 slapd.conf # This was originally 600
4. Ran: chgrp -R openldap /usr/local/etc/openldap/certs # Certs for SSL/TLS; originally owned by the group "other"
5. Ran: chmod 440 /usr/local/etc/openldap/certs/host.key # Private key for SSL/TLS; originally 400
6. Ran: chgrp -R openldap /usr/local/var/openldap-data # Back-end bdb; originally owned by the group "other"
7. Ran: chmod 775 /usr/local/var/openldap-data # Originally 755
8. Ran: chmod g+s /usr/local/var/openldap-data
8. Ran: chgrp openldap /usr/local/var/run # Originally owned by the group "other"
9. Ran: chmod 775 /usr/local/var/run # Originally 755
10. Ran: chmod 660 /usr/local/var/openldap-data/* # Originally 600, except for alock
11. Ran: chmod 664 /usr/local/var/openldap-data/alock # Originally 644
After these steps, I can bring up OpenLDAP as my "openldap" user:
# /usr/local/libexec/slapd -d 256 -u openldap -h ldaps:///
@(#) $OpenLDAP: slapd 2.4.6 (Jan 29 2008 18:42:36) $
bill@bill1:/home/bill/openldap-2.4.6/servers/slapd
bdb_monitor_open: monitoring disabled; configure monitor database to enable
slapd starting
Am I going about this the right way? Is running OpenLDAP as a non-root user a non-recommended thing to do when using an installation built from source? And are there any other gotchas that might cause problems later? One possible problem I can think of is if the database needs to be wiped and recreated from a backed-up LDIF file using slapadd; if slapadd is run as root, the permissions would have to be reset on the database files before slapd could start up.
Any help would be greatly appreciated.
Thanks,
-Bill
_________________________________________________________________
Helping your favorite cause is as easy as instant messaging. You IM, we give.
http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join
15 years, 2 months
Re: Invalid syntax on ldapadd
by Quanah Gibson-Mount
--On Tuesday, January 29, 2008 4:01 PM -0500 Vinh.CTR.Hoang(a)faa.gov wrote:
>
> Oh i was going to ask about that. the x option is illegal for some
> reason. I might of been using the solaris ldapadd. Is there a way to
> tell which is which? I install openldap as a package so I don't really
> know where the OpenLDAP ldapadd went.
Keep replies on the list if you want further help.
type "which ldapadd" to see where the ldapadd you are using is located. If
you don't know where the OpenLDAP installation put things, I suggest you
figure that out first.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
15 years, 2 months
ldap + ssl confusion
by Steve Pribyl
Good Morning,
I need some help understanding why thing are the way they are.
All nodes run
slapd 2.3.34
slurpd 2.3.34
on Fedora 7
All nodes keys are self authenticated, i.e. links to from hash.
!!The Problem!!
ldapsearch works to NodeB server, iff NodeB_key is present on NodeA
slurpd works to NodeB server, iff NodeB_key is present on NodeA
Node A - ldap master/client
/etc/ldap/cacerts/NodeA_pub.pem
/etc/ldap/cacerts/NodeB_pub.pem
/etc/pki/tls/certs/NodeA_key.pem
ldapsearch works to NodeA ldap server.
/etc/pki/tls/certs/NodeB_key.pem <--Why is this required?
ldapsearch works to NodeB server, iff NodeB_key is present on NodeA
slurpd works to NodeB server, iff NodeB_key is present on NodeA
Node B - ldap slave/client
/etc/ldap/cacerts/NodeA_pub.pem
/etc/ldap/cacerts/NodeB_pub.pem
/etc/pki/tls/certs/NodeB_key.pem
ldapsearch works to all ldap servers.
Node C - ldap client
/etc/ldap/cacerts/NodeA_pub.pem
/etc/ldap/cacerts/NodeB_pub.pem
No Keys present
ldapsearch works to all ldap servers.
More details can be provied.
--
Steve Pribyl
Infrastructure Practitioner
Peel, Inc
990 Grove St. Suite 204
Evanston, IL 60201
Phone: 847-424-0954 ex 14
Cell: 847-434-2349
Fax: 847-424-0986
spribyl(a)peel.com
15 years, 2 months
Invalid syntax on ldapadd
by Vinh.CTR.Hoang＠faa.gov
Hi, I'm very new ldap, and i'm wondering if you guys can help me with
something.
I'm going over the some tutorials to setup ldap for authentication.
However, I can't seem to be able to add any users or groups.
I'm Solaris 9, w/ openldap 2.3.35.
my slapd.conf looks like:
database bdb
suffix "dc=caplan,dc=org"
rootdn "cn=root,dc=caplan,dc=org"
rootpw <PASSWORD>
directory /usr/local/var/openldap-data
index objecClass,uid,uidNumer,gidNumber eq
index cn eq
the user i'm trying to add is:
dn: uid=ldapauth,dc=caplan,dc=org
objectclass: account
objectclass: posixAccount
objectclass: top
cn: ldapauth
uid: ldapauth
uidNumber: 100
gidNumber: 100
I have no trailling spaces.
my add commands is :
ldapadd -D "cn=root,dc=caplan,dc=org" -f <File>
no matter what i do i get "Invalid syntax"
Thanks in advance,
Vinh
15 years, 2 months
OpenLDAP system architecture?
by Brad Knowles
Folks,
I'm going through the documentation at
<http://www.openldap.org/doc/admin24/>, the OpenLDAP FAQ-o-Matic at
<http://www.openldap.org/faq/data/cache/1.html>, and the archives of the
various Open-LDAP mailing lists, but I have not yet found anything that
discusses how one might want to architect a large-scale OpenLDAP system
with multiple masters, multiple slaves, etc... for best performance and
low latency.
In our case, we have OpenLDAP 2.3.something (a few versions behind the
official latest stable release), and we've recently hit our four
millionth object (at a large University with something like 48,000
students, 2700 faculty, and 19,000 employees), and we're running into
some performance issues that are going to keep us from rolling out some
other large projects, at least until we can get the problems resolved.
I do not yet understand a great deal about how our existing OpenLDAP
systems are designed, but I am curious to learn what kinds of
recommendations you folks would have for a large scale system like this.
In the far, dark, distant past, I know that OpenLDAP did not handle
situations well when you had both updates and reads occurring on the
same system, so the recommendation at the time was to make all updates
on the master server, then replicate that out to the slaves where all
the read operations would occur. You could even go so far as to set up
slaves on pretty much every single major client machine, for maximum
distribution and replication of the data, and maximum scalability of the
overall LDAP system.
I know that modern versions of OpenLDAP are able to handle a mix of both
updates and reads much better, so that the old style architecture is not
so necessary. But for a large-scale system like we have, would it not
be wise to use the old-style architecture for maximum performance and
scalability?
If you did use a multi-master cluster pair environment that handled all
the updates and all the LDAP queries that were generated, what kind of
performance do you think you should reasonably be able to get with the
latest version of 2.4.whatever on high-end hardware, and what kind of
hardware would you consider to be "high-end" for that environment? Is
CPU more important, or RAM, or disk space/latency?
Alternatively, if you went to a three-level master(s)->proxies->slaves
architecture [0], what kind of performance would you expect to be able
to get, and how many machines would you expect that to be able to scale
to? Are there any other major issues to be concerned about with that
kind of architecture, like latency of updates getting pushed out to the
leaf-node slaves?
How about the ultimate maximum distribution scenario, where you put an
LDAP slave on virtually every major LDAP client machine?
Any and all advice you can provide would be appreciated, and in
particular I would greatly appreciate it if you can provide any
references to documentation, FAQs, mailing list archives where I can
read more.
Thanks!
[0] Is this test045? As I believe is mentioned at
<http://www.openldap.org/lists/openldap-software/200707/msg00320.html>?
--
Brad Knowles <b.knowles(a)its.utexas.edu>
Sr. System Administrator, UT Austin ITS-Unix
COM 24 | 5-9342
15 years, 2 months
Upgrading blues
by Sn!per
Am currently running openldap-2.3.35 against BerkeleyDB version 4.5.20. Saw that there are now the stable openLDAP version 2.3.39 and also the Berkeley DB version 4.6.21.
I used openLDAP to power my qmail-ldap and wonder if I really need to upgrade at all. If the answer is yes, then with openLDAP version 2.3.39, would it be recommended to go for the latest Berkeley DB's version of should I stay with my current 4.5.20 ? I have read (was it this list?) somewhere that there were some incompatibilities issues between some version of openLDAP and Berkeley DB.
Please advise and thank you in advance.
--
roger
---------------------------------------------------
Sign Up for free Email at http://ureg.home.net.my/
---------------------------------------------------
15 years, 2 months
DN index delete failed
by Aaron Richton
My syncrepl provider seems to be missing updates following an upgrade to
2.3.40. While I was trying to push them through this morning, I got an odd
message:
Jan 28 08:46:19 slapd[12685]: [ID 588225 local4.debug] conn=234174 op=2
RESULT tag=107 err=80 text=DN index delete failed
Is there anything I can do about this, or maybe just an idea of where to
look or what information to take down for next time? I was going to try
and file an ITS for tracking or maybe to try and walk some structures, but
the DN in question deleted without incident about ten minutes later.
15 years, 2 months
