openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

(ITS#5066) ldap error :server down
by jalali_azam＠yahoo.com 30 Jul '07

30 Jul '07

Full_Name: Azam Jalali Version: 2.2.29 OS: windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.207.237.38) I installed openldap 2.2.9 and set sldap.conf as following: /////////////////////////////////////////////////////////////////////////// ucdata-path ./ucdata include ./schema/core.schema include ./schema/cosine.schema include ./schema/inetorgperson.schema include ./schema/nis.schema include ./schema/dyngroup.schema # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap:/root.openldap.org pidfile ./run/slapd.pid argsfile ./run/slapd.args # Load dynamic backend modules: # modulepath ./libexec/openldap # moduleload back_bdb.la # moduleload back_ldap.la # moduleload back_ldbm.la # moduleload back_passwd.la # moduleload back_shell.la # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! ####################################################################### # BDB database definitions ####################################################################### database bdb suffix "dc=my-domain,dc=com" rootdn "cn=Manager,dc=my-domain,dc=com" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw secret # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory ./data # Indices to maintain index objectClass eq access to attr=userpassword by anonymous auth by self write by dn="cn=Manager,dc=my-domain,dc=com" write by * none access to * by dn="cn=Manager,dc=my-domain,dc=com" write by users write by self write by * read by * write /////////////////////////////////////////////////////////////////////////// After running some query on this openldap i got ldap error:server down. This event occurs every time i reinstalled it and ran some query on it? How i fix this error? Thanks in advance Azam Jalali

1 0

Slapd doesn't start after update
by ツ Leandro Sales 28 Jul '07

28 Jul '07

Hello folks... I update the openldap from version 2.2.28-r7 to 2.3.35-r1 using emerge. After update the slapd deamon didn't start. I enabled the log and realized that the problem was the incompatible version of the database. I then downgrade to the 2.2.28 version and when I started slapd I got the message: "/usr/lib64/openldap/slapd: error while loading shared libraries: liblber-2.3.so.0: cannot open shared object file: No such file or directory". I then reinstall and this problem doesn't happen anymore, but slapd still doesn't start and print the following messages in the log file: Jul 27 17:55:11 embedded slapd[2957]: bdb_db_init: Initializing BDB database Jul 27 17:55:11 embedded slapd[2958]: bdb(o=Embedded,c=BR): Program version 4.5 doesn't match environment version 0.22 Jul 27 17:55:11 embedded slapd[2958]: bdb_db_open: dbenv_open failed: DB_VERSION_MISMATCH: Database environment version mismatch (-30972) Jul 27 17:55:11 embedded slapd[2958]: backend_startup: bi_db_open failed! (-30972) Jul 27 17:55:11 embedded slapd[2958]: bdb(o=Embedded,c=BR): DB_ENV->lock_id_free interface requires an environment configured for the locking subsystem Jul 27 17:55:11 embedded slapd[2958]: bdb(o=Embedded,c=BR): txn_checkpoint interface requires an environment configured for the transaction subsystem Jul 27 17:55:11 embedded slapd[2958]: bdb_db_destroy: txn_checkpoint failed: Invalid argument (22) Please, help me on this. []s Leandro.

2 1

Re: (ITS#5064) Issues with openldap 2.2 (Error 34 Invalid DN syntax )
by ando＠sys-net.it 27 Jul '07

27 Jul '07

ando(a)sys-net.it wrote: > 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 I confirm that using the schema extracted from <ldap://cclcgtopbdii01.in2p3.fr:2170/>, 2.3/2.4 slapdn can successfully handle the offending DN: $ slapdn \ '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 succeeded normalized: <GlueVOViewLocalID=/vo\3Dswetest/group\3D/swetest/role\3Dswadmin,GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,Mds-Vo-name=uporto,Mds-Vo-name=local,o=grid> pretty: <GlueVOViewLocalID=/VO\3Dswetest/GROUP\3D/swetest/ROLE\3Dswadmin,GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,Mds-Vo-name=UPorto,Mds-Vo-name=local,o=grid> I'd consider this ITS closed. 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 ---------------------------------------

1 0

(ITS#5065) out of order ctxcsn from old entryCSN
by donn＠u.washington.edu 27 Jul '07

27 Jul '07

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.

1 0

Re: (ITS#5058) LDAP/Egroupware addressbook issue
by ando＠sys-net.it 27 Jul '07

27 Jul '07

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 ---------------------------------------

1 0

Re: (ITS#5062) back-sql with non-integer keycol's
by ando＠sys-net.it 27 Jul '07

27 Jul '07

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#functio… > > 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 ---------------------------------------

1 0

Re: (ITS#5062) back-sql with non-integer keycol's
by ando＠sys-net.it 27 Jul '07

27 Jul '07

1 0

Re: (ITS#5064) Issues with openldap 2.2 (Error 34 Invalid DN syntax )
by ando＠sys-net.it 27 Jul '07

27 Jul '07

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 ---------------------------------------

1 0

Re: (ITS#5064) Issues with openldap 2.2 (Error 34 Invalid DN syntax )
by pbrinette＠cc.in2p3.fr 27 Jul '07

27 Jul '07

> 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/sc… 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

1 0

Re: (ITS#5064) Issues with openldap 2.2 (Error 34 Invalid DN syntax )
by ando＠sys-net.it 27 Jul '07

27 Jul '07

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 ---------------------------------------

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs