Note: found in debugging/testing ticket 47973.
Steps:
cat > /path/to/99user.ldif << EOF dn: cn=schema attributetypes: ( 8.9.10.11.12.13.14 NAME 'MozillaAttribute' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Mozilla Dummy Schema' ) objectclasses: ( 1.2.3.4.5.6.7 NAME 'MozillaObject' SUP top MUST ( objectclass $ cn ) MAY ( givenName $ sn $ MozillaAttribute ) X-ORIGIN 'user defined' ) EOF
schema-reload.pl -Z SERVERINST -D 'cn=directory manager' -W <== expect to success
ldapsearch returns, e.g. "MAY ( givenName $ sn $ MozillaAttribute )"
cat > /path/to/98user.ldif << EOF dn: cn=schema attributetypes: ( 8.9.10.11.12.13.140 NAME 'MozillaAttribute' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Mozilla Dummy Schema' ) objectclasses: ( 1.2.3.4.5.6.70 NAME 'MoZiLLaOBJeCT' SUP top MUST ( objectclass $ cn ) MAY ( givenName $ sn $ MoZiLLaATTRiBuTe ) X-ORIGIN 'user defined' ) EOF Note: the objectclasses and attributetypes have different OIDs.
schema-reload.pl -Z SERVERINST -D 'cn=directory manager' -W <== expect to fail. check it in the error log.
Although the reload failed, ldapsearch returns, e.g. 1.2.3.4.5.6.70 and "MAY ( givenName $ sn $ MoZiLLaATTRiBuTe )"
If you try to restart the server, it refuses to start due to the invalid schema.
The problem is observed on rhel6 as well as on the local build from the master branch.
Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1417342
Metadata Update from @nhosoi: - Issue set to the milestone: 1.3.6.0
Metadata Update from @mreynolds: - Issue close_status updated to: None - Issue set to the milestone: 1.3.7.0 (was: 1.3.6.0)
Metadata Update from @mreynolds: - Issue assigned to mreynolds
I can not reproduce this behavior, adding CI test to confirm
<img alt="0001-Ticket-49092-Add-CI-test-for-schema-reload.patch" src="/389-ds-base/issue/raw/files/cf6f75525dc4eca61a79ab5e093ea0b92d81512025b169ded542c818f08be196-0001-Ticket-49092-Add-CI-test-for-schema-reload.patch" />
Metadata Update from @mreynolds: - Custom field reviewstatus adjusted to review
Tested on 1.3.6.1-16.el7 - PASS.
Only one small issue: Probably, better to have it with "with open()" structure:
68 + schema_file = open(schema_filename, 'w') ... 76 + schema_file.close()
And I don't know if it's a code style, but there is one other possibility to write it:
94 + if oc_obj is None: 95 + log.fatal("The new objectclass was not found on server") 96 + assert False 94 + assert oc_obj is None, "The new objectclass was not found on server"
Tested on 1.3.6.1-16.el7 - PASS. Only one small issue: Probably, better to have it with "with open()" structure: 68 + schema_file = open(schema_filename, 'w') ... 76 + schema_file.close()
I made this change, but I don't know what was wrong with the code I had, or why this is better (except for readability).
And I don't know if it's a code style, but there is one other possibility to write it: 94 + if oc_obj is None: 95 + log.fatal("The new objectclass was not found on server") 96 + assert False 94 + assert oc_obj is None, "The new objectclass was not found on server"
And I don't know if it's a code style, but there is one other possibility to write it: 94 + if oc_obj is None: 95 + log.fatal("The new objectclass was not found on server") 96 + assert False
94 + assert oc_obj is None, "The new objectclass was not found on server"
Done, and patch attached
<img alt="0001-Ticket-49092-Add-CI-test-for-schema-reload.patch" src="/389-ds-base/issue/raw/files/7c27300916186b871000cacce4c3be349f5368491faf22a5d02025d87c77f08d-0001-Ticket-49092-Add-CI-test-for-schema-reload.patch" />
My only concern is with the 'topo.standalone.schemadir" over say standalone.get_schemadir(). But I think it's sourced from the same place, so should be okay...
I think, your previous code is okay and shouldn't fail. My main concern is good practices. 'with open()' will call 'close()' method for you in the end even if some exception will happen. And it's one line less because you don't need to call file.close(). So you can remove it.
And I don't know if it's a code style, but there is one other possibility to write it: 94 + if oc_obj is None: 95 + log.fatal("The new objectclass was not found on server") 96 + assert False 94 + assert oc_obj is None, "The new objectclass was not found on server" Done, and patch attached
Oh, sorry for that, I've missed 'not' word. It should be:
94 + assert oc_obj is not None, "The new objectclass was not found on server"
@firstyear - there is no get_schemadir() ;-)
Commits for CI test
4b41a02..a6d2c68 master -> master
a7984d3..c96e8f5 389-ds-base-1.3.7 -> 389-ds-base-1.3.7
Metadata Update from @mreynolds: - Issue close_status updated to: worksforme - Issue status updated to: Closed (was: Open)
Metadata Update from @spichugi: - Custom field reviewstatus adjusted to ack (was: review)
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/2151
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: worksforme)
Login to comment on this ticket.