389-users July 2006

389-users@lists.fedoraproject.org

59 participants
75 discussions

Re: [Fedora-directory-users] Fedora DS 1.0.2 Multiple Master SSL replication: empty bind DN...
by Kevin McCarthy 05 Jul '06

05 Jul '06

Thanks again Richard, My attempt to determine why the bind DN remains as "" have still not located the cause - though I guess that is due to this being my first usage and I have merely missed the obvious! > To ensure that you are doing client cert auth, you can examine the access > log on the replication consumer - look for the connection and BIND from > the supplier. If you're not sure what you're looking at, just post the > relevant excerpts here. I can see from the bind result that the initial "dn" is still the required: "cn=nema2,ou=EDS,o=teligent,dc=co,c=uk" ..but the BIND dn remains as "", with the method as "sasl"? Consumer Access log file extract: [03/Jul/2006:10:24:11 +0100] conn=11 fd=67 slot=67 SSL connection from 192.168.27.15 to 192.168.144.61 [03/Jul/2006:10:24:11 +0100] conn=11 SSL 256-bit AES; client CN=nema2,OU=EDS,O=teligent,DC=co,C=uk; issuer CN=CAcertnema2 [03/Jul/2006:10:24:11 +0100] conn=11 SSL client bound as cn=nema2,ou=EDS,o=teligent,dc=co,c=uk [03/Jul/2006:10:24:11 +0100] conn=11 op=0 BIND dn="" method=sasl version=3 mech=EXTERNAL [03/Jul/2006:10:24:11 +0100] conn=11 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=nema2,ou=EDS,o=teligent,dc=co,c=uk" [03/Jul/2006:10:24:11 +0100] conn=11 op=1 SRCH base="" scope=0 filter="(objectClass=*)" attrs="supportedControl supportedExtension" [03/Jul/2006:10:24:11 +0100] conn=11 op=1 RESULT err=0 tag=101 nentries=1 etime=0 [03/Jul/2006:10:24:11 +0100] conn=11 op=2 SRCH base="" scope=0 filter="(objectClass=*)" attrs="supportedControl supportedExtension" [03/Jul/2006:10:24:11 +0100] conn=11 op=2 RESULT err=0 tag=101 nentries=1 etime=0 [03/Jul/2006:10:24:11 +0100] conn=11 op=3 EXT oid="2.16.840.1.113730.3.5.3" name="Netscape Replication Start Session" [03/Jul/2006:10:24:11 +0100] conn=11 op=3 RESULT err=0 tag=120 nentries=0 etime=0 [03/Jul/2006:10:24:12 +0100] conn=11 op=4 EXT oid="2.16.840.1.113730.3.5.3" name="Netscape Replication Start Session" [03/Jul/2006:10:24:12 +0100] conn=11 op=4 RESULT err=0 tag=120 nentries=0 etime=0 [03/Jul/2006:10:24:15 +0100] conn=11 op=5 EXT oid="2.16.840.1.113730.3.5.3" name="Netscape Replication Start Session" [03/Jul/2006:10:24:15 +0100] conn=11 op=5 RESULT err=0 tag=120 nentries=0 etime=0 [03/Jul/2006:10:24:19 +0100] conn=11 op=6 EXT oid="2.16.840.1.113730.3.5.3" name="Netscape Replication Start Session" [03/Jul/2006:10:24:19 +0100] conn=11 op=6 RESULT err=0 tag=120 nentries=0 etime=0 [03/Jul/2006:10:24:28 +0100] conn=11 op=8 EXT oid="2.16.840.1.113730.3.5.3" name="Netscape Replication Start Session" [03/Jul/2006:10:24:28 +0100] conn=11 op=8 RESULT err=0 tag=120 nentries=0 etime=0 [03/Jul/2006:10:24:34 +0100] conn=10 op=4 UNBIND [03/Jul/2006:10:24:34 +0100] conn=10 op=4 fd=64 closed - U1 [03/Jul/2006:10:24:46 +0100] conn=11 op=10 EXT oid="2.16.840.1.113730.3.5.3" name="Netscape Replication Start Session" [03/Jul/2006:10:24:46 +0100] conn=11 op=10 RESULT err=0 tag=120 nentries=0 etime=0 [03/Jul/2006:10:25:08 +0100] conn=11 op=12 UNBIND [03/Jul/2006:10:25:08 +0100] conn=11 op=12 fd=67 closed - U1 Consumer Error log file extract: [03/Jul/2006:10:24:11 +0100] NSMMReplicationPlugin - conn=11 op=3 replica="ou=EDS,o=teligent,dc= co,c=uk": Unable to acquire replica: error: permission denied [03/Jul/2006:10:24:12 +0100] NSMMReplicationPlugin - conn=11 op=4 replica="ou=EDS,o=teligent,dc=co,c=uk": Unable to acquire replica: error: permission denied [03/Jul/2006:10:24:15 +0100] NSMMReplicationPlugin - conn=11 op=5 replica="ou=EDS,o=teligent,dc=co,c=uk": Unable to acquire replica: error: permission denied [03/Jul/2006:10:24:19 +0100] NSMMReplicationPlugin - conn=11 op=6 replica="ou=EDS,o=teligent,dc=co,c=uk": Unable to acquire replica: error: permission denied [03/Jul/2006:10:24:28 +0100] NSMMReplicationPlugin - conn=11 op=8 replica="ou=EDS,o=teligent,dc=co,c=uk": Unable to acquire replica: error: permission denied [03/Jul/2006:10:24:46 +0100] NSMMReplicationPlugin - conn=11 op=10 replica="ou=EDS,o=teligent,dc=co,c=uk": Unable to acquire replica: error: permission denied [03/Jul/2006:10:24:50 +0100] NSMMReplicationPlugin - agmt="cn=EDS from Server 1" (nema2:636): Unable to acquire replica: permission denied. The bind dn "" does not have permission to supply replication updates to the replica. Will retry later. Regards and thanks again, Kevin From: Richard Megginson <rmeggins(a)redhat.com> Subject: Re: [Fedora-directory-users] Fedora DS 1.0.2 Multiple Master SSL replication: empty bind DN... To: "General discussion list for the Fedora Directory server project." <fedora-directory-users(a)redhat.com> Message-ID: <44A51838.4040409(a)redhat.com> Content-Type: text/plain; charset="windows-1252" Kevin McCarthy wrote: > > Richard, thank you for your response! > > hopefully whatever configuration mistake I made to cause a NULL bind > DN will soon come to light > > > Dear List Members, > > > > > > Release: *fedora-ds-1.0.2-1.RHEL3.i386.opt.rpm* > > > > > > A typical replication error log entry now follows (seen repeatedly at > > > both fedora DS servers): > > > > > > [28/Jun/2006:18:29:21 +0100] NSMMReplicationPlugin - agmt="cn=EDS from > > > server 2" (ukstatlap:636): Unable to acquire replica: permission > > > denied. The *bind dn ""* does not have permission to supply > > > replication updates to the replica. Will retry later. > > > > > > Believe me, I have been investigating this one for 2 or 3 days now > > > (having just switched from OpenLDAP, since multiple master replication > > > is required) before sending this submission, just in case I missed a > > > configuration item or work-around, but unfortunately no luck (so far). > > > > > > The only reference I can find for SSL Client Authentication based > > > Multiple Master replication (2 Linux RHEL 3 servers being used) that > > > supplies empty DNs, is the Windows specific entry (whose work-around I > > > tried anyway, but without success)_ > > > > > > Unable to acquire replica: permission denied. The bind dn "" does not > > > have permission to supply replication updates to the replica. Will > > > retry later. > > > To workaround the problem, after you modify and save the replication > > > schedule of an agreement, refresh the console, reconfigure the > > > connection settings (to SSL client authentication) for the agreement, > > > and save your changes. > > > > > > http://www.redhat.com/docs/manuals/dir-server/release-notes/ds611relno > > > tes.html > > > > > > The mutual _Current Supplier DNs_ are indeed set (cn=Replication > > > Manager,cn=replication,cn=config) and the corresponding directory > > > entries do exist. > > > > > > The respective server certificates and CA certificates are installed, > > > with Subject DN entries loaded. > > > > > What are the SubjectDNs in the server certificates? > > CN=<SERVERNAME>,OU=EDS,O=teligent,DC=co,C=uk > > where <SERVERNAME> is the respective server name of the replicating > servers e.g. nema2 rather than a full domain name. > I think this is ok, as long as your DNS (/etc/resolv.conf) configuration can resolve nema2. > > The following will hopefully also be relevant: > > 1) The tree being replicated is OU=EDS,O=Teligent,DC=co,C=uk i.e. > the Subject DN is within the replicated tree. > > 2) certutil was used to generate the server and CA certificates. > Surprisingly (to me at least) the CA certificate was then listed in > the "Server Certs" panel on the Directory Server Manage Certificates > panel. > > 3) I loaded the ascii version of the other servers CA Certificate > directly into the CA Certs panel. > > 4) All CA certificates have both the accept and make connection trusts > ticked. > > > I do _not_ have Legacy Consumer enabled. > > > > > You don't need it. > > > > > > CertMapping is also defined (though with a NULL DN being supplied, I > > > guess that will not be kicking in just yet, though there are entries > > > for the exact subject DN anyway.) > > > > > You might want to post your certmap.conf and see here - > http://directory.fedora.redhat.com/wiki/Howto:CertMapping > > I must admit that since the Bind DN was NULL I had not realized that > certmapping would actually take affect. > If you are using client cert based auth (and not just username/password auth with SSL) then certmapping will be used. To ensure that you are doing client cert auth, you can examine the access log on the replication consumer - look for the connection and BIND from the supplier. If you're not sure what you're looking at, just post the relevant excerpts here. ...log file extract at the head. > > I ensured that the exact subject DN of the server certificates > corresponded to an actual directory entry (with the respective > servers user certificate loaded), which I had thought would be > matched without the need for a certmap configuration via the original > default option, but I tried one anyway > > certmap nema ou=EDS,o=teligent,dc=co,c=uk > I think this DN should correspond to the issuerDN (i.e. the subjectDN of your CA cert). But I don't think it's used for cert mapping. > > nema:FilterComps cn > This means you must have one and only one entry called cn=nema2, ....., o=teligent,dc=co,c=uk somewhere in your tree. ...indeed, just the one. > > nema:verifycert off > > certmap default default > > indeed one server still runs with the default certmap configuration > to see if it made any difference, but both servers receive a NULL bind > DN . > This leads me to believe it is not doing client cert auth. Also check the errors log for your supplier and consumer. ...extracts at the head. > > > When using simple authentication, with or without SSL, all is well > > > (although replication did require both servers to Initialize the > > > Consumer, I thought that only one was required e.g. ID 1 initializing > > > ID 2, but ID 2 then needed to initialize ID 1 before successful 2-way > > > replication was achieved). > > > > > That's odd. You should only need to initialize once one way. > > indeed, but I guess that it can not do any harm, as the secondary > server will not actually need to supply any further updates back to > the primary server and it does at least make the mutual replication > work for me until the certificates took their toll

