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
