[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