2 2

[Fedora-directory-users] RPM/SRPM issues and old RHEL
by Oliver Hookins 04 Jul '06

04 Jul '06

Hi there, I'm trying to get started testing out Fedora Directory Server with the goal of replacing our OpenLDAP infrastructure. Most of our servers are RHEL3/4 so there are no big issues there since there are already prepackaged binary RPMS for those platforms. But we do have two RHEL2.1 server which we will definitely need packages for in order to do any migration to FDS. Upgrading these servers to RHEL3/4 is not an option. Looking at the spec file of the SRPM from RHEL3 it seems like dependencies won't be a problem, the spec file itself is a mess and doesn't come close to building everything (which I understand is a work in progress). So my questions are: has anyone got FDS running well on RHEL2.1 (either by compiling directly from source, shoehorning the RPM from RHEL3 or building the RPM from the SRPM)? Has anyone written their own spec file from scratch to build FDS in its entirety from sources? I also wanted to change the installation prefix from /opt so getting a working and complete spec file would be very desirable. -- Regards, Oliver Hookins Anchor Systems

1 0

[Fedora-directory-users] packaging problems.
by Hai Zaar 04 Jul '06

04 Jul '06

Dear, list, I know that you are currently working on making FDS to be more FHS friendly, but anyway, I've got the problem with the current packaging. I'm building FDS-1.0.2 using dsbuild. When build finishes, ds/ldapserver/work dir contains file allLinux2.6_x86_glibc_PTH_OPT.OBJ.tar.gz, that, AFAIK, should be unzipped and then ./setup should be run. The problem is, not all of the files are packaged: cd ds/ldapserver/work mkdir /tmp/fds tar zxvf allLinux2.6_x86_glibc_PTH_OPT.OBJ.tar.gz -C /tmp/fds cd /tmp/fds && ls -la admin base dsktune setup setup.inf slapd tmp 'svrcore' dir is missing, setup complains about it and fails. On the onther hand, produced rpm is fine, and running setup from ds/servercore/work/pkg dir (that looks like origin for the tarball) succeeds. Distro: LFS-6.1+kernel-2.6.15. P.S. I'm not on the list, so please CC me. -- Zaar

