2011/7/29 夜神 岩男 <supergiantpotato(a)yahoo.co.jp>:
On 07/29/2011 04:34 PM, Techie wrote:
> We were required to change the hostname of our LDAP server running
> 389-DS. Since that time the LDAP server runs fine but the admin server
> does not authenticate login any longer, meaning i cannot log into the
> admin server. What do I need to do to fix the admin server and change
> all references from the old host name to the new host name.
Just for clarity, what does "admin server" mean:
The admin-server is the
Java front end/interface that allows you to
admin the server via http.
So you connect like..
Then you can admin the LDAP instance via GUI.
1. The machine itself cannot be authenticated against (which could
happen if its authentication system it a client of its own directory --
which I avoid for this reason)
The LDAP server is not a client of any LDAP server,
It just serves LDAP.
2. The master or admin LDAP server program cannot be authenticated
against because of domain/realm/hotname issues related to your
authentication system (like Kerberos disliking you because hostnames
don't match principal instances anymore or whatever)
LDAP works fine.. It is
the Java admin-server that is broken. It is
broken because hte references under the config files under
/etc/dirsrv/admin-serv are pointing to the incorrect host name. I am
not sure if me simply changing all references to the new hostname will
In case 1, you should boot into single-user mode/admin mode (runlevel 1
on Fedora pre 15 or any RHEL -- I don't remember how this works on
Debian anymore). That runlevel/mode should drop you into a root shell
prompt directly. From there you can edit whatever you need on the
command line and then reboot to normal.
No Need..box is serving LDAP fine.
In case 2 you should stop the server (without corrupting the data -- I'm
not sure about 389 anymore but OpenLDAP's slapd can be shut down gently
by sending an INT signal (traditionally something like "kill -INT [pid
of slapd]"). If you just do something equivalent to kill -9 you'll screw
up your database (again, not totally sure how 389 handles this compared
to OpenLDAP; fortunately I never had problems with 389 at all but I've
had serious issues with OpenLDAP in the past so I'm always extra
careful). Once slapd is shut down you can use the slap* tools to change
things around inside the database if that is where your problem lies.
389 has init
scripts to properly shutdown the DBs. There is no issue
with the LDAP server.
If your situation is way different than the above, we'd need to know
more information before anyone can help.
Here is the situation.
First off LDAP is still running just fine. So all my admin from the
command line ldapmodify, ldapdelete etc.. work fine. I am using this
389-directory server as a stand alone LDAP instance. The admin-server
and the LDAP directory are run from the same host.
It is the admin-server that is broken. While I do almost everything
from the CLI, I do add the indexing via the admin -server because when
I do it from the CLI, the indexes don't show up in the admin-server so
I am never sure if they are set correctly..
Root cause of the issue::
We were required to change the server host name.
Once I changed the server host name, the LDAP server continued to run
fine...however the admin-server will not authenticate me. Obviously
the entries in local.conf and other files under /etc/dirsrv/admin-serv
still pointing to incorrect hostnames. I just need to know how to fix
Rich any clues, I have seen this issue before on the list but can't
find the threads.