Description of problem: Currently, you can not change the address which engine uses to connect to a host in webadmin or via API, instead you have to change the db by hand Version-Release number of selected component (if applicable): tested in 3.3.2 should still be the same in 3.4 alpha1 How reproducible: always Steps to Reproduce: 1.select a host in webadmin 2. click edit 3. find the "address" field greyed out Actual results: you can't change the address Expected results: you are able to change the address of the hostname Additional info: currently, this just works by logging in as the postgres user and use the following command: psql engine -c "update vds_static set host_name = '$NEWNAME' where host_name = '$OLDNAME';" This would be a cool feature, e.g. if you switch from fqdn addresses to ip based addresses or vice versa.
Sven - can you try: 1. move hos to maint. 2. edit the name 3. click re-install
Itamar, I tried as you suggested, but I think you misunderstood my intent. I do not want to edit the "name" but the "address" field, which ovirt uses to connect to the host. So I did: 1. shutdown all running vms on that host. 2. put it into maintenance. 3. Clicked edit Actual Result: The "address" field is greyed out, you can not edit it. Expected result: be able to edit this field. It is already possible to achieve this by hacking at the db (like I discribed above).
barak - thoughts on why we block editing the hostname (other than it will have to be re-installed?)
Itamar, you still don't seem to understand. oVirt does _not_ block editing the "name" field but it blocks the "address" field, which is used to connect to the host via ssh. This field might get filled by a hostname which is resolvable via DNS or with an IPv4 address. It may be related to the hosts certificates, which I didn't check. All I can is report that you can achieve a changed address by hacking the db so I think this should also be possible without hacking it. Thank you.
sven - address == hostname and yes, the issue is about the need to re-install once changing it, so the certificate will be re-generated. I assume changing the address would cause the node to become non-responsive if you activate it without re-installing?
Well my workflow was like the following: 1. move host to maintenance 2. stop ovirt engine, do a backup of the db 3. as postgres user: psql engine -c "update vds_static set host_name = '$NEWNAME' where host_name = '$OLDNAME';" 4. restart engine 5. activate host again 6. everything is up and running, so no reinstallation of the host was done I'll check the certificates by hand, this is weird, according to your description the host should not be recognized because the certificate doesn't fit the address?
Additional Info: The certificates still hold the old Hostname in the "CN" Field So I guess for my RFE to work we would need a helper script in the background which creates new certs for the new hostname and rolls them out, revoking the old ones? But why is my host still operational in the first place?
(In reply to Sven Kieske from comment #7) > But why is my host still operational in the first place? this is a serious bug, I can confirm that this is the case, just tried it.
(In reply to Alon Bar-Lev from comment #8) > (In reply to Sven Kieske from comment #7) > > But why is my host still operational in the first place? > > this is a serious bug, I can confirm that this is the case, just tried it. bug#1060717 opened.
(In reply to Alon Bar-Lev from comment #8) > (In reply to Sven Kieske from comment #7) > > But why is my host still operational in the first place? > > this is a serious bug, I can confirm that this is the case, just tried it. This happens because we only validate that the certificate is signed by a trusted CA (which is the engine), we do not perform a full client certificate authentication (= validate the request/response actually came from the subject of the cerificate). I don't remember the reason for that ... long time go. Anyway In this case Bug 1060717 contradicts this Bug. The right way is to validate the certificate using the hostname. Bug 1060717 only covers the engine side of validation .... this should also happen on the vdsm side.
Itamar, In light of the above contradistinction how do you suggest to proceed ? Solving Bug 1060717 (by validating the subject ...) will force redeploy of the host after such a change, while this bug addresses that ability to change the address. So I suggest to enable editing the address when the host is in maintenance, and notify the user somehow it must redeploy after such a change.
(In reply to Barak from comment #11) > Itamar, > > In light of the above contradistinction how do you suggest to proceed ? > Solving Bug 1060717 (by validating the subject ...) will force redeploy of > the host after such a change, while this bug addresses that ability to > change the address. > > So I suggest to enable editing the address when the host is in maintenance, > and notify the user somehow it must redeploy after such a change. yes.
*** Bug 1098762 has been marked as a duplicate of this bug. ***
Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.