Quanah Gibson-Mount wrote:
--On Friday, April 29, 2005 3:51 PM -0500 Curt Blank <curt@uwm.edu> wrote:
cat the dumped DB, pipe to sed "s/structuralObjectClass: ctCalUser/objectClass: ctCalUser/", redirect to new LDIF file.
cat X.ldif | sed "s/structuralObjectClass: ctCalUser/objectClass: ctCalUser/" >new.ldif
all off the top of my head, likely syntax to the sed bit.
Thanks. One last question here at least, can't I just remove the
structuralObjectClass attribute from the dump and let slapadd put it back
in? as what ever it wants? I only ask because when I did the slapadd from
2.0.27 it wasn't there but now it is. And for the ones that have it they
already have a objectClass: ctCalUser attribute. My real problem is the
ones that have the objectClass: uwmPerson but need to have it be
ctCalUser. If I were to change every structuralObjectClass: uwmPerson to
structuralObjectClass: ctCalUser without that dn having the objectClass:
ctCalUser attribute would that fail? Just curious. Don't think I want to
do that. Following your #2 suggestion seems like the way I will go. When
I do that and assuming I just remove structuralObjectClass from the dump
and do the slapadd, then will structuralObjectClass be uwmPerson for all?
And will that be ok and ctCalUser then being AUXILIARY be able to be
added by the Calendar server when needed to add a new user?
Hm, yeah, you should actually just be able to pull out all instances of structural, and then reload, and I think it will all work right. Then yes, the Calendar server can likely add a new user. ;)
--Quanah
-- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html