Announcing 389 Directory Server 1.2.6

[Rich Megginson]

The 389 team is pleased to announce the availability of version 1.2.6.
This release is essentially the same as 1.2.6 RC7.

* Release Notes - http://port389.org/wiki/Release_Notes
* Install_Guide - http://port389.org/wiki/Install_Guide
* Download - http://port389.org/wiki/Download

=== New features ===
* Upgrade_to_New_DN_Format 
http://directory.fedoraproject.org/wiki/Upgrade_to_New_DN_Format
** in order to make sure DN valued attributes can be searched correctly, 
an upgrade will automatically fix these values in the database

* Replication_Session_Hooks 
http://directory.fedoraproject.org/wiki/Replication_Session_Hooks
** API for plugins to intercept replication session at various points

* Managed Entries - 
http://directory.fedoraproject.org/wiki/Managed_Entry_Design
** Used, for example, to automatically create the user's group entry 
when adding a user entry

* Subtree Rename and Entry Move (modifyDN with newSuperior)
** https://bugzilla.redhat.com/show_bug.cgi?id=429005
** ability to rename a node that has children
** ability to move a node, with or without children, to another parent node

* Security Enhancements
** SELinux Policy http://directory.fedoraproject.org/wiki/SELinux_Policy
*** https://bugzilla.redhat.com/show_bug.cgi?id=442228

* Matching rules
** support for all RFC 4517 matching rules (except the FirstComponent ones)

=== Bugs Fixed ===
This release contains many, many bug fixes.  The complete list of bugs
fixed is found at the link below.  Note that bugs marked as MODIFIED
have been fixed but are still in testing.
* Tracking bug for 1.2.6 release -
https://bugzilla.redhat.com/showdependencytree.cgi?id=543590&hide_resolv...

[Aaron Hagopian]

After upgrading, although it's possible it broke on one of the RCs since I
do not usually run the admin server on my development environment, when I
try to connect using the 389-console I get an error 32, cannot connect to
the directory server....

When I look through the admin-serv logs i see:

[Tue Sep 14 08:53:43 2010] [notice] [client 127.0.0.1]
admserv_host_ip_check: ap_get_remote_host could not resolve 127.0.0.1
[Tue Sep 14 08:53:43 2010] [notice] [client 127.0.0.1]
admserv_host_ip_check: host [localhost.localdomain] did not match pattern
[*.barf.hra.local] -will scan aliases
[Tue Sep 14 08:53:43 2010] [notice] [client 127.0.0.1]
admserv_host_ip_check: host alias [localhost] did not match pattern
[*.barf.hra.local]
[Tue Sep 14 08:53:43 2010] [crit] buildUGInfo(): unable to initialize TLS
connection to LDAP host barfolomew.hra.local port 389: 4
[Tue Sep 14 08:53:43 2010] [notice] [client 127.0.0.1]
admserv_check_authz(): passing [/admin-serv/authenticate] to the userauth
handler
[Tue Sep 14 08:53:43 2010] [crit] buildUGInfo(): unable to initialize TLS
connection to LDAP host barfolomew.hra.local port 389: 4

Now I see what the problem is about the cert name but I never told the admin
server to use TLS to connect to the LDAP server and when I was running 1.2.5
I never had this problem.  I do run my server on SSL as well on port 636.
 Is it trying start TLS because it can?  Anyway to disable that since I do
not feel like generating a new cert to match my administrative domain I put
in when I setup the DS.

[root@barfolomew admin-serv]# rpm -qi 389-ds-base
Name        : 389-ds-base                  Relocations: (not relocatable)
Version     : 1.2.6                             Vendor: Fedora Project
Release     : 1.fc13                        Build Date: Thu 26 Aug 2010
04:34:30 PM CDT
Install Date: Mon 13 Sep 2010 09:19:02 AM CDT      Build Host:
x86-20.phx2.fedoraproject.org
Group       : System Environment/Daemons    Source RPM:
389-ds-base-1.2.6-1.fc13.src.rpm
Size        : 6043179                          License: GPLv2 with
exceptions
Signature   : RSA/SHA256, Thu 26 Aug 2010 08:43:14 PM CDT, Key ID
7edc6ad6e8e40fde
Packager    : Fedora Project
URL         : http://port389.org/
Summary     : 389 Directory Server (base)
Description :
389 Directory Server is an LDAPv3 compliant server.  The base package
includes
the LDAP server and command line utilities for server administration.

[root@barfolomew admin-serv]# rpm -qi 389-admin
Name        : 389-admin                    Relocations: (not relocatable)
Version     : 1.1.11                            Vendor: Fedora Project
Release     : 1.fc13                        Build Date: Thu 26 Aug 2010
04:53:40 PM CDT
Install Date: Mon 13 Sep 2010 09:19:35 AM CDT      Build Host:
x86-20.phx2.fedoraproject.org
Group       : System Environment/Daemons    Source RPM:
389-admin-1.1.11-1.fc13.src.rpm
Size        : 1510119                          License: GPLv2 and ASL 2.0
Signature   : RSA/SHA256, Thu 26 Aug 2010 08:49:10 PM CDT, Key ID
7edc6ad6e8e40fde
Packager    : Fedora Project
URL         : http://port389.org/
Summary     : 389 Administration Server (admin)
Description :
389 Administration Server is an HTTP agent that provides management features
for 389 Directory Server.  It provides some management web apps that can
be used through a web browser.  It provides the authentication, access
control,
and CGI utilities used by the console.

On Mon, Sep 13, 2010 at 2:03 PM, Rich Megginson  wrote:
> The 389 team is pleased to announce the availability of version 1.2.6.
> This release is essentially the same as 1.2.6 RC7.
> Release Notes - http://port389.org/wiki/Release_Notes
> Install_Guide - http://port389.org/wiki/Install_Guide
> Download - http://port389.org/wiki/Download
>
> === New features ===
> Upgrade_to_New_DN_Format
>
> http://directory.fedoraproject.org/wiki/Upgrade_to_New_DN_Format
> ** in order to make sure DN valued attributes can be searched correctly,
> an upgrade will automatically fix these values in the database
> Replication_Session_Hooks
>
> http://directory.fedoraproject.org/wiki/Replication_Session_Hooks
> ** API for plugins to intercept replication session at various points
> Managed Entries -
>
> http://directory.fedoraproject.org/wiki/Managed_Entry_Design
> ** Used, for example, to automatically create the user's group entry
> when adding a user entry
> Subtree Rename and Entry Move (modifyDN with newSuperior)
>
> ** https://bugzilla.redhat.com/show_bug.cgi?id=429005
> ** ability to rename a node that has children
> ** ability to move a node, with or without children, to another parent node
> Security Enhancements
>
> ** SELinux Policy http://directory.fedoraproject.org/wiki/SELinux_Policy
> *** https://bugzilla.redhat.com/show_bug.cgi?id=442228
> Matching rules
>
> ** support for all RFC 4517 matching rules (except the FirstComponent ones)
>
> === Bugs Fixed ===
> This release contains many, many bug fixes.  The complete list of bugs
> fixed is found at the link below.  Note that bugs marked as MODIFIED
> have been fixed but are still in testing.
> Tracking bug for 1.2.6 release -
>
> https://bugzilla.redhat.com/showdependencytree.cgi?id=543590&hide_resolv...
>
> --
> 389 users mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/389-users

[Rich Megginson]

Aaron Hagopian wrote:
> After upgrading, although it's possible it broke on one of the RCs 
> since I do not usually run the admin server on my development 
> environment, when I try to connect using the 389-console I get an 
> error 32, cannot connect to the directory server....
>
> When I look through the admin-serv logs i see:
> [Tue Sep 14 08:53:43 2010] [notice] [client 127.0.0.1]
> admserv_host_ip_check: ap_get_remote_host could not resolve 127.0.0.1
> [Tue Sep 14 08:53:43 2010] [notice] [client 127.0.0.1]
> admserv_host_ip_check: host [localhost.localdomain] did not match
> pattern [*.barf.hra.local] -will scan aliases
> [Tue Sep 14 08:53:43 2010] [notice] [client 127.0.0.1]
> admserv_host_ip_check: host alias [localhost] did not match
> pattern [*.barf.hra.local]
> [Tue Sep 14 08:53:43 2010] [crit] buildUGInfo(): unable to
> initialize TLS connection to LDAP host barfolomew.hra.local port
> 389: 4
> [Tue Sep 14 08:53:43 2010] [notice] [client 127.0.0.1]
> admserv_check_authz(): passing [/admin-serv/authenticate] to the
> userauth handler
> [Tue Sep 14 08:53:43 2010] [crit] buildUGInfo(): unable to
> initialize TLS connection to LDAP host barfolomew.hra.local port
> 389: 4
>
> Now I see what the problem is about the cert name but I never told the 
> admin server to use TLS to connect to the LDAP server and when I was 
> running 1.2.5 I never had this problem.  I do run my server on SSL as 
> well on port 636.  Is it trying start TLS because it can?

No.  Not sure what changed.  Take a look at the directory server access 
log from around this time.  Let's see what the admin server is looking 
for.  Also check /etc/dirsrv/admin-serv/adm.conf and local.conf for any 
tls/ssl/ldaps settings.
> Anyway to disable that since I do not feel like generating a new cert 
> to match my administrative domain I put in when I setup the DS.

http://directory.fedoraproject.org/wiki/Howto:SSL#Console_SSL_Information
or
http://directory.fedoraproject.org/wiki/Howto:SSL#Admin_Server_SSL_Informati...
> [root@barfolomew admin-serv]# rpm -qi 389-ds-base
> Name        : 389-ds-base                  Relocations: (not relocatable)
> Version     : 1.2.6                             Vendor: Fedora Project
> Release     : 1.fc13                        Build Date: Thu 26 Aug 
> 2010 04:34:30 PM CDT
> Install Date: Mon 13 Sep 2010 09:19:02 AM CDT      Build Host: 
> x86-20.phx2.fedoraproject.org http://x86-20.phx2.fedoraproject.org
> Group       : System Environment/Daemons    Source RPM: 
> 389-ds-base-1.2.6-1.fc13.src.rpm
> Size        : 6043179                          License: GPLv2 with 
> exceptions
> Signature   : RSA/SHA256, Thu 26 Aug 2010 08:43:14 PM CDT, Key ID 
> 7edc6ad6e8e40fde
> Packager    : Fedora Project
> URL         : http://port389.org/
> Summary     : 389 Directory Server (base)
> Description :
> 389 Directory Server is an LDAPv3 compliant server.  The base package 
> includes
> the LDAP server and command line utilities for server administration.
>
> [root@barfolomew admin-serv]# rpm -qi 389-admin
> Name        : 389-admin                    Relocations: (not relocatable)
> Version     : 1.1.11                            Vendor: Fedora Project
> Release     : 1.fc13                        Build Date: Thu 26 Aug 
> 2010 04:53:40 PM CDT
> Install Date: Mon 13 Sep 2010 09:19:35 AM CDT      Build Host: 
> x86-20.phx2.fedoraproject.org http://x86-20.phx2.fedoraproject.org
> Group       : System Environment/Daemons    Source RPM: 
> 389-admin-1.1.11-1.fc13.src.rpm
> Size        : 1510119                          License: GPLv2 and ASL 2.0
> Signature   : RSA/SHA256, Thu 26 Aug 2010 08:49:10 PM CDT, Key ID 
> 7edc6ad6e8e40fde
> Packager    : Fedora Project
> URL         : http://port389.org/
> Summary     : 389 Administration Server (admin)
> Description :
> 389 Administration Server is an HTTP agent that provides management 
> features
> for 389 Directory Server.  It provides some management web apps that can
> be used through a web browser.  It provides the authentication, access 
> control,
> and CGI utilities used by the console.
>
> On Mon, Sep 13, 2010 at 2:03 PM, Rich Megginson <[e-mail] 
> > wrote:
> The 389 team is pleased to announce the availability of version 1.2.6.
> This release is essentially the same as 1.2.6 RC7.
>
> * Release Notes - http://port389.org/wiki/Release_Notes
> * Install_Guide - http://port389.org/wiki/Install_Guide
> * Download - http://port389.org/wiki/Download
>
> === New features ===
> * Upgrade_to_New_DN_Format
> http://directory.fedoraproject.org/wiki/Upgrade_to_New_DN_Format
> ** in order to make sure DN valued attributes can be searched
> correctly,
> an upgrade will automatically fix these values in the database
>
> * Replication_Session_Hooks
> http://directory.fedoraproject.org/wiki/Replication_Session_Hooks
> ** API for plugins to intercept replication session at various points
>
> * Managed Entries -
> http://directory.fedoraproject.org/wiki/Managed_Entry_Design
> ** Used, for example, to automatically create the user's group entry
> when adding a user entry
>
> * Subtree Rename and Entry Move (modifyDN with newSuperior)
> ** https://bugzilla.redhat.com/show_bug.cgi?id=429005
> ** ability to rename a node that has children
> ** ability to move a node, with or without children, to another
> parent node
>
> * Security Enhancements
> ** SELinux Policy
> http://directory.fedoraproject.org/wiki/SELinux_Policy
> *** https://bugzilla.redhat.com/show_bug.cgi?id=442228
>
> * Matching rules
> ** support for all RFC 4517 matching rules (except the
> FirstComponent ones)
>
> === Bugs Fixed ===
> This release contains many, many bug fixes.  The complete list of bugs
> fixed is found at the link below.  Note that bugs marked as MODIFIED
> have been fixed but are still in testing.
> * Tracking bug for 1.2.6 release -
> https://bugzilla.redhat.com/showdependencytree.cgi?id=543590&hide_resolved=0
> <https://bugzilla.redhat.com/showdependencytree.cgi?id=543590&hide_resolved=0>
>
>
> --
> 389 users mailing list
> [e-mail]
> <mailto:[e-mail]>
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
> --
> 389 users mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/389-users

[Aaron Hagopian]

Think I figured it out, a while back when I had to do the manual steps from
something like RC5->RC6, my netscapeRoot didn't load back properly leaving
with an empty o=netscapeRoot

On Tue, Sep 14, 2010 at 10:20 AM, Rich Megginson wrote:
> Aaron Hagopian wrote:
> > After upgrading, although it's possible it broke on one of the RCs
> > since I do not usually run the admin server on my development
> > environment, when I try to connect using the 389-console I get an
> > error 32, cannot connect to the directory server....
> >
> > When I look through the admin-serv logs i see:
> > [Tue Sep 14 08:53:43 2010] [notice] [client 127.0.0.1]
> > admserv_host_ip_check: ap_get_remote_host could not resolve 127.0.0.1
> > [Tue Sep 14 08:53:43 2010] [notice] [client 127.0.0.1]
> > admserv_host_ip_check: host [localhost.localdomain] did not match
> > pattern [*.barf.hra.local] -will scan aliases
> > [Tue Sep 14 08:53:43 2010] [notice] [client 127.0.0.1]
> > admserv_host_ip_check: host alias [localhost] did not match
> > pattern [*.barf.hra.local]
> > [Tue Sep 14 08:53:43 2010] [crit] buildUGInfo(): unable to
> > initialize TLS connection to LDAP host barfolomew.hra.local port
> > 389: 4
> > [Tue Sep 14 08:53:43 2010] [notice] [client 127.0.0.1]
> > admserv_check_authz(): passing [/admin-serv/authenticate] to the
> > userauth handler
> > [Tue Sep 14 08:53:43 2010] [crit] buildUGInfo(): unable to
> > initialize TLS connection to LDAP host barfolomew.hra.local port
> > 389: 4
> >
> > Now I see what the problem is about the cert name but I never told the
> > admin server to use TLS to connect to the LDAP server and when I was
> > running 1.2.5 I never had this problem.  I do run my server on SSL as
> > well on port 636.  Is it trying start TLS because it can?
>
> No.  Not sure what changed.  Take a look at the directory server access
> log from around this time.  Let's see what the admin server is looking
> for.  Also check /etc/dirsrv/admin-serv/adm.conf and local.conf for any
> tls/ssl/ldaps settings.
> > Anyway to disable that since I do not feel like generating a new cert
> > to match my administrative domain I put in when I setup the DS.
>
> http://directory.fedoraproject.org/wiki/Howto:SSL#Console_SSL_Information
> or
>
> http://directory.fedoraproject.org/wiki/Howto:SSL#Admin_Server_SSL_Informati...
> > [root@barfolomew admin-serv]# rpm -qi 389-ds-base
> > Name        : 389-ds-base                  Relocations: (not relocatable)
> > Version     : 1.2.6                             Vendor: Fedora Project
> > Release     : 1.fc13                        Build Date: Thu 26 Aug
> > 2010 04:34:30 PM CDT
> > Install Date: Mon 13 Sep 2010 09:19:02 AM CDT      Build Host:
> > x86-20.phx2.fedoraproject.org http://x86-20.phx2.fedoraproject.org
> > Group       : System Environment/Daemons    Source RPM:
> > 389-ds-base-1.2.6-1.fc13.src.rpm
> > Size        : 6043179                          License: GPLv2 with
> > exceptions
> > Signature   : RSA/SHA256, Thu 26 Aug 2010 08:43:14 PM CDT, Key ID
> > 7edc6ad6e8e40fde
> > Packager    : Fedora Project
> > URL         : http://port389.org/
> > Summary     : 389 Directory Server (base)
> > Description :
> > 389 Directory Server is an LDAPv3 compliant server.  The base package
> > includes
> > the LDAP server and command line utilities for server administration.
> >
> > [root@barfolomew admin-serv]# rpm -qi 389-admin
> > Name        : 389-admin                    Relocations: (not relocatable)
> > Version     : 1.1.11                            Vendor: Fedora Project
> > Release     : 1.fc13                        Build Date: Thu 26 Aug
> > 2010 04:53:40 PM CDT
> > Install Date: Mon 13 Sep 2010 09:19:35 AM CDT      Build Host:
> > x86-20.phx2.fedoraproject.org http://x86-20.phx2.fedoraproject.org
> > Group       : System Environment/Daemons    Source RPM:
> > 389-admin-1.1.11-1.fc13.src.rpm
> > Size        : 1510119                          License: GPLv2 and ASL 2.0
> > Signature   : RSA/SHA256, Thu 26 Aug 2010 08:49:10 PM CDT, Key ID
> > 7edc6ad6e8e40fde
> > Packager    : Fedora Project
> > URL         : http://port389.org/
> > Summary     : 389 Administration Server (admin)
> > Description :
> > 389 Administration Server is an HTTP agent that provides management
> > features
> > for 389 Directory Server.  It provides some management web apps that can
> > be used through a web browser.  It provides the authentication, access
> > control,
> > and CGI utilities used by the console.
> >
> > On Mon, Sep 13, 2010 at 2:03 PM, Rich Megginson <[e-mail]
> > > wrote:
> > The 389 team is pleased to announce the availability of version
>
> 1.2.6.
> > This release is essentially the same as 1.2.6 RC7.
> >
> > * Release Notes - http://port389.org/wiki/Release_Notes
> > * Install_Guide - http://port389.org/wiki/Install_Guide
> > * Download - http://port389.org/wiki/Download
> >
> > === New features ===
> > * Upgrade_to_New_DN_Format
> > http://directory.fedoraproject.org/wiki/Upgrade_to_New_DN_Format
> > ** in order to make sure DN valued attributes can be searched
> > correctly,
> > an upgrade will automatically fix these values in the database
> >
> > * Replication_Session_Hooks
> > http://directory.fedoraproject.org/wiki/Replication_Session_Hooks
> > ** API for plugins to intercept replication session at various points
> >
> > * Managed Entries -
> > http://directory.fedoraproject.org/wiki/Managed_Entry_Design
> > ** Used, for example, to automatically create the user's group entry
> > when adding a user entry
> >
> > * Subtree Rename and Entry Move (modifyDN with newSuperior)
> > ** https://bugzilla.redhat.com/show_bug.cgi?id=429005
> > ** ability to rename a node that has children
> > ** ability to move a node, with or without children, to another
> > parent node
> >
> > * Security Enhancements
> > ** SELinux Policy
> > http://directory.fedoraproject.org/wiki/SELinux_Policy
> > *** https://bugzilla.redhat.com/show_bug.cgi?id=442228
> >
> > * Matching rules
> > ** support for all RFC 4517 matching rules (except the
> > FirstComponent ones)
> >
> > === Bugs Fixed ===
> > This release contains many, many bug fixes.  The complete list of
>
> bugs
> > fixed is found at the link below.  Note that bugs marked as MODIFIED
> > have been fixed but are still in testing.
> > * Tracking bug for 1.2.6 release -
>
> https://bugzilla.redhat.com/showdependencytree.cgi?id=543590&hide_resolv...
> > <
>
> https://bugzilla.redhat.com/showdependencytree.cgi?id=543590&hide_resolv...
> > --
> > 389 users mailing list
> > [e-mail]
> > <mailto:[e-mail]>
> > https://admin.fedoraproject.org/mailman/listinfo/389-users
> >
> >
> > --
> > 389 users mailing list
> > [e-mail]
> > https://admin.fedoraproject.org/mailman/listinfo/389-users
>
> --
> 389 users mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/389-users

[Aaron Hagopian]

So i removed my entire setup and tried to re-setup.  Now when I try to
enable SSL for my directory server I get the following error:

[15/Sep/2010:10:25:45 -0500] - SSL alert: Security Initialization: Unable to
authenticate (Netscape Portable Runtime error -8192 - An I/O error occurred
during security authorization.)
[15/Sep/2010:10:25:45 -0500] - ERROR: SSL Initialization Failed.

I tried using my previously working .db files for this instance as well and
did a full re-import for my server cert and the CA cert.  I am working on a
fedora 13 machine that is fully up-to-date.

On Tue, Sep 14, 2010 at 11:43 AM, Aaron Hagopian  wrote:
> Think I figured it out, a while back when I had to do the manual steps from
> something like RC5->RC6, my netscapeRoot didn't load back properly leaving
> with an empty o=netscapeRoot
>
> On Tue, Sep 14, 2010 at 10:20 AM, Rich Megginson wrote:
> > Aaron Hagopian wrote:
> > > After upgrading, although it's possible it broke on one of the RCs
> > > since I do not usually run the admin server on my development
> > > environment, when I try to connect using the 389-console I get an
> > > error 32, cannot connect to the directory server....
> > >
> > > When I look through the admin-serv logs i see:
> > > [Tue Sep 14 08:53:43 2010] [notice] [client 127.0.0.1]
> > > admserv_host_ip_check: ap_get_remote_host could not resolve
> >
> > 127.0.0.1
> > > [Tue Sep 14 08:53:43 2010] [notice] [client 127.0.0.1]
> > > admserv_host_ip_check: host [localhost.localdomain] did not match
> > > pattern [*.barf.hra.local] -will scan aliases
> > > [Tue Sep 14 08:53:43 2010] [notice] [client 127.0.0.1]
> > > admserv_host_ip_check: host alias [localhost] did not match
> > > pattern [*.barf.hra.local]
> > > [Tue Sep 14 08:53:43 2010] [crit] buildUGInfo(): unable to
> > > initialize TLS connection to LDAP host barfolomew.hra.local port
> > > 389: 4
> > > [Tue Sep 14 08:53:43 2010] [notice] [client 127.0.0.1]
> > > admserv_check_authz(): passing [/admin-serv/authenticate] to the
> > > userauth handler
> > > [Tue Sep 14 08:53:43 2010] [crit] buildUGInfo(): unable to
> > > initialize TLS connection to LDAP host barfolomew.hra.local port
> > > 389: 4
> > >
> > > Now I see what the problem is about the cert name but I never told the
> > > admin server to use TLS to connect to the LDAP server and when I was
> > > running 1.2.5 I never had this problem.  I do run my server on SSL as
> > > well on port 636.  Is it trying start TLS because it can?
> >
> > No.  Not sure what changed.  Take a look at the directory server access
> > log from around this time.  Let's see what the admin server is looking
> > for.  Also check /etc/dirsrv/admin-serv/adm.conf and local.conf for any
> > tls/ssl/ldaps settings.
> > > Anyway to disable that since I do not feel like generating a new cert
> > > to match my administrative domain I put in when I setup the DS.
> >
> > http://directory.fedoraproject.org/wiki/Howto:SSL#Console_SSL_Information
> > or
> >
> > http://directory.fedoraproject.org/wiki/Howto:SSL#Admin_Server_SSL_Informati...
> > > [root@barfolomew admin-serv]# rpm -qi 389-ds-base
> > > Name        : 389-ds-base                  Relocations: (not
> >
> > relocatable)
> > > Version     : 1.2.6                             Vendor: Fedora Project
> > > Release     : 1.fc13                        Build Date: Thu 26 Aug
> > > 2010 04:34:30 PM CDT
> > > Install Date: Mon 13 Sep 2010 09:19:02 AM CDT      Build Host:
> > > x86-20.phx2.fedoraproject.org http://x86-20.phx2.fedoraproject.org
> > > Group       : System Environment/Daemons    Source RPM:
> > > 389-ds-base-1.2.6-1.fc13.src.rpm
> > > Size        : 6043179                          License: GPLv2 with
> > > exceptions
> > > Signature   : RSA/SHA256, Thu 26 Aug 2010 08:43:14 PM CDT, Key ID
> > > 7edc6ad6e8e40fde
> > > Packager    : Fedora Project
> > > URL         : http://port389.org/
> > > Summary     : 389 Directory Server (base)
> > > Description :
> > > 389 Directory Server is an LDAPv3 compliant server.  The base package
> > > includes
> > > the LDAP server and command line utilities for server administration.
> > >
> > > [root@barfolomew admin-serv]# rpm -qi 389-admin
> > > Name        : 389-admin                    Relocations: (not
> >
> > relocatable)
> > > Version     : 1.1.11                            Vendor: Fedora Project
> > > Release     : 1.fc13                        Build Date: Thu 26 Aug
> > > 2010 04:53:40 PM CDT
> > > Install Date: Mon 13 Sep 2010 09:19:35 AM CDT      Build Host:
> > > x86-20.phx2.fedoraproject.org http://x86-20.phx2.fedoraproject.org
> > > Group       : System Environment/Daemons    Source RPM:
> > > 389-admin-1.1.11-1.fc13.src.rpm
> > > Size        : 1510119                          License: GPLv2 and ASL
> >
> > 2.0
> > > Signature   : RSA/SHA256, Thu 26 Aug 2010 08:49:10 PM CDT, Key ID
> > > 7edc6ad6e8e40fde
> > > Packager    : Fedora Project
> > > URL         : http://port389.org/
> > > Summary     : 389 Administration Server (admin)
> > > Description :
> > > 389 Administration Server is an HTTP agent that provides management
> > > features
> > > for 389 Directory Server.  It provides some management web apps that can
> > > be used through a web browser.  It provides the authentication, access
> > > control,
> > > and CGI utilities used by the console.
> > >
> > > On Mon, Sep 13, 2010 at 2:03 PM, Rich Megginson <[e-mail]
> > > > wrote:
> > > The 389 team is pleased to announce the availability of version
> >
> > 1.2.6.
> > > This release is essentially the same as 1.2.6 RC7.
> > >
> > > * Release Notes - http://port389.org/wiki/Release_Notes
> > > * Install_Guide - http://port389.org/wiki/Install_Guide
> > > * Download - http://port389.org/wiki/Download
> > >
> > > === New features ===
> > > * Upgrade_to_New_DN_Format
> > > http://directory.fedoraproject.org/wiki/Upgrade_to_New_DN_Format
> > > ** in order to make sure DN valued attributes can be searched
> > > correctly,
> > > an upgrade will automatically fix these values in the database
> > >
> > > * Replication_Session_Hooks
> > > http://directory.fedoraproject.org/wiki/Replication_Session_Hooks
> > > ** API for plugins to intercept replication session at various
> >
> > points
> > > * Managed Entries -
> > > http://directory.fedoraproject.org/wiki/Managed_Entry_Design
> > > ** Used, for example, to automatically create the user's group entry
> > > when adding a user entry
> > >
> > > * Subtree Rename and Entry Move (modifyDN with newSuperior)
> > > ** https://bugzilla.redhat.com/show_bug.cgi?id=429005
> > > ** ability to rename a node that has children
> > > ** ability to move a node, with or without children, to another
> > > parent node
> > >
> > > * Security Enhancements
> > > ** SELinux Policy
> > > http://directory.fedoraproject.org/wiki/SELinux_Policy
> > > *** https://bugzilla.redhat.com/show_bug.cgi?id=442228
> > >
> > > * Matching rules
> > > ** support for all RFC 4517 matching rules (except the
> > > FirstComponent ones)
> > >
> > > === Bugs Fixed ===
> > > This release contains many, many bug fixes.  The complete list of
> >
> > bugs
> > > fixed is found at the link below.  Note that bugs marked as MODIFIED
> > > have been fixed but are still in testing.
> > > * Tracking bug for 1.2.6 release -
> >
> > https://bugzilla.redhat.com/showdependencytree.cgi?id=543590&hide_resolv...
> > > <
> >
> > https://bugzilla.redhat.com/showdependencytree.cgi?id=543590&hide_resolv...
> > > --
> > > 389 users mailing list
> > > [e-mail]
> > > <mailto:[e-mail]>
> > > https://admin.fedoraproject.org/mailman/listinfo/389-users
> > >
> > >
> > > --
> > > 389 users mailing list
> > > [e-mail]
> > > https://admin.fedoraproject.org/mailman/listinfo/389-users
> >
> > --
> > 389 users mailing list
> > [e-mail]
> > https://admin.fedoraproject.org/mailman/listinfo/389-users

[Rich Megginson]

