On Thu, 2015-09-03 at 15:21 +0200, Martin Basti wrote: > > On 09/03/2015 02:57 PM, Simo Sorce wrote: > > On Thu, 2015-09-03 at 10:57 +0200, 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. > > I bet on py3 changes, somethign cause data to stay as int instead of > > being converted to string I would guess. > > I have not updated python-ldap so that is unlikely. > > > > Simo. > > > It is already fixed, it was py3 change
Thanks, I'll rebase on latest master then. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
