Extending the schema

[Johnnie Adams]

Hi, folks,

I thought this would be as simple as moving *.ldif files from our old
directory server's schema directory to the new one, but this appears not to
be working.

I suspect this is a deep subject, so I'll stop here.

Thanks,

John A

[William Brown]

> On 22 Nov 2025, at 06:52, Johnnie Adams via 389-users  wrote:
>
> Hi, folks,
>  I thought this would be as simple as moving *.ldif files from our old directory server's schema directory to the new one, but this appears not to be working.

What "brand" of directory server are you moving from? IIRC there might be some format differences between the schema in some directories compared to 389-ds.

Also what makes you think it's "not working"? Does your imported schema appear in cn=schema if you query it?
>  I suspect this is a deep subject, so I'll stop here.
>
> Thanks,
>  John A

[Mark Reynolds]

On 11/21/25 7:21 PM, William Brown via 389-users wrote:
> > On 22 Nov 2025, at 06:52, Johnnie Adams via 389-users 
> >  wrote:
> >
> > Hi, folks,
> >
> > I thought this would be as simple as moving *.ldif files from 
> > our old directory server's schema directory to the new one, but this 
> > appears not to be working.
>
> What "brand" of directory server are you moving from? IIRC there might 
> be some format differences between the schema in some directories 
> compared to 389-ds.
>
> Also what makes you think it's "not working"? Does your imported 
> schema appear in cn=schema if you query it?

Also, where are you moving it to exactly?  Did you restart the server or 
run the schema reload task afterwards?

Mark
> > I suspect this is a deep subject, so I'll stop here.
> >
> > Thanks,
> >
> > John A
>
> -- 
> Sincerely,
>
> William Brown
>
> Senior Software Engineer,
> Identity and Access Management
> SUSE Labs, Australia

[Johnnie Adams]

Hi, folks,

Sorry for the slow response. Things got busy.
> On 11/21/25 7:21 PM, William Brown via 389-users wrote:

What "brand" of directory server are you moving from? IIRC there might be
> some format differences between the schema in some directories compared to
> 389-ds.

I'm moving from OpenDJ.
> Also what makes you think it's "not working"? Does your imported schema
> appear in cn=schema if you query it?
>
> The imported schema does appear. However, at least one attribute is acting

wonky. I can't load an ldif file containing it. I get this:

#!ERROR  [LDAP result code 65 - objectClassViolation] attribute
"mailUserStatus" not allowed

Entries which do have it show it in the Apache Directory browser in italics
and are completely uncapitalized.

On Sat, Nov 22, 2025 at 11:55 AM Mark Reynolds  wrote:
> Also, where are you moving it to exactly?  Did you restart the server or
> run the schema reload task afterwards?

I couldn't tell from the documentation whether to put it into
/etc/dirserv/schema or /etc/dirserv/slapd-mail/schema, so I put it into
both and restarted the server.

Thanks,

John A

[Thierry Bordaz]

On 12/2/25 4:45 PM, Johnnie Adams via 389-users wrote:
> Hi, folks,
>
> Sorry for the slow response. Things got busy.
> On 11/21/25 7:21 PM, William Brown via 389-users wrote:
>
> What "brand" of directory server are you moving from? IIRC there
> might be some format differences between the schema in some
> directories compared to 389-ds.
>
>
> I'm moving from OpenDJ.
> > Also what makes you think it's "not working"? Does your imported
> > schema appear in cn=schema if you query it?
>
> The imported schema does appear. However, at least one attribute is 
> acting wonky. I can't load an ldif file containing it. I get this:
>
> #!ERROR[LDAP result code 65 - objectClassViolation] attribute 
> "mailUserStatus" not allowed

If you added your schema definitions, 'mailUserStatus' should be present 
in the schema. You may search the attribute on suffix 'cn=schema' with 
'attributetypes' and 'objectclasses' attributes to confirm they are 
available. If a definition can not be loaded you will find a error 
message in error log.
The above message means that added/updated entry has not the objectclass 
allowing 'mailUserStatus'. Looking in access logs for err=65 you will 
identify what is the target entry.
> Entries which do have it show it in the Apache Directory browser in 
> italics and are completely uncapitalized.
>
> On Sat, Nov 22, 2025 at 11:55 AM Mark Reynolds  
> wrote:
> Also, where are you moving it to exactly?  Did you restart the
> server or run the schema reload task afterwards?
>
> I couldn't tell from the documentation whether to put it into 
> /etc/dirserv/schema or /etc/dirserv/slapd-mail/schema, so I put it 
> into both and restarted the server.

