389-users September 2011

389-users@lists.fedoraproject.org

30 participants
36 discussions

Question on certificate storage
by Orion Poplawski 23 Sep '11

23 Sep '11

I'm trying to setup MMR with another office site. We're trying to connect over SSL, but my server gives the error: [23/Sep/2011:12:00:56 -0600] slapi_ldap_bind - Error: could not send bind request for id [cn=Replication Manager,cn=config] mech [SIMPLE]: error 81 (Can't contact LDAP server) -8179 (Peer's Certificate issuer is not recognized.) 11 (Resource temporarily unavailable) I've added what I believe are the proper CA certs (it is a chain of 3) for the remote server to my directory server via the 389-console and manage certificates. However, I noticed that when I use certutil on the server to list the certificates, I don't see them: # certutil -d /etc/dirsrv/slapd-cora/ -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI CA certificate CT,, server-cert u,u,u I would have thought they would be stored in the same place. If not, where are the one listed in the console stored? Does it matter that they aren't showing up with certutil? Anything else I can do to debug the SSL connection? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion(a)cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com

2 5

Epel-testing Repo
by Curran Woodward 22 Sep '11

22 Sep '11

Hello, I can no longer install 389-ds with the below epel-testing.repo. It was working fine last week: [epel-testing] name=Extra Packages for Enterprise Linux 6 - Testing - $basearch #baseurl=http://download.fedoraproject.org/pub/epel/testing/6/$basearch mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=testing-epel6&ar… failovermethod=priority enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6 Does anyone have a current epel-testing.repo that works? Thanks! Curran

2 1

389-adminutil package dependency issues fresh install
by Aaron Oas 22 Sep '11

22 Sep '11

I recently spent hours resolving a packaging issue when trying to install 389-ds 1.2.9.9, and thought I would share my finding, which is that the recent 389-adminutil-1.1.14 package version seems to have gone backwards in the library versions it provides. My system is on Centos 5.5, 64bit, using the regular epel repos with mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=epel-5&arch=$ba…. I have been installing and uninstalling 389-ds over the past few weeks as I develop and prove out a migration of our ldap server, using a script to manage the yum installs/erases and related cleanup so that my results would be consistent. I started getting dependency problems after 1.2.9.9 came out, like: Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package 389-ds.noarch 0:1.2.1-1.el5 set to be updated --> Processing Dependency: 389-ds-console-doc for package: 389-ds --> Processing Dependency: 389-ds-console for package: 389-ds --> Processing Dependency: 389-admin-console-doc for package: 389-ds --> Processing Dependency: 389-admin-console for package: 389-ds --> Processing Dependency: 389-dsgw for package: 389-ds --> Processing Dependency: 389-console for package: 389-ds --> Running transaction check ---> Package 389-admin-console.noarch 0:1.1.8-1.el5 set to be updated ---> Package 389-admin-console-doc.noarch 0:1.1.8-1.el5 set to be updated ---> Package 389-console.noarch 0:1.1.7-1.el5 set to be updated ---> Package 389-ds-console.noarch 0:1.2.6-1.el5 set to be updated ---> Package 389-ds-console-doc.noarch 0:1.2.6-1.el5 set to be updated ---> Package 389-dsgw.x86_64 0:1.1.7-1.el5 set to be updated --> Processing Dependency: libadmsslutil.so.1()(64bit) for package: 389-dsgw --> Processing Dependency: libadminutil.so.1()(64bit) for package: 389-dsgw --> Finished Dependency Resolution 389-dsgw-1.1.7-1.el5.x86_64 from epel has depsolving problems --> Missing Dependency: libadmsslutil.so.1()(64bit) is needed by package 389-dsgw-1.1.7-1.el5.x86_64 (epel) 389-dsgw-1.1.7-1.el5.x86_64 from epel has depsolving problems --> Missing Dependency: libadminutil.so.1()(64bit) is needed by package 389-dsgw-1.1.7-1.el5.x86_64 (epel) Error: Missing Dependency: libadminutil.so.1()(64bit) is needed by package 389-dsgw-1.1.7-1.el5.x86_64 (epel) Error: Missing Dependency: libadmsslutil.so.1()(64bit) is needed by package 389-dsgw-1.1.7-1.el5.x86_64 (epel) You could try using --skip-broken to work around the problem You could try running: package-cleanup --problems package-cleanup --dupes rpm -Va --nofiles --nodigest The program package-cleanup is found in the yum-utils package. [root@ds03 ~]# rpm -q --provides 389-adminutil adminutil = 1.1.14-1.el5 libadminutil.so.0()(64bit) libadmsslutil.so.0()(64bit) 389-adminutil = 1.1.14-1.el5 I started doing a yum clean all in between every install to make sure there were no issues. I still failed every time, then suddenly 10 minutes later, an install worked. I successfully reinstalled with my script a few times, then the next time it failed again with the same dependency complaint. Ultimately, it turned out that I was sometimes getting 389-adminutil-1.1.13-1.el5 and sometimes getting 389-adminutil-1.1.14-1.el5 as I hit different mirrors after each yum clean all. The version that resolves the dependency requirements is the *lesser* version: 389-adminutil-1.1.13-1.el5. What is odd to me is that the older 389-adminutil 1.1.13 version supplies an apparently higher version of libadminutil and libadmsslutil: rpm -q --provides 389-adminutil adminutil = 1.1.13-1.el5 libadminutil.so.1()(64bit) libadmsslutil.so.1()(64bit) 389-adminutil = 1.1.13-1.el5 I.e., 389-adminutil-1.1.14 provides libadminutil.so.0, and 389-adminutil-1.1.13 provides libadminutil.so.1 I haven't gone so far as to dig into which mirrors were providing which versions, but I hope this helps someone else in the same boat, and perhaps even helps the repo or mirror retainers if there is something wrong there. - Aaron

