Fedora directory users - Dec 2005 - Announcing Fedora Directory Server 1.0

We are proud to announce the release of Fedora Directory Server 1.0.

This release marks a significant milestone for the open source 
community, who now have access to the code for the console and 
administration engine as well as the previously open sourced LDAP 
engine. This release uses the Apache httpd engine as its administration 
server, and includes mod_nss - a rewrite of mod_ssl which uses the 
Mozilla NSS crypto engine. The 1.0 release, in addition to its many 
other features such as LDAPv3, Multi-Master Replication, and Windows 
Synchronization, includes support for MD5, SHA-256, SHA-384, and SHA-512 
password hashing, as well as many bug fixes. Fedora Directory Server 1.0 
furthers the evolution and democratization of open source software in 
making this powerful, enterprise proven technology available to all. It 
is a boon for developers who are now able to port the full package - 
LDAP engine, console, and admin engine - to many different platforms.

If you have used the previous version of Fedora Directory Server, we 
invite you to try our new version. If you are using another LDAP server, 
we invite you to try ours and let us know how it compares - we''re
always
looking for ways to improve. Our community is already active and 
growing, and you are welcome and encouraged to join. There are many 
ways: joining the mailing lists, reporting bugs, editing documentation, 
writing scripts/patches/plug-ins, and many more.

Try it out! - http://directory.fedora.redhat.com/wiki/Download
Our home page - http://directory.fedora.redhat.com/
Join our community! - 
http://directory.fedora.redhat.com/wiki/Ways_to_contribute
mod_nss - http://directory.fedora.redhat.com/wiki/Mod_nss
Drop us a line! - fedora-directory-users@redhat.com and 
http://directory.fedora.redhat.com/wiki/Mailing_Lists

Are there any notes available for "upgrading" from 7.1 to 1.0 (my 
feelings about using lower version numbers for newer releases, aside)?

I just did a ''rpm -uvh fedora-ds-1.0-2.RHEL3.i386.opt.rpm
--force'' to
upgrade a test installation and upon trying to start slapd, I get:

# ./start-slapd
[01/Dec/2005:08:59:17 -0500] SSL Initialization - Warning: certificate 
DB file /opt/fedora-ds/alias/slapd-tremolite-cert8.db does not exist - 
SSL initialization will likely fail
[01/Dec/2005:08:59:17 -0500] SSL Initialization - Warning: key DB file 
/opt/fedora-ds/alias/slapd-tremolite-key3.db does not exist - SSL 
initialization will likely fail
[01/Dec/2005:08:59:17 -0500] - SSL alert: Security Initialization: NSS 
initialization failed (Netscape Portable Runtime error -8192 - An I/O 
error occurred during security authorization.): path: 
/opt/fedora-ds/alias/, certdb prefix: slapd-tremolite-, keydb prefix: 
slapd-tremolite-.
[01/Dec/2005:08:59:17 -0500] - ERROR: NSS Initialization Failed.

Both DB files do exist:

# pwd
/opt/fedora-ds/alias
# ls -al slap*
-rw-------    1 root     nobody      65536 Jun  3 17:14 
slapd-tremolite-cert8.db
-rw-------    1 root     nobody      16384 Jun  3 17:14 
slapd-tremolite-key3.db

Do I still need to run the setup script, even if its an upgrade, not a 
fresh install?

Kevin
-- 
Kevin M. Myer
Senior Systems Administrator
Lancaster-Lebanon Intermediate Unit 13  http://www.iu13.org

Kevin M. Myer wrote:
> Are there any notes available for "upgrading" from 7.1 to 1.0 (my
> feelings about using lower version numbers for newer releases, aside)?
>
> I just did a ''rpm -uvh fedora-ds-1.0-2.RHEL3.i386.opt.rpm
--force'' to
> upgrade a test installation and upon trying to start slapd, I get:
>
> # ./start-slapd
> [01/Dec/2005:08:59:17 -0500] SSL Initialization - Warning: certificate 
> DB file /opt/fedora-ds/alias/slapd-tremolite-cert8.db does not exist - 
> SSL initialization will likely fail
> [01/Dec/2005:08:59:17 -0500] SSL Initialization - Warning: key DB file 
> /opt/fedora-ds/alias/slapd-tremolite-key3.db does not exist - SSL 
> initialization will likely fail
> [01/Dec/2005:08:59:17 -0500] - SSL alert: Security Initialization: NSS 
> initialization failed (Netscape Portable Runtime error -8192 - An I/O 
> error occurred during security authorization.): path: 
> /opt/fedora-ds/alias/, certdb prefix: slapd-tremolite-, keydb prefix: 
> slapd-tremolite-.
> [01/Dec/2005:08:59:17 -0500] - ERROR: NSS Initialization Failed.
>
> Both DB files do exist:
>
> # pwd
> /opt/fedora-ds/alias
> # ls -al slap*
> -rw-------    1 root     nobody      65536 Jun  3 17:14 
> slapd-tremolite-cert8.db
> -rw-------    1 root     nobody      16384 Jun  3 17:14 
> slapd-tremolite-key3.db
>
> Do I still need to run the setup script, even if its an upgrade, not a 
> fresh install?
Yes, and that probably won''t work in an upgrade installation situation.
For upgrade, it''s best to backup your data and security db files, and
do
a completely new installation.  You should be able to save your data, 
database configuration, security configuration, replication 
configuration, etc., remove the old software, install the new software, 
and reapply your old data and config.

