[
https://issues.apache.org/jira/browse/VCL-839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Kurth updated VCL-839:
---------------------------
Description:
The {{vcl-install.sh}} script uses _localhost_ as the name of the management
node by default. This _FQDN_ parameter in {{/etc/vcl/vcld.conf}} gets set to
_localhost_ as well as the _managementnode.hostname_ value.
The backend code needs to determine the private IP address being used on the
management node. This is not stored in the database. Only the management
node's hostname and an ambiguous _IPaddress_ values are stored in the
management node table. The _IPaddress_ value should be set to the public IP
address in order to allow management nodes which don't share the same private
network to communicate.
To determine its own private IP address, the management node attempts to
resolve its hostname, _localhost_, which resolves to 127.0.0.1. After this
step, the code compares the resolved IP address to the addresses assigned to
the management node's interfaces. The loopback interface's IP addresses are
explicitly excluded because there would be no reason for the code to ever use a
loopback address.
This introduces the first problem, which is mostly cosmetic at this point. The
following warning is generated:
{noformat}
|30351|3|3|new|OS.pm:get_private_interface_name|1451| ---- WARNING ----
|30351|3|3|new|OS.pm:get_private_interface_name|1451| 2015-03-18
14:17:32|30351|3|3|new|OS.pm:get_private_interface_name|1451|failed to
determine private interface name, no interface is assigned the private IP
address for the reservation: 127.0.0.1
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : {
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : "eth0" => {
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : "broadcast_address"
=> "10.x.x.x",
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : "ip_address" => {
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : "10.x.x.x" =>
"255.255.240.0"
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : },
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : "name" => "eth0",
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : "physical_address"
=> "00:50:56:23:00:bc"
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : },
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : "eth1" => {
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : "broadcast_address"
=> "x.x.x.x",
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : "default_gateway"
=> "x.x.x.x",
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : "ip_address" => {
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : "152.46.18.135"
=> "255.255.248.0"
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : },
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : "name" => "eth1",
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : "physical_address"
=> "00:50:56:23:00:bd"
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : },
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : "lo" => {
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : "ip_address" => {},
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : "name" => "lo"
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : }
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : }
|30351|3|3|new|OS.pm:get_private_interface_name|1451| ( 0) OS.pm,
get_private_interface_name (line: 1451)
|30351|3|3|new|OS.pm:get_private_interface_name|1451| (-1) OS.pm,
get_private_network_configuration (line: 1695)
|30351|3|3|new|OS.pm:get_private_interface_name|1451| (-2) (eval 762), (eval)
(line: 1)
|30351|3|3|new|OS.pm:get_private_interface_name|1451| (-3) OS.pm,
get_ip_address (line: 1846)
|30351|3|3|new|OS.pm:get_private_interface_name|1451| (-4) OS.pm,
get_private_ip_address (line: 1901)
|30351|3|3|new|OS.pm:get_private_interface_name|1451| (-5) Linux.pm, post_load
(line: 418)
{noformat}
The next problem occurs when a computer is being loaded. Linux.pm's post_load
subroutine attempts to add firewall rules to allow traffic to any port and and
specifically to port 22 from the management node's private IP address. This
isn't working as expected because the private IP address could not be
determined. The result is the attempt to allow traffic to any port from the
management node's private IP address is skipped:
{noformat}
|30351|3|3|new|Linux.pm:enable_firewall_port|3655| ---- WARNING ----
|30351|3|3|new|Linux.pm:enable_firewall_port|3655| 2015-03-18
14:22:44|30351|3|3|new|Linux.pm:enable_firewall_port|3655|firewall not
modified, port argument is not restricted to a certain port: 'any', scope
argument was not sup
plied, it must be restricted to certain IP addresses if the port argument is
unrestricted
{noformat}
The attempt to allow traffic to port 22 is completed. However, because no IP
address was specified traffic is allowed from any address. At this point, the
management node can still control the computer.
After the computer is reserved and the user connects, the code attempts to lock
down the firewall to the user's remote IP address. Existing firewall rules for
the specific connect method port are replaced when a user initially connects:
{noformat}
2015-03-18
14:23:35|31054|3|3|reserved|Linux.pm:enable_firewall_port|3734|overwrite
existing argument specified, existing tcp/22 firewall rule(s) will be replaced:
|31054|3|3|reserved|Linux.pm:enable_firewall_port|3734| existing scope:
0.0.0.0/0.0.0.0
|31054|3|3|reserved|Linux.pm:enable_firewall_port|3734| new scope:
y.y.y.y/255.255.255.0
{noformat}
_y.y.y.y is the user's remote IP address in this example_
Once the firewall is modified, the managment loses control of the computer
because the only existing rule which allowed access, 22 from any IP address,
was removed. All commands after this point fail.
{noformat}
2015-03-18 14:23:35|31054|3|3|reserved|utils.pm:run_ssh_command|4181|executing
SSH command on 192.168.2.1 (vm241-1): '/sbin/iptables-save >
/etc/sysconfig/iptables'
|31054|3|3|reserved|utils.pm:run_ssh_command|4291| ---- WARNING ----
|31054|3|3|reserved|utils.pm:run_ssh_command|4291| 2015-03-18
14:23:35|31054|3|3|reserved|utils.pm:run_ssh_command|4291|attempt 1/3: failed
to execute SSH command on 192.168.2.1 (vm241-1): '/sbin/iptables-save >
/etc/sysconfig/iptables', exit status: 255, output:
|31054|3|3|reserved|utils.pm:run_ssh_command|4291| ssh output (/sbin/ipta...):
ssh: connect to host 192.168.2.1 port 22: No route to host
{noformat}
The user isn't affected at this point. Traffic is still allowed from his/her
remote IP address. The management node will continue to check for a user
connection every few minutes. It continues to fail to do so. The reservation
is not timed out when a management node has no control over the computer.
Everything is fine for the user as long as he/she does not change location. If
they do so and click the _Connect_ button from another remote IP address, the
management node won't be able to open the firewall to the new address and the
user will not be able to connect.
User initiated image captures will also fail:
{noformat}
|6680|3|3|image|OS.pm:pre_capture|102| ---- WARNING ----
|6680|3|3|image|OS.pm:pre_capture|102| 2015-03-18
14:31:22|6680|3|3|image|OS.pm:pre_capture|102|unable to complete capture
preparation tasks, vm241-1 is powered on but not responding to SSH
|6680|3|3|image|OS.pm:pre_capture|102| ( 0) OS.pm, pre_capture (line: 102)
|6680|3|3|image|OS.pm:pre_capture|102| (-1) Linux.pm, pre_capture (line: 331)
|6680|3|3|image|OS.pm:pre_capture|102| (-2) VMware.pm, capture (line: 752)
|6680|3|3|image|OS.pm:pre_capture|102| (-3) image.pm, process (line: 179)
|6680|3|3|image|OS.pm:pre_capture|102| (-4) vcld, make_new_child (line: 587)
|6680|3|3|image|OS.pm:pre_capture|102| (-5) vcld, main (line: 348)
{noformat}
One simple fix is to not use _localhost_ for the management node name. Another
fix would be to edit {{/etc/hosts}} on the management node and set localhost to
the private IP address. I'm not sure if this will cause other problems if
something relies on _localhost_ being a loopback address.
Regardless, the problems with the code need to be resolved. A management node
should never lock itself out.
was:
The {{vcl-install.sh}} script uses _localhost_ as the name of the management
node by default. This _FQDN_ parameter in {{/etc/vcl/vcld.conf}} gets set to
_localhost_ as well as the _managementnode.hostname_ value.
The backend code needs to determine the private IP address being used on the
management node. This is not stored in the database. Only the management
node's hostname and an ambiguous _IPaddress_ values are stored in the
management node table. The _IPaddress_ value should be set to the public IP
address in order to allow management nodes which don't share the same private
network to communicate.
To determine its own private IP address, the management node attempts to
resolve its hostname, _localhost_, which resolves to 127.0.0.1. After this
step, the code compares the resolved IP address to the addresses assigned to
the management node's interfaces. The loopback interface's IP addresses are
explicitly excluded because there would be no reason for the code to ever use a
loopback address.
This introduces the first problem, which is mostly cosmetic at this point. The
following warning is generated:
{noformat}
|30351|3|3|new|OS.pm:get_private_interface_name|1451| ---- WARNING ----
|30351|3|3|new|OS.pm:get_private_interface_name|1451| 2015-03-18
14:17:32|30351|3|3|new|OS.pm:get_private_interface_name|1451|failed to
determine private interface name, no interface is assigned the private IP
address for the reservation: 127.0.0.1
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : {
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : "eth0" => {
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : "broadcast_address"
=> "10.x.x.x",
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : "ip_address" => {
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : "10.x.x.x" =>
"255.255.240.0"
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : },
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : "name" => "eth0",
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : "physical_address"
=> "00:50:56:23:00:bc"
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : },
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : "eth1" => {
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : "broadcast_address"
=> "x.x.x.x",
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : "default_gateway"
=> "x.x.x.x",
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : "ip_address" => {
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : "152.46.18.135"
=> "255.255.248.0"
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : },
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : "name" => "eth1",
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : "physical_address"
=> "00:50:56:23:00:bd"
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : },
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : "lo" => {
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : "ip_address" => {},
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : "name" => "lo"
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : }
|30351|3|3|new|OS.pm:get_private_interface_name|1451| : }
|30351|3|3|new|OS.pm:get_private_interface_name|1451| ( 0) OS.pm,
get_private_interface_name (line: 1451)
|30351|3|3|new|OS.pm:get_private_interface_name|1451| (-1) OS.pm,
get_private_network_configuration (line: 1695)
|30351|3|3|new|OS.pm:get_private_interface_name|1451| (-2) (eval 762), (eval)
(line: 1)
|30351|3|3|new|OS.pm:get_private_interface_name|1451| (-3) OS.pm,
get_ip_address (line: 1846)
|30351|3|3|new|OS.pm:get_private_interface_name|1451| (-4) OS.pm,
get_private_ip_address (line: 1901)
|30351|3|3|new|OS.pm:get_private_interface_name|1451| (-5) Linux.pm, post_load
(line: 418)
{noformat}
The next problem occurs when a computer is being loaded. Linux.pm's post_load
subroutine attempts to add firewall rules to allow traffic to any port and and
specifically to port 22 from the management node's private IP address. This
isn't working as expected because the private IP address could not be
determined. The result is the attempt to allow traffic to any port from the
management node's private IP address is skipped:
{noformat}
|30351|3|3|new|Linux.pm:enable_firewall_port|3655| ---- WARNING ----
|30351|3|3|new|Linux.pm:enable_firewall_port|3655| 2015-03-18
14:22:44|30351|3|3|new|Linux.pm:enable_firewall_port|3655|firewall not
modified, port argument is not restricted to a certain port: 'any', scope
argument was not sup
plied, it must be restricted to certain IP addresses if the port argument is
unrestricted
{noformat}
The attempt to allow traffic to port 22 is completed. However, because no IP
address was specified traffic is allowed from any address. At this point, the
management node can still control the computer.
After the computer is reserved and the user connects, the code attempts to lock
down the firewall to the user's remote IP address. Existing firewall rules for
the specific connect method port are replaced when a user initially connects:
{noformat}
2015-03-18
14:23:35|31054|3|3|reserved|Linux.pm:enable_firewall_port|3734|overwrite
existing argument specified, existing tcp/22 firewall rule(s) will be replaced:
|31054|3|3|reserved|Linux.pm:enable_firewall_port|3734| existing scope:
0.0.0.0/0.0.0.0
|31054|3|3|reserved|Linux.pm:enable_firewall_port|3734| new scope:
y.y.y.y/255.255.255.0
{noformat}
_y.y.y.y is the user's remote IP address in this example_
Once the firewall is modified, the managment loses control of the computer
because the only existing rule which allowed access, 22 from any IP address,
was removed. All commands after this point fail.
{noformat}
2015-03-18 14:23:35|31054|3|3|reserved|utils.pm:run_ssh_command|4181|executing
SSH command on 192.168.2.1 (vm241-1): '/sbin/iptables-save >
/etc/sysconfig/iptables'
|31054|3|3|reserved|utils.pm:run_ssh_command|4291| ---- WARNING ----
|31054|3|3|reserved|utils.pm:run_ssh_command|4291| 2015-03-18
14:23:35|31054|3|3|reserved|utils.pm:run_ssh_command|4291|attempt 1/3: failed
to execute SSH command on 192.168.2.1 (vm241-1): '/sbin/iptables-save >
/etc/sysconfig/iptables', exit status: 255, output:
|31054|3|3|reserved|utils.pm:run_ssh_command|4291| ssh output (/sbin/ipta...):
ssh: connect to host 192.168.2.1 port 22: No route to host
{noformat}
The user isn't affected at this point. Traffic is still allowed from his/her
remote IP address. The management node will continue to check for a user
connection every few minutes. It continues to fail to do so. The reservation
is not timed out when a management node has no control over the computer.
Everything is fine for the user as long as he/she does not change location. If
they do so and click the _Connect_ button from another remote IP address, the
management node won't be able to open the firewall to the new address and the
user will not be able to connect.
User initiated image captures will also fail:
{noformat}
|6680|3|3|image|OS.pm:pre_capture|102| ---- WARNING ----
|6680|3|3|image|OS.pm:pre_capture|102| 2015-03-18
14:31:22|6680|3|3|image|OS.pm:pre_capture|102|unable to complete capture
preparation tasks, vm241-1 is powered on but not responding to SSH
|6680|3|3|image|OS.pm:pre_capture|102| ( 0) OS.pm, pre_capture (line: 102)
|6680|3|3|image|OS.pm:pre_capture|102| (-1) Linux.pm, pre_capture (line: 331)
|6680|3|3|image|OS.pm:pre_capture|102| (-2) VMware.pm, capture (line: 752)
|6680|3|3|image|OS.pm:pre_capture|102| (-3) image.pm, process (line: 179)
|6680|3|3|image|OS.pm:pre_capture|102| (-4) vcld, make_new_child (line: 587)
|6680|3|3|image|OS.pm:pre_capture|102| (-5) vcld, main (line: 348)
{noformat}
One simple fix is to not use _localhost_ for the management node name. The
problems with the code need to be resolved regardless. A management node
should never lock itself out.
> Problems occur when "localhost" is used for a management node name
> ------------------------------------------------------------------
>
> Key: VCL-839
> URL: https://issues.apache.org/jira/browse/VCL-839
> Project: VCL
> Issue Type: Bug
> Components: vcld (backend)
> Affects Versions: 2.4
> Reporter: Andy Kurth
> Fix For: 2.4.1
>
>
> The {{vcl-install.sh}} script uses _localhost_ as the name of the management
> node by default. This _FQDN_ parameter in {{/etc/vcl/vcld.conf}} gets set to
> _localhost_ as well as the _managementnode.hostname_ value.
> The backend code needs to determine the private IP address being used on the
> management node. This is not stored in the database. Only the management
> node's hostname and an ambiguous _IPaddress_ values are stored in the
> management node table. The _IPaddress_ value should be set to the public IP
> address in order to allow management nodes which don't share the same private
> network to communicate.
> To determine its own private IP address, the management node attempts to
> resolve its hostname, _localhost_, which resolves to 127.0.0.1. After this
> step, the code compares the resolved IP address to the addresses assigned to
> the management node's interfaces. The loopback interface's IP addresses are
> explicitly excluded because there would be no reason for the code to ever use
> a loopback address.
> This introduces the first problem, which is mostly cosmetic at this point.
> The following warning is generated:
> {noformat}
> |30351|3|3|new|OS.pm:get_private_interface_name|1451| ---- WARNING ----
> |30351|3|3|new|OS.pm:get_private_interface_name|1451| 2015-03-18
> 14:17:32|30351|3|3|new|OS.pm:get_private_interface_name|1451|failed to
> determine private interface name, no interface is assigned the private IP
> address for the reservation: 127.0.0.1
> |30351|3|3|new|OS.pm:get_private_interface_name|1451| : {
> |30351|3|3|new|OS.pm:get_private_interface_name|1451| : "eth0" => {
> |30351|3|3|new|OS.pm:get_private_interface_name|1451| :
> "broadcast_address" => "10.x.x.x",
> |30351|3|3|new|OS.pm:get_private_interface_name|1451| : "ip_address" => {
> |30351|3|3|new|OS.pm:get_private_interface_name|1451| : "10.x.x.x" =>
> "255.255.240.0"
> |30351|3|3|new|OS.pm:get_private_interface_name|1451| : },
> |30351|3|3|new|OS.pm:get_private_interface_name|1451| : "name" => "eth0",
> |30351|3|3|new|OS.pm:get_private_interface_name|1451| :
> "physical_address" => "00:50:56:23:00:bc"
> |30351|3|3|new|OS.pm:get_private_interface_name|1451| : },
> |30351|3|3|new|OS.pm:get_private_interface_name|1451| : "eth1" => {
> |30351|3|3|new|OS.pm:get_private_interface_name|1451| :
> "broadcast_address" => "x.x.x.x",
> |30351|3|3|new|OS.pm:get_private_interface_name|1451| : "default_gateway"
> => "x.x.x.x",
> |30351|3|3|new|OS.pm:get_private_interface_name|1451| : "ip_address" => {
> |30351|3|3|new|OS.pm:get_private_interface_name|1451| : "152.46.18.135"
> => "255.255.248.0"
> |30351|3|3|new|OS.pm:get_private_interface_name|1451| : },
> |30351|3|3|new|OS.pm:get_private_interface_name|1451| : "name" => "eth1",
> |30351|3|3|new|OS.pm:get_private_interface_name|1451| :
> "physical_address" => "00:50:56:23:00:bd"
> |30351|3|3|new|OS.pm:get_private_interface_name|1451| : },
> |30351|3|3|new|OS.pm:get_private_interface_name|1451| : "lo" => {
> |30351|3|3|new|OS.pm:get_private_interface_name|1451| : "ip_address" =>
> {},
> |30351|3|3|new|OS.pm:get_private_interface_name|1451| : "name" => "lo"
> |30351|3|3|new|OS.pm:get_private_interface_name|1451| : }
> |30351|3|3|new|OS.pm:get_private_interface_name|1451| : }
> |30351|3|3|new|OS.pm:get_private_interface_name|1451| ( 0) OS.pm,
> get_private_interface_name (line: 1451)
> |30351|3|3|new|OS.pm:get_private_interface_name|1451| (-1) OS.pm,
> get_private_network_configuration (line: 1695)
> |30351|3|3|new|OS.pm:get_private_interface_name|1451| (-2) (eval 762), (eval)
> (line: 1)
> |30351|3|3|new|OS.pm:get_private_interface_name|1451| (-3) OS.pm,
> get_ip_address (line: 1846)
> |30351|3|3|new|OS.pm:get_private_interface_name|1451| (-4) OS.pm,
> get_private_ip_address (line: 1901)
> |30351|3|3|new|OS.pm:get_private_interface_name|1451| (-5) Linux.pm,
> post_load (line: 418)
> {noformat}
> The next problem occurs when a computer is being loaded. Linux.pm's
> post_load subroutine attempts to add firewall rules to allow traffic to any
> port and and specifically to port 22 from the management node's private IP
> address. This isn't working as expected because the private IP address could
> not be determined. The result is the attempt to allow traffic to any port
> from the management node's private IP address is skipped:
> {noformat}
> |30351|3|3|new|Linux.pm:enable_firewall_port|3655| ---- WARNING ----
> |30351|3|3|new|Linux.pm:enable_firewall_port|3655| 2015-03-18
> 14:22:44|30351|3|3|new|Linux.pm:enable_firewall_port|3655|firewall not
> modified, port argument is not restricted to a certain port: 'any', scope
> argument was not sup
> plied, it must be restricted to certain IP addresses if the port argument is
> unrestricted
> {noformat}
> The attempt to allow traffic to port 22 is completed. However, because no IP
> address was specified traffic is allowed from any address. At this point,
> the management node can still control the computer.
> After the computer is reserved and the user connects, the code attempts to
> lock down the firewall to the user's remote IP address. Existing firewall
> rules for the specific connect method port are replaced when a user initially
> connects:
> {noformat}
> 2015-03-18
> 14:23:35|31054|3|3|reserved|Linux.pm:enable_firewall_port|3734|overwrite
> existing argument specified, existing tcp/22 firewall rule(s) will be
> replaced:
> |31054|3|3|reserved|Linux.pm:enable_firewall_port|3734| existing scope:
> 0.0.0.0/0.0.0.0
> |31054|3|3|reserved|Linux.pm:enable_firewall_port|3734| new scope:
> y.y.y.y/255.255.255.0
> {noformat}
> _y.y.y.y is the user's remote IP address in this example_
> Once the firewall is modified, the managment loses control of the computer
> because the only existing rule which allowed access, 22 from any IP address,
> was removed. All commands after this point fail.
> {noformat}
> 2015-03-18
> 14:23:35|31054|3|3|reserved|utils.pm:run_ssh_command|4181|executing SSH
> command on 192.168.2.1 (vm241-1): '/sbin/iptables-save >
> /etc/sysconfig/iptables'
> |31054|3|3|reserved|utils.pm:run_ssh_command|4291| ---- WARNING ----
> |31054|3|3|reserved|utils.pm:run_ssh_command|4291| 2015-03-18
> 14:23:35|31054|3|3|reserved|utils.pm:run_ssh_command|4291|attempt 1/3: failed
> to execute SSH command on 192.168.2.1 (vm241-1): '/sbin/iptables-save >
> /etc/sysconfig/iptables', exit status: 255, output:
> |31054|3|3|reserved|utils.pm:run_ssh_command|4291| ssh output
> (/sbin/ipta...): ssh: connect to host 192.168.2.1 port 22: No route to host
> {noformat}
> The user isn't affected at this point. Traffic is still allowed from his/her
> remote IP address. The management node will continue to check for a user
> connection every few minutes. It continues to fail to do so. The
> reservation is not timed out when a management node has no control over the
> computer.
> Everything is fine for the user as long as he/she does not change location.
> If they do so and click the _Connect_ button from another remote IP address,
> the management node won't be able to open the firewall to the new address and
> the user will not be able to connect.
> User initiated image captures will also fail:
> {noformat}
> |6680|3|3|image|OS.pm:pre_capture|102| ---- WARNING ----
> |6680|3|3|image|OS.pm:pre_capture|102| 2015-03-18
> 14:31:22|6680|3|3|image|OS.pm:pre_capture|102|unable to complete capture
> preparation tasks, vm241-1 is powered on but not responding to SSH
> |6680|3|3|image|OS.pm:pre_capture|102| ( 0) OS.pm, pre_capture (line: 102)
> |6680|3|3|image|OS.pm:pre_capture|102| (-1) Linux.pm, pre_capture (line: 331)
> |6680|3|3|image|OS.pm:pre_capture|102| (-2) VMware.pm, capture (line: 752)
> |6680|3|3|image|OS.pm:pre_capture|102| (-3) image.pm, process (line: 179)
> |6680|3|3|image|OS.pm:pre_capture|102| (-4) vcld, make_new_child (line: 587)
> |6680|3|3|image|OS.pm:pre_capture|102| (-5) vcld, main (line: 348)
> {noformat}
> One simple fix is to not use _localhost_ for the management node name.
> Another fix would be to edit {{/etc/hosts}} on the management node and set
> localhost to the private IP address. I'm not sure if this will cause other
> problems if something relies on _localhost_ being a loopback address.
> Regardless, the problems with the code need to be resolved. A management
> node should never lock itself out.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
