On 5/1/20 10:50 am, Brian Burch wrote:
On 5/1/20 10:00 am, Emmanuel Lécharny wrote:
On 04/01/2020 23:59, Brian Burch wrote:
On 5/1/20 2:45 am, Emmanuel Lécharny wrote:
Hi Brian,
it works for me, but I have added the MUST attributes homeDirectory
and uid (from posixAccount):
objectclass ( 1.3.6.1.1.1.2.0 NAME 'posixAccount'
DESC 'Abstraction of an account with POSIX attributes'
SUP top
AUXILIARY
MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )
MAY ( userPassword $ loginShell $ gecos $ description ) )
Your LDIF does dot add those two mandatory attributes. the error
message is not appropriate though...
Thanks for your quick and helpful reply, Emmanuel.
Yes, that was my own conclusion. However, the best of my google
searches ALL turn up with the same ldif that worked successfully
under the M23 schema.
Do you mean that this ldif worked with M23 ?
Yes!
Here is the ldapEntry copied with studio from my own M23 directory which
is running in production:-
dn: m-oid=1.3.6.1.1.1.2.0,ou=objectClasses,cn=nis,ou=schema
objectclass: top
objectclass: metaTop
objectclass: metaObjectClass
m-oid: 1.3.6.1.1.1.2.0
m-description: Abstraction of an account with POSIX attributes
m-may: userPassword
m-may: loginShell
m-may: gecos
m-may: description
m-must: cn
m-must: uid
m-must: uidNumber
m-must: gidNumber
m-must: homeDirectory
m-name: posixAccount
m-obsolete: FALSE
m-supobjectclass: top
m-typeobjectclass: AUXILIARY
Obviously, all the MAYs and MUSTs are defined. I have no evidence or
memory of me having hacked this schema myself in the past. I'm pretty
sure I just enabled it and then created the atomic ldif to add the the
extra objectClass in the same ldapmodify as adding the attribute values.
I keep this ldif in my source repository.
Obviously, one of our devs updated cn=nis,ou=schema in either M24 or
M25, so now the advice on the internet is both wrong and confusing..
Can you proivide the pointers on the internet pages you are mentionning?
I found quite a few which were related, but this was the most explicit:-
https://stackoverflow.com/questions/52604987/apacheds-gidnumber-not-declared-in-objectclasses
Note particularly the answer section, which states "Since the
objectClass has mandatory attributes, this needs to be performed as a
single operation."
The PosixAccount ObjectClass hasn't been changed since 2011...
Wow! I don't know what to say! I installed M25 from git quite recently
and it must have come with the "broken" schema because I didn't change it.
How do you explain the fact that you needed to hack your own local schema?
Clearly we need to figure out what is going on here.
I'm getting out of my depth here, but this is the "newest" rfc I can
find and its status is "experimental"
https://tools.ietf.org/html/rfc2307
The schema is exactly as we expect to see.
Also, there is a copy in the openldap documentation:-
https://www.zytrax.com/books/ldap/ape/nis.html
which also has the MAYs and MUSTs we expect in the posixAccount objectclass.
Do you agree the nis schema from 2011 is also the "broken" version?
Do you know how our project generates this schema? Is it automatically
cloned from some external repository, or simply maintained manually?
Puzzled and not able to make any progress..
Brian
Can you shed any light on the reason for this change? I though the
registered owner of the nis schema OID space made the decision about
its content, while the apacheds project merely accepted any changes
and (of course) is free to maintain the m-disabled switch as it
wishes...
I don't have my new M25 system running at the moment, but am I right
in thinking this current M25 schema makes the posixAccount
objectClass almost pointless? It's only use would be as a search term.
I can't see why ANY ldap object at all could not have the uidNumber,
etc, attributes assigned to it once the nis schema has been enabled?
I haven't tried yet, but these ldap attributes don't seem to be
defined in any objectClass that I could find...
uidNumber AT is used by the posixAccount, sambaUnixIdPool and
sambaIdmapEntry ObjectClass.
WDYT? I don't want to change the schema back to M23 (like you did!)
without a good reason, because simply circumventing the current
problem doesn't feel right to me. There's the matter of the
misleading google searches, too!
Again, there was no schema change made since a very long time, and
certainly not between M23 and M25.
There must be something else that cause your issue (and again, I did
check on my current trunk, and the ObjetClass change just works).
Regards,
Brian
On 04/01/2020 07:28, Brian Burch wrote:
I am currently trying to do a clean setup of a new M25 installation
using and adapting the set of ldapmodify jobs I successfully used
many years ago for my production M23 system (which still works fine).
I've hit quite a few issues with additional schema elements, so I
decided to take it slow and easy to just get the posix stuff
working first. It has been driving me pretty crazy and I really
can't work out what is wrong.
Of course, I have modified:-
dn: cn=nis,ou=schema
changetype: modify
replace: m-disabled
m-disabled: FALSE
... and restarted the server. Studio confirms my change is active.
Here is the existing basic user definition (copied as ldif with
studio):-
dn: uid=brian,ou=people,o=pingtoo.com
objectclass: inetOrgPerson
objectclass: organizationalPerson
objectclass: person
objectclass: top
cn: Brian E. Burch
sn: Burch
givenname: Brian
uid: brian
userPassword::
e1NTSEF9WWsvOXZhN3ZtNkxBemhYeURmOEczNjhPSjJndGkwazNJeVphelE9P
Q==
So now I try to make a very simple change to turn my ldapentry into
a posixUser:-
dn: uid=brian,ou=People,o=pingtoo.com
changetype: modify
replace: objectClass
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
-
add: uidNumber
uidNumber: 2000
-
add: gidNumber
gidNumber: 2000
But it fails as follows:
ldap_initialize( ldap://ldap.pingtoo.com:10389 )
replace objectClass:
top
person
organizationalPerson
inetOrgPerson
posixAccount
add uidNumber:
2000
add gidNumber:
2000
modifying entry "uid=brian,ou=People,o=pingtoo.com"
ldap_modify: Object class violation (65)
additional info: OBJECT_CLASS_VIOLATION: failed for MessageType
: MODIFY_REQUEST
Message ID : 2
Modify Request
Object : 'uid=brian,ou=People,o=pingtoo.com'
Modification[0]
Operation : replace
Modification
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount Modification[1]
Operation : add
Modification
uidNumber: 2000 Modification[2]
Operation : add
Modification
gidNumber:
2000org.apache.directory.api.ldap.model.message.ModifyRequestImpl@4477d5e7:
ERR_277 Attribute gidNumber not declared in objectClasses of entry
uid=brian,ou=People,o=pingtoo.com
modify ended with rc 65
So I take a look at cn=nis,ou=schema..
* the attributes m-oid 1.3.6.1.1.1.1.0 uidNumber and
1.3.6.1.1.1.1.1 gidNumber are defined.
* the objectClass m-oid 1.3.6.1.1.1.2.0 posixAccount is defined as
structural, metaTop, BUT it does NOT have MAY or MUST entries for
uidNumber or gidNumber!
* I have searched all the other nis objectClasses, but can't find
any reference to the attributes I want to associate with my user. I
can't find the less important ones either, e.g. loginShell,
homeDirectory or gcos.
It has been a long time since I last did this kind of basic setup,
so I accept I have probably overlooked something simple and obvious.
HOWEVER... when I look at the M23 schema, objectClass=posixAccount
has MUST for uidNumber, gidNumber and homeDirectory. It also has
MAY for the other attributes I want to associate with this user.
Why the difference?
I would be grateful if anyone wiser could let me know how to get
past this show-stopper.
Thanks...
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
