Graphical Console Missing

When using Xenserver, if you go to a specific managed system and click Graphical Console it gives an error and does not work.

The page just displays: Missing lsof command

Status: 
Closed (fixed)

Comments

Try running yum install lsof on the host system.

Thanks, this was not installed in the system by default, since its a clean install and only cloudmin was installed, maybe the installer missed this package.

I see now the option for a flash/java console.

Unfortunately the Cloudmin installer cannot install this, as it is needed on the Citrix Xen host system.

That is strange, I did not installed this on the Citrix Host System.

I installed this on the system where Cloudmin is running.

Thanks - I will add this as a dependency in future.

Well that fixed the mentioned error, I now get indeed an option for 2 consoles, both Flash and Java, but none of them actually work.

I don´t know if this is related to that error or not, as before I did not even loaded the consoles. It was just a straight blank page with an error. Now I does load the consoles.

The Java one, just loads and then gives just fails related to the security settings.

The flash one gives an error, tested in several browsers.

An security error ocurred (Error #2048). Check your policy-policy server configuration or disable security for this domain

When you mentioned this has to be installed in the Citrix Host what exactly where you saying? Installing it in the node server?

My guess is that both consoles need to be executed from the Cloudmin server and connect remotely to the Citrix host but establishing a tunnel to the local VNC ports.

Is there anything special required to make them run?

This is what I assumed how it would work.

That looks like an unrelated issue to the problem with the lsof command.

At the bottom of the graphical console page there should be instructions on now to connect with a separate VNC client like realVNC. Does that work for you?

Yes I thought it was not related.

No, I can´t connect via VNC directly either.

It says there to connect to

mycloudminserver.domain.com port 5900

Is Cloudmin acting as proxy for the XenServer hosts? If yes I assume this is correct, otherwise I think it would list there the Xen host domain name for connection but then this would not work by default, I know that XenServer does not allow to VNC directly without establishing a session first for security purposes.

So what I assume is: The Cloudmin server establish this session "it has the SSH logins for doing this" and then you actually connect to the Cloudmin on its local port which is just a proxy to the remote XenServer node. If this correct? Then the information I see there is correct.

Either way this issue was about the lsof issue, this was executed only in the cloudmin server, not in any XenServer hosts by the way, just for confirmation since I assume this has nothing to with the hosts itself, since the console only need to run in the Cloudmin control panel itself.

I don´t know how Cloudmin tries too or establish a connection, otherwise I would try to debug this. My perception is (since I did this in the past) is that it actually does create a SSH session, which automatically makes a tunnel to the Xenserver host, then the user can connect via Cloudmin or even on its local porst like "localhost:5900" to his VM since he actually has opened a secure SSH tunnel to the server, the VNC protocol is not safe otherwise and this is why its not allowed to connect to VNC on XenServer by default, not at least without messing with its firewall and making it insecure.

Like I did this in the past, was,

Create a temporary SSH user in the XenServer node, with some tokens that expire right away after starting the VNC.

Starting the VNC on the client side, Java usually, which just opens "localhost:port" since he already has a SSH session into the server, his session is secure and the VNC viewer, Java or Flash can connect locally.

Since there is absolutely no way to avoid the user establishing the SSH session on his side, regardless if he runs Flash or the Java viewer it would be absolutely crazy to do with root, otherwise a customer could snif the package and get root access to the whole node, the only way I found is temporary SSH user, that is cut off once the VNC is initiated, the users does not even know the logins, but even if he gets this from his local computer, he could not be able to do anything with them, since the SSH session from that user does not exists anymore.

I have noticed that even if you delete the SSH user, the connection does not break, this means you can actually erase the user 1 minute or after confirming the VNC session, so if he gets the logins, he cannot actually login with those, just uses his current VNC session and once its done, the ssh session dies together.

Another way would be cloudmin actually establishing the session and acting as some type of secure proxy.

What Cloudmin does is establish a connection from the master system to the correct VNC port on the Xen host, picks a free port on the master, and then forwards traffic between them. This is needed because Java and Flash objects cannot connect to arbitrary hosts - only the one they were loaded from.

Automatically closed -- issue fixed for 2 weeks with no activity.

Can you please confirm again where does lsof need to be installed?

The cloudmin machine (controller) or the Citrix Hosts (node) or both?

Regards

lsof needs to be installed on the Cloudmin master system.

Ok, so this should be included by the installer script them. Of course Cloudmin cannot install anything on the nodes (and it should not either), but if this is indeed installed in the server where Cloudmin is installed/running, a simple extra command in the installer would fix this: yum lsof install -y

I tested this 2 times, in several months and it seems the installer misses to install this on CentOS 6. Nothing serious but just something to add to the installer script then.

Regards

I actually thought the installer had been updated to do this already, but it turns out I was wrong :-( It is fixed now though.

Automatically closed -- issue fixed for 2 weeks with no activity.