Problematic Programs

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

Contents 1 OpenGroupware Apache Module 2 Hylafax (with CAPI) 3 Links inside screen inside a V-Server 4 screen inside a VServer 5 OpenLDAP Startup 6 rndc 7 Asterisk 8 Open/FreeSwan 9 Samba 9.1 Samba from Debian 3.1 9.2 Samba printer and file server with cups

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

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

screen inside a VServer

[root@ge root]# vserver zoe enter

zoe:/# screen
Cannot open your terminal '/dev/pts/5' - please check.

zoe:/# strace screen 
...
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)

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.

Asterisk

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. You can also not run Asterisk with the realtime priority - Just pass the '-p' command ligne argument to disable the read-time priority. Good doc on setting up Asterisk devices in the vserver: http://www.telephreak.org/papers/vpa/

Open/FreeSwan

Fails because of writing to /proc (requires patch) TODO: write me

Samba

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

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

# cat /etc/sysconfig/network
NETWORKING=yes

Some more tweaking is needeed in /etc/smb.conf

# cat /etc/smb.conf
...
  # YOUR VSERVER IP/MASK HERE
  interfaces = xxx.xxx.xxx.xxx/mask
...

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 !

# cat /etc/smb.conf
...
  use client driver = no
...

So, here is a full smb.conf file:

# cat /etc/samba/smb.conf | awk '!/^$/ && !/^\s*(#|;)/ {print $0}'
[global]
   workgroup = MYDOMAIN
   netbios name = MYHOSTNAME
   server string = MYCOMMENT (Samba %v)
   printcap name = cups
   load printers = yes
   printing = cups
   printer admin = @adm
   log file = /var/log/samba/log.%m
   max log size = 50
   map to guest = bad user
   security = domain
   password server = *
   encrypt passwords = yes
   smb passwd file = /etc/samba/smbpasswd
   username map = /etc/samba/smbusers
   idmap uid = 10000-20000
   idmap gid = 10000-20000
   socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
   interfaces = 127. MYVSERVERIP/MYVSERVERMASK
   wins server = MYWINSIP
   dns proxy = no
   # for french users:
   dos charset = 850
   unix charset = ISO8859-1
[homes]
   comment = Home Directories
   browseable = no
   writable = no
[printers]
   comment = All Printers
   path = /var/spool/samba
   browseable = no
   guest ok = no
   writable = no
   printable = yes
   create mode = 0700
   print command = lpr-cups -P %p -o raw %s -r   # using client side printer drivers.
   use client driver = no
[print$]
   path = /var/lib/samba/printers
   browseable = yes
   write list = @adm root
   guest ok = yes
   inherit permissions = yes

...And a working smbusers:

# Unix_name = SMB_name1 SMB_name2 ...
root = administrator MYDOMAIN\administrator
nobody = guest pcguest smbguest