There was a bug in the server - those files should be owned by
"nobody"
(or whatever your ns-slapd uid is).  We have not tested upgrade install 
- there may be some problems with the console or other admin server 
functions because the admin server is radically different.
>
> Kevin

Quoting Richard Megginson <rmeggins@redhat.com>:
> Yes, and that probably won''t work in an upgrade installation 
> situation.  For upgrade, it''s best to backup your data and
security
> db files, and do a completely new installation.  You should be able 
> to save your data, database configuration, security configuration, 
> replication configuration, etc., remove the old software, install the 
> new software, and reapply your old data and config.
>
> There was a bug in the server - those files should be owned by 
> "nobody" (or whatever your ns-slapd uid is).  We have not tested 
> upgrade install - there may be some problems with the console or 
> other admin server functions because the admin server is radically 
> different.
Well, after spending a little time with it, I think a forced RPM 
upgrade can still be made to work, without doing a complete backup, 
uninstall, and new install.  There are a few caveats, namely that the 
setup script (at least on my forced upgrade test server) failed to 
properly configure the admin server, which meant none of the Apache 
config files were generated.  But I installed a fresh install on my 
workstation, and copied config files, made a few changes to them on my 
test installation and am up and running.

Only issues I''ve seen so far are organizational charts throw an Apache 
server error (undefined symbol: PL_sv_undef at 
/usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229.), 
and from the Java console, my Administration Domain has disappeared.  
Haven''t put a finger on that one yet.

And the speed boost going to Apache is amazing.  I believe I saw a post 
in the dev archives about that (or maybe it was here) but seeing is 
definitely believing :)

Kevin
-- 
Kevin M. Myer
Senior Systems Administrator
Lancaster-Lebanon Intermediate Unit 13  http://www.iu13.org

Kevin M. Myer wrote:
> Quoting Richard Megginson <rmeggins@redhat.com>:
>
>> Yes, and that probably won''t work in an upgrade installation 
>> situation.  For upgrade, it''s best to backup your data and
security
>> db files, and do a completely new installation.  You should be able 
>> to save your data, database configuration, security configuration, 
>> replication configuration, etc., remove the old software, install the 
>> new software, and reapply your old data and config.
>>
>> There was a bug in the server - those files should be owned by 
>> "nobody" (or whatever your ns-slapd uid is).  We have not
tested
>> upgrade install - there may be some problems with the console or 
>> other admin server functions because the admin server is radically 
>> different.
>
>
> Well, after spending a little time with it, I think a forced RPM 
> upgrade can still be made to work, without doing a complete backup, 
> uninstall, and new install.  There are a few caveats, namely that the 
> setup script (at least on my forced upgrade test server) failed to 
> properly configure the admin server, which meant none of the Apache 
> config files were generated.
Right.  That''s my main concern, along with some other file/directory 
configuration that setup does for admin server/console.
> But I installed a fresh install on my workstation, and copied config 
> files, made a few changes to them on my test installation and am up 
> and running.
Ok.
>
> Only issues I''ve seen so far are organizational charts throw an
Apache
> server error (undefined symbol: PL_sv_undef at 
> /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229.),
What OS and version is this?
> and from the Java console, my Administration Domain has disappeared.  
> Haven''t put a finger on that one yet.
I think that has to do with some info under o=netscaperoot that''s using
4.0 or 7.0 or 7.1 or 71 instead of 1.0 or 10 e.g. the jar file names 
should be ds10.jar instead of ds71.jar.
Try a search like this:
ldapsearch -T -b o=netscaperoot -D "cn=directory manager" -w password 
"objectclass=*" | grep 71
or grep 7.1 or grep 4.0
All of those will have to be replaced with 10 or 1.0.
>
> And the speed boost going to Apache is amazing.  I believe I saw a 
> post in the dev archives about that (or maybe it was here) but seeing 
> is definitely believing :)
>
> Kevin

