Console and Schema Attribute Errors

[Thad]

I have single master/replica setup and information is flowing. After the sync I had 2 issues. First issue is within the console. After syncing from the 8.2 master to the 9.1 replica I can no longer access any of the items in the server group on the replica.. Clicking on Administration server or the dirsrv instance gives an error.  "Failed to install a local copy of redhat-ds-8.2.jar or one of its supporting files. Please ensure that the appropriate console package is installed on the administration server. redhat-ds-8.2jar not found at http://dir.mycomp.org:9830/". So not sure if I need to find the redhat-ds-8.2.jar file on the master and install it on the replica, run setup-ds-admin.pl -u or if this is normal behavior for the replica?

The second issue are schema issues. Initially I copied the /etc/dirsrv/slapd-inst/schema/99user.ldif file over from the master to the replica and it took care of most of the schema errors. However I am still getting the following error:

[25/Feb/2020:08:38:15 -0500] NSACLPlugin - __aclp__init_targetattr: targetattr "ssn" does not exist in schema. Please add attributeTypes "ssn" to schema if necessary.
[25/Feb/2020:08:38:15 -0500] NSACLPlugin - ACL PARSE ERR(rv=-5): (targetattr  = "ssn
[25/Feb/2020:08:38:15 -0500] NSACLPlugin - Error: This  ((targetattr != "ssn || userPassword") (version 3.0;acl "Directory Comparator";allow (read,compare,search)(userdn = "ldap:///uid=comparator,ou=Special Users,o=dir.mycomp.org");)) ACL will not be considered for evaluation because of syntax errors.

I have looked at the attributes in schema under the instance's configuration tab (within the master's console) but there isn't an ssn attribute that I can find. I see userPassword attribute. Not sure how to proceed from here.

[William Brown]

> On 26 Feb 2020, at 03:22, Thad  wrote:
>
> I have single master/replica setup and information is flowing. After the sync I had 2 issues. First issue is within the console. After syncing from the 8.2 master to the 9.1 replica I can no longer access any of the items in the server group on the replica.. Clicking on Administration server or the dirsrv instance gives an error.  "Failed to install a local copy of redhat-ds-8.2.jar or one of its supporting files. Please ensure that the appropriate console package is installed on the administration server. redhat-ds-8.2jar not found at http://dir.mycomp.org:9830/". So not sure if I need to find the redhat-ds-8.2.jar file on the master and install it on the replica, run setup-ds-admin.pl -u or if this is normal behavior for the replica?

You have an 8.2 supplier and a 9.1 consumer, so probably the best strategy here is to get everything upgraded to 9.1 as soon as possible to get everything consistent.
> The second issue are schema issues. Initially I copied the /etc/dirsrv/slapd-inst/schema/99user.ldif file over from the master to the replica and it took care of most of the schema errors. However I am still getting the following error:
>
> [25/Feb/2020:08:38:15 -0500] NSACLPlugin - __aclp__init_targetattr: targetattr "ssn" does not exist in schema. Please add attributeTypes "ssn" to schema if necessary.
> [25/Feb/2020:08:38:15 -0500] NSACLPlugin - ACL PARSE ERR(rv=-5): (targetattr  = "ssn
> [25/Feb/2020:08:38:15 -0500] NSACLPlugin - Error: This  ((targetattr != "ssn || userPassword") (version 3.0;acl "Directory Comparator";allow (read,compare,search)(userdn = "ldap:///uid=comparator,ou=Special Users,o=dir.mycomp.org");)) ACL will not be considered for evaluation because of syntax errors.
>
> I have looked at the attributes in schema under the instance's configuration tab (within the master's console) but there isn't an ssn attribute that I can find. I see userPassword attribute. Not sure how to proceed from here.

99user.ldif is not the only place where custom schema can live. IIRC in DS 10 (?) we have schema replication, but we may not have it in 8.2/9.1.

It's likely worth checking that the /etc/dirsrv/slapd-instancename/schema/*.ldif files match on both your instances. for example, someone may have added 90customschema.ldif or similar which is providing the ssn attribute.

You can also check by searching cn=schema to see what the servers attributes and classes are supported, and see if there are differences.

ldapsearch -H ldap://<LDAPURL> -b cn=schema -x +

Hope that helps,
> 389-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs

[Thad]

There are 2 LDIF files on the old server (01Common, 05RFC2247) that don't exist on the new server but no luck in finding that line. I went ahead and did a grep of the files in the schema directory on both servers and couldn't find that entry in either place.

Is it possible to do a master/replica from DS 8.2 to 10 to take advantage of the schema replication?

[Mark Reynolds]

On 2/26/20 12:43 PM, Thad wrote:
> There are 2 LDIF files on the old server (01Common, 05RFC2247) that don't exist on the new server but no luck in finding that line. I went ahead and did a grep of the files in the schema directory on both servers and couldn't find that entry in either place.
>
> Is it possible to do a master/replica from DS 8.2 to 10 to take advantage of the schema replication?

This could work as a migration technique, but I would not use it as a 
long term solution.

As for the console issue, I'm not sure why the jar files are not 
downloading.  Hopefully they were not removed, but you should be able to 
find a copy on the FS.  Check on the master or replica for 
~/.redhat-ds-console/jars/redhat-*.jar

If you find them then you can manually add them on the other server 
under ~/.redhat-ds-console/jars/

Also it would not hurt to run "setup-ds-admin.pl -u".  It just runs 
these upgrade scripts and it's ok if they get run multiple times.

As for the schema issue, the ACL is complaining that you are using an 
attribute that does not exist in the schema the ACI will be ignored.  So 
you should add "ssn" to the schema, or change the aci to not use "ssn".  
If you have "ssn" in your custom schema its in 
/etc/dirsrv/slapd-YOUR_ISNTNCE/schema/99user.ldif then you just need to 
restart the server or run the schema-reload.pl script.

HTH,

Mark
> 389-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....