Aaron Hagopian wrote:
> So i removed my entire setup and tried to re-setup.  Now when I try to 
> enable SSL for my directory server I get the following error:
> [15/Sep/2010:10:25:45 -0500] - SSL alert: Security Initialization:
> Unable to authenticate (Netscape Portable Runtime error -8192 - An
> I/O error occurred during security authorization.)
> [15/Sep/2010:10:25:45 -0500] - ERROR: SSL Initialization Failed.
>
>
> I tried using my previously working .db files for this instance as 
> well and did a full re-import for my server cert and the CA cert.  I 
> am working on a fedora 13 machine that is fully up-to-date.

grep nsslapd-localuser /etc/dirsrv/slapd-instance/dse.ldif
ls -al /etc/dirsrv/slapd-instance

try /usr/lib64/dirsrv/slapd-instance/start-slapd -d 1
> On Tue, Sep 14, 2010 at 11:43 AM, Aaron Hagopian <[e-mail] 
> > wrote:
> Think I figured it out, a while back when I had to do the manual
> steps from something like RC5->RC6, my netscapeRoot didn't load
> back properly leaving with an empty o=netscapeRoot
>
>
> On Tue, Sep 14, 2010 at 10:20 AM, Rich Megginson
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     Aaron Hagopian wrote:
>     > After upgrading, although it's possible it broke on one of
>     the RCs
>     > since I do not usually run the admin server on my development
>     > environment, when I try to connect using the 389-console I
>     get an
>     > error 32, cannot connect to the directory server....
>     >
>     > When I look through the admin-serv logs i see:
>     >
>     >     [Tue Sep 14 08:53:43 2010] [notice] [client 127.0.0.1]
>     >     admserv_host_ip_check: ap_get_remote_host could not
>     resolve 127.0.0.1
>     >     [Tue Sep 14 08:53:43 2010] [notice] [client 127.0.0.1]
>     >     admserv_host_ip_check: host [localhost.localdomain] did
>     not match
>     >     pattern [*.barf.hra.local] -will scan aliases
>     >     [Tue Sep 14 08:53:43 2010] [notice] [client 127.0.0.1]
>     >     admserv_host_ip_check: host alias [localhost] did not match
>     >     pattern [*.barf.hra.local]
>     >     [Tue Sep 14 08:53:43 2010] [crit] buildUGInfo(): unable to
>     >     initialize TLS connection to LDAP host
>     barfolomew.hra.local port
>     >     389: 4
>     >     [Tue Sep 14 08:53:43 2010] [notice] [client 127.0.0.1]
>     >     admserv_check_authz(): passing
>     [/admin-serv/authenticate] to the
>     >     userauth handler
>     >     [Tue Sep 14 08:53:43 2010] [crit] buildUGInfo(): unable to
>     >     initialize TLS connection to LDAP host
>     barfolomew.hra.local port
>     >     389: 4
>     >
>     > Now I see what the problem is about the cert name but I
>     never told the
>     > admin server to use TLS to connect to the LDAP server and
>     when I was
>     > running 1.2.5 I never had this problem.  I do run my server
>     on SSL as
>     > well on port 636.  Is it trying start TLS because it can?
>     No.  Not sure what changed.  Take a look at the directory
>     server access
>     log from around this time.  Let's see what the admin server is
>     looking
>     for.  Also check /etc/dirsrv/admin-serv/adm.conf and
>     local.conf for any
>     tls/ssl/ldaps settings.
>     > Anyway to disable that since I do not feel like generating a
>     new cert
>     > to match my administrative domain I put in when I setup the DS.
>     http://directory.fedoraproject.org/wiki/Howto:SSL#Console_SSL_Information
>     or
>     http://directory.fedoraproject.org/wiki/Howto:SSL#Admin_Server_SSL_Information
>     >
>     >
>     >
>     > [root@barfolomew admin-serv]# rpm -qi 389-ds-base
>     > Name        : 389-ds-base                  Relocations: (not
>     relocatable)
>     > Version     : 1.2.6                             Vendor:
>     Fedora Project
>     > Release     : 1.fc13                        Build Date: Thu
>     26 Aug
>     > 2010 04:34:30 PM CDT
>     > Install Date: Mon 13 Sep 2010 09:19:02 AM CDT      Build Host:
>     > x86-20.phx2.fedoraproject.org
>     <http://x86-20.phx2.fedoraproject.org>
>     <http://x86-20.phx2.fedoraproject.org>
>     > Group       : System Environment/Daemons    Source RPM:
>     > 389-ds-base-1.2.6-1.fc13.src.rpm
>     > Size        : 6043179                          License:
>     GPLv2 with
>     > exceptions
>     > Signature   : RSA/SHA256, Thu 26 Aug 2010 08:43:14 PM CDT,
>     Key ID
>     > 7edc6ad6e8e40fde
>     > Packager    : Fedora Project
>     > URL         : http://port389.org/
>     > Summary     : 389 Directory Server (base)
>     > Description :
>     > 389 Directory Server is an LDAPv3 compliant server.  The
>     base package
>     > includes
>     > the LDAP server and command line utilities for server
>     administration.
>     >
>     > [root@barfolomew admin-serv]# rpm -qi 389-admin
>     > Name        : 389-admin                    Relocations: (not
>     relocatable)
>     > Version     : 1.1.11                            Vendor:
>     Fedora Project
>     > Release     : 1.fc13                        Build Date: Thu
>     26 Aug
>     > 2010 04:53:40 PM CDT
>     > Install Date: Mon 13 Sep 2010 09:19:35 AM CDT      Build Host:
>     > x86-20.phx2.fedoraproject.org
>     <http://x86-20.phx2.fedoraproject.org>
>     <http://x86-20.phx2.fedoraproject.org>
>     > Group       : System Environment/Daemons    Source RPM:
>     > 389-admin-1.1.11-1.fc13.src.rpm
>     > Size        : 1510119                          License:
>     GPLv2 and ASL 2.0
>     > Signature   : RSA/SHA256, Thu 26 Aug 2010 08:49:10 PM CDT,
>     Key ID
>     > 7edc6ad6e8e40fde
>     > Packager    : Fedora Project
>     > URL         : http://port389.org/
>     > Summary     : 389 Administration Server (admin)
>     > Description :
>     > 389 Administration Server is an HTTP agent that provides
>     management
>     > features
>     > for 389 Directory Server.  It provides some management web
>     apps that can
>     > be used through a web browser.  It provides the
>     authentication, access
>     > control,
>     > and CGI utilities used by the console.
>     >
>     >
>     >
>     >
>     > On Mon, Sep 13, 2010 at 2:03 PM, Rich Megginson
>     <[e-mail] <mailto:[e-mail]>
>     > <mailto:[e-mail] <mailto:[e-mail]>>>
>     wrote:
>     >
>     >     The 389 team is pleased to announce the availability of
>     version 1.2.6.
>     >     This release is essentially the same as 1.2.6 RC7.
>     >
>     >     * Release Notes - http://port389.org/wiki/Release_Notes
>     >     * Install_Guide - http://port389.org/wiki/Install_Guide
>     >     * Download - http://port389.org/wiki/Download
>     >
>     >     === New features ===
>     >     * Upgrade_to_New_DN_Format
>     >    
>     http://directory.fedoraproject.org/wiki/Upgrade_to_New_DN_Format
>     >     ** in order to make sure DN valued attributes can be
>     searched
>     >     correctly,
>     >     an upgrade will automatically fix these values in the
>     database
>     >
>     >     * Replication_Session_Hooks
>     >    
>     http://directory.fedoraproject.org/wiki/Replication_Session_Hooks
>     >     ** API for plugins to intercept replication session at
>     various points
>     >
>     >     * Managed Entries -
>     >     http://directory.fedoraproject.org/wiki/Managed_Entry_Design
>     >     ** Used, for example, to automatically create the user's
>     group entry
>     >     when adding a user entry
>     >
>     >     * Subtree Rename and Entry Move (modifyDN with newSuperior)
>     >     ** https://bugzilla.redhat.com/show_bug.cgi?id=429005
>     >     ** ability to rename a node that has children
>     >     ** ability to move a node, with or without children, to
>     another
>     >     parent node
>     >
>     >     * Security Enhancements
>     >     ** SELinux Policy
>     >     http://directory.fedoraproject.org/wiki/SELinux_Policy
>     >     *** https://bugzilla.redhat.com/show_bug.cgi?id=442228
>     >
>     >     * Matching rules
>     >     ** support for all RFC 4517 matching rules (except the
>     >     FirstComponent ones)
>     >
>     >     === Bugs Fixed ===
>     >     This release contains many, many bug fixes.  The
>     complete list of bugs
>     >     fixed is found at the link below.  Note that bugs marked
>     as MODIFIED
>     >     have been fixed but are still in testing.
>     >     * Tracking bug for 1.2.6 release -
>     >    
>     https://bugzilla.redhat.com/showdependencytree.cgi?id=543590&hide_resolved=0
>     <https://bugzilla.redhat.com/showdependencytree.cgi?id=543590&hide_resolved=0>
>     >    
>     <https://bugzilla.redhat.com/showdependencytree.cgi?id=543590&hide_resolved=0
>     <https://bugzilla.redhat.com/showdependencytree.cgi?id=543590&hide_resolved=0>>
>     >
>     >
>     >     --
>     >     389 users mailing list
>     >     [e-mail]
>     <mailto:[e-mail]>
>     >     <mailto:[e-mail]
>     <mailto:[e-mail]>>
>     >     https://admin.fedoraproject.org/mailman/listinfo/389-users
>     >
>     >
>     >
>     ------------------------------------------------------------------------
>     >
>     > --
>     > 389 users mailing list
>     > [e-mail]
>     <mailto:[e-mail]>
>     > https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>     --
>     389 users mailing list
>     [e-mail]
>     <mailto:[e-mail]>
>     https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
> --
> 389 users mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/389-users

