#444 schema upgrade failure should not abort upgrade process
Closed: wontfix Opened by rmeggins.

edit standard schema files in /etc/dirsrv/slapd-inst/schema so that there is a conflict with OID
upgrade (setup-ds.pl -u)
the database upgrade fails due to schema conflicts, and the directory server is unusable


I can not reproduce this issue:

[1] I stopped my instance.
[2] Edited 00core.ldif and set the same OID for objectclasses: top & alias
[3] ran setup-ds.pl -u:
...
...
Which update mode do you want to use? [quit]: Offline
[16/Jan/2013:11:02:13 -0500] - check_and_set_import_cache: pagesize: 4096, pages: 950798, procpages: 52536
[16/Jan/2013:11:02:13 -0500] - Import allocates 1521276KB import cache.
[16/Jan/2013:11:02:13 -0500] Upgrade DN Format - userRoot: Start upgrade dn format.
[16/Jan/2013:11:02:13 -0500] Upgrade DN Format - Instance userRoot in /var/lib/dirsrv/slapd-repl/db/userRoot is up-to-date
Finished successful update of directory server.
Please restart your directory servers.
Exiting . . .
Log file is '/tmp/setupWfb130.log'

[4] Success

At this point the server starts because 00core.ldif has been replaced during the upgrade process.

Is there something I am missing to reproduce this?

My reproducer originally was:

  1. cp /usr/share/dirsrv/data/60sendmail.ldif to /etc/dirsrv/slapd-INSTANCE/schema
  2. rm /etc/dirsrv/slapd-INSTANCE/schema/50ns-mail.ldif because it conflicts with 60sendmail.ldif
  3. upgrade

Just coping over 60sendmail.ldif causes errors, but the upgrade seems to work:

Which update mode do you want to use? [quit]: Offline
[16/Jan/2013:14:01:16 -0500] dse_read_one_file - The entry cn=schema in file /etc/dirsrv/slapd-repl/schema/60sendmail.ldif (lineno: 1) is invalid, error code 20 (Type or value exists) - attribute type mailLocalAddress: Does not match the OID "2.16.840.1.113730.3.1.13". Another attribute type is already using the name or OID.
[16/Jan/2013:14:01:16 -0500] dse - Please edit the file to correct the reported problems and then restart the server.
Finished successful update of directory server.
Please restart your directory servers.
Exiting . . .
Log file is '/tmp/setupuUsGLk.log'

You can't start the DS until you correct the schema issues - this is expected behavior. Is this the same issue you encountered? Or did the upgrade actually report an error about not finishing successfully?

Also, which version of 389 are you testing with?

Thanks,
Mark

If I recall correctly the original problem happened during an upgrade between two versions that required database updates to be applied and these failed due to the oid conflicts.

I'm not entirely sure what Rich was expecting to be handled by this report though. I'll let him weigh in as well.

Replying to [comment:9 orion]:

If I recall correctly the original problem happened during an upgrade between two versions that required database updates to be applied and these failed due to the oid conflicts.

I'm not entirely sure what Rich was expecting to be handled by this report though. I'll let him weigh in as well.

Orion, which version did you upgrade from, and which version did you upgrade to? Yes, I recall it had something to do with database upgrade. The problem with database upgrade is this - if the database upgrade part fails, then you restart the server, the server will update the db version in the database without updating the files - which means the server doesn't like the db files, and you can no longer run the db upgrade script, so you're stuck with a broken server.

I just upgraded (setup-ds.pl -u) from 1.2.10.25 to 1.3.0.rc1, and it still appears to have worked:

Which update mode do you want to use? [quit]: Offline
[16/Jan/2013:14:18:40 -0500] - Warning: ignoring invalid line ")"...
[16/Jan/2013:14:18:40 -0500] - Warning: ignoring invalid line ")"...
[16/Jan/2013:14:18:40 -0500] - Warning: ignoring invalid line ")"...
[16/Jan/2013:14:18:40 -0500] - Warning: ignoring invalid line ")"...
[16/Jan/2013:14:18:40 -0500] - Warning: ignoring invalid line ")"...
[16/Jan/2013:14:18:40 -0500] dse_read_one_file - The entry cn=schema in file /etc/dirsrv/slapd-upgrade/schema/60sendmail.ldif (lineno: 1) is invalid, error code 20 (Type or value exists) - attribute type mailLocalAddress: Does not match the OID "2.16.840.1.113730.3.1.13". Another attribute type is already using the name or OID.
[16/Jan/2013:14:18:40 -0500] dse - Please edit the file to correct the reported problems and then restart the server.
Finished successful update of directory server.
Please restart your directory servers.
Exiting . . .
Log file is '/tmp/setupajlmcb.log'