2 1

Re: [389-users] SSL Error on Startup
by Rich Megginson 21 Sep '11

21 Sep '11

On 09/20/2011 07:45 AM, Chris Ober wrote: > Rich, > > I've read that, and I believe I've followed the steps shown there, but > it doesn't solve my problem. let's start with perms/ownership ls -al /etc/dirsrv/slapd-instance grep nsslapd-localuser /etc/dirsrv/slapd-instance/dse.ldif see what the server cert name is grep -i personality /etc/dirsrv/slapd-instance/dse.ldif next, look at certutil certutil -d /etc/dirsrv/slapd-instance -L certutil -d /etc/dirsrv/slapd-instance -L -n "name of CA cert" certutil -d /etc/dirsrv/slapd-instance -L -n "name of server cert" > > ~Chris > > On 9/19/11 2:47 PM, Rich Megginson wrote: >> On 09/19/2011 12:26 PM, Chris M. Ober wrote: >>> Hello all, >>> >>> I've installed 389 to replace an ancient server that is on its last >>> legs. I got everything configured and working, until just now. I >>> generated and signed ssl keys to use ldaps, and it seemed to accept >>> everything. It told me to restart the service, which it wouldn't >>> allow me to do from the console. From the command line `service >>> dirsrv restart` gave me an error I can't figure out. The error is: >>> >>> <?ae=PreFormAction&a=Forward&t=IPM.Note&id=RgAAAAAddcPi7ODVRL%2bRKLFJpZ86BwCjUgqOSZifQqfpcvM7EMjGAAAAkkLWAACjUgqOSZifQqfpcvM7EMjGAAAO0Wg%2fAAAJ&pspid=_1316456764395_268663948#> >>> >>> [root@ceto2 ~]# service dirsrv start >>> Starting dirsrv: >>> ceto2...[19/Sep/2011:14:07:19 -0400] - SSL alert: Security >>> Initialization: Unable to authenticate (Netscape Portable Runtime >>> error -8192 - An I/O error occurred during security authorization.) >>> [19/Sep/2011:14:07:19 -0400] - ERROR: SSL Initialization Failed. >>> [FAILED] >>> *** Warning: 1 instance(s) failed to start >>> >>> >>> I haven't been able to find anything on google to help me solve >>> this. Any idea what is going wrong? >> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/… >> >>> >>> >>> Thank you, >>> Chris >>> >>> >>> -- >>> 389 users mailing list >>> 389-users(a)lists.fedoraproject.org >>> https://admin.fedoraproject.org/mailman/listinfo/389-users >> >>

2 1

memberOf plugin case
by Vasil Mikhalenya 20 Sep '11

20 Sep '11

Hi all, memberOf plugin changes case of it attrs. I have to specify about 4 variants in Cisco ASA ldap map to get auth work, like memberOf: CN=VPN-users,ou=People,dc=mydoamin memberOf: cn=VPN-users,ou=People,dc=mydoamin memberOf: cn=vpn-users,ou=people,dc=mydoamin memberOf: cn=VPN-users,ou=people,dc=mydoamin Is there any workaround? -- Best regards, Vasil Mikhalenya

3 3

Will administrator set passwords expire ?
by Svein Otto Solem 20 Sep '11

20 Sep '11

