389-users September 2017

389-users@lists.fedoraproject.org

15 participants
21 discussions

Multi-master replication among 1.2 and 1.3 servers
by tdarby＠email.arizona.edu 25 Sep '17

25 Sep '17

I'm in a situation where I will need to have my two existing version 1.2.11.15 B2015.345.187 servers, set up for multi-master replication, do multi-master replication with two additional 1.3 servers. Is there any known problem with this and is anyone doing it?

1 1

Announcing 389 Directory Server 1.4.0.0
by Mark Reynolds 22 Sep '17

22 Sep '17

389 Directory Server 1.4.0.0 The 389 Directory Server team is proud to announce 389-ds-base version 1.4.0.0 Fedora packages are available on Fedora 28(rawhide). https://koji.fedoraproject.org/koji/buildinfo?buildID=974103 <https://koji.fedoraproject.org/koji/buildinfo?buildID=974103> - Fedora 28 (rawhide) The new packages and versions are: * 389-ds-base-1.4.0.0-1 Source tarballs are available for download at Download 389-ds-base Source <https://releases.pagure.org/389-ds-base/389-ds-base-1.4.0.0.tar.bz2> Highlights in 1.4.0.0 * Version change 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* if you have 389-admin installed, otherwise please run *setup-ds.pl* to set up your directory server. To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run *setup-ds-admin.pl -u* if you have 389-admin installed, otherwise please run *setup-ds.pl* to update your directory server/admin server/console information. 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.o… 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.4.0.0-1

1 0

Announcing 389 Directory Server 1.3.7.5
by Mark Reynolds 22 Sep '17

22 Sep '17

389 Directory Server 1.3.7.5 The 389 Directory Server team is proud to announce 389-ds-base version 1.3.7.5 Fedora packages are available on Fedora 27. https://koji.fedoraproject.org/koji/buildinfo?buildID=974124 <https://koji.fedoraproject.org/koji/buildinfo?buildID=974124> - Fedora 27 The new packages and versions are: * 389-ds-base-1.3.7.5-1 Source tarballs are available for download at Download 389-ds-base Source <https://releases.pagure.org/389-ds-base/389-ds-base-1.3.7.5.tar.bz2> Highlights in 1.3.7.5 * Bug fixes 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* if you have 389-admin installed, otherwise please run *setup-ds.pl* to set up your directory server. To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run *setup-ds-admin.pl -u* if you have 389-admin installed, otherwise please run *setup-ds.pl* to update your directory server/admin server/console information. 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.o… 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.7.5 * Ticket 49327 - Add CI test for password expiration controls * Ticket 48085 - CI tests - replication ruvstore * Ticket 49381 - Refactor numerous suite docstrings * Ticket 48085 - CI tests - replication cl5 * Ticket 49379 - Allowed sasl mapping requires restart * Ticket 49327 - password expired control not sent during grace logins * Ticket 49380 - Add CI test * Ticket 83 - Fix create_test.py imports * Ticket 49381 - Add docstrings to ds_logs, gssapi_repl, betxn * Ticket 49380 - Crash when adding invalid replication agreement * Ticket 48081 - CI test - password - Ticket 49295 - Fix CI tests * Ticket 49295 - Fix CI test for account policy * Ticket 49373 - remove unused header file

1 0

Possible bug? - Silent install behaves differently from interactive
by Julian Kippels 20 Sep '17

20 Sep '17

