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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 07/30/2011 05:17 AM, Techie wrote:
> 2011/7/29 夜神 岩男<supergiantpotato@xxxxxxxxxxx>:
>> 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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users



[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux