MJD Shop Account wrote:
I've set up a few FDS 1.0.4 servers now and have problems every time getting 
certain things right with the admin server.  I run into problems using either 
the console or just ldif file (which I prefer, for scripting).  Here's the 
typical problem: when I try to set nsAdminAccessHosts, I use an ldif file.  I 
can see the new value is set in the operational attributes, but it doesn't 
always make it into /opt/fedora-ds/admin-server/config/local.conf.  The admin 
server logs indicate it is using the old values.
If you modify settings yourself in the configuration DS via LDAP, you will have to tell Admin Server to refresh its configuration. The console does this when you change admin server parameters. It uses the special url path "/Commands/sync-task-sie-data". You must authenticate to http first becauses it uses those credentials to bind to the directory server to read the new configuration. This is how local.conf is updated with the information from the config ds.

http://directory.fedoraproject.org/wiki/AdminServer#Admin_Server_Config_Files gives an overview of the various Admin Server config files. One thing it doesn't say is what the ownership should be.

admin-serv/config - directory - should be owned by the admin server uid and should be mode 0700. adm.conf - must be owned by the admin server uid (default nobody) and mode 0600
admpw - must be owned by the admin server uid (default nobody) and mode 0600
local.conf - must be owned by the admin server uid (default nobody) and mode 0600 console.conf - must be owned by the admin server uid (default nobody) and mode 0600

All other files can be owned by root and be read only.
I looked at file permissions, on one server I had owner:group as ldap:root, 
another has root:root, a third  had ldap:ldap.  That one was not getting 
updated, I changed it to root:root and restarted things and that seemed to 
update local.conf.

Now I'm building a new server and it's not updating. I get this error in the 
admin server error log:
[warn] Unable to bind as LocalAdmin to populate LocalAdmin tasks into cache.

This was similar to the server I fixed, but I already have root:root 
permissions on that file.

I went and looked at the server that originally had root:root, and while it has 
been functioning OK, it too doesn't have the correctly updated values for 
nsAdminAccessHosts in local.conf and shows the same error in its logs from 
awhile back (March).  So, I tried, for a test, setting the owner:group to 
ldap:root.  When I did this and restarted admin server, I got this error:
[error] server reached MaxClients setting, consider raising the MaxClients 
setting

This on a server that should not have anyone connected to the admin server...

So I set it back to root:root and had neither error on restarting (but the 
attribute value is still wrong).  On all servers, there is an httpd process 
under ldap user id and two under root user id (one of the two of the two root 
processes is the parent to the other root and to the ldap process).

Sometime ago I tried to find out what triggers the re-writing of local.conf, as 
Richard said it was best to use the console for updating these values, where 
some magic makes it do that.  Richard suggested looking in the logs to see what 
was happening, but I found no clues there.  If anyone has one...

Maybe the permissions need to match the method; would it be different running a 
root script at the command prompt vs. using the java console from a windows 
machine and connecting as the cn=dirmgr user?

Thanks,
  MJD

--
Fedora-directory-users mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/fedora-directory-users

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

--
Fedora-directory-users mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/fedora-directory-users

Reply via email to