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

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

+

<hr>

+

Please see the section [http://linux-vserver.org/Problematic_Programs#AMD_64_Etch_Vserver_Guest_WORKING.21.21.21_:o.29_21Oct2008 below] to get rndc working without switches.

+

:-Paul Allen

+

<hr>

=== Asterisk ===

=== Asterisk ===

Line 253:

Line 257:

echo "bind9 hold" | dpkg --set-selections

echo "bind9 hold" | dpkg --set-selections

</pre>

</pre>

+

or you may be better off to set the selections for all the packages that were generated by dpkg-buildpackage:

Before I begin with all the grueling steps, if you want to be lazy, I wrote a Perl script to do all of this for you, and you can get it [http://compampus.com/bind9-vserver-installer.pl here].

+

:*Note:

+

::If you plan to use the script, you need to ensure you have Perl5, as well as have your locale set properly.

+

::(On a brand-new Etch guest, I had to do those before my script would work)

+

:I noticed after much googling that all links I found to any of the pre-compiled Bind9 (in the above bind9-capacheck directories) are DEAD. However, after many times of running into a brick wall, I caught something that isn't mentioned here...

+

Following the above steps to build Bind9 from source acquired with apt-get, if you look closely, on about line 499 or so after you execute the dpkg-buildpackage command, you'll see this:

+

<pre>

+

dpkg-source: building bind9 using existing bind9_9.3.4.orig.tar.gz

+

dpkg-source: building bind9 in bind9_9.3.4-2etch3.diff.gz

+

dpkg-source: building bind9 in bind9_9.3.4-2etch3.dsc

+

</pre>

+

:...which is basically ignoring the debian/rules modifications you just made...

+

So, following you will find the steps I took to make Bind9 AND rndc run flawlessly on my vserver guest. Everything denoted with // in front is a comment:

+

<pre>

+

su -

+

cd /usr/src

+

mkdir bind9-build

+

cd !$

+

apt-get build-dep bind9

+

apt-get source bind9

+

mkdir unused

+

mv bind9_* !$ //note the ones you don't need all have the underscore _

+

cd bind9-x.x.x //whatever your version # is

+

nano debian/rules

+

beneath this line: ./configure --prefix=/usr \

+

-add --disable-linux-caps \

+

-change --enable-threads \ to: --disable-threads \

+

dpkg-buildpackage

+

cd ../

+

dpkg -i *deb //This will install all the debs that were created, but the actual bind9 deb will fail because of dependencies

+

//At this point, you can just run it again, or 'apt-get install -f' might fix it, but I'm unsure on that

+

dpkg -i *deb

+

echo "bind9 hold" | dpkg --set-selections

+

</pre>

+

:Here you will still see it fail to start, and even though it says that, it isn't named that failed, but only rndc.

+

:So actually, you can stop here, but rndc will fail every time, and bind won't restart with the /etc/init.d/bind9 restart call

+

:In fact, everytime you want to reload, you'll need to manually kill the named process ID and then issue:

+

:/etc/init.d/bind9 start

+

:But if you're a perfectionist like me, and you want a completely error-free starting Bind9 with working rndc, keep reading...

:Now, do the same thing for the 'options' section of the rndc-confgen output, except you'll be adding that to the rndc.conf file, along with an include statement for the key file you just made.

+

:NOTE: Delete all lines in rndc.conf first so that it contains only what you paste. (ctrl+k will cut lines... cut all of them before pasting)

+

:After pasting, your ENTIRE rndc.conf file should look thusly:

+

<pre>

+

include "/etc/bind/my-vps-key";

+

+

options {

+

default-key "my-vps-key";

+

default-server 11.22.33.44;

+

default-port 953;

+

};

+

</pre>

+

:Finally, you need to do the same process, but with the 'controls' section of the rndc-confgen output, and that goes in /etc/named.conf. Again, you will need to add the include statement for the key you created.

+

:Also, while you're editing named.conf, you might as well go ahead and edit the IP addresses. The only one that really seems to matter is the 'localhost' zone

:;Be sure to remove the comment tags (#) from the beginning of the lines!!!

+

<pre>

+

<snip>

+

// If you are just adding zones, please do that in /etc/bind/named.conf.local

+

+

include "/etc/bind/named.conf.options";

+

include "/etc/bind/my-vps-key";

+

+

controls {

+

inet 11.22.33.44 port 953

+

allow { 11.22.33.44; } keys { "my-vps-key"; };

+

};

+

+

zone "." {

+

type hint;

+

file "/etc/bind/db.root";

+

};

+

+

// be authoritative for the localhost forward and reverse zones, and for

+

// broadcast zones as per RFC 1912

+

+

zone "11.22.33.44" {

+

type master;

+

file "/etc/bind/db.local";

+

};

+

+

zone "127.in-addr.arpa" {

+

<snip>

+

</pre>

+

:I'm unsure if this next step is necessary, but I did it anyway...

+

:Edit /etc/bind/db.local and modify all instances of 'localhost' and '127.0.0.1' with your IP address.

+

:When complete, it should look something like this:

+

<pre>

+

vps:~# cat /etc/bind/db.local

+

;

+

; BIND data file for local loopback interface

+

;

+

$TTL 604800

+

@ IN SOA 11.22.33.44. root.11.22.33.44. (

+

1 ; Serial

+

604800 ; Refresh

+

86400 ; Retry

+

2419200 ; Expire

+

604800 ) ; Negative Cache TTL

+

;

+

@ IN NS 11.22.33.44.

+

@ IN A 11.22.33.44

+

</pre>

+

:All that's left is to start your new error-free Bind9 (we hope...)

+

<pre>

+

/etc/init.d/bind9 start

+

</pre>

+

<br />

+

If you find anything in this tutorial OR in the Perl script that's incorrect, or that would make it better, please let me know: [mailto:paul@grandesigns.net?Subject=VServer_Bind9_Tutorial paul@grandesigns.net]

+

<br><hr>

+

=====Update (11/04/08)...=====

+

After an apt-get dist-upgrade, bind9 failed to start. After poking around, I found out that somehow /etc/default/bind had the -u switch set to run Bind9 as the user 'named'. Weird, because with Bind9, there is no user 'named'. I set it back to: -u bind

+

and everything fired right up.

+

Also, my particular vserver doesn't log to dmesg, so if you want intuitive debug level info that isn't being printed in /var/log/syslog, then you can run named like this:

+

<pre>

+

named -g -d 10

+

</pre>

+

That tells named to start with the debug level globally set to 10.

+

<br><br>

+

I also tinkered a little more and found that you can remove all of the db. files in /etc/bind and in /etc/bind/named.conf except for db.local and db.root. In other words, you don't need to configure or keep db.0, db.127, db.255, db.empty, nor do you need them referenced in named.conf.

+

<br><br>

+

<hr>

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

Line 279:

Line 479:

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

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

−

=== 127.0.0.1 issues ===

+

=== nagios ===

−

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 :

+

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

−

<pre>

+

−

dev lo

+

on older kernels, which do not support loopback isolation (separate 127.0.0.1) and use 'localhost' mapped to the first guest IP you can work around this by adding 127.0.0.1 to the interfaces (temporarily) but make sure to remove it afterwards.

−

ip 127.0.0.1

+

−

mask 255.0.0.0

+

−

name lo

+

−

</pre>

+

−

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

<div style="color: red;">

<div style="color: red;">

note: nagios is broken, because it uses a hardcoded 127.0.0.1, and this change (which is not needed with newer kernels providing lback remapping) will affect guest security and should not be used lightly (Bertl)

note: nagios is broken, because it uses a hardcoded 127.0.0.1, and this change (which is not needed with newer kernels providing lback remapping) will affect guest security and should not be used lightly (Bertl)

Line 353:

Line 547:

CAP_IPC_LOCK

CAP_IPC_LOCK

CAP_IPC_OWNER

CAP_IPC_OWNER

−

which will greatly reduce security.

+

<div style="color: red;">

−

+

WARNING: this configuration reduces security

+

</div>

=== ejabberd ===

=== ejabberd ===

−

ejabberd does not work properly in a Linux-VServer guest under Debian Etch. The server eventually stops accepting connections. Also, it's not possible to control ejabberd with ejabberdctl. The Jabber server from the jabber package works though.

+

ejabberd does not work properly in a Linux-VServer guest under Debian Etch. The server eventually stops accepting connections. Also, it's not possible to control ejabberd with ejabberdctl.

+

+

Newer versions of ejabberd (2.0.x) don't seem to have this problem. On Debian Etch a newer version can be installed from etch-backports ([http://backports.org/dokuwiki/doku.php?id=instructions backports.org]).

+

+

The Jabber server from the jabber package also works.

+

+

Other problem, which seems to happen with (at least) erlang R14B : epmd has been modified and accepts some commands only from 127/8, which causes problems. Details and solution can be found here : http://www.ejabberd.im/node/3709.

+

In case this page becomes unavailable, the solution is to change network flags on the vserver, as follow (run these on the host) :

+

+

nattribute --set --nid vserver_name --flag ~single_ip

+

echo "~single_ip" > /etc/vservers/vserver_name/nflags

+

+

+

=== VMware Server ===

+

VMware Server needs the following capabilities to run correctly:

+

CAP_MKNOD

+

CAP_SYS_MODULE

+

CAP_SYS_ADMIN

+

CAP_SYS_NICE

+

CAP_NET_RAW

+

CAP_NET_ADMIN

+

CAP_IPC_OWNER

+

<div style="color: red;">

+

WARNING: this configuration reduces security

+

</div>

+

+

=== ntpd ===

+

The ntpd daemon needs to set the hardware time and can't do that from inside a vserver by default.

+

Allow CAP_SYS_TIME and ntpd will be happy.

+

+

=== FAI server / fai-setup ===

+

FAI Server / fai-setup

+

fai-setup wants to create some devices and needs to mount proc.

+

+

bcapabilities:

+

MKNOD

+

ccapabilities:

+

SECURE_MOUNT

+

SECURE_REMOUNT

+

BINARY_MOUNT

+

<div style="color: red;">

+

WARNING: this configuration reduces security big time

+

</div>

+

Only do it if you just want your FAIserver in a seperate tree from main server.

+

+

[[Category:Software under linux-vserver| ]]

+

[[Category:Documentation| ]]

Latest revision as of 22:43, 21 October 2011

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

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)

util-vserver 0.30.211+ includes a workaround for the issue (vlogin), which allocates a tty inside the guest.

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.

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

To assign the broadcast address to a vserver guest you need to create a new directory inside the /etc/vservers/<guest name>/interfaces/ directory. The directory is a number not used by this vserver guest. Inside the directory should be normal information and a file called nodev (see util-vserver for information). The contents of the dev file can be identical between directories.

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.

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

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.

Before I begin with all the grueling steps, if you want to be lazy, I wrote a Perl script to do all of this for you, and you can get it here.

Note:

If you plan to use the script, you need to ensure you have Perl5, as well as have your locale set properly.

(On a brand-new Etch guest, I had to do those before my script would work)

I noticed after much googling that all links I found to any of the pre-compiled Bind9 (in the above bind9-capacheck directories) are DEAD. However, after many times of running into a brick wall, I caught something that isn't mentioned here...

Following the above steps to build Bind9 from source acquired with apt-get, if you look closely, on about line 499 or so after you execute the dpkg-buildpackage command, you'll see this:

dpkg-source: building bind9 using existing bind9_9.3.4.orig.tar.gz
dpkg-source: building bind9 in bind9_9.3.4-2etch3.diff.gz
dpkg-source: building bind9 in bind9_9.3.4-2etch3.dsc

...which is basically ignoring the debian/rules modifications you just made...

So, following you will find the steps I took to make Bind9 AND rndc run flawlessly on my vserver guest. Everything denoted with // in front is a comment:

Finally, you need to do the same process, but with the 'controls' section of the rndc-confgen output, and that goes in /etc/named.conf. Again, you will need to add the include statement for the key you created.

Also, while you're editing named.conf, you might as well go ahead and edit the IP addresses. The only one that really seems to matter is the 'localhost' zone

When finished, your named.conf should look something like this (only showing the relevant portions)

Be sure to remove the comment tags (#) from the beginning of the lines!!!

After an apt-get dist-upgrade, bind9 failed to start. After poking around, I found out that somehow /etc/default/bind had the -u switch set to run Bind9 as the user 'named'. Weird, because with Bind9, there is no user 'named'. I set it back to: -u bind
and everything fired right up.
Also, my particular vserver doesn't log to dmesg, so if you want intuitive debug level info that isn't being printed in /var/log/syslog, then you can run named like this:

named -g -d 10

That tells named to start with the debug level globally set to 10.

I also tinkered a little more and found that you can remove all of the db. files in /etc/bind and in /etc/bind/named.conf except for db.local and db.root. In other words, you don't need to configure or keep db.0, db.127, db.255, db.empty, nor do you need them referenced in named.conf.

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 now starts when using /etc/init.d/bind9 start and resolving seems to work. Mind you, the usual warnings and rants about running stuff as root still applies! - 2007-08-06 MGS

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

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

on older kernels, which do not support loopback isolation (separate 127.0.0.1) and use 'localhost' mapped to the first guest IP you can work around this by adding 127.0.0.1 to the interfaces (temporarily) but make sure to remove it afterwards.

note: nagios is broken, because it uses a hardcoded 127.0.0.1, and this change (which is not needed with newer kernels providing lback remapping) will affect guest security and should not be used lightly (Bertl)

ejabberd does not work properly in a Linux-VServer guest under Debian Etch. The server eventually stops accepting connections. Also, it's not possible to control ejabberd with ejabberdctl.

Newer versions of ejabberd (2.0.x) don't seem to have this problem. On Debian Etch a newer version can be installed from etch-backports (backports.org).

The Jabber server from the jabber package also works.

Other problem, which seems to happen with (at least) erlang R14B : epmd has been modified and accepts some commands only from 127/8, which causes problems. Details and solution can be found here : http://www.ejabberd.im/node/3709.
In case this page becomes unavailable, the solution is to change network flags on the vserver, as follow (run these on the host) :