Hello,
We are using PowerDNS with LDAP Backend.
At some point the backend schema changed so in order to upgrade we need to change the schema loaded in OpenLDAP.
Unfortunately, something seems to be going wrong in the process.
What I did: First, I converted the new schema to ldif by creating a dummy conf file:
# cat /root/work/dnsdomain2-new.conf include /root/work/core.schema include /root/work/cosine.schema include /root/work/dnsdomain2.schema include /root/work/pdns-domaininfo.schema
and then running:
# slaptest -f dnsdomain2-new.conf -F dnsdomain2-new.d # slapcat -F dnsdomain2-new.d -bcn=config > dd2new-schema.ldif
Then, on the actual config I exported initial config:
# slapcat -n0 -F /usr/local/openldap/etc/openldap/slapd.d/ -l /root/work/ldapconf-01.ldif
and edited the output (ldapconf-01.ldif) by replacing the whole dnsdomain2 section with the new one (as is in dd2new-schema.ldif file). The initial dnsdomain2 section was {10} so I renumbered the copied schema section from {2} to {10}.
In the end of schema definitions section I added pdns-domaininfo definition (copied from dd2new-schema.conf), to which I gave the last number +1, which was {16} (rather than {3}, as it was in the converted file).
However, when I try to load this config to a new (empty) slapd.d directory, I get:
==========================================================================================
# rm -rf slapd.d # mkdir slapd.d # chown ldap:ldap slapd.d
# slapadd -n0 -F ./slapd.d -l /root/work/ldapconf-01.ldif 60a2e22a olcAttributeTypes: value #2 olcAttributeTypes: Unexpected token before SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) AttributeTypeDescription = "(" whsp numericoid whsp ; AttributeType identifier [ "NAME" qdescrs ] ; name used in AttributeType [ "DESC" qdstring ] ; description [ "OBSOLETE" whsp ] [ "SUP" woid ] ; derived from this other ; AttributeType [ "EQUALITY" woid ] ; Matching Rule name [ "ORDERING" woid ] ; Matching Rule name [ "SUBSTR" woid ] ; Matching Rule name [ "SYNTAX" whsp noidlen whsp ] ; see section 4.3 [ "SINGLE-VALUE" whsp ] ; default multi-valued [ "COLLECTIVE" whsp ] ; default not collective [ "NO-USER-MODIFICATION" whsp ]; default user modifiable [ "USAGE" whsp AttributeUsage ]; default userApplications ; userApplications ; directoryOperation ; distributedOperation ; dSAOperation whsp ")" slapadd: could not add entry dn="cn={10}dnsdomain2,cn=schema,cn=config" (line=2256): _############### 76.98% eta none elapsed none spd 1001.2 k/s Closing DB...
==========================================================================================
What am I doing wrong in updating the schemas in cn=config?
I find the above message difficult to interpret. Note that there are numerous "SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )" statements in the schema definition.
I include the new dnsdomain2 section for your reference:
==========================================================================================
dn: cn={10}dnsdomain2,cn=schema,cn=config objectClass: olcSchemaConfig cn: {10}dnsdomain2 olcAttributeTypes: {0}( 1.3.6.1.4.1.2428.20.0.0 NAME 'dNSTTL' DESC 'An integ er denoting time to live' EQUALITY integerMatch ORDERING integerOrderingMat ch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) olcAttributeTypes: {1}( 1.3.6.1.4.1.2428.20.0.1 NAME 'dNSClass' DESC 'The cl ass of a resource record' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.14 66.115.121.1.26 ) olcAttributeTypes: {2}( 1.3.6.1.4.1.2428.20.1.11 NAME 'wKSRecord' DESC 'a we ll known service description, RFC 1035' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {3}( 1.3.6.1.4.1.2428.20.1.12 NAME 'pTRRecord' DESC 'doma in name pointer, RFC 1035' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5 SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {4}( 1.3.6.1.4.1.2428.20.1.13 NAME 'hInfoRecord' DESC 'ho st information, RFC 1035' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5S ubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {5}( 1.3.6.1.4.1.2428.20.1.14 NAME 'mInfoRecord' DESC 'ma ilbox or mail list information, RFC 1035' EQUALITY caseIgnoreIA5Match SUBST R caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {6}( 1.3.6.1.4.1.2428.20.1.16 NAME 'tXTRecord' DESC 'text string, RFC 1035' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5Substrin gsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {7}( 1.3.6.1.4.1.2428.20.1.17 NAME 'rPRecord' DESC 'for R esponsible Person, RFC 1183' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreI A5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {8}( 1.3.6.1.4.1.2428.20.1.18 NAME 'aFSDBRecord' DESC 'fo r AFS Data Base location, RFC 1183' EQUALITY caseIgnoreIA5Match SUBSTR case IgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {9}( 1.3.6.1.4.1.2428.20.1.24 NAME 'SigRecord' DESC 'Sign ature, RFC 2535' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5Substrings Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {10}( 1.3.6.1.4.1.2428.20.1.25 NAME 'KeyRecord' DESC 'Key , RFC 2535' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {11}( 1.3.6.1.4.1.2428.20.1.27 NAME 'gPosRecord' DESC 'Ge ographical Position, RFC 1712' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnor eIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {12}( 1.3.6.1.4.1.2428.20.1.28 NAME 'aAAARecord' DESC 'IP v6 address, RFC 1886' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5Subst ringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {13}( 1.3.6.1.4.1.2428.20.1.29 NAME 'LocRecord' DESC 'Loc ation, RFC 1876' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5Substrings Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {14}( 1.3.6.1.4.1.2428.20.1.30 NAME 'nXTRecord' DESC 'non -existant, RFC 2535' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5Substr ingsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {15}( 1.3.6.1.4.1.2428.20.1.33 NAME 'sRVRecord' DESC 'ser vice location, RFC 2782' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5Su bstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {16}( 1.3.6.1.4.1.2428.20.1.35 NAME 'nAPTRRecord' DESC 'N aming Authority Pointer, RFC 2915' EQUALITY caseIgnoreIA5Match SUBSTR caseI gnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {17}( 1.3.6.1.4.1.2428.20.1.36 NAME 'kXRecord' DESC 'Key Exchange Delegation, RFC 2230' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnor eIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {18}( 1.3.6.1.4.1.2428.20.1.37 NAME 'certRecord' DESC 'ce rtificate, RFC 2538' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5Substr ingsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {19}( 1.3.6.1.4.1.2428.20.1.38 NAME 'a6Record' DESC 'A6 R ecord Type, RFC 2874' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5Subst ringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {20}( 1.3.6.1.4.1.2428.20.1.39 NAME 'dNameRecord' DESC 'N on-Terminal DNS Name Redirection, RFC 2672' EQUALITY caseIgnoreIA5Match SUB STR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {21}( 1.3.6.1.4.1.2428.20.1.42 NAME 'aPLRecord' DESC 'Lis ts of Address Prefixes, RFC 3123' EQUALITY caseIgnoreIA5Match SUBSTR caseIg noreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {22}( 1.3.6.1.4.1.2428.20.1.43 NAME 'dSRecord' DESC 'Dele gation Signer, RFC 3658' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5Su bstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {23}( 1.3.6.1.4.1.2428.20.1.44 NAME 'sSHFPRecord' DESC 'S SH Key Fingerprint, RFC 4255' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnore IA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {24}( 1.3.6.1.4.1.2428.20.1.45 NAME 'iPSecKeyRecord' DESC 'SSH Key Fingerprint, RFC 4025' EQUALITY caseIgnoreIA5Match SUBSTR caseIgn oreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {25}( 1.3.6.1.4.1.2428.20.1.46 NAME 'rRSIGRecord' DESC 'R RSIG, RFC 3755' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsM atch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {26}( 1.3.6.1.4.1.2428.20.1.47 NAME 'nSECRecord' DESC 'NS EC, RFC 3755' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMat ch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {27}( 1.3.6.1.4.1.2428.20.1.48 NAME 'dNSKeyRecord' DESC ' DNSKEY, RFC 3755' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5Substring sMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {28}( 1.3.6.1.4.1.2428.20.1.49 NAME 'dHCIDRecord' DESC 'D HCID, RFC 4701' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsM atch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {29}( 1.3.6.1.4.1.2428.20.1.50 NAME 'nSEC3Record' DESC 'N SEC record version 3, RFC 5155' EQUALITY caseIgnoreIA5Match SUBSTR caseIgno reIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {30}( 1.3.6.1.4.1.2428.20.1.51 NAME 'nSEC3PARAMRecord' DE SC 'NSEC3 parameters, RFC 5155' EQUALITY caseIgnoreIA5Match SUBSTR caseIgno reIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {31}( 1.3.6.1.4.1.2428.20.1.52 NAME 'tLSARecord' DESC 'TL SA certificate association, RFC 6698' EQUALITY caseIgnoreIA5Match SUBSTR ca seIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {32}( 1.3.6.1.4.1.2428.20.1.59 NAME 'cDSRecord' DESC 'Chi ld DS, RFC7344' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsM atch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {33}( 1.3.6.1.4.1.2428.20.1.60 NAME 'cDNSKeyRecord' DESC 'DNSKEY(s) the Child wants reflected in DS, RFC7344' EQUALITY caseIgnoreIA5 Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1 .26 ) olcAttributeTypes: {34}( 1.3.6.1.4.1.2428.20.1.61 NAME 'openPGPKeyRecord' DE SC 'OpenPGP Key, RFC7929' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5S ubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {35}( 1.3.6.1.4.1.2428.20.1.64 NAME 'SVCBRecord' DESC 'Se rvice binding, draft-ietf-dnsop-svcb-https-01' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {36}( 1.3.6.1.4.1.2428.20.1.65 NAME 'HTTPSRecord' DESC 'H TTPS service binding, draft-ietf-dnsop-svcb-https-01' EQUALITY caseIgnoreIA 5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121. 1.26 ) olcAttributeTypes: {37}( 1.3.6.1.4.1.2428.20.1.99 NAME 'sPFRecord' DESC 'Sen der Policy Framework, RFC 4408' EQUALITY caseIgnoreIA5Match SUBSTR caseIgno reIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {38}( 1.3.6.1.4.1.2428.20.1.108 NAME 'EUI48Record' DESC ' EUI-48 address, RFC7043' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5Su bstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {39}( 1.3.6.1.4.1.2428.20.1.109 NAME 'EUI64Record' DESC ' EUI-64 address, RFC7043' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5Su bstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {40}( 1.3.6.1.4.1.2428.20.1.249 NAME 'tKeyRecord' DESC 'T ransaction Key, RFC2930' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5Su bstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {41}( 1.3.6.1.4.1.2428.20.1.256 NAME 'uRIRecord' DESC 'UR I, RFC7553' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {42}( 1.3.6.1.4.1.2428.20.1.257 NAME 'cAARecord' DESC 'Ce rtification Authority Restriction, RFC6844' EQUALITY caseIgnoreIA5Match SUB STR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {43}( 1.3.6.1.4.1.2428.20.1.32769 NAME 'dLVRecord' DESC ' DNSSEC Lookaside Validation, RFC4431' EQUALITY caseIgnoreIA5Match SUBSTR ca seIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {44}( 1.3.6.1.4.1.2428.20.1.65226 NAME 'TYPE65226Record' DESC '' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYN TAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {45}( 1.3.6.1.4.1.2428.20.1.65534 NAME 'TYPE65534Record' DESC '' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYN TAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcObjectClasses: {0}( 1.3.6.1.4.1.2428.20.2 NAME 'dNSDomain2' SUP dNSDomain STRUCTURAL MAY ( DNSTTL $ DNSClass $ WKSRecord $ PTRRecord $ HINFORecord $ MINFORecord $ TXTRecord $ RPRecord $ AFSDBRecord $ SIGRecord $ KEYRecord $ GPOSRecord $ AAAARecord $ LOCRecord $ NXTRecord $ SRVRecord $ NAPTRRecord $ KXRecord $ CERTRecord $ A6Record $ DNAMERecord $ APLRecord $ DSRecord $ S SHFPRecord $ IPSECKEYRecord $ RRSIGRecord $ NSECRecord $ DNSKEYRecord $ DHC IDRecord $ NSEC3Record $ NSEC3PARAMRecord $ TLSARecord $ CDSRecord $ CDNSKE YRecord $ OPENPGPKEYRecord $ SVCBRecord $ HTTPSRecord $ SPFRecord $ EUI48Re cord $ EUI64Record $ TKEYRecord $ URIRecord $ CAARecord $ DLVRecord $ TYPE6 5226Record $ TYPE65534Record ) ) structuralObjectClass: olcSchemaConfig entryUUID: 15113670-9f95-49b9-a483-b7d7bf2629ec creatorsName: cn=config createTimestamp: 20111017141815Z entryCSN: 20111017141815.387018Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20111017141815Z
==========================================================================================
I even tried to keep the original entryUUID, createTimestamp, entryCSN, modifyTimestamp values (just in case), but it did not make a difference.
I appreciate your help.
(Note that export of the intial config was done on v2.4.56 and import of the modified config was done on a test server with 2.4.58.)
If there is any additional info you may require, I will be glad to provide it.
Thanks, Nick
On 5/18/21 12:39 AM, Nick Milas wrote:
# slapadd -n0 -F ./slapd.d -l /root/work/ldapconf-01.ldif 60a2e22a olcAttributeTypes: value #2 olcAttributeTypes: Unexpected token before SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) [..] olcAttributeTypes: {2}( 1.3.6.1.4.1.2428.20.1.11 NAME 'wKSRecord' DESC 'a we ll known service description, RFC 1035' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
Missing space after SUBSTR?
Ciao, Michael.
Nick Milas wrote:
However, when I try to load this config to a new (empty) slapd.d directory, I get:
==========================================================================================
# rm -rf slapd.d # mkdir slapd.d # chown ldap:ldap slapd.d
# slapadd -n0 -F ./slapd.d -l /root/work/ldapconf-01.ldif 60a2e22a olcAttributeTypes: value #2 olcAttributeTypes: Unexpected token before SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) AttributeTypeDescription = "(" whsp numericoid whsp ; AttributeType identifier [ "NAME" qdescrs ] ; name used in AttributeType [ "DESC" qdstring ] ; description [ "OBSOLETE" whsp ] [ "SUP" woid ] ; derived from this other ; AttributeType [ "EQUALITY" woid ] ; Matching Rule name [ "ORDERING" woid ] ; Matching Rule name [ "SUBSTR" woid ] ; Matching Rule name [ "SYNTAX" whsp noidlen whsp ] ; see section 4.3 [ "SINGLE-VALUE" whsp ] ; default multi-valued [ "COLLECTIVE" whsp ] ; default not collective [ "NO-USER-MODIFICATION" whsp ]; default user modifiable [ "USAGE" whsp AttributeUsage ]; default userApplications ; userApplications ; directoryOperation ; distributedOperation ; dSAOperation whsp ")" slapadd: could not add entry dn="cn={10}dnsdomain2,cn=schema,cn=config" (line=2256): _############### 76.98% eta none elapsed none spd 1001.2 k/s Closing DB...
==========================================================================================
What am I doing wrong in updating the schemas in cn=config?
I find the above message difficult to interpret. Note that there are numerous "SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )" statements in the schema definition.
Yes, but there is only one attribute value #2 in the attribute. Pay attention to what the error message tells you.
I include the new dnsdomain2 section for your reference:
==========================================================================================
dn: cn={10}dnsdomain2,cn=schema,cn=config objectClass: olcSchemaConfig cn: {10}dnsdomain2 olcAttributeTypes: {0}( 1.3.6.1.4.1.2428.20.0.0 NAME 'dNSTTL' DESC 'An integ er denoting time to live' EQUALITY integerMatch ORDERING integerOrderingMat ch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) olcAttributeTypes: {1}( 1.3.6.1.4.1.2428.20.0.1 NAME 'dNSClass' DESC 'The cl ass of a resource record' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.14 66.115.121.1.26 ) olcAttributeTypes: {2}( 1.3.6.1.4.1.2428.20.1.11 NAME 'wKSRecord' DESC 'a we ll known service description, RFC 1035' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
This is value #2 ^^
Read the ldif(5) manpage more carefully. You're missing a trailing space after SUBSTR.
olcAttributeTypes: {3}( 1.3.6.1.4.1.2428.20.1.12 NAME 'pTRRecord' DESC 'doma in name pointer, RFC 1035' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5 SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {4}( 1.3.6.1.4.1.2428.20.1.13 NAME 'hInfoRecord' DESC 'ho st information, RFC 1035' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5S ubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
On 18/5/2021 1:55 π.μ., Michael Ströder wrote:
Missing space after SUBSTR?
On 18/5/2021 1:57 π.μ., Howard Chu wrote:
Yes, but there is only one attribute value #2 in the attribute. Pay attention to what the error message tells you.
You were both right, thank you.
Turns out that all trailing spaces of the copied (and inserted) ldif sections were cut off (obviously during the copy process), so I had to manually add them in wrapped lines which happened to be wrapped at a space character... Tricky.
Case solved, thanks again.
Cheers, Nick
On 5/18/21 10:28 AM, Nick Milas wrote:
On 18/5/2021 1:55 π.μ., Michael Ströder wrote:
Missing space after SUBSTR?
On 18/5/2021 1:57 π.μ., Howard Chu wrote:
Yes, but there is only one attribute value #2 in the attribute. Pay attention to what the error message tells you.
You were both right, thank you.
Turns out that all trailing spaces of the copied (and inserted) ldif sections were cut off (obviously during the copy process), so I had to manually add them in wrapped lines which happened to be wrapped at a space character... Tricky.
It might be easier for such small schema changes to use a GUI LDAP client to avoid exactly this kind of problem.
Ciao, Michael.
On 5/18/21 12:57 AM, Howard Chu wrote:
60a2e22a olcAttributeTypes: value #2 olcAttributeTypes: Unexpected .. [..] What am I doing wrong in updating the schemas in cn=config? I find the above message difficult to interpret. Note that there are numerous "SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )" statements in the schema definition.>
Yes, but there is only one attribute value #2 in the attribute. Pay attention to what the error message tells you.
It would be helpful if an LDAP GUI client could get a machine-readable response control to determine which values were wrong.
Or at least you OpenLDAP developers stick to fairly stable text parts in info field returned which I could parse in web2ldap.
Ciao, Michael.
On Tue, May 18 2021 at 11:28:16 +0300, Nick Milas scribbled in "Re: Updating schema in cn=config":
On 18/5/2021 1:55 π.μ., Michael Ströder wrote:
Missing space after SUBSTR?
On 18/5/2021 1:57 π.μ., Howard Chu wrote:
Yes, but there is only one attribute value #2 in the attribute. Pay attention to what the error message tells you.
You were both right, thank you.
Turns out that all trailing spaces of the copied (and inserted) ldif sections were cut off (obviously during the copy process), so I had to manually add them in wrapped lines which happened to be wrapped at a space character... Tricky.
For this sort of round-trip editing (if you don't have a GUI tool available, as suggested by Michael), you can add `-o ldif-wrap=no` to many of the openldap tools -- like `ldapsearch` or `slapcat` -- which prevents the output being wrapped like this.
Cheers.
Dameon.
Michael Ströder wrote:
On 5/18/21 10:28 AM, Nick Milas wrote:
On 18/5/2021 1:55 π.μ., Michael Ströder wrote:
Missing space after SUBSTR?
On 18/5/2021 1:57 π.μ., Howard Chu wrote:
Yes, but there is only one attribute value #2 in the attribute. Pay attention to what the error message tells you.
You were both right, thank you.
Turns out that all trailing spaces of the copied (and inserted) ldif sections were cut off (obviously during the copy process), so I had to manually add them in wrapped lines which happened to be wrapped at a space character... Tricky.
It might be easier for such small schema changes to use a GUI LDAP client to avoid exactly this kind of problem.
I don't see how that is relevant. The first problem is that he was trying to do a wholesale replace of a schema file. If instead he had just a diff of the old and new versions of the schema, he could of course have fed that into an ldapmodify operation - whether by GUI or by CLI.
Ciao, Michael.
On 5/18/21 6:23 PM, Howard Chu wrote:
Michael Ströder wrote:
On 5/18/21 10:28 AM, Nick Milas wrote:
On 18/5/2021 1:55 π.μ., Michael Ströder wrote:
Missing space after SUBSTR?
On 18/5/2021 1:57 π.μ., Howard Chu wrote:
Yes, but there is only one attribute value #2 in the attribute. Pay attention to what the error message tells you.
You were both right, thank you.
Turns out that all trailing spaces of the copied (and inserted) ldif sections were cut off (obviously during the copy process), so I had to manually add them in wrapped lines which happened to be wrapped at a space character... Tricky.
It might be easier for such small schema changes to use a GUI LDAP client to avoid exactly this kind of problem.
I don't see how that is relevant. The first problem is that he was trying to do a wholesale replace of a schema file. If instead he had just a diff of the old and new versions of the schema, he could of course have fed that into an ldapmodify operation - whether by GUI or by CLI.
Yes, he could have done this. With yet another tool required to create the LDIF diff. Or did you mean normal textual diff? This sometimes does not work.
With a normal input form it would have been pretty easy just to edit a single attribute value without piping stuff through several tools. It's one of the rare cases where a GUI is IMHO better.
Of course it's also a matter of personal taste.
Ciao, Michael.
Michael Ströder wrote:
On 5/18/21 6:23 PM, Howard Chu wrote:
Michael Ströder wrote:
On 5/18/21 10:28 AM, Nick Milas wrote:
On 18/5/2021 1:55 π.μ., Michael Ströder wrote:
Missing space after SUBSTR?
On 18/5/2021 1:57 π.μ., Howard Chu wrote:
Yes, but there is only one attribute value #2 in the attribute. Pay attention to what the error message tells you.
You were both right, thank you.
Turns out that all trailing spaces of the copied (and inserted) ldif sections were cut off (obviously during the copy process), so I had to manually add them in wrapped lines which happened to be wrapped at a space character... Tricky.
It might be easier for such small schema changes to use a GUI LDAP client to avoid exactly this kind of problem.
I don't see how that is relevant. The first problem is that he was trying to do a wholesale replace of a schema file. If instead he had just a diff of the old and new versions of the schema, he could of course have fed that into an ldapmodify operation - whether by GUI or by CLI.
Yes, he could have done this. With yet another tool required to create the LDIF diff. Or did you mean normal textual diff? This sometimes does not work.
With a normal input form it would have been pretty easy just to edit a single attribute value without piping stuff through several tools. It's one of the rare cases where a GUI is IMHO better.
I don't see how this makes the initial step any easier. Presumably he starts with an old version and new version schema file. How is a GUI going to let him create the diff between these any more easily than a command line? How does a GUI prevent a copy/paste from losing trailing spaces, any more reliably than a command line? Completely irrelevant.
Of course it's also a matter of personal taste.
Ciao, Michael.
On 5/19/21 1:02 PM, Howard Chu wrote:
Michael Ströder wrote:
On 5/18/21 6:23 PM, Howard Chu wrote:
Michael Ströder wrote:
On 5/18/21 10:28 AM, Nick Milas wrote:
On 18/5/2021 1:55 π.μ., Michael Ströder wrote:
Missing space after SUBSTR?
On 18/5/2021 1:57 π.μ., Howard Chu wrote:
Yes, but there is only one attribute value #2 in the attribute. Pay attention to what the error message tells you.
You were both right, thank you.
Turns out that all trailing spaces of the copied (and inserted) ldif sections were cut off (obviously during the copy process), so I had to manually add them in wrapped lines which happened to be wrapped at a space character... Tricky.
It might be easier for such small schema changes to use a GUI LDAP client to avoid exactly this kind of problem.
I don't see how that is relevant. The first problem is that he was trying to do a wholesale replace of a schema file. If instead he had just a diff of the old and new versions of the schema, he could of course have fed that into an ldapmodify operation - whether by GUI or by CLI.
Yes, he could have done this. With yet another tool required to create the LDIF diff. Or did you mean normal textual diff? This sometimes does not work.
With a normal input form it would have been pretty easy just to edit a single attribute value without piping stuff through several tools. It's one of the rare cases where a GUI is IMHO better.
I don't see how this makes the initial step any easier. Presumably he starts with an old version and new version schema file. How is a GUI going to let him create the diff between these any more easily than a command line?
In this particular case the admin would have just edited one or very few input field(s) and then hit the submit button.
BTW: web2ldap internally only applies diffs after user edited the entry.
How does a GUI prevent a copy/paste from losing trailing spaces, any more reliably than a command line?
I assume that in this particular case the admin was confused by line-wrapping and/or his text editor has whitespace-cleaning enabled. The latter is pretty usual.
We're talking here about behaviour of human beings which differs a lot (UX aspects). Thus your and my assumptions are subject to YMMV.
Ciao, Michael.
Michael Ströder wrote:
On 5/19/21 1:02 PM, Howard Chu wrote:
Michael Ströder wrote:
On 5/18/21 6:23 PM, Howard Chu wrote:
Michael Ströder wrote:
On 5/18/21 10:28 AM, Nick Milas wrote:
On 18/5/2021 1:55 π.μ., Michael Ströder wrote: > Missing space after SUBSTR? On 18/5/2021 1:57 π.μ., Howard Chu wrote: > Yes, but there is only one attribute value #2 in the attribute. Pay > attention to what the error message tells you.
You were both right, thank you.
Turns out that all trailing spaces of the copied (and inserted) ldif sections were cut off (obviously during the copy process), so I had to manually add them in wrapped lines which happened to be wrapped at a space character... Tricky.
It might be easier for such small schema changes to use a GUI LDAP client to avoid exactly this kind of problem.
I don't see how that is relevant. The first problem is that he was trying to do a wholesale replace of a schema file. If instead he had just a diff of the old and new versions of the schema, he could of course have fed that into an ldapmodify operation - whether by GUI or by CLI.
Yes, he could have done this. With yet another tool required to create the LDIF diff. Or did you mean normal textual diff? This sometimes does not work.
With a normal input form it would have been pretty easy just to edit a single attribute value without piping stuff through several tools. It's one of the rare cases where a GUI is IMHO better.
I don't see how this makes the initial step any easier. Presumably he starts with an old version and new version schema file. How is a GUI going to let him create the diff between these any more easily than a command line?
In this particular case the admin would have just edited one or very few input field(s) and then hit the submit button.
You're still missing the point. Unless you're saying the admin would eyeball the differences between the old schema and the new schema and manually type them into the GUI. That sounds like the worst of all possible worlds.
BTW: web2ldap internally only applies diffs after user edited the entry.
On 5/19/21 6:52 PM, Howard Chu wrote:
Michael Ströder wrote:
In this particular case the admin would have just edited one or very few input field(s) and then hit the submit button.>
You're still missing the point. Unless you're saying the admin would eyeball the differences
No, the admin should just copy & paste the whole new schema description string and the client validates that or the server indicates to the client which attribute values were wrong.
I've now implemented syntax checking for schema descriptions and olcSchemaConfig attrs in upcoming web2ldap 1.6.3+.
Hmm, it seems the tokenizer in ldap0.schema is too liberal, causing false positives. It was implemented that way to even parse seriously broken schema descriptions found on other LDAP servers. Will try to make that configurable somehow...
Ciao, Michael.
openldap-technical@openldap.org
-
Dameon Wagner -
Howard Chu -
Michael Ströder -
Nick Milas