Created attachment 962065 [details] rhevm-engine-log Description of problem: A day ago, I sucesfully added a host to rhevm and everything is OK. Next day I working with backup and restore utility "engine-backup", it seems all is OK. But when I tried add the hosts to rhevm, but it stop at "Failed to install Host VHOST. Certificate enrollment failed." It's a second time, when it happen to me. Every time I was working on something else. Then I had to reinstall engine. I used a different host: RHEL-6.6 RHEV-H-6.6-20141119 RHEV-H-7.0-20141120 Host added to rhevm a day ago has RHEL-6.6 Version-Release number of selected component (if applicable): RHEVM 3.5.0-0.22.el6ev How reproducible: Not always Steps to Reproduce: - Actual results: Cannot add any hosts Additional info: attached logs
Created attachment 962070 [details] vdsm-log from host with rhel6.6
Not sure it is related to backup/restore, I did not understand from description if you actually restored or only backed up. rm: cannot remove `/tmp/ovirt-engine-pki.v2.lock': Permission denied Please paste output of: # ls -laLd /tmp/ovirt-engine-pki.v2.lock /etc/pki/ovirt-engine/private drwxr-x---. 2 ovirt ovirt 4096 Oct 27 22:30 /etc/pki/ovirt-engine/private drwxr-x---. 2 ovirt ovirt 40 Nov 25 21:28 /tmp/ovirt-engine-pki.v2.lock if ovirt is not owner of /tmp/ovirt-engine-pki.v2.lock it is probably a leftover from crash. if ovirt is not owner of /etc/pki/ovirt-engine/private it is probably a restore issue as the permissions are set in packaging (rpm).
I created a backup of the engine, cleanup the engine and after I restored the engine from backup. http://www.ovirt.org/Ovirt-engine-backup -> but on the same machine. But I don't know, what caused this issue. output: # ls -laLd /tmp/ovirt-engine-pki.v2.lock /etc/pki/ovirt-engine/private ls: cannot access /tmp/ovirt-engine-pki.v2.lock: No such file or directory drwxr-x---. 2 ovirt ovirt 4096 Nov 25 18:39 /etc/pki/ovirt-engine/private when adding the host, ovirt-engine-pki.v2.lock seems to be not created.
# ls -lad /tmp drwx------. 5 root root 4096 Nov 28 10:57 /tmp should be: # ls -lad /tmp drwxrwxrwt. 10 root root 61440 Nov 28 03:17 /tmp so entire system is damaged. I do not think it is related to backup/restore... reassigning to correct component and closing for now. if you can reproduce this on clean machine with documented sequence please reopen.
It would be also nice to understand what changed the /tmp permission, supposing you didn't change them by hand.
I found what causing this permission on tmp directory: I created sosreport via rhevm-log-collector This command created archive in tmp folder sosreport-LogCollector-....tar.xz Permission was still ok until I runned tar in folder /tmp #tar -Jxf sosreport-LogCollector-....tar.xz this change the permission of the /tmp
So tar is changing "." permission? Moving to log-collector for further investigation. Simone, can you check if this is due to the way we build the tar file? I suggest to reduce the severity to high: - it's not likely that a sosreport is opened on the same host producing it - manual fix is pretty simple: chmod 777 /tmp (if extracted in /tmp instead of /tmp/whatever
> So tar is changing "." permission? always if . is within tarball, you should put leading directory. > chmod 777 /tmp chmod 1777 /tmp or more correctly: chmod a=rwxt /tmp
BTW: best was to open a new bug with clear comment#0 and without history.
Reducing severity since workaround has been provided.
Automated message: can you please update doctext or set it as not required?
Verified in ovirt-log-collector-3.6.0-0.1.master.20150410091746.git19f1be0.el6.noarch
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2016-0392.html