Hide Forgot
Description of problem: ovirt-engine public SSH keys stays on host after removal. not sure if this is what we want. Version-Release number of selected component (if applicable): is24.2 How reproducible: 100% Steps to Reproduce: 1. add host with password 2. hosts -> maintainance 3. remove host Actual results: ovirt-engine public ssh keys stays on the host Expected results: not sure Additional info:
There is no active operation on host when host is removed, hence no removal of any resource. The public key can be used for future add host using public key. I tend to close it as NOTABUG.
What about documenting somewhere that while a host is added into setup public SSH keys of engine installation is place on the host and not removed? Getting private key from /etc/pki/ovirt-engine/keys/engine_id_rsa means access to hosts removed from RHEVM setup.
(In reply to Jiri Belka from comment #2) > What about documenting somewhere that while a host is added into setup > public SSH keys of engine installation is place on the host and not removed? > Getting private key from /etc/pki/ovirt-engine/keys/engine_id_rsa means > access to hosts removed from RHEVM setup. I do not mind documenting anything, can you please move this into doc bug? BTW: it was always the case since [at least] 3.0.
Hmmm.... just some more information... vdsm stays up... engine can keep communicate with it post remove if so it wishes. So under the same logic, vdsm should be removed as well, or at least keys removed. This regardless if we install some back door... What I mean is that once host is added to some provisioning framework with root credentials, it is a total slave and cannot be trusted even if removed.
So... RHEVM should learn how to do cleaning (no access without confirmation, no RHEVM services running...). And... if something cannot be cleaned up, then it should be documented, what kind of "backdoors" are kept there...
RHEL management of services is not so stupid as on Debian, they are 'off' by default. So vdsm related services should be put 'off' again.
The RHEV 3.4 docs development cycle has only one week remaining, and all features that are not substantially in their final form can not be documented given the resources that we have. I agree that people should know that public SSH keys stay on host after the host has been removed from the RHEVM environment, but this unclean key treatment sounds like a bug to me and ECS has a policy of not documenting bugs. I will set this to CLOSED WONTFIX, and will return to examine this issue during the 3.5 planning.