''Problems getting this to work in an x86_64 vserver. Any hints? From what I can tell from stracing, turning off threads doesn't fix everything related to it. It also caused a juicy Ksymoops.''

''Problems getting this to work in an x86_64 vserver. Any hints? From what I can tell from stracing, turning off threads doesn't fix everything related to it. It also caused a juicy Ksymoops.''

+

+

''- Apparently this does work when running bind as user root. I Installed a bare Debian Etch vserver without granting any special capabilities on my x86_64 system, apt-get install bind9, kill any started named-processes and edit /etc/default/bind, changing the user (-u) from bind to root. Bind starts and resolving seems to work. Mind you, the usual warnings and rants about running stuff as root still applies! - 2007-08-06 MGS''

=== Zimbra Mail ===

=== Zimbra Mail ===

Revision as of 21:46, 6 August 2007

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)

Hylafax (with CAPI)

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):

is neither a bug nor an issue with screen, it just shows that a vserver context is not allowed to mess with host terminals. either use ssh/telnet to reach the 'guest' or start the screen session before you do the 'enter' (i.e. on the host)

OpenLDAP Startup

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.

rndc

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. You can make a rndc.conf and set the default-server option, like that the '-s localhost' isn't necessary.

or if you don't want to patch the samba source code you can disable oplock in Samba and it will work too!

Just put the following in your smb.conf:

kernel oplocks = no
oplocks = no

Note: The Vserver using Samba should also listen on the broadcast address. Thereby you will not be able to have two samba servers in the same net (on the same broadcast).

Samba from Debian 3.1

The samba deb in sarge (3.1) provided file sharing. The only oddity observed is that the vserver guest running samba did not appear in a windows box's 'My Network Places'

Use a WINS server. The SMB browsing protocol relies heavily on broadcasts on the local net, which are problematic with vservers. WINS resolution on the other hand is unicast and works flawlessly under vserver.

Samba printer and file server with cups

Samba runs correctly in a Mandriva (Mdk) 10.1 Vserver, (Apart from the above oplock problem ?).First, edit your /etc/sysconfig/network file, and set networking to yes (This will solve problems for other services !):

But if you're using Samba + Cups to provide printing for Windows clients, AND if you want to use the Point and Print feature, there is more: In the [printers] section of your smb.conf, you should have the use client drivers directive set to no, or the driver upload procedure will fail !

With a correct "cupsd.conf file" (Tested version 1.1.21-0.rc1.7mdk, on Mandrake 10.1 - Now Mandriva), it works; All we need is to remove references to 127.0.0.1 or localhost from the file, as well as correctly unsetting the Listen directive:

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:

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

Bind9 on Debian GNU/Linux Woody (3.0), Sarge (3.1), Etch (4.0)

named provided by the bind9 binary packages fails to start because it is compiled with CAPs option.

The last line is to set the package "on hold", so it is not touched by the update process. you have to take care of security holes by yourself now!

The Xs in "bind9-x.x.x" denote the version number of bind9. Alternatively you can allow the CAP_SYS_RESOURCE for that V-Server. The best way would be to fix bind, which is somehow broken when it comes to capabilities. Daniel Hokka Zakrisson repaired it. His patch is to be found here:

So, if you recompile, it would be the cleanest way to apply that patch. Thanks Daniel! It would be also nice, if someone submits that patch to the bind people or maybe to your distribution's package maintainers in the first step.

Problems getting this to work in an x86_64 vserver. Any hints? From what I can tell from stracing, turning off threads doesn't fix everything related to it. It also caused a juicy Ksymoops.

- Apparently this does work when running bind as user root. I Installed a bare Debian Etch vserver without granting any special capabilities on my x86_64 system, apt-get install bind9, kill any started named-processes and edit /etc/default/bind, changing the user (-u) from bind to root. Bind starts and resolving seems to work. Mind you, the usual warnings and rants about running stuff as root still applies! - 2007-08-06 MGS

Zimbra Mail

Zimbra is many applications (including Postfix and MySQL? and OpenLDAP? and more) which try to take over the interfaces, and depend a lot on binding from 127.0.0.1 - it is not hard to change, but there is a couple of tricks - it is documented here - http://wiki.zimbra.com/index.php?title=Install_VServer

xine

won't start with no error message.

"xine --verbose" shows this.

ERROR: Could not determine network interfaces, you must use a interfaces config line

This happens if you have the xineplug_inp_smb.so plugin. Delete it and everything is fine.

127.0.0.1 issues

I had problems with an application that wanted me to access it on 127.0.0.1 and AS 127.0.0.1 to be able to do its configuration. A simple tweak solved the problem. I renamed the default interface directory "0" in /etc/vservers/server/interfaces to "1" and created interface 0 as :

dev lo
ip 127.0.0.1
mask 255.0.0.0
name lo

now interface "1" is the default created interface by the vserver build script with a local adress like 192.168.1.2 and interface "0" is the loopback. I can now telnet on 127.0.0.1 and it sees that im connecting to 127.0.0.1 from 127.0.0.1

Compiling nagios-1.4 within a vserver requires this, otherwise it hangs during the configure with "checking for ICMP ping syntax..."