Just tried a test install on FC4/x86_64.  Selected all default answers 
to /opt/fedora-ds/setup/setup.  Here''s what I got:

cat /tmp/fileauZe9w
ERROR: ld.so: object ''/opt/fedora-ds/bin/admin/lib/libssl3.so''
from LD_PRELOAD
cannot be preloaded: ignored.
ERROR: ld.so: object
''/opt/fedora-ds/bin/admin/lib/libldap50.so'' from
LD_PRELOAD cannot be preloaded: ignored.
Syntax error on line 150 of /opt/fedora-ds/admin-serv/config/httpd.conf:
Cannot load /opt/fedora-ds/bin/admin/lib/libmodrestartd.so into 
server: /opt/fedora-ds/bin/admin/lib/libmodrestartd.so: cannot open shared 
object file: No such file or directory

We do not yet have binaries for x86_64.

Neal Becker wrote:
>Just tried a test install on FC4/x86_64.  Selected all default answers 
>to /opt/fedora-ds/setup/setup.  Here''s what I got:
>
>cat /tmp/fileauZe9w
>ERROR: ld.so: object
''/opt/fedora-ds/bin/admin/lib/libssl3.so'' from LD_PRELOAD
>cannot be preloaded: ignored.
>ERROR: ld.so: object
''/opt/fedora-ds/bin/admin/lib/libldap50.so'' from
>LD_PRELOAD cannot be preloaded: ignored.
>Syntax error on line 150 of /opt/fedora-ds/admin-serv/config/httpd.conf:
>Cannot load /opt/fedora-ds/bin/admin/lib/libmodrestartd.so into 
>server: /opt/fedora-ds/bin/admin/lib/libmodrestartd.so: cannot open shared 
>object file: No such file or directory
>
>--
>Fedora-directory-users mailing list
>Fedora-directory-users@redhat.com
>https://www.redhat.com/mailman/listinfo/fedora-directory-users
>  
>

Quoting Richard Megginson <rmeggins@redhat.com>:
>>
>> Only issues I''ve seen so far are organizational charts throw
an
>> Apache server error (undefined symbol: PL_sv_undef at 
>> /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 
>> 229.),
>
> What OS and version is this?
That error is with RHEL 3, update 5, with most errata applied.

Slightly different issue with FC4:

Can''t load
''/opt/fedora-ds/lib/perl/arch/auto/Mozilla/LDAP/API/API.so''
for module Mozilla::LDAP::API: libldap50.so: cannot open shared object 
file: No such file or directory at 
/usr/lib/perl5/5.8.6/i386-linux-thread-multi/DynaLoader.pm line 230.
>
>> and from the Java console, my Administration Domain has disappeared. 
>>  Haven''t put a finger on that one yet.
>
> I think that has to do with some info under o=netscaperoot that''s 
> using 4.0 or 7.0 or 7.1 or 71 instead of 1.0 or 10 e.g. the jar file 
> names should be ds10.jar instead of ds71.jar.
> Try a search like this:
> ldapsearch -T -b o=netscaperoot -D "cn=directory manager" -w
password
> "objectclass=*" | grep 71
> or grep 7.1 or grep 4.0
> All of those will have to be replaced with 10 or 1.0.
Aha - I thought it was something like that, but had only changed 
nsProductVersion and nsBuildNumber values.  But I see the admserv70jar 
references now.

Kevin

-- 
Kevin M. Myer
Senior Systems Administrator
Lancaster-Lebanon Intermediate Unit 13  http://www.iu13.org

