[389-users] Change name of server, admin-server no longer works

Techie techchavez at gmail.com
Fri Jul 29 20:17:18 UTC 2011

2011/7/29 夜神 岩男 <supergiantpotato at yahoo.co.jp>:
> On 07/29/2011 04:34 PM, Techie wrote:
>> Hello,
>> 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.
>        or
> 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
fix it.
> 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.
> Good luck!
> -Iwao

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.


More information about the 389-users mailing list