Can't use local time format on a Generalized Time attribute
by jfillman@central1.com
I'm migrating a DS from RHDS 8.2 to 389 DS and i'm having an issue attributes of type 'Generalized Time'.
One my old LDAP server, i could set dates in this format: 20160215133951.842
389 DS 1.2.11 doesn't seem to allow this local time version. Is there any way to enable/allow this?
8 years, 2 months
determining dynamic group membership
by Frank Munsche
Hi guys,
how can I determine the members of a dynamic group? After some research, it is
still not obvious to me. There is an example at page 220 of the redhat
directory server adm guide at:
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10...
Within the 389 console you can list the members of the dynamic group using the
'test' button. Unfortunately, I'm using a stripped down installation of 389
without the admin server. But it should be possible to list the members of a
dynamic group using ldapsearch, or?
I've tried to query the dyn group object itself, but the members are missing:
ldapsearch -H ldap://ldap.example.org -D "cn=directory manager" -W -Z -x -b
'cn=admin,ou=sampleapp,ou=appgroups,dc=example,dc=org' 'objectclass=*'
dn: cn=admin,ou=sampleapp,ou=appgroups,dc=example,dc=org
objectClass: top
objectClass: groupOfUniqueNames
objectClass: groupOfURLs
cn: admin
description: sampleapp admin users dyn group
memberURL: ldap:///ou=people,dc=example,dc=org??sub?(&(objectclass=pers
on)(mail=*example.org))
# search result
search: 3
result: 0 Success
# numResponses: 2
# numEntries: 1
I've also tested the Url in a separate ldapsearch which returns lots of
entries.
What am I missing?
thank you very much,
cheers, Frank
8 years, 2 months
Announcing 389 Directory Server version 1.3.4.8
by Noriko Hosoi
389 Directory Server 1.3.4.8
The 389 Directory Server team is proud to announce 389-ds-base version
1.3.4.8.
Fedora packages are available from the Fedora 22, 23 and
Rawhide repositories.
The new packages and versions are:
* 389-ds-base-1.3.4.8-1
Source tarballs are available for download at Download 389-ds-base
Source
<http://directory.fedoraproject.org/binaries/389-ds-base-1.3.4.8.tar.bz2> and
Download nunc-stans Source
<http://directory.fedoraproject.org/binaries/nunc-stans-0.1.5.tar.bz2>.
Highlights in 1.3.4.8
* Various bugs including a security bug 1299417 are fixed.
Installation and Upgrade
See Download
<http://directory.fedoraproject.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://directory.fedoraproject.org/docs/389ds/legacy/install-guide.html> for
more information about the initial installation, setup, and upgrade
See Source
<http://directory.fedoraproject.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...
as well as
https://admin.fedoraproject.org/updates/389-ds-base-1.3.4.8-1.fc22
<https://admin.fedoraproject.org/updates/389-ds-base-1.3.4.8-1.fc22> and
https://admin.fedoraproject.org/updates/389-ds-base-1.3.4.8-1.fc23
<https://admin.fedoraproject.org/updates/389-ds-base-1.3.4.8-1.fc23>.
If you find a bug, or would like to see a new feature, file it in our
Trac instance: https://fedorahosted.org/389
Detailed Changelog since 1.3.4.5
* Ticket 47788 - Supplier can skip a failing update, although it
should retry
* Ticket 48289 - 389-ds-base: ldclt-bin killed by SIGSEGV
* Ticket 48305 - perl module conditional test is not conditional when
checking SELinux policies
* Ticket 48312 - Crash when doing modrdn on managed entry
* Ticket 48332 - allow users to specify to relax the FQDN constraint
* Ticket 48341 - deadlock on connection mutex
* Ticket 48362 - With exhausted range, part of DNA shared
configuration is deleted after server restart
* Ticket 48369 - RFE - Add config setting to always send the password
expiring time
* Ticket 48370 - The ‘eq’ index does not get updated properly when
deleting and re-adding attributes in the same modify operation
* Ticket 48375 - SimplePagedResults – in the search error case, simple
paged results slot was not released.
* Ticket 48388 - db2ldif -r segfaults from time to time
* Ticket 48406 - Avoid self deadlock by PR_Lock(conn->c_mutex)
* Ticket 48412 - worker threads do not detect abnormally
closed connections
* Ticket 48445 - keep alive entries can break replication
* Ticket 48448 - dirsrv start-stop fail in certain shell environments.
* Ticket 48492 - heap corruption at schema replication.
* Ticket 48536 - Crash in slapi_get_object_extension
8 years, 2 months
Question about re-indexing with db2index.pl
by Derek Belcher
I recently added a new Muilt-Master and Consumer to my existing LDAP
infrastructure and I am having issues when I go to initialize the new
servers. On the new servers I am getting the following errors:
[02/Feb/2016:15:27:17 -0600] NSMMReplicationPlugin -
multimaster_be_state_change: replica dc=alertlogic,dc=net is going offline;
disabling replication
[02/Feb/2016:15:27:17 -0600] - WARNING: Import is running with
nsslapd-db-private-import-mem on; No other process is allowed to access the
database
[02/Feb/2016:15:27:17 -0600] - import userRoot: WARNING: Skipping entry
"uid=user1,ou=Users,ou=Place1,ou=Place2,ou=Groups,dc=mydomain,dc=net" which
has no parent, ending at line 0 of file "(bulk import)"
[02/Feb/2016:15:27:17 -0600] - import userRoot: WARNING: Skipping entry
"uid=user2,ou=Users,ou=Place1,ou=Place2,ou=Groups,dc=mydomain,dc=net" which
has no parent, ending at line 0 of file "(bulk import)"
[02/Feb/2016:15:27:17 -0600] - import userRoot: WARNING: bad entry: ID 29
[02/Feb/2016:15:27:17 -0600] - import userRoot: WARNING: Skipping entry
"uid=user3,ou=Users,ou=Place1,ou=Place2,ou=Groups,dc=mydomain,dc=net" which
has no parent, ending at line 0 of file "(bulk import)"
[02/Feb/2016:15:27:17 -0600] - import userRoot: WARNING: bad entry: ID 30
[02/Feb/2016:15:27:17 -0600] - import userRoot: WARNING: bad entry: ID 31
I could not find much on these errors and was thinking that I may need to
re-index my source master LDAP server. I have verified that all of the OU's
exist on the new servers. When I re-initalize these two new servers it does
put the bulk of the users into the OU's but is failing on a few users (as
shown above). I found the following post and have surmised my strategy from
it:
http://www.spinics.net/linux/fedora/389-users/msg17329.html
I am planning on running the following command on my source server:
# /usr/lib64/dirsrv/slapd-YOURID/db2index -n MYBACKEND -t entryrdn
Questions:
1) Is this the right command and am I thinking about this issue in the
correct manner?
2) If this is the corrent command to run, after running it, do I need to
break all replications and re-initialize all of my Masters, then consumers,
then setup all of the replication agreements again? Or do I just run the
db2index.pl and then let the established replication agreements just do
their thing?
3) Is there anything else that I should be aware of or do before I take
this action?
All servers are running CentOS 6.xx
# rpm -qa 389*
389-ds-console-1.2.6-1.el6.noarch
389-ds-1.2.2-1.el6.noarch
389-ds-base-libs-1.2.11.15-48.el6_6.x86_64
389-dsgw-1.1.11-1.el6.x86_64
389-admin-console-1.1.8-1.el6.noarch
389-ds-console-doc-1.2.6-1.el6.noarch
389-console-1.1.7-1.el6.noarch
389-admin-1.1.35-1.el6.x86_64
389-admin-console-doc-1.1.8-1.el6.noarch
389-adminutil-1.1.19-1.el6.x86_64
389-ds-base-1.2.11.15-48.el6_6.x86_64
Thank you all for your time and I really appreciate all of your help!
--Derek
8 years, 2 months
Failback behaviour in 2 instance MMR config
by bernie jones
Hi all, hope someone might be able to help with this question.
I've configured two 389-DS servers each on a Centos 6.7 server and successfully configured MMR between them - all working well with 'always keep in synch' configured.
However, I'm uncertain how to configure the failback behaviour for my LDAP client - specifically:
I configure my client to bind to instance 1 and failover to instance 2 if instance 1 becomes unavailable
If after failover, instance 1 is brought back up some time later, then If I configure my client to automatically fail back to instance 1 when it detects it as available is there a risk that LDAP operations will commence against instance 1 before replication has completed from instance 2 to instance 1?
If so, are there any ways to avoid this so that reading/writing stale data can be avoided.
Many thanks,
Bernie
8 years, 2 months
Unable to connect to 389 admin server after applying SSL
by Richard Tearle
Hello
We've successfully deployed a test instance of 389 on Centos 7 within
Docker. We can connect with our usual LDAP tools, our code, the
administrator web application and by using the 389 Windows
application. All OK.
When we applied SSL/TLS, by using the setupssl2.sh script we can no
longer connect using the 389 Windows application, although all other
functions are running OK. The error messages we receive after entering
the user information are:
The certificate this server present is either untrusted or unknown -
that's fine it's a self signed certificate, so I accept this
certificate.
Cannot connect to the Admin Server "https://<host>:9830". The Url is
not correct or the server is not running.
Looking in the error log file for the admin server I have the following entries:
[Thu Feb 04 11:34:28.884037 2016] [:info] [pid 662:tid
140597238659136] Configuring server for SSL protocol
[Thu Feb 04 11:34:28.884248 2016] [:debug] [pid 662:tid
140597238659136] nss_engine_init.c(702): NSSProtocol: Enabling
TLSv1.1
[Thu Feb 04 11:34:28.884331 2016] [:debug] [pid 662:tid
140597238659136] nss_engine_init.c(761): NSSProtocol: [TLS 1.1]
(minimum)
[Thu Feb 04 11:34:28.884420 2016] [:debug] [pid 662:tid
140597238659136] nss_engine_init.c(778): NSSProtocol: [TLS 1.1]
(maximum)
[Thu Feb 04 11:34:28.884642 2016] [:debug] [pid 662:tid
140597238659136] nss_engine_init.c(983): NSSCipherSuite: Configuring
permitted SSL ciphers
[+rsa_rc4_128_md5,+rsa_rc4_128_sha,+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha]
[Thu Feb 04 11:34:28.884792 2016] [:info] [pid 662:tid
140597238659136] Using nickname server-cert.
[Thu Feb 04 11:34:28.918651 2016] [:debug] [pid 662:tid
140597238659136] mod_admserv/mod_admserv.c(2369): Entering
do_admserv_post_config - pid is [662]
[Thu Feb 04 11:34:28.918813 2016] [:debug] [pid 662:tid
140597238659136] mod_admserv/mod_admserv.c(2377): Entering
do_admserv_post_config - init count is [2]
[Thu Feb 04 11:34:28.918899 2016] [:debug] [pid 662:tid
140597238659136] mod_admserv/mod_admserv.c(2401): [662] Cache
expiration set to 600 seconds
[Thu Feb 04 11:34:28.956732 2016] [:debug] [pid 662:tid
140597238659136] mod_admserv/mod_admserv.c(2505): Added StartConfigDs
task entry [cn=startconfigds,cn=operation,cn=tasks,cn=admin-serv-ldap-server,cn=389
administration server,cn=server
group,cn=ldap-server.docker,ou=docker,o=netscaperoot:start_config_ds:]
for user [LocalSuper]
[Thu Feb 04 11:34:28.961067 2016] [:info] [pid 662:tid
140597238659136] host_ip_init(): problem creating secure AdmldapInfo
(error code = 4)
[Thu Feb 04 11:34:28.963356 2016] [:notice] [pid 662:tid
140597238659136] Access Host filter is: *.docker
[Thu Feb 04 11:34:28.963422 2016] [:notice] [pid 662:tid
140597238659136] Access Address filter is: *
When I try to connect to the admin server, there is no corresponding
entry in the access logs for the directory server. Running strace
shows the following logs around the point the software logs the
"host_ip_init(): problem creating secure AdmldapInfo" message:
659 11:34:28 stat("/etc/dirsrv/admin-serv/adm.conf",
{st_mode=S_IFREG|0600, st_size=508, ...}) = 0
659 11:34:28 open("/etc/dirsrv/admin-serv/adm.conf", O_RDONLY) = 12
659 11:34:28 fstat(12, {st_mode=S_IFREG|0600, st_size=508, ...}) = 0
659 11:34:28 mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fdf58776000
659 11:34:28 read(12, "AdminDomain: docker\nsysuser: nobody\nisie:
cn=389 Administration Server,cn=Server
Group,cn=ldap-server.docker,ou=docker,o=Netscap"..., 4096) = 508
659 11:34:28 read(12, "", 4096) = 0
659 11:34:28 close(12) = 0
659 11:34:28 munmap(0x7fdf58776000, 4096) = 0
659 11:34:28 stat("/etc/dirsrv/admin-serv/admpw",
{st_mode=S_IFREG|0600, st_size=40, ...}) = 0
659 11:34:28 open("/etc/dirsrv/admin-serv/admpw", O_RDONLY) = 12
659 11:34:28 fstat(12, {st_mode=S_IFREG|0600, st_size=40, ...}) = 0
659 11:34:28 mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fdf58776000
659 11:34:28 read(12, "admin:{SHA}L9P5p6bDeyroxEtjCalDW6iFyIc=\n", 4096) = 40
659 11:34:28 close(12) = 0
659 11:34:28 munmap(0x7fdf58776000, 4096) = 0
659 11:34:28 write(2, "[Thu Feb 04 11:34:28.659125 2016] [:info]
[pid 659:tid 140597238659136] host_ip_init(): problem creating secure
AdmldapInfo (err"..., 141) = 141
659 11:34:28 geteuid() = 0
659 11:34:28 setresuid(-1, 99, -1) = 0
These are the 389 packages that have been installed:
389-admin-1.1.42-1.el7.x86_64.rpm
389-admin-console-1.1.10-1.el7.noarch.rpm
389-adminutil-1.1.22-1.el7.x86_64.rpm
389-console-1.1.9-1.el7.noarch.rpm
389-ds-base-1.3.3.1-20.el7_1.x86_64.rpm
389-ds-base-libs-1.3.3.1-20.el7_1.x86_64.rpm
389-ds-console-1.2.12-1.el7.noarch.rpm
And this is the output from uname -all:
Linux d83459731f6d 3.10.0-229.11.1.el7.x86_64 #1 SMP Thu Aug 6
01:06:18 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
and finally this is the hosts file:
172.17.0.3 ldap-server.docker d83459731f6d ldap-server.bridge ldap-server
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
We're at a bit of a loss where to turn.
--
This email is sent on behalf of Northgate Public Services (UK) Limited and
its associated companies including Rave Technologies (India) Pvt Limited
(together "Northgate Public Services") and is strictly confidential and
intended solely for the addressee(s).
If you are not the intended recipient of this email you must: (i) not
disclose, copy or distribute its contents to any other person nor use its
contents in any way or you may be acting unlawfully; (ii) contact
Northgate Public Services immediately on +44(0)1908 264500 quoting the name
of the sender and the addressee then delete it from your system.
Northgate Public Services has taken reasonable precautions to ensure that
no viruses are contained in this email, but does not accept any
responsibility once this email has been transmitted. You should scan
attachments (if any) for viruses.
Northgate Public Services (UK) Limited, registered in England and Wales
under number 00968498 with a registered address of Peoplebuilding 2,
Peoplebuilding Estate, Maylands Avenue, Hemel Hempstead, Hertfordshire, HP2
4NN. Rave Technologies (India) Pvt Limited, registered in India under
number 117068 with a registered address of 2nd Floor, Ballard House, Adi
Marzban Marg, Ballard Estate, Mumbai, Maharashtra, India, 400001.
8 years, 2 months