I am getting the error below form my Version 220.127.116.11 (Build
2011.104.231) 389 Directory Server:
"libdb: Lock table is out of available locks"
The cn=database,cn=monitor,cn=ldbm database, cn=plugins,cn=config show
Its clear I am reaching the max number of locks of 10000. However I
don't know how to increase the value of nsslapd-db-configured-locks
The RedHat Directory documentation talks about increasing the value
through the attribute:
|cn=config,cn=ldbm database,cn=plugins,cn=config : nsslapd-db-locks
However this did not origiinally exist and even when it was added it did
not change the value of |nsslapd-db-configured-locks
How do I increase the value of nsslapd-db-configured-locks?
Thanks for any help you can provide.
We are using Ubuntu 10.04 server OS and all the web applications are running
on that.We have already implemented fedora-ds for ldap auth.now we are
planning to go some up-gradation.kindly let me know the following,
1.How to migrate running fedora-ds server to another server ?
2.i have taken all the user/group+etc in ldif format.is it enough for
migration or any other db (/var/lib/dirsrv/slapd-<instance>) also need to
bacup ? if any procedure please share with me ? how to import/export .ldif
3.in our setup,one server is in public network.so i am planning to do
replication through "ldaps", i.e local server to public server replication
through highly secure how to ?
Please help me on the above topics.
It is necessary for me to transfer server FDS on the new server. The old server worked under control fedora 7 (i386) the software fds 1.0.4. The new server works under control fedora 14 (x86_64). For transfer of the directory server I used the instruction http://directory.fedoraproject.org/wiki/FDS_Setup#migrate-ds-admin.pl (Cross Platform Migration Usage):
/usr/sbin/migrate-ds-admin.pl - crossplatform - oldsroot =/mnt/old-fds/opt/fedora-ds - actualsroot =/opt/fedora-ds General. ConfigDirectoryAdminPwd=FDS_password
Transfer of the directory server has happened successfully. I didn't manage to transfer and launch Admin Server. By script operation migrate-ds-admin.pl there is an error:
[Migration] Info Beginning migration of Administration server from/opt/fedora-ds... [Migration] Fatal Exiting...
I ask the help.
----- Missatge original -----
> Has anyone engineered a design to run 389-ds servers behind a hardware
> load balancer like an f5 LTM? I've found this question presented
> before, but never answered.
> a) the openldap-clients ldap module will query the first host/uri in
> the list until the port goes down
> b) the server can run out of file descriptors or memory and stop
> answering queries without closing the port
> c) pointing clients at a virtualized name on a hardware LB will
> present a name conflict. The SSL cert on the directory server must
> match the v-name on the LB to answer queries, but it must match the
> local hostname for replication agreements.
certutil -R -s "CN=hostname,OU=example,O=example,L=example,ST=example,C=example" -o example.csr -d . -a -8 hostname.example.com,ldap.example.com,repl.another.one
this is the only step that can't be done through gui, the rest is in the official docs.
Has anyone engineered a design to run 389-ds servers behind a hardware load balancer like an f5 LTM? I've found this question presented before, but never answered.
a) the openldap-clients ldap module will query the first host/uri in the list until the port goes down
b) the server can run out of file descriptors or memory and stop answering queries without closing the port
c) pointing clients at a virtualized name on a hardware LB will present a name conflict. The SSL cert on the directory server must match the v-name on the LB to answer queries, but it must match the local hostname for replication agreements.
I have not found an example where someone has started a second, replication-only listener on the database or configured an LTM to accept multiple v-names... This may be feasible with a robust SSL accelerator, but we don't have one on hand.
I get this error when trying to connect to mgmtd from the Pacemaker GUI Client.
mgmtd: : ERROR: on_listen protocol mismatch. Want 2.1 but got 1.0
I am using the client heartbeat-gui-2.1.3-3.el5.centos
Anyone know what is wrong?
Take 30 hosts, all with identical
/etc/auto.master and subsidiary files
The only two hosts where LDAP authentication fails are the two Oracle
servers. All are running on the same RHEL 5.4.
Anyone seen anything like this, before?
David - Offbeat http://dafydd.livejournal.com
dafydd - Online http://pgp.mit.edu/
Battalion 4 - Black Rock City Emergency Services Department
After having searched a bit, I think I know the answer. However, I am
asking the question in hopes that people may know of a project or effort
underway that I can dig into.
We have a requirement to record user activity (or more notably
inactivity). This is separate from password expiration. If an account
is inactive for X days, it must be auto-disabled. Since we are using a
directory server across hundreds of systems, the only way to do this is
in the directory.
Is there a schema option in 389-ds to support this, and concurrently a
pam module or extension to pam_ldap that supports it?
Ideally, pam_ldap would just have an option 'lastlog on' that would just
update the attribute on the user's object.
If there are not even any efforts to this end, I'll probably just hack
up something and put it into the .profile, but I was hoping to hedge off
of something else...