#3778 Upgrade fails, attribute "nsSaslMapPriority" not allowed
Closed: Fixed None Opened 7 years ago by rcritten.

While testing upgrades I had an upgrade failure.

I was testing an initial IPA Master in F-17 (2.2.2) and an IPA replica in F-19, 3.2.1.

I tried upgrading the F-19 box to master and it failed. This was in /var/log/ipaupgrade.log:

2013-07-11T16:03:03Z DEBUG ---------------------------------------------
2013-07-11T16:03:03Z DEBUG Final value after applying updates
2013-07-11T16:03:03Z DEBUG dn: cn=Name Only,cn=mapping,cn=sasl,cn=config
2013-07-11T16:03:03Z DEBUG nsSaslMapPriority:
2013-07-11T16:03:03Z DEBUG      10
2013-07-11T16:03:03Z DEBUG cn:
2013-07-11T16:03:03Z DEBUG      Name Only
2013-07-11T16:03:03Z DEBUG objectClass:
2013-07-11T16:03:03Z DEBUG      top
2013-07-11T16:03:03Z DEBUG      nsSaslMapping
2013-07-11T16:03:03Z DEBUG nsSaslMapRegexString:
2013-07-11T16:03:03Z DEBUG      ^[^:@]+$
2013-07-11T16:03:03Z DEBUG nsSaslMapBaseDNTemplate:
2013-07-11T16:03:03Z DEBUG      dc=greyoak,dc=com
2013-07-11T16:03:03Z DEBUG nsSaslMapFilterTemplate:
2013-07-11T16:03:03Z DEBUG      (krbPrincipalName=&@GREYOAK.COM)
2013-07-11T16:03:03Z DEBUG [(2, u'nssaslmappriority', ['10'])]
2013-07-11T16:03:03Z DEBUG Live 1, updated 1
2013-07-11T16:03:03Z ERROR Upgrade failed with attribute "nsSaslMapPriority" not allowed
2013-07-11T16:03:03Z DEBUG Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 118, in __upgrade
    self.modified = ld.update(self.files, ordered=True)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 940, in update
    self._run_updates(all_updates)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 897, in _run_updates
    self._update_record(update)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 800, in _update_record
    self.conn.updateEntry(entry.dn, entry.origDataDict(), entry.toDict())
  File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1749, in updateEntry
    self.modify_s(dn, modlist)
  File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__
    self.gen.throw(type, value, traceback)
 File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 934, in error_handler
    raise errors.ObjectclassViolation(info=info)
ObjectclassViolation: attribute "nsSaslMapPriority" not allowed

This was added in ticket https://fedorahosted.org/freeipa/ticket/3330


I tried to reproduce this several times with different setups and was unsuccessful.

The nsSaslMapPriority attribute was added in DS 1.3.1.0, which is required for FreeIPA 3.2.0 and later, so I don't see how an update from 3.2.1 to master could have resulted in such a failure.

I think the only way this could happen is if you had pre-1.3.1 DS installed on the F19 box, updated it to 1.3.1 and something went wrong, causing the schema not to be updated properly.

This seems to be some glitch in a DS early versions. We now require 1.3.1.3 at minimum and I have never seen an error like this one when doing upgrade testing.

Closing the ticket as worksforme, Rob please feel free to reopen if you see this error also with current DS versions.

I tried after updating 389-ds-base to 1.3.1.4 from updates-testing and reproduced this again.

A standalone install on the F-19 system works fine.

I confirmed that nsSaslMapPriority appears in 99user.ldif in the 2.2.2 master. The difference is in the 2.2.2 master lacks MAY ( nsSaslMapPriority ) in the objectclass definition of nsSaslMapping. So I guess 389-ds replication didn't notice that the schema was different.

Why does it matter what's on the 2.2.2 master? It's the 3.2.1 replica that is failing the upgrade, right?

Anyway, your DS instance must be broken. I did (AFAIK) exactly what you did - installed a 2.2.2 master on F17 and created a 3.2.1 replica on F19 - and the upgrade was successful.

You keep using the word upgrade. I'm doing a replica install on a new F-19 instance.

You said you were doing an upgrade yourself:

I tried upgrading the F-19 box to master and it failed.

Here's what I did:

  1. install new 2.2.2 master on host A (F17) - no failure
  2. install new 3.2.1 replica on host B (F19) - no failure
  3. upgrade the 3.2.1 on host B to current git master - no failure

Is this different from what you did?

It fails in step 2 for me.

Moving all non-critical bugs to 3.3.x bug fixing bucket (FreeIPA 3.3 final was released).

I finally managed to reproduce this (I merged steps 2 and 3 and installed a replica from git master right away).

It looks like the definition of nsSaslMapping got overwritten on the replica with the old version from the master during initial replication.

I wonder if there is a way to prevent this. The simple fix would be to manually add the nsSaslMapPriority attribute type and update the nsSaslMapping object class before setting up the mapping.

Seems like we need to involve the 389-ds team to figure out how to force out the new objectclass.

Replying to [comment:12 jcholast]:

I wonder if there is a way to prevent this. The simple fix would be to manually add the nsSaslMapPriority attribute type and update the nsSaslMapping object class before setting up the mapping.

Yes, this would be the easiest workaround. This needs to be filed as a 389 DS ticket for a real fix.

Thanks.

I posted a workaround patch on freeipa-devel.

Workaround added to IPA, let's track the proper solution in the DS ticket.

master: 5a8e326[[BR]]
ipa-3-3: 20b9007

My understanding is that the schema of the master F17 (IPA 2.2.2), overwrites the schema of the consumer F19 (3.2.1). I would like to know if the schema of the master was updated, sometime before or after the installation of the consumer ?
This can be checked with ldapsearch -h .... -p <master> -D "cn=directory manager" -w... -b "cn=schema" "(&(objectclass=ldapsubentry)(objectclass=subschema))" nscpentrywsi | grep -i nsSchemaCSN

AFAIU, the problem here was that 389-ds updated their core schema, so when IPA replica of a newer version was being installed, it's schema was based on the old core schema init-ted from older DS (F17). This caused the installation issues. It should be fixed in the DS bug in comment:15.

Metadata Update from @rcritten:
- Issue assigned to jcholast
- Issue set to the milestone: FreeIPA 3.3.x - 2013/08 (bug fixing)

4 years ago

Login to comment on this ticket.

Metadata