Hello list,
Just a newbie question: I try to create a simple addressbook in LDAP and I just wondered why there is no country attribute in the standard structure:
objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson
Just an "st" attribute, but this should not be used for a country AFAIK. Is there an easy way to add the country or friendlyCountryName as a MAY attribute without having to create my own objectClass?
R.
richard lucassen wrote:
I just wondered why there is no country attribute in the standard structure:
objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson
As you already noticed 'c' (two-letter ISO-3166 country code) is not available in 'inetOrgPerson'.
Is there an easy way to add the country or friendlyCountryName as a MAY attribute without having to create my own objectClass?
No. You might have additionally schema locally installed providing an AUXILIARY object class for person entries. But you have to dig your installed schema yourself.
It's not that hard to define custom schema.
You may also use 'msPerson' AUXILIARY object class defined herein: https://www.stroeder.com/stroeder.com.schema
Ciao, Michael.
On Sat, 30 Sep 2017 13:29:30 +0200 Michael Ströder michael@stroeder.com wrote:
Is there an easy way to add the country or friendlyCountryName as a MAY attribute without having to create my own objectClass?
No. You might have additionally schema locally installed providing an AUXILIARY object class for person entries. But you have to dig your installed schema yourself.
It's not that hard to define custom schema.
No, I was already playing with a custom schema, but for a newbie it's not quite clear matter, there is a lot of outdated doc out there. But anyway, I succeeded to load my own schema into the cn=config structure :)
You may also use 'msPerson' AUXILIARY object class defined herein: https://www.stroeder.com/stroeder.com.schema
Thnx, I'll have a closer look at it :)
BTW: I tried to use the "c" attribute in my AUXILIARY objectclass, but slapd complains that it conflicts with the existing "c". I suppose this is because I applied different properties to it?
R.
richard lucassen wrote:
BTW: I tried to use the "c" attribute in my AUXILIARY objectclass, but slapd complains that it conflicts with the existing "c". I suppose this is because I applied different properties to it?
Do not re-define attribute type "c".
Simply define your own object class referencing _existing_ attribute type description "c".
Ciao, Michael.
On Sat, 30 Sep 2017 15:30:07 +0200 Michael Ströder michael@stroeder.com wrote:
BTW: I tried to use the "c" attribute in my AUXILIARY objectclass, but slapd complains that it conflicts with the existing "c". I suppose this is because I applied different properties to it?
Do not re-define attribute type "c".
Simply define your own object class referencing _existing_ attribute type description "c".
But I have to give it a different name (e.g. "cty") though, right or wrong? Something like this:
attributetype ( 1.3.6.1.4.1.10624.1.50 NAME 'cty' DESC 'Country' SUP c )
I now defined an independend "cty":
attributetype ( 1.3.6.1.4.1.10624.1.50 NAME 'cty' DESC 'country' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
It works, but I have no idea if this is dirty or not.
R.
Am Sat, 30 Sep 2017 20:34:51 +0200 schrieb richard lucassen mailinglists@lucassen.org:
On Sat, 30 Sep 2017 15:30:07 +0200 Michael Ströder michael@stroeder.com wrote:
BTW: I tried to use the "c" attribute in my AUXILIARY objectclass, but slapd complains that it conflicts with the existing "c". I suppose this is because I applied different properties to it?
Do not re-define attribute type "c".
Simply define your own object class referencing _existing_ attribute type description "c".
But I have to give it a different name (e.g. "cty") though, right or wrong? Something like this:
attributetype ( 1.3.6.1.4.1.10624.1.50 NAME 'cty' DESC 'Country' SUP c )
I now defined an independend "cty":
attributetype ( 1.3.6.1.4.1.10624.1.50 NAME 'cty' DESC 'country' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
It works, but I have no idea if this is dirty or not.
As Michael mentioned, define an auxiliary object class and attribute type countryName, c as a MUST.
-Dieter
richard lucassen wrote:
On Sat, 30 Sep 2017 15:30:07 +0200 Michael Ströder michael@stroeder.com wrote:
BTW: I tried to use the "c" attribute in my AUXILIARY objectclass, but slapd complains that it conflicts with the existing "c". I suppose this is because I applied different properties to it?
Do not re-define attribute type "c".
Simply define your own object class referencing _existing_ attribute type description "c".
But I have to give it a different name (e.g. "cty") though, right or wrong?
No. Why?
An object class description may reference any attribute type description present in the schema (and defined in configuration _before_ the object class).
Just add 'c' to the MAY part in your object class description.
You should declare your own attribute type description if the attribute has another semantic.
Ciao, Michael.
On Sun, 1 Oct 2017 10:27:41 +0200 Michael Ströder michael@stroeder.com wrote:
But I have to give it a different name (e.g. "cty") though, right or wrong?
No. Why?
An object class description may reference any attribute type description present in the schema (and defined in configuration _before_ the object class).
Just add 'c' to the MAY part in your object class description.
You should declare your own attribute type description if the attribute has another semantic.
Ok, I'll try that, I was afraid that my own "c" would inherit the MUST of the original "c" as well.
Thnx for the answers and your time.
R.
Am Sonntag, 01. Oktober 2017 20:12 CEST, richard lucassen mailinglists@lucassen.org schrieb:
Ok, I'll try that, I was afraid that my own "c" would inherit the MUST of the original "c" as well.
Attributes don't have MUST or MAY - Object class definitions regulate MUST/MAY.
Cheers, Ralf Mattes
richard lucassen wrote:
I was afraid that my own "c" would inherit the MUST of the original "c" as well.
Attribute types only inherit from their SUP attribute type. There's no MUST in an attribute type description.
Object classes inherit the MUST from their SUP object classes. But if you define your own auxiliary object class with SUP top there's no MUST attribute list.
Ciao, Michael.
On Sun, 1 Oct 2017 20:34:23 +0200 Michael Ströder michael@stroeder.com wrote:
I was afraid that my own "c" would inherit the MUST of the original "c" as well.
Attribute types only inherit from their SUP attribute type. There's no MUST in an attribute type description.
Object classes inherit the MUST from their SUP object classes. But if you define your own auxiliary object class with SUP top there's no MUST attribute list.
I've got it up and running now. It works like a charm :)
R.
openldap-technical@openldap.org
-
Dieter Klünter -
Michael Ströder -
Ralf Mattes -
richard lucassen