(ITS#5065) out of order ctxcsn from old entryCSN
by donn＠u.washington.edu
Full_Name: Donn Cave
Version: 2.4.4
OS: RH Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (128.95.135.150)
Old entryCSN values imported into the data from another server, can crash
replicas.
In loop at top of syncrepl_updateCookie, replica encounters a syncCookie whose
value is less than its matching si_cookieState->cs_val. This breaks out of the
inner loop, and the outer loop, without copying anything into `first', so
slap_queue_csn crashes on the null csn. Both are element 0 of their respective
arrays. I assume it is no surprise that syncCookie takes its value from an
entryCSN attribute.
To duplicate, add an entry with an explicit entryCSN, with value less than the
current contextCSN. In my case, the entryCSN is of the format without the
`decimal fraction' field, but I doubt that matters.
I don't want to say OpenLDAP needs to support this, but maybe it would be better
to catch the problem in the master, than crash the replicas.
15 years, 8 months
Re: (ITS#5058) LDAP/Egroupware addressbook issue
by ando＠sys-net.it
chandra(a)sentienthealth.com wrote:
> Jul 23 13:39:35 shs slapd[20739]: SRCH "o=sen,dc=domainname,dc=com" 2 0
> Jul 23 13:39:35 shs slapd[20739]: 300 0 0
> Jul 23 13:39:35 shs slapd[20739]: begin get_filter
> Jul 23 13:39:35 shs slapd[20739]: OR
> Jul 23 13:39:35 shs slapd[20739]: begin get_filter_list
> Jul 23 13:39:35 shs slapd[20739]: begin get_filter
> Jul 23 13:39:35 shs slapd[20739]: EQUALITY
>
> Its stop here and hang and we have to restart ldap to make it work.
Seems to be related to filter parsing, but we don't get any logging
about the filter, and there's too little information to detect what's
the issue. You might add "packets" to the log level to see what
actually gets sent along with the request (beware that log level will be
very verbose, then), and post the output concerning the sole initiation
of the search request up to the hang.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 8 months
Re: (ITS#5062) back-sql with non-integer keycol's
by ando＠sys-net.it
lehner(a)webdynamite.com wrote:
> Full_Name: GeorgLehner
> Version: 2.3.30
> OS: Debian Gnu/Linux i386
> URL:
> Submission from: (NULL) (83.64.52.210)
>
>
> The slapd-sql(5) man page states:
>
> '- the key must be an integer. ...
> If anyone needs support for different types for keys
> - he may want to write a patch,'
>
> I am configuring back-sql as a frontend to the SugarCRM Customer Database.
> SugarCRM uses UUID's as keys:
>
> http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html#funct...
>
> so I want (to write) a patch. Can you please give me some hint where
> to start?
Actually, I think this has been already implemented (although possibly
experimental). You need to rebuild back-sql after manually defining
BACKSQL_ARBITRARY_KEY in <servers/slapd/back-sql/back-sql.h>. In that
case, however, all keys need to be strings. Please test and report.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 8 months
Re: (ITS#5062) back-sql with non-integer keycol's
by ando＠sys-net.it
lehner(a)webdynamite.com wrote:
> Full_Name: GeorgLehner
> Version: 2.3.30
> OS: Debian Gnu/Linux i386
> URL:
> Submission from: (NULL) (83.64.52.210)
>
>
> The slapd-sql(5) man page states:
>
> '- the key must be an integer. ...
> If anyone needs support for different types for keys
> - he may want to write a patch,'
>
> I am configuring back-sql as a frontend to the SugarCRM Customer Database.
> SugarCRM uses UUID's as keys:
>
> http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html#funct...
>
> so I want (to write) a patch. Can you please give me some hint where
> to start?
Actually, I think this has been already implemented (although possibly
experimental). You need to rebuild back-sql after manually defining
BACKSQL_ARBITRARY_KEY in <servers/slapd/back-sql/back-sql.h>. In that
case, however, all keys need to be strings. Please test and report.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 8 months
Re: (ITS#5064) Issues with openldap 2.2 (Error 34 Invalid DN syntax )
by ando＠sys-net.it
Pierre-Emmanuel Brinette wrote:
>
> > 1) both 2.0 and 2.2 are ancient. OpenLDAP 2.3 is mature, and 2.4 is
> > about to exit beta stage. Unless the problem is related to a real
> > software bug, and it persists either in HEAD/2.4 or in 2.3 code, this
> > ITS will be closed.
>
> Currently, I've no mean to use an openldap 2.3 unless exists an RPM
> update package for RHEL 4 (or CentOS).
>
> But the problem is that the request like
> "attribute=a_string=another_string,..." worked fine with openldap 2.0
> but not with openldap 2.2.
I'm not sure I made the point: both 2.0 and 2.2 are ancient.
The fact that something worked with 2.0 doesn't prove anything, as that
software was very poor in validating things, and very forgiving with
respect to syntax and specs compliance errors (which I value as a
defect, while others might see it as a "feature").
The fact that something does no longer work with 2.2 while it worked
with 2.0 is a pity, but it doesn't mean anything as well. Either (a)
2.0 was wrong, and 2.2 correctly detects an error, or (b) 2.0 was right,
and 2.2 introduced a bug, or (c) both were plainly wrong. In any case
2.2 is historical and no longer supported, so in cases (b) and (c) no
one on the OpenLDAP side is going to fix 2.2. You could try asking the
distributor of the packages you're using (YMMV).
What would make things totally different is the persistence of a problem
in 2.3 and 2.4. But the very existence of a problem has to be proven
yet. If you look at my analysis with dntest, you'll see that your DN
'GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds-vo-name=local,o=grid'
is split in
ldap_rdn2str() =
"GlueVOViewLocalID=/VO\3Dswetest/GROUP\3D/swetest/ROLE\
3Dswadmin"
ldap_rdn2str() =
"GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge
-swetest"
ldap_rdn2str() = "mds-vo-name=UPorto"
ldap_rdn2str() = "mds-vo-name=local"
ldap_rdn2str() = "o=grid"
Is this what you'd expect? Note that in GlueVOViewLocalID embedded '='
are expanded as '\3D'. If any of the commas/equals in the DN are
actually parts of the IA5 string, you'll need to escape them to have
them parsed as expected.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 8 months
Re: (ITS#5064) Issues with openldap 2.2 (Error 34 Invalid DN syntax )
by pbrinette＠cc.in2p3.fr
> 1) both 2.0 and 2.2 are ancient. OpenLDAP 2.3 is mature, and 2.4 is
> about to exit beta stage. Unless the problem is related to a real
> software bug, and it persists either in HEAD/2.4 or in 2.3 code, this
> ITS will be closed.
Currently, I've no mean to use an openldap 2.3 unless exists an RPM
update package for RHEL 4 (or CentOS).
But the problem is that the request like
"attribute=a_string=another_string,..." worked fine with openldap 2.0
but not with openldap 2.2.
[..CUT..]
>
> 2) were GlueCEUniqueID and mds-vo-name declared anywhere? There seems
> to be nothing wrong with your DN per se; in fact, dntest yields
[..CUT..]
>
> But apparently some attribute declarations are missing; in fact, slapdn
> (after declaring GlueVOViewLocalID as indicated above) yields
>
> slapdn -f testrun/slapd.1.conf
> 'GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds-vo-name=local,o=grid'
>
> DN:
> <GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds-vo-name=local,o=grid>
> check failed 21 (Invalid syntax)
>
> where the failure refers exactly to the fact that GlueCEUniqueID was not
> declared.
>
If you want some informations regarding the schema used, you will find
here :
http://glueschema.forge.cnaf.infn.it/Spec/V13
And you ca download the schema here :
https://forge.cnaf.infn.it/plugins/scmsvn/viewcvs.php/v_1_3/mapping/ldap/...
if you want to import some datas with slapadd, you could find here a
reference ldiff file :
ldap://cclcgtopbdii01.in2p3.fr:2170/
root : o=grid
Regards.
Pierre-Emmanuel
--
Pierre-Emmanuel Brinette
Grid computing - EGEE/LCG team
IN2P3/CNRS Computing Centre - Lyon (France)
27 bd du 11 novembre, F-69622 Villeurbanne cedex
pbrinette(a)cc.in2p3.fr - Tél. : +33 (0) 4 78 93 08 80
15 years, 8 months
Re: (ITS#5064) Issues with openldap 2.2 (Error 34 Invalid DN syntax )
by ando＠sys-net.it
pbrinette(a)cc.in2p3.fr wrote:
> Openldap is used as information provider in a GRID middleware project
> (http://www.eu-egee.org/). This information provider is known as BDII.
>
> The information about grid nodes are published via openldap.
>
> Until now, the platform supported by the middleware is Scientific Linux 3 (a
> RHEL 3 clone like CentOS). The openldap version provided with this system is
> openldap 2.0.27.
>
> We updated our systems with Scientific Linux 4.4 (RHEL 4.4) for new hardware
> support. The openldap version provided is now 2.2.13.
>
> When I put the new service in production, I find some issues with some
> attributes that disappears from the directory.
>
> In our openldap schema, we have an attribute declared like this:
>
> attributetype ( 1.3.6.1.4.1.8005.100.2.2.7.1
> NAME 'GlueVOViewLocalID'
> DESC 'Local ID for this VO view'
> EQUALITY caseIgnoreIA5Match
> SUBSTR caseIgnoreIA5SubstringsMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
> SINGLE-VALUE)
>
>
> This attribute may containt string like these:
>
> GlueVOViewLocalID=dteam
> GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,
>
> It seem that theses both sample strings are IA5 compliant.
>
> When I ask the openldap server with this request, Ive got different results
> regarding the openldap version :
>
> ------------ Openldap 2.0.27 -----------------------
>
> ldapsearch -x -P3 -H ldap://cclcgtopbdii01.in2p3.fr:2170 -b
> "GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds-vo-name=local,o=grid"
> version: 2
>
> #
> # filter: (objectclass=*)
> # requesting: ALL
> #
>
> # /VO=swetest/GROUP=/swetest/ROLE=swadmin, grid001.fc.up.pt:2119/jobmanager-l
> cgsge-swetest, UPorto, local, grid
> dn: GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,GlueCEUniqueID=g
> rid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds-vo-name
> =local,o=grid
> objectClass: GlueCETop
> objectClass: GlueVOView
> objectClass: GlueCEInfo
> objectClass: GlueCEState
> objectClass: GlueCEAccessControlBase
> objectClass: GlueCEPolicy
> objectClass: GlueKey
> objectClass: GlueSchemaVersion
> GlueVOViewLocalID: /VO=swetest/GROUP=/swetest/ROLE=swadmin
> GlueCEAccessControlBaseRule: VOMS:/VO=swetest/GROUP=/swetest/ROLE=swadmin
> GlueCEAccessControlBaseRule: DENY:dteam
> GlueCEAccessControlBaseRule: DENY:ops
> GlueCEAccessControlBaseRule: DENY:swetest
> GlueCEAccessControlBaseRule: DENY:/VO=dteam/GROUP=/dteam/ROLE=lcgadmin
> GlueCEAccessControlBaseRule: DENY:/VO=dteam/GROUP=/dteam/ROLE=production
> GlueCEAccessControlBaseRule: DENY:/VO=ops/GROUP=/ops/ROLE=lcgadmin
> GlueCEStateRunningJobs: 0
> GlueCEStateWaitingJobs: 0
> GlueCEStateTotalJobs: 0
> GlueCEStateFreeJobSlots: 22
> GlueCEStateEstimatedResponseTime: 0
> GlueCEStateWorstResponseTime: 0
> GlueCEInfoDefaultSE: hades.up.pt
> GlueCEInfoApplicationDir: /vosoft/swetestsoft
> GlueCEInfoDataDir: unset
> GlueChunkKey: GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest
> GlueSchemaVersionMajor: 1
> GlueSchemaVersionMinor: 2
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 2
> # numEntries: 1
>
>
>
> --------------------- openldap 2.2.13 ------------------------
>
> ldapsearch -P3 -x -H ldap://cclcgtopbdii02.in2p3.fr:2170 -b
> "GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds-vo-name=local,o=grid"
> version: 2
>
> #
> # filter: (objectclass=*)
> # requesting: ALL
> #
>
> # search result
> search: 2
> result: 34 Invalid DN syntax
> text: invalid DN
>
> # numResponses: 1
>
> ---------------------------------------------------
>
>
>
> Each time a dn contain an attribute of the following form :
> "attribute=a_string=another_string,..." (eg:
> "/VO=swetest/GROUP=/swetest/ROLE=swadmin") openldap 2.2 produce an error "could
> not parse entry"
>
> In fact, each time the attribute value contain more that one equal ("=")
> character, openldap failed to handle the string, even though this character is
> included in the IA5 table.
>
> Best regards.
>
>
1) both 2.0 and 2.2 are ancient. OpenLDAP 2.3 is mature, and 2.4 is
about to exit beta stage. Unless the problem is related to a real
software bug, and it persists either in HEAD/2.4 or in 2.3 code, this
ITS will be closed.
2) were GlueCEUniqueID and mds-vo-name declared anywhere? There seems
to be nothing wrong with your DN per se; in fact, dntest yields
$ dntest \
'GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds-vo-name=local,o=grid'
ldap_rdn2str() =
"GlueVOViewLocalID=/VO\3Dswetest/GROUP\3D/swetest/ROLE\
3Dswadmin"
ldap_rdn2str() =
"GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge
-swetest"
ldap_rdn2str() = "mds-vo-name=UPorto"
ldap_rdn2str() = "mds-vo-name=local"
ldap_rdn2str() = "o=grid"
ldap_dn2str(ldap_str2dn("GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadm
in,GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UP
orto,mds-vo-name=local,o=grid"))
=
"GlueVOViewLocalID=/VO\3Dswetest/GROUP\3D/swetest/ROLE\3Dswadmin,GlueC
EUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds
-vo-name=local,o=grid"
ldap_dn2domain("GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,GlueCE
UniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds-
vo-name=local,o=grid")
= ""
ldap_dn2ufn("GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,GlueCEUni
queID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds-vo-
name=local,o=grid")
= "/VO\3Dswetest/GROUP\3D/swetest/ROLE\3Dswadmin,
grid001.fc.up.pt:2119/
jobmanager-lcgsge-swetest, UPorto, local, grid"
ldap_dn2dcedn("GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,GlueCEU
niqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds-v
o-name=local,o=grid")
=
"/o=grid/mds-vo-name=local/mds-vo-name=UPorto/GlueCEUniqueID=grid001.f
c.up.pt:2119\/jobmanager-lcgsge-swetest/GlueVOViewLocalID=\/VO\=swetest\/GROUP\=
\/swetest\/ROLE\=swadmin"
ldap_dcedn2dn("/o=grid/mds-vo-name=local/mds-vo-name=UPorto/GlueCEUniqueID=grid0
01.fc.up.pt:2119\/jobmanager-lcgsge-swetest/GlueVOViewLocalID=\/VO\=swetest\/GRO
UP\=\/swetest\/ROLE\=swadmin")
=
"GlueVOViewLocalID=/VO\3Dswetest/GROUP\3D/swetest/ROLE\3Dswadmin,GlueC
EUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds
-vo-name=local,o=grid"
ldap_dn2ad_canonical("GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,
GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPort
o,mds-vo-name=local,o=grid")
=
"grid/local/UPorto/grid001.fc.up.pt:2119\/jobmanager-lcgsge-swetest/\/
VO\=swetest\/GROUP\=\/swetest\/ROLE\=swadmin/"
ldap_explode_dn("GlueVOViewLocalID=/VO\3Dswetest/GROUP\3D/swetest/ROLE\3Dswadmin
,GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPor
to,mds-vo-name=local,o=grid"):
"GlueVOViewLocalID=/VO\3Dswetest/GROUP\3D/swetest/ROLE\3Dswadmin"
ldap_explode_rdn("GlueVOViewLocalID=/VO\3Dswetest/GROUP\3D/swetest/ROLE\
3Dswadmin")
'GlueVOViewLocalID=/VO\3Dswetest/GROUP\3D/swetest/ROLE\3Dswadmin
'
ldap_explode_rdn("GlueVOViewLocalID=/VO\3Dswetest/GROUP\3D/swetest/ROLE\
3Dswadmin") (no types)
"/VO\3Dswetest/GROUP\3D/swetest/ROLE\3Dswadmin"
"GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest"
ldap_explode_rdn("GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge
-swetest")
'GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest'
ldap_explode_rdn("GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge
-swetest") (no types)
"grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest"
"mds-vo-name=UPorto"
ldap_explode_rdn("mds-vo-name=UPorto")
'mds-vo-name=UPorto'
ldap_explode_rdn("mds-vo-name=UPorto") (no types)
"UPorto"
"mds-vo-name=local"
ldap_explode_rdn("mds-vo-name=local")
'mds-vo-name=local'
ldap_explode_rdn("mds-vo-name=local") (no types)
"local"
"o=grid"
ldap_explode_rdn("o=grid")
'o=grid'
ldap_explode_rdn("o=grid") (no types)
"grid"
ldap_explode_dn("GlueVOViewLocalID=/VO\3Dswetest/GROUP\3D/swetest/ROLE\3Dswadmin
,GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPor
to,mds-vo-name=local,o=grid") (no types):
"/VO\3Dswetest/GROUP\3D/swetest/ROLE\3Dswadmin"
"grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest"
"UPorto"
"local"
"grid"
"GlueVOViewLocalID=/VO\3Dswetest/GROUP\3D/swetest/ROLE\3Dswadmin,GlueCEUniqueID=
grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds-vo-name=l
ocal,o=grid"
==
"GlueVOViewLocalID=/VO\3Dswetest/GROUP\3D/swetest/ROLE\3Dswadmin,Glu
eCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,m
ds-vo-name=local,o=grid" ? yes
But apparently some attribute declarations are missing; in fact, slapdn
(after declaring GlueVOViewLocalID as indicated above) yields
slapdn -f testrun/slapd.1.conf
'GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds-vo-name=local,o=grid'
DN:
<GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds-vo-name=local,o=grid>
check failed 21 (Invalid syntax)
where the failure refers exactly to the fact that GlueCEUniqueID was not
declared.
p.
PS: don't look for those tools in ancient software; they've been
introduced only in recent times (dntest: October 2001; slapdn: March 2004).
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 8 months
(ITS#5064) Issues with openldap 2.2 (Error 34 Invalid DN syntax )
by pbrinette＠cc.in2p3.fr
Full_Name: Pierre-Emmanuel Brinette
Version: 2.2.13 (openldap-2.2.13-6.4E)
OS: Scientific Linux 4.4 (RHEL 4.4 clone)
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (134.158.71.215)
Hello,
Openldap is used as information provider in a GRID middleware project
(http://www.eu-egee.org/). This information provider is known as BDII.
The information about grid nodes are published via openldap.
Until now, the platform supported by the middleware is Scientific Linux 3 (a
RHEL 3 clone like CentOS). The openldap version provided with this system is
openldap 2.0.27.
We updated our systems with Scientific Linux 4.4 (RHEL 4.4) for new hardware
support. The openldap version provided is now 2.2.13.
When I put the new service in production, I find some issues with some
attributes that disappears from the directory.
In our openldap schema, we have an attribute declared like this:
attributetype ( 1.3.6.1.4.1.8005.100.2.2.7.1
NAME 'GlueVOViewLocalID'
DESC 'Local ID for this VO view'
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
SINGLE-VALUE)
This attribute may containt string like these:
GlueVOViewLocalID=dteam
GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,
It seem that theses both sample strings are IA5 compliant.
When I ask the openldap server with this request, Ive got different results
regarding the openldap version :
------------ Openldap 2.0.27 -----------------------
ldapsearch -x -P3 -H ldap://cclcgtopbdii01.in2p3.fr:2170 -b
"GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds-vo-name=local,o=grid"
version: 2
#
# filter: (objectclass=*)
# requesting: ALL
#
# /VO=swetest/GROUP=/swetest/ROLE=swadmin, grid001.fc.up.pt:2119/jobmanager-l
cgsge-swetest, UPorto, local, grid
dn: GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,GlueCEUniqueID=g
rid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds-vo-name
=local,o=grid
objectClass: GlueCETop
objectClass: GlueVOView
objectClass: GlueCEInfo
objectClass: GlueCEState
objectClass: GlueCEAccessControlBase
objectClass: GlueCEPolicy
objectClass: GlueKey
objectClass: GlueSchemaVersion
GlueVOViewLocalID: /VO=swetest/GROUP=/swetest/ROLE=swadmin
GlueCEAccessControlBaseRule: VOMS:/VO=swetest/GROUP=/swetest/ROLE=swadmin
GlueCEAccessControlBaseRule: DENY:dteam
GlueCEAccessControlBaseRule: DENY:ops
GlueCEAccessControlBaseRule: DENY:swetest
GlueCEAccessControlBaseRule: DENY:/VO=dteam/GROUP=/dteam/ROLE=lcgadmin
GlueCEAccessControlBaseRule: DENY:/VO=dteam/GROUP=/dteam/ROLE=production
GlueCEAccessControlBaseRule: DENY:/VO=ops/GROUP=/ops/ROLE=lcgadmin
GlueCEStateRunningJobs: 0
GlueCEStateWaitingJobs: 0
GlueCEStateTotalJobs: 0
GlueCEStateFreeJobSlots: 22
GlueCEStateEstimatedResponseTime: 0
GlueCEStateWorstResponseTime: 0
GlueCEInfoDefaultSE: hades.up.pt
GlueCEInfoApplicationDir: /vosoft/swetestsoft
GlueCEInfoDataDir: unset
GlueChunkKey: GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest
GlueSchemaVersionMajor: 1
GlueSchemaVersionMinor: 2
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
--------------------- openldap 2.2.13 ------------------------
ldapsearch -P3 -x -H ldap://cclcgtopbdii02.in2p3.fr:2170 -b
"GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds-vo-name=local,o=grid"
version: 2
#
# filter: (objectclass=*)
# requesting: ALL
#
# search result
search: 2
result: 34 Invalid DN syntax
text: invalid DN
# numResponses: 1
---------------------------------------------------
Each time a dn contain an attribute of the following form :
"attribute=a_string=another_string,..." (eg:
"/VO=swetest/GROUP=/swetest/ROLE=swadmin") openldap 2.2 produce an error "could
not parse entry"
In fact, each time the attribute value contain more that one equal ("=")
character, openldap failed to handle the string, even though this character is
included in the IA5 table.
Best regards.
--
Pierre-Emmanuel Brinette
Grid computing - EGEE/LCG team
IN2P3/CNRS Computing Centre - Lyon (France)
27 bd du 11 novembre, F-69622 Villeurbanne cedex
pbrinette(a)cc.in2p3.fr - Tél. : +33 (0) 4 78 93 08 80
15 years, 8 months
Re: Contrib: addpartial overlay (ITS#3593)
by ghenry＠OpenLDAP.org
David Hawes wrote:
> On Thursday 26 July 2007 09:15, you wrote:
>> dhawes(a)vt.edu wrote:
>>> On Thursday 19 July 2007 17:18, ghenry(a)suretecsystems.com wrote:
>>>> <quote who="dhawes(a)vt.edu">
>>>>
>>>>> On Thursday 19 July 2007 05:35, Gavin Henry wrote:
>>>>>>> An updated version of addpartial is available at:
>>>>>>>
>>>>>>> ftp://ftp.openldap.org/incoming/david_hawes-addpartial-070126.tgz
>>>>>>>
>>>>>>> This version includes changes to work with OpenLDAP 2.3 as well as
>>>>>>> ensuring syncrepl works properly.
>>>>>>>
>>>>>>> david hawes
>>>>>> If this hasn't been added to 2.4/HEAD yet, would you consider updating
>>>>>> it
>>>>>> for inclusion in 2.4 contrib?
>>>>> Absolutely, I've been meaning to test with 2.4. I'll bump it to the
>>>>> top of
>>>>> the list.
>>>> Can you make sure that is dynamically configurable via cn=config like
>>>> everything else in 2.4.
>>>>
>>>> Thanks.
>>> I have tested the overlay at
>>> ftp://ftp.openldap.org/incoming/david_hawes-addpartial-070126.tgz, and it
>>> works with 2.4.4alpha, including dynamic loading via cn=config.
>>>
>>> Apart from using "overlay addpartial", there is no slapd configuration
>>> for addpartial. I believe this means it doesn't need its own schema to
>>> work correctly. Please correct me if I am wrong about this.
>>>
>>> Thanks,
>>>
>>> dave
>> Anyone mind if I commit this to contrib in HEAD?
>
> I don't think you were asking me about this, but I certainly have no problem
> with it. If I need to state the disclaimer I'll gladly do so. The OpenLDAP
> public license is included, so that may be all that is needed.
>
> dave
Committed. Closing ITS.
--
Kind Regards,
Gavin Henry.
OpenLDAP Engineering Team.
E ghenry(a)OpenLDAP.org
Community developed LDAP software.
http://www.openldap.org/project/
15 years, 8 months