[Date Prev][Date Next]
Re: v2.2.24 structural object class modification not allowed
- To: OpenLDAP software list <openldap-software@OpenLDAP.org>
- Subject: Re: v2.2.24 structural object class modification not allowed
- From: Curt Blank <email@example.com>
- Date: Tue, 03 May 2005 12:05:15 -0500
- In-reply-to: <8311E6B1436F3AA5384AAEF1@[10.0.0.1]>
- References: <4256CBE6.firstname.lastname@example.org> <4256FC6D.email@example.com> <firstname.lastname@example.org> <42576A54.email@example.com> <426176AB.firstname.lastname@example.org> <email@example.com> <4266A504.firstname.lastname@example.org> <4266B983.email@example.com> <4269F64A.firstname.lastname@example.org> <426A4F4D.email@example.com> <426D01C9.firstname.lastname@example.org> <426D0E8B.email@example.com> <426D178C.firstname.lastname@example.org> <426D1B56.email@example.com> <426D2386.firstname.lastname@example.org> <426DF07E.email@example.com> <firstname.lastname@example.org> <email@example.com> <42723C0B.firstname.lastname@example.org> <email@example.com> <42726EA9.firstname.lastname@example.org> <A51D3045424580C617FF7105@[10.0.0.1]> <4272913F.email@example.com> <A06AA19F394279E08E9AD6F7@[10.0.0.1]> <42729E3D.firstname.lastname@example.org> <8311E6B1436F3AA5384AAEF1@[10.0.0.1]>
- User-agent: Mozilla Thunderbird 1.0 (X11/20041206)
Just want to say thanks to all on this. With everyone's help I was able
to correct this problem and have a better understanding of things.
As a sidebar when I did this I removed structuralObjectClass, entryUUID,
and entryCSN from the dump and let them be recreated when slapadd
recreated the db. (After modifying the objectClass that couldn't be
added before doing the slapadd.)
Quanah Gibson-Mount wrote:
--On Friday, April 29, 2005 3:51 PM -0500 Curt Blank <email@example.com>
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:
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
in? as what ever it wants? I only ask because when I did the slapadd
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
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. ;)
Principal Software Developer
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html