We currently migrate to MediaWiki from our old installation, but not all content has been migrated yet. Take a look at the Wiki Team page for instructions how to help or browse through our new wiki at wiki.linux-vserver.org to find the information already migrated.

Some programs do things that might work on a normal host but not inside a V-Server. This is often not a fault of V-Server itself, the programs are doing automagic things which fail and no proper error handling is done. Also sometimes the actions need special rights which are not permitted by default in V-Servers. Allowing CAPs is often not necessary since those special CAPs are only required once (e.g. when the program initializes the directories/settings/whatever).

If your V-Server doesn't have access to localhost, then the connection to the OpenGroupware server will fail with a "Internal Server Error".
The apache module for OpenGroupware called mod_ngobjweb uses a hardcoded "127.0.0.1" IP address in the source (handler.c line 339), this line you need to change to the IP address that should be used (the IP of the V-Server that runs the OpenGroupware? server)
If you want to run hylafax in a V-Server, you will get a CAP and device problem which can be easily solved. First you need your capi20 devices in your V-Server, which can't be created by ./MAKEDEV (requires special CAPs) so copy the devices into the V-Server, like this (command run on the host):
cp -aR /dev/capi* /vservers/your_vserver/dev
Now hylafax can access your CAPI ISDN card but will exit after a few seconds, the problem is it tries to create a /dev/null nod in the hylafax chroot. This fails because of missing CAPs, so lets help hylafax again with copying the nod into the hylafax chroot in the V-Server. Like this (command run on the host):
cp -aR /dev/null /vservers/your_vserver/var/spool/hylafax/dev
Allright, now hylafax should have CAPI access and run properly.
Don't know why, but links crashes systematically being inside a screen session inside a V-Server started outside a V-Server. (please elaborate!)

[root@ge root]# vserver zoe enter

ipv4root is now 192.168.24.3

New security context is 49178

zoe:/# screen

Cannot open your terminal '/dev/pts/5' - please check.

zoe:/# strace screen 2> /tmp/err.txt

Cannot open your terminal '/dev/pts/5' - please check.

zoe:/# grep /dev/pts/5 /tmp/err.txt

readlink("/proc/self/fd/0", "/dev/pts/5", 511) = 10

readlink("/proc/self/fd/0", "/dev/pts/5", 4095) = 10

stat64("/dev/pts/5", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 5), ...}) = 0

open("/dev/pts/5", O_RDWR|O_NONBLOCK) = -1 EACCES (Permission denied)

zoe:/# ls -l /dev/pts/5

crww-- 1 root root 136, 5 2005-04-08 22:10 /dev/pts/5

zoe:/#

[root@ge root]# uname -a

Linux ge.kalou.net 2.4.29-vs1.2.10 #12 mar mar 29 20:15:48 CEST 2005 i686 athlon i386 GNU/Linux

slapd needs name resolution available in order to start up, otherwise it appears to hang. Make sure you have working DNS (or whatever) available to your vserver before starting one with slapd. This behavior is confirmed in my setup, no confirmation from others yet. My Setup: vservers all bind to an interface on a DMZ-like network segment, BIND runs on a vserver. slapd would hang at startup if the BIND vserver had not been started first.
Bind's rndc has a hardcoded 127.0.0.1 somewhere so any command to rndc will fail with connection refused.
You should have a reachable localhost address defined in /etc/hosts and then you can use rndc -s localhost command
Since some version of Asterisk (at least since 1.0.2), it will not run anymore. On start it fails with: "Unable to set high priority"
This can be solved by allowing CAP_SYS_NICE for that V-Server
Fails because of writing to /proc (requires patch)
TODO: write me
Oplocks don't work as smbd insists on receiving break requests from 127.0.0.1
Just patch source/smbd/oplock.c (commenting paranoid code) 
+++ oplock.c.orig       2005-02-14 14:27:51.000000000 +0200
--- oplock.c    2005-02-02 12:27:50.000000000 +0200
@@ -181,14 +181,12 @@
                return False;
        }

+#if 0
     /* Validate message from address (must be localhost). */
        if(from.sin_addr.s_addr != htonl(INADDR_LOOPBACK)) {
                DEBUG(0,("receive_local_message: invalid 'from' address \
 (was %lx should be 127.0.0.1)\n", (long)from.sin_addr.s_addr));
                return False;
        }
+#endif

        /* Setup the message header */
        SIVAL(buffer,OPBRK_CMD_LEN_OFFSET,msg_len);
Symptoms: The Cups init script exits with: 
Starting CUPS printing system: cupsd: Child exited with status 98!

And the logs (/var/log/cups/error_log) show: 
E [date:hour...] StartListening: Unable to bind socket for address 0.0.0.0:631 - Address already in use.
...Or something like this.

With a correct "cupsd.conf file" (Tested version 1.1.21-0.rc1.7mdk, on Mandrake 10.1), it works; All we need is to remove references to 127.0.0.1 or localhost from the file, as well as correctly setting the Listen directive: 
LogLevel info
TempDir /var/spool/cups/tmp
Listen vserver_hostname   # IMPORTANT ! : Do _not_ specify a port or IP here (No "vserver_hostname:631" or "172.16.0.10" !)
Port 631
BrowseAddress @LOCAL
BrowseDeny All
BrowseAllow @LOCAL
BrowseOrder deny,allow
<Location />
  Order Deny,Allow
  Deny From All
  Allow From @LOCAL
</Location>
<Location /admin>
  AuthType Basic
  AuthClass System
  Order Deny,Allow
  Deny From All
  Allow From YOUR_NETWORK_ADDRESS/YOUR_NETMASK # Example: 172.16.0.0/24
</Location>

Then you'll need to modify the /etc/init.d/cups script, to comment any section referring to 127.0.0.1 lookup and configuration. This section exists at least on Mandrake 10.1, and is pretty long (Lines 35 to 55 and/or 79), and additionnaly four "else...if" lines must be commented far below (Lines 161 to 164) !

Remember to stop any Cupsd running in the host server, or to start it via a wrapper /etc/init.d/v_cups script: 
#!/bin/sh
# chkconfig: 2345 15 60
# description: Wrapper to start cups bound to a single IP
USR_LIB_VSERVER=/usr/lib/util-vserver
exec $USR_LIB_VSERVER/vsysvwrapper cups $*

Then use /etc/init.d/v_cups (re)start to launch Cups on the host server.
You will now be able to make Cupsd start in the vserver , but more tweaking on the ACLs may be necessary to avoid authentification problems... I'll update this section when I fully have this working.
named provided by the bind9 binary packages fails to start because it is compiled with CAPs option.

Recompiling it helps, however you'll need the start/stop scripts etc as well. You may get them by temporarily installing the binary packages provided by the distribution, copying the neccessary files, and removing it.

To compile bind9 without CAPs, do: 
su -
cd /usr/src
apt-get source bind9
cd bind9-x.x.x
./configure --disable-linux-caps --enable-threads --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
make
make install

The Xs in "cd bind9-x.x.x" denote the version number of bind9. These instructions have only been tested on Sarge, but should work on Woody and Sid, too. If you are on a different distribution, you may need to change the 'sysconfdir' option. If unsure, try omitting it.