Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1060215 - [RFE] Allow changing the address of hosts
Summary: [RFE] Allow changing the address of hosts
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-engine-core
Version: 3.3
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
: 3.6.0
Assignee: Yaniv Bronhaim
QA Contact: bugs@ovirt.org
URL:
Whiteboard: infra
: 1098762 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-31 13:29 UTC by Sven Kieske
Modified: 2016-02-10 19:30 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-29 09:06:30 UTC
oVirt Team: Infra


Attachments (Terms of Use)

Description Sven Kieske 2014-01-31 13:29:02 UTC
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.

Comment 1 Itamar Heim 2014-02-01 15:17:48 UTC
Sven - can you try:
1. move hos to maint.
2. edit the name
3. click re-install

Comment 2 Sven Kieske 2014-02-03 11:45:48 UTC
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).

Comment 3 Itamar Heim 2014-02-03 11:50:17 UTC
barak - thoughts on why we block editing the hostname (other than it will have to be re-installed?)

Comment 4 Sven Kieske 2014-02-03 12:06:00 UTC
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.

Comment 5 Itamar Heim 2014-02-03 12:09:12 UTC
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?

Comment 6 Sven Kieske 2014-02-03 12:16:00 UTC
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?

Comment 7 Sven Kieske 2014-02-03 12:38:55 UTC
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?

Comment 8 Alon Bar-Lev 2014-02-03 12:44:52 UTC
(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.

Comment 9 Alon Bar-Lev 2014-02-03 12:53:53 UTC
(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.

Comment 10 Barak 2014-02-04 18:05:34 UTC
(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.

Comment 11 Barak 2014-02-04 18:10:28 UTC
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.

Comment 12 Itamar Heim 2014-02-04 21:45:26 UTC
(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.

Comment 13 Oved Ourfali 2014-05-26 11:24:19 UTC
*** Bug 1098762 has been marked as a duplicate of this bug. ***

Comment 14 Itamar Heim 2015-03-29 09:06:30 UTC
Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.


Note You need to log in before you can comment on or make changes to this bug.