2 1

Re: [Fedora-directory-users] [Fwd: migrate sendmail with fds]
by Mike Jackson 04 Jul '06

04 Jul '06

basile <basile.mathieu(a)siris.sorbonne.fr> kirjoitti: > i have this errors in logs > > Jul 4 13:08:22 sorbon sm-mta[21182]: [ID 293258 mail.error] libsldap: > Status: 91 Mesg: Error 0 > Jul 4 13:08:22 sorbon last message repeated 1 time > Jul 4 13:08:22 xxx sm-mta[21182]: [ID 293258 mail.error] libsldap: > Status: 7 Mesg: Session error no available conn. Hi, For FDS support, post FDS logs to the FDS list. We understand those. For sendmail support, post sendmail logs to the sendmail list. They understand those. -- mike

1 0

[Fedora-directory-users] sendmail and fds
by basile 04 Jul '06

04 Jul '06

hi our mail users are now in a fedora directory it works fine except : i have this errors in logs Jul 4 13:08:22 sorbon sm-mta[21182]: [ID 293258 mail.error] libsldap: Status: 91 Mesg: Error 0 Jul 4 13:08:22 sorbon last message repeated 1 time Jul 4 13:08:22 xxx sm-mta[21182]: [ID 293258 mail.error] libsldap: Status: 7 Mesg: Session error no available conn. Jul 4 13:08:22 xxx sm-mta[21182]: [ID 293258 mail.error] libsldap: Status: 91 Mesg: No such file or directory Jul 4 13:08:22 xxx last message repeated 1 time Jul 4 13:08:22 xxx sm-mta[21182]: [ID 293258 mail.error] libsldap: Status: 7 Mesg: Session error no available conn. and i have a thunderbird on xp which cannot send mail ( xp , thunderbird 1.5.0.4 ) but with another instance of thunderbird ( same version on xp all works fine ) that is very strange if someone have any idea or experience , because we are now in production thanks basile

