Fedora directory users - Jun 2007 - problems w/ admin server, local.conf

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.

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

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
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

I''ve had other issues with SSL and the admin server, these seem to
stick
me the most. These seem to happen with the ssl shell scripts, or by
hand.

When clicking on ''Manager Certificates '' under the task menu
for Fedora
Admin server you get an error that the cert8.db could not be found.


The fix is :

# cd /opt/fedora-ds/alias
# ../shared/bin/certutil -N -d . -P admin-serv-[LDAPINSTANCE]-

Also when installing a certificate, then going to configure and manage
encryption. Selecting using SSL and RSA will give me a PSET error.

Then the certificate will not be listed in the drop down box. By
clicking various checkboxes on and off it will stick with a bla k
certificate.

You need to make sure that the NSSNickName is set with your server-cert
in /opt/fedora-ds/admin/admin-serv/config. If not the error log will say
something with ''blank'' certificate.

Also, double verify the nssLPersonalitySSL: is not blank attribute at

# RSA, encryption, config
dn: cn=RSA,cn=encryption,cn=config
nsSSLToken: internal (software)
nsSSLPersonalitySSL: server-cert
nsSSLActivation: on
objectClass: top
objectClass: nsEncryptionModule
cn: RSA


- Dennis

On Mon, 2007-06-18 at 18:10 -0400, 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.
> 
> 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
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
This message (including any attachments) contains confidential information
intended for a specific individual and purpose, and is protected by law.  If you
are not the intended recipient, you should delete this message.  Any disclosure,
copying, or distribution of this message, or the taking of any action based on
it, is strictly prohibited.