I suggest that you use UI or dsconf to update your schema. Else you can 
manually drop it in schema directory see 
https://docs.redhat.com/en/documentation/red_hat_directory_server/13/html/ma...
> Thanks,
>
> John A

[Johnnie Adams]

On Tue, Dec 2, 2025 at 10:16 AM Thierry Bordaz via 389-users <
[e-mail]> wrote:

If you added your schema definitions, 'mailUserStatus' should be present in
> the schema. You may search the attribute on suffix 'cn=schema' with
> 'attributetypes' and 'objectclasses' attributes to confirm they are
> available. If a definition can not be loaded you will find a error message
> in error log.

I don't find an error; I do find a listing when I search:

objectclasses: ( 2.16.840.1.113730.3.2.146 NAME 'inetMailUser' DESC
'auxiliary

class for a messaging server user' SUP top AUXILIARY MAY (
mailDeliveryOptio

n $ mailForwardingAddress $ mailAlternateAddress $ mail $ mailUserStatus $
ma

ilAllowedServiceAccess ) X-ORIGIN 'Sun ONE Messaging Server' X-SCHEMA-FILE
'9

5-mail.ldif' )
> The above message means that added/updated entry has not the objectclass
> allowing 'mailUserStatus'. Looking in access logs for err=65 you will
> identify what is the target entry.

I didn't find the access log entry terribly informative:

[02/Dec/2025:09:31:09.233659798 -0600] conn=62436 op=13 RESULT *err=65*
tag=105 nentries=0 wtime=0.000191603 optime=0.005365186 etime=0.005553484 -
attribute "mailUserStatus" not allowed

Thanks,

John A

[Thierry Bordaz]

On 12/2/25 5:39 PM, Johnnie Adams wrote:
> On Tue, Dec 2, 2025 at 10:16 AM Thierry Bordaz via 389-users 
>  wrote:
> If you added your schema definitions, 'mailUserStatus' should be
> present in the schema. You may search the attribute on suffix
> 'cn=schema' with 'attributetypes' and 'objectclasses' attributes
> to confirm they are available. If a definition can not be loaded
> you will find a error message in error log.
>
> I don't find an error; I do find a listing when I search:

Good so the all definitions were valid
> objectclasses: (2.16.840.1.113730.3.2.146 NAME 'inetMailUser' DESC 
> 'auxiliary
>
> class for a messaging server user' SUP top AUXILIARY MAY ( 
> mailDeliveryOptio
>
> n $ mailForwardingAddress $ mailAlternateAddress $ mail $ 
> mailUserStatus$ ma
>
> ilAllowedServiceAccess ) X-ORIGIN 'Sun ONE Messaging Server' 
> X-SCHEMA-FILE '9
>
> 5-mail.ldif' )
> The above message means that added/updated entry has not the
> objectclass allowing 'mailUserStatus'. Looking in access logs for
> err=65 you will identify what is the target entry.
>
>
> I didn't find the access log entry terribly informative:

doing 'grep "conn=62436 op=13 " /var/lib/dirsrv/slapd-instance/access' 
will give the target entry, then you can look if this entry is missing 
or not 'objectclass: inetMailUser'
> [02/Dec/2025:09:31:09.233659798 -0600] conn=62436 op=13 RESULT 
> *err=65*tag=105 nentries=0 wtime=0.000191603 optime=0.005365186 
> etime=0.005553484 - attribute "mailUserStatus" not allowed
>
> Thanks,
>
> John A

[Johnnie Adams]

Hi,

On Tue, Dec 2, 2025 at 12:08 PM Thierry Bordaz  wrote:
> doing 'grep "conn=62436 op=13 " /var/lib/dirsrv/slapd-instance/access'
> will give the target entry, then you can look if this entry is missing or
> not 'objectclass: inetMailUser'

The target entry doesn't yet exist. This was an attempt to create an entry

Thanks,

John A