Kevin M. Myer wrote:
> Quoting Richard Megginson <rmeggins@redhat.com>:
>
>>>
>>> Only issues I''ve seen so far are organizational charts
throw an
>>> Apache server error (undefined symbol: PL_sv_undef at 
>>> /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line
229.),
>>
>>
>> What OS and version is this?
>
>
> That error is with RHEL 3, update 5, with most errata applied.
>
> Slightly different issue with FC4:
>
> Can''t load
''/opt/fedora-ds/lib/perl/arch/auto/Mozilla/LDAP/API/API.so''
> for module Mozilla::LDAP::API: libldap50.so: cannot open shared object 
> file: No such file or directory at 
> /usr/lib/perl5/5.8.6/i386-linux-thread-multi/DynaLoader.pm line 230.
Ah, because it probably didn''t replace the old orgchart .pl scripts and
config with the new ones.
>
>>
>>> and from the Java console, my Administration Domain has
disappeared.
>>>  Haven''t put a finger on that one yet.
>>
>>
>> I think that has to do with some info under o=netscaperoot
that''s
>> using 4.0 or 7.0 or 7.1 or 71 instead of 1.0 or 10 e.g. the jar file 
>> names should be ds10.jar instead of ds71.jar.
>> Try a search like this:
>> ldapsearch -T -b o=netscaperoot -D "cn=directory manager" -w
password
>> "objectclass=*" | grep 71
>> or grep 7.1 or grep 4.0
>> All of those will have to be replaced with 10 or 1.0.
>
>
> Aha - I thought it was something like that, but had only changed 
> nsProductVersion and nsBuildNumber values.  But I see the admserv70jar 
> references now.
>
> Kevin
>

Quoting Richard Megginson <rmeggins@redhat.com>:
> Kevin M. Myer wrote:
>
>> Quoting Richard Megginson <rmeggins@redhat.com>:
>>
>>>>
>>>> Only issues I''ve seen so far are organizational charts
throw an
>>>> Apache server error (undefined symbol: PL_sv_undef at 
>>>> /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line
>>>> 229.),
>>>
>>>
>>> What OS and version is this?
>>
>>
>> That error is with RHEL 3, update 5, with most errata applied.
>>
>> Slightly different issue with FC4:
>>
>> Can''t load 
>>
''/opt/fedora-ds/lib/perl/arch/auto/Mozilla/LDAP/API/API.so''
for
>> module Mozilla::LDAP::API: libldap50.so: cannot open shared object 
>> file: No such file or directory at 
>> /usr/lib/perl5/5.8.6/i386-linux-thread-multi/DynaLoader.pm line 230.
>
> Ah, because it probably didn''t replace the old orgchart .pl
scripts
> and config with the new ones.
I should have been more specific.  The EL 3 undefined symbol was the 
forced upgrade.  The FC 4 install is my workstation, which was a brand 
new install.  I resolved the FC 4 issue by adding 
/opt/fedora-ds/shared/lib to my /etc/ld.so.conf (which I had 
incidentally already done on my test installation, but forgotten about).

So its just the undefined symbol: PL_sv_undef with RHEL 3 that I''m 
currently seeing.  If you think this is of more interest to developers 
only, I can take the conversation there, off the users list.

Kevin
-- 
Kevin M. Myer
Senior Systems Administrator
Lancaster-Lebanon Intermediate Unit 13  http://www.iu13.org

Kevin M. Myer wrote:
> Quoting Richard Megginson <rmeggins@redhat.com>:
>
>> Kevin M. Myer wrote:
>>
>>> Quoting Richard Megginson <rmeggins@redhat.com>:
>>>
>>>>>
>>>>> Only issues I''ve seen so far are organizational
charts throw an
>>>>> Apache server error (undefined symbol: PL_sv_undef at 
>>>>> /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm
line
>>>>> 229.),
>>>>
>>>>
>>>>
>>>> What OS and version is this?
>>>
>>>
>>>
>>> That error is with RHEL 3, update 5, with most errata applied.
>>>
>>> Slightly different issue with FC4:
>>>
>>> Can''t load 
>>>
''/opt/fedora-ds/lib/perl/arch/auto/Mozilla/LDAP/API/API.so''
for
>>> module Mozilla::LDAP::API: libldap50.so: cannot open shared object 
>>> file: No such file or directory at 
>>> /usr/lib/perl5/5.8.6/i386-linux-thread-multi/DynaLoader.pm line
230.
>>
>>
>> Ah, because it probably didn''t replace the old orgchart .pl
scripts
>> and config with the new ones.
>
>
> I should have been more specific.  The EL 3 undefined symbol was the 
> forced upgrade.
Take a look at clients/orgchart/bin/org - does it have the bit about 
setting the LD_LIBRARY_PATH?
> The FC 4 install is my workstation, which was a brand new install.  I 
> resolved the FC 4 issue by adding /opt/fedora-ds/shared/lib to my 
> /etc/ld.so.conf (which I had incidentally already done on my test 
> installation, but forgotten about).
That shouldn''t be necessary.  See clients/orgchart/bin/org for more
details.
>
> So its just the undefined symbol: PL_sv_undef with RHEL 3 that I''m
> currently seeing.  If you think this is of more interest to developers 
> only, I can take the conversation there, off the users list.
>
> Kevin