Hi, I was playing around with silent installs and found out that the final configuration differs from interactive installations. Here is what I did: I installed two servers on different machines ds-1.localdomain and ds-2.localdomain. ds-1 is used as a master and ds-2 is supposed to use it as its configuration server. Both machines run RHEL 7.4 with the latest EPEL-builds of 389-ds. First I used setup-ds-admin.pl --keepcache interactively first on ds-1 and told it not to use an existing configuration server, then on ds-2 and told it to use ds-1. When I connect to ds-1 using 389-console I can see both ds-1 and ds-2. Then I took the generated .inf-files, removed all traces from the previous instances from both machines using remove-ds-admin.pl -a -f -y and then ran setup-ds-admin.pl --silent --file=ds-1.inf and --file=ds-2.inf respectively. When I connect to ds-1 now, I only see ds-1, to see ds-2 I have to connect to ds-2 with 389-console. The .inf-files look like this: -------- $ cat ds-1.inf [General] AdminDomain = localdomain ConfigDirectoryAdminID = admin ConfigDirectoryAdminPwd = XXX ConfigDirectoryLdapURL = ldap://ds-1.localdomain:389/o=NetscapeRoot FullMachineName = ds-1.localdomain ServerRoot = /usr/lib64/dirsrv StrictHostCheck = true SuiteSpotGroup = dirsrv SuiteSpotUserID = dirsrv [admin] Port = 9830 ServerAdminID = admin ServerAdminPwd = XXX ServerIpAddress = 0.0.0.0 SysUser = dirsrv [slapd] start_server = 0 AddOrgEntries = Yes AddSampleEntries = No HashedRootDNPwd = XXX InstScriptsEnabled = true InstallLdifFile = suggest RootDN = cn=Directory Manager RootDNPwd = XXX ServerIdentifier = ds-1 ServerPort = 389 SlapdConfigForMC = yes Suffix = dc=localdomain UseExistingMC = 0 bak_dir = /var/lib/dirsrv/slapd-ds-1/bak bindir = /usr/bin cert_dir = /etc/dirsrv/slapd-ds-1 config_dir = /etc/dirsrv/slapd-ds-1 datadir = /usr/share db_dir = /var/lib/dirsrv/slapd-ds-1/db ds_bename = userRoot inst_dir = /usr/lib64/dirsrv/slapd-ds-1 ldif_dir = /var/lib/dirsrv/slapd-ds-1/ldif localstatedir = /var lock_dir = /var/lock/dirsrv/slapd-ds-1 log_dir = /var/log/dirsrv/slapd-ds-1 naming_value = rz run_dir = /var/run/dirsrv sbindir = /usr/sbin schema_dir = /etc/dirsrv/slapd-ds-1/schema sysconfdir = /etc tmp_dir = /tmp -------- $ cat ds-2.inf [General] AdminDomain = localdomain ConfigDirectoryAdminID = admin ConfigDirectoryAdminPwd = XXX ConfigDirectoryLdapURL = ldap://ds-1.localdomain:389/o=NetscapeRoot FullMachineName = ds-2.localdomain ServerRoot = /usr/lib64/dirsrv StrictHostCheck = true SuiteSpotGroup = dirsrv SuiteSpotUserID = dirsrv [admin] Port = 9830 ServerAdminID = admin ServerAdminPwd = XXX ServerIpAddress = 0.0.0.0 SysUser = dirsrv [slapd] AddOrgEntries = Yes AddSampleEntries = No HashedRootDNPwd = XXX InstScriptsEnabled = true InstallLdifFile = suggest RootDN = cn=Directory Manager RootDNPwd = XXX ServerIdentifier = ds-2 ServerPort = 389 Suffix = dc=localdomain UseExistingMC = 1 bak_dir = /var/lib/dirsrv/slapd-ds-2/bak bindir = /usr/bin cert_dir = /etc/dirsrv/slapd-ds-2 config_dir = /etc/dirsrv/slapd-ds-2 datadir = /usr/share db_dir = /var/lib/dirsrv/slapd-ds-2/db ds_bename = userRoot inst_dir = /usr/lib64/dirsrv/slapd-ds-2 ldif_dir = /var/lib/dirsrv/slapd-ds-2/ldif localstatedir = /var lock_dir = /var/lock/dirsrv/slapd-ds-2 log_dir = /var/log/dirsrv/slapd-ds-2 naming_value = rz run_dir = /var/run/dirsrv sbindir = /usr/sbin schema_dir = /etc/dirsrv/slapd-ds-2/schema sysconfdir = /etc tmp_dir = /tmp I think this unintended behaviour and should be fixed. Unless I did a mistake somewhere, but I can't see where… Julian

2 7

Error after setting nsslapd-allow-anonymous-access:rootdse
by Patrick Landry 15 Sep '17

15 Sep '17

