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.
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