[Aaron Hagopian]

> grep nsslapd-localuser /etc/dirsrv/slapd-instance/dse.ldif

nsslapd-localuser: nobody

ls -al /etc/dirsrv/slapd-instance
>

[root@barfolomew slapd-barfolomew]# ls -al /etc/dirsrv/slapd-barfolomew
total 364
drwxrwx---. 3 nobody nobody  4096 Sep 16 07:46 .
drwxrwxr-x. 8 root   nobody  4096 Sep 15 10:20 ..
-rw-rw----. 1 nobody nobody 65536 Sep 16 07:44 cert8.db
-r--r-----. 1 nobody nobody  3595 Sep 15 10:20 certmap.conf
-rw-------. 1 nobody nobody 70422 Sep 16 07:44 dse.ldif
-rw-------. 1 nobody nobody 70422 Sep 16 07:44 dse.ldif.bak
-rw-------. 1 nobody nobody 69463 Sep 15 17:32 dse.ldif.startOK
-r--r-----. 1 nobody nobody 31234 Sep 15 10:20 dse_original.ldif
-rw-rw----. 1 nobody nobody 16384 Sep 16 07:44 key3.db
drwxrwx---. 2 nobody nobody  4096 Sep 16 07:46 schema
-rw-rw----. 1 nobody nobody 16384 Sep 15 10:11 secmod.db
-r--r-----. 1 nobody nobody  5366 Sep 15 10:20 slapd-collations.conf
> try /usr/lib64/dirsrv/slapd-instance/start-slapd -d 1

Here's the ending of the errors log file, and attached is the whole thing:

[16/Sep/2010:07:49:51 -0500] - => send_ldap_search_entry
(cn=encryption,cn=config)

[16/Sep/2010:07:49:51 -0500] - <= send_ldap_search_entry

[16/Sep/2010:07:49:51 -0500] - => send_ldap_result 0::

[16/Sep/2010:07:49:52 -0500] - <= send_ldap_result

[16/Sep/2010:07:49:52 -0500] - => slapi_reslimit_get_integer_limit()
conn=0x0, handle=-1

[16/Sep/2010:07:49:52 -0500] - <= slapi_reslimit_get_integer_limit()
returning NO VALUE

[16/Sep/2010:07:49:52 -0500] - => slapi_reslimit_get_integer_limit()
conn=0x0, handle=-1

[16/Sep/2010:07:49:52 -0500] - <= slapi_reslimit_get_integer_limit()
returning NO VALUE

[16/Sep/2010:07:49:52 -0500] - => compute_limits: sizelimit=-1, timelimit=-1

[16/Sep/2010:07:49:52 -0500] - => send_ldap_search_entry
(cn=RSA,cn=encryption,cn=config)

[16/Sep/2010:07:49:52 -0500] - <= send_ldap_search_entry

[16/Sep/2010:07:49:52 -0500] - => send_ldap_result 0::

[16/Sep/2010:07:49:52 -0500] - <= send_ldap_result

[16/Sep/2010:07:49:52 -0500] - => slapi_reslimit_get_integer_limit()
conn=0x0, handle=-1

[16/Sep/2010:07:49:52 -0500] - <= slapi_reslimit_get_integer_limit()
returning NO VALUE

[16/Sep/2010:07:49:52 -0500] - => slapi_reslimit_get_integer_limit()
conn=0x0, handle=-1

[16/Sep/2010:07:49:52 -0500] - <= slapi_reslimit_get_integer_limit()
returning NO VALUE

[16/Sep/2010:07:49:52 -0500] - => compute_limits: sizelimit=-1, timelimit=-1

[16/Sep/2010:07:49:52 -0500] - => send_ldap_search_entry
(cn=RSA,cn=encryption,cn=config)

[16/Sep/2010:07:49:52 -0500] - <= send_ldap_search_entry

[16/Sep/2010:07:49:52 -0500] - => send_ldap_result 0::

[16/Sep/2010:07:49:52 -0500] - <= send_ldap_result

[16/Sep/2010:07:49:52 -0500] - SSL alert: Security Initialization: Unable to
authenticate (Netscape Portable Runtime error -8192 - An I/O error occurred
during security authorization.)
[16/Sep/2010:07:49:53 -0500] - ERROR: SSL Initialization Failed.

[Rich Megginson]

Aaron Hagopian wrote:
> grep nsslapd-localuser /etc/dirsrv/slapd-instance/dse.ldif
>
>
> nsslapd-localuser: nobody
> ls -al /etc/dirsrv/slapd-instance
>
>
> [root@barfolomew slapd-barfolomew]# ls -al /etc/dirsrv/slapd-barfolomew
> total 364
> drwxrwx---. 3 nobody nobody  4096 Sep 16 07:46 .
> drwxrwxr-x. 8 root   nobody  4096 Sep 15 10:20 ..
> -rw-rw----. 1 nobody nobody 65536 Sep 16 07:44 cert8.db
> -r--r-----. 1 nobody nobody  3595 Sep 15 10:20 certmap.conf
> -rw-------. 1 nobody nobody 70422 Sep 16 07:44 dse.ldif
> -rw-------. 1 nobody nobody 70422 Sep 16 07:44 dse.ldif.bak
> -rw-------. 1 nobody nobody 69463 Sep 15 17:32 dse.ldif.startOK
> -r--r-----. 1 nobody nobody 31234 Sep 15 10:20 dse_original.ldif
> -rw-rw----. 1 nobody nobody 16384 Sep 16 07:44 key3.db
> drwxrwx---. 2 nobody nobody  4096 Sep 16 07:46 schema
> -rw-rw----. 1 nobody nobody 16384 Sep 15 10:11 secmod.db
> -r--r-----. 1 nobody nobody  5366 Sep 15 10:20 slapd-collations.conf

