[Freeipa-devel] [PATCHSET] Replica promotion patches
Oleg Fayans
ofayans at redhat.com
Thu Sep 3 09:04:10 UTC 2015
I've encountered this today too. Filed a ticket about it:
https://fedorahosted.org/freeipa/ticket/5283
On 09/03/2015 10:57 AM, Martin Basti wrote:
>
>
> On 09/02/2015 10:37 PM, Simo Sorce wrote:
>> On Wed, 2015-09-02 at 15:22 -0400, Simo Sorce wrote:
>>> On Mon, 2015-08-31 at 14:45 +0200, Tomas Babej wrote:
>>>> On 08/26/2015 11:27 PM, Simo Sorce wrote:
>>>>> This patchset implements https://fedorahosted.org/freeipa/ticket/2888
>>>>> and introduces a number of required changes and dependencies to
>>>>> achieve
>>>>> this goal.
>>>>> This work requires the custodia project to securely transfer keys
>>>>> between ipa servers.
>>>>>
>>>>> This work is not 100% complete, it still misses the ability to install
>>>>> kra instances and the ability to install a CA (via ipa-ca-install)
>>>>> with
>>>>> externally signed certs.
>>>>>
>>>>> However it is massive enough that warrants review and pushing, the
>>>>> resat
>>>>> of the changes can be applied later as this work should not disrupt
>>>>> the
>>>>> classic install methods.
>>>>>
>>>>> In order to build my previous patches (530-533) are needed as well
>>>>> as a
>>>>> number of updated components.
>>>>>
>>>>> I used the following coprs for testing:
>>>>> simo/jwcrypto
>>>>> simo/custodia
>>>>> abbra/sssd-kkdcproxy (for sssd 1.13.1)
>>>>> lkrispen/389-ds-current (for 389 > 1.3.4.4)
>>>>> vakwetu/dogtag_10.2.7_test_builds (for dogtag 10.2.7)
>>>>> mkosek/freeipa-4.2-fedora-22 (misc)
>>>>> fedora/updates-testing (python-gssapi 1.1.2)
>>>>>
>>>>> Ludwig's copr is necessary to have a functional DNA plugin in
>>>>> replicas,
>>>>> eventually his patches should be committed in 389-ds-base 1.3.4.4 when
>>>>> it will be released.
>>>>>
>>>>> We are aware of a dogtag bug https://fedorahosted.org/pki/ticket/1580
>>>>> that may cause installation issues in some case (re-install of a
>>>>> replica).
>>>>>
>>>>> The domain must be raised to level 1 in order to use replica
>>>>> promotion.
>>>>>
>>>>> In order to promote a replica the server must be first joined as a
>>>>> regular client to the domain.
>>>>>
>>>>> This is the flow I usually use for testing:
>>>>>
>>>>> # ipa-client-install
>>>>> # kinit admin
>>>>> # ipa-replica-install --promote --setup-ca
>>>>> <perform operations like add user, get keytabs, get certificates,
>>>>> etc...>
>>>>>
>>>>> These patches are also available in this git tree rebnase on current
>>>>> master:
>>>>> https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review
>>>>>
>>>>>
>>>>> Simo.
>>>>>
>>>>>
>>>>>
>>>> I'm running in a issue when upgrading RPMs:
>>>>
>>>> 2015-08-31T10:53:32Z DEBUG File
>>>> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in
>>>> execute
>>>> return_value = self.run()
>>>> File
>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py",
>>>>
>>>> line 48, in run
>>>> server.upgrade()
>>>> File
>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py",
>>>> line 1596, in upgrade
>>>> upgrade_configuration()
>>>> File
>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py",
>>>> line 1508, in upgrade_configuration
>>>> custodia.upgrade_instance()
>>>> File
>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py",
>>>> line
>>>> 57, in upgrade_instance
>>>> self.__gen_keys()
>>>> File
>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py",
>>>> line
>>>> 51, in __gen_keys
>>>> KeyStore.generate_server_keys()
>>>> File "/usr/lib/python2.7/site-packages/ipakeys/kem.py", line 181, in
>>>> generate_server_keys
>>>> ldapconn.set_key(KEY_USAGE_SIG, self.host, principal, pubkeys[0])
>>>> File "/usr/lib/python2.7/site-packages/ipakeys/kem.py", line 127, in
>>>> set_key
>>>> conn.modify_s(dn, mods)
>>>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
>>>> 364, in modify_s
>>>> return self.result(msgid,all=1,timeout=self.timeout)
>>>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
>>>> 465, in result
>>>> resp_type, resp_data, resp_msgid = self.result2(msgid,all,timeout)
>>>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
>>>> 469, in result2
>>>> resp_type, resp_data, resp_msgid, resp_ctrls =
>>>> self.result3(msgid,all,timeout)
>>>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
>>>> 476, in result3
>>>> resp_ctrl_classes=resp_ctrl_classes
>>>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
>>>> 483, in result4
>>>> ldap_result =
>>>> self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
>>>>
>>>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
>>>> 106, in _ldap_call
>>>> result = func(*args,**kwargs)
>>>>
>>>> 2015-08-31T10:53:32Z DEBUG The ipa-server-upgrade command failed,
>>>> exception: NO_SUCH_OBJECT: {'desc': 'No such object'}
>>>> 2015-08-31T10:53:32Z ERROR LDAP error: NO_SUCH_OBJECT
>>>> No such object
>>> Have you found out what this was about ?
>>>
>>> I just found a different probelm affecting ipa-server-upgrade on my
>>> master, it tracebacks trying to update the schema, which is odd:
>>>
>>> 2015-09-02T19:06:39Z DEBUG [5/8]: updating schema
>>> 2015-09-02T19:06:39Z DEBUG flushing
>>> ldapi://%2fvar%2frun%2fslapd-PROMO-LAN.socket from SchemaCache
>>> 2015-09-02T19:06:39Z DEBUG retrieving schema for SchemaCache
>>> url=ldapi://%2fvar%2frun%2fslapd-PROMO-LAN.socket
>>> conn=<ldap.ldapobject.SimpleLDAPObject instance at 0x7f7900550ab8>
>>> 2015-09-02T19:06:40Z DEBUG Processing schema LDIF file
>>> /usr/share/ipa/60kerberos.ldif
>>> 2015-09-02T19:06:40Z DEBUG Traceback (most recent call last):
>>> File
>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line
>>> 417, in start_creation
>>> run_step(full_msg, method)
>>> File
>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line
>>> 407, in run_step
>>> method()
>>> File
>>> "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py",
>>> line 299, in __update_schema
>>> dm_password='', ldapi=True) or self.modified
>>> File
>>> "/usr/lib/python2.7/site-packages/ipaserver/install/schemaupdate.py",
>>> line 131, in update_schema
>>> for oids_set in _get_oid_dependency_order(new_schema, cls):
>>> File
>>> "/usr/lib/python2.7/site-packages/ipaserver/install/schemaupdate.py",
>>> line 59, in _get_oid_dependency_order
>>> unordered_oids = set(tree)
>>> File "/usr/lib64/python2.7/site-packages/ldap/cidict.py", line 27,
>>> in __getitem__
>>> return self.data[lower(key)]
>>> File "/usr/lib64/python2.7/string.py", line 228, in lower
>>> return s.lower()
>>> AttributeError: 'int' object has no attribute 'lower'
>>>
>>>
>>> Any ideas about this ?
>> FYI: replicated this on the second replica too...
>>
>> I can plod through by manually hacking the script to skip the schema
>> update check, but this never happened before, did some patch recently
>> land that changed how schemas are handled ?
>>
>> Simo.
>>
>>
> We did not change schemaupdater code.
> I saw this issue yesterday for first time.
> I have to inspect this, python-ldap may be broken or some py3 cahnges
> could break it.
>
> Martin^2
>
--
Oleg Fayans
Quality Engineer
FreeIPA team
RedHat.
More information about the Freeipa-devel
mailing list