389-users February 2012

389-users@lists.fedoraproject.org

35 participants
60 discussions

Re: [389-users] 389 on a Redhat VPS?
by Carsten Grzemba 09 Feb '12

09 Feb '12

Some time ago, I have tested this on Solaris Branded Zone and it did not work, because there was an not mapped/implemented system call for semaphore or shared memory. The Centos itself has worked on Solaris Branded Zone Because that helps. Carsten Am 09.02.12, schrieb Craig T <389(a)noboost.org>: > hi, > > Has anyone setup 389-ds on a OpenVZ VPS yet? I'm attempting to setup IPA 2.x on my VPS and it's giving odd errors when starting the 389 Directory Server. > > Spec; > Centos 6.2 (x86-64) > model name : Intel(R) Xeon(R) CPU E5645 @ 2.40GHz > > > Linux mx1.example.com 2.6.18-274.7.1.el5.028stab095.1 #1 SMP Mon Oct 24 20:49:24 MSD 2011 x86_64 x86_64 x86_64 GNU/Linux > > 389-ds-base-libs-1.2.9.14-1.el6_2.2.x86_64 > 389-ds-base-1.2.9.14-1.el6_2.2.x86_64 > > > Errors: > ------------------------------------------------------------------------------ > 2012-02-09 04:59:18,815 DEBUG calling setup-ds.pl > 2012-02-09 05:09:24,460 DEBUG args=/usr/sbin/setup-ds.pl --silent --logfile - -f /tmp/tmpkU_Ram > 2012-02-09 05:09:24,461 DEBUG stdout=Server failed to start !!! Please check errors log for problems > [12/02/09:05:09:24] - [Setup] Info Could not start the directory server using command '/usr/lib64/dirsrv/slapd-PKI-IPA/start-slapd'. The last line from the error log was '[09/Feb/2012:04:59:24 +0300] - Failed to create semaphore for stats file (/var/run/dirsrv/slapd-PKI-IPA.stats). Error 13.(Permission denied) > '. Error: Unknown error 256 > Could not start the directory server using command '/usr/lib64/dirsrv/slapd-PKI-IPA/start-slapd'. The last line from the error log was '[09/Feb/2012:04:59:24 +0300] - Failed to create semaphore for stats file (/var/run/dirsrv/slapd-PKI-IPA.stats). Error 13.(Permission denied) > '. Error: Unknown error 256 > [12/02/09:05:09:24] - [Setup] Fatal Error: Could not create directory server instance 'PKI-IPA'. > Error: Could not create directory server instance 'PKI-IPA'. > [12/02/09:05:09:24] - [Setup] Fatal Exiting . . . > Log file is '-' > ---------------------------------- > > cya > > Craig > -- > 389 users mailing list > 389-users(a)lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users >

1 0

Re: [389-users] dirsrv-admin with existing (remote) configuration server using SSL
by Rich Megginson 09 Feb '12

09 Feb '12

