I've seen the same issues, except I dont' think I've gotten the error about
using the cert8.db; but generally I'm using the same *db files as for the DS itself,
so I copy and rename them. The PSET error I see all the time. It's one reason
I'm hoping to script this setup. Even when it seems to be working (as it is now), I
notice things like the config operational attribute for the cert nssPersonalitySSL says
'blank', while the http config files have the right value.
-----Original Message-----
From: Dennis De Marco <ddemarco(a)seisint.com>
Sent: Jun 20, 2007 10:48 AM
To: MJD Shop Account <mjdshop(a)earthlink.net>, "General discussion list for the
Fedora Directory server project." <fedora-directory-users(a)redhat.com>
Subject: Re: [Fedora-directory-users] problems w/ admin server, local.conf
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(a)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.