There is no pin.txt file in there, and the error message indicates a 
failure to authenticate, which is usually password/pin related.
http://www.redhat.com/docs/manuals/dir-server/8.2/admin/html/Managing_SSL.ht...
> try /usr/lib64/dirsrv/slapd-instance/start-slapd -d 1
>
>
> Here's the ending of the errors log file, and attached is the whole thing:
>
> [16/Sep/2010:07:49:51 -0500] - => send_ldap_search_entry 
> (cn=encryption,cn=config)
>
> [16/Sep/2010:07:49:51 -0500] - <= send_ldap_search_entry
>
> [16/Sep/2010:07:49:51 -0500] - => send_ldap_result 0::
>
> [16/Sep/2010:07:49:52 -0500] - <= send_ldap_result
>
> [16/Sep/2010:07:49:52 -0500] - => slapi_reslimit_get_integer_limit() 
> conn=0x0, handle=-1
>
> [16/Sep/2010:07:49:52 -0500] - <= slapi_reslimit_get_integer_limit() 
> returning NO VALUE
>
> [16/Sep/2010:07:49:52 -0500] - => slapi_reslimit_get_integer_limit() 
> conn=0x0, handle=-1
>
> [16/Sep/2010:07:49:52 -0500] - <= slapi_reslimit_get_integer_limit() 
> returning NO VALUE
>
> [16/Sep/2010:07:49:52 -0500] - => compute_limits: sizelimit=-1, 
> timelimit=-1
>
> [16/Sep/2010:07:49:52 -0500] - => send_ldap_search_entry 
> (cn=RSA,cn=encryption,cn=config)
>
> [16/Sep/2010:07:49:52 -0500] - <= send_ldap_search_entry
>
> [16/Sep/2010:07:49:52 -0500] - => send_ldap_result 0::
>
> [16/Sep/2010:07:49:52 -0500] - <= send_ldap_result
>
> [16/Sep/2010:07:49:52 -0500] - => slapi_reslimit_get_integer_limit() 
> conn=0x0, handle=-1
>
> [16/Sep/2010:07:49:52 -0500] - <= slapi_reslimit_get_integer_limit() 
> returning NO VALUE
>
> [16/Sep/2010:07:49:52 -0500] - => slapi_reslimit_get_integer_limit() 
> conn=0x0, handle=-1
>
> [16/Sep/2010:07:49:52 -0500] - <= slapi_reslimit_get_integer_limit() 
> returning NO VALUE
>
> [16/Sep/2010:07:49:52 -0500] - => compute_limits: sizelimit=-1, 
> timelimit=-1
>
> [16/Sep/2010:07:49:52 -0500] - => send_ldap_search_entry 
> (cn=RSA,cn=encryption,cn=config)
>
> [16/Sep/2010:07:49:52 -0500] - <= send_ldap_search_entry
>
> [16/Sep/2010:07:49:52 -0500] - => send_ldap_result 0::
>
> [16/Sep/2010:07:49:52 -0500] - <= send_ldap_result
>
> [16/Sep/2010:07:49:52 -0500] - SSL alert: Security Initialization: 
> Unable to authenticate (Netscape Portable Runtime error -8192 - An I/O 
> error occurred during security authorization.)
> [16/Sep/2010:07:49:53 -0500] - ERROR: SSL Initialization Failed.
>
> --
> 389 users mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/389-users

[Aaron Hagopian]

Been using passwordless cert the whole time.  This worked fine until I
upgraded to 1.2.6 final.

On Thu, Sep 16, 2010 at 1:14 PM, Rich Megginson  wrote:
> Aaron Hagopian wrote:
> > grep nsslapd-localuser /etc/dirsrv/slapd-instance/dse.ldif
> >
> >
> > nsslapd-localuser: nobody
> > ls -al /etc/dirsrv/slapd-instance
> >
> >
> > [root@barfolomew slapd-barfolomew]# ls -al /etc/dirsrv/slapd-barfolomew
> > total 364
> > drwxrwx---. 3 nobody nobody  4096 Sep 16 07:46 .
> > drwxrwxr-x. 8 root   nobody  4096 Sep 15 10:20 ..
> > -rw-rw----. 1 nobody nobody 65536 Sep 16 07:44 cert8.db
> > -r--r-----. 1 nobody nobody  3595 Sep 15 10:20 certmap.conf
> > -rw-------. 1 nobody nobody 70422 Sep 16 07:44 dse.ldif
> > -rw-------. 1 nobody nobody 70422 Sep 16 07:44 dse.ldif.bak
> > -rw-------. 1 nobody nobody 69463 Sep 15 17:32 dse.ldif.startOK
> > -r--r-----. 1 nobody nobody 31234 Sep 15 10:20 dse_original.ldif
> > -rw-rw----. 1 nobody nobody 16384 Sep 16 07:44 key3.db
> > drwxrwx---. 2 nobody nobody  4096 Sep 16 07:46 schema
> > -rw-rw----. 1 nobody nobody 16384 Sep 15 10:11 secmod.db
> > -r--r-----. 1 nobody nobody  5366 Sep 15 10:20 slapd-collations.conf
>
> There is no pin.txt file in there, and the error message indicates a
> failure to authenticate, which is usually password/pin related.
>
> http://www.redhat.com/docs/manuals/dir-server/8.2/admin/html/Managing_SSL.ht...
> > try /usr/lib64/dirsrv/slapd-instance/start-slapd -d 1
> >
> >
> > Here's the ending of the errors log file, and attached is the whole
>
> thing:
> > [16/Sep/2010:07:49:51 -0500] - => send_ldap_search_entry
> > (cn=encryption,cn=config)
> >
> > [16/Sep/2010:07:49:51 -0500] - <= send_ldap_search_entry
> >
> > [16/Sep/2010:07:49:51 -0500] - => send_ldap_result 0::
> >
> > [16/Sep/2010:07:49:52 -0500] - <= send_ldap_result
> >
> > [16/Sep/2010:07:49:52 -0500] - => slapi_reslimit_get_integer_limit()
> > conn=0x0, handle=-1
> >
> > [16/Sep/2010:07:49:52 -0500] - <= slapi_reslimit_get_integer_limit()
> > returning NO VALUE
> >
> > [16/Sep/2010:07:49:52 -0500] - => slapi_reslimit_get_integer_limit()
> > conn=0x0, handle=-1
> >
> > [16/Sep/2010:07:49:52 -0500] - <= slapi_reslimit_get_integer_limit()
> > returning NO VALUE
> >
> > [16/Sep/2010:07:49:52 -0500] - => compute_limits: sizelimit=-1,
> > timelimit=-1
> >
> > [16/Sep/2010:07:49:52 -0500] - => send_ldap_search_entry
> > (cn=RSA,cn=encryption,cn=config)
> >
> > [16/Sep/2010:07:49:52 -0500] - <= send_ldap_search_entry
> >
> > [16/Sep/2010:07:49:52 -0500] - => send_ldap_result 0::
> >
> > [16/Sep/2010:07:49:52 -0500] - <= send_ldap_result
> >
> > [16/Sep/2010:07:49:52 -0500] - => slapi_reslimit_get_integer_limit()
> > conn=0x0, handle=-1
> >
> > [16/Sep/2010:07:49:52 -0500] - <= slapi_reslimit_get_integer_limit()
> > returning NO VALUE
> >
> > [16/Sep/2010:07:49:52 -0500] - => slapi_reslimit_get_integer_limit()
> > conn=0x0, handle=-1
> >
> > [16/Sep/2010:07:49:52 -0500] - <= slapi_reslimit_get_integer_limit()
> > returning NO VALUE
> >
> > [16/Sep/2010:07:49:52 -0500] - => compute_limits: sizelimit=-1,
> > timelimit=-1
> >
> > [16/Sep/2010:07:49:52 -0500] - => send_ldap_search_entry
> > (cn=RSA,cn=encryption,cn=config)
> >
> > [16/Sep/2010:07:49:52 -0500] - <= send_ldap_search_entry
> >
> > [16/Sep/2010:07:49:52 -0500] - => send_ldap_result 0::
> >
> > [16/Sep/2010:07:49:52 -0500] - <= send_ldap_result
> >
> > [16/Sep/2010:07:49:52 -0500] - SSL alert: Security Initialization:
> > Unable to authenticate (Netscape Portable Runtime error -8192 - An I/O
> > error occurred during security authorization.)
> > [16/Sep/2010:07:49:53 -0500] - ERROR: SSL Initialization Failed.
> >
> > --
> > 389 users mailing list
> > [e-mail]
> > https://admin.fedoraproject.org/mailman/listinfo/389-users
>
> --
> 389 users mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/389-users

