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.
Thanks Jimmy
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:
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)
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)
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.
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.
If your situation is way different than the above, we'd need to know more information before anyone can help.
Good luck! -Iwao
2011/7/29 夜神 岩男 supergiantpotato@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.. http://myserver:9080 Then you can admin the LDAP instance via GUI.
- 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
- 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 it.
Rich any clues, I have seen this issue before on the list but can't find the threads.
Thanks Jimmy
On 07/30/2011 05:17 AM, Techie wrote:
2011/7/29 夜神 岩男supergiantpotato@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.. http://myserver:9080 Then you can admin the LDAP instance via GUI.
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.
Fixing the hostname references is part of it, and if you are using certificates specific to the admin-server to authenticate then they need to be updated/replaced as well to avoid things like instance/realm or nss hostname check problems.
The config files should contain lots of references to the old hostname (unless a magical script fixed them when you weren't looking), and those must be changed. Don't forget to look places like nss.conf, and weirder areas like filnames of auth keys (and make sure to check silly spots like hosts.conf to make sure NetworkManager or whatever didn't append the new hostname in there somewhere (like an unused IPv6 line), or mix and match old and new hostnames, as this can break random authentication things related to Kerberos and NSS). Some files have hostname info tagged at the end of them, and things that point to them must be lined up.
I would start by walking myself back through manual setup steps as if I were setting up admin-server on a new system to make sure I didn't miss anything and then recreating my authentication keys if necessary.
Fixing a partially broken authentication setup *sucks*. In situations like that if the machine isn't the sole server (a slave is out there somewhere), I'll just re-install the server packages to make sure nothing is missed and then replicate back from the slave or a backup because re-setting nitpicky manual setups without doing them 100% from the beginning can be a real pain.
-Iwao
2011/7/29 夜神 岩男 supergiantpotato@yahoo.co.jp:
On 07/30/2011 05:17 AM, Techie wrote:
2011/7/29 夜神 岩男supergiantpotato@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.. http://myserver:9080 Then you can admin the LDAP instance via GUI.
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.
Fixing the hostname references is part of it, and if you are using certificates specific to the admin-server to authenticate then they need to be updated/replaced as well to avoid things like instance/realm or nss hostname check problems.
The config files should contain lots of references to the old hostname (unless a magical script fixed them when you weren't looking), and those must be changed. Don't forget to look places like nss.conf, and weirder areas like filnames of auth keys (and make sure to check silly spots like hosts.conf to make sure NetworkManager or whatever didn't append the new hostname in there somewhere (like an unused IPv6 line), or mix and match old and new hostnames, as this can break random authentication things related to Kerberos and NSS). Some files have hostname info tagged at the end of them, and things that point to them must be lined up.
I would start by walking myself back through manual setup steps as if I were setting up admin-server on a new system to make sure I didn't miss anything and then recreating my authentication keys if necessary.
Fixing a partially broken authentication setup *sucks*. In situations like that if the machine isn't the sole server (a slave is out there somewhere), I'll just re-install the server packages to make sure nothing is missed and then replicate back from the slave or a backup because re-setting nitpicky manual setups without doing them 100% from the beginning can be a real pain.
-Iwao
389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Is there any way I can fix the name of the Directory server and Admin-Server by using setup-ds-admin.pl? I'd rather not blow things away and import the data.
Thanks
On 08/01/2011 08:34 AM, Techie wrote:
2011/7/29 夜神 岩男supergiantpotato@yahoo.co.jp:
On 07/30/2011 05:17 AM, Techie wrote:
2011/7/29 夜神 岩男supergiantpotato@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.. http://myserver:9080 Then you can admin the LDAP instance via GUI. 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.
Fixing the hostname references is part of it, and if you are using certificates specific to the admin-server to authenticate then they need to be updated/replaced as well to avoid things like instance/realm or nss hostname check problems.
The config files should contain lots of references to the old hostname (unless a magical script fixed them when you weren't looking), and those must be changed. Don't forget to look places like nss.conf, and weirder areas like filnames of auth keys (and make sure to check silly spots like hosts.conf to make sure NetworkManager or whatever didn't append the new hostname in there somewhere (like an unused IPv6 line), or mix and match old and new hostnames, as this can break random authentication things related to Kerberos and NSS). Some files have hostname info tagged at the end of them, and things that point to them must be lined up.
I would start by walking myself back through manual setup steps as if I were setting up admin-server on a new system to make sure I didn't miss anything and then recreating my authentication keys if necessary.
Fixing a partially broken authentication setup *sucks*. In situations like that if the machine isn't the sole server (a slave is out there somewhere), I'll just re-install the server packages to make sure nothing is missed and then replicate back from the slave or a backup because re-setting nitpicky manual setups without doing them 100% from the beginning can be a real pain.
-Iwao
389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Is there any way I can fix the name of the Directory server and Admin-Server by using setup-ds-admin.pl? I'd rather not blow things away and import the data.
You can't do it with setup-ds-admin.pl
You'll have to first do a search of the directory server for the old hostname
I suggest using mozldap ldapsearch because of the -T option to disable LDIF line wrapping. /usr/lib64/mozldap/ldapsearch -T -b o=netscaperoot "objectclass=*" * aci | grep oldhostname and /usr/lib64/mozldap/ldapsearch -T -b cn=config "objectclass=*" * aci | grep oldhostname
If you have to use openldap ldapsearch, see http://richmegginson.livejournal.com/18726.html
You'll have to use ldapmodify to change attribute values to use the new hostname.
You'll also have to change /etc/dirsrv/admin-serv/adm.conf to use the new hostname.
Finally, see http://port389.org/wiki/DS_Admin_Migration#Note_about_hostnames
Thanks
389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Thanks Rich, that is what I was looking for.
Jimmy
On Mon, Aug 1, 2011 at 8:32 AM, Rich Megginson rmeggins@redhat.com wrote:
On 08/01/2011 08:34 AM, Techie wrote:
2011/7/29 夜神 岩男supergiantpotato@yahoo.co.jp:
On 07/30/2011 05:17 AM, Techie wrote:
2011/7/29 夜神 岩男supergiantpotato@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.. http://myserver:9080 Then you can admin the LDAP instance via GUI. 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.
Fixing the hostname references is part of it, and if you are using certificates specific to the admin-server to authenticate then they need to be updated/replaced as well to avoid things like instance/realm or nss hostname check problems.
The config files should contain lots of references to the old hostname (unless a magical script fixed them when you weren't looking), and those must be changed. Don't forget to look places like nss.conf, and weirder areas like filnames of auth keys (and make sure to check silly spots like hosts.conf to make sure NetworkManager or whatever didn't append the new hostname in there somewhere (like an unused IPv6 line), or mix and match old and new hostnames, as this can break random authentication things related to Kerberos and NSS). Some files have hostname info tagged at the end of them, and things that point to them must be lined up.
I would start by walking myself back through manual setup steps as if I were setting up admin-server on a new system to make sure I didn't miss anything and then recreating my authentication keys if necessary.
Fixing a partially broken authentication setup *sucks*. In situations like that if the machine isn't the sole server (a slave is out there somewhere), I'll just re-install the server packages to make sure nothing is missed and then replicate back from the slave or a backup because re-setting nitpicky manual setups without doing them 100% from the beginning can be a real pain.
-Iwao
389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Is there any way I can fix the name of the Directory server and Admin-Server by using setup-ds-admin.pl? I'd rather not blow things away and import the data.
You can't do it with setup-ds-admin.pl
You'll have to first do a search of the directory server for the old hostname
I suggest using mozldap ldapsearch because of the -T option to disable LDIF line wrapping. /usr/lib64/mozldap/ldapsearch -T -b o=netscaperoot "objectclass=*" * aci | grep oldhostname and /usr/lib64/mozldap/ldapsearch -T -b cn=config "objectclass=*" * aci | grep oldhostname
If you have to use openldap ldapsearch, see http://richmegginson.livejournal.com/18726.html
You'll have to use ldapmodify to change attribute values to use the new hostname.
You'll also have to change /etc/dirsrv/admin-serv/adm.conf to use the new hostname.
Finally, see http://port389.org/wiki/DS_Admin_Migration#Note_about_hostnames
Thanks
389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
389-users@lists.fedoraproject.org