When setting "passwordMustChange" to on and resetting a users password as an administrator, the users passwordExpirationTime will be set to 19700101000000Z. The user will then be prompted for a new password at first login. It seems that 19700101000000Z in passwordExpirationTime indicate that the user must change his password at next use. How do I set that the user must change his password at first use, but if "first use" is after a year since adminstrator reset the password, the users password should have expired and been set to unusable ? Regards Svein Otto Solem

2 1

Replication questions.
by Reinhard Nappert 19 Sep '11

19 Sep '11

Hi, I have a multi-master setup with three masters. All of them are running 1.2.8.2. I had created and deleted the replication environment at least 3 times. The current setup looks like the following. Svr A has replication id 1, Srv B has the replication id 3 and Srv C has the id 4. The replication seems to work. When I look into the dse.ldif files, I see the following: Srv A: dn: cn=replica,cn=o\3base,cn=mapping tree,cn=config nsDS5ReplicaRoot: o=base nsDS5ReplicaId: 1 nsDS5Flags: 1 nsDS5ReplicaType: 3 objectClass: top objectClass: nsDS5Replica cn: replica ... nsDS5ReplicaReferral: ldap://SrvB:389/o=base nsDS5ReplicaReferral: ldap://SrvC:389/o=base numSubordinates: 2 dn: cn=SrvA2SrvB,cn=replica,cn=o\3base,cn=mapping tree,cn=config objectClass: top objectClass: nsDS5ReplicationAgreement ... nsDS5ReplicaRoot: o=base nsds50ruv: {replicageneration} 4e5ab509000000010000 nsds50ruv: {replica 3 ldap://SrvB:389} 4e775b74000000030000 4e77634c00000003 0000 nsds50ruv: {replica 4 ldap://SrvC:389} 4e77621d000000040000 4e77634900000 0040000 nsds50ruv: {replica 1 ldap://SrvA:389} 4e5ab517000000010000 4e77633d0000000 10000 nsds50ruv: {replica 2 ldap://SrvC:389} 4e775c9c000000020000 4e775e4c00000 0020000 nsruvReplicaLastModified: {replica 3 ldap://SrvB:389} 00000000 nsruvReplicaLastModified: {replica 4 ldap://SrvC:389} 00000000 nsruvReplicaLastModified: {replica 1 ldap://SrvA389} 00000000 nsruvReplicaLastModified: {replica 2 ldap://SrvC:389} 00000000 dn: cn=SrvA2SrvC,cn=replica,cn=o\3DUMC,cn=mapping tree,cn=config ... nsds50ruv: {replicageneration} 4e5ab509000000010000 nsds50ruv: {replica 4 ldap://SrvC:389} 4e77621d000000040000 4e77634900000 0040000 nsds50ruv: {replica 3 ldap://SrvB:389} 4e775b74000000030000 4e77634c00000003 0000 nsds50ruv: {replica 1 ldap://SrvA:389} 4e5ab517000000010000 4e77634e0000000 10000 nsds50ruv: {replica 2 ldap://SrvC:389} 4e775c9c000000020000 4e775e4c00000 0020000 nsruvReplicaLastModified: {replica 4 ldap://SrvC:389} 00000000 nsruvReplicaLastModified: {replica 3 ldap://SrvB:389} 00000000 nsruvReplicaLastModified: {replica 1 ldap://SrvA:389} 00000000 nsruvReplicaLastModified: {replica 2 ldap://SrvC:389} 00000000 I did expect that the replicageneration is equal for all of the agreements (not only locally but also for the others). When, I look at SrvB and SrvC, I do not seen any replicageneration: No nsds50ruv and nsruvReplicaLastModified values! Srv B: dn: cn=replica,cn=o\3base,cn=mapping tree,cn=config nsDS5ReplicaRoot: o=base nsDS5ReplicaId: 2 nsDS5Flags: 1 nsDS5ReplicaType: 3 objectClass: top objectClass: nsDS5Replica cn: replica ... nsDS5ReplicaReferral: ldap://SrvA:389/o=base nsDS5ReplicaReferral: ldap://SrvC:389/o=base numSubordinates: 2 dn: cn=SrvB2SrvA,cn=replica,cn=o\3base,cn=mapping tree,cn=config objectClass: top objectClass: nsDS5ReplicationAgreement ... nsDS5ReplicaRoot: o=base dn: cn=SrvB2SrvC,cn=replica,cn=o\3DUMC,cn=mapping tree,cn=config ... Srv3 entries look like: Srv C: dn: cn=replica,cn=o\3base,cn=mapping tree,cn=config nsDS5ReplicaRoot: o=base nsDS5ReplicaId: 3 nsDS5Flags: 1 nsDS5ReplicaType: 3 objectClass: top objectClass: nsDS5Replica cn: replica ... nsDS5ReplicaReferral: ldap://SrvB:389/o=base nsDS5ReplicaReferral: ldap://SrvA:389/o=base numSubordinates: 2 dn: cn=SrvC2SrvA,cn=replica,cn=o\3base,cn=mapping tree,cn=config objectClass: top objectClass: nsDS5ReplicationAgreement ... nsDS5ReplicaRoot: o=base dn: cn=SrvC2SrvB,cn=replica,cn=o\3DUMC,cn=mapping tree,cn=config ... So, my questions are: Why are the two attributes nsds50ruv and nsruvReplicaLastModified missing in the agreement objects on SrvB and SrvC. Secondly, why do I still see those old values for nsds50ruv and nsruvReplicaLastModified in SrvA. This looks strange to me. Even more confusing is that I see those attributes if I read the dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,o=base entry. Why are those nsds50ruv with old replicagenerations still there? At least the replicageneration is identical on all three boxes. SrvA: dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,o=base objectClass: top objectClass: nsTombstone objectClass: extensibleobject nsds50ruv: {replicageneration} 4e5ab509000000010000 nsds50ruv: {replica 4 ldap://SrvC:389} 4e77621d000000040000 4e7770f200000 0040000 nsds50ruv: {replica 3 ldap://SrvB:389} 4e775b74000000030000 4e77860b00000003 0000 nsds50ruv: {replica 1 ldap://SrvA:389} 4e5ab517000000010000 4e77859d0000000 10000 nsds50ruv: {replica 2 ldap://SrvC:389} 4e775c9c000000020000 4e775e4c00000 0020000 o: umc nsruvReplicaLastModified: {replica 4 ldap://SrvC:389} 4e7770f1 nsruvReplicaLastModified: {replica 3 ldap://SrvB:389} 4e77860a nsruvReplicaLastModified: {replica 1 ldap://SrvA:389} 4e77859c nsruvReplicaLastModified: {replica 2 ldap://SrvC:389} 00000000 SrvB: dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,o=base objectClass: top objectClass: nsTombstone objectClass: extensibleobject nsds50ruv: {replicageneration} 4e5ab509000000010000 nsds50ruv: {replica 1 ldap://SrvA:389} 4e5ab517000000010000 4e77859d0000000 10000 nsds50ruv: {replica 4 ldap://SrvC:389} 4e77621d000000040000 4e7770f200000 0040000 nsds50ruv: {replica 2 ldap://SrvC:389} 4e775c9c000000020000 4e775e4c00000 0020000 nsds50ruv: {replica 3 ldap://SrvB:389} 4e775b74000000030000 4e77860b00000003 0000 o: umc nsruvReplicaLastModified: {replica 1 ldap://SrvA:389} 4e77859c nsruvReplicaLastModified: {replica 4 ldap://SrvC:389} 4e7770f1 nsruvReplicaLastModified: {replica 2 ldap://SrvC:389} 00000000 nsruvReplicaLastModified: {replica 3 ldap://SrvB:389} 4e778609 SrvC: dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,o=base objectClass: top objectClass: nsTombstone objectClass: extensibleobject nsds50ruv: {replicageneration} 4e5ab509000000010000 nsds50ruv: {replica 3 ldap://SrvB:389} 4e775b74000000030000 4e77860b00000003 0000 nsds50ruv: {replica 4 ldap://SrvC:389} 4e77621d000000040000 4e7770f200000 0040000 nsds50ruv: {replica 1 ldap://SrvA:389} 4e5ab517000000010000 4e77859d0000000 10000 nsds50ruv: {replica 2 ldap://SrvC:389} 4e775c9c000000020000 4e775e4c00000 0020000 o: umc nsruvReplicaLastModified: {replica 3 ldap://SrvB:389} 4e77860a nsruvReplicaLastModified: {replica 4 ldap://SrvC:389} 4e7770f1 nsruvReplicaLastModified: {replica 1 ldap://SrvA:389} 4e77859c nsruvReplicaLastModified: {replica 2 ldap://SrvC:389} 00000000