[Rich Megginson]

Aaron Hagopian wrote:
> Been using passwordless cert the whole time.  This worked fine until I 
> upgraded to 1.2.6 final.

I suppose it is possible that something happened during the upgrade to 
reset the password.  Try using the modutil command - see modutil -H for 
details - modutil -dbdir /etc/dirsrv/slapd-barfolomew -changepw "NSS 
Certificate DB"
> On Thu, Sep 16, 2010 at 1:14 PM, Rich Megginson <[e-mail] 
> > wrote:
> Aaron Hagopian wrote:
> >
> >
> >     grep nsslapd-localuser /etc/dirsrv/slapd-instance/dse.ldif
> >
> >
> > nsslapd-localuser: nobody
> >
> >     ls -al /etc/dirsrv/slapd-instance
> >
> >
> > [root@barfolomew slapd-barfolomew]# ls -al
> /etc/dirsrv/slapd-barfolomew
> > total 364
> > drwxrwx---. 3 nobody nobody  4096 Sep 16 07:46 .
> > drwxrwxr-x. 8 root   nobody  4096 Sep 15 10:20 ..
> > -rw-rw----. 1 nobody nobody 65536 Sep 16 07:44 cert8.db
> > -r--r-----. 1 nobody nobody  3595 Sep 15 10:20 certmap.conf
> > -rw-------. 1 nobody nobody 70422 Sep 16 07:44 dse.ldif
> > -rw-------. 1 nobody nobody 70422 Sep 16 07:44 dse.ldif.bak
> > -rw-------. 1 nobody nobody 69463 Sep 15 17:32 dse.ldif.startOK
> > -r--r-----. 1 nobody nobody 31234 Sep 15 10:20 dse_original.ldif
> > -rw-rw----. 1 nobody nobody 16384 Sep 16 07:44 key3.db
> > drwxrwx---. 2 nobody nobody  4096 Sep 16 07:46 schema
> > -rw-rw----. 1 nobody nobody 16384 Sep 15 10:11 secmod.db
> > -r--r-----. 1 nobody nobody  5366 Sep 15 10:20 slapd-collations.conf
> There is no pin.txt file in there, and the error message indicates a
> failure to authenticate, which is usually password/pin related.
> http://www.redhat.com/docs/manuals/dir-server/8.2/admin/html/Managing_SSL.html#Starting_the_Server_with_SSL_Enabled-Creating_a_Password_File
> >
> >
> >
> >     try /usr/lib64/dirsrv/slapd-instance/start-slapd -d 1
> >
> >
> > Here's the ending of the errors log file, and attached is the
> whole thing:
> >
> > [16/Sep/2010:07:49:51 -0500] - => send_ldap_search_entry
> > (cn=encryption,cn=config)
> >
> > [16/Sep/2010:07:49:51 -0500] - <= send_ldap_search_entry
> >
> > [16/Sep/2010:07:49:51 -0500] - => send_ldap_result 0::
> >
> > [16/Sep/2010:07:49:52 -0500] - <= send_ldap_result
> >
> > [16/Sep/2010:07:49:52 -0500] - => slapi_reslimit_get_integer_limit()
> > conn=0x0, handle=-1
> >
> > [16/Sep/2010:07:49:52 -0500] - <= slapi_reslimit_get_integer_limit()
> > returning NO VALUE
> >
> > [16/Sep/2010:07:49:52 -0500] - => slapi_reslimit_get_integer_limit()
> > conn=0x0, handle=-1
> >
> > [16/Sep/2010:07:49:52 -0500] - <= slapi_reslimit_get_integer_limit()
> > returning NO VALUE
> >
> > [16/Sep/2010:07:49:52 -0500] - => compute_limits: sizelimit=-1,
> > timelimit=-1
> >
> > [16/Sep/2010:07:49:52 -0500] - => send_ldap_search_entry
> > (cn=RSA,cn=encryption,cn=config)
> >
> > [16/Sep/2010:07:49:52 -0500] - <= send_ldap_search_entry
> >
> > [16/Sep/2010:07:49:52 -0500] - => send_ldap_result 0::
> >
> > [16/Sep/2010:07:49:52 -0500] - <= send_ldap_result
> >
> > [16/Sep/2010:07:49:52 -0500] - => slapi_reslimit_get_integer_limit()
> > conn=0x0, handle=-1
> >
> > [16/Sep/2010:07:49:52 -0500] - <= slapi_reslimit_get_integer_limit()
> > returning NO VALUE
> >
> > [16/Sep/2010:07:49:52 -0500] - => slapi_reslimit_get_integer_limit()
> > conn=0x0, handle=-1
> >
> > [16/Sep/2010:07:49:52 -0500] - <= slapi_reslimit_get_integer_limit()
> > returning NO VALUE
> >
> > [16/Sep/2010:07:49:52 -0500] - => compute_limits: sizelimit=-1,
> > timelimit=-1
> >
> > [16/Sep/2010:07:49:52 -0500] - => send_ldap_search_entry
> > (cn=RSA,cn=encryption,cn=config)
> >
> > [16/Sep/2010:07:49:52 -0500] - <= send_ldap_search_entry
> >
> > [16/Sep/2010:07:49:52 -0500] - => send_ldap_result 0::
> >
> > [16/Sep/2010:07:49:52 -0500] - <= send_ldap_result
> >
> > [16/Sep/2010:07:49:52 -0500] - SSL alert: Security Initialization:
> > Unable to authenticate (Netscape Portable Runtime error -8192 -
> An I/O
> > error occurred during security authorization.)
> > [16/Sep/2010:07:49:53 -0500] - ERROR: SSL Initialization Failed.
> >
> >
> >
> ------------------------------------------------------------------------
> >
> > --
> > 389 users mailing list
> > [e-mail]
> <mailto:[e-mail]>
> > https://admin.fedoraproject.org/mailman/listinfo/389-users
>
> --
> 389 users mailing list
> [e-mail]
> <mailto:[e-mail]>
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
> --
> 389 users mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/389-users