cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthew Hartmann" <mhartm...@tls.net>
Subject RE: Make vnc bind to 0.0.0.0 insted of localhost on XenServer 6 with CS 3.0.2
Date Tue, 06 Nov 2012 14:08:27 GMT
Just to add my $0.02, but I had originally reported this issue in March
2012.

http://bugs.cloudstack.org/browse/CS-13931

However the assigned developer claimed he could not re-create the issue. I
do not see a bug in the Apache Jira so I linked to the original bug report
in the (pre-Apache) CloudStack Jira.


Matthew Hartmann
Systems Administrator | V: 812.378.4100 x 850 | E: mhartmann@tls.net

TLS.NET, Inc.
http://www.tls.net

-----Original Message-----
From: France [mailto:mailinglists@isg.si] 
Sent: Tuesday, November 06, 2012 6:39 AM
To: cloudstack-users@incubator.apache.org
Cc: Rajesh Battala
Subject: Re: Make vnc bind to 0.0.0.0 insted of localhost on XenServer 6
with CS 3.0.2

Hi Rajesh,

if there is a more secure solution, which we can implement, we'll be 
happy to do so.

Because we need working console access for our Windows VM, i'm willing 
to live with option, that if someone gains access to our management 
network, where hypervisors are, then he can access VNC consoles. If 
hacker gains access to our management network, we have bigger problems 
anyway.

Thank you for your help.
Regards,
F.