This is a fresh install on RHEL 7. 389-adminutil-1.1.21-2.el7.x86_64 389-admin-console-doc-1.1.12-1.el7.noarch 389-admin-console-1.1.12-1.el7.noarch 389-ds-base-libs-1.3.6.1-16.el7.x86_64 389-ds-console-1.2.16-1.el7.noarch 389-ds-1.2.2-6.el7.noarch 389-ds-base-1.3.6.1-16.el7.x86_64 389-ds-console-doc-1.2.16-1.el7.noarch 389-admin-1.1.46-1.el7.x86_64 389-console-1.1.18-1.el7.noarch 389-dsgw-1.1.11-5.el7.x86_64 Installation went fine and I was able to secure the directory server and admin server with certificates and restrict access to secure connections only. But after I changed nsslapd-allow-anonymous-access:rootdse to prevent anonymous binds the admin server now complains at startup: [Sat Sep 02 15:53:14.402180 2017] [:crit] [pid 2640:tid 139788241741952] populate_tasks_from_server(): Unable to search [cn=admin-serv-ldap-prod1,cn=389 Administration Server,cn=Server Group,cn=SERVER,ou=DOMAIN,o=NetscapeRoot] for LDAPConnection [SERVER:636] I am still able to use the console and the error doesn't seem to affect operation. If I set nsslapd-allow-anonymous-access:on the error goes away. If I set nsslapd-allow-anonymous-access:off I get additional errors (which would be expected): [Sat Sep 02 16:18:36.559764 2017] [:error] [pid 3298:tid 139706415569024] Could not bind as []: ldap error 48: Inappropriate authentication [Sat Sep 02 16:18:36.559933 2017] [:warn] [pid 3298:tid 139706415569024] Unable to bind as LocalAdmin to populate LocalAdmin tasks into cache. I did find an old issue in Pagure https://pagure.io/389-ds-base/issue/47850 which was for a different issue related to setting nsslapd-allow-anonymous-access:rootdse In that issue Mark mentions adding a separate user entry to be used to search o=netscaperoot but I can't find any other references to this solution (and don't know if it would solve this issue). -- Patrick Landry Director, UCSS University of Louisiana at Lafayette pml(a)louisiana.edu

3 4

jss and idm-console-framework conflict
by Morgan Jones 15 Sep '17

15 Sep '17

As of just today a yum install 389-ds fails for me with --> Processing Conflict: jss-4.4.0-7.el7.x86_64 conflicts idm-console-framework < 1.1.17-4 --> Finished Dependency Resolution Error: jss conflicts with idm-console-framework-1.1.17-1.el7.noarch It appears to be an update to jss in early August. I’m not an expert on how packages propagate but maybe it just took this long for it to get to my local mirror? This appears to be the issue, is there a work-around I’m not thinking of? It seems like this would make 389 installs from epel impossible. https://bugzilla.redhat.com/show_bug.cgi?id=1478547 Thanks, -morgan

2 6

ACI help
by Alberto Viana 11 Sep '17

11 Sep '17

Hi Folks, 389-Directory/1.3.7.3.20170901gite67788a B2017.244.1727 I'm trying to give a specific read/search/compare permissions to an user in a sub OU in my tree. I deleted the default ACI "anonymous access" (For tests purposes) I'm tried the following ACIs: OU scope: dn: OU=pop-ac,ou=pops,dc=my,dc=domain changetype: modify add: aci aci: (targetattr!="userPassword") (version 3.0;acl "All attributes PoP-AC Permissions";allow (read,search,compare) userdn="ldap:///uid=my-test-user,ou=aplicacoes,dc=my,dc=domain";) Log: 06/Sep/2017:16:15:32.427750186 -0300] - DEBUG - NSACLPlugin - print_access_control_summary - conn=47 op=1 (main): Deny search on entry(uid=rodrigo.nonato,ou=pop-ac,ou=pops,dc=my,dc=domain).attr(objectClass) to uid=my-test-user,ou=aplicacoes,dc=my,dc=domain: no aci matched the subject by aci(242): aciname= "SIE Group", acidn="dc=my,dc=domain" => SIE Group is one of the default 389 ACIs. or Whole domain scope: dn: dc=my,dc=domain changetype: modify add: aci aci: (target="ldap:///OU=pop-ac,ou=pops,dc=my,dc=domain")(targetattr!="userPassword") (version 3.0;acl "All attributes PoP-AC Permissions";allow (read,search,compare) userdn="ldap:///uid=my-test-user,ou=aplicacoes,dc=my,dc=domain";) Log: [06/Sep/2017:16:41:33.824679480 -0300] - DEBUG - NSACLPlugin - print_access_control_summary - conn=50 op=1 (main): Deny search on entry(uid=rodrigo.nonato,ou=pop-ac,ou=pops,dc=my,dc=domain).attr(objectClass) to uid=my-test-user,ou=aplicacoes,dc=my,dc=domain: no aci matched the subject by aci(253): aciname= "All attributes PoP-AC Permissions", acidn="dc=my,dc=domain" What I need: An user that has no other rights on my tree to read/search all attributes/users on an specific OU. Is that possible? What am I missing? Thanks Cheers, Alberto Viana

3 4

libdb: unable to allocate memory for mutex; resize mutex region
by Joshua Brodie 07 Sep '17

07 Sep '17