Error log:

[16/Jan/2013:14:14:58 -0500] - 389-Directory/1.2.10.25 B2013.016.1912 starting up
[16/Jan/2013:14:14:58 -0500] - I'm resizing my cache now...cache was 1557786624 and is now 8000000
[16/Jan/2013:14:14:59 -0500] - slapd started. Listening on All Interfaces port 22715 for LDAP requests
[16/Jan/2013:14:18:17 -0500] - slapd shutting down - signaling operation threads
[16/Jan/2013:14:18:17 -0500] - slapd shutting down - closing down internal subsystems and plugins
[16/Jan/2013:14:18:17 -0500] - Waiting for 4 database threads to stop
[16/Jan/2013:14:18:18 -0500] - All database threads now stopped
[16/Jan/2013:14:18:18 -0500] - slapd stopped.
[16/Jan/2013:14:18:40 -0500] - Warning: ignoring invalid line ")"...
[16/Jan/2013:14:18:40 -0500] - Warning: ignoring invalid line ")"...
[16/Jan/2013:14:18:40 -0500] - Warning: ignoring invalid line ")"...
[16/Jan/2013:14:18:40 -0500] - Warning: ignoring invalid line ")"...
[16/Jan/2013:14:18:40 -0500] - Warning: ignoring invalid line ")"...
[16/Jan/2013:14:18:40 -0500] dse_read_one_file - The entry cn=schema in file /etc/dirsrv/slapd-upgrade/schema/60sendmail.ldif (lineno: 1) is invalid, error code 20 (Type or value exists) - attribute type mailLocalAddress: Does not match the OID "2.16.840.1.113730.3.1.13". Another attribute type is already using the name or OID.
[16/Jan/2013:14:18:40 -0500] dse - Please edit the file to correct the reported problems and then restart the server.
[16/Jan/2013:14:19:08 -0500] - Warning: ignoring invalid line ")"...
[16/Jan/2013:14:19:08 -0500] - Warning: ignoring invalid line ")"...
[16/Jan/2013:14:19:08 -0500] - Warning: ignoring invalid line ")"...
[16/Jan/2013:14:19:08 -0500] - Warning: ignoring invalid line ")"...
[16/Jan/2013:14:19:08 -0500] - Warning: ignoring invalid line ")"...
[16/Jan/2013:14:19:09 -0500] - 389-Directory/1.3.0.rc1.git16651d6 B2013.016.1916 starting up
[16/Jan/2013:14:19:09 -0500] - slapd started. Listening on All Interfaces port 22715 for LDAP requests

Rich, is there some other script to the "db upgrade"?

I probably did an online upgrade - or what ever is done with an automatic yum upgrade. Looking at my old emails:

So, 389-ds-base-1.2.10.14-1.el5 came in today and broke my server, ldap searches returned the base of the tree but nothing else. I needed to downgrade to 1.2.9.9 and restore my /etc/dirsrv/slapd-cora directory from backup.

ok - so it was probably with the upgrade from 1.2.9 to 1.2.10

setup-ds.pl -u in offline mode is run during yum/rpm update. This runs the following "sub-scriptlets" - 91subtreereindex.pl 90subtreerename.pl 80upgradednformat.pl - which may upgrade the database in some way - if this happens, you will see messages in the errors log about database upgrade

I still can not reproduce the issue(using yum upgrade, setup-ds.pl -u, etc). I believe I need the "proper" entries to trigger the scriplets that are causing the problem. I've tried adding entries like:

dn: cn="value",dc=example,dc=com
dn: cn=/22value/22,dc=example,dc=com

Orion, Is there anything else you can give us to help reproduce this issue? Can you reproduce it with a plain data set?

Thanks,
Mark

Going to close this as "works for me" for now, but if we get a new data set/testcase we can reopen it.

Metadata Update from @mreynolds:
- Issue assigned to mreynolds
- Issue set to the milestone: 1.3.1

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/444

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: Invalid)

Metadata