On 6/11/12 11:33 AM, Rajesh Battala wrote:
> Hi France,
> If the vnc starts listening 0.0.0.0 then with vnc viewer we can access the
consoles of any VM running in the host without any password.
>
> This will be a security issue as we are accessing any VM console running
in the host without any password.
>
> Thanks
> Rajesh Battala
>
> -----Original Message-----
> From: France [mailto:mailinglists@isg.si]
> Sent: Tuesday, November 06, 2012 3:06 PM
> To: cloudstack-users@incubator.apache.org
> Cc: Rajesh Battala
> Subject: Re: Make vnc bind to 0.0.0.0 insted of localhost on XenServer 6
with CS 3.0.2
>
> Hi Rajesh and others,
>
> i decided that we don't have time to discuss this anymore, so i just
hacked myself qemu-dm-wrapper file.
> I used this commit as a guideline:
>
https://github.com/xen-org/xen-api/commit/682f85fadff8cf199c8bf932854c5ef1a9
a3e0a7
>
> this is the change i did:
> [root@x1 libexec]# diff /root/qemu-dm-wrapper qemu-dm-wrapper
> 98a99,101
>   >     qemu_args.append("-vnc")
>   >     qemu_args.append("0.0.0.0:1")
>   >
>
> After migrating one Windows VM to x1 hipervisor host, i get a working
console using CS 3.0.2 GUI.
>
> If this is somehow wrong or will have some dire consequences please let me
know, otherwise i'll just do it on all hypervisors.
>
> Regards,
> F.
>
> On 6/11/12 10:17 AM, France wrote:
>> Hi Rajesh,
>>
>> stopping and starting (not restarting) did not help.
>> The console still isn't accessible from CloudStack GUI.
>>
>> On unrelated note, it works from XenCenter.
>> As for the wiki post, i cannot read it. I get this error upon visiting
>> with registered username:
>> -
>> You cannot view this page due to inherited restrictions Page level
>> restrictions have been applied to a parent of the current page. These
>> restrictions limit access to certain user(s) or group(s) and apply to
>> all pages underneath the parent.
>> -
>>
>> Regards,
>> F.
>>
>> On 6/11/12 6:35 AM, Rajesh Battala wrote:
>>> Hi France,
>>>
>>> Moving vnc term to listen on localhost is done because of this
>>> http://wiki.cloudstack.org/display/RelOps/Secure+Console+Access+on+Xe
>>> nServer ( sorry to point to cloudstack wiki as I didn't find the same
>>> page in apache Cwiki).
>>>
>>> Can you please stop the vm and then start instead of restarting the
>>> vm and let us know the issue is resolved or not?
>>>
>>> Thanks
>>> Rajesh Battala
>>>
>>>
>>>
>>> From: France [mailto:mailinglists@isg.si]
>>> Sent: Monday, November 05, 2012 8:25 PM
>>> To: Rajesh Battala
>>> Cc: cloudstack-users@incubator.apache.org
>>> Subject: Re: Make vnc bind to 0.0.0.0 insted of localhost on
>>> XenServer 6 with CS 3.0.2
>>>
>>> Hi Rajesh,
>>>
>>> thank you for taking the time and helping us with this issue.
>>> Below is additional information.
>>> Some of the consoles started working after rebooting them via
>>> CloudStack GUI, while some (Windows) are still inaccessible. This
>>> seems to be now a Windows only issue or an issue related to:
>>> qemu-dm-wrapper script.
>>>
>>> Currently on none of the running/old (not rebooted) instances console
>>> is available.
>>> After rebooting "Console Proxy VM" itself, i can access following
>>> system VMs:
>>> "Secondary Storage VM"
>>> "Console Proxy VM"
>>> All rebooted system routers.
>>>
>>> If i reboot Linux based VM, router or user's instance, the console
>>> starts working again.
>>> If i create a new centos 6.3 VM, i also get a working web console.
>>>
>>> If i create a new windows 2008R2 vm or if a reboot an already created
>>> one, i cannot get the console. I could before installing hotfixes.
>>>
>>> This is how netstat looks if for that windows VM:
>>> tcp        0      0 127.0.0.1:5901 0.0.0.0:*
>>> LISTEN      8232/vncterm
>>> tcp        0      0 127.0.0.1:9501 0.0.0.0:*
>>> LISTEN      8232/vncterm
>>> This is how netstat looks if a live migrate another linux to the same
>>> hipervisor:
>>> tcp        0      0 127.0.0.1:5901 0.0.0.0:*
>>> LISTEN      8232/vncterm
>>> tcp        0      0 0.0.0.0:5903 0.0.0.0:*
>>> LISTEN      5065/vncterm
>>> tcp        0      0 127.0.0.1:9501 0.0.0.0:*
>>> LISTEN      8232/vncterm
>>> tcp        0      0 0.0.0.0:9502 0.0.0.0:*
>>> LISTEN      5065/vncterm
>>>
>>> Some additional details:
>>> [root@x1 ~]# netstat -paltn | grep 59
>>> tcp        0      0 127.0.0.1:5901 0.0.0.0:*
>>> LISTEN      8232/vncterm
>>> tcp        0      0 127.0.0.1:5902 0.0.0.0:*
>>> LISTEN      3504/qemu-dm-15
>>> tcp        0      0 0.0.0.0:5903 0.0.0.0:*
>>> LISTEN      5065/vncterm
>>> tcp        0      0 10.31.0.21:59994 10.31.0.24:443
>>> ESTABLISHED 8288/stunnel
>>> tcp        0      0 10.31.0.21:5903 10.31.0.238:39476
>>> ESTABLISHED 5075/vncterm
>>> tcp        0      0 10.31.0.21:48259 10.31.0.24:443
>>> TIME_WAIT   -
>>>
>>> It seems to me that the problem is, that qemu-dm-wrapper is listening
>>> on 127.0.0.1 instead of 0.0.0.0. Probably qemu-dm-wrapper was changed
>>> by some hotfix.
>>>
>>> So to sum up again. Using windows templates after installing
>>> hotfixes, VNC get's binded to localhost (127.0.01) instead of binding
>>> it to every IPv4: 0.0.0.0.
>>> Please advise how to get Windows consoles back or make it listen on
>>> all IPs.
>>>
>>> Thank you and Regards,
>>> F.
>>> On 5/11/12 11:40 AM, Rajesh Battala wrote:
>>> Hi France,
>>> For which kind of instances you are getting the error message? [Newly
>>> created or old vm's ] Were you able to view the console for the
>>> system VM's?
>>>
>>> Thanks
>>> Rajesh Battala
>>>
>>> From: France [mailto:mailinglists@isg.si]
>>> Sent: Monday, November 05, 2012 3:36 PM
>>> To:
>>> cloudstack-users@incubator.apache.org<mailto:cloudstack-users@incubat
>>> or.apache.org>
>>> Cc: Rajesh Battala
>>> Subject: Re: Make vnc bind to 0.0.0.0 insted of localhost on
>>> XenServer 6 with CS 3.0.2
>>>
>>> Hi Rajesh,
>>>
>>> thank you for your explanation.
>>> What is the proposed solution to get the proxy web console
>>> back/working in CloudStack 3.0.2 web GUI?
>>>
>>> Currently i'm getting error: " Unable to start console session as
>>> connection is refused by the machine you are accessing"
>>>
>>> Regards,
>>> M.
>>> On 5/11/12 10:50 AM, Rajesh Battala wrote:
>>>
>>> Hi  France,
>>>
>>> We had modified the vnc config on xenserver hosts to listen on
>>> localhost instead of 0.0.0.0 because of security reasons.
>>>
>>> In your 3.0.2 environment, CS uses https console url provided by the
>>> xenserver host to stream the VNC to the Ajax client.
>>>
>>>
>>>
>>> Thanks
>>>
>>> Rajesh Battala
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>>
>>> From: France [mailto:mailinglists@isg.si]
>>>
>>> Sent: Monday, November 05, 2012 3:11 PM
>>>
>>> To:
>>> cloudstack-users@incubator.apache.org<mailto:cloudstack-users@incubat
>>> or.apache.org>
>>>
>>> Subject: Make vnc bind to 0.0.0.0 insted of localhost on XenServer 6
>>> with CS 3.0.2
>>>
>>>
>>>
>>> Hi,
>>>
>>>
>>>
>>> i'm using CloudStack 3.0.2 (as per last official release) and
>>> XenServer 6.0.2-53456p (xenenterprise).
>>>
>>>
>>>
>>> After installing some of these hotfixes:
>>>
>>> [root@x4 ~]# xe patch-list | grep XS6
>>>
>>>                  name-label ( RO): XS602E002
>>>
>>>                  name-label ( RO): XS602E005
>>>
>>>                  name-label ( RO): XS602E006
>>>
>>>                  name-label ( RO): XS602E003
>>>
>>>                  name-label ( RO): XS602E001
>>>
>>>                  name-label ( RO): XS602E008
>>>
>>>                  name-label ( RO): XS602E009
>>>
>>>                  name-label ( RO): XS602E004
>>>
>>>                  name-label ( RO): XS602E007
>>>
>>>
>>>
>>> VNC terminal get's binded to 127.0.0.1 or localhost instead of
>>> binding to 0.0.0.0, which in turn means, that newly created
>>> (restarted?) virtual instances can not be accessed with WEB proxy
>>> console, because connection to hipervisor host is refused.
>>>
>>> [root@x4 ~]# netstat -apltn | grep vnc
>>>
>>> tcp        0      0 127.0.0.1:9504 0.0.0.0:*
>>>
>>> LISTEN      11695/vncterm
>>>
>>> tcp        0      0 127.0.0.1:9505 0.0.0.0:*
>>>
>>> LISTEN      12269/vncterm
>>>
>>> tcp        0      0 127.0.0.1:5901 0.0.0.0:*
>>>
>>> LISTEN      8128/vncterm
>>>
>>> tcp        0      0 0.0.0.0:5902 0.0.0.0:* LISTEN
>>>
>>> 28166/vncterm
>>>
>>> tcp        0      0 127.0.0.1:5903 0.0.0.0:*
>>>
>>> LISTEN      11251/vncterm
>>>
>>> tcp        0      0 127.0.0.1:5904 0.0.0.0:*
>>>
>>> LISTEN      11695/vncterm
>>>
>>> tcp        0      0 127.0.0.1:5905 0.0.0.0:*
>>>
>>> LISTEN      12269/vncterm
>>>
>>> tcp        0      0 127.0.0.1:9501 0.0.0.0:*
>>>
>>> LISTEN      8128/vncterm
>>>
>>> tcp        0      0 0.0.0.0:9502 0.0.0.0:* LISTEN
>>>
>>> 28166/vncterm
>>>
>>> tcp        0      0 127.0.0.1:9503 0.0.0.0:*
>>>
>>> LISTEN      11251/vncterm
>>>
>>>
>>>
>>> #####
>>>
>>> How can i make newly created (restarted?) virtual instances to bind
>>> to
>>>
>>> 0.0.0.0 again?
>>>
>>> #####
>>>
>>>
>>>
>>>
>>>
>>> We've had a lot of other problems after the upgrade(s), most of them
>>>
>>> solved bo manually copying files from cloudstack management server to
>>>
>>> hipervisors. Like: NFSSR.py to fix storage template problems. This
>>>
>>> problem might be related to files:
>>>
>>> /opt/xensource/libexec/vncterm-wrapper or qemu-dm-wrapper but i don't
>>>
>>> want to screw around with these on production system myself.
>>>
>>> Please advise. Thank you.
>>>
>>>
>>>
>>> Regards,
>>>
>>> France
>>>
>>>
>>>



Mime
View raw message