[Fedora-directory-users] Install fails to create domain after re-install

[Steve Jacobson]

Hi Rich,

Thanks for the help.  I've run setup-ds-admin.pl with the -ddd option.  The
compressed log is attached to this.  Short version is, I can't tell from
this what went wrong.  It claims to have successfully created
"dc=kasayka,dc=local" (This is what I meant by 'domain' - the suffix for all
the other entries for our directory).

Trying to add an item to that directory under that suffix yields "No such
object".  Looking with the idm-console shows nothing.  A search of "Users
and Groups" shows no groups or anything else installed in the directory, and
I can't create a user with the console, since there's no Groups for the user
to be part of.  Same with trying to create a Group, or an ou.

As for the 64-bit version of sasl, this is what I've got installed:

# rpm -qa --queryformat '%{name}-%{version}.%{arch}\n' | grep sasl
cyrus-sasl-lib-2.1.22.i386
cyrus-sasl-plain-2.1.22.i386
cyrus-sasl-gssapi-2.1.22.x86_64
cyrus-sasl-plain-2.1.22.x86_64
cyrus-sasl-gssapi-2.1.22.i386
cyrus-sasl-lib-2.1.22.x86_64
cyrus-sasl-md5-2.1.22.i386
cyrus-sasl-2.1.22.x86_64
cyrus-sasl-devel-2.1.22.x86_64
cyrus-sasl-md5-2.1.22.x86_64

Thanks for any futher help or guidance.  I'm thinking of blowing the OS away
at this point, and trying to get back to the point where I was able to
create everything.  I started trying to configure samba to use the
directory, and added a couple of RPMs for samba.  I'm wondering if any of
them could have interfered?  If so, I haven't been able to figure out which
one yet.

Thanks again!

-Steve J.

On 3/6/08 7:59 AM, "Rich Megginson" <rmeggins at redhat.com> wrote:

> Steve Jacobson wrote:
>> All,
>> 
>> I had a successful installation of FDS 1.1 on CentOS 5.1 x86_64. I had
>> a bunch of cruft in the directory from a poor migration, so I decided
>> to start over with a re-install to get things clean. The uninstall was
>> successful, and I wiped /etc/dirsrv, /var/lib/dirsrv, and
>> /usr/share/dirsrv.
> Also /usr/lib64/dirsrv/slapd*
>> Then I re-installed, and ran setup-ds-admin.pl. The dialogs were as
>> expected, and seemed to be just fine. The setup program reported that
>> everything was fine, and the directory was created. However, the
>> domain didn¹t materialize. There was nothing in the setup log to hint
>> at any problem. I found the following messages in /var/log/messages:
>> 
>> 
>> Mar 5 19:20:38 corp-admin-001 ns-slapd: unable to dlopen
>> /usr/lib/sasl2/libcrammd5.so.2: /usr/lib/sasl2/libcrammd5.so.2: wrong
>> ELF class: ELFCLASS32
>> Mar 5 19:20:38 corp-admin-001 ns-slapd: unable to dlopen
>> /usr/lib/sasl2/libanonymous.so.2: /usr/lib/sasl2/libanonymous.so.2:
>> wrong ELF class: ELFCLASS32
>> Mar 5 19:20:38 corp-admin-001 ns-slapd: unable to dlopen
>> /usr/lib/sasl2/libplain.so.2: /usr/lib/sasl2/libplain.so.2: wrong ELF
>> class: ELFCLASS32
>> Mar 5 19:20:38 corp-admin-001 ns-slapd: unable to dlopen
>> /usr/lib/sasl2/libgssapiv2.so.2: /usr/lib/sasl2/libgssapiv2.so.2:
>> wrong ELF class: ELFCLASS32
>> Mar 5 19:20:38 corp-admin-001 ns-slapd: unable to dlopen
>> /usr/lib/sasl2/liblogin.so.2: /usr/lib/sasl2/liblogin.so.2: wrong ELF
>> class: ELFCLASS32
>> Mar 5 19:20:38 corp-admin-001 ns-slapd: unable to dlopen
>> /usr/lib/sasl2/libdigestmd5.so.2: /usr/lib/sasl2/libdigestmd5.so.2:
>> wrong ELF class: ELFCLASS32
>> 
>> So, this implies that ns-slapd is trying to get at the 32 bit
>> libraries instead of the 64 bit versions.
> I'm assuming you have the 64-bit versions of the sasl package installed?
> rpm -qa --queryformat '%{name}-%{version}.%{arch}\n' | grep sasl
>> 
>> I tried setting LD_LIBRARY_PATH to /usr/lib64, I¹ve tried renaming
>> /usr/lib/sasl2 to get it out of the path, hoping the software would
>> just find the right version.
>> 
>> After these two attempts, the setup procedure created without
>> generating any error messages. However, the domain still failed to be
>> created.
> I'm not sure what you mean by "domain" in this context.
> 
> If you can, try starting over from scratch, and running
> setup-ds-admin.pl -ddd to generate verbose debug logs. By default the
> log file is written to /tmp/setupXXXXX.log
>> 
>> Any advice on where to look, or what else to try?
>> 
>> Thanks!
>> 
>> -steve j
>> 
>> 
>> -- 
>> 
>> *
>> **Steve Jacobson* € *Cozi * € IT Manager € m: 206.310.7760 € www.cozi.com
>> ------------------------------------------------------------------------
>> 
>> --
>> Fedora-directory-users mailing list
>> Fedora-directory-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>   
> 
> 
> --
> Fedora-directory-users mailing list
> Fedora-directory-users at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

-- 
   
 
Steve Jacobson  € Cozi  € IT Manager  € m: 206.310.7760  € www.cozi.com 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: setup.err.gz
Type: application/octet-stream
Size: 5422 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20080306/643740aa/attachment.obj>