1 0

[Fedora-directory-users] [Fwd: migrate sendmail with fds]
by basile 04 Jul '06

04 Jul '06

1 0

[Fedora-directory-users] ldapadd with Kerberos
by Andrey Ivanov 04 Jul '06

04 Jul '06

Hi, There is something I can't explain concerning the interaction of ldapadd & ldapsearch (from openldap) with FDS while using kerberos Here is what i do : 1. kinit User.Name ... 2. Verification with klist -ok, i have the kerberos ticket 3. Verification with ldapsearch works without any problem, giving all the necessary infos: ldapsearch -Y GSSAPI 'sn=toto*' SASL/GSSAPI authentication started SASL username: User.Name@KRB-FDS SASL SSF: 56 SASL installing layers # extended LDIF # # LDAPv3 # base <> with scope sub # filter: sn=aic* # requesting: userPassword .... infos ... 4. The problem appears when i try to use ldapadd/ldapmodify with some ldif files (apparently, these files should be larger than some critical value to produce the error) Her is an example of such an ldif test.ldif: dn: cn=Gilles Martin,ou=CMLS,ou=Laboratoires,o=Some Organization,dc=fds-example,dc=domain,dc=com givenName: Gilles sn: Martin telephoneNumber: 00 00 loginShell: /bin/bash departmentNumber: LAB CMLS physicalDeliveryOfficeName: 402:10-02 uidNumber: 3090 gidNumber: 3000 mail: gilles.martin(a)some-organization.domain.com displayName: Gilles Martin (M.) uid: Gilles.Martin objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson objectClass: posixAccount gecos: Gilles Martin,LAB CMLS ,PERSONNEL DE RECHERCHE cn: Gilles Martin title: PERSONNEL DE RECHERCHE homeDirectory: /home/CMLS/Gilles.Martin userPassword: {clear}Gilles.Martin When i try to add this entry using ldapadd or ldapmodify with kerberos : [root@workstation ~]# ldapadd -Y GSSAPI -v -f test.ldif -H ldap://fds-example.domain.com ldap_initialize( ldap://fds-example.domain.com ) SASL/GSSAPI authentication started SASL username: User.Name@KRB-FDS SASL SSF: 56 SASL installing layers add givenName: Gilles add sn: Martin add telephoneNumber: 00 00 add loginShell: /bin/bash add departmentNumber: LAB CMLS add physicalDeliveryOfficeName: 402:10-02 add uidNumber: 3090 add gidNumber: 3000 add mail: gilles.martin(a)some-organization.domain.com add displayName: Gilles Martin (M.) add uid: Gilles.Martin add objectClass: top person organizationalPerson inetorgperson posixAccount add gecos: Gilles Martin,LAB CMLS ,PERSONNEL DE RECHERCHE add cn: Gilles Martin add title: PERSONNEL DE RECHERCHE add homeDirectory: /home/CMLS/Gilles.Martin add userPassword: {clear}Gilles.Martin adding new entry " cn=Gilles Martin,ou=CMLS,ou=Laboratoires,o=Some Organization,dc=fds-example,dc=domain,dc=com" modify complete ldap_add: Protocol error (2) additional info: decoding error 5. Adding the same entry using simple authentification (plain text or SSL/TLS) is possible without any problem. The only way of using kerberos and ldapadd/ldapmodify is adding the option "-O maxssf=0" : ldapadd -Y GSSAPI -O maxssf=0 -v -f test.ldif -H ldap://fds-example.domain.com With this command line, the ldapadd adds the entry with success. Can someone explain me why ldapsearch works without problem and ldapadd needs an additional option (this option forbids the double encryption kerberos+ssl if i understand correctly)? Thank you! Andrey Ivanov tel +33-(0)1-69-33-99-24 fax +33-(0)1-69-33-99-55 Direction des Systemes d'Information Ecole Polytechnique 91128 Palaiseau CEDEX France

