http://linux-vserver.org/api.php?action=feedcontributions&user=188.94.20.43&feedformat=atomLinux-VServer - User contributions [en]2024-03-28T18:11:35ZUser contributionsMediaWiki 1.20.2http://linux-vserver.org/Resource_LimitsResource Limits2013-04-16T14:06:33Z<p>188.94.20.43: /* Determining the Page Size */</p>
<hr />
<div>'''NOTE: This page describes Linux <tt>rlimit</tt> support (an SVr4/BSD4.3/POSIX.1-2001 standard). vServers can also be managed using the Linux Control Group (<tt>cgroup</tt>) system, for information on Control Group based resource management, see [[util-vserver:Cgroups|util-vserver - Cgroups]].'''<br />
<br />
Most properties related to system resources, might it be the memory consumption, the number of processes or file-handles, qualify for imposing limits on them.<br />
<br />
The Linux kernel provides the getrlimit and setrlimit system calls to get and set resource limits ''per process''. Each resource has an associated soft and hard limit. The soft limit is the value that the kernel enforces for the corresponding resource. The hard limit acts as a ceiling for the soft limit: an unprivileged process may only set its soft limit to a value in the range from 0 up to the hard limit, and (irreversibly) lower its hard limit. A privileged process (one with the CAP_SYS_RESOURCE capability) may make arbitrary changes to either limit value.<br />
<br />
The Linux-VServer kernel extends this system to provide resource limits for ''whole contexts'', not just single processes. Additionally a few new limit types missing in the vanilla kernel were introduced.<br />
<br />
Additionally the context limit system keeps track of observed maxima and resource limit hits, to provide some feedback for the administrator. See [[Context Accounting]] for details.<br />
<br />
__FORCETOC__<br />
<br />
== List of Resource Limits ==<br />
<br />
Below is a list of resource limits used for contexts and processes within. The tables contain the following information:<br />
<br />
; ID : Resource limit ID<br />
; Name : Human readable identifier used in userspace utilities<br />
; procfs : Name used in /proc/virtual/*/limit<br />
; ulimit : command line switch for the ulimit utility<br />
; Unit : Aprropriate unit for the limit<br />
; Tag : Special resource limit code to denote if resources are accounted, enforced (see below)<br />
; Description : Description of capability/flag effects<br />
<br />
=== Special Resource Limit Codes ===<br />
<br />
The tag column may contain one or more of the following tags:<br />
<br />
{| class="wikitable_inline"<br />
! Tag<br />
! Description<br />
|-<br />
| A<br />
| Limit will be accounted<br />
|-<br />
| E<br />
| Limit will be enforced<br />
|}<br />
<br />
=== Linux Resource Limits ===<br />
<br />
Below is a list of resource limits available in vanilla Linux (>=2.6.18).<br />
<br />
{| class="wikitable_list"<br />
! ID<br />
! Name<br />
! procfs<br />
! ulimit<br />
! Tag<br />
! Unit<br />
! Description<br />
|-<br />
| 0<br />
| CPU<br />
| --<br />
| -t<br />
|<br />
| ms<br />
| CPU time in ms<br />
|-<br />
| 1<br />
| FSIZE<br />
| --<br />
| -f<br />
|<br />
| KiB<br />
| Maximum file size<br />
|-<br />
| 2<br />
| DATA<br />
| --<br />
| -d<br />
|<br />
| KiB<br />
| Maximum size of the data segment<br />
|-<br />
| 3<br />
| STACK<br />
| --<br />
| -s<br />
|<br />
| KiB<br />
| Maximum stack size<br />
|-<br />
| 4<br />
| CORE<br />
| --<br />
| -c<br />
|<br />
| KiB<br />
| Maximum core file size<br />
|-<br />
| 5<br />
| RSS<br />
| RSS<br />
| -m<br />
| AE<br />
| page<br />
| Maximum resident set size<br />
|-<br />
| 6<br />
| NPROC<br />
| PROC<br />
| -u<br />
| AE<br />
| 1<br />
| Maximum number of processes<br />
|-<br />
| 7<br />
| NOFILE<br />
| FILES<br />
| -n<br />
| AE<br />
| 1<br />
| Maximum number of open files<br />
|-<br />
| 8<br />
| MEMLOCK<br />
| VML<br />
| -l<br />
| AE<br />
| page<br />
| Maximum locked-in-memory address space<br />
|-<br />
| 9<br />
| AS<br />
| VM<br />
| -v<br />
| AE<br />
| page<br />
| Maximum address space size<br />
|-<br />
| 10<br />
| LOCKS<br />
| LOCKS<br />
| -x<br />
| AE<br />
| 1<br />
| Maximum file locks held<br />
|-<br />
| 11<br />
| SIGPENDING<br />
| --<br />
| -i<br />
|<br />
| 1<br />
| Maximum number of pending signals<br />
|-<br />
| 12<br />
| MSGQUEUE<br />
| MSGQ<br />
| -q<br />
| AE<br />
| Byte<br />
| Maximum bytes in POSIX mqueues<br />
|-<br />
| 13<br />
| NICE<br />
| --<br />
|<br />
|<br />
| 1<br />
| Maximum nice prio allowed to raise to<br />
|-<br />
| 14<br />
| RTPRIO<br />
| --<br />
| -r<br />
|<br />
| 1<br />
| Maximum realtime priority<br />
|}<br />
<br />
=== Linux-VServer Resource Limits ===<br />
<br />
Below is a list of additional resource limits available in the Linux-VServer kernel.<br />
<br />
{| class="wikitable_list"<br />
! ID<br />
! Name<br />
! procfs<br />
! Tag<br />
! Unit<br />
! Description<br />
|-<br />
| 16<br />
| NSOCK<br />
| SOCK<br />
| AE<br />
| 1<br />
| Maximum number of open sockets<br />
|-<br />
| 17<br />
| OPENFD<br />
| OFD<br />
| AE<br />
| 1<br />
| Maximum number of open file descriptors<br />
|-<br />
| 18<br />
| ANON<br />
| ANON<br />
| A<br />
| page<br />
| Maximum anonymous memory size<br />
|-<br />
| 19<br />
| SHMEM<br />
| SHM<br />
| AE<br />
| page<br />
| Maximum shared memory size<br />
|-<br />
| 20<br />
| SEMARY<br />
| SEMA<br />
| A<br />
| 1<br />
| Maximum number of semaphore arrays<br />
|-<br />
| 21<br />
| NSEMS<br />
| SEMS<br />
| A<br />
| 1<br />
| Maximum number of semaphores<br />
|-<br />
| 22<br />
| DENTRY<br />
| DENT<br />
| AE<br />
| 1<br />
| Maximum number of dentry structs<br />
|}<br />
<br />
== Determining the Page Size ==<br />
<br />
You can use the following program to determine the page size for your architecture (if it supports the getpagesize() function)<br />
<br />
<pre><br />
#include <stdlib.h><br />
#include <stdint.h><br />
#include <unistd.h><br />
<br />
int main(int argc, char *argv[])<br />
{<br />
int page_size = getpagesize();<br />
printf("The page size is %d\n", page_size);<br />
exit(0);<br />
}<br />
</pre><br />
<br />
Here's how to compile and run it (assuming you save it as pagesize.c):<br />
<br />
<pre><br />
# gcc pagesize.c -o pagesize<br />
# ./pagesize <br />
The page size is 4096<br />
</pre><br />
<br />
'''Note''': Whether getpagesize() is present as a Linux system call depends on the architecture. If it is, it returns the kernel symbol PAGE_SIZE, which is architecture and machine model dependent. Generally, one uses binaries that are architecture but not machine model dependent, in order to have a single binary distribution per architecture. This means that a user program should not find PAGE_SIZE at compile time from a header file, but use an actual system call, at least for those architectures (like sun4) where this dependency exists. Here libc4, libc5, glibc 2.0 fail because their getpagesize() returns a statically derived value, and does not use a system call. Things are OK in glibc 2.1.<br />
<br />
If you prefer, you can get the pagesize using python, just start a python console and write:<br />
<br />
<pre><br />
>>> import resource<br />
>>> resource.getpagesize()<br />
4096<br />
</pre><br />
<br />
Most Linux operating systems also just support a simple native command<br />
<br />
<pre><br />
getconf PAGESIZE<br />
</pre><br />
<br />
Here are some typical page sizes ...<br />
<br />
{| class="wikitable_list"<br />
! arch<br />
! pagesize<br />
|-<br />
| arm, extensa, s390, sh64, x86, x86_64, v850<br />
| 4k<br />
|-<br />
| alpha, cris<br />
| 8k<br />
|-<br />
| m68k, sparc<br />
| 4k, 8k<br />
|- <br />
| powerpc<br />
| 4k, 64k<br />
|- <br />
| parisc<br />
| 4k, 16k, 64k<br />
|-<br />
| ia64, mips<br />
| 4k, 8k, 16k, 64k<br />
|}<br />
<br />
== Configure Resource Limits in util-vserver ==<br />
<br />
For example, if the adress space size (AS) and the resident set size (RSS) should be limited, the appropriate config files should be the following. You might have to create parent directories first.<br />
<br />
<pre><br />
# ls -al /etc/vservers/myguest/rlimits<br />
total 28<br />
drwxr-xr-x 2 root root 4096 2005-08-24 12:37 .<br />
drwxr-xr-x 5 root root 4096 2005-08-24 00:22 ..<br />
-rw-r--r-- 1 root root 6 2005-08-24 12:43 as<br />
-rw-r--r-- 1 root root 6 2005-08-24 12:37 rss<br />
<br />
# cat /etc/vservers/myguest/rlimits/as<br />
90000<br />
<br />
# cat /etc/vservers/myguest/rlimits/rss<br />
10000<br />
</pre><br />
<br />
[[Category:Documentation]]</div>188.94.20.43http://linux-vserver.org/Vservers_and_XVservers and X2012-05-05T12:29:01Z<p>188.94.20.43: /* Running X on the HOST from inside a Debian Vserver */</p>
<hr />
<div>This page has been made to answer the questions related to running X ( XFree86 and XOrg ) in a Vserver.<br />
<br />
There are a few things you might want to do relating to X:<br />
<br />
# Run an X server on the physical machine that the Vserver is running on, and log in on the keyboard, mouse, and monitor that are connected to the hardware the host and vserver run on. <br />
# Connect from an Xserver on a different machine, and log into a desktop that is running on the Vserver. <br />
# Run an X server on the host and connect to the vserver (I haven't tried this, but I can't imagine that there would be any problems - this should be pretty much the same as option 2. However, you would need to make sure that running the X server on the host didn't create any security concerns - -nolisten tcp should be used for example.) <br />
# Simply forward X via SSH <br />
<br />
== Running an X server inside a vserver ==<br />
*Allow capability CAP_SYS_RAWIO. It can be set in the capabilities file or the vserver config depending on your util-vserver. (echo SYS_RAWIO >> bcapabilities)<br />
*Set up a mouse device, such as /dev/psaux or /dev/input/mice (mknod psaux c 10 1)<br />
*Set up a vc/tty device, such as /dev/tty7 or /dev/vc/7 (major 4, minor same as device). If you are running a main X server you might need to use 8 or 9 for the vc/tty device (mknod tty7 c 4 7)<br />
*Set up /dev/kmem (not 100% sure this is needed, don't think X has to have it to run) (note: Xorg on debian sid require a /dev/mem -- NebuchadnezzaR?) (mknod -m 660 mem c 1 1)<br />
*Now just switch to a console, log in as root, enter your vserver and startx, a caveat on newer versions of vserver when switching between a vserver X server and the main server's X server you need to switch :to a console first or you can lose access to the main server's X server.<br />
*You'll also need pts/pty devices to run things like xterm, but if you have ssh set up you probably already have them.<br />
<br />
Note: All the stuff below is written from memory - I don't have access to the machine I did this on right now, so I'll have to come back later, and fill in the blanks.<br />
<br />
<br />
== Running X on the HOST from inside a Debian Vserver ==<br />
<br />
This is not meant as a secure implementation - but is a working guide, with the minimum of operations.<br />
<br />
*On the HOST, install Xorg - your guest cannot run an environment without the modules/drivers being loaded on the host<br />
<br />
<source lang=bash><br />
apt-get install xorg<br />
</source><br />
<br />
*Copy the necessary devices to the Vserver guest<br />
<br />
<source lang=bash><br />
VSERVER=gui2<br />
VSERVER_CONF=/etc/vservers/$VSERVER<br />
VSERVER_BASE=/var/lib/vservers/$VSERVER<br />
cp -prax /dev/psaux /dev/input /dev/fb0 /dev/tty7 $VSERVER_BASE/dev<br />
</source><br />
<br />
*Add capabilities to the guest (to control some of the HOST functionalities)<br />
<br />
<source lang=bash><br />
echo SYS_RAWIO >> $VSERVER_CONF/$VSERVER/bcapabilities<br />
</source><br />
<br />
*Start and enter the guest<br />
<br />
<source lang=bash><br />
vserver $VSERVER start<br />
vserver $VSERVER enter<br />
</source><br />
<br />
*If it is a clean Vserver, then the first package a Debian guest needs is 'locales'. On Squeeze, there is also a bug with the 'keyboard-setup' package, so we install that first<br />
<br />
<source lang=bash><br />
apt-get install locales keyboard-setup<br />
</source><br />
<br />
*On Squeeze, the installation will fail and you'll need to edit `/etc/init.d/keyboard-setup`. Remove the 'mountkernfs' and 'udev' directives from the opening 6 lines of the file<br />
<br />
*To install LXDE,<br />
<br />
<source lang=bash><br />
aptitude install lxde-core kdm x-window-system xorg xserver-xorg xserver-xorg-input-mouse xserver-xorg-input-kbd<br />
apt-get remove xserver-xorg-video-vmware hal<br />
apt-get -f install<br />
apt-get autoremove<br />
</source><br />
<br />
'''OR'''<br />
<br />
*To install KDE (an error with occur with network-manager, this is normal, follow the instructions below exactly)<br />
<br />
<source lang=bash><br />
aptitude install x-window-system xorg xserver-xorg kde-core kdm xserver-xorg-input-mouse xserver-xorg-input-kbd<br />
apt-get remove network-manager xserver-xorg-video-vmware hal<br />
apt-get -f install<br />
apt-get autoremove<br />
</source><br />
<br />
*Then finally, to get the mouse working in the guest, you need to create an 'xorg.conf'. Either use the following command, or if that doesn't work run 'Xorg -configure' on the host, then extract the sections used below (do NOT include screen/display sections).<br />
<br />
<br />
<source lang=bash><br />
cat > /etc/X11/xorg.conf <<EOF<br />
Section "ServerLayout"<br />
Identifier "X.org Configured"<br />
InputDevice "Mouse0" "CorePointer"<br />
InputDevice "Keyboard0" "CoreKeyboard"<br />
EndSection<br />
<br />
Section "InputDevice"<br />
Identifier "Keyboard0"<br />
Driver "kbd"<br />
EndSection<br />
<br />
Section "InputDevice"<br />
Identifier "Mouse0"<br />
Driver "mouse"<br />
Option "Protocol" "auto"<br />
Option "Device" "/dev/input/mice"<br />
Option "ZAxisMapping" "4 5 6 7"<br />
EndSection<br />
<br />
Section "ServerFlags"<br />
Option "AllowEmptyInput" "no"<br />
EndSection<br />
EOF<br />
</source><br />
<br />
*Now, exit your guest, and restart it. It should come back on and be running X on the HOST server.<br />
<br />
== Running an X session on a vserver ==<br />
For this, you don't need to assign any special capabilities to the vserver, as the vserver won't be running an X server. It will run an Xsession back to your local X server. <br />
===In the Vserver:===<br />
* Install the xdm package - this is the process that listens on udp/177 for XMDCP requests. You can also use kdm, the package that comes with KDE, or gdm, for Gnome.<br />
* Install your desktop of choice. I used KDE.<br />
* Comment out the local X server in /etc/X11*/?dm/Xservers - if you don't do this, X will try to start and will fail - you will get IOPerm errors in /var/log/Xorg.1.log, and it may stop your display manager from starting. (TODO: check this path)<br />
* Set ListenXDMCP? to true in /etc/kde/.../kdmrc (TODO: check this path)<br />
* Add the line: LISTEN 82.x.y.z to your DM config file (/etc/kde/kdm/kdm-config ? <- TODO: Check this).<br />
<br />
Make sure that the you can run [xkg]dm in the vserver. [xkd]dm logs to /var/log, and you can run it with higher debug levels from the command line to work out any problems. Most distros will have an init script to run this from startup.<br />
<br />
netstat -plnu | grep :177 should show your ?dm running on udp/177.<br />
<br />
=== Problems I encountered: ===<br />
*If your ?dm starts, and exits without any errors, this may mean that your greeter program isn't working or installed.<br />
*My konsole program didn't start properly - this was due to /dev/ptmx not being writable by my user - chmod 666 /dev/ptmx as root solved this.<br />
<br />
Test it by running X -query w.x.y.z :2 on a remote machine (not the vserver). You should get a grey screen, followed by the login manager for KDE/Gnome/X.<br />
<br />
== SSH Forwarding X ==<br />
Using ssh X forwarding to get the gui of the apps you want.<br />
* first make sure your guest has an ip and a hostname.<br />
* install open-ssh server onto the guest.<br />
* edit the file /etc/ssh/sshd_config to include X11UseLocalhost no<br />
* restart the ssh server and make sure that you can logon<br />
* ssh into the guest with 'ssh -X'<br />
* if you can't ssh into the vserver check that your own ssh server is not interfering. if so bind it to your ip.<br />
* check the DISPLAY env. var, it should show you soemthing like myhost.mydomain.com:10.0 <br />
* make sure that myhost.mydomain.com resolves to the guest IP <br />
* either configure it via DNS or just add it to /etc/hosts like this: <br />
192.168.0.1 myhost.mydomain.com <br />
* verify with ping myhost.mydomain.com that the resolving works <br />
* start whatever X app you ahve installed (e.g. xeyes, xlogo, xterm ...)<br />
<br />
[[Category:Software under linux-vserver]]</div>188.94.20.43http://linux-vserver.org/Vservers_and_XVservers and X2012-05-05T11:27:01Z<p>188.94.20.43: /* Running an X server inside a vserver */</p>
<hr />
<div>This page has been made to answer the questions related to running X ( XFree86 and XOrg ) in a Vserver.<br />
<br />
There are a few things you might want to do relating to X:<br />
<br />
# Run an X server on the physical machine that the Vserver is running on, and log in on the keyboard, mouse, and monitor that are connected to the hardware the host and vserver run on. <br />
# Connect from an Xserver on a different machine, and log into a desktop that is running on the Vserver. <br />
# Run an X server on the host and connect to the vserver (I haven't tried this, but I can't imagine that there would be any problems - this should be pretty much the same as option 2. However, you would need to make sure that running the X server on the host didn't create any security concerns - -nolisten tcp should be used for example.) <br />
# Simply forward X via SSH <br />
<br />
== Running an X server inside a vserver ==<br />
*Allow capability CAP_SYS_RAWIO. It can be set in the capabilities file or the vserver config depending on your util-vserver. (echo SYS_RAWIO >> bcapabilities)<br />
*Set up a mouse device, such as /dev/psaux or /dev/input/mice (mknod psaux c 10 1)<br />
*Set up a vc/tty device, such as /dev/tty7 or /dev/vc/7 (major 4, minor same as device). If you are running a main X server you might need to use 8 or 9 for the vc/tty device (mknod tty7 c 4 7)<br />
*Set up /dev/kmem (not 100% sure this is needed, don't think X has to have it to run) (note: Xorg on debian sid require a /dev/mem -- NebuchadnezzaR?) (mknod -m 660 mem c 1 1)<br />
*Now just switch to a console, log in as root, enter your vserver and startx, a caveat on newer versions of vserver when switching between a vserver X server and the main server's X server you need to switch :to a console first or you can lose access to the main server's X server.<br />
*You'll also need pts/pty devices to run things like xterm, but if you have ssh set up you probably already have them.<br />
<br />
Note: All the stuff below is written from memory - I don't have access to the machine I did this on right now, so I'll have to come back later, and fill in the blanks.<br />
<br />
<br />
== Running X on the HOST from inside a Debian Vserver ==<br />
<br />
This is not meant as a secure implementation - but is a working guide, with the minimum of operations.<br />
<br />
*On the HOST, install Xorg - your guest cannot run an environment without the modules/drivers being loaded on the host<br />
<br />
<source lang=bash><br />
apt-get install xorg<br />
</source><br />
<br />
*Copy the necessary devices to the Vserver guest<br />
<br />
<source lang=bash><br />
VSERVER=gui2<br />
VSERVER_CONF=/etc/vservers/$VSERVER<br />
VSERVER_BASE=/var/lib/vservers/$VSERVER<br />
cp -prax /dev/psaux /dev/input /dev/fb0 /dev/tty7 /dev/tty8 /dev/tty9 $VSERVER_BASE/dev<br />
</source><br />
<br />
*Add capabilities to the guest (to control some of the HOST functionalities)<br />
<br />
<source lang=bash><br />
cat > $VSERVER_CONF/$VSERVER/bcapabilities <<EOF<br />
IPC_LOCK<br />
IPC_OWNER<br />
SYS_RAWIO<br />
SYS_ADMIN<br />
NET_ADMIN<br />
NET_RAW<br />
MKNOD<br />
EOF<br />
</source><br />
<br />
*Start and enter the guest<br />
<br />
<source lang=bash><br />
vserver $VSERVER start<br />
vserver $VSERVER enter<br />
</source><br />
<br />
*If it is a clean Vserver, then the first package a Debian guest needs is 'locales'. On Squeeze, there is also a bug with the 'keyboard-setup' package, so we install that first<br />
<br />
<source lang=bash><br />
apt-get install locales keyboard-setup<br />
</source><br />
<br />
*On Squeeze, the installation will fail and you'll need to edit `/etc/init.d/keyboard-setup`. Remove the 'mountkernfs' and 'udev' directives from the opening 6 lines of the file<br />
<br />
*To install LXDE,<br />
<br />
<source lang=bash><br />
aptitude install lxde-core kdm x-window-system xorg xserver-xorg xserver-xorg-input-mouse xserver-xorg-input-kbd<br />
apt-get remove xserver-xorg-video-vmware<br />
apt-get -f install<br />
apt-get autoremove<br />
</source><br />
<br />
'''OR'''<br />
<br />
*To install KDE (an error with occur with network-manager, this is normal, follow the instructions below exactly)<br />
<br />
<source lang=bash><br />
aptitude install x-window-system xorg xserver-xorg kde-core kdm xserver-xorg-input-mouse xserver-xorg-input-kbd<br />
apt-get remove network-manager xserver-xorg-video-vmware<br />
apt-get -f install<br />
apt-get autoremove<br />
</source><br />
<br />
*Then finally, to get the mouse working in the guest, you need to create an 'xorg.conf'. Either use the following command, or if that doesn't work run 'Xorg -configure' on the host, then extract the sections used below (do NOT include screen/display sections).<br />
<br />
<br />
<source lang=bash><br />
cat > /etc/X11/xorg.conf <<EOF<br />
Section "ServerLayout"<br />
Identifier "X.org Configured"<br />
InputDevice "Mouse0" "CorePointer"<br />
InputDevice "Keyboard0" "CoreKeyboard"<br />
EndSection<br />
<br />
Section "InputDevice"<br />
Identifier "Keyboard0"<br />
Driver "kbd"<br />
EndSection<br />
<br />
Section "InputDevice"<br />
Identifier "Mouse0"<br />
Driver "mouse"<br />
Option "Protocol" "auto"<br />
Option "Device" "/dev/input/mice"<br />
Option "ZAxisMapping" "4 5 6 7"<br />
EndSection<br />
<br />
Section "ServerFlags"<br />
Option "AllowEmptyInput" "no"<br />
EndSection<br />
EOF<br />
</source><br />
<br />
*Now, exit your guest, and restart it. It should come back on and be running X on the HOST server.<br />
<br />
== Running an X session on a vserver ==<br />
For this, you don't need to assign any special capabilities to the vserver, as the vserver won't be running an X server. It will run an Xsession back to your local X server. <br />
===In the Vserver:===<br />
* Install the xdm package - this is the process that listens on udp/177 for XMDCP requests. You can also use kdm, the package that comes with KDE, or gdm, for Gnome.<br />
* Install your desktop of choice. I used KDE.<br />
* Comment out the local X server in /etc/X11*/?dm/Xservers - if you don't do this, X will try to start and will fail - you will get IOPerm errors in /var/log/Xorg.1.log, and it may stop your display manager from starting. (TODO: check this path)<br />
* Set ListenXDMCP? to true in /etc/kde/.../kdmrc (TODO: check this path)<br />
* Add the line: LISTEN 82.x.y.z to your DM config file (/etc/kde/kdm/kdm-config ? <- TODO: Check this).<br />
<br />
Make sure that the you can run [xkg]dm in the vserver. [xkd]dm logs to /var/log, and you can run it with higher debug levels from the command line to work out any problems. Most distros will have an init script to run this from startup.<br />
<br />
netstat -plnu | grep :177 should show your ?dm running on udp/177.<br />
<br />
=== Problems I encountered: ===<br />
*If your ?dm starts, and exits without any errors, this may mean that your greeter program isn't working or installed.<br />
*My konsole program didn't start properly - this was due to /dev/ptmx not being writable by my user - chmod 666 /dev/ptmx as root solved this.<br />
<br />
Test it by running X -query w.x.y.z :2 on a remote machine (not the vserver). You should get a grey screen, followed by the login manager for KDE/Gnome/X.<br />
<br />
== SSH Forwarding X ==<br />
Using ssh X forwarding to get the gui of the apps you want.<br />
* first make sure your guest has an ip and a hostname.<br />
* install open-ssh server onto the guest.<br />
* edit the file /etc/ssh/sshd_config to include X11UseLocalhost no<br />
* restart the ssh server and make sure that you can logon<br />
* ssh into the guest with 'ssh -X'<br />
* if you can't ssh into the vserver check that your own ssh server is not interfering. if so bind it to your ip.<br />
* check the DISPLAY env. var, it should show you soemthing like myhost.mydomain.com:10.0 <br />
* make sure that myhost.mydomain.com resolves to the guest IP <br />
* either configure it via DNS or just add it to /etc/hosts like this: <br />
192.168.0.1 myhost.mydomain.com <br />
* verify with ping myhost.mydomain.com that the resolving works <br />
* start whatever X app you ahve installed (e.g. xeyes, xlogo, xterm ...)<br />
<br />
[[Category:Software under linux-vserver]]</div>188.94.20.43http://linux-vserver.org/Vservers_and_XVservers and X2012-05-04T15:40:20Z<p>188.94.20.43: /* Running an X server inside a vserver */</p>
<hr />
<div>This page has been made to answer the questions related to running X ( XFree86 and XOrg ) in a Vserver.<br />
<br />
There are a few things you might want to do relating to X:<br />
<br />
# Run an X server on the physical machine that the Vserver is running on, and log in on the keyboard, mouse, and monitor that are connected to the hardware the host and vserver run on. <br />
# Connect from an Xserver on a different machine, and log into a desktop that is running on the Vserver. <br />
# Run an X server on the host and connect to the vserver (I haven't tried this, but I can't imagine that there would be any problems - this should be pretty much the same as option 2. However, you would need to make sure that running the X server on the host didn't create any security concerns - -nolisten tcp should be used for example.) <br />
# Simply forward X via SSH <br />
<br />
== Running an X server inside a vserver ==<br />
*Allow capability CAP_SYS_RAWIO. It can be set in the capabilities file or the vserver config depending on your util-vserver. (echo SYS_RAWIO >> bcapabilities)<br />
*Set up a mouse device, such as /dev/psaux or /dev/input/mice (mknod psaux c 10 1)<br />
*Set up a vc/tty device, such as /dev/tty7 or /dev/vc/7 (major 4, minor same as device). If you are running a main X server you might need to use 8 or 9 for the vc/tty device (mknod tty7 c 4 7)<br />
*Set up /dev/kmem (not 100% sure this is needed, don't think X has to have it to run) (note: Xorg on debian sid require a /dev/mem -- NebuchadnezzaR?) (mknod -m 660 mem c 1 1)<br />
*Now just switch to a console, log in as root, enter your vserver and startx, a caveat on newer versions of vserver when switching between a vserver X server and the main server's X server you need to switch :to a console first or you can lose access to the main server's X server.<br />
*You'll also need pts/pty devices to run things like xterm, but if you have ssh set up you probably already have them.<br />
<br />
Note: All the stuff below is written from memory - I don't have access to the machine I did this on right now, so I'll have to come back later, and fill in the blanks.<br />
<br />
== Running an X session on a vserver ==<br />
For this, you don't need to assign any special capabilities to the vserver, as the vserver won't be running an X server. It will run an Xsession back to your local X server. <br />
===In the Vserver:===<br />
* Install the xdm package - this is the process that listens on udp/177 for XMDCP requests. You can also use kdm, the package that comes with KDE, or gdm, for Gnome.<br />
* Install your desktop of choice. I used KDE.<br />
* Comment out the local X server in /etc/X11*/?dm/Xservers - if you don't do this, X will try to start and will fail - you will get IOPerm errors in /var/log/Xorg.1.log, and it may stop your display manager from starting. (TODO: check this path)<br />
* Set ListenXDMCP? to true in /etc/kde/.../kdmrc (TODO: check this path)<br />
* Add the line: LISTEN 82.x.y.z to your DM config file (/etc/kde/kdm/kdm-config ? <- TODO: Check this).<br />
<br />
Make sure that the you can run [xkg]dm in the vserver. [xkd]dm logs to /var/log, and you can run it with higher debug levels from the command line to work out any problems. Most distros will have an init script to run this from startup.<br />
<br />
netstat -plnu | grep :177 should show your ?dm running on udp/177.<br />
<br />
=== Problems I encountered: ===<br />
*If your ?dm starts, and exits without any errors, this may mean that your greeter program isn't working or installed.<br />
*My konsole program didn't start properly - this was due to /dev/ptmx not being writable by my user - chmod 666 /dev/ptmx as root solved this.<br />
<br />
Test it by running X -query w.x.y.z :2 on a remote machine (not the vserver). You should get a grey screen, followed by the login manager for KDE/Gnome/X.<br />
<br />
== SSH Forwarding X ==<br />
Using ssh X forwarding to get the gui of the apps you want.<br />
* first make sure your guest has an ip and a hostname.<br />
* install open-ssh server onto the guest.<br />
* edit the file /etc/ssh/sshd_config to include X11UseLocalhost no<br />
* restart the ssh server and make sure that you can logon<br />
* ssh into the guest with 'ssh -X'<br />
* if you can't ssh into the vserver check that your own ssh server is not interfering. if so bind it to your ip.<br />
* check the DISPLAY env. var, it should show you soemthing like myhost.mydomain.com:10.0 <br />
* make sure that myhost.mydomain.com resolves to the guest IP <br />
* either configure it via DNS or just add it to /etc/hosts like this: <br />
192.168.0.1 myhost.mydomain.com <br />
* verify with ping myhost.mydomain.com that the resolving works <br />
* start whatever X app you ahve installed (e.g. xeyes, xlogo, xterm ...)<br />
<br />
[[Category:Software under linux-vserver]]</div>188.94.20.43http://linux-vserver.org/Vservers_and_XVservers and X2012-05-04T14:31:27Z<p>188.94.20.43: /* Running an X server inside a vserver */</p>
<hr />
<div>This page has been made to answer the questions related to running X ( XFree86 and XOrg ) in a Vserver.<br />
<br />
There are a few things you might want to do relating to X:<br />
<br />
# Run an X server on the physical machine that the Vserver is running on, and log in on the keyboard, mouse, and monitor that are connected to the hardware the host and vserver run on. <br />
# Connect from an Xserver on a different machine, and log into a desktop that is running on the Vserver. <br />
# Run an X server on the host and connect to the vserver (I haven't tried this, but I can't imagine that there would be any problems - this should be pretty much the same as option 2. However, you would need to make sure that running the X server on the host didn't create any security concerns - -nolisten tcp should be used for example.) <br />
# Simply forward X via SSH <br />
<br />
== Running an X server inside a vserver ==<br />
*Allow capability CAP_SYS_RAWIO. It can be set in the capabilities file or the vserver config depending on your util-vserver. (echo SYS_RAWIO >> bcapabilities)<br />
*Set up a mouse device, such as /dev/psaux or /dev/input/mice (mknod psaux c 10 1)<br />
*Set up a vc/tty device, such as /dev/tty7 or /dev/vc/7 (major 4, minor same as device). If you are running a main X server you might need to use 8 or 9 for the vc/tty device (mknod tty7 c 5 0)<br />
*Set up /dev/kmem (not 100% sure this is needed, don't think X has to have it to run) (note: Xorg on debian sid require a /dev/mem -- NebuchadnezzaR?) (mknod -m 660 mem c 1 1)<br />
*Now just switch to a console, log in as root, enter your vserver and startx, a caveat on newer versions of vserver when switching between a vserver X server and the main server's X server you need to switch :to a console first or you can lose access to the main server's X server.<br />
*You'll also need pts/pty devices to run things like xterm, but if you have ssh set up you probably already have them.<br />
<br />
Note: All the stuff below is written from memory - I don't have access to the machine I did this on right now, so I'll have to come back later, and fill in the blanks.<br />
<br />
== Running an X session on a vserver ==<br />
For this, you don't need to assign any special capabilities to the vserver, as the vserver won't be running an X server. It will run an Xsession back to your local X server. <br />
===In the Vserver:===<br />
* Install the xdm package - this is the process that listens on udp/177 for XMDCP requests. You can also use kdm, the package that comes with KDE, or gdm, for Gnome.<br />
* Install your desktop of choice. I used KDE.<br />
* Comment out the local X server in /etc/X11*/?dm/Xservers - if you don't do this, X will try to start and will fail - you will get IOPerm errors in /var/log/Xorg.1.log, and it may stop your display manager from starting. (TODO: check this path)<br />
* Set ListenXDMCP? to true in /etc/kde/.../kdmrc (TODO: check this path)<br />
* Add the line: LISTEN 82.x.y.z to your DM config file (/etc/kde/kdm/kdm-config ? <- TODO: Check this).<br />
<br />
Make sure that the you can run [xkg]dm in the vserver. [xkd]dm logs to /var/log, and you can run it with higher debug levels from the command line to work out any problems. Most distros will have an init script to run this from startup.<br />
<br />
netstat -plnu | grep :177 should show your ?dm running on udp/177.<br />
<br />
=== Problems I encountered: ===<br />
*If your ?dm starts, and exits without any errors, this may mean that your greeter program isn't working or installed.<br />
*My konsole program didn't start properly - this was due to /dev/ptmx not being writable by my user - chmod 666 /dev/ptmx as root solved this.<br />
<br />
Test it by running X -query w.x.y.z :2 on a remote machine (not the vserver). You should get a grey screen, followed by the login manager for KDE/Gnome/X.<br />
<br />
== SSH Forwarding X ==<br />
Using ssh X forwarding to get the gui of the apps you want.<br />
* first make sure your guest has an ip and a hostname.<br />
* install open-ssh server onto the guest.<br />
* edit the file /etc/ssh/sshd_config to include X11UseLocalhost no<br />
* restart the ssh server and make sure that you can logon<br />
* ssh into the guest with 'ssh -X'<br />
* if you can't ssh into the vserver check that your own ssh server is not interfering. if so bind it to your ip.<br />
* check the DISPLAY env. var, it should show you soemthing like myhost.mydomain.com:10.0 <br />
* make sure that myhost.mydomain.com resolves to the guest IP <br />
* either configure it via DNS or just add it to /etc/hosts like this: <br />
192.168.0.1 myhost.mydomain.com <br />
* verify with ping myhost.mydomain.com that the resolving works <br />
* start whatever X app you ahve installed (e.g. xeyes, xlogo, xterm ...)<br />
<br />
[[Category:Software under linux-vserver]]</div>188.94.20.43http://linux-vserver.org/Vservers_and_XVservers and X2012-05-04T14:29:56Z<p>188.94.20.43: /* Running an X server inside a vserver */</p>
<hr />
<div>This page has been made to answer the questions related to running X ( XFree86 and XOrg ) in a Vserver.<br />
<br />
There are a few things you might want to do relating to X:<br />
<br />
# Run an X server on the physical machine that the Vserver is running on, and log in on the keyboard, mouse, and monitor that are connected to the hardware the host and vserver run on. <br />
# Connect from an Xserver on a different machine, and log into a desktop that is running on the Vserver. <br />
# Run an X server on the host and connect to the vserver (I haven't tried this, but I can't imagine that there would be any problems - this should be pretty much the same as option 2. However, you would need to make sure that running the X server on the host didn't create any security concerns - -nolisten tcp should be used for example.) <br />
# Simply forward X via SSH <br />
<br />
== Running an X server inside a vserver ==<br />
*Allow capability CAP_SYS_RAWIO. It can be set in the capabilities file or the vserver config depending on your util-vserver.<br />
*Set up a mouse device, such as /dev/psaux or /dev/input/mice (mknod psaux c 10 1)<br />
*Set up a vc/tty device, such as /dev/tty7 or /dev/vc/7 (major 4, minor same as device). If you are running a main X server you might need to use 8 or 9 for the vc/tty device (mknod tty7 c 5 0)<br />
*Set up /dev/kmem (not 100% sure this is needed, don't think X has to have it to run) (note: Xorg on debian sid require a /dev/mem -- NebuchadnezzaR?) (mknod -m 660 mem c 1 1)<br />
*Now just switch to a console, log in as root, enter your vserver and startx, a caveat on newer versions of vserver when switching between a vserver X server and the main server's X server you need to switch :to a console first or you can lose access to the main server's X server.<br />
*You'll also need pts/pty devices to run things like xterm, but if you have ssh set up you probably already have them.<br />
<br />
Note: All the stuff below is written from memory - I don't have access to the machine I did this on right now, so I'll have to come back later, and fill in the blanks.<br />
<br />
== Running an X session on a vserver ==<br />
For this, you don't need to assign any special capabilities to the vserver, as the vserver won't be running an X server. It will run an Xsession back to your local X server. <br />
===In the Vserver:===<br />
* Install the xdm package - this is the process that listens on udp/177 for XMDCP requests. You can also use kdm, the package that comes with KDE, or gdm, for Gnome.<br />
* Install your desktop of choice. I used KDE.<br />
* Comment out the local X server in /etc/X11*/?dm/Xservers - if you don't do this, X will try to start and will fail - you will get IOPerm errors in /var/log/Xorg.1.log, and it may stop your display manager from starting. (TODO: check this path)<br />
* Set ListenXDMCP? to true in /etc/kde/.../kdmrc (TODO: check this path)<br />
* Add the line: LISTEN 82.x.y.z to your DM config file (/etc/kde/kdm/kdm-config ? <- TODO: Check this).<br />
<br />
Make sure that the you can run [xkg]dm in the vserver. [xkd]dm logs to /var/log, and you can run it with higher debug levels from the command line to work out any problems. Most distros will have an init script to run this from startup.<br />
<br />
netstat -plnu | grep :177 should show your ?dm running on udp/177.<br />
<br />
=== Problems I encountered: ===<br />
*If your ?dm starts, and exits without any errors, this may mean that your greeter program isn't working or installed.<br />
*My konsole program didn't start properly - this was due to /dev/ptmx not being writable by my user - chmod 666 /dev/ptmx as root solved this.<br />
<br />
Test it by running X -query w.x.y.z :2 on a remote machine (not the vserver). You should get a grey screen, followed by the login manager for KDE/Gnome/X.<br />
<br />
== SSH Forwarding X ==<br />
Using ssh X forwarding to get the gui of the apps you want.<br />
* first make sure your guest has an ip and a hostname.<br />
* install open-ssh server onto the guest.<br />
* edit the file /etc/ssh/sshd_config to include X11UseLocalhost no<br />
* restart the ssh server and make sure that you can logon<br />
* ssh into the guest with 'ssh -X'<br />
* if you can't ssh into the vserver check that your own ssh server is not interfering. if so bind it to your ip.<br />
* check the DISPLAY env. var, it should show you soemthing like myhost.mydomain.com:10.0 <br />
* make sure that myhost.mydomain.com resolves to the guest IP <br />
* either configure it via DNS or just add it to /etc/hosts like this: <br />
192.168.0.1 myhost.mydomain.com <br />
* verify with ping myhost.mydomain.com that the resolving works <br />
* start whatever X app you ahve installed (e.g. xeyes, xlogo, xterm ...)<br />
<br />
[[Category:Software under linux-vserver]]</div>188.94.20.43