Difference between revisions of "X inside VE"
(→Using Xephyr: changed comma to dot in DISPLAY value) |
|||
(31 intermediate revisions by 16 users not shown) | |||
Line 1: | Line 1: | ||
− | + | There are several ways to run X applications inside your [[container]]. | |
− | To run application inside | + | == X forwarding == |
+ | |||
+ | === Single application === | ||
+ | |||
+ | To run an X application inside a [[container]], one needs simply to connect to a container with '''ssh -X''': | ||
<pre> | <pre> | ||
− | host# ssh -X user@address | + | host# ssh -2 -c blowfish -X user@address |
</pre> | </pre> | ||
− | After login to | + | After login to container check that <code>$DISPLAY</code> variable is set and X11 forwarding is enabled: |
<pre> | <pre> | ||
− | + | ve# echo $DISPLAY | |
localhost:10.0 | localhost:10.0 | ||
</pre> | </pre> | ||
− | + | In case <code>$DISPLAY</code> is not set, make sure that X forwarding is enabled in <code>sshd</code> config inside container. In most Linux distros sshd configuration is stored in <code>/etc/ssh/sshd_config</code>. You should set parameter <code>X11Forwarding</code> to <code>yes</code>. Also container should contain <code>xauth</code> package, thus install <code>xauth</code> if it is missing (in Debian this is part of the xbase-clients package). After that, restart your sshd daemon: | |
− | |||
− | |||
<pre> | <pre> | ||
− | + | ve# /etc/init.d/sshd restart | |
</pre> | </pre> | ||
− | Don't forget to reconnect after this | + | {{Note|Don't forget to reconnect after this}} |
− | Now you can run X applications from your | + | Now you can run X applications from your container: |
<pre> | <pre> | ||
− | + | ve# firefox | |
</pre> | </pre> | ||
− | == | + | === Desktop === |
− | First, one need to run '''Xvnc''' server inside | + | |
+ | Note : If you want to run complete X window environment (including window manager), you should kill local window manager and run only pure X server. Secondly you should use '''-Y''' option when invoking ssh. And if you want to run gnome/kde/..., don't forget to increase [[UBC]] limits, 'cause default values are certainly too small for these monsters. ;) | ||
+ | |||
+ | You can run a desktop with ''xinit'' (on the node): | ||
+ | |||
+ | <pre> | ||
+ | xinit -e ssh -XCc blowfish user@ip_address "/usr/bin/xfce4-session &" -- :1 & disown | ||
+ | </pre> | ||
+ | |||
+ | * Substitute the window manager of choice | ||
+ | * Once xfce has started, you can then close the xterm if you like | ||
+ | |||
+ | |||
+ | Your node will be on Ctrl-Alt-F7 | ||
+ | |||
+ | And your VM on Ctrl-Alt-F8 | ||
+ | |||
+ | == VNC for X desktop == | ||
+ | First, one need to run '''Xvnc''' server inside container. The easiest way for this is to run | ||
'''vncserver''' script. This scripts starts all the required services | '''vncserver''' script. This scripts starts all the required services | ||
and small http daemon which provides graphical web access to your desktop (via Java applet). | and small http daemon which provides graphical web access to your desktop (via Java applet). | ||
<pre> | <pre> | ||
− | + | ve# vncserver -name mydesktop | |
− | New 'mydekstop' desktop is | + | New 'mydekstop' desktop is ve:1 |
Starting applications specified in ~/.vnc/xstartup | Starting applications specified in ~/.vnc/xstartup | ||
− | Log file is ~/.vnc/ | + | Log file is ~/.vnc/ve:1.log |
</pre> | </pre> | ||
Line 42: | Line 62: | ||
using '''vncviewer''' command: | using '''vncviewer''' command: | ||
<pre> | <pre> | ||
− | host# vncviewer < | + | host# vncviewer <container_IP>:1 |
</pre> | </pre> | ||
− | + | If the VNC desktop is the same size or larger than your X desktop, you will see scroll bars on the bottom and the side. This is often inconvenient. You may reduce your VNC desktop to a more reasonable size like this: | |
− | + | <pre>vncserver -geometry 1000x650</pre> | |
− | + | This setting works quite well for a 1024 by 768 X desktop setting. | |
− | == Connecting with VNC from firewalled network == | + | === Starting KDE desktop with VNC === |
+ | To start KDE desktop instead of default twm one replace <code>twm &</code> line with <code>startkde &</code> in user's | ||
+ | <code>~/.vnc/xstartup</code> file on the container. | ||
+ | |||
+ | === Connecting with VNC from firewalled network === | ||
VNC uses 590x TCP ports for its connections. These ports can be firewalled in | VNC uses 590x TCP ports for its connections. These ports can be firewalled in | ||
many networks so in order to be able to connect to remote side one need to tunnel VNC connections somehow. | many networks so in order to be able to connect to remote side one need to tunnel VNC connections somehow. | ||
− | A | + | A usual '''ssh''' can be used for tunneling VNC connections as described below. |
<pre> | <pre> | ||
Line 58: | Line 82: | ||
</pre> | </pre> | ||
− | where | + | where <remote host> is the name of the system you want to connect to. When you are asked for a username and password enter your normal username and password. Then start the VNC session to localhost, i.e. |
<pre> | <pre> | ||
Line 64: | Line 88: | ||
</pre> | </pre> | ||
− | == Using | + | == Using Xephyr == |
− | + | ||
− | + | Xephyr gives you nested X windows. | |
+ | |||
+ | First, install Xephyr on your host. | ||
+ | |||
+ | Start Xephyr | ||
+ | |||
+ | <pre>Xephyr -ac -screen 1280x1024 -br -reset -terminate :1 &</pre> | ||
+ | |||
+ | Change your display settings (don't forget to change them back after you establish a connection) | ||
+ | |||
+ | <pre>DISPLAY=:1.0</pre> | ||
+ | |||
+ | Forward your application or desktop over ssh to Xephyr | ||
+ | |||
+ | <pre>ssh -XfC -c blowfish user@server xfce4-session</pre> | ||
+ | |||
+ | If you use an alternate window manager, substitute "startkde", "gnome-session", "startfluxbox", etc. as needed. | ||
+ | |||
+ | [http://cafelinux.org/OptickleArt/albums/userpics/Xephyr.png Screenshot] | ||
+ | |||
+ | == Using XDM with XDMCP == | ||
+ | This method will give you a graphical login prompt remotely similar to VNC, but with some differences. Most notably, XDMCP is faster than VNC (due to the way each deals with screen handling) and but you CANNOT connect to existing sessions like you can with VNC. Each time you logout, your programs are closed. XDMCP is better suited in situations where you don't have a local display (or dumb terminals/clients) but want to run X11 programs | ||
+ | |||
+ | === container Configuration === | ||
+ | Install your desktop environment as you'd like (kde/gnome/xfce/etc) and ensure you install at least XDM. You can opt to use GDM/KDM as they also do the same job as XDM. The configuration for KDM/GDM is different than XDM's and I was only able to find one link on configuring GDM (more below). | ||
+ | |||
+ | ===== XDM ===== | ||
+ | Configuring XDM requires editing 3 files: /etc/X11/xdm/xdm-config, /etc/X11/xdm/Xservers, /etc/X11/xdm/Xaccess | ||
+ | |||
+ | In xdm-config, comment out the line where it says '''DisplayManager.requestPort: 0''' | ||
+ | |||
+ | In Xservers, comment out the line ''':0 local /usr/bin/X :0 vt7'''' (this starts a local X server, which will fail) | ||
+ | |||
+ | In Xaccess, uncomment the line with ''' * #any host can get a login window''' | ||
+ | (Please keep in mind the security implications by the above line. Read the comments found in the file and set it appropriately) | ||
+ | |||
+ | To provide the possibility to run sound applications from container, /dev/dsp device file needs to be exported in container: | ||
+ | <pre> | ||
+ | vzctl set 221 --devnodes dsp:rw --save | ||
+ | </pre> | ||
+ | |||
+ | Finally, if you intend to make xdm invoking a heavy desktop like kde, it is reasonable to increase the amount of memory available for allocation inside this container: | ||
+ | <pre> | ||
+ | vzctl set 221 --privvmpages 500M:600M --save | ||
+ | </pre> | ||
+ | For light desktop like icewm this is not needed. | ||
+ | |||
+ | Once these changes have been made, start your xdm server by the appropriate startup script (typically similar to /etc/init.d/xdm start). That concludes the XDM setup in the container. | ||
+ | |||
+ | ===== GDM ===== | ||
+ | Edit the '''gdm.conf''' file and in xdmcp section, comment out the '''0=standard''' line under the [servers] section - this will prevent gdm from trying to launch an X server on the local machine - it will simply listen for xdmcp requests. Insert '''0=inactive''' in [servers] section. Insert '''Enable=1''' in [xdmcp] section. Also, change from VCAllocation=true to VTAllocation=false and comment out the FirstVT=7 line if that lines exists. Change the access restrictions (if any) to suit your needs and then start GDM. | ||
− | However | + | === Client/Host Configuration === |
+ | |||
+ | On the Client/Host (whatever machine you are connecting from to the container), you need to install ONLY a bare Xserver as per your OS instructions (use yum, emerge, apt, whatever). A desktop environment like XFCE/GNOME/KDE is entirely optional on the client, but keep in mind that it won't be used while you're connecting to the desktop on the container. | ||
+ | |||
+ | To get access to the XDM server, just start an Xserver with '''X -query <remote IP> :0''' (where :0 is the local display...set to :1 if you already have an X session running, or use Xnest) | ||
+ | |||
+ | There are guides online on howto securely tunnel XDMCP over the Internet (typically vpn as XDMCP can't be tunneled over ssh afaik), in an otherwise INSECURE protocol. | ||
+ | |||
+ | === Errata === | ||
+ | On a side note, as of December 2007, I was never able to successfully get an Xserver to run inside a container and have the display output onto virtual-terminal 7 (the Xserver default), However, you can get an Xserver running on the hostnode to display output on virtual-terminal 7 without any special configuration (as the hostnode has direct access to all necessary devices). | ||
+ | |||
+ | Another user has done this with XDM and X. Just follow the directions on the wiki. It is possible. | ||
+ | |||
+ | == See also == | ||
+ | * [[NX inside VE]] | ||
== External links == | == External links == | ||
− | http://forum.openvz.org/index.php?t=tree&th=235&mid=1115&&rev=&reveal= | + | * http://www.myatus.co.uk/2009/08/24/x-server-with-sound-inside-an-openvz-proxmox-container/ |
− | http://ait.web.psi.ch/services/linux/ | + | * http://forum.openvz.org/index.php?t=tree&th=235&mid=1115&&rev=&reveal= |
− | http://ait.web.psi.ch/services/ssh/vnc-ssh.html | + | * http://ait.web.psi.ch/services/linux/software/local/by_task/desktop_sharing/index.html |
− | http://www.vnc.com/pipermail/vnc-list/2002-July/031831.html | + | * http://ait.web.psi.ch/services/ssh/vnc-ssh.html |
− | http://www.linuxjournal.com/article/5499 | + | * http://www.vnc.com/pipermail/vnc-list/2002-July/031831.html |
− | + | * http://www.linuxjournal.com/article/5499 | |
− | http://www.realvnc.com/pipermail/vnc-list/2002-March/029502.html | + | * http://www.realvnc.com/pipermail/vnc-list/2002-March/029502.html |
− | http://www.redhat.com/archives/rhl-list/2003-December/msg01859.html | + | * http://www.redhat.com/archives/rhl-list/2003-December/msg01859.html |
− | http://faq.gotomyvnc.com/fom-serve/cache/56.html | + | * http://faq.gotomyvnc.com/fom-serve/cache/56.html |
[[Category: HOWTO]] | [[Category: HOWTO]] | ||
+ | [[Category: Networking]] | ||
+ | [[Category: X]] |
Latest revision as of 09:03, 13 April 2016
There are several ways to run X applications inside your container.
Contents
X forwarding[edit]
Single application[edit]
To run an X application inside a container, one needs simply to connect to a container with ssh -X:
host# ssh -2 -c blowfish -X user@address
After login to container check that $DISPLAY
variable is set and X11 forwarding is enabled:
ve# echo $DISPLAY localhost:10.0
In case $DISPLAY
is not set, make sure that X forwarding is enabled in sshd
config inside container. In most Linux distros sshd configuration is stored in /etc/ssh/sshd_config
. You should set parameter X11Forwarding
to yes
. Also container should contain xauth
package, thus install xauth
if it is missing (in Debian this is part of the xbase-clients package). After that, restart your sshd daemon:
ve# /etc/init.d/sshd restart
Note: Don't forget to reconnect after this |
Now you can run X applications from your container:
ve# firefox
Desktop[edit]
Note : If you want to run complete X window environment (including window manager), you should kill local window manager and run only pure X server. Secondly you should use -Y option when invoking ssh. And if you want to run gnome/kde/..., don't forget to increase UBC limits, 'cause default values are certainly too small for these monsters. ;)
You can run a desktop with xinit (on the node):
xinit -e ssh -XCc blowfish user@ip_address "/usr/bin/xfce4-session &" -- :1 & disown
- Substitute the window manager of choice
- Once xfce has started, you can then close the xterm if you like
Your node will be on Ctrl-Alt-F7
And your VM on Ctrl-Alt-F8
VNC for X desktop[edit]
First, one need to run Xvnc server inside container. The easiest way for this is to run vncserver script. This scripts starts all the required services and small http daemon which provides graphical web access to your desktop (via Java applet).
ve# vncserver -name mydesktop New 'mydekstop' desktop is ve:1 Starting applications specified in ~/.vnc/xstartup Log file is ~/.vnc/ve:1.log
Now when your desktop is up and running you can connect to it using vncviewer command:
host# vncviewer <container_IP>:1
If the VNC desktop is the same size or larger than your X desktop, you will see scroll bars on the bottom and the side. This is often inconvenient. You may reduce your VNC desktop to a more reasonable size like this:
vncserver -geometry 1000x650
This setting works quite well for a 1024 by 768 X desktop setting.
Starting KDE desktop with VNC[edit]
To start KDE desktop instead of default twm one replace twm &
line with startkde &
in user's
~/.vnc/xstartup
file on the container.
Connecting with VNC from firewalled network[edit]
VNC uses 590x TCP ports for its connections. These ports can be firewalled in many networks so in order to be able to connect to remote side one need to tunnel VNC connections somehow. A usual ssh can be used for tunneling VNC connections as described below.
localhost# ssh -L 5900:localhost:5900 <remote host>
where <remote host> is the name of the system you want to connect to. When you are asked for a username and password enter your normal username and password. Then start the VNC session to localhost, i.e.
localhost# vncviewer localhost
Using Xephyr[edit]
Xephyr gives you nested X windows.
First, install Xephyr on your host.
Start Xephyr
Xephyr -ac -screen 1280x1024 -br -reset -terminate :1 &
Change your display settings (don't forget to change them back after you establish a connection)
DISPLAY=:1.0
Forward your application or desktop over ssh to Xephyr
ssh -XfC -c blowfish user@server xfce4-session
If you use an alternate window manager, substitute "startkde", "gnome-session", "startfluxbox", etc. as needed.
Using XDM with XDMCP[edit]
This method will give you a graphical login prompt remotely similar to VNC, but with some differences. Most notably, XDMCP is faster than VNC (due to the way each deals with screen handling) and but you CANNOT connect to existing sessions like you can with VNC. Each time you logout, your programs are closed. XDMCP is better suited in situations where you don't have a local display (or dumb terminals/clients) but want to run X11 programs
container Configuration[edit]
Install your desktop environment as you'd like (kde/gnome/xfce/etc) and ensure you install at least XDM. You can opt to use GDM/KDM as they also do the same job as XDM. The configuration for KDM/GDM is different than XDM's and I was only able to find one link on configuring GDM (more below).
XDM[edit]
Configuring XDM requires editing 3 files: /etc/X11/xdm/xdm-config, /etc/X11/xdm/Xservers, /etc/X11/xdm/Xaccess
In xdm-config, comment out the line where it says DisplayManager.requestPort: 0
In Xservers, comment out the line :0 local /usr/bin/X :0 vt7' (this starts a local X server, which will fail)
In Xaccess, uncomment the line with * #any host can get a login window (Please keep in mind the security implications by the above line. Read the comments found in the file and set it appropriately)
To provide the possibility to run sound applications from container, /dev/dsp device file needs to be exported in container:
vzctl set 221 --devnodes dsp:rw --save
Finally, if you intend to make xdm invoking a heavy desktop like kde, it is reasonable to increase the amount of memory available for allocation inside this container:
vzctl set 221 --privvmpages 500M:600M --save
For light desktop like icewm this is not needed.
Once these changes have been made, start your xdm server by the appropriate startup script (typically similar to /etc/init.d/xdm start). That concludes the XDM setup in the container.
GDM[edit]
Edit the gdm.conf file and in xdmcp section, comment out the 0=standard line under the [servers] section - this will prevent gdm from trying to launch an X server on the local machine - it will simply listen for xdmcp requests. Insert 0=inactive in [servers] section. Insert Enable=1 in [xdmcp] section. Also, change from VCAllocation=true to VTAllocation=false and comment out the FirstVT=7 line if that lines exists. Change the access restrictions (if any) to suit your needs and then start GDM.
Client/Host Configuration[edit]
On the Client/Host (whatever machine you are connecting from to the container), you need to install ONLY a bare Xserver as per your OS instructions (use yum, emerge, apt, whatever). A desktop environment like XFCE/GNOME/KDE is entirely optional on the client, but keep in mind that it won't be used while you're connecting to the desktop on the container.
To get access to the XDM server, just start an Xserver with X -query <remote IP> :0 (where :0 is the local display...set to :1 if you already have an X session running, or use Xnest)
There are guides online on howto securely tunnel XDMCP over the Internet (typically vpn as XDMCP can't be tunneled over ssh afaik), in an otherwise INSECURE protocol.
Errata[edit]
On a side note, as of December 2007, I was never able to successfully get an Xserver to run inside a container and have the display output onto virtual-terminal 7 (the Xserver default), However, you can get an Xserver running on the hostnode to display output on virtual-terminal 7 without any special configuration (as the hostnode has direct access to all necessary devices).
Another user has done this with XDM and X. Just follow the directions on the wiki. It is possible.
See also[edit]
External links[edit]
- http://www.myatus.co.uk/2009/08/24/x-server-with-sound-inside-an-openvz-proxmox-container/
- http://forum.openvz.org/index.php?t=tree&th=235&mid=1115&&rev=&reveal=
- http://ait.web.psi.ch/services/linux/software/local/by_task/desktop_sharing/index.html
- http://ait.web.psi.ch/services/ssh/vnc-ssh.html
- http://www.vnc.com/pipermail/vnc-list/2002-July/031831.html
- http://www.linuxjournal.com/article/5499
- http://www.realvnc.com/pipermail/vnc-list/2002-March/029502.html
- http://www.redhat.com/archives/rhl-list/2003-December/msg01859.html
- http://faq.gotomyvnc.com/fom-serve/cache/56.html