ken wrote:
Graham Seaman wrote:
I'm tinkering with new schema as well as including the standard
eduPerson
Perhaps best to get it working with the standard before changing
anything?
Well, it does work on another Fedora install so I know there's nothing
syntactically wrong with the schema. But I just know I'm going to have
to make changes to my new schema after the thing goes live... (I'm not
modifying eduPerson, the new schema is something separate)
and was hoping to avoid having to strip out all the data and then
repopulate each time I make a minor change to the schema.
That should not be neccessary unless your new or altered schema
removed or redefines attributes or classes that are already in place
in the directory. I added three or four new schemata to the directory
I just installed, including EduPerson, and each time the data remained
in place but I became able to add new attribute types to existing
directory objects
OK, that's the way I thought it should work. So I must have something
setup wrong. What Fedora version are you using?
What order are you loading the schema files in? (Controlled by the
two digits at the start of the file name)
60pam-plugin.ldif
65eduperson200806.ldif
70edumember.ldif
80testperson.ldif
99user.ldif
> I'm
populating it from a large Active Directory by script, which already
has quite a long run time.
Pretty much exactly what I'm doing!
But I don't have any users in the directory at all yet, which is why
I was a bit surprised at the behaviour. I thought at least adding new
users with a new schema wouldn't be a problem. I guess if that is
out the next thing I need to check is what happens if I add a new
'may' field to an existing schema - will it force me to drop all the
old data to install that, too.
I do not think it should not do this at all. As far as I know adding
EduPerson (or any other new schema) ought not to change what is in the
directory already as long as you do not delete or redefine old
classes or attributes that are used by existing entries.
Are there no error messages at startup?
None. Maybe I should look at increasing the log level. But I just
realised the admin server (which I'm not using) does have a problem -
[13:39 g_seaman@enterprise1:~/Ldap] sudo /etc/init.d/dirsrv-admin start
Starting dirsrv-admin:
grep: /etc/dirsrv/admin-serv/adm.conf: No such file or directory
/var/run/dirsrv is not writable for
Odd, since /var/run/dirsrv is world writeable (and the main directory is
writing to it fine). But there genuinely is no adm.conf. All the same, I
can't see how this would relate to my original problem.
Does the "new schema" you say you are "tinkering with" contain any
attributes or classes with the same names or OIDs as ones in any other
schema?
No. It works fine in another fedora-ds install anyway. It's mainly just
to mop up a few Active Directory attributes I want to keep which don't
have equivalents in the other schema I'm using (things like department
(not departmentNumber), coursecode, etc). It's there exactly because
those names don't exist anywhere else.
Does the version of the eduPerson schema you are using contain a
"changetype:" or any "add:" or "delete:" attributes? (I had to strip
them all out to get mine working because Fedora didn't like an attempt
to modify things that didn't exist)
No, I didn't even know you could do that in a schema. Mine is a straight
version of the latest one on the educause site.
I wouldn't want to bet on what happens if a class is defined in one
schema, then referred to in another, then redefined in a third!
Nor me, but I'm sure that's not the problem.
Graham
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
