[Fedora-directory-users] forcing reload?
Graham Seaman
G.Seaman at lse.ac.uk
Mon Aug 4 12:50:23 UTC 2008
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 at 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
More information about the Fedora-directory-users
mailing list