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.

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

Reply via email to