2 2

SSL Error on Startup
by Chris M. Ober 19 Sep '11

19 Sep '11

Hello all, I've installed 389 to replace an ancient server that is on its last legs. I got everything configured and working, until just now. I generated and signed ssl keys to use ldaps, and it seemed to accept everything. It told me to restart the service, which it wouldn't allow me to do from the console. From the command line `service dirsrv restart` gave me an error I can't figure out. The error is: [root@ceto2 ~]# service dirsrv start Starting dirsrv: ceto2...[19/Sep/2011:14:07:19 -0400] - SSL alert: Security Initialization: Unable to authenticate (Netscape Portable Runtime error -8192 - An I/O error occurred during security authorization.) [19/Sep/2011:14:07:19 -0400] - ERROR: SSL Initialization Failed. [FAILED] *** Warning: 1 instance(s) failed to start I haven't been able to find anything on google to help me solve this. Any idea what is going wrong? Thank you, Chris

2 1

ad nested objects sync
by Vasil Mikhalenya 16 Sep '11

16 Sep '11

hi all, can windows sync agreement replicate nested objects ? like cn=user1,ou=location1,ou=Root,dc=domain ? when i specify ou=Root,dc=domain in sync agreement - it replicates only objects under ou=Root,dc=domain itself like cn=user_in_root,ou=Root,dc=domain but neither cn=user1,ou=location1,ou=Root,dc=domain nor ou=location1,ou=Root,dc=domain Is it possible at all? thnx -- Best regards, Vasil Mikhalenya