Hello: We are running an older 389-Directory Server (v 1.2.11.29) --- being upgraded soon but still stuck with it. Starting a week ago, we have started receiving error messages like below --- restarting resolves till the next time error reoccurs (and service subsequently not responsive till restart). Any ideas on how to find the root cause to what triggers it? > [07/Sep/2017:06:18:03 -0700] - libdb: unable to allocate memory for mutex; resize mutex region > [07/Sep/2017:06:18:03 -0700] - libdb: unable to allocate memory for mutex; resize mutex region > [07/Sep/2017:06:18:03 -0700] - libdb: unable to allocate memory for mutex; resize mutex region > [07/Sep/2017:06:18:03 -0700] - libdb: unable to allocate memory for mutex; resize mutex region > [07/Sep/2017:06:18:04 -0700] - libdb: unable to allocate memory for mutex; resize mutex region > [07/Sep/2017:06:18:04 -0700] - libdb: unable to allocate memory for mutex; resize mutex region > [07/Sep/2017:06:18:04 -0700] - libdb: unable to allocate memory for mutex; resize mutex region > [07/Sep/2017:06:18:04 -0700] - libdb: unable to allocate memory for mutex; resize mutex region > [07/Sep/2017:06:18:05 -0700] - libdb: unable to allocate memory for mutex; resize mutex region > [07/Sep/2017:06:18:05 -0700] - libdb: unable to allocate memory for mutex; resize mutex region > [07/Sep/2017:06:18:05 -0700] - libdb: unable to allocate memory for mutex; resize mutex region > [07/Sep/2017:06:18:05 -0700] - libdb: unable to allocate memory for mutex; resize mutex region > [07/Sep/2017:06:18:05 -0700] - libdb: unable to allocate memory for mutex; resize mutex region > [07/Sep/2017:06:18:05 -0700] - libdb: unable to allocate memory for mutex; resize mutex region > [07/Sep/2017:06:18:06 -0700] - libdb: unable to allocate memory for mutex; resize mutex region > [07/Sep/2017:06:18:06 -0700] - libdb: unable to allocate memory for mutex; resize mutex region > [07/Sep/2017:06:18:06 -0700] - libdb: unable to allocate memory for mutex; resize mutex region

2 1

Announcing 389 Directory Server 1.3.7.4
by Mark Reynolds 06 Sep '17

06 Sep '17

389 Directory Server 1.3.7.4 The 389 Directory Server team is proud to announce 389-ds-base version 1.3.7.4 Fedora packages are available on Fedora 27 and 28(Rawhide). https://koji.fedoraproject.org/koji/taskinfo?taskID=21684703 <https://koji.fedoraproject.org/koji/taskinfo?taskID=21607186> - Fedora 28 https://koji.fedoraproject.org/koji/taskinfo?taskID=21684678 <https://koji.fedoraproject.org/koji/taskinfo?taskID=21607237> - Fedora 27 The new packages and versions are: * 389-ds-base-1.3.7.4-1 Source tarballs are available for download at Download 389-ds-base Source <http://www.port389.org/binaries/389-ds-base-1.3.7.4.tar.bz2> Highlights in 1.3.7.4 * Bug fixes 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* if you have 389-admin installed, otherwise please run *setup-ds.pl* to set up your directory server. To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run *setup-ds-admin.pl -u* if you have 389-admin installed, otherwise please run *setup-ds.pl* to update your directory server/admin server/console information. 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.o… 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.7.4 * Ticket 49371 - Cleanup update script * Ticket 48831 - Autotune dncache with entry cache. * Ticket 49312 - pwdhash -D used default hash algo * Ticket 49043 - make replication conflicts transparent to clients * Ticket 49371 - Fix rpm build * Ticket 49371 - Template dse.ldif did not contain all needed plugins * Ticket 49295 - Fix CI Tests * Ticket 49050 - make objectclass ldapsubentry effective immediately

1 0

Console hang after 4th server install
by Morgan Jones 05 Sep '17

05 Sep '17

I’m in the process of installing 389 in CentOS 7 from epel (versions below) and find that the console becomes unresponsive after I install the 4th server. I can open the console and expand a few servers but within 30 seconds it consistently hangs. I am storing configuration data in one server. Has anyone else seen this or do you have any insight? Thanks, -morgan [morgan@devldap03 ~]$ rpm -qa|grep 389 pcp-pmda-ds389log-3.11.3-4.el7.x86_64 389-admin-console-1.1.12-1.el7.noarch 389-dsgw-1.1.11-5.el7.x86_64 389-adminutil-1.1.21-2.el7.x86_64 389-admin-1.1.46-1.el7.x86_64 389-ds-console-doc-1.2.16-1.el7.noarch 389-ds-1.2.2-6.el7.noarch 389-ds-base-libs-1.3.5.10-21.el7_3.x86_64 389-ds-base-1.3.5.10-21.el7_3.x86_64 389-admin-console-doc-1.1.12-1.el7.noarch 389-console-1.1.18-1.el7.noarch pcp-pmda-ds389-3.11.3-4.el7.x86_64 389-ds-console-1.2.16-1.el7.noarch [morgan@devldap03 ~]$

2 18

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users September 2017