3:39 p.m.
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
3:55 p.m.
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.
1:28 a.m.
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
4:54 a.m.
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.
9:23 a.m.
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
10:11 a.m.
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.
4:02 a.m.
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
6:42 a.m.
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.
9:52 a.m.
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
10:58 a.m.
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.
6:29 a.m.
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.
--
<> ><> ><> ><> ><>
><> ooOoo <>< <>< <>< <>< <><
<><
Dr. Dameon Wagner, Unix Platform Services
IT Services, University of Oxford
<> ><> ><> ><> ><>
><> ooOoo <>< <>< <>< <>< <><
<><
3:57 p.m.
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 )
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
4:58 a.m.
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.
858
days inactive
860
days old
openldap-technical@openldap.org
12 comments
4 participants
participants (4)
-
Dameon Wagner -
Howard Chu -
Michael Ströder -
Nick Milas