Description of problem: While upgrading rhev-m from 3.5.8 to 3.6.5 engine-setup fails with the following trace right after otopi.plugins.ovirt_engine_setup.ovirt_engine.config.aaa ~~~ 2016-05-03 11:40:17 DEBUG otopi.plugins.ovirt_engine_setup.ovirt_engine.config.aaa plugin.execute:941 execute-output: ('/usr/bin/openssl', 'pkcs12', '-in', '/etc/pki/ovirt-engine/keys/engine.p12', '-passin', 'pass:**FILTERED**', '-nocerts', '-nodes') stderr: MAC verified OK 2016-05-03 11:40:17 DEBUG otopi.context context._executeMethod:156 method exception Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/otopi/context.py", line 146, in _executeMethod method['method']() File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/config/aaa.py", line 229, in _validation_late padding=RSA.pkcs1_padding, File "/usr/lib64/python2.6/site-packages/M2Crypto/RSA.py", line 63, in private_decrypt return m2.rsa_private_decrypt(self.rsa, data, padding) RSAError: data too large for modulus ~~~ Version-Release number of selected component (if applicable): rhevm-3.5.8-0.1.el6ev.noarch rhevm-setup-3.6.5.3-0.1.el6.noarch ovirt-engine-extension-aaa-jdbc-1.0.6-1.el6ev.noarch How reproducible: 100% in customer's environment everytime he tries to upgrade Steps to Reproduce: 1. Have a working 3.5.8 environment 2. Subscribe to 3.6 channel 3. yum update rhevm-setup 4. engine-setup Actual results: Upgrade process fails with "data too large for modulus" Expected results: Upgrade should succeed Additional info: On the same day, customer upgraded from 3.5.3.1 to 3.5.8. While checking on the setup log file on that previous upgrade I see "Generating RSA private key, 2048 bit long modulus" messages Will upload setup files separately
Is this reproducible on your own system?
Javier, could you please ask how long that password is? I think that the maximum allowed is 245 bytes
(In reply to Yedidyah Bar David from comment #5) > Is this reproducible on your own system? Didi, I haven't tried this yet. Will see if I can reproduce this issue and share the results. (In reply to Simone Tiraboschi from comment #6) > Javier, > could you please ask how long that password is? > I think that the maximum allowed is 245 bytes Simone, customer shared the password for the admin@internal user, it's a short one, so I don't think we are having issues there. Customer tried to reproduce this in his environment to share the exact steps he followed and the procedure worked this time. I've asked a new LogCollector to upload the setup logs, will upload it as soon as I have it. Let me know if you need additional information from the environment. Will leave the need-info on my side to upload the setup log.
This was reproduced by Javier (Thanks!) with the following flow: 1. Install and setup 3.5.8. 2. rm /etc/pki/ovirt-engine/ca.pem 3. engine-setup 4. Try to login as admin, get error as above in the log 5. reset admin password 6. Login, see the hosts are not responsive etc. The correct solution is to reinstall all hosts. We are still considering other options for this specific customer/flow.
It was found that the ovirt-engine PKI certificates were re-created during the 'engine-setup' process and this caused the hosts to stop communicating with the engine due to a certificate mismatch. After creating a new CSR on host side, sign it with the new ca.pem on engine side, move signed cert to host and restarting libvirtd and vdsmd services, the Web Admin UI was restored and a re-deploy of each hypervisor would be performed later to ensure that all the steps of the 'host-deploy' gets executed with all the registration steps against the hosts with the new PKI keys. KB solution to create CSR and sign it back https://access.redhat.com/solutions/2301831 Closing this BZ
Dropping needinfo on me, you already handled the BZ.