I am trying to update the index on our userRoot database. I imported the attribute using the ldif2db routine. Error log reports success.
Then I ran the db2index.pl routine with no particular attribute (in essence I guess the whole database is re-indexed) causing the database to grow, fill partition up, and crash.
Tested on another system similar process but this time used the "-t" option with the new attribute. Error log shows success. However, no re-indexing occurred.
When we import through the console, then add the attribute for indexing, the console kicks off a reindex of the database with the new attribute selected.
Version 389-DS: 188.8.131.52
Command used to import attribute:
/usr/lib64/dirsrv/slapd-test/ldif2db -n userRoot -i /var/log/dirsrv/slapd-test/my.ldif; systemctl start dirsrv(a)test.service
Command to index:
/usr//lib64/dirsrv/slapd-test/db2index.pl -D "cn=Directory Manager" -w - -n userRoot (re-indexes all but fills partition and crashes)
/usr//lib64/dirsrv/slapd-test/db2index.pl -D "cn=Directory Manager" -w - -n userRoot -t my_attribute:pres (log reports success but does not re-index like it does on console.)
Any ideas on why through console it indexes the whole database with new attribute, but not from the command line?
Paul M. Whitney
Sent from my browser.
Would someone out there have a good resource/guide for samba set up with 389 DS for dummies? I have been trying for two days to get samba to use LDAP users and passwords for authentication with no success.
Any help someone can give out would be greatly appreciated.
Just detected two entries in my errors log:
_entry_set_tombstone_rdn - Failed to convert DN ou=Policies to RDN with different IDs. The replicants seem to be performing fine, access logs show activity, but wondering what is this error and is it something I need to fix or can I attribute it to the DS doing its job?
Paul M. Whitney
Sent from my browser.
I'm new to this list and 389 Directory, I have what I think is a simple question but I've spent a couple of days looking for this answer without success. It could be I'm asking the wrong question. I have a 389 installation which an application will use to authenticate a pool of users. I was able to successfully configure the LDAP admin user to connect and pull the list of users (ou=mygroup, dc=domain) but the problem comes up when I want to narrow the list of possible users. Meaning, only allowing members of a certain group to be queried and authenticated against.
I'm generally new to directory services, though I have some experience with managing users through MS AD. The ou=group which contains the memberUid's is directly above the group and users which I'm able to successfully pull. For example, the location I need to filter users from is cn=myusergroup,ou=groups. The cn=myusergroup entry has a drop down field called memberUid which contains the members of the group. Getting the list of these users to work in a search filter is the problem I'm having.
The individual entries for each user are sparsely populated with fields and don't contain samaccountname but use UID instead. As I understand this is not a problem. Also, in each user entry there are no references to the group which they are a part of.
I'm using Ldapsearch to test the search filters and Apache Directory Studio to browse the directory. In my last experience in MS AD, I believe I just added the group attributes in each user entry as needed. Though, I'm new to 389 and want to do best practices as opposed to workarounds.
Any advice you could give is very much appreciated and or recommended references. The documentation I've found so far doesn't seem to connect.
We have an old version of CentOS Directory Server running on RHEL5 hosts.
This has been successfully replicating our LDAP directory to CentOS 6 hosts running a version of 389:
We've recently wanted to replicate to a pair of CentOS 7 servers running:
Whilst we've had no problems with initialising the consumers, we're having major problems with rename and delete actions for specific entries...
I've identified the problem as a rogue space after a comma in many objects DN's. Strangely, not all objects have this extra space! About 70% do and it's enough to cause a major problem.
An example would be:
with the space after dc=company,
My understanding is that LDAP should cope with either format. Unfortunately, we're finding replication to our CentOS7 hosts doesn't cope with the additional space.
So, if we rename or remove an object from a group it's not updated correctly on the CentOS 7 389 Slaves.
uid=fblogs,cn=company,ou=People,dc=company, dc=com leaves the company. We remove him from all his groups and disable his account. This successfully replicates to all Centos DS and RHEL6 389 instances. The change fails on the CentOS 7 389.
If we rename an entry to remove the space after the comma then we end up with two entries on the CentOS 7 389 :( One with the space and one without. Subsequent changes will correctly update the space free entry.
The only way to re-align the directories (and remove changed / stale comma space entries) is to re-initialise the CentOS 7 consumers :(
I could REALLY use some help to get to the bottom of this issue. I know we're trying to replicate to a new version of 389 but my feelings are that it should be handling the comma space issue as it has in previous versions. If this is a bug we'd be happy to help with getting it fixed ASAP.
question! ... I setup 389-ds for our organization and it has been working great for months.
i have two servers replicating as multiple masters and it is fantastic. However a new problem came upon my desk today. We are incubating another company within ours and for the foreseeable future we will be providing support for them.
That being said, i setup their Samba server yesterday and i would like to have them authenticate with the directory server. However instead of creating accounts on our domain for them, i wanted to see if i can add an administrative domain to the server without having to install 389 ds on any additional servers. I would like the same two servers to serve both domains. Is this possible?
if so ... help :D
Delaware Biotechnology Institute
15 Innovation Way
Newark, DE 19711
I have the following problems after upgrading from:
slapd-ldap12 is one of the directory server instance.
1. a new directory slapd-ldap12.0 under /etc/dirsrv/
drwxrwx---. 4 dirsrv dirsrv 235 May 2 10:46 slapd-ldap12
drwxrwx---. 4 dirsrv dirsrv 220 May 2 10:44 slapd-ldap12.0
2. database backup fail
/usr/lib64/dirsrv/slapd-ldap12/db2bak.pl -D "uid=backup_tasks_operator,cn=config
" -j some.pwd
#export to ldif
/usr/lib64/dirsrv/slapd-ldap12/db2ldif -n userRoot
[02/May/2017:10:44:48.973921266 -0400] Beginning backup of 'ldbm database'
[02/May/2017:10:44:48.974718649 -0400] db2archive: mkdir(/var/lib/dirsrv/slapd-ldap12.0/bak/ldap12.0-2017_5_2_10_44_48) failed; errno 2 (No such file or directory)
[02/May/2017:10:44:48.975490609 -0400] db2archive failed: removing /var/lib/dirsrv/slapd-ldap12.0/bak/ldap12.0-2017_5_2_10_44_48
[02/May/2017:10:44:48.977120481 -0400] Backup failed (error -1)
[02/May/2017:10:44:49.120992823 -0400] chown_dir_files: file (/etc/dirsrv/slapd-ldap12.0/slapd-collations.conf) chown failed (1) Operation not permitted.
[02/May/2017:10:44:49.146722858 -0400] chown_dir_files: file (/etc/dirsrv/slapd-ldap12.0/slapd-collations.conf) chown failed (1) Operation not permitted.
[02/May/2017:10:44:49.155797890 -0400] db2ldif: can't open /var/lib/dirsrv/slapd-ldap12.0/ldif/ldap12.0-userRoot-2017_05_02_104449.ldif: 2 (No such file or directory)
Thank you very much.
I'm looking for ideas to update ~100 uid's loginShell to /bin/nologin. For
the most part I use ADS to maintain the LDAP server but familiar with
modifying ONE entry using ldif file fed into ldapmodify.. What are some
good ways to bulk update?