#49092 schema reload task picks up schema when the validation fails.
Closed: wontfix 3 years ago Opened 4 years ago by nhosoi.

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.


Metadata Update from @nhosoi:
- Issue set to the milestone: 1.3.6.0

4 years ago

Metadata Update from @mreynolds:
- Issue close_status updated to: None
- Issue set to the milestone: 1.3.7.0 (was: 1.3.6.0)

4 years ago

Metadata Update from @mreynolds:
- Issue assigned to mreynolds

3 years ago

Metadata Update from @mreynolds:
- Custom field reviewstatus adjusted to review

3 years ago

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"

Done, and patch attached

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 made this change, but I don't know what was wrong with the code I had, or why this is better (except for readability).

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)

3 years ago

Metadata Update from @spichugi:
- Custom field reviewstatus adjusted to ack (was: review)

3 years ago

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.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: worksforme)

a year ago

Login to comment on this ticket.

Metadata