On 11/1/05 2:07 pm, Christopher A Bongaarts <[EMAIL PROTECTED]> wrote:
> In the immortal words of Ronan McGlue:
>> Hi all, problem as follows... (im not subscribed so could you reply
>> directly to me... thanks)
>>
>> i create an LDAP:Entry object as follows
>>
>> $list{'entry'} = {
>> 'objectClass' => ['top' ,'mjDistributionList'],
>> 'cn' => ["AUT"],
>> 'mj_admin_passwd' => ["password"],
>> 'mj_moderate' => ['TRUE'],
>> 'owner' => [$list_owner],
>> 'description' => ["AUT mailing list"],
>> 'mj_approve_passwd' => ["aut.approve"],
>> 'mj_submit_policy' => ["restricted"],
>> 'mj_subscribe_policy' => ["closed"],
>> 'mj_restrict_post' => [EMAIL PROTECTED],
>> 'mj_DLMembers' => []
>> };
>>
>>
>> I populate mj_DLMembers
>>
>> then execute
>>
>> $ret = $ldap->add(dn=>$dn,attrs => [EMAIL PROTECTED]'entry'}]);
>> if ($ret != LDAP_SUCCESS){
>> $ret->code && warn "failed to add entry: ", $ret->error ;
>> } else {
>> print "Added $rdn successfully\n";
>> };
>>
>>
>>
>>
>> I continually get the follwoing output
>>
>> failed to add entry: Object class violation at ./e2.pl line 83.
>> line 83 is the code && warn line
>> $ret->code && warn "f....
>>
>> any clues? have i specified the attributes for the entry badly? i know
>> our directory structure will be different to yours but have I covered
>> the basics of Net::ldap?
>
> A couple things to try:
>
> (1) I suspect both top and mjDistributionList are structural
> objectClasses, so you can only specify one or the other. top is
> implicitly inherited by all other objectClasses, so it may be as
> simple as removing top from the objectClass value list.
'top' is defined as abstract, so if 'mjDistributionList' is structural, it
is correct to list both. But since we don't know Ronan's schema...
> (2) Failing that, the error suggests that you are not setting an
> attribute that the mjDistributionList objectClass requires. Check
> your schema to see if you're missing anything. I note that the mj_*
> attributes do not follow the usual LDAP/X.500 conventions for
> attribute naming, so that seems a bit odd, but not necessarily
> broken.
I would also suggest putting in a 'use strict;' at the top of the script,
and fixing any errors that it noticed :-)
Cheers,
Chris