On 02/08/2012 02:11 PM, MATON Brett wrote: > > *De :*Rich Megginson [mailto:rmeggins@redhat.com] > *Envoyé :* mercredi 8 février 2012 21:57 > *À :* MATON Brett > *Cc :* General discussion list for the 389 Directory server project. > *Objet :* Re: [389-users] dirsrv-admin with existing (remote) > configuration server using SSL > > On 02/08/2012 01:53 PM, MATON Brett wrote: > > *De :*Rich Megginson [mailto:rmeggins@redhat.com] > *Envoyé :* mercredi 8 février 2012 21:49 > *À :* MATON Brett > *Cc :* General discussion list for the 389 Directory server project. > *Objet :* Re: [389-users] dirsrv-admin with existing (remote) > configuration server using SSL > > On 02/08/2012 01:31 PM, MATON Brett wrote: > > Platform is RHEL6.2 x64 > > $ rpm -qa|grep 389 > > 389-admin-console-doc-1.1.8-1.el6.noarch > > 389-ds-base-libs-1.2.9.14-1.el6_2.2.x86_64 > > 389-admin-console-1.1.8-1.el6.noarch > > 389-adminutil-1.1.14-2.el6.x86_64 > > 389-ds-console-1.2.6-1.el6.noarch > > 389-ds-1.2.2-1.el6.noarch > > 389-ds-base-1.2.9.14-1.el6_2.2.x86_64 > > 389-ds-console-doc-1.2.6-1.el6.noarch > > 389-console-1.1.7-1.el6.noarch > > 389-admin-1.1.25-1.el6.x86_64 > > 389-dsgw-1.1.7-2.el6.x86_64 > > $ rpm -qi openldap > > Name : openldap Relocations: (not relocatable) > > Version : 2.4.23 Vendor: Red Hat, Inc. > > Release : 20.el6 Build Date: Tue 04 Oct > 2011 01:48:15 PM CEST > > Install Date: Wed 08 Feb 2012 09:20:30 AM CET Build Host: > x86-010.build.bos.redhat.com > > Group : System Environment/Daemons Source RPM: > openldap-2.4.23-20.el6.src.rpm > > Size : 779076 License: OpenLDAP > > Signature : RSA/8, Mon 07 Nov 2011 08:37:10 AM CET, Key ID > 199e2f91fd431d51 > > Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> > > URL : http://www.openldap.org/ > > Summary : LDAP support libraries > > Description : <snipped> > > rpm -qi nss > > Name : nss Relocations: (not relocatable) > > Version : 3.12.10 Vendor: Red Hat, Inc. > > Release : 17.el6_2 Build Date: Sat 10 Dec > 2011 12:32:24 AM CET > > Install Date: Wed 08 Feb 2012 09:20:30 AM CET Build Host: > x86-003.build.bos.redhat.com > > Group : System Environment/Libraries Source RPM: > nss-3.12.10-17.el6_2.src.rpm > > Size : 2602368 License: MPLv1.1 or > GPLv2+ or LGPLv2+ > > Signature : RSA/8, Wed 14 Dec 2011 01:37:20 PM CET, Key ID > 199e2f91fd431d51 > > Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> > > URL : http://www.mozilla.org/projects/security/pki/nss/ > > Summary : Network Security Services > > Description : <snipped> > > grep -i admconfigdir /etc/dirsrv/admin-serv/* > > # grep -i admconfigdir /etc/dirsrv/admin-serv/* > > /etc/dirsrv/admin-serv/admserv.conf:ADMConfigDir "/etc/dirsrv/admin-serv" > > > grep -i NSSEngine /etc/dirsrv/admin-serv/* > > # grep -i NSSEngine /etc/dirsrv/admin-serv/* > > /etc/dirsrv/admin-serv/console.conf:NSSEngine off > > > service dirsrv stop > /usr/sbin/start-ds-admin -e debug > > # service dirsrv stop > > Shutting down dirsrv: > > <host>... [ OK ] > > # /usr/sbin/start-ds-admin -e debug > > [Wed Feb 08 22:03:59 2012] [debug] mod_so.c(246): loaded module > authz_host_module > > [Wed Feb 08 22:03:59 2012] [debug] mod_so.c(246): loaded module > auth_basic_module > > [Wed Feb 08 22:03:59 2012] [debug] mod_so.c(246): loaded module > authn_file_module > > [Wed Feb 08 22:03:59 2012] [debug] mod_so.c(246): loaded module > log_config_module > > [Wed Feb 08 22:03:59 2012] [debug] mod_so.c(246): loaded module env_module > > [Wed Feb 08 22:03:59 2012] [debug] mod_so.c(246): loaded module > mime_magic_module > > [Wed Feb 08 22:03:59 2012] [debug] mod_so.c(246): loaded module > unique_id_module > > [Wed Feb 08 22:03:59 2012] [debug] mod_so.c(246): loaded module > setenvif_module > > [Wed Feb 08 22:03:59 2012] [debug] mod_so.c(246): loaded module > mime_module > > [Wed Feb 08 22:03:59 2012] [debug] mod_so.c(246): loaded module > negotiation_module > > [Wed Feb 08 22:03:59 2012] [debug] mod_so.c(246): loaded module dir_module > > [Wed Feb 08 22:03:59 2012] [debug] mod_so.c(246): loaded module > alias_module > > [Wed Feb 08 22:03:59 2012] [debug] mod_so.c(246): loaded module > rewrite_module > > [Wed Feb 08 22:03:59 2012] [debug] mod_so.c(246): loaded module cgi_module > > [Wed Feb 08 22:03:59 2012] [debug] mod_so.c(246): loaded module > restartd_module > > [Wed Feb 08 22:03:59 2012] [debug] mod_so.c(246): loaded module nss_module > > [Wed Feb 08 22:03:59 2012] [debug] mod_so.c(246): loaded module > admserv_module > > [Wed Feb 08 22:03:59 2012] [debug] mod_admserv/mod_admserv.c(2509): > [25197] create_server_config [0xbogus %p for (null) > > [Wed Feb 08 22:03:59 2012] [debug] mod_admserv/mod_admserv.c(2497): > [25197] create_config [0xbogus %p for (null) > > [Wed Feb 08 22:03:59 2012] [debug] mod_admserv/mod_admserv.c(2570): > [25197] Set [0xbogus %p [ADMCacheLifeTime] to 600 > > [Wed Feb 08 22:03:59 2012] [debug] mod_admserv/mod_admserv.c(2588): > [25197] Set [0xbogus %p [ADMServerVersionString] to > 389-Administrator/1.1.25 > > [Wed Feb 08 22:03:59 2012] [debug] mod_admserv/mod_admserv.c(2497): > [25197] create_config [0xbogus %p for /*/[tT]asks/[Oo]peration/* > > [Wed Feb 08 22:03:59 2012] [debug] mod_admserv/mod_admserv.c(2522): > [25197] adminsdk [0xbogus %p flag 1 > > [Wed Feb 08 22:03:59 2012] [debug] mod_admserv/mod_admserv.c(2497): > [25197] create_config [0xbogus %p for /*/[tT]asks/[Cc]onfiguration/* > > [Wed Feb 08 22:03:59 2012] [debug] mod_admserv/mod_admserv.c(2522): > [25197] adminsdk [0xbogus %p flag 1 > > [Wed Feb 08 22:03:59 2012] [debug] mod_admserv/mod_admserv.c(2497): > [25197] create_config [0xbogus %p for > /*/[tT]asks/[Oo]peration/(?i:stop|start|restart|startconfigds|create|remove)$ > > [Wed Feb 08 22:03:59 2012] [debug] mod_admserv/mod_admserv.c(2522): > [25197] adminsdk [0xbogus %p flag 0 > > Server failed to start !!! Please check errors log for problems > > # tail /var/log/dirsrv/admin-serv/error > > [Wed Feb 08 22:04:05 2012] [debug] mod_admserv/mod_admserv.c(1456): > populate_tasks_from_server(): getting tasks for server [admin-serv] > siedn [cn=admin-serv-<host>,cn=389 Administration Server,cn=Server > Group,cn=<host FQDN>,ou=admins.unix,o=NetscapeRoot] > > [Wed Feb 08 22:04:05 2012] [crit] sslinit: NSS is required to use > LDAPS, but security initialization failed [-12285:Unable to find the > certificate or key necessary for authentication.]. Cannot start server > Ok. Well, it's just not working and I don't know why. Please file a ticket and we'll get around to it. > > *De :*Rich Megginson [mailto:rmeggins@redhat.com] > *Envoyé :* mercredi 8 février 2012 21:16 > *À :* MATON Brett > *Cc :* General discussion list for the 389 Directory server project. > *Objet :*Re: [389-users] dirsrv-admin with existing (remote) > configuration server using SSL > > On 02/08/2012 12:18 PM, MATON Brett wrote: > > Thanks for your help Rich, > > LDAPTLS_CACERTDIR=/etc/dirsrv/admin-serv > > ldapsearch -x -H ldaps://<config server FQDN> -D "cn=Directory > Manager" --W --s base --b "" > > # extended LDIF > > # > > # LDAPv3 > > # base <> with scope baseObject > > # filter: (objectclass=*) > > # requesting: ALL > > # > > # > > dn: > > objectClass: top > > namingContexts: dc=admins,dc=unix > > ... > > No complaints from those commands, the plot thickens ;) > > What platform is this? > rpm -qa|grep 389 > rpm -qi openldap > rpm -qi nss > > > > Brett > > *De :*Rich Megginson [mailto:rmeggins@redhat.com] > *Envoyé :* mercredi 8 février 2012 16:43 > *À :* General discussion list for the 389 Directory server project. > *Cc :* MATON Brett > *Objet :* Re: [389-users] dirsrv-admin with existing (remote) > configuration server using SSL > > On 02/08/2012 07:20 AM, MATON Brett wrote: > > Installation appears to go fine until it tries to start the admin server: > > Configuration directory server URL [ldap://<local > FQDN>:389/o=NetscapeRoot]: ldaps://<Config Server FQDN>:636/o=NetscapeRoot > > ... > > CA certificate filename: /etc/openldap/cacerts/<base64 cert file> > > ... > > output: Server failed to start !!! Please check errors log for problems > > output: [FAILED] > > /var/log/dirsrv/admin-serv/error: > > [Wed Feb 08 13:35:26 2012] [notice] SELinux policy enabled; httpd > running as context unconfined_u:system_r:httpd_t:s0 > > [Wed Feb 08 13:35:32 2012] [crit] sslinit: NSS is required to use > LDAPS, but security initialization failed [-12285:Unable to find the > certificate or key necessary for authentication.]. Cannot start server > > The server, has however successfully registered itself with the remote > Configuration Directory Server. > > (shows up in the server group in 389-Console and Directory Server is > available). > > I wasn't asked to provide a keystore password when adding the > certificate to the store, as you would be with 389-Console GUI when > first opening the certificate store. > > Is that intentional or not? > > I'm now a bit stumped (again), I had a look at the certdb with certutil: > > [root@<host> admin-serv]# certutil -d . -L > > Certificate Nickname Trust > Attributes > > > SSL,S/MIME,JAR/XPI > > CA certificate CT,, > > Which leads me to believe that it should be able to at least find the > certificate... > > I also checked file/directory ownership and permissions which match > those on the working 'master' server. > > Installer issue: > > If you make a mistake and get asked to try again (I typed the ldaps > port as 633 instead if 636), you get stuck at the CA Certificate > filename stage with the following: > > CA certificate filename [/etc/openldap/cacerts/CAServer.crt]: > > The certificate database in '/etc/dirsrv/admin-serv' already contains > a CA certificate. Please remove it first, or use the certutil program > to add the CA certificate with a different name. > > Please try again, in case you mis-typed something. > > Simple enough solution as for me this is a fresh install, is to delete > cert8.db and keys3.db in /etc/dirserv/admin-serv/ from another session. > > You can use ldapsearch to test if the cert db is correct: > > LDAPTLS_CACERTDIR=/etc/dirsrv/admin-serv ldapsearch -x -H > ldaps://<Config Server FQDN> -D "cn=directory manager" -W -s base -b "" > if that doesn't work, use ldapsearch -d 1 -x .... to get more > debugging information. > > The error is strange though. It seems to imply that the admin server > is looking for a cert or key. If the admin server is acting only as > an SSL client, it should not need to look up a cert or key, it should > only need the CA cert. > > > > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > > > -- > 389 users mailing list > 389-users(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > https://admin.fedoraproject.org/mailman/listinfo/389-users > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > ------------------------------------------------------------------- > > *GreeNRB > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ >

1 0

Re: [389-users] dirsrv-admin with existing (remote) configuration server using SSL
by Rich Megginson 09 Feb '12

09 Feb '12

On 02/08/2012 01:53 PM, MATON Brett wrote: > > *De :*Rich Megginson [mailto:rmeggins@redhat.com] > *Envoyé :* mercredi 8 février 2012 21:49 > *À :* MATON Brett > *Cc :* General discussion list for the 389 Directory server project. > *Objet :* Re: [389-users] dirsrv-admin with existing (remote) > configuration server using SSL > > On 02/08/2012 01:31 PM, MATON Brett wrote: > > Platform is RHEL6.2 x64 > > $ rpm -qa|grep 389 > > 389-admin-console-doc-1.1.8-1.el6.noarch > > 389-ds-base-libs-1.2.9.14-1.el6_2.2.x86_64 > > 389-admin-console-1.1.8-1.el6.noarch > > 389-adminutil-1.1.14-2.el6.x86_64 > > 389-ds-console-1.2.6-1.el6.noarch > > 389-ds-1.2.2-1.el6.noarch > > 389-ds-base-1.2.9.14-1.el6_2.2.x86_64 > > 389-ds-console-doc-1.2.6-1.el6.noarch > > 389-console-1.1.7-1.el6.noarch > > 389-admin-1.1.25-1.el6.x86_64 > > 389-dsgw-1.1.7-2.el6.x86_64 > > $ rpm -qi openldap > > Name : openldap Relocations: (not relocatable) > > Version : 2.4.23 Vendor: Red Hat, Inc. > > Release : 20.el6 Build Date: Tue 04 Oct > 2011 01:48:15 PM CEST > > Install Date: Wed 08 Feb 2012 09:20:30 AM CET Build Host: > x86-010.build.bos.redhat.com > > Group : System Environment/Daemons Source RPM: > openldap-2.4.23-20.el6.src.rpm > > Size : 779076 License: OpenLDAP > > Signature : RSA/8, Mon 07 Nov 2011 08:37:10 AM CET, Key ID > 199e2f91fd431d51 > > Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> > > URL : http://www.openldap.org/ > > Summary : LDAP support libraries > > Description : <snipped> > > rpm -qi nss > > Name : nss Relocations: (not relocatable) > > Version : 3.12.10 Vendor: Red Hat, Inc. > > Release : 17.el6_2 Build Date: Sat 10 Dec > 2011 12:32:24 AM CET > > Install Date: Wed 08 Feb 2012 09:20:30 AM CET Build Host: > x86-003.build.bos.redhat.com > > Group : System Environment/Libraries Source RPM: > nss-3.12.10-17.el6_2.src.rpm > > Size : 2602368 License: MPLv1.1 or > GPLv2+ or LGPLv2+ > > Signature : RSA/8, Wed 14 Dec 2011 01:37:20 PM CET, Key ID > 199e2f91fd431d51 > > Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> > > URL : http://www.mozilla.org/projects/security/pki/nss/ > > Summary : Network Security Services > > Description : <snipped> > > grep -i admconfigdir /etc/dirsrv/admin-serv/* > > # grep -i admconfigdir /etc/dirsrv/admin-serv/* > > /etc/dirsrv/admin-serv/admserv.conf:ADMConfigDir "/etc/dirsrv/admin-serv" > > > grep -i NSSEngine /etc/dirsrv/admin-serv/* > > # grep -i NSSEngine /etc/dirsrv/admin-serv/* > > /etc/dirsrv/admin-serv/console.conf:NSSEngine off > service dirsrv stop /usr/sbin/start-ds-admin -e debug > > *De :*Rich Megginson [mailto:rmeggins@redhat.com] > *Envoyé :* mercredi 8 février 2012 21:16 > *À :* MATON Brett > *Cc :* General discussion list for the 389 Directory server project. > *Objet :* Re: [389-users] dirsrv-admin with existing (remote) > configuration server using SSL > > On 02/08/2012 12:18 PM, MATON Brett wrote: > > Thanks for your help Rich, > > LDAPTLS_CACERTDIR=/etc/dirsrv/admin-serv > > ldapsearch -x -H ldaps://<config server FQDN> -D "cn=Directory > Manager" --W --s base --b "" > > # extended LDIF > > # > > # LDAPv3 > > # base <> with scope baseObject > > # filter: (objectclass=*) > > # requesting: ALL > > # > > # > > dn: > > objectClass: top > > namingContexts: dc=admins,dc=unix > > ... > > No complaints from those commands, the plot thickens ;) > > What platform is this? > rpm -qa|grep 389 > rpm -qi openldap > rpm -qi nss > > > Brett > > *De :*Rich Megginson [mailto:rmeggins@redhat.com] > *Envoyé :* mercredi 8 février 2012 16:43 > *À :* General discussion list for the 389 Directory server project. > *Cc :* MATON Brett > *Objet :* Re: [389-users] dirsrv-admin with existing (remote) > configuration server using SSL > > On 02/08/2012 07:20 AM, MATON Brett wrote: > > Installation appears to go fine until it tries to start the admin server: > > Configuration directory server URL [ldap://<local > FQDN>:389/o=NetscapeRoot]: ldaps://<Config Server FQDN>:636/o=NetscapeRoot > > ... > > CA certificate filename: /etc/openldap/cacerts/<base64 cert file> > > ... > > output: Server failed to start !!! Please check errors log for problems > > output: [FAILED] > > /var/log/dirsrv/admin-serv/error: > > [Wed Feb 08 13:35:26 2012] [notice] SELinux policy enabled; httpd > running as context unconfined_u:system_r:httpd_t:s0 > > [Wed Feb 08 13:35:32 2012] [crit] sslinit: NSS is required to use > LDAPS, but security initialization failed [-12285:Unable to find the > certificate or key necessary for authentication.]. Cannot start server > > The server, has however successfully registered itself with the remote > Configuration Directory Server. > > (shows up in the server group in 389-Console and Directory Server is > available). > > I wasn't asked to provide a keystore password when adding the > certificate to the store, as you would be with 389-Console GUI when > first opening the certificate store. > > Is that intentional or not? > > I'm now a bit stumped (again), I had a look at the certdb with certutil: > > [root@<host> admin-serv]# certutil -d . -L > > Certificate Nickname Trust > Attributes > > > SSL,S/MIME,JAR/XPI > > CA certificate CT,, > > Which leads me to believe that it should be able to at least find the > certificate... > > I also checked file/directory ownership and permissions which match > those on the working 'master' server. > > Installer issue: > > If you make a mistake and get asked to try again (I typed the ldaps > port as 633 instead if 636), you get stuck at the CA Certificate > filename stage with the following: > > CA certificate filename [/etc/openldap/cacerts/CAServer.crt]: > > The certificate database in '/etc/dirsrv/admin-serv' already contains > a CA certificate. Please remove it first, or use the certutil program > to add the CA certificate with a different name. > > Please try again, in case you mis-typed something. > > Simple enough solution as for me this is a fresh install, is to delete > cert8.db and keys3.db in /etc/dirserv/admin-serv/ from another session. > > You can use ldapsearch to test if the cert db is correct: > > LDAPTLS_CACERTDIR=/etc/dirsrv/admin-serv ldapsearch -x -H > ldaps://<Config Server FQDN> -D "cn=directory manager" -W -s base -b "" > if that doesn't work, use ldapsearch -d 1 -x .... to get more > debugging information. > > The error is strange though. It seems to imply that the admin server > is looking for a cert or key. If the admin server is acting only as > an SSL client, it should not need to look up a cert or key, it should > only need the CA cert. > > > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > > > -- > 389 users mailing list > 389-users(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > https://admin.fedoraproject.org/mailman/listinfo/389-users > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > ------------------------------------------------------------------- > > *GreeNRB > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ >

1 0

Re: [389-users] dirsrv-admin with existing (remote) configuration server using SSL
by Rich Megginson 09 Feb '12

09 Feb '12

On 02/08/2012 01:31 PM, MATON Brett wrote: > > Platform is RHEL6.2 x64 > > $ rpm -qa|grep 389 > > 389-admin-console-doc-1.1.8-1.el6.noarch > > 389-ds-base-libs-1.2.9.14-1.el6_2.2.x86_64 > > 389-admin-console-1.1.8-1.el6.noarch > > 389-adminutil-1.1.14-2.el6.x86_64 > > 389-ds-console-1.2.6-1.el6.noarch > > 389-ds-1.2.2-1.el6.noarch > > 389-ds-base-1.2.9.14-1.el6_2.2.x86_64 > > 389-ds-console-doc-1.2.6-1.el6.noarch > > 389-console-1.1.7-1.el6.noarch > > 389-admin-1.1.25-1.el6.x86_64 > > 389-dsgw-1.1.7-2.el6.x86_64 > > $ rpm -qi openldap > > Name : openldap Relocations: (not relocatable) > > Version : 2.4.23 Vendor: Red Hat, Inc. > > Release : 20.el6 Build Date: Tue 04 Oct > 2011 01:48:15 PM CEST > > Install Date: Wed 08 Feb 2012 09:20:30 AM CET Build Host: > x86-010.build.bos.redhat.com > > Group : System Environment/Daemons Source RPM: > openldap-2.4.23-20.el6.src.rpm > > Size : 779076 License: OpenLDAP > > Signature : RSA/8, Mon 07 Nov 2011 08:37:10 AM CET, Key ID > 199e2f91fd431d51 > > Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> > > URL : http://www.openldap.org/ > > Summary : LDAP support libraries > > Description : <snipped> > > rpm -qi nss > > Name : nss Relocations: (not relocatable) > > Version : 3.12.10 Vendor: Red Hat, Inc. > > Release : 17.el6_2 Build Date: Sat 10 Dec > 2011 12:32:24 AM CET > > Install Date: Wed 08 Feb 2012 09:20:30 AM CET Build Host: > x86-003.build.bos.redhat.com > > Group : System Environment/Libraries Source RPM: > nss-3.12.10-17.el6_2.src.rpm > > Size : 2602368 License: MPLv1.1 or > GPLv2+ or LGPLv2+ > > Signature : RSA/8, Wed 14 Dec 2011 01:37:20 PM CET, Key ID > 199e2f91fd431d51 > > Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> > > URL : http://www.mozilla.org/projects/security/pki/nss/ > > Summary : Network Security Services > > Description : <snipped> > grep -i admconfigdir /etc/dirsrv/admin-serv/* grep -i NSSEngine /etc/dirsrv/admin-serv/* > > *De :*Rich Megginson [mailto:rmeggins@redhat.com] > *Envoyé :* mercredi 8 février 2012 21:16 > *À :* MATON Brett > *Cc :* General discussion list for the 389 Directory server project. > *Objet :* Re: [389-users] dirsrv-admin with existing (remote) > configuration server using SSL > > On 02/08/2012 12:18 PM, MATON Brett wrote: > > Thanks for your help Rich, > > LDAPTLS_CACERTDIR=/etc/dirsrv/admin-serv > > ldapsearch -x -H ldaps://<config server FQDN> -D "cn=Directory > Manager" --W --s base --b "" > > # extended LDIF > > # > > # LDAPv3 > > # base <> with scope baseObject > > # filter: (objectclass=*) > > # requesting: ALL > > # > > # > > dn: > > objectClass: top > > namingContexts: dc=admins,dc=unix > > ... > > No complaints from those commands, the plot thickens ;) > > What platform is this? > rpm -qa|grep 389 > rpm -qi openldap > rpm -qi nss > > Brett > > *De :*Rich Megginson [mailto:rmeggins@redhat.com] > *Envoyé :* mercredi 8 février 2012 16:43 > *À :* General discussion list for the 389 Directory server project. > *Cc :* MATON Brett > *Objet :* Re: [389-users] dirsrv-admin with existing (remote) > configuration server using SSL > > On 02/08/2012 07:20 AM, MATON Brett wrote: > > Installation appears to go fine until it tries to start the admin server: > > Configuration directory server URL [ldap://<local > FQDN>:389/o=NetscapeRoot]: ldaps://<Config Server FQDN>:636/o=NetscapeRoot > > ... > > CA certificate filename: /etc/openldap/cacerts/<base64 cert file> > > ... > > output: Server failed to start !!! Please check errors log for problems > > output: [FAILED] > > /var/log/dirsrv/admin-serv/error: > > [Wed Feb 08 13:35:26 2012] [notice] SELinux policy enabled; httpd > running as context unconfined_u:system_r:httpd_t:s0 > > [Wed Feb 08 13:35:32 2012] [crit] sslinit: NSS is required to use > LDAPS, but security initialization failed [-12285:Unable to find the > certificate or key necessary for authentication.]. Cannot start server > > The server, has however successfully registered itself with the remote > Configuration Directory Server. > > (shows up in the server group in 389-Console and Directory Server is > available). > > I wasn't asked to provide a keystore password when adding the > certificate to the store, as you would be with 389-Console GUI when > first opening the certificate store. > > Is that intentional or not? > > I'm now a bit stumped (again), I had a look at the certdb with certutil: > > [root@<host> admin-serv]# certutil -d . -L > > Certificate Nickname Trust > Attributes > > > SSL,S/MIME,JAR/XPI > > CA certificate CT,, > > Which leads me to believe that it should be able to at least find the > certificate... > > I also checked file/directory ownership and permissions which match > those on the working 'master' server. > > Installer issue: > > If you make a mistake and get asked to try again (I typed the ldaps > port as 633 instead if 636), you get stuck at the CA Certificate > filename stage with the following: > > CA certificate filename [/etc/openldap/cacerts/CAServer.crt]: > > The certificate database in '/etc/dirsrv/admin-serv' already contains > a CA certificate. Please remove it first, or use the certutil program > to add the CA certificate with a different name. > > Please try again, in case you mis-typed something. > > Simple enough solution as for me this is a fresh install, is to delete > cert8.db and keys3.db in /etc/dirserv/admin-serv/ from another session. > > You can use ldapsearch to test if the cert db is correct: > > LDAPTLS_CACERTDIR=/etc/dirsrv/admin-serv ldapsearch -x -H > ldaps://<Config Server FQDN> -D "cn=directory manager" -W -s base -b "" > if that doesn't work, use ldapsearch -d 1 -x .... to get more > debugging information. > > The error is strange though. It seems to imply that the admin server > is looking for a cert or key. If the admin server is acting only as > an SSL client, it should not need to look up a cert or key, it should > only need the CA cert. > > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > > > -- > 389 users mailing list > 389-users(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > https://admin.fedoraproject.org/mailman/listinfo/389-users > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > ------------------------------------------------------------------- > > *GreeNRB > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ >

1 0

Re: [389-users] admserv_host_ip_check: ap_get_remote_host could not resolve
by Rich Megginson 09 Feb '12

