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).
- OpenGroupware Apache Module
- 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.
- Links inside screen inside a V-Server
- Don't know why, but links crashes systematically being inside a screen session inside a V-Server started outside a V-Server. (please elaborate!)
- 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.
- Bind9 on Debian GNU/Linux Woody (3.0) and Sarge (3.1)
Binary packages fail because they are 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.