May 2017 - 389-users - Fedora Mailing-Lists

G

by Andrei.shlidt

Andrei.shlidt(a)gmail.com

5 years, 10 months

1
0
0 / 0

Announcing 389 Directory Server version 1.3.6.6

by Mark Reynolds

389 Directory Server 1.3.6.6 The 389 Directory Server team is proud to announce 389-ds-base version 1.3.6.6 Fedora packages are available for testing from the Fedora 26 and Rawhide repositories. https://bodhi.fedoraproject.org/updates/FEDORA-2017-8ab2f264a3 The new packages and versions are: * 389-ds-base-1.3.6.6-1 Fedora 26 * 389-ds-base-1.3.6.6-2 Rawhide (F27) Source tarballs are available for download at Download 389-ds-base Source <http://www.port389.org/binaries/389-ds-base-1.3.6.6.tar.bz2> Highlights in 1.3.6.6 * Bug fixes, and enhancements Installation and Upgrade See Download <http://www.port389.org/docs/389ds/download.html> for information about setting up your yum repositories. To install, use *yum install 389-ds* yum install 389-ds After install completes, run *setup-ds-admin.pl* to set up your directory server. setup-ds-admin.pl To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run *setup-ds-admin.pl -u* to update your directory server/admin server/console information. setup-ds-admin.pl -u See Install_Guide <http://www.port389.org/docs/389ds/legacy/install-guide.html> for more information about the initial installation, setup, and upgrade See Source <http://www.port389.org/docs/389ds/development/source.html> for information about source tarballs and SCM (git) access. Feedback We are very interested in your feedback! Please provide feedback and comments to the 389-users mailing list: https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproject... If you find a bug, or would like to see a new feature, file it in our Pagure project: https://pagure.io/389-ds-base * Bump version to 1.3.6.6-1 * Ticket 49157 - fix error in ds-logpipe.py * Ticket 48864 - remove config.h from spal header. * Ticket 48681 - logconv.pl - Fix SASL Bind stats and rework report format * Ticket 49261 - Fix script usage and man pages * Ticket 49238 - AddressSanitizer: heap-use-after-free in libreplication * Ticket 48864 - Fix FreeIPA build * Ticket 49257 - Reject dbcachesize updates while auto cache sizing is enabled * Ticket 49249 - cos_cache is erroneously logging schema checking failure * Ticket 49258 - Allow nsslapd-cache-autosize to be modified while the server is running * Ticket 49247 - resolve build issues on debian * Ticket 49246 - ns-slapd crashes in role cache creation * Ticket 49157 - ds-logpipe.py crashes for non-existing users * Ticket 49241 - Update man page and usage for db2bak.pl * Ticket 49075 - Adjust logging severity levels * Ticket 47662 - db2index not properly evaluating arguments * Ticket 48989 - fix perf counters

5 years, 10 months

1
0
0 / 0

Announcing 389 Directory Server version 1.3.6.5

by Mark Reynolds

389 Directory Server 1.3.6.5 The 389 Directory Server team is proud to announce 389-ds-base version 1.3.6.5 Fedora packages are available from the Fedora 26 https://koji.fedoraproject.org/koji/buildinfo?buildID=884231 The new packages and versions are: * 389-ds-base-1.3.6.5-1 Source tarballs are available for download at Download 389-ds-base Source <http://www.port389.org/binaries/389-ds-base-1.3.6.5.tar.bz2> Highlights in 1.3.6.5 * Bug fixes, and enhancements Installation and Upgrade See Download <http://www.port389.org/docs/389ds/download.html> for information about setting up your yum repositories. To install, use *yum install 389-ds* yum install 389-ds After install completes, run *setup-ds-admin.pl* to set up your directory server. setup-ds-admin.pl To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run *setup-ds-admin.pl -u* to update your directory server/admin server/console information. setup-ds-admin.pl -u See Install_Guide <http://www.port389.org/docs/389ds/legacy/install-guide.html> for more information about the initial installation, setup, and upgrade See Source <http://www.port389.org/docs/389ds/development/source.html> for information about source tarballs and SCM (git) access. Feedback We are very interested in your feedback! Please provide feedback and comments to the 389-users mailing list: https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproject... If you find a bug, or would like to see a new feature, file it in our Pagure project: https://pagure.io/389-ds-base * Bump version to 1.3.6.5-1 * Ticket 49231 - fix sasl mech handling * Ticket 49233 - Fix crash in persistent search * Ticket 49230 - slapi_register_plugin creates config entry where it should not * Ticket 49135 - PBKDF2 should determine rounds at startup * Ticket 49236 - Fix CI Tests * Ticket 48310 - entry distribution should be case insensitive * Ticket 49224 - without –prefix, $prefixdir would be NONE in defaults.

5 years, 10 months

1
0
0 / 0

db2index.pl Questionable

by Paul Whitney

Hi guys, 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. Stats: Version 389-DS: 1.3.5.10 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) Second test: /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 E-mail: paul.whitney(a)mac.com Sent from my browser.

5 years, 10 months

2
1
0 / 0

389 DS with Samba

by Duarte,Alexander A

Hey everyone! 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. Regards, Alex

5 years, 10 months

2
1
0 / 0

entry set tombstone rdn

by Paul Whitney

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? Thanks, Paul M. Whitney E-mail: paul.whitney(a)mac.com Sent from my browser.

5 years, 10 months

2
1
0 / 0

Search Filter by Group

by saul.cisneros＠gmail.com

Hi all, 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. -Saul

5 years, 10 months

4
11
2 / 0

Replication Issue between versions - Space after commas issues in DN

by its-notify＠alfresco.com

Hi, 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: 389-ds-base-1.2.11.25-1.el6.x86_64 389-ds-1.2.2-1.el6.noarch We've recently wanted to replicate to a pair of CentOS 7 servers running: 389-ds-1.2.2-6.el7.noarch 389-ds-base-1.3.5.10-18.el7_3.x86_64 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: uid=fblogs,cn=company,ou=People,dc=company, dc=com with the space after dc=company, rather than: uid=fblogs,cn=company,ou=People,dc=company,dc=com 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. i.e. 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. Thanks, Philip

5 years, 10 months

3
4
0 / 0

Adding another Domain to 389-DS

by Duarte,Alexander A

Hello all!... 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 Regards, Alex Duarte System Administrator Delaware Biotechnology Institute 15 Innovation Way Newark, DE 19711 (302) 831-3414 alexdu@<mailto:alexdu@e>udel.edu<http://udel.edu/> alex(a)dbi.udel.edu<mailto:alex@dbi.udel.edu>

5 years, 10 months

2
1
0 / 0

problems after upgrading to 1.3.5.10 B2017.093.2133

by albert.luo＠uwindsor.ca

I have the following problems after upgrading from: 389-Directory/1.3.5.10 B2017.047.2239 to: 389-Directory/1.3.5.10 B2017.093.2133 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 #!/bin/sh #backup db /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 error log [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.

5 years, 11 months

2
3
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users May 2017