4 3

can't install 389-ds-base 1.2.9.9 on RHEL 6.1
by Thang Nguyen 16 Sep '11

16 Sep '11

I can't seem to install 389-ds-base 1.2.9.9 on RHEL6.1 using yum. I follow the instructions from http://directory.fedoraproject.org/wiki/Download by 1. Download and copy epel-389-ds-base.repo to /etc/yum.reposd 2. rpm -Uvh epel-release-6-5.noarch.rpm When I run 'yum install 389-ds' which by default pointing to epel-389-ds-base repo. I get selinux-policy-base conflict: # yum install 389-ds Loaded plugins: rhnplugin Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package 389-ds.noarch 0:1.2.2-1.el6 will be installed --> Processing Dependency: 389-ds-console for package: 389-ds-1.2.2-1.el6.noarch --> Processing Dependency: 389-ds-console-doc for package: 389-ds-1.2.2-1.el6.noarch --> Processing Dependency: 389-admin-console-doc for package: 389-ds-1.2.2-1.el6.noarch --> Processing Dependency: 389-ds-base for package: 389-ds-1.2.2-1.el6.noarch --> Processing Dependency: 389-admin-console for package: 389-ds-1.2.2-1.el6.noarch --> Processing Dependency: 389-admin for package: 389-ds-1.2.2-1.el6.noarch --> Processing Dependency: 389-dsgw for package: 389-ds-1.2.2-1.el6.noarch --> Processing Dependency: 389-console for package: 389-ds-1.2.2-1.el6.noarch --> Running transaction check ---> Package 389-admin.x86_64 0:1.1.23-1.el6 will be installed --> Processing Dependency: libadminutil.so.0()(64bit) for package: 389-admin-1.1.23-1.el6.x86_64 --> Processing Dependency: libadmsslutil.so.0()(64bit) for package: 389-admin-1.1.23-1.el6.x86_64 ---> Package 389-admin-console.noarch 0:1.1.8-1.el6 will be installed ---> Package 389-admin-console-doc.noarch 0:1.1.8-1.el6 will be installed ---> Package 389-console.noarch 0:1.1.7-1.el6 will be installed ---> Package 389-ds-base.x86_64 0:1.2.8.3-1.el6 will be installed --> Processing Dependency: 389-ds-base-libs = 1.2.8.3-1.el6 for package: 389-ds-base-1.2.8.3-1.el6.x86_64 --> Processing Dependency: libslapd.so.0()(64bit) for package: 389-ds-base-1.2.8.3-1.el6.x86_64 ---> Package 389-ds-console.noarch 0:1.2.6-1.el6 will be installed ---> Package 389-ds-console-doc.noarch 0:1.2.6-1.el6 will be installed ---> Package 389-dsgw.x86_64 0:1.1.7-1.el6 will be installed --> Running transaction check ---> Package 389-adminutil.x86_64 0:1.1.14-2.el6 will be installed ---> Package 389-ds-base-libs.x86_64 0:1.2.8.3-1.el6 will be installed --> Processing Conflict: 389-ds-base-1.2.8.3-1.el6.x86_64 conflicts selinux-policy-base < 3.9.7-11 --> Finished Dependency Resolution Error: 389-ds-base conflicts with selinux-policy-targeted You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest It doesn't automatically install version 1.2.9.9 instead it tries to install version 1.2.8.3. I was able to install 389-ds-base 1.2.9.0 when pointing to "epel-testing-389-ds-base" I can only install 389-ds-base-1.2.9.0 and can't seem to upgrade to 1.2.9.9. Anyone know why I can't install 389-ds-base 1.2.9.9 using yum even though the rpm is in the epel-389-ds-base repository? thank you. --thang --

2 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users September 2011