Multi-master replication among 1.2 and 1.3 servers
by tdarby@email.arizona.edu
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?
6 years, 6 months
Announcing 389 Directory Server 1.4.0.0
by Mark Reynolds
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...
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
6 years, 6 months
Announcing 389 Directory Server 1.3.7.5
by Mark Reynolds
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...
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
6 years, 6 months
Possible bug? - Silent install behaves differently from interactive
by Julian Kippels
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
6 years, 6 months
Error after setting nsslapd-allow-anonymous-access:rootdse
by Patrick Landry
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
6 years, 6 months
jss and idm-console-framework conflict
by Morgan Jones
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
6 years, 6 months
ACI help
by Alberto Viana
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
6 years, 6 months
libdb: unable to allocate memory for mutex; resize mutex region
by Joshua Brodie
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
6 years, 6 months
Announcing 389 Directory Server 1.3.7.4
by Mark Reynolds
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...
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
6 years, 6 months
Console hang after 4th server install
by Morgan Jones
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 ~]$
6 years, 6 months