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:
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]:
Yes, this would be the easiest workaround. This needs to be filed as a 389 DS ticket for a real fix.
I filed a 389 DS ticket for this issue:
https://fedorahosted.org/389/ticket/47490
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)
Login to comment on this ticket.