Problem browsing LDAP with Outlook
by Chris Bryant
When configuring Microsoft Outlook (not Outlook Express) to access an LDAP directory, there is an option to 'Enable Browsing (requires server support)'. If this option is chosen and the directory server supports it, then you should be able to open the LDAP address book and page up and down through the results. I have been unable to get this working properly with 389 DS.
When I try to browse from Outlook against the 389 DS directory, I am able to see the first page of results perfectly. However, if I move to the next page, only the first object returned will have any attributes included, and all of the rest of the objects in the page will have no attributes. I have a test perl script that duplicates this functionality as well.
I can get this to work properly with an older version of Netscape Directory Server, and I can get it working with OpenDS. Since 389 DS advertises support for the controls that are required for this to work, just like the other two servers, then I would expect it to work there also.
Has anyone out there gotten this to work with 389 DS? If so, can you share if there was anything special that you needed to do to get this to work? I'm trying to determine if this is a bug in the server, or if I'm just missing something in the configuration.
Thanks,
Chris
USA.NET
You Run Your Business. We'll Run Your Email.
This message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information of USA.NET, Inc. Any unauthorized review, use, copying, disclosure, or distribution is prohibited. If you are not the intended recipient, please immediately contact the sender by reply email and delete all copies of the original message.
3 years, 3 months
changelog
by Denise Cosso
Hi,
How to modify the attribute nsslapd-encryptionalgorithm in Centos?
Thanks,
Denise
Stop Master servers and set nsslapd-encryptionalgorithm. The allowed value is AES or 3DES.
dn: cn=changelog5,cn=config
[...]
nsslapd-encryptionalgorithm: AES
--- Em ter, 4/6/13, Rich Megginson <rmeggins(a)redhat.com> escreveu:
De: Rich Megginson <rmeggins(a)redhat.com>
Assunto: Re: [389-users] changelog
Para: "Denise Cosso" <guanaes51(a)yahoo.com.br>
Data: Terça-feira, 4 de Junho de 2013, 16:34
On 06/04/2013 01:26 PM, Denise Cosso
wrote:
Hi, Rich
CentOS release 6.3 (Final)
389-ds-base-libs-1.2.10.2-20.el6_3.x86_64
389-ds-1.2.2-1.el6.noarch
389-dsgw-1.1.10-1.el6.x86_64
389-ds-console-1.2.6-1.el6.noarch
389-ds-console-doc-1.2.6-1.el6.noarch
389-ds-base-1.2.10.2-20.el6_3.x86_64
As far as replication goes - you will need to use a security layer
(SSL, TLS, or GSSAPI) to protect the clear text password on the wire
As far as encrypting it in the changelog - not sure
Denise
--- Em ter, 4/6/13, Rich Megginson <rmeggins(a)redhat.com>
escreveu:
De: Rich Megginson <rmeggins(a)redhat.com>
Assunto: Re: [389-users] changelog
Para: "General discussion list for the 389 Directory
server project."
<389-users(a)lists.fedoraproject.org>
Cc: "Denise Cosso" <guanaes51(a)yahoo.com.br>
Data: Terça-feira, 4 de Junho de 2013, 16:11
On
06/04/2013 12:39 PM, Denise Cosso wrote:
Hi,
Description of problem:
When a userPassword is changed in a server with changelog, the hashed password
is logged and also a cleartext pseudo-attribute version. It looks like this:
change::
replace: userPassword
userPassword: {SHA256}vqtiN2LHdrEUOJUKu+IBVqAVFsAlvFw+11kD/Q==
-
replace: unhashed#user#password
unhashed#user#password: secret12
This unhashed version is used in winsync where the cleartext version of the
password must be written to the AD.
Now if the DS is involved in replication with another DS, the change will be
replayed exactly as it is logged to the other DS replicas, including the
cleartext pseudo-attribute password.
What platform? What version of 389-ds-base are you
using?
thanks,
Denise
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
8 years, 7 months
389 Master - Master Replication
by Santos Ramirez
Good Morning,
We have a master - master replication agreement. When we initialize the replication it works perfectly we can see changes to a test user we have set up go up and down from the two servers. However at some point the replication stops and we cannot get replication to start once again. The only way we can get replication to start once again is to recreate the replication agreement and then it fails again. Can anyone please point us in a direction. I am relatively new to 389 so any help would be greatly appreciated.
Santos U. Ramirez
Linux Systems Administrator
National DCP, LLC
150 Depot Street
Bellingham, Ma. 02019
Phone: 508-422-3089
Fax: 508-422-3866
Santos.Ramirez(a)natdcp.com<mailto:Santos.Ramirez@natdcp.com>
This email and any attachments are intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, do not copy or forward to any unauthorized persons, permanently delete the original and notify the sender by replying to this email.
9 years, 2 months
Re: [389-users] Password Failure Lockout doesn't seem to work
by JLPicard
Yes, I can, after 8 consecutive failed authentications, the account can
still successfully query the DS with the correct password.
% ldapsearch -x -ZZ -LLL -h "my-ldapHost01.my-domain.com" -b
"dc=my-domain,dc=com" -D
"uid=test-user-account,ou=people,dc=my-domain,dc=com" -w badPword
"cn=test-user-account"
ldap_bind: Invalid credentials (49)
% ldapsearch -x -ZZ -LLL -h "my-ldapHost01.my-domain.com" -b
"dc=my-domain,dc=com" -D
"uid=test-user-account,ou=people,dc=my-domain,dc=com" -w badPword
"cn=test-user-account"
ldap_bind: Invalid credentials (49)
% ldapsearch -x -ZZ -LLL -h "my-ldapHost01.my-domain.com" -b
"dc=my-domain,dc=com" -D
"uid=test-user-account,ou=people,dc=my-domain,dc=com" -w badPword
"cn=test-user-account"
ldap_bind: Invalid credentials (49)
% ldapsearch -x -ZZ -LLL -h "my-ldapHost01.my-domain.com" -b
"dc=my-domain,dc=com" -D
"uid=test-user-account,ou=people,dc=my-domain,dc=com" -w badPword
"cn=test-user-account"
ldap_bind: Invalid credentials (49)
% ldapsearch -x -ZZ -LLL -h "my-ldapHost01.my-domain.com" -b
"dc=my-domain,dc=com" -D
"uid=test-user-account,ou=people,dc=my-domain,dc=com" -w badPword
"cn=test-user-account"
ldap_bind: Invalid credentials (49)
% ldapsearch -x -ZZ -LLL -h "my-ldapHost01.my-domain.com" -b
"dc=my-domain,dc=com" -D
"uid=test-user-account,ou=people,dc=my-domain,dc=com" -w badPword
"cn=test-user-account"
ldap_bind: Invalid credentials (49)
% ldapsearch -x -ZZ -LLL -h "my-ldapHost01.my-domain.com" -b
"dc=my-domain,dc=com" -D
"uid=test-user-account,ou=people,dc=my-domain,dc=com" -w badPword
"cn=test-user-account"
ldap_bind: Invalid credentials (49)
% ldapsearch -x -ZZ -LLL -h "my-ldapHost01.my-domain.com" -b
"dc=my-domain,dc=com" -D
"uid=test-user-account,ou=people,dc=my-domain,dc=com" -w badPword
"cn=test-user-account"
ldap_bind: Invalid credentials (49)
% ldapsearch -x -ZZ -LLL -h "my-ldapHost01.my-domain.com" -b
"dc=my-domain,dc=com" -D
"uid=test-user-account,ou=people,dc=my-domain,dc=com" -w goodPwrd
"cn=test-user-account"
dn: uid=test-user-account,ou=people,dc=my-domain,dc=com
description: accountHasItsOwnPwdPolicy
objectClass: posixAccount
objectClass: shadowAccount
objectClass: account
objectClass: top
uid: test-user-account
cn: test-user-account
uidNumber: 2853
gidNumber: 2600
gecos: LDAP Test
homeDirectory: /home/test-user-account
loginShell: /bin/tcsh
On 11/25/2013 5:49 PM, 389-users-request(a)lists.fedoraproject.org wrote:
> From: Rich Megginson <rmeggins(a)redhat.com> To: "General discussion
> list for the 389 Directory server project."
> <389-users(a)lists.fedoraproject.org> Cc: JLPicard
> <jlpicard15(a)hotmail.com> Subject: Re: [389-users] Password Failure
> Lockout doesn't seem to work Message-ID: <5293D3FC.2090907(a)redhat.com>
> Content-Type: text/plain; charset="utf-8"; Format="flowed" On
> 11/25/2013 03:33 PM, JLPicard wrote:
>> >Hi, I am testing out 389_ds_base, version =1.2.11.15,REV=2013.01.31
>> >running on mixed Solaris 10 servers (SPARC and X86) sourced from
>> >http://www.opencsw.org/packages/CSW389-ds-base
>> >in multi-master mode with 4 servers that is primarily used for
>> >authentication and user/group/netgroup management.
>> >
>> >Most of the Password policy components seem to work as they should,
>> >but password failure account lockout doesn't appear to engage after
>> >X-failed attempts. After creating a new account, testing a successful
>> >login, after 5+ failed logins with bad passwords, I can still login
>> >after I would expect to be locked out. I even created a new password
>> >policy and applied it to this user and it still doesn't lock him out
>> >after 5+ failed logins with bad passwords.
> Can you reproduce the issue with ldapsearch?
>
> ldapsearch ... -D "uid=myuser,...." -w "badpassword" ...
> repeat 5 times
>
>
9 years, 11 months
Upgrade failure
by Gordon Messmer
On Friday, I updated one of several systems that I manage from version
1.2.11.15 to version 1.2.11.25. Thereafter, the service was unable to
start. The error indicates a problem with SSL that I don't understand.
I've included the relevant section from the "error" log below.
After reverting to the old package, the service starts again.
Does anyone understand this error and have a pointer on resolving it?
yum.log:
Sep 20 15:35:43 Updated: 389-ds-base-libs-1.2.11.15-22.el6_4.x86_64
Sep 20 15:36:24 Updated: 389-ds-base-1.2.11.15-22.el6_4.x86_64
Nov 22 15:03:40 Updated: 389-ds-base-libs-1.2.11.25-1.el6.x86_64
Nov 22 15:05:17 Updated: 389-ds-base-1.2.11.25-1.el6.x86_64
error:
[22/Nov/2013:15:05:08 -0800] - check_and_set_import_cache: pagesize:
4096, pages: 980670, procpages: 52580
[22/Nov/2013:15:05:08 -0800] - Import allocates 1569072KB import cache.
[22/Nov/2013:15:05:08 -0800] Upgrade DN Format - userRoot: Start upgrade
dn format.
[22/Nov/2013:15:05:08 -0800] Upgrade DN Format - Instance userRoot in
/var/lib/dirsrv/slapd-master1/db/userRoot is up-to-date
[22/Nov/2013:15:05:14 -0800] - 389-Directory/1.2.11.25 B2013.325.1951
starting up
[22/Nov/2013:15:05:15 -0800] slapd_get_unlocked_key_for_cert - Error:
could not find any unlocked slots for certificate
[E=postmaster(a)xxx.com,CN=mail.xxx.com,O=xxx,
L=Seattle,ST=Washington,C=US,OID.2.5.4.13=5t6jP8FugTLuYrW8]. Please
review your TLS/SSL configuration. The following slots were found:
[22/Nov/2013:15:05:15 -0800] slapd_get_unlocked_key_for_cert - Slot [NSS
User Private Key and Certificate Services] token [Internal (Software)
Token] was locked.
[22/Nov/2013:15:05:15 -0800] - Can't get private key from cert
Server-Cert in attrcrypt_fetch_private_key: -8049 - Unrecognized Object
IDentifier.
[22/Nov/2013:15:05:15 -0800] - Error: unable to initialize attrcrypt
system for userRoot
[22/Nov/2013:15:05:16 -0800] - start: Failed to start databases, err=-1
Unknown error: -1
[22/Nov/2013:15:05:16 -0800] - Failed to start database plugin ldbm database
[22/Nov/2013:15:05:16 -0800] - WARNING: ldbm instance userRoot already
exists
[22/Nov/2013:15:05:16 -0800] - ldbm_config_read_instance_entries: failed
to add instance entry cn=userRoot,cn=ldbm database,cn=plugins,cn=config
[22/Nov/2013:15:05:16 -0800] - ldbm_config_load_dse_info: failed to read
instance entries
[22/Nov/2013:15:05:16 -0800] - start: Loading database configuration failed
[22/Nov/2013:15:05:16 -0800] - Failed to start database plugin ldbm database
[22/Nov/2013:15:05:16 -0800] - Error: Failed to resolve plugin dependencies
[22/Nov/2013:15:05:16 -0800] - Error: preoperation plugin 7-bit check is
not started
[22/Nov/2013:15:05:16 -0800] - Error: preoperation plugin Account
Usability Plugin is not started
[22/Nov/2013:15:05:16 -0800] - Error: accesscontrol plugin ACL Plugin is
not started
[22/Nov/2013:15:05:16 -0800] - Error: preoperation plugin ACL
preoperation is not started
[22/Nov/2013:15:05:16 -0800] - Error: preoperation plugin Auto
Membership Plugin is not started
[22/Nov/2013:15:05:16 -0800] - Error: object plugin Class of Service is
not started
[22/Nov/2013:15:05:16 -0800] - Error: preoperation plugin deref is not
started
[22/Nov/2013:15:05:16 -0800] - Error: preoperation plugin HTTP Client is
not started
[22/Nov/2013:15:05:16 -0800] - Error: database plugin ldbm database is
not started
[22/Nov/2013:15:05:16 -0800] - Error: object plugin Legacy Replication
Plugin is not started
[22/Nov/2013:15:05:16 -0800] - Error: preoperation plugin Linked
Attributes is not started
[22/Nov/2013:15:05:16 -0800] - Error: preoperation plugin Managed
Entries is not started
[22/Nov/2013:15:05:16 -0800] - Error: object plugin Multimaster
Replication Plugin is not started
[22/Nov/2013:15:05:16 -0800] - Error: preoperation plugin Pass Through
Authentication is not started
[22/Nov/2013:15:05:16 -0800] - Error: object plugin Roles Plugin is not
started
[22/Nov/2013:15:05:16 -0800] - Error: object plugin Views is not started
10 years
Adding new master in the topology
by Todor Petkov
Hello all,
currently I have 2 servers, based on Centos6. They are in master/master
mode and everything is working flawlessly.
I would like to extend the topology with a third server. When I did the
current set up, I set the first as ID1, second as ID2, and told the
first to initiate the second.
Can someone give me a hint how to add the third without making a mess
with the users? I am thinking something like this:
set the third with ID=3
Connect ID1 and ID3
Tell ID1 to initiate ID3 (transferring the users/groups to ID3)
Connect ID2 and ID3
Tell ID2 to initiate ID3 (transferring the users/groups to ID3)
What bothers me is the initiation part. Is there any danger in my case
to transfer an empty set of users to an old server? ID1 -> ID3 should
not been a problem, but ID2 -> ID3 may lead to transferring users from
ID1 to ID3.. is this correct?
Thanks in advance,
10 years
Re: [389-users] acl__TestRights - cache overflown
by Vesa Alho
Thanks for the answer. I just set it to 400 and let's see what happens.
At least initially looks better. This would useful information in 389 wiki?
-Vesa
> On 28/11/13 11:17, Ludwig Krispenz wrote:
>> Hi,
>>
>> the message is not related to the dbcache, it is about cached aci
>> evaluations and there is a default value of 200. You can increase this
>> by setting the attribute nsslapd-aclpb-max-selected-acls in cn=ACL
>> Plugin,cn=plugins,cn=config and restart the server. There is also a
>> ticket for this: https://fedorahosted.org/389/ticket/342
>> but the fix only fixes one of two occurrencies of the error message and
>> I 'm not sure if it is in your version.
>>
>> Regards,
>> Ludwig
>>
>> On 11/28/2013 08:48 AM, Vesa Alho wrote:
>>>> 1. I changed values using Console. But for the second LDAP server I was
>>>> not able to save new nsslapd-dbcachesize value, because Save button was
>>>> greyed out. I changed value using ldapmodify. But is there a reason why
>>>> Save button is disabled?
>>>
>>> I figured out that Save button is greyed out if value is incorrect
>>> (e.g. too big). So it works as it should.
>>>
>>> Anyways, I still get "acl__TestRights - cache overflow" error from my
>>> second LDAP server which is more heavily loaded. It puzzles me because
>>> I only have like less than 10 ACIs in root suffix or in OU levels.
>>>
>>> I found only a few references by googling. Like this old bug report:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=918702
>>> But I couldn't find nsslapd-aclpb-max-selected-acls attribute. Do I
>>> need to add it and what is default value?
>>>
>>> Here are my versions (latest EPEL 6 stable):
>>>
>>> 389-console-1.1.7-1.el6.noarch
>>> 389-admin-console-1.1.8-1.el6.noarch
>>> 389-admin-console-doc-1.1.8-1.el6.noarch
>>> 389-ds-base-libs-1.2.11.25-1.el6.x86_64
>>> 389-ds-console-doc-1.2.6-1.el6.noarch
>>> 389-ds-base-1.2.11.25-1.el6.x86_64
>>> 389-ds-console-1.2.6-1.el6.noarch
>>> 389-ds-1.2.2-1.el6.noarch
>>> 389-dsgw-1.1.10-1.el6.x86_64
>>> 389-adminutil-1.1.15-1.el6.x86_64
>>> 389-admin-1.1.29-1.el6.x86_64
>>>
>>> This issue appeared when I upgraded 389 packages via normal yum
>>> updates from 1.2.11.15.
>>>
>>> -Vesa
>>> --
>>> 389 users mailing list
>>> 389-users(a)lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>
>> --
>> 389 users mailing list
>> 389-users(a)lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
10 years
acl__TestRights - cache overflown
by Vesa Alho
Hi,
I noticed a warning from error logs that userRoot cache settings were
too small compared to db size.
I tuned cache values based on this article:
https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Serv...
Based on log report, I used following values:
Entry cache:
nsslapd-cachememsize: 268435456 (256MB)
DB cache:
nsslapd-dbcachesize: 268435456 (256MB)
After this, my second LDAP server gives the following errors:
acl__TestRights - cache overflown
Some of the queries fails. For example some of the sudoers entries don't
work.
Questions:
1. I changed values using Console. But for the second LDAP server I was
not able to save new nsslapd-dbcachesize value, because Save button was
greyed out. I changed value using ldapmodify. But is there a reason why
Save button is disabled?
2. Do my values make sense in general? Default values were only 10MB and
wondering why is that?
I have currently 2GB RAM for directory servers and DBs are relatively
small. Log reports userRoot size as 180MB. RAM usage is fine, plenty of
free memory.
-Vesa
10 years
Re: [389-users] setup-ds-admin.pl errors
by Alberto Viana
Rich,
Any clues?
On Thu, Nov 21, 2013 at 3:19 PM, Alberto Viana <albertocrj(a)gmail.com> wrote:
> $ ./configure --with-openldap
>
> I did not specify any CFLAGS.
>
>
>
>
> On Thu, Nov 21, 2013 at 3:09 PM, Rich Megginson <rmeggins(a)redhat.com>wrote:
>
>> On 11/21/2013 09:55 AM, Alberto Viana wrote:
>>
>> Rich,
>>
>> Yes. If you need any specific info about how I built please let me know.
>>
>> yes, your configure and cflags, please.
>>
>>
>> Thanks.
>>
>>
>> On Thu, Nov 21, 2013 at 2:51 PM, Rich Megginson <rmeggins(a)redhat.com>wrote:
>>
>>> On 11/21/2013 09:43 AM, Alberto Viana wrote:
>>>
>>> Rich,
>>>
>>> I'm still getting some errors:
>>>
>>> Could not import LDIF file '/tmp/ldifTVzppg.ldif'. Error: 256.
>>> Output: importing data ...
>>> [21/Nov/2013:14:42:11 -0200] - Netscape Portable Runtime error -5977:
>>> /opt/dirsrv/lib/dirsrv/plugins/libretrocl-plugin.so: undefined symbol:
>>> retrocl_cn_lock
>>> [21/Nov/2013:14:42:11 -0200] - Could not open library
>>> "/opt/dirsrv/lib/dirsrv/plugins/libretrocl-plugin.so" for plugin Retro
>>> Changelog Plugin
>>> [21/Nov/2013:14:42:11 -0200] - Unable to load plugin "cn=Retro Changelog
>>> Plugin,cn=plugins,cn=config"
>>>
>>> Error: Could not create directory server instance 'RNP'.
>>> Exiting . . .
>>> Log file is '/tmp/setupbogCkT.log'
>>>
>>> Any Clues?
>>>
>>>
>>> You built this yourself from the 1.3.2.4 source tarball?
>>>
>>>
>>>
>>> Thanks
>>>
>>>
>>> On Thu, Nov 21, 2013 at 1:51 PM, Alberto Viana <albertocrj(a)gmail.com>wrote:
>>>
>>>> Yes, you're right, once ubuntu is based on debian and always link
>>>> /bin/sh to dash.
>>>>
>>>> Thanks.
>>>>
>>>>
>>>> On Thu, Nov 21, 2013 at 1:48 PM, Rich Megginson <rmeggins(a)redhat.com>wrote:
>>>>
>>>>> On 11/21/2013 08:44 AM, Alberto Viana wrote:
>>>>>
>>>>> You are right, /bin/sh was linked to "dash" shell.
>>>>>
>>>>> I linked to /bin/bash and everything is working as expected.
>>>>>
>>>>> Thanks so much for your help.
>>>>>
>>>>>
>>>>> I think you ran into this issue:
>>>>> https://fedorahosted.org/389/ticket/47511
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Nov 21, 2013 at 1:35 PM, Rich Megginson <rmeggins(a)redhat.com>wrote:
>>>>>
>>>>>> On 11/21/2013 08:28 AM, Alberto Viana wrote:
>>>>>>
>>>>>> Rich,
>>>>>>
>>>>>> oot@hmg3:~# bash --version
>>>>>> GNU bash, version 4.2.24(1)-release (x86_64-pc-linux-gnu)
>>>>>>
>>>>>>
>>>>>> Ok. What about /bin/sh?
>>>>>>
>>>>>> The problem is that the shell script is complaining that it cannot
>>>>>> find the "source" command. I'm not sure why - that is built-in to bash.
>>>>>> Perhaps /bin/sh is in strict posix bourne shell mode, which would require
>>>>>> the "." command? Perhaps /bin/sh is linked to some other shell like zsh?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Nov 21, 2013 at 1:23 PM, Rich Megginson <rmeggins(a)redhat.com>wrote:
>>>>>>
>>>>>>> On 11/21/2013 08:16 AM, Alberto Viana wrote:
>>>>>>>
>>>>>>> Rich,
>>>>>>>
>>>>>>> root@hmg3:~# env
>>>>>>> SHELL=/bin/bash
>>>>>>>
>>>>>>>
>>>>>>> ls -al /bin/sh
>>>>>>> /bin/sh --version
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Nov 21, 2013 at 1:13 PM, Rich Megginson <rmeggins(a)redhat.com
>>>>>>> > wrote:
>>>>>>>
>>>>>>>> On 11/21/2013 08:07 AM, Alberto Viana wrote:
>>>>>>>>
>>>>>>>> I'm trying to set up a new instance of 389 DS in my homologation
>>>>>>>> enviroment:
>>>>>>>>
>>>>>>>> 389-ds-base-1.3.2.4
>>>>>>>> 389-adminutil-1.1.18
>>>>>>>> 389-admin-console-1.1.8
>>>>>>>>
>>>>>>>> After I ran setup-ds-admin.pl, i'm getting the following errors:
>>>>>>>>
>>>>>>>> Are you ready to set up your servers? [yes]:
>>>>>>>> Creating directory server . . .
>>>>>>>> Could not import LDIF file '/tmp/ldif9lEZLw.ldif'. Error: 256.
>>>>>>>> Output: ./ldif2db: 3: ./ldif2db: source: not found
>>>>>>>> ./ldif2db: 5: ./ldif2db: libpath_add: not found
>>>>>>>> ./ldif2db: 6: ./ldif2db: libpath_add: not found
>>>>>>>> ./ldif2db: 7: ./ldif2db: libpath_add: not found
>>>>>>>> ./ldif2db: 8: ./ldif2db: libpath_add: not found
>>>>>>>> ./ldif2db: 84: ./ldif2db: get_init_file: not found
>>>>>>>> ./ldif2db: 85: [: 127: unexpected operator
>>>>>>>> importing data ...
>>>>>>>> usage: ns-slapd ldif2db -D configdir [-d debuglevel] [-n
>>>>>>>> backend_instance_name] [-O] [-g uniqueid_type] [--namespaceid uniqueID][{-s
>>>>>>>> includesuffix}*] [{-x excludesuffix}*] [-E] [-q] {-i ldif-file}*
>>>>>>>> Note: either "-n backend_instance_name" or "-s includesuffix" is
>>>>>>>> required.
>>>>>>>>
>>>>>>>> Error: Could not create directory server instance 'RNP'.
>>>>>>>> Exiting . . .
>>>>>>>> Log file is '/tmp/setupBsGuLZ.log'
>>>>>>>>
>>>>>>>>
>>>>>>>> I also tried "389-ds-base-1.3.1.12". Any clues?
>>>>>>>>
>>>>>>>>
>>>>>>>> What is your login shell?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> 389 users mailing list389-users@lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
10 years
