https://wiki.openvz.org/api.php?action=feedcontributions&user=Adeel&feedformat=atomOpenVZ Virtuozzo Containers Wiki - User contributions [en]2024-03-29T01:09:50ZUser contributionsMediaWiki 1.31.1https://wiki.openvz.org/index.php?title=RequestedTutorials&diff=6693RequestedTutorials2008-11-16T03:20:30Z<p>Adeel: </p>
<hr />
<div><b>Please make a list of the tutorials you'd like to have written up or done in a quick screen capture movie.</b><br />
<br />
*There are no explicit instructions here about creating an Application Template for VPS's. Is this even possible with OpenVZ? A tutorial would be great.<br />
** Hope this helps, [[Application Templates]] [[User:Adeel|Adeel]] 03:20, 16 November 2008 (UTC)<br />
<br />
<br />
[[Category:HOWTO]]</div>Adeelhttps://wiki.openvz.org/index.php?title=Application_Templates&diff=6692Application Templates2008-11-16T03:18:49Z<p>Adeel: </p>
<hr />
<div>===Abstract===<br />
Application Templates (AT's) are commonly found when using Virtualization as a means to try out new software without having to perform a full manual install. Unfortunately, OpenVZ, as of yet, doesn't have any precreated AT's for people to try out, which might be attributed to the lack of documentation on how to create them. The primary goal of this howto is to give an overview of how an AT can be created for OpenVZ without too much trouble. This howto assumes the user is familiar with basic OpenVZ terminology and operation, so basic tasks such as setting VE memory, networking parameters, package repositories, etc are not covered here.<br />
<br />
===Introduction===<br />
There are two ways to create an AT: as a full VE template, or an interactive shell script/installer that installs the software into an existing VE. The second method is more advanced, and will be very specific to the individual applications, so is out of the scope of this document.<br />
<br />
===Step 1: The Base===<br />
Choose the base OS you'd like to use and find an existing VE template to use (or create your [{{fullurl:Category:Templates}} own]). For this document, I'm using the [http://download.openvz.org/template/precreated/contrib/centos-5-x86_64-default-5.2-20081107.tar.gz CentOS 5 x86_64] template and will be installing Ruby-on-Rails.<br />
====Creating the bare VE====<br />
<pre>vzctl create 3000 --ostemplate centos-5-x86_64-default-5.2-20081107 --hostname RoR-AT <br />
vzctl set 3000 --userpasswd root:<whatever> --save</pre><br />
<br />
===Step 2: Software Installation===<br />
This is the part where you'll follow the application specific installation procedures. Make sure that you install all the dependancies and do a proper configuration so that the application is usable.<br />
In regards to Ruby-on-Rails, I found a good guide on installing RoR on CentOS [http://wiki.rubyonrails.org/rails/pages/RailsOnCentos here].<br />
<br />
===Step 3: Package the Software===<br />
Once you have everything installed and configured, packaging is a simple procedure:<br />
*Remove any unecessary files (e.g. /tmp /var/tmp /usr/src/, any downloaded files, etc)<br />
*Stop the VE<br />
:<pre>vzctl stop 3000</pre><br />
*Create a tar.gz of the /vz/private/$VEID directory<br />
:<pre>tar xfvz /vz/template/cache/centos-5-x86_64-RoR-AT-11152008.tar.gz /vz/private/3000/ </pre><br />
*Done<br />
<br />
===Step 4: Deployment/Distribution===<br />
To do rapid deployment of your new AT, you can utilize for/while loops to create multiple VE's as shown [[Demo scripts | here]].<br />
<br />
As for distribution, please share any of the AT's you create [http://download.openvz.org/template/precreated/contrib/ here]<br />
<br />
[[Category:HOWTO]]<br />
[[Category:Templates]]</div>Adeelhttps://wiki.openvz.org/index.php?title=Application_Templates&diff=6691Application Templates2008-11-16T03:18:24Z<p>Adeel: add to proper categories</p>
<hr />
<div>===Abstract===<br />
Application Templates (AT's) are commonly found when using Virtualization as a means to try out new software without having to perform a full manual install. Unfortunately, OpenVZ, as of yet, doesn't have any precreated AT's for people to try out, which might be attributed to the lack of documentation on how to create them. The primary goal of this howto is to give an overview of how an AT can be created for OpenVZ without too much trouble. This howto assumes the user is familiar with basic OpenVZ terminology and operation, so basic tasks such as setting VE memory, networking parameters, package repositories, etc are not covered here.<br />
<br />
===Introduction===<br />
There are two ways to create an AT: as a full VE template, or an interactive shell script/installer that installs the software into an existing VE. The second method is more advanced, and will be very specific to the individual applications, so is out of the scope of this document.<br />
<br />
===Step 1: The Base===<br />
Choose the base OS you'd like to use and find an existing VE template to use (or create your [{{fullurl:Category:Templates}} own]). For this document, I'm using the [http://download.openvz.org/template/precreated/contrib/centos-5-x86_64-default-5.2-20081107.tar.gz CentOS 5 x86_64] template and will be installing Ruby-on-Rails.<br />
====Creating the bare VE====<br />
<pre>vzctl create 3000 --ostemplate centos-5-x86_64-default-5.2-20081107 --hostname RoR-AT <br />
vzctl set 3000 --userpasswd root:<whatever> --save</pre><br />
<br />
===Step 2: Software Installation===<br />
This is the part where you'll follow the application specific installation procedures. Make sure that you install all the dependancies and do a proper configuration so that the application is usable.<br />
In regards to Ruby-on-Rails, I found a good guide on installing RoR on CentOS [http://wiki.rubyonrails.org/rails/pages/RailsOnCentos here].<br />
<br />
===Step 3: Package the Software===<br />
Once you have everything installed and configured, packaging is a simple procedure:<br />
*Remove any unecessary files (e.g. /tmp /var/tmp /usr/src/, any downloaded files, etc)<br />
*Stop the VE<br />
:<pre>vzctl stop 3000</pre><br />
*Create a tar.gz of the /vz/private/$VEID directory<br />
:<pre>tar xfvz /vz/template/cache/centos-5-x86_64-RoR-AT-11152008.tar.gz /vz/private/3000/ </pre><br />
*Done<br />
<br />
===Step 4: Deployment/Distribution===<br />
To do rapid deployment of your new AT, you can utilize for/while loops to create multiple VE's as shown [[Demo scripts | here]].<br />
<br />
As for distribution, please share any of the AT's you create [http://download.openvz.org/template/precreated/contrib/ here]<br />
<br />
[[Category:HOWTO]]<br />
[[Category:Template]]</div>Adeelhttps://wiki.openvz.org/index.php?title=Application_Templates&diff=6690Application Templates2008-11-16T03:17:33Z<p>Adeel: finish initial write-up</p>
<hr />
<div>===Abstract===<br />
Application Templates (AT's) are commonly found when using Virtualization as a means to try out new software without having to perform a full manual install. Unfortunately, OpenVZ, as of yet, doesn't have any precreated AT's for people to try out, which might be attributed to the lack of documentation on how to create them. The primary goal of this howto is to give an overview of how an AT can be created for OpenVZ without too much trouble. This howto assumes the user is familiar with basic OpenVZ terminology and operation, so basic tasks such as setting VE memory, networking parameters, package repositories, etc are not covered here.<br />
<br />
===Introduction===<br />
There are two ways to create an AT: as a full VE template, or an interactive shell script/installer that installs the software into an existing VE. The second method is more advanced, and will be very specific to the individual applications, so is out of the scope of this document.<br />
<br />
===Step 1: The Base===<br />
Choose the base OS you'd like to use and find an existing VE template to use (or create your [{{fullurl:Category:Templates}} own]). For this document, I'm using the [http://download.openvz.org/template/precreated/contrib/centos-5-x86_64-default-5.2-20081107.tar.gz CentOS 5 x86_64] template and will be installing Ruby-on-Rails.<br />
====Creating the bare VE====<br />
<pre>vzctl create 3000 --ostemplate centos-5-x86_64-default-5.2-20081107 --hostname RoR-AT <br />
vzctl set 3000 --userpasswd root:<whatever> --save</pre><br />
<br />
===Step 2: Software Installation===<br />
This is the part where you'll follow the application specific installation procedures. Make sure that you install all the dependancies and do a proper configuration so that the application is usable.<br />
In regards to Ruby-on-Rails, I found a good guide on installing RoR on CentOS [http://wiki.rubyonrails.org/rails/pages/RailsOnCentos here].<br />
<br />
===Step 3: Package the Software===<br />
Once you have everything installed and configured, packaging is a simple procedure:<br />
*Remove any unecessary files (e.g. /tmp /var/tmp /usr/src/, any downloaded files, etc)<br />
*Stop the VE<br />
:<pre>vzctl stop 3000</pre><br />
*Create a tar.gz of the /vz/private/$VEID directory<br />
:<pre>tar xfvz /vz/template/cache/centos-5-x86_64-RoR-AT-11152008.tar.gz /vz/private/3000/ </pre><br />
*Done<br />
<br />
===Step 4: Deployment/Distribution===<br />
To do rapid deployment of your new AT, you can utilize for/while loops to create multiple VE's as shown [[Demo scripts | here]].<br />
<br />
As for distribution, please share any of the AT's you create [http://download.openvz.org/template/precreated/contrib/ here]</div>Adeelhttps://wiki.openvz.org/index.php?title=Application_Templates&diff=6689Application Templates2008-11-16T02:50:22Z<p>Adeel: adding basic content</p>
<hr />
<div>===Abstract===<br />
Application Templates (AT's) are commonly found when using Virtualization as a means to try out new software without having to perform a full manual install. Unfortunately, OpenVZ, as of yet, doesn't have any precreated AT's for people to try out, which might be attributed to the lack of documentation on how to create them. The primary goal of this howto is to give an overview of how an AT can be created for OpenVZ without too much trouble.<br />
<br />
===Introduction===<br />
There are two ways to create an AT: as a full VE template, or an interactive shell script/installer that installs the software into an existing VE. The second method is more advanced, and will be very specific to the individual applications, so is out of the scope of this document.<br />
<br />
===Step 1: The Base===<br />
Choose the base OS you'd like to use and find an existing VE template to use (or create your [{{fullurl:Category:Templates}} own]). For this document, I'm using the [http://download.openvz.org/template/precreated/contrib/centos-5-x86_64-default-5.2-20081107.tar.gz CentOS 5 x86_64] template</div>Adeelhttps://wiki.openvz.org/index.php?title=RequestedTutorials&diff=6688RequestedTutorials2008-11-16T00:40:35Z<p>Adeel: </p>
<hr />
<div><b>Please make a list of the tutorials you'd like to have written up or done in a quick screen capture movie.</b><br />
<br />
*There are no explicit instructions here about creating an Application Template for VPS's. Is this even possible with OpenVZ? A tutorial would be great.<br />
<br />
<br />
<br />
<br />
[[Category:HOWTO]]</div>Adeelhttps://wiki.openvz.org/index.php?title=RequestedTutorials&diff=6381RequestedTutorials2008-08-27T19:23:37Z<p>Adeel: New page: Please make a list of the tutorials you'd like to have written up or done in a quick screen capture movie. Category:HOWTO</p>
<hr />
<div>Please make a list of the tutorials you'd like to have written up or done in a quick screen capture movie.<br />
<br />
[[Category:HOWTO]]</div>Adeelhttps://wiki.openvz.org/index.php?title=X_inside_VE&diff=4139X inside VE2008-02-21T14:52:10Z<p>Adeel: /* Client Configuration */</p>
<hr />
<div>There are several ways to run X applications inside your [[VE]].<br />
<br />
== X forwarding ==<br />
<br />
=== Single application ===<br />
<br />
To run an X application inside a [[VE]], one need simply to connect to a VE with '''ssh -X''':<br />
<pre><br />
host# ssh -2 -c blowfish -X user@address<br />
</pre><br />
<br />
After login to VE check that <code>$DISPLAY</code> variable is set and X11 forwarding is enabled:<br />
<pre><br />
ve# echo $DISPLAY<br />
localhost:10.0<br />
</pre><br />
<br />
In case <code>$DISPLAY</code> is not set, make sure that X forwarding is enabled in <code>sshd</code> config inside VE. 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 VE 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:<br />
<pre><br />
ve# /etc/init.d/sshd restart<br />
</pre><br />
<br />
{{Note|Don't forget to reconnect after this}}<br />
<br />
Now you can run X applications from your VE:<br />
<pre><br />
ve# firefox<br />
</pre><br />
<br />
=== Desktop ===<br />
<br />
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. ;)<br />
<br />
You can run a desktop with ''xinit'' (on the node):<br />
<br />
<pre><br />
xinit -e ssh -XCc blowfish user@ip_address "/usr/bin/xfce4-session &" -- :1 & disown<br />
</pre><br />
<br />
* Substitute the window manager of choice<br />
* Once xfce has started, you can then close the xterm if you like<br />
<br />
<br />
Your node will be on Ctrl-Alt-F7<br />
<br />
And your VM on Ctrl-Alt-F8<br />
<br />
== VNC for X desktop ==<br />
First, one need to run '''Xvnc''' server inside VE. The easiest way for this is to run<br />
'''vncserver''' script. This scripts starts all the required services<br />
and small http daemon which provides graphical web access to your desktop (via Java applet).<br />
<br />
<pre><br />
ve# vncserver -name mydesktop<br />
New 'mydekstop' desktop is ve:1<br />
<br />
Starting applications specified in ~/.vnc/xstartup<br />
Log file is ~/.vnc/ve:1.log<br />
</pre><br />
<br />
Now when your desktop is up and running you can connect to it<br />
using '''vncviewer''' command:<br />
<pre><br />
host# vncviewer <VE_IP>:1<br />
</pre><br />
<br />
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:<br />
<pre>vncserver -geometry 1000x650</pre><br />
This setting works quite well for a 1024 by 768 X desktop setting.<br />
<br />
=== Starting KDE desktop with VNC ===<br />
To start KDE desktop instead of default twm one replace <code>twm &</code> line with <code>startkde &</code> in user's<br />
<code>~/.vnc/xstartup</code> file on the VE.<br />
<br />
=== Connecting with VNC from firewalled network ===<br />
VNC uses 590x TCP ports for its connections. These ports can be firewalled in<br />
many networks so in order to be able to connect to remote side one need to tunnel VNC connections somehow.<br />
A usual '''ssh''' can be used for tunneling VNC connections as described below.<br />
<br />
<pre><br />
localhost# ssh -L 5900:localhost:5900 <remote host><br />
</pre><br />
<br />
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.<br />
<br />
<pre><br />
localhost# vncviewer localhost<br />
</pre><br />
<br />
== Using Xephyr ==<br />
<br />
Xephyr gives you nested X windows.<br />
<br />
First, install Xephyr on your host.<br />
<br />
Start Xephyr<br />
<br />
<pre>Xephyr -ac -screen 1280x1024 -br -reset -terminate :1 &</pre><br />
<br />
Change your display settings (don't forget to change them back after you establish a connection)<br />
<br />
<pre>DISPLAY=:1,0</pre><br />
<br />
Forward your application or desktop over ssh to Xephyr<br />
<br />
<pre>ssh -XfC -c blowfish user@server xfce4-session</pre><br />
<br />
If you use an alternate window manager, substitute "startkde", "gnome-session", "startfluxbox", etc. as needed. <br />
<br />
[http://cafelinux.org/OptickleArt/albums/userpics/Xephyr.png Screenshot]<br />
<br />
== Using XDM with XDMCP ==<br />
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<br />
<br />
=== VE Configuration ===<br />
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).<br />
<br />
===== XDM =====<br />
Configuring XDM requires editing 3 files: /etc/X11/xdm/xdm-config, /etc/X11/xdm/Xservers, /etc/X11/xdm/Xaccess<br />
<br />
In xdm-config, comment out the line where it says '''DisplayManager.requestPort: 0'''<br />
<br />
In Xservers, comment out the line ''':0 local /usr/bin/X :0 vt7'''' (this starts a local X server, which will fail)<br />
<br />
In Xaccess, uncomment the line with ''' * #any host can get a login window'''<br />
(Please keep in mind the security implications by the above line. Read the comments found in the file and set it appropriately)<br />
<br />
To provide the possibility to run sound applications from VE, /dev/dsp device file needs to be exported in VE:<br />
<pre><br />
vzctl set 221 --devnodes dsp:rw --save<br />
</pre><br />
<br />
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 VE:<br />
<pre><br />
vzctl set 221 --privvmpages 500M:600M --save<br />
</pre><br />
For light desktop like icewm this is not needed.<br />
<br />
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 VE.<br />
<br />
===== GDM =====<br />
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. Also, change from VCAllocation=true to VTAllocation=false and comment out the FirstVT=7 line. Change the access restrictions (if any) to suit your needs and then start GDM.<br />
<br />
=== Client/Host Configuration ===<br />
<br />
On the Client/Host (whatever machine you are connecting from to the VE), 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 VE.<br />
<br />
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)<br />
<br />
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.<br />
<br />
=== Errata ===<br />
On a side note, as of December 2007, I was never able to successfully get an Xserver to run inside a VE 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).<br />
<br />
== External links ==<br />
* http://forum.openvz.org/index.php?t=tree&th=235&mid=1115&&rev=&reveal=<br />
* http://ait.web.psi.ch/services/linux/kde-desktop-sharing.htm<br />
* http://ait.web.psi.ch/services/ssh/vnc-ssh.html<br />
* http://www.vnc.com/pipermail/vnc-list/2002-July/031831.html<br />
* http://www.linuxjournal.com/article/5499<br />
* http://www.realvnc.com/pipermail/vnc-list/2002-March/029502.html<br />
* http://www.redhat.com/archives/rhl-list/2003-December/msg01859.html<br />
* http://faq.gotomyvnc.com/fom-serve/cache/56.html<br />
<br />
[[Category: HOWTO]]<br />
[[Category: Networking]]</div>Adeelhttps://wiki.openvz.org/index.php?title=X_inside_VE&diff=4138X inside VE2008-02-21T14:47:05Z<p>Adeel: /* Hostnode Configuration */</p>
<hr />
<div>There are several ways to run X applications inside your [[VE]].<br />
<br />
== X forwarding ==<br />
<br />
=== Single application ===<br />
<br />
To run an X application inside a [[VE]], one need simply to connect to a VE with '''ssh -X''':<br />
<pre><br />
host# ssh -2 -c blowfish -X user@address<br />
</pre><br />
<br />
After login to VE check that <code>$DISPLAY</code> variable is set and X11 forwarding is enabled:<br />
<pre><br />
ve# echo $DISPLAY<br />
localhost:10.0<br />
</pre><br />
<br />
In case <code>$DISPLAY</code> is not set, make sure that X forwarding is enabled in <code>sshd</code> config inside VE. 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 VE 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:<br />
<pre><br />
ve# /etc/init.d/sshd restart<br />
</pre><br />
<br />
{{Note|Don't forget to reconnect after this}}<br />
<br />
Now you can run X applications from your VE:<br />
<pre><br />
ve# firefox<br />
</pre><br />
<br />
=== Desktop ===<br />
<br />
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. ;)<br />
<br />
You can run a desktop with ''xinit'' (on the node):<br />
<br />
<pre><br />
xinit -e ssh -XCc blowfish user@ip_address "/usr/bin/xfce4-session &" -- :1 & disown<br />
</pre><br />
<br />
* Substitute the window manager of choice<br />
* Once xfce has started, you can then close the xterm if you like<br />
<br />
<br />
Your node will be on Ctrl-Alt-F7<br />
<br />
And your VM on Ctrl-Alt-F8<br />
<br />
== VNC for X desktop ==<br />
First, one need to run '''Xvnc''' server inside VE. The easiest way for this is to run<br />
'''vncserver''' script. This scripts starts all the required services<br />
and small http daemon which provides graphical web access to your desktop (via Java applet).<br />
<br />
<pre><br />
ve# vncserver -name mydesktop<br />
New 'mydekstop' desktop is ve:1<br />
<br />
Starting applications specified in ~/.vnc/xstartup<br />
Log file is ~/.vnc/ve:1.log<br />
</pre><br />
<br />
Now when your desktop is up and running you can connect to it<br />
using '''vncviewer''' command:<br />
<pre><br />
host# vncviewer <VE_IP>:1<br />
</pre><br />
<br />
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:<br />
<pre>vncserver -geometry 1000x650</pre><br />
This setting works quite well for a 1024 by 768 X desktop setting.<br />
<br />
=== Starting KDE desktop with VNC ===<br />
To start KDE desktop instead of default twm one replace <code>twm &</code> line with <code>startkde &</code> in user's<br />
<code>~/.vnc/xstartup</code> file on the VE.<br />
<br />
=== Connecting with VNC from firewalled network ===<br />
VNC uses 590x TCP ports for its connections. These ports can be firewalled in<br />
many networks so in order to be able to connect to remote side one need to tunnel VNC connections somehow.<br />
A usual '''ssh''' can be used for tunneling VNC connections as described below.<br />
<br />
<pre><br />
localhost# ssh -L 5900:localhost:5900 <remote host><br />
</pre><br />
<br />
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.<br />
<br />
<pre><br />
localhost# vncviewer localhost<br />
</pre><br />
<br />
== Using Xephyr ==<br />
<br />
Xephyr gives you nested X windows.<br />
<br />
First, install Xephyr on your host.<br />
<br />
Start Xephyr<br />
<br />
<pre>Xephyr -ac -screen 1280x1024 -br -reset -terminate :1 &</pre><br />
<br />
Change your display settings (don't forget to change them back after you establish a connection)<br />
<br />
<pre>DISPLAY=:1,0</pre><br />
<br />
Forward your application or desktop over ssh to Xephyr<br />
<br />
<pre>ssh -XfC -c blowfish user@server xfce4-session</pre><br />
<br />
If you use an alternate window manager, substitute "startkde", "gnome-session", "startfluxbox", etc. as needed. <br />
<br />
[http://cafelinux.org/OptickleArt/albums/userpics/Xephyr.png Screenshot]<br />
<br />
== Using XDM with XDMCP ==<br />
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<br />
<br />
=== VE Configuration ===<br />
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).<br />
<br />
===== XDM =====<br />
Configuring XDM requires editing 3 files: /etc/X11/xdm/xdm-config, /etc/X11/xdm/Xservers, /etc/X11/xdm/Xaccess<br />
<br />
In xdm-config, comment out the line where it says '''DisplayManager.requestPort: 0'''<br />
<br />
In Xservers, comment out the line ''':0 local /usr/bin/X :0 vt7'''' (this starts a local X server, which will fail)<br />
<br />
In Xaccess, uncomment the line with ''' * #any host can get a login window'''<br />
(Please keep in mind the security implications by the above line. Read the comments found in the file and set it appropriately)<br />
<br />
To provide the possibility to run sound applications from VE, /dev/dsp device file needs to be exported in VE:<br />
<pre><br />
vzctl set 221 --devnodes dsp:rw --save<br />
</pre><br />
<br />
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 VE:<br />
<pre><br />
vzctl set 221 --privvmpages 500M:600M --save<br />
</pre><br />
For light desktop like icewm this is not needed.<br />
<br />
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 VE.<br />
<br />
===== GDM =====<br />
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. Also, change from VCAllocation=true to VTAllocation=false and comment out the FirstVT=7 line. Change the access restrictions (if any) to suit your needs and then start GDM.<br />
<br />
=== Client Configuration ===<br />
<br />
On the Client, 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 (and not recommended as it'll unnecessarily just chew up resources on the client) not to mention, they won't be used (since you're connecting to the desktop on the VE).<br />
<br />
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)<br />
<br />
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.<br />
<br />
=== Errata ===<br />
On a side note, as of December 2007, I was never able to successfully get an Xserver to run inside a VE 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).<br />
<br />
== External links ==<br />
* http://forum.openvz.org/index.php?t=tree&th=235&mid=1115&&rev=&reveal=<br />
* http://ait.web.psi.ch/services/linux/kde-desktop-sharing.htm<br />
* http://ait.web.psi.ch/services/ssh/vnc-ssh.html<br />
* http://www.vnc.com/pipermail/vnc-list/2002-July/031831.html<br />
* http://www.linuxjournal.com/article/5499<br />
* http://www.realvnc.com/pipermail/vnc-list/2002-March/029502.html<br />
* http://www.redhat.com/archives/rhl-list/2003-December/msg01859.html<br />
* http://faq.gotomyvnc.com/fom-serve/cache/56.html<br />
<br />
[[Category: HOWTO]]<br />
[[Category: Networking]]</div>Adeelhttps://wiki.openvz.org/index.php?title=Using_NAT_for_container_with_private_IPs&diff=4092Using NAT for container with private IPs2008-01-29T23:32:23Z<p>Adeel: /* How to provide access from Internet to a VE */</p>
<hr />
<div>Usually you supply public IP addresses to your VEs. Sometimes you don't want to do it (lack of IPs, etc.). This article describes how to use private IP addresses for VEs.<br />
<br />
== Prerequisites ==<br />
<br />
=== IP forwarding ===<br />
IP forwarding should be turned on on hardware node in order for VE networking to work. Make sure it is turned on:<br />
<br />
$ cat /proc/sys/net/ipv4/ip_forward <br />
1<br />
<br />
Output should be '1'. If it is '0', enable IP forwarding as it is described in [[Quick installation#sysctl]].<br />
<br />
NOTE: '''Ubuntu''' made some changes to the syntax for NAT. See this link if you are needing to enable NAT on an Ubuntu host :<br />
<br />
[https://bugs.launchpad.net/ubuntu/+source/procps/+bug/84537 Launchpad]<br />
<br />
The syntax of /etc/sysctl.conf has changed to :<br />
<br />
<pre>net.ipv4.conf.default.forwarding=1<br />
net.ipv4.conf.all.forwarding=1</pre><br />
<br />
=== IP conntracks ===<br />
IP connection tracking should be enabled for VE0.<br />
<br />
'''For OpenVZ kernels 2.6.8''', put the following line into /etc/modprobe.conf:<br />
<br />
modprobe ip_conntrack ip_conntrack_enable_ve0=1<br />
<br />
and reboot.<br />
<br />
'''For OpenVZ kernels later than 2.6.8''', connection tracking for VE0 is enabled by default. '''However''', make sure there is '''no''' line like<br />
<br />
options ip_conntrack ip_conntrack_disable_ve0=1<br />
<br />
in /etc/modules.conf or /etc/modprobe.conf. If there is such line, comment it out (or remove) and reboot.<br />
<br />
== How to provide access for VE to Internet ==<br />
<br />
To enable the [[VE]]s, which have only internal IP addresses, to access the Internet, SNAT (Source Network Address Translation, also known as IP masquerading) should be configured on the [[Hardware Node]]. This is ensured by the standard Linux <tt>iptables</tt> utility. To perform a simple SNAT setup, execute the following command on the [[Hardware Node]]:<br />
<pre><br />
# iptables -t nat -A POSTROUTING -s src_net -o eth0 -j SNAT --to ip_address<br />
</pre><br />
<br />
where <tt>src_net</tt> is a range of IP addresses of VEs to be translated by SNAT, and <tt>ip_address</tt> is the external IP address of your [[Hardware Node]]. Multiple rules are allowed, for example, in case you wish to specify several ranges of IP addresses. If you are using a number of physical network interfaces on the [[Hardware Node|Node]], you may need to specify a different interface for outgoing connections, e.g. <tt>-o eth2</tt>.<br />
<br />
To make all IP addresses to be translated by SNAT (not only the ones of [[VE]]s with private addresses), you should type the following string:<br />
<pre><br />
# iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to ip_address<br />
</pre><br />
<br />
{{Note|If the above is not working then check if one of the following solutions does the trick.}}<br />
1. If you are using stable (currently 2.6.8-based) kernel, then to enable SNAT for the VEs on your local network you need to explicitly enable connection tracking in [[VE0]]. Make sure that the following string is present in the <tt>/etc/modprobe.conf</tt> file:<br />
<pre><br />
options ip_conntrack ip_conntrack_enable_ve0=1<br />
</pre><br />
<br />
{{Note|in kernels later than 2.6.8, connection tracking is enabled by default}}<br />
<br />
In case it is not, add this string to the file by means of any text editor (for example, vi). This setting is not needed for kernels more recent than 2.6.8, since connection tracking for [[VE0]] is enabled by default in those kernels.<br />
<br />
2. For unknown reasons the above didn't work on a Debian host. The solution is to do it in an init.d script as follows:<br />
<pre><br />
modprobe ip_conntrack ip_conntrack_enable_ve0=1<br />
</pre><br />
Make sure that this module is loaded before any of the other iptables-modules are loaded! Also remember that if this module is loaded without the option, unloading and reloading doesn't work! You need to reboot the computer.<br />
<br />
{{Note|in kernels later than 2.6.8, connection tracking is enabled by default}}<br />
<br />
== How to provide access from Internet to a VE ==<br />
<br />
In addition, to make some services in VE with private IP address be accessible from the Internet, DNAT (Destination Network Address Translation) should be configured on the [[Hardware Node]]. To perform a simple DNAT setup, execute the following command on the [[Hardware Node]]:<br />
<pre><br />
# iptables -t nat -A PREROUTING -p tcp -d ip_address --dport port_num \<br />
-i eth0 -j DNAT --to-destination ve_address:dst_port_num <br />
</pre><br />
<br />
where <tt>ve_address</tt> is an IP address of the VE, <tt>dst_port_num</tt> is a tcp port which requires service use, <tt>ip_address</tt> is the external (public) IP address of your [[Hardware Node]], and <tt>port_num</tt> is a tcp port of [[Hardware Node]], which will be used for Internet connections to private VE service. Note that this setup makes the service which is using <tt>port_num</tt> on the [[Hardware Node]] be unaccessible from the Internet. Also note that SNAT translation is required too.<br />
<br />
For example, if you need a web server in a VE to be accessible from outside and, at the same time, keep a web server on the [[Hardware Node]] be accessible, use the following config:<br />
<pre><br />
# iptables -t nat -A PREROUTING -p tcp -d ip_address --dport 8080 \<br />
-i eth0 -j DNAT --to-destination ve_address:80<br />
# iptables -t nat -A POSTROUTING -s ve_address -o eth0 -j SNAT --to ip_address<br />
</pre><br />
<br />
After applying this, you'll see VE' web server at <code><nowiki>http://ip_address:8080/</nowiki></code>.<br />
<br />
{{Note|this rule will only work for external clients, i.e. connections originating from a different host — so you can not test if it works locally.}}<br />
<br />
{{Note|If you get any errors relating to: <br />
<code>iptables: No chain/target/match by that name</code><br />
double check to see if you have all the iptables/netfilter modules loaded properly. I had to <code> modprobe xt_tcpudp </code> before getting it to work.}}<br />
<br />
<br />
The <tt>iptables</tt> utility allows to set up more complex rules for Network Address Translation, involving various protocols and ports. If you wish to get more information on this, consult the numerous Internet sites (e.g. [http://www.netfilter.org netfilter.org]) and tutorials devoted to this issue.<br />
<br />
== External Links ==<br />
* [http://www.netfilter.org netfilter.org]<br />
* [[w:Private network]]<br />
<br />
[[Category: HOWTO]]<br />
[[Category: Networking]]</div>Adeelhttps://wiki.openvz.org/index.php?title=X_inside_VE&diff=3732X inside VE2007-12-09T15:14:52Z<p>Adeel: /* Using xdm */</p>
<hr />
<div>There are several ways to run X applications inside your [[VE]].<br />
<br />
== X forwarding ==<br />
<br />
=== Single application ===<br />
<br />
To run an X application inside a [[VE]], one need simply to connect to a VE with '''ssh -X''':<br />
<pre><br />
host# ssh -2 -c blowfish -X user@address<br />
</pre><br />
<br />
After login to VE check that <code>$DISPLAY</code> variable is set and X11 forwarding is enabled:<br />
<pre><br />
ve# echo $DISPLAY<br />
localhost:10.0<br />
</pre><br />
<br />
In case <code>$DISPLAY</code> is not set, make sure that X forwarding is enabled in <code>sshd</code> config inside VE. 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 VE 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:<br />
<pre><br />
ve# /etc/init.d/sshd restart<br />
</pre><br />
<br />
{{Note|Don't forget to reconnect after this}}<br />
<br />
Now you can run X applications from your VE:<br />
<pre><br />
ve# firefox<br />
</pre><br />
<br />
=== Desktop ===<br />
<br />
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. ;)<br />
<br />
You can run a desktop with ''xinit'' (on the node):<br />
<br />
<pre><br />
xinit -e ssh -XCc blowfish user@ip_address "/usr/bin/xfce4-session &" -- :1 & disown<br />
</pre><br />
<br />
* Substitute the window manager of choice<br />
* Once xfce has started, you can then close the xterm if you like<br />
<br />
<br />
Your node will be on Ctrl-Alt-F7<br />
<br />
And your VM on Ctrl-Alt-F8<br />
<br />
== VNC for X desktop ==<br />
First, one need to run '''Xvnc''' server inside VE. The easiest way for this is to run<br />
'''vncserver''' script. This scripts starts all the required services<br />
and small http daemon which provides graphical web access to your desktop (via Java applet).<br />
<br />
<pre><br />
ve# vncserver -name mydesktop<br />
New 'mydekstop' desktop is ve:1<br />
<br />
Starting applications specified in ~/.vnc/xstartup<br />
Log file is ~/.vnc/ve:1.log<br />
</pre><br />
<br />
Now when your desktop is up and running you can connect to it<br />
using '''vncviewer''' command:<br />
<pre><br />
host# vncviewer <VE_IP>:1<br />
</pre><br />
<br />
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:<br />
<pre>vncserver -geometry 1000x650</pre><br />
This setting works quite well for a 1024 by 768 X desktop setting.<br />
<br />
=== Starting KDE desktop with VNC ===<br />
To start KDE desktop instead of default twm one replace <code>twm &</code> line with <code>startkde &</code> in user's<br />
<code>~/.vnc/xstartup</code> file on the VE.<br />
<br />
=== Connecting with VNC from firewalled network ===<br />
VNC uses 590x TCP ports for its connections. These ports can be firewalled in<br />
many networks so in order to be able to connect to remote side one need to tunnel VNC connections somehow.<br />
A usual '''ssh''' can be used for tunneling VNC connections as described below.<br />
<br />
<pre><br />
localhost# ssh -L 5900:localhost:5900 <remote host><br />
</pre><br />
<br />
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.<br />
<br />
<pre><br />
localhost# vncviewer localhost<br />
</pre><br />
<br />
== Using Xephyr ==<br />
<br />
Xephyr gives you nested X windows.<br />
<br />
First, install Xephyr on your host.<br />
<br />
Start Xephyr<br />
<br />
<pre>Xephyr -ac -screen 1280x1024 -br -reset -terminate :1 &</pre><br />
<br />
Change your display settings (don't forget to change them back after you establish a connection)<br />
<br />
<pre>DISPLAY=:1,0</pre><br />
<br />
Forward your application or desktop over ssh to Xephyr<br />
<br />
<pre>ssh -XfC -c blowfish user@server xfce4-session</pre><br />
<br />
If you use an alternate window manager, substitute "startkde", "gnome-session", "startfluxbox", etc. as needed. <br />
<br />
[http://cafelinux.org/OptickleArt/albums/userpics/Xephyr.png Screenshot]<br />
<br />
== Using XDM with XDMCP ==<br />
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<br />
<br />
=== VE Configuration ===<br />
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).<br />
<br />
===== XDM =====<br />
Configuring XDM requires editing 3 files: /etc/X11/xdm/xdm-config, /etc/X11/xdm/Xservers, /etc/X11/xdm/Xaccess<br />
<br />
In xdm-config, comment out the line where it says '''DisplayManager.requestPort: 0'''<br />
<br />
In Xservers, comment out the line ''':0 local /usr/bin/X :0 vt7'''' (this starts a local X server, which will fail)<br />
<br />
In Xaccess, uncomment the line with ''' * #any host can get a login window'''<br />
(Please keep in mind the security implications by the above line. Read the comments found in the file and set it appropriately)<br />
<br />
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 VE.<br />
<br />
===== GDM =====<br />
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. Also, change from VCAllocation=true to VTAllocation=false and comment out the FirstVT=7 line. Change the access restrictions (if any) to suit your needs and then start GDM.<br />
<br />
=== Hostnode Configuration ===<br />
On the HN, 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 are entirely optional (and not recommended as it'll unnecessarily just chew up resources) on the HN.<br />
<br />
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)<br />
<br />
There are guides online on howto tunnel the XDMCP settings over ssh giving you security, in an otherwise INSECURE protocol.<br />
<br />
=== Errata ===<br />
On a side note, as of December 2007, I was never able to successfully get an Xserver to run inside a VE 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).<br />
<br />
== External links ==<br />
* http://forum.openvz.org/index.php?t=tree&th=235&mid=1115&&rev=&reveal=<br />
* http://ait.web.psi.ch/services/linux/kde-desktop-sharing.htm<br />
* http://ait.web.psi.ch/services/ssh/vnc-ssh.html<br />
* http://www.vnc.com/pipermail/vnc-list/2002-July/031831.html<br />
* http://www.linuxjournal.com/article/5499<br />
* http://www.realvnc.com/pipermail/vnc-list/2002-March/029502.html<br />
* http://www.redhat.com/archives/rhl-list/2003-December/msg01859.html<br />
* http://faq.gotomyvnc.com/fom-serve/cache/56.html<br />
<br />
[[Category: HOWTO]]<br />
[[Category: Networking]]</div>Adeelhttps://wiki.openvz.org/index.php?title=X_inside_VE&diff=3731X inside VE2007-12-09T15:09:20Z<p>Adeel: /* Using xdm */</p>
<hr />
<div>There are several ways to run X applications inside your [[VE]].<br />
<br />
== X forwarding ==<br />
<br />
=== Single application ===<br />
<br />
To run an X application inside a [[VE]], one need simply to connect to a VE with '''ssh -X''':<br />
<pre><br />
host# ssh -2 -c blowfish -X user@address<br />
</pre><br />
<br />
After login to VE check that <code>$DISPLAY</code> variable is set and X11 forwarding is enabled:<br />
<pre><br />
ve# echo $DISPLAY<br />
localhost:10.0<br />
</pre><br />
<br />
In case <code>$DISPLAY</code> is not set, make sure that X forwarding is enabled in <code>sshd</code> config inside VE. 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 VE 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:<br />
<pre><br />
ve# /etc/init.d/sshd restart<br />
</pre><br />
<br />
{{Note|Don't forget to reconnect after this}}<br />
<br />
Now you can run X applications from your VE:<br />
<pre><br />
ve# firefox<br />
</pre><br />
<br />
=== Desktop ===<br />
<br />
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. ;)<br />
<br />
You can run a desktop with ''xinit'' (on the node):<br />
<br />
<pre><br />
xinit -e ssh -XCc blowfish user@ip_address "/usr/bin/xfce4-session &" -- :1 & disown<br />
</pre><br />
<br />
* Substitute the window manager of choice<br />
* Once xfce has started, you can then close the xterm if you like<br />
<br />
<br />
Your node will be on Ctrl-Alt-F7<br />
<br />
And your VM on Ctrl-Alt-F8<br />
<br />
== VNC for X desktop ==<br />
First, one need to run '''Xvnc''' server inside VE. The easiest way for this is to run<br />
'''vncserver''' script. This scripts starts all the required services<br />
and small http daemon which provides graphical web access to your desktop (via Java applet).<br />
<br />
<pre><br />
ve# vncserver -name mydesktop<br />
New 'mydekstop' desktop is ve:1<br />
<br />
Starting applications specified in ~/.vnc/xstartup<br />
Log file is ~/.vnc/ve:1.log<br />
</pre><br />
<br />
Now when your desktop is up and running you can connect to it<br />
using '''vncviewer''' command:<br />
<pre><br />
host# vncviewer <VE_IP>:1<br />
</pre><br />
<br />
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:<br />
<pre>vncserver -geometry 1000x650</pre><br />
This setting works quite well for a 1024 by 768 X desktop setting.<br />
<br />
=== Starting KDE desktop with VNC ===<br />
To start KDE desktop instead of default twm one replace <code>twm &</code> line with <code>startkde &</code> in user's<br />
<code>~/.vnc/xstartup</code> file on the VE.<br />
<br />
=== Connecting with VNC from firewalled network ===<br />
VNC uses 590x TCP ports for its connections. These ports can be firewalled in<br />
many networks so in order to be able to connect to remote side one need to tunnel VNC connections somehow.<br />
A usual '''ssh''' can be used for tunneling VNC connections as described below.<br />
<br />
<pre><br />
localhost# ssh -L 5900:localhost:5900 <remote host><br />
</pre><br />
<br />
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.<br />
<br />
<pre><br />
localhost# vncviewer localhost<br />
</pre><br />
<br />
== Using Xephyr ==<br />
<br />
Xephyr gives you nested X windows.<br />
<br />
First, install Xephyr on your host.<br />
<br />
Start Xephyr<br />
<br />
<pre>Xephyr -ac -screen 1280x1024 -br -reset -terminate :1 &</pre><br />
<br />
Change your display settings (don't forget to change them back after you establish a connection)<br />
<br />
<pre>DISPLAY=:1,0</pre><br />
<br />
Forward your application or desktop over ssh to Xephyr<br />
<br />
<pre>ssh -XfC -c blowfish user@server xfce4-session</pre><br />
<br />
If you use an alternate window manager, substitute "startkde", "gnome-session", "startfluxbox", etc. as needed. <br />
<br />
[http://cafelinux.org/OptickleArt/albums/userpics/Xephyr.png Screenshot]<br />
<br />
== Using xdm ==<br />
First off, as of December 2007, I was never able to successfully get an Xserver to run inside a VE and have it's 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).<br />
<br />
=== VE Configuration ===<br />
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).<br />
<br />
===== XDM =====<br />
Configuring XDM requires editing 3 files: /etc/X11/xdm/xdm-config, /etc/X11/xdm/Xservers, /etc/X11/xdm/Xaccess<br />
<br />
In xdm-config, comment out the line where it says '''DisplayManager.requestPort: 0'''<br />
<br />
In Xservers, comment out the line ''':0 local /usr/bin/X :0 vt7'''' (this starts a local X server, which will fail)<br />
<br />
In Xaccess, uncomment the line with ''' * #any host can get a login window'''<br />
(Please keep in mind the security implications by the above line. Read the comments found in the file and set it appropriately)<br />
<br />
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 VE.<br />
<br />
===== GDM =====<br />
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. Also, change from VCAllocation=true to VTAllocation=false and comment out the FirstVT=7 line. Change the access restrictions (if any) to suit your needs and then start GDM.<br />
<br />
=== Hostnode Configuration ===<br />
On the HN, 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 are entirely optional (and not recommended as it'll unnecessarily just chew up resources) on the HN.<br />
<br />
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)<br />
<br />
There are guides online on howto tunnel the XDMCP settings over ssh giving you security, in an otherwise INSECURE protocol. This approach has some major benefits over the VNC method described above, but also has a couple of major drawbacks. The biggest pro being XDMCP is faster than VNC (due to the way each deals with screen handling) and the biggest con being that you CANNOT connect to existing sessions like you can with VNC. Each time you logout, your programs are closed.<br />
<br />
== External links ==<br />
* http://forum.openvz.org/index.php?t=tree&th=235&mid=1115&&rev=&reveal=<br />
* http://ait.web.psi.ch/services/linux/kde-desktop-sharing.htm<br />
* http://ait.web.psi.ch/services/ssh/vnc-ssh.html<br />
* http://www.vnc.com/pipermail/vnc-list/2002-July/031831.html<br />
* http://www.linuxjournal.com/article/5499<br />
* http://www.realvnc.com/pipermail/vnc-list/2002-March/029502.html<br />
* http://www.redhat.com/archives/rhl-list/2003-December/msg01859.html<br />
* http://faq.gotomyvnc.com/fom-serve/cache/56.html<br />
<br />
[[Category: HOWTO]]<br />
[[Category: Networking]]</div>Adeel