09 Feb '12

On 02/08/2012 01:27 PM, MATON Brett wrote: > > Hi Rich, > > I've got no nsAdminAccessHost lines in that config file, only a > configuration.nsAdminAccessAddresses entry. > Ok. Looks like it will refuse to leave nsAdminAccessHost - if missing, it defaults to your local hostname. The error message is coming because this is returning NULL: const char *maxdns = ap_get_remote_host(r->connection, r->per_dir_config, REMOTE_HOST, NULL); Here is the documentation for http://www.rcbowen.com/httpd_api_docs/group__get__remote__host.html that explains how/why this function returns NULL. > > Cheers, > > Brett > > *De :*Rich Megginson [mailto:rmeggins@redhat.com] > *Envoyé :* mercredi 8 février 2012 21:15 > *À :* MATON Brett > *Cc :* General discussion list for the 389 Directory server project. > *Objet :* Re: [389-users] admserv_host_ip_check: ap_get_remote_host > could not resolve > > On 02/08/2012 12:09 PM, MATON Brett wrote: > > Hi Rick, > > I restarted both dirsrv and dirsrv-admin, problem persists though. > > ok - try this > service dirsrv-admin stop > edit /etc/dirsrv/admin-serv/local.conf - remove any nsAdminAccessHost > lines > service dirsrv-admin start > > *De :*Rich Megginson [mailto:rmeggins@redhat.com] > *Envoyé :* mercredi 8 février 2012 16:39 > *À :* General discussion list for the 389 Directory server project. > *Cc :* MATON Brett > *Objet :* Re: [389-users] admserv_host_ip_check: ap_get_remote_host > could not resolve > > On 02/08/2012 08:19 AM, MATON Brett wrote: > > Thanks the update to the wiki solved the "wrong attribute type" error > on nsAdminAccessHosts. > > Configuration as it stands, with no nsAdminAccessHosts attribure: > > # configuration, admin-serv-<host>, 389 Administration Server, Server Gro > > up, <fqdn>, admins.unix, NetscapeRoot > > dn: cn=configuration,cn=admin-serv-<host>,cn=389 Administration > Server,cn=Server Group,cn=<fqdn>,ou=admins.unix,o=NetscapeRoot > > nsServerPort: 9830 > > objectClass: nsConfig > > objectClass: nsAdminConfig > > objectClass: nsAdminObject > > objectClass: nsDirectoryInfo > > objectClass: top > > nsClassname: > com.netscape.management.admserv.AdminServer@389-admin-1.1.jar@cn=admin-serv-<host>,cn=389 > <mailto:com.netscape.management.admserv.AdminServer@389-admin-1.1.jar@cn=admin-serv-%3chost%3e,cn=389> > Administration Server,cn=Server > Group,cn=<fqdn>,ou=admins.unix,o=NetscapeRoot > > cn: Configuration > > nsDirectoryInfoRef: cn=Server > Group,cn=<fqdn>,ou=admins.unix,o=NetscapeRoot > > nsAdminAccessAddresses: * > > nsSuiteSpotUser: nobody > > nsAdminEnableDSGW: on > > nsAdminCacheLifetime: 600 > > nsDefaultAcceptLanguage: en > > nsServerAddress: 0.0.0.0 > > nsAdminOneACLDir: adminacl > > nsErrorLog: /var/log/dirsrv/admin-serv/error > > nsAdminUsers: /etc/dirsrv/admin-serv/admpw > > nsPidLog: admin-serv.pid > > nsAccessLog: /var/log/dirsrv/admin-serv/access > > nsAdminEnableEnduser: on > > nsServerSecurity: on > > admin-serv/error log after restarting admin-serv (also tried > restarting dirsrv / dirsrv-admin): > > [Wed Feb 08 07:02:35 2012] [notice] caught SIGTERM, shutting down > > [Wed Feb 08 07:02:36 2012] [notice] SELinux policy enabled; httpd > running as context unconfined_u:system_r:httpd_t:s0 > > [Wed Feb 08 07:02:37 2012] [notice] Access Host filter is: * > > [Wed Feb 08 07:02:37 2012] [notice] Access Address filter is: * > > [Wed Feb 08 07:02:38 2012] [notice] Apache/2.2.15 (Unix) > mod_nss/2.2.15 NSS/3.12.9.0 configured -- resuming normal operations > > [Wed Feb 08 07:02:38 2012] [notice] Access Host filter is: * > > [Wed Feb 08 07:02:38 2012] [notice] Access Address filter is: * > > [Wed Feb 08 07:03:07 2012] [notice] [client <client ip>] > admserv_host_ip_check: ap_get_remote_host could not resolve <client ip> > > [Wed Feb 08 07:03:07 2012] [notice] [client <client ip>] > admserv_check_authz(): passing [/admin-serv/authenticate] to the > userauth handler > > [Wed Feb 08 07:17:10 2012] [notice] [client <client ip>] > admserv_host_ip_check: ap_get_remote_host could not resolve <client ip> > > [Wed Feb 08 07:17:10 2012] [notice] [client <client ip>] > admserv_check_authz(): passing [/admin-serv/authenticate] to the > userauth handler > > [Wed Feb 08 07:17:17 2012] [notice] [client <client ip>] > admserv_host_ip_check: ap_get_remote_host could not resolve <client ip> > > I'm still getting the could not resolve notices, and noticed that the > Access Host filter is still '*', picking up a default somewhere? > > (I don't know why it can't resolve either, nslookup / host can both > resolve ip's to hostnames and vice versa). > > Did you restart the admin server after making this change? > > > Brett > > *From:*Rich Megginson [mailto:rmeggins@redhat.com] > *Sent:* 08 February 2012 00:57 > *To:* MATON Brett > *Cc:* General discussion list for the 389 Directory server project. > *Subject:* Re: [389-users] admserv_host_ip_check: ap_get_remote_host > could not resolve > > On 02/07/2012 03:23 PM, MATON Brett wrote: > > Hi Rich, > > I tried this and got the following error : > > Enter LDAP Password: > > dn: cn=configuration,cn=admin-serv-<host>,cn=389 Administration Server,cn= > > Server Group,cn=<fqdn>,ou=admins.unix,o=NetscapeRoot > > changetype: modify > > replace: nsAdminAccessAddresses nsAdminAccessHosts > > nsAdminAccessAddresses: * > > nsAdminAccessHosts: > > ldapmodify: wrong attributeType at line 4, entry > "cn=configuration,cn=admin-serv-<host>,cn=389 Administration > Server,cn=Server Group,cn=<fqdn>,ou=admins.unix,o=NetscapeRoot" > > Does this mean anything to you? > > Yes, a typo on the wiki page. I've updated the page. > > > > Thanks, > > Brett > > *De :*Rich Megginson [mailto:rmeggins@redhat.com] > *Envoyé :* mardi 7 février 2012 15:18 > *À :* General discussion list for the 389 Directory server project. > *Cc :* MATON Brett > *Objet :* Re: [389-users] admserv_host_ip_check: ap_get_remote_host > could not resolve > > On 02/07/2012 01:05 AM, MATON Brett wrote: > > How can I stop admin server from logging theses messages? > > I realize from the console.conf file that the messages are created > because HostnameLookups is Off. > > My /etc/dirsrv.admin-serv/httpd.conf file has LogLevel set to warn, so > why is it logging notice messages? > > I'm probably overlooking some other configuration file somewhere. > > Any help appreciated > > As a side note, why is it whining about name resolution when the > configuration specifically says Don't do name lookups? > > http://directory.fedoraproject.org/wiki/Howto:AdminServerLDAPMgmt > > > > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > > > -- > 389 users mailing list > 389-users(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > https://admin.fedoraproject.org/mailman/listinfo/389-users > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > > > -- > 389 users mailing list > 389-users(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > https://admin.fedoraproject.org/mailman/listinfo/389-users > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > ------------------------------------------------------------------- > > *GreeNRB > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ >

1 0

Re: [389-users] dirsrv-admin with existing (remote) configuration server using SSL
by Rich Megginson 09 Feb '12

09 Feb '12

On 02/08/2012 12:18 PM, MATON Brett wrote: > > Thanks for your help Rich, > > LDAPTLS_CACERTDIR=/etc/dirsrv/admin-serv > > ldapsearch -x -H ldaps://<config server FQDN> -D "cn=Directory > Manager" --W --s base --b "" > > # extended LDIF > > # > > # LDAPv3 > > # base <> with scope baseObject > > # filter: (objectclass=*) > > # requesting: ALL > > # > > # > > dn: > > objectClass: top > > namingContexts: dc=admins,dc=unix > > ... > > No complaints from those commands, the plot thickens ;) > What platform is this? rpm -qa|grep 389 rpm -qi openldap rpm -qi nss > > Brett > > *De :*Rich Megginson [mailto:rmeggins@redhat.com] > *Envoyé :* mercredi 8 février 2012 16:43 > *À :* General discussion list for the 389 Directory server project. > *Cc :* MATON Brett > *Objet :* Re: [389-users] dirsrv-admin with existing (remote) > configuration server using SSL > > On 02/08/2012 07:20 AM, MATON Brett wrote: > > Installation appears to go fine until it tries to start the admin server: > > Configuration directory server URL [ldap://<local > FQDN>:389/o=NetscapeRoot]: ldaps://<Config Server FQDN>:636/o=NetscapeRoot > > ... > > CA certificate filename: /etc/openldap/cacerts/<base64 cert file> > > ... > > output: Server failed to start !!! Please check errors log for problems > > output: [FAILED] > > /var/log/dirsrv/admin-serv/error: > > [Wed Feb 08 13:35:26 2012] [notice] SELinux policy enabled; httpd > running as context unconfined_u:system_r:httpd_t:s0 > > [Wed Feb 08 13:35:32 2012] [crit] sslinit: NSS is required to use > LDAPS, but security initialization failed [-12285:Unable to find the > certificate or key necessary for authentication.]. Cannot start server > > The server, has however successfully registered itself with the remote > Configuration Directory Server. > > (shows up in the server group in 389-Console and Directory Server is > available). > > I wasn't asked to provide a keystore password when adding the > certificate to the store, as you would be with 389-Console GUI when > first opening the certificate store. > > Is that intentional or not? > > I'm now a bit stumped (again), I had a look at the certdb with certutil: > > [root@<host> admin-serv]# certutil -d . -L > > Certificate Nickname Trust > Attributes > > > SSL,S/MIME,JAR/XPI > > CA certificate CT,, > > Which leads me to believe that it should be able to at least find the > certificate... > > I also checked file/directory ownership and permissions which match > those on the working 'master' server. > > Installer issue: > > If you make a mistake and get asked to try again (I typed the ldaps > port as 633 instead if 636), you get stuck at the CA Certificate > filename stage with the following: > > CA certificate filename [/etc/openldap/cacerts/CAServer.crt]: > > The certificate database in '/etc/dirsrv/admin-serv' already contains > a CA certificate. Please remove it first, or use the certutil program > to add the CA certificate with a different name. > > Please try again, in case you mis-typed something. > > Simple enough solution as for me this is a fresh install, is to delete > cert8.db and keys3.db in /etc/dirserv/admin-serv/ from another session. > > You can use ldapsearch to test if the cert db is correct: > > LDAPTLS_CACERTDIR=/etc/dirsrv/admin-serv ldapsearch -x -H > ldaps://<Config Server FQDN> -D "cn=directory manager" -W -s base -b "" > if that doesn't work, use ldapsearch -d 1 -x .... to get more > debugging information. > > The error is strange though. It seems to imply that the admin server > is looking for a cert or key. If the admin server is acting only as > an SSL client, it should not need to look up a cert or key, it should > only need the CA cert. > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > > > -- > 389 users mailing list > 389-users(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > https://admin.fedoraproject.org/mailman/listinfo/389-users > > ------------------------------------------------------------------- > > *GreeNRB > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ >

1 0

Re: [389-users] admserv_host_ip_check: ap_get_remote_host could not resolve
by Rich Megginson 09 Feb '12

09 Feb '12

On 02/08/2012 12:09 PM, MATON Brett wrote: > > Hi Rick, > > I restarted both dirsrv and dirsrv-admin, problem persists though. > ok - try this service dirsrv-admin stop edit /etc/dirsrv/admin-serv/local.conf - remove any nsAdminAccessHost lines service dirsrv-admin start > > *De :*Rich Megginson [mailto:rmeggins@redhat.com] > *Envoyé :* mercredi 8 février 2012 16:39 > *À :* General discussion list for the 389 Directory server project. > *Cc :* MATON Brett > *Objet :* Re: [389-users] admserv_host_ip_check: ap_get_remote_host > could not resolve > > On 02/08/2012 08:19 AM, MATON Brett wrote: > > Thanks the update to the wiki solved the "wrong attribute type" error > on nsAdminAccessHosts. > > Configuration as it stands, with no nsAdminAccessHosts attribure: > > # configuration, admin-serv-<host>, 389 Administration Server, Server Gro > > up, <fqdn>, admins.unix, NetscapeRoot > > dn: cn=configuration,cn=admin-serv-<host>,cn=389 Administration > Server,cn=Server Group,cn=<fqdn>,ou=admins.unix,o=NetscapeRoot > > nsServerPort: 9830 > > objectClass: nsConfig > > objectClass: nsAdminConfig > > objectClass: nsAdminObject > > objectClass: nsDirectoryInfo > > objectClass: top > > nsClassname: > com.netscape.management.admserv.AdminServer@389-admin-1.1.jar@cn=admin-serv-<host>,cn=389 > <mailto:com.netscape.management.admserv.AdminServer@389-admin-1.1.jar@cn=admin-serv-%3chost%3e,cn=389> > Administration Server,cn=Server > Group,cn=<fqdn>,ou=admins.unix,o=NetscapeRoot > > cn: Configuration > > nsDirectoryInfoRef: cn=Server > Group,cn=<fqdn>,ou=admins.unix,o=NetscapeRoot > > nsAdminAccessAddresses: * > > nsSuiteSpotUser: nobody > > nsAdminEnableDSGW: on > > nsAdminCacheLifetime: 600 > > nsDefaultAcceptLanguage: en > > nsServerAddress: 0.0.0.0 > > nsAdminOneACLDir: adminacl > > nsErrorLog: /var/log/dirsrv/admin-serv/error > > nsAdminUsers: /etc/dirsrv/admin-serv/admpw > > nsPidLog: admin-serv.pid > > nsAccessLog: /var/log/dirsrv/admin-serv/access > > nsAdminEnableEnduser: on > > nsServerSecurity: on > > admin-serv/error log after restarting admin-serv (also tried > restarting dirsrv / dirsrv-admin): > > [Wed Feb 08 07:02:35 2012] [notice] caught SIGTERM, shutting down > > [Wed Feb 08 07:02:36 2012] [notice] SELinux policy enabled; httpd > running as context unconfined_u:system_r:httpd_t:s0 > > [Wed Feb 08 07:02:37 2012] [notice] Access Host filter is: * > > [Wed Feb 08 07:02:37 2012] [notice] Access Address filter is: * > > [Wed Feb 08 07:02:38 2012] [notice] Apache/2.2.15 (Unix) > mod_nss/2.2.15 NSS/3.12.9.0 configured -- resuming normal operations > > [Wed Feb 08 07:02:38 2012] [notice] Access Host filter is: * > > [Wed Feb 08 07:02:38 2012] [notice] Access Address filter is: * > > [Wed Feb 08 07:03:07 2012] [notice] [client <client ip>] > admserv_host_ip_check: ap_get_remote_host could not resolve <client ip> > > [Wed Feb 08 07:03:07 2012] [notice] [client <client ip>] > admserv_check_authz(): passing [/admin-serv/authenticate] to the > userauth handler > > [Wed Feb 08 07:17:10 2012] [notice] [client <client ip>] > admserv_host_ip_check: ap_get_remote_host could not resolve <client ip> > > [Wed Feb 08 07:17:10 2012] [notice] [client <client ip>] > admserv_check_authz(): passing [/admin-serv/authenticate] to the > userauth handler > > [Wed Feb 08 07:17:17 2012] [notice] [client <client ip>] > admserv_host_ip_check: ap_get_remote_host could not resolve <client ip> > > I'm still getting the could not resolve notices, and noticed that the > Access Host filter is still '*', picking up a default somewhere? > > (I don't know why it can't resolve either, nslookup / host can both > resolve ip's to hostnames and vice versa). > > Did you restart the admin server after making this change? > > Brett > > *From:*Rich Megginson [mailto:rmeggins@redhat.com] > *Sent:* 08 February 2012 00:57 > *To:* MATON Brett > *Cc:* General discussion list for the 389 Directory server project. > *Subject:* Re: [389-users] admserv_host_ip_check: ap_get_remote_host > could not resolve > > On 02/07/2012 03:23 PM, MATON Brett wrote: > > Hi Rich, > > I tried this and got the following error : > > Enter LDAP Password: > > dn: cn=configuration,cn=admin-serv-<host>,cn=389 Administration Server,cn= > > Server Group,cn=<fqdn>,ou=admins.unix,o=NetscapeRoot > > changetype: modify > > replace: nsAdminAccessAddresses nsAdminAccessHosts > > nsAdminAccessAddresses: * > > nsAdminAccessHosts: > > ldapmodify: wrong attributeType at line 4, entry > "cn=configuration,cn=admin-serv-<host>,cn=389 Administration > Server,cn=Server Group,cn=<fqdn>,ou=admins.unix,o=NetscapeRoot" > > Does this mean anything to you? > > Yes, a typo on the wiki page. I've updated the page. > > > Thanks, > > Brett > > *De :*Rich Megginson [mailto:rmeggins@redhat.com] > *Envoyé :* mardi 7 février 2012 15:18 > *À :* General discussion list for the 389 Directory server project. > *Cc :* MATON Brett > *Objet :* Re: [389-users] admserv_host_ip_check: ap_get_remote_host > could not resolve > > On 02/07/2012 01:05 AM, MATON Brett wrote: > > How can I stop admin server from logging theses messages? > > I realize from the console.conf file that the messages are created > because HostnameLookups is Off. > > My /etc/dirsrv.admin-serv/httpd.conf file has LogLevel set to warn, so > why is it logging notice messages? > > I'm probably overlooking some other configuration file somewhere. > > Any help appreciated > > As a side note, why is it whining about name resolution when the > configuration specifically says Don't do name lookups? > > http://directory.fedoraproject.org/wiki/Howto:AdminServerLDAPMgmt > > > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > > > -- > 389 users mailing list > 389-users(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > https://admin.fedoraproject.org/mailman/listinfo/389-users > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > > > -- > 389 users mailing list > 389-users(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > https://admin.fedoraproject.org/mailman/listinfo/389-users > > ------------------------------------------------------------------- > > *GreeNRB > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ >

1 0

Re: [389-users] dirsrv-admin with existing (remote) configuration server using SSL
by Rich Megginson 08 Feb '12

08 Feb '12

On 02/08/2012 07:20 AM, MATON Brett wrote: > > Installation appears to go fine until it tries to start the admin server: > > Configuration directory server URL [ldap://<local > FQDN>:389/o=NetscapeRoot]: ldaps://<Config Server FQDN>:636/o=NetscapeRoot > > ... > > CA certificate filename: /etc/openldap/cacerts/<base64 cert file> > > ... > > output: Server failed to start !!! Please check errors log for problems > > output: [FAILED] > > /var/log/dirsrv/admin-serv/error: > > [Wed Feb 08 13:35:26 2012] [notice] SELinux policy enabled; httpd > running as context unconfined_u:system_r:httpd_t:s0 > > [Wed Feb 08 13:35:32 2012] [crit] sslinit: NSS is required to use > LDAPS, but security initialization failed [-12285:Unable to find the > certificate or key necessary for authentication.]. Cannot start server > > The server, has however successfully registered itself with the remote > Configuration Directory Server. > > (shows up in the server group in 389-Console and Directory Server is > available). > > I wasn't asked to provide a keystore password when adding the > certificate to the store, as you would be with 389-Console GUI when > first opening the certificate store. > > Is that intentional or not? > > I'm now a bit stumped (again), I had a look at the certdb with certutil: > > [root@<host> admin-serv]# certutil -d . -L > > Certificate Nickname Trust > Attributes > > > SSL,S/MIME,JAR/XPI > > CA certificate CT,, > > Which leads me to believe that it should be able to at least find the > certificate... > > I also checked file/directory ownership and permissions which match > those on the working 'master' server. > > Installer issue: > > If you make a mistake and get asked to try again (I typed the ldaps > port as 633 instead if 636), you get stuck at the CA Certificate > filename stage with the following: > > CA certificate filename [/etc/openldap/cacerts/CAServer.crt]: > > The certificate database in '/etc/dirsrv/admin-serv' already contains > a CA certificate. Please remove it first, or use the certutil program > to add the CA certificate with a different name. > > Please try again, in case you mis-typed something. > > Simple enough solution as for me this is a fresh install, is to delete > cert8.db and keys3.db in /etc/dirserv/admin-serv/ from another session. > You can use ldapsearch to test if the cert db is correct: LDAPTLS_CACERTDIR=/etc/dirsrv/admin-serv ldapsearch -x -H ldaps://<Config Server FQDN> -D "cn=directory manager" -W -s base -b "" if that doesn't work, use ldapsearch -d 1 -x .... to get more debugging information. The error is strange though. It seems to imply that the admin server is looking for a cert or key. If the admin server is acting only as an SSL client, it should not need to look up a cert or key, it should only need the CA cert. > > ------------------------------------------------------------------- > > *GreeNRB > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > > -- > 389 users mailing list > 389-users(a)lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users

1 0

Re: [389-users] admserv_host_ip_check: ap_get_remote_host could not resolve
by Rich Megginson 08 Feb '12

08 Feb '12

On 02/08/2012 08:19 AM, MATON Brett wrote: > > Thanks the update to the wiki solved the "wrong attribute type" error > on nsAdminAccessHosts. > > Configuration as it stands, with no nsAdminAccessHosts attribure: > > # configuration, admin-serv-<host>, 389 Administration Server, Server Gro > > up, <fqdn>, admins.unix, NetscapeRoot > > dn: cn=configuration,cn=admin-serv-<host>,cn=389 Administration > Server,cn=Server Group,cn=<fqdn>,ou=admins.unix,o=NetscapeRoot > > nsServerPort: 9830 > > objectClass: nsConfig > > objectClass: nsAdminConfig > > objectClass: nsAdminObject > > objectClass: nsDirectoryInfo > > objectClass: top > > nsClassname: > com.netscape.management.admserv.AdminServer@389-admin-1.1.jar@cn=admin-serv-<host>,cn=389 > <mailto:com.netscape.management.admserv.AdminServer@389-admin-1.1.jar@cn=admin-serv-%3chost%3e,cn=389> > Administration Server,cn=Server > Group,cn=<fqdn>,ou=admins.unix,o=NetscapeRoot > > cn: Configuration > > nsDirectoryInfoRef: cn=Server > Group,cn=<fqdn>,ou=admins.unix,o=NetscapeRoot > > nsAdminAccessAddresses: * > > nsSuiteSpotUser: nobody > > nsAdminEnableDSGW: on > > nsAdminCacheLifetime: 600 > > nsDefaultAcceptLanguage: en > > nsServerAddress: 0.0.0.0 > > nsAdminOneACLDir: adminacl > > nsErrorLog: /var/log/dirsrv/admin-serv/error > > nsAdminUsers: /etc/dirsrv/admin-serv/admpw > > nsPidLog: admin-serv.pid > > nsAccessLog: /var/log/dirsrv/admin-serv/access > > nsAdminEnableEnduser: on > > nsServerSecurity: on > > admin-serv/error log after restarting admin-serv (also tried > restarting dirsrv / dirsrv-admin): > > [Wed Feb 08 07:02:35 2012] [notice] caught SIGTERM, shutting down > > [Wed Feb 08 07:02:36 2012] [notice] SELinux policy enabled; httpd > running as context unconfined_u:system_r:httpd_t:s0 > > [Wed Feb 08 07:02:37 2012] [notice] Access Host filter is: * > > [Wed Feb 08 07:02:37 2012] [notice] Access Address filter is: * > > [Wed Feb 08 07:02:38 2012] [notice] Apache/2.2.15 (Unix) > mod_nss/2.2.15 NSS/3.12.9.0 configured -- resuming normal operations > > [Wed Feb 08 07:02:38 2012] [notice] Access Host filter is: * > > [Wed Feb 08 07:02:38 2012] [notice] Access Address filter is: * > > [Wed Feb 08 07:03:07 2012] [notice] [client <client ip>] > admserv_host_ip_check: ap_get_remote_host could not resolve <client ip> > > [Wed Feb 08 07:03:07 2012] [notice] [client <client ip>] > admserv_check_authz(): passing [/admin-serv/authenticate] to the > userauth handler > > [Wed Feb 08 07:17:10 2012] [notice] [client <client ip>] > admserv_host_ip_check: ap_get_remote_host could not resolve <client ip> > > [Wed Feb 08 07:17:10 2012] [notice] [client <client ip>] > admserv_check_authz(): passing [/admin-serv/authenticate] to the > userauth handler > > [Wed Feb 08 07:17:17 2012] [notice] [client <client ip>] > admserv_host_ip_check: ap_get_remote_host could not resolve <client ip> > > I'm still getting the could not resolve notices, and noticed that the > Access Host filter is still '*', picking up a default somewhere? > > (I don't know why it can't resolve either, nslookup / host can both > resolve ip's to hostnames and vice versa). > Did you restart the admin server after making this change? > > Brett > > *From:*Rich Megginson [mailto:rmeggins@redhat.com] > *Sent:* 08 February 2012 00:57 > *To:* MATON Brett > *Cc:* General discussion list for the 389 Directory server project. > *Subject:* Re: [389-users] admserv_host_ip_check: ap_get_remote_host > could not resolve > > On 02/07/2012 03:23 PM, MATON Brett wrote: > > Hi Rich, > > I tried this and got the following error : > > Enter LDAP Password: > > dn: cn=configuration,cn=admin-serv-<host>,cn=389 Administration Server,cn= > > Server Group,cn=<fqdn>,ou=admins.unix,o=NetscapeRoot > > changetype: modify > > replace: nsAdminAccessAddresses nsAdminAccessHosts > > nsAdminAccessAddresses: * > > nsAdminAccessHosts: > > ldapmodify: wrong attributeType at line 4, entry > "cn=configuration,cn=admin-serv-<host>,cn=389 Administration > Server,cn=Server Group,cn=<fqdn>,ou=admins.unix,o=NetscapeRoot" > > Does this mean anything to you? > > Yes, a typo on the wiki page. I've updated the page. > > Thanks, > > Brett > > *De :*Rich Megginson [mailto:rmeggins@redhat.com] > *Envoyé :* mardi 7 février 2012 15:18 > *À :* General discussion list for the 389 Directory server project. > *Cc :* MATON Brett > *Objet :* Re: [389-users] admserv_host_ip_check: ap_get_remote_host > could not resolve > > On 02/07/2012 01:05 AM, MATON Brett wrote: > > How can I stop admin server from logging theses messages? > > I realize from the console.conf file that the messages are created > because HostnameLookups is Off. > > My /etc/dirsrv.admin-serv/httpd.conf file has LogLevel set to warn, so > why is it logging notice messages? > > I'm probably overlooking some other configuration file somewhere. > > Any help appreciated > > As a side note, why is it whining about name resolution when the > configuration specifically says Don't do name lookups? > > http://directory.fedoraproject.org/wiki/Howto:AdminServerLDAPMgmt > > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > > > -- > 389 users mailing list > 389-users(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > https://admin.fedoraproject.org/mailman/listinfo/389-users > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > ------------------------------------------------------------------- > > *GreeNRB > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > > -- > 389 users mailing list > 389-users(a)lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users

1 0

Re: [389-users] admserv_host_ip_check: ap_get_remote_host could not resolve
by Rich Megginson 08 Feb '12

08 Feb '12

On 02/07/2012 03:23 PM, MATON Brett wrote: > > Hi Rich, > > I tried this and got the following error : > > Enter LDAP Password: > > dn: cn=configuration,cn=admin-serv-<host>,cn=389 Administration Server,cn= > > Server Group,cn=<fqdn>,ou=admins.unix,o=NetscapeRoot > > changetype: modify > > replace: nsAdminAccessAddresses nsAdminAccessHosts > > nsAdminAccessAddresses: * > > nsAdminAccessHosts: > > ldapmodify: wrong attributeType at line 4, entry > "cn=configuration,cn=admin-serv-<host>,cn=389 Administration > Server,cn=Server Group,cn=<fqdn>,ou=admins.unix,o=NetscapeRoot" > > Does this mean anything to you? > Yes, a typo on the wiki page. I've updated the page. > > Thanks, > > Brett > > *De :*Rich Megginson [mailto:rmeggins@redhat.com] > *Envoyé :* mardi 7 février 2012 15:18 > *À :* General discussion list for the 389 Directory server project. > *Cc :* MATON Brett > *Objet :* Re: [389-users] admserv_host_ip_check: ap_get_remote_host > could not resolve > > On 02/07/2012 01:05 AM, MATON Brett wrote: > > How can I stop admin server from logging theses messages? > > I realize from the console.conf file that the messages are created > because HostnameLookups is Off. > > My /etc/dirsrv.admin-serv/httpd.conf file has LogLevel set to warn, so > why is it logging notice messages? > > I'm probably overlooking some other configuration file somewhere. > > Any help appreciated > > As a side note, why is it whining about name resolution when the > configuration specifically says Don't do name lookups? > > http://directory.fedoraproject.org/wiki/Howto:AdminServerLDAPMgmt > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > > > -- > 389 users mailing list > 389-users(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > https://admin.fedoraproject.org/mailman/listinfo/389-users > > ------------------------------------------------------------------- > > *GreeNRB > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users February 2012