2 2

Re: [Fedora-directory-users] New filesystem layout for directory server and admin server files
by Mike Jackson 03 Jul '06

03 Jul '06

Richard Megginson <rmeggins(a)redhat.com> kirjoitti: > But there are a lot of people for whom this is a problem. For example, we ship 3 versions of NSPR, NSS, LDAP C SDK, ICU, etc. that are private to RHDS. In > addition, we ship our own versions of bdb, cyrus sasl, netsnmp, and other software that are in most cases identical to what is already included or available for > the OS. To remedy this situation, we are going to switch FDS/RHDS to build and run against those OS libraries, and to not include them in the DS package. > So we are already committed to not including all of the dependencies in an isolated manner. This change will affect the linux and solaris ports. I'm not sure > how it will affect the HP-UX port. HP already takes our software and repackages it in the HP-UX depot format. Argh. This is also a strength of the FDS software, not a problem or weakness. The package always works because it always includes exactly what it needs. Using OS libraries can cause all sorts of unpredictable problems. IMO, removing the included dependencies is also a bad idea. My list of reasons on the plus side for FDS/RHDS vs OL are being reduced, strangely. One would have thought that the package could only get better, not worse. Consider Symas, how they compile and deliver CDS, which is intended to be a supportable product for commercial customers. They put the entire chain of dependencies and software into /opt/symas, so CDS doesn't break everytime somebody installs a new buggy OS level bdb or OL library on the machine. There's a good reason for that; it is then a supportable product. Trusting the proper operation of your critically important software to the random quality and version numbers of system libraries is not wise. BTW, when is the autoconf support coming? The patch was submitted quite a while ago, IIRC... BR, -- mike

2 1

[Fedora-directory-users] Retrieving User Password From Fedora Directory Server
by Hariharan R 03 Jul '06

03 Jul '06

Dear all, I am using FDS 7.2 on FC3 for my development. I am storing userprofile along with user password to the FDS database (BDB). When i look the user profile in console i seen that the password value has been encrypted. Fine. If i do 'ldapsearch' , it doesn't returns the 'userpassword' attribute and its value. How i can get the userPassword attribute and it's value using LDAP search command. Is there is any way to convert the encrypted password to plain text one. I am in an urgent need , so please any one guide me. Thanks in advance. --- Regards, Hariharan.R

3 2

Re: [Fedora-directory-users] New filesystem layout for directory server and admin server files
by Mike Jackson 03 Jul '06

03 Jul '06

Les Mikesell <lesmikesell(a)gmail.com> kirjoitti: > > > Moving locations is always traumatic. Personally I like > stand-alone packages that aren't going to be installed on > every machine you have to live under /opt, but if it is > ever going to move, do it soon to minimize the number of > people who will be affected by already having it installed > in the wrong place. As FDS is the basis of a commercial product, RHDS, let's talk about the commercial aspect for a moment. Things which are changed in FDS will eventually go into RHDS. There are already folks with lots of RHDS servers deployed or being deployed into commercial environments. We are already talking about a large number of installations. One of the reasons why I argue so strongly to use RHDS in commercial environments is that it includes all dependencies in an isolated manner, and doesn't change interfaces often. IMO, those features make it currently the most suitable server for commercial usage. To the people who are complaining about the filesystem layout, understand that FDS is the basis for a complex and _stable_ commercial product. You don't just start fiddling with it if it ain't broken... Moving to FHS is certainly not going to increase sales or product stability, although it might make a few systems engineers who have never heard of RFC 2251 happy for a day or two. Or am I wrong to assume that these type of proposed changes would also make it into RHDS? -- mike

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users July 2006