http://linux-vserver.org/api.php?action=feedcontributions&user=Kapil&feedformat=atomLinux-VServer - User contributions [en]2024-03-28T19:31:12ZUser contributionsMediaWiki 1.20.2http://linux-vserver.org/RestrictingVserverNetworkingTipsRestrictingVserverNetworkingTips2007-09-17T13:21:33Z<p>Kapil: added related links</p>
<hr />
<div>= Tips on Restricting Vserver Guest Network Access =<br />
<br />
These tips are being collected here because they seem scattered over<br />
the documentation. (Thanks to Bertl on <tt>#vserver</tt> for these tips<br />
but errors are not his responsibility :)).<br />
<br />
Most of the discussion below is based on vserver version 2.0.2 with<br />
util-vserver version 0.30.212. Newer versions have easier ways to<br />
achieve the same goals.<br />
<br />
Before doing anything else with Vserver Networking you should repeat<br />
the following mantras many times:<br />
# Network routing policy is determined by the routing table on the host.<br />
# The first interface defined in each guest is treated as the address of the loopback interface for the guest. (The Great Flower Page talks about the <tt>lback</tt> configuration; how does that work?)<br />
# The guest can only establishing "listeners" on <tt><IP address>:<port></tt> combinations where <tt><IP address></tt> is an address that is "assigned" to the guest via an interface definition (or a call to <tt>naddress</tt>).<br />
# All guest interfaces are also available to the host.<br />
<br />
== Network-less guest ==<br />
Strictly speaking this is an "interface-less" guest rather than<br />
a network-less one. This is a guest that cannot make network<br />
connections and cannot be reached from the network since it has<br />
''no'' network interfaces.<br />
<br />
On a kernel with newer (>= 2.3?) vserver patches it should be possible to create a guest<br />
with no interfaces by keeping the directory <tt>/etc/vservers/<guest-name>/interfaces/</tt> empty.<br />
<br />
However, this does '''not''' work with Debian etch (util-vserver 0.30.212 and vserver 2.0.2).<br />
Instead, you get a guest with all host interfaces available for outgoing network connections. At the same time the guest cannot bind a server to these interfaces so one cannot reach the guest from the network.<br />
<br />
To disable ''outgoing'' use of network interfaces under a <br />
kernel with the older (<= 2.0.2?) vserver patches, you<br />
proceed as follows. You create an interface directory (say<br />
<tt>/etc/vservers/<guest-name>/interfaces/0/</tt>) with the<br />
<tt>nodev</tt> configuration. Be sure to define an <tt>ip</tt> as this<br />
is verified first in <tt>/usr/lib/util-vserver/vserver.functions</tt>;<br />
the value in <tt>ip</tt> can be any IP address that is '''not'''<br />
an IP address of the host. (For example, an address like<br />
<tt>192.168.x.y</tt> or <tt>10.x.y.z</tt> which is chosen at random<br />
will not be a host address with some luck.)<br />
This will result in a non-existent host interface being "assigned" to<br />
the guest and thus "no" interface will be available to the guest.<br />
<br />
== Network-local guest ==<br />
We now describe a configuration that leads to a guest that can (''a priori'')<br />
only connect to the host and can be reached via the network only<br />
from the host.<br />
<br />
Define an interface using <tt>dummy0</tt> as the value of <tt>dev</tt> and an <tt>ip</tt><br />
value like <tt>192.168.x.y</tt> or <tt>10.x.y.z</tt> which is not an existing<br />
external-facing interface address for the host. (You may need to<br />
<tt>modprobe dummy</tt> in order to create such an interface.)<br />
<br />
The guest can now connect to '''any''' service on the host that is<br />
listening for connections to <tt><IP address>:80</tt>; where the IP address<br />
must be the one chosen above or the wildcard <tt>0.0.0.0</tt>. For example,<br />
if the host is running a web server that listens to <tt>0.0.0.0</tt>, then<br />
(in the guest) one can run the command<br />
<blockquote><br />
socat - TCP:192.168.x.y:80<br />
</blockquote><br />
to connect to this server; where as before <tt>192.168.x.y</tt> is the chosen IP address.<br />
On the guest, this command is '''equivalent''' to the command<br />
<blockquote><br />
socat - TCP:127.0.0.1:80<br />
</blockquote><br />
Note that the address 127.0.0.1 '''on the guest''' is '''equivalent''' to the chosen<br />
IP address but '''not''' on the host.<br />
<br />
Similarly, the guest can start servers that listen to<br />
<tt>192.168.x.y:8888</tt> or <tt>0.0.0.0:8888</tt> providing that there is no<br />
server that is already listening to this address (on the guest '''or'''<br />
on the host). The host can connect to such a server using the command<br />
<blockquote><br />
socat - TCP:192.168.x.y:80<br />
</blockquote><br />
Both the above type of connections, <tt>guest-to-host</tt> or <tt>host-to-guest</tt><br />
happen over the loopback network interface. <br />
<br />
Suppose you do not want the guest to access services on the host and<br />
vice versa. Then you use <tt>netfilter</tt> to limit connections over<br />
the loopback port. For example,<br />
<blockquote><br />
iptables -I INPUT -d ! 127.0.0.1 -i lo -j DROP<br />
</blockquote><br />
One can restrict specific services by more specific netfilter rules. <br />
For example, we can use<br />
<blockquote><br />
iptables -I INPUT -i lo -p tcp --dport 80 -j ACCEPT<br />
</blockquote><br />
to allow the guest to access the web server on the host and vice<br />
versa.<br />
<br />
'''Warning''': With this configuration the guest will "pollute" the<br />
network neighbourhood with packets whose source address is the given<br />
IP address. So it is best to use netfilter to prevent this with a<br />
configuration like<br />
<blockquote><br />
iptables -I OUTPUT -s 192.168.x.y -d ! lo -j DROP<br />
</blockquote><br />
<br />
== Network-global guest ==<br />
To allow the guest as configured above to have access to the wider<br />
network beyond the host, you can replace the <tt>dummy0</tt><br />
interface with a real one and the private IP address with a "real" IP<br />
address --- assuming such a static adddress is available.<br />
<br />
If your host has a dynamic external IP address and or interface,<br />
then one can instead use <tt>netfilter</tt> to translate the private<br />
address into a real one.<br />
<blockquote><br />
iptables -t nat -A POSTROUTING -o ! lo -j MASQUERADE<br />
</blockquote><br />
This allows the guest to access the internet without polluting the<br />
network neighbourhood with 192.168.x.y addresses.<br />
<br />
==See also==<br />
* [[Networking_vserver_guests |Networking vserver guests]]<br />
* [[Frequently_Asked_Questions#If_my_host_has_only_one_a_single_public_IP.2C_can_I_use_RFC1918_IP_.28e.g._192.168.foo.bar.29_for_the_guest_vservers.3F |FAQ on private networking]]<br />
* [[Frequently_Asked_Questions#When_I_try_to_ssh_to_the_guest.2C_I_log_into_the_host.2C_even_if_I_installed_sshd_on_the_guest._What.27s_wrong_here.3F |Permit guest sshd to bind to its IP address's port 22]]<br />
<br />
----<br />
[[User:Kapil|Kapil Hari Paranjape]] 13:09, 17 September 2007 (CEST)</div>Kapilhttp://linux-vserver.org/RestrictingVserverNetworkingTipsRestrictingVserverNetworkingTips2007-09-17T11:25:44Z<p>Kapil: /* Tips on Restricting Vserver Guest Network Access */ Errors are not Bertls!</p>
<hr />
<div>= Tips on Restricting Vserver Guest Network Access =<br />
<br />
These tips are being collected here because they seem scattered over<br />
the documentation. (Thanks to Bertl on <tt>#vserver</tt> for these tips<br />
but errors are not his responsibility :)).<br />
<br />
Most of the discussion below is based on vserver version 2.0.2 with<br />
util-vserver version 0.30.212. Newer versions have easier ways to<br />
achieve the same goals.<br />
<br />
Before doing anything else with Vserver Networking you should repeat<br />
the following mantras many times:<br />
# Network routing policy is determined by the routing table on the host.<br />
# The first interface defined in each guest is treated as the address of the loopback interface for the guest. (The Great Flower Page talks about the <tt>lback</tt> configuration; how does that work?)<br />
# The guest can only establishing "listeners" on <tt><IP address>:<port></tt> combinations where <tt><IP address></tt> is an address that is "assigned" to the guest via an interface definition (or a call to <tt>naddress</tt>).<br />
# All guest interfaces are also available to the host.<br />
<br />
== Network-less guest ==<br />
Strictly speaking this is an "interface-less" guest rather than<br />
a network-less one. This is a guest that cannot make network<br />
connections and cannot be reached from the network since it has<br />
''no'' network interfaces.<br />
<br />
On a kernel with newer (>= 2.3?) vserver patches it should be possible to create a guest<br />
with no interfaces by keeping the directory <tt>/etc/vservers/<guest-name>/interfaces/</tt> empty.<br />
<br />
However, this does '''not''' work with Debian etch (util-vserver 0.30.212 and vserver 2.0.2).<br />
Instead, you get a guest with all host interfaces available for outgoing network connections. At the same time the guest cannot bind a server to these interfaces so one cannot reach the guest from the network.<br />
<br />
To disable ''outgoing'' use of network interfaces under a <br />
kernel with the older (<= 2.0.2?) vserver patches, you<br />
proceed as follows. You create an interface directory (say<br />
<tt>/etc/vservers/<guest-name>/interfaces/0/</tt>) with the<br />
<tt>nodev</tt> configuration. Be sure to define an <tt>ip</tt> as this<br />
is verified first in <tt>/usr/lib/util-vserver/vserver.functions</tt>;<br />
the value in <tt>ip</tt> can be any IP address that is '''not'''<br />
an IP address of the host. (For example, an address like<br />
<tt>192.168.x.y</tt> or <tt>10.x.y.z</tt> which is chosen at random<br />
will not be a host address with some luck.)<br />
This will result in a non-existent host interface being "assigned" to<br />
the guest and thus "no" interface will be available to the guest.<br />
<br />
== Network-local guest ==<br />
We now describe a configuration that leads to a guest that can (''a priori'')<br />
only connect to the host and can be reached via the network only<br />
from the host.<br />
<br />
Define an interface using <tt>dummy0</tt> as the value of <tt>dev</tt> and an <tt>ip</tt><br />
value like <tt>192.168.x.y</tt> or <tt>10.x.y.z</tt> which is not an existing<br />
external-facing interface address for the host. (You may need to<br />
<tt>modprobe dummy</tt> in order to create such an interface.)<br />
<br />
The guest can now connect to '''any''' service on the host that is<br />
listening for connections to <tt><IP address>:80</tt>; where the IP address<br />
must be the one chosen above or the wildcard <tt>0.0.0.0</tt>. For example,<br />
if the host is running a web server that listens to <tt>0.0.0.0</tt>, then<br />
(in the guest) one can run the command<br />
<blockquote><br />
socat - TCP:192.168.x.y:80<br />
</blockquote><br />
to connect to this server; where as before <tt>192.168.x.y</tt> is the chosen IP address.<br />
On the guest, this command is '''equivalent''' to the command<br />
<blockquote><br />
socat - TCP:127.0.0.1:80<br />
</blockquote><br />
Note that the address 127.0.0.1 '''on the guest''' is '''equivalent''' to the chosen<br />
IP address but '''not''' on the host.<br />
<br />
Similarly, the guest can start servers that listen to<br />
<tt>192.168.x.y:8888</tt> or <tt>0.0.0.0:8888</tt> providing that there is no<br />
server that is already listening to this address (on the guest '''or'''<br />
on the host). The host can connect to such a server using the command<br />
<blockquote><br />
socat - TCP:192.168.x.y:80<br />
</blockquote><br />
Both the above type of connections, <tt>guest-to-host</tt> or <tt>host-to-guest</tt><br />
happen over the loopback network interface. <br />
<br />
Suppose you do not want the guest to access services on the host and<br />
vice versa. Then you use <tt>netfilter</tt> to limit connections over<br />
the loopback port. For example,<br />
<blockquote><br />
iptables -I INPUT -d ! 127.0.0.1 -i lo -j DROP<br />
</blockquote><br />
One can restrict specific services by more specific netfilter rules. <br />
For example, we can use<br />
<blockquote><br />
iptables -I INPUT -i lo -p tcp --dport 80 -j ACCEPT<br />
</blockquote><br />
to allow the guest to access the web server on the host and vice<br />
versa.<br />
<br />
'''Warning''': With this configuration the guest will "pollute" the<br />
network neighbourhood with packets whose source address is the given<br />
IP address. So it is best to use netfilter to prevent this with a<br />
configuration like<br />
<blockquote><br />
iptables -I OUTPUT -s 192.168.x.y -d ! lo -j DROP<br />
</blockquote><br />
<br />
== Network-global guest ==<br />
To allow the guest as configured above to have access to the wider<br />
network beyond the host, you can replace the <tt>dummy0</tt><br />
interface with a real one and the private IP address with a "real" IP<br />
address --- assuming such a static adddress is available.<br />
<br />
If your host has a dynamic external IP address and or interface,<br />
then one can instead use <tt>netfilter</tt> to translate the private<br />
address into a real one.<br />
<blockquote><br />
iptables -t nat -A POSTROUTING -o ! lo -j MASQUERADE<br />
</blockquote><br />
This allows the guest to access the internet without polluting the<br />
network neighbourhood with 192.168.x.y addresses.<br />
<br />
----<br />
[[User:Kapil|Kapil Hari Paranjape]] 13:09, 17 September 2007 (CEST)</div>Kapilhttp://linux-vserver.org/RestrictingVserverNetworkingTipsRestrictingVserverNetworkingTips2007-09-17T11:24:30Z<p>Kapil: /* Network-less guest */ another version number fix</p>
<hr />
<div>= Tips on Restricting Vserver Guest Network Access =<br />
<br />
These tips are being collected here because they seem scattered over<br />
the documentation. (Thanks to Bertl on <tt>#vserver</tt> for these tips).<br />
<br />
Most of the discussion below is based on vserver version 2.0.2 with<br />
util-vserver version 0.30.212. Newer versions have easier ways to<br />
achieve the same goals.<br />
<br />
Before doing anything else with Vserver Networking you should repeat<br />
the following mantras many times:<br />
# Network routing policy is determined by the routing table on the host.<br />
# The first interface defined in each guest is treated as the address of the loopback interface for the guest. (The Great Flower Page talks about the <tt>lback</tt> configuration; how does that work?)<br />
# The guest can only establishing "listeners" on <tt><IP address>:<port></tt> combinations where <tt><IP address></tt> is an address that is "assigned" to the guest via an interface definition (or a call to <tt>naddress</tt>).<br />
# All guest interfaces are also available to the host.<br />
<br />
== Network-less guest ==<br />
Strictly speaking this is an "interface-less" guest rather than<br />
a network-less one. This is a guest that cannot make network<br />
connections and cannot be reached from the network since it has<br />
''no'' network interfaces.<br />
<br />
On a kernel with newer (>= 2.3?) vserver patches it should be possible to create a guest<br />
with no interfaces by keeping the directory <tt>/etc/vservers/<guest-name>/interfaces/</tt> empty.<br />
<br />
However, this does '''not''' work with Debian etch (util-vserver 0.30.212 and vserver 2.0.2).<br />
Instead, you get a guest with all host interfaces available for outgoing network connections. At the same time the guest cannot bind a server to these interfaces so one cannot reach the guest from the network.<br />
<br />
To disable ''outgoing'' use of network interfaces under a <br />
kernel with the older (<= 2.0.2?) vserver patches, you<br />
proceed as follows. You create an interface directory (say<br />
<tt>/etc/vservers/<guest-name>/interfaces/0/</tt>) with the<br />
<tt>nodev</tt> configuration. Be sure to define an <tt>ip</tt> as this<br />
is verified first in <tt>/usr/lib/util-vserver/vserver.functions</tt>;<br />
the value in <tt>ip</tt> can be any IP address that is '''not'''<br />
an IP address of the host. (For example, an address like<br />
<tt>192.168.x.y</tt> or <tt>10.x.y.z</tt> which is chosen at random<br />
will not be a host address with some luck.)<br />
This will result in a non-existent host interface being "assigned" to<br />
the guest and thus "no" interface will be available to the guest.<br />
<br />
== Network-local guest ==<br />
We now describe a configuration that leads to a guest that can (''a priori'')<br />
only connect to the host and can be reached via the network only<br />
from the host.<br />
<br />
Define an interface using <tt>dummy0</tt> as the value of <tt>dev</tt> and an <tt>ip</tt><br />
value like <tt>192.168.x.y</tt> or <tt>10.x.y.z</tt> which is not an existing<br />
external-facing interface address for the host. (You may need to<br />
<tt>modprobe dummy</tt> in order to create such an interface.)<br />
<br />
The guest can now connect to '''any''' service on the host that is<br />
listening for connections to <tt><IP address>:80</tt>; where the IP address<br />
must be the one chosen above or the wildcard <tt>0.0.0.0</tt>. For example,<br />
if the host is running a web server that listens to <tt>0.0.0.0</tt>, then<br />
(in the guest) one can run the command<br />
<blockquote><br />
socat - TCP:192.168.x.y:80<br />
</blockquote><br />
to connect to this server; where as before <tt>192.168.x.y</tt> is the chosen IP address.<br />
On the guest, this command is '''equivalent''' to the command<br />
<blockquote><br />
socat - TCP:127.0.0.1:80<br />
</blockquote><br />
Note that the address 127.0.0.1 '''on the guest''' is '''equivalent''' to the chosen<br />
IP address but '''not''' on the host.<br />
<br />
Similarly, the guest can start servers that listen to<br />
<tt>192.168.x.y:8888</tt> or <tt>0.0.0.0:8888</tt> providing that there is no<br />
server that is already listening to this address (on the guest '''or'''<br />
on the host). The host can connect to such a server using the command<br />
<blockquote><br />
socat - TCP:192.168.x.y:80<br />
</blockquote><br />
Both the above type of connections, <tt>guest-to-host</tt> or <tt>host-to-guest</tt><br />
happen over the loopback network interface. <br />
<br />
Suppose you do not want the guest to access services on the host and<br />
vice versa. Then you use <tt>netfilter</tt> to limit connections over<br />
the loopback port. For example,<br />
<blockquote><br />
iptables -I INPUT -d ! 127.0.0.1 -i lo -j DROP<br />
</blockquote><br />
One can restrict specific services by more specific netfilter rules. <br />
For example, we can use<br />
<blockquote><br />
iptables -I INPUT -i lo -p tcp --dport 80 -j ACCEPT<br />
</blockquote><br />
to allow the guest to access the web server on the host and vice<br />
versa.<br />
<br />
'''Warning''': With this configuration the guest will "pollute" the<br />
network neighbourhood with packets whose source address is the given<br />
IP address. So it is best to use netfilter to prevent this with a<br />
configuration like<br />
<blockquote><br />
iptables -I OUTPUT -s 192.168.x.y -d ! lo -j DROP<br />
</blockquote><br />
<br />
== Network-global guest ==<br />
To allow the guest as configured above to have access to the wider<br />
network beyond the host, you can replace the <tt>dummy0</tt><br />
interface with a real one and the private IP address with a "real" IP<br />
address --- assuming such a static adddress is available.<br />
<br />
If your host has a dynamic external IP address and or interface,<br />
then one can instead use <tt>netfilter</tt> to translate the private<br />
address into a real one.<br />
<blockquote><br />
iptables -t nat -A POSTROUTING -o ! lo -j MASQUERADE<br />
</blockquote><br />
This allows the guest to access the internet without polluting the<br />
network neighbourhood with 192.168.x.y addresses.<br />
<br />
----<br />
[[User:Kapil|Kapil Hari Paranjape]] 13:09, 17 September 2007 (CEST)</div>Kapilhttp://linux-vserver.org/RestrictingVserverNetworkingTipsRestrictingVserverNetworkingTips2007-09-17T11:15:29Z<p>Kapil: another version fix</p>
<hr />
<div>= Tips on Restricting Vserver Guest Network Access =<br />
<br />
These tips are being collected here because they seem scattered over<br />
the documentation. (Thanks to Bertl on <tt>#vserver</tt> for these tips).<br />
<br />
Most of the discussion below is based on vserver version 2.0.2 with<br />
util-vserver version 0.30.212. Newer versions have easier ways to<br />
achieve the same goals.<br />
<br />
Before doing anything else with Vserver Networking you should repeat<br />
the following mantras many times:<br />
# Network routing policy is determined by the routing table on the host.<br />
# The first interface defined in each guest is treated as the address of the loopback interface for the guest. (The Great Flower Page talks about the <tt>lback</tt> configuration; how does that work?)<br />
# The guest can only establishing "listeners" on <tt><IP address>:<port></tt> combinations where <tt><IP address></tt> is an address that is "assigned" to the guest via an interface definition (or a call to <tt>naddress</tt>).<br />
# All guest interfaces are also available to the host.<br />
<br />
== Network-less guest ==<br />
Strictly speaking this is an "interface-less" guest rather than<br />
a network-less one. This is a guest that cannot make network<br />
connections and cannot be reached from the network since it has<br />
''no'' network interfaces.<br />
<br />
On a kernel with newer (>= 2.3?) vserver patches it should be possible to create a guest<br />
with no interfaces by keeping the directory <tt>/etc/vservers/<guest-name>/interfaces/</tt> empty.<br />
<br />
However, this does '''not''' work with Debian etch (util-vserver 0.30.212 and vserver 2.2).<br />
Instead, you get a guest with all host interfaces available for outgoing network connections. At the same time the guest cannot bind a server to these interfaces so one cannot reach the guest from the network.<br />
<br />
To disable ''outgoing'' use of network interfaces under a <br />
kernel with the older (<= 2.0.2?) vserver patches, you<br />
proceed as follows. You create an interface directory (say<br />
<tt>/etc/vservers/<guest-name>/interfaces/0/</tt>) with the<br />
<tt>nodev</tt> configuration. Be sure to define an <tt>ip</tt> as this<br />
is verified first in <tt>/usr/lib/util-vserver/vserver.functions</tt>;<br />
the value in <tt>ip</tt> can be any IP address that is '''not'''<br />
an IP address of the host. (For example, an address like<br />
<tt>192.168.x.y</tt> or <tt>10.x.y.z</tt> which is chosen at random<br />
will not be a host address with some luck.)<br />
This will result in a non-existent host interface being "assigned" to<br />
the guest and thus "no" interface will be available to the guest.<br />
<br />
== Network-local guest ==<br />
We now describe a configuration that leads to a guest that can (''a priori'')<br />
only connect to the host and can be reached via the network only<br />
from the host.<br />
<br />
Define an interface using <tt>dummy0</tt> as the value of <tt>dev</tt> and an <tt>ip</tt><br />
value like <tt>192.168.x.y</tt> or <tt>10.x.y.z</tt> which is not an existing<br />
external-facing interface address for the host. (You may need to<br />
<tt>modprobe dummy</tt> in order to create such an interface.)<br />
<br />
The guest can now connect to '''any''' service on the host that is<br />
listening for connections to <tt><IP address>:80</tt>; where the IP address<br />
must be the one chosen above or the wildcard <tt>0.0.0.0</tt>. For example,<br />
if the host is running a web server that listens to <tt>0.0.0.0</tt>, then<br />
(in the guest) one can run the command<br />
<blockquote><br />
socat - TCP:192.168.x.y:80<br />
</blockquote><br />
to connect to this server; where as before <tt>192.168.x.y</tt> is the chosen IP address.<br />
On the guest, this command is '''equivalent''' to the command<br />
<blockquote><br />
socat - TCP:127.0.0.1:80<br />
</blockquote><br />
Note that the address 127.0.0.1 '''on the guest''' is '''equivalent''' to the chosen<br />
IP address but '''not''' on the host.<br />
<br />
Similarly, the guest can start servers that listen to<br />
<tt>192.168.x.y:8888</tt> or <tt>0.0.0.0:8888</tt> providing that there is no<br />
server that is already listening to this address (on the guest '''or'''<br />
on the host). The host can connect to such a server using the command<br />
<blockquote><br />
socat - TCP:192.168.x.y:80<br />
</blockquote><br />
Both the above type of connections, <tt>guest-to-host</tt> or <tt>host-to-guest</tt><br />
happen over the loopback network interface. <br />
<br />
Suppose you do not want the guest to access services on the host and<br />
vice versa. Then you use <tt>netfilter</tt> to limit connections over<br />
the loopback port. For example,<br />
<blockquote><br />
iptables -I INPUT -d ! 127.0.0.1 -i lo -j DROP<br />
</blockquote><br />
One can restrict specific services by more specific netfilter rules. <br />
For example, we can use<br />
<blockquote><br />
iptables -I INPUT -i lo -p tcp --dport 80 -j ACCEPT<br />
</blockquote><br />
to allow the guest to access the web server on the host and vice<br />
versa.<br />
<br />
'''Warning''': With this configuration the guest will "pollute" the<br />
network neighbourhood with packets whose source address is the given<br />
IP address. So it is best to use netfilter to prevent this with a<br />
configuration like<br />
<blockquote><br />
iptables -I OUTPUT -s 192.168.x.y -d ! lo -j DROP<br />
</blockquote><br />
<br />
== Network-global guest ==<br />
To allow the guest as configured above to have access to the wider<br />
network beyond the host, you can replace the <tt>dummy0</tt><br />
interface with a real one and the private IP address with a "real" IP<br />
address --- assuming such a static adddress is available.<br />
<br />
If your host has a dynamic external IP address and or interface,<br />
then one can instead use <tt>netfilter</tt> to translate the private<br />
address into a real one.<br />
<blockquote><br />
iptables -t nat -A POSTROUTING -o ! lo -j MASQUERADE<br />
</blockquote><br />
This allows the guest to access the internet without polluting the<br />
network neighbourhood with 192.168.x.y addresses.<br />
<br />
----<br />
[[User:Kapil|Kapil Hari Paranjape]] 13:09, 17 September 2007 (CEST)</div>Kapilhttp://linux-vserver.org/RestrictingVserverNetworkingTipsRestrictingVserverNetworkingTips2007-09-17T11:13:22Z<p>Kapil: version of vserver</p>
<hr />
<div>= Tips on Restricting Vserver Guest Network Access =<br />
<br />
These tips are being collected here because they seem scattered over<br />
the documentation. (Thanks to Bertl on <tt>#vserver</tt> for these tips).<br />
<br />
Most of the discussion below is based on vserver version 2.0.2 with<br />
util-vserver version 0.30.212. Newer versions have easier ways to<br />
achieve the same goals.<br />
<br />
Before doing anything else with Vserver Networking you should repeat<br />
the following mantras many times:<br />
# Network routing policy is determined by the routing table on the host.<br />
# The first interface defined in each guest is treated as the address of the loopback interface for the guest. (The Great Flower Page talks about the <tt>lback</tt> configuration; how does that work?)<br />
# The guest can only establishing "listeners" on <tt><IP address>:<port></tt> combinations where <tt><IP address></tt> is an address that is "assigned" to the guest via an interface definition (or a call to <tt>naddress</tt>).<br />
# All guest interfaces are also available to the host.<br />
<br />
== Network-less guest ==<br />
Strictly speaking this is an "interface-less" guest rather than<br />
a network-less one. This is a guest that cannot make network<br />
connections and cannot be reached from the network since it has<br />
''no'' network interfaces.<br />
<br />
On a kernel with newer (>= 2.0.3?) vserver patches it should be possible to create a guest<br />
with no interfaces by keeping the directory <tt>/etc/vservers/<guest-name>/interfaces/</tt> empty.<br />
<br />
However, this does '''not''' work with Debian etch (util-vserver 0.30.212 and vserver 2.2).<br />
Instead, you get a guest with all host interfaces available for outgoing network connections. At the same time the guest cannot bind a server to these interfaces so one cannot reach the guest from the network.<br />
<br />
To disable ''outgoing'' use of network interfaces under a <br />
kernel with the older (<= 2.0.2?) vserver patches, you<br />
proceed as follows. You create an interface directory (say<br />
<tt>/etc/vservers/<guest-name>/interfaces/0/</tt>) with the<br />
<tt>nodev</tt> configuration. Be sure to define an <tt>ip</tt> as this<br />
is verified first in <tt>/usr/lib/util-vserver/vserver.functions</tt>;<br />
the value in <tt>ip</tt> can be any IP address that is '''not'''<br />
an IP address of the host. (For example, an address like<br />
<tt>192.168.x.y</tt> or <tt>10.x.y.z</tt> which is chosen at random<br />
will not be a host address with some luck.)<br />
This will result in a non-existent host interface being "assigned" to<br />
the guest and thus "no" interface will be available to the guest.<br />
<br />
== Network-local guest ==<br />
We now describe a configuration that leads to a guest that can (''a priori'')<br />
only connect to the host and can be reached via the network only<br />
from the host.<br />
<br />
Define an interface using <tt>dummy0</tt> as the value of <tt>dev</tt> and an <tt>ip</tt><br />
value like <tt>192.168.x.y</tt> or <tt>10.x.y.z</tt> which is not an existing<br />
external-facing interface address for the host. (You may need to<br />
<tt>modprobe dummy</tt> in order to create such an interface.)<br />
<br />
The guest can now connect to '''any''' service on the host that is<br />
listening for connections to <tt><IP address>:80</tt>; where the IP address<br />
must be the one chosen above or the wildcard <tt>0.0.0.0</tt>. For example,<br />
if the host is running a web server that listens to <tt>0.0.0.0</tt>, then<br />
(in the guest) one can run the command<br />
<blockquote><br />
socat - TCP:192.168.x.y:80<br />
</blockquote><br />
to connect to this server; where as before <tt>192.168.x.y</tt> is the chosen IP address.<br />
On the guest, this command is '''equivalent''' to the command<br />
<blockquote><br />
socat - TCP:127.0.0.1:80<br />
</blockquote><br />
Note that the address 127.0.0.1 '''on the guest''' is '''equivalent''' to the chosen<br />
IP address but '''not''' on the host.<br />
<br />
Similarly, the guest can start servers that listen to<br />
<tt>192.168.x.y:8888</tt> or <tt>0.0.0.0:8888</tt> providing that there is no<br />
server that is already listening to this address (on the guest '''or'''<br />
on the host). The host can connect to such a server using the command<br />
<blockquote><br />
socat - TCP:192.168.x.y:80<br />
</blockquote><br />
Both the above type of connections, <tt>guest-to-host</tt> or <tt>host-to-guest</tt><br />
happen over the loopback network interface. <br />
<br />
Suppose you do not want the guest to access services on the host and<br />
vice versa. Then you use <tt>netfilter</tt> to limit connections over<br />
the loopback port. For example,<br />
<blockquote><br />
iptables -I INPUT -d ! 127.0.0.1 -i lo -j DROP<br />
</blockquote><br />
One can restrict specific services by more specific netfilter rules. <br />
For example, we can use<br />
<blockquote><br />
iptables -I INPUT -i lo -p tcp --dport 80 -j ACCEPT<br />
</blockquote><br />
to allow the guest to access the web server on the host and vice<br />
versa.<br />
<br />
'''Warning''': With this configuration the guest will "pollute" the<br />
network neighbourhood with packets whose source address is the given<br />
IP address. So it is best to use netfilter to prevent this with a<br />
configuration like<br />
<blockquote><br />
iptables -I OUTPUT -s 192.168.x.y -d ! lo -j DROP<br />
</blockquote><br />
<br />
== Network-global guest ==<br />
To allow the guest as configured above to have access to the wider<br />
network beyond the host, you can replace the <tt>dummy0</tt><br />
interface with a real one and the private IP address with a "real" IP<br />
address --- assuming such a static adddress is available.<br />
<br />
If your host has a dynamic external IP address and or interface,<br />
then one can instead use <tt>netfilter</tt> to translate the private<br />
address into a real one.<br />
<blockquote><br />
iptables -t nat -A POSTROUTING -o ! lo -j MASQUERADE<br />
</blockquote><br />
This allows the guest to access the internet without polluting the<br />
network neighbourhood with 192.168.x.y addresses.<br />
<br />
----<br />
[[User:Kapil|Kapil Hari Paranjape]] 13:09, 17 September 2007 (CEST)</div>Kapilhttp://linux-vserver.org/RestrictingVserverNetworkingTipsRestrictingVserverNetworkingTips2007-09-17T11:09:24Z<p>Kapil: Added some info on global access</p>
<hr />
<div>= Tips on Restricting Vserver Guest Network Access =<br />
<br />
These tips are being collected here because they seem scattered over<br />
the documentation. (Thanks to Bertl on <tt>#vserver</tt> for these tips).<br />
<br />
Most of the discussion below is based on vserver version 2.2 with<br />
util-vserver version 0.30.212. Newer versions have easier ways to<br />
achieve the same goals.<br />
<br />
Before doing anything else with Vserver Networking you should repeat<br />
the following mantras many times:<br />
# Network routing policy is determined by the routing table on the host.<br />
# The first interface defined in each guest is treated as the address of the loopback interface for the guest. (The Great Flower Page talks about the <tt>lback</tt> configuration; how does that work?)<br />
# The guest can only establishing "listeners" on <tt><IP address>:<port></tt> combinations where <tt><IP address></tt> is an address that is "assigned" to the guest via an interface definition (or a call to <tt>naddress</tt>).<br />
# All guest interfaces are also available to the host.<br />
<br />
== Network-less guest ==<br />
Strictly speaking this is an "interface-less" guest rather than<br />
a network-less one. This is a guest that cannot make network<br />
connections and cannot be reached from the network since it has<br />
''no'' network interfaces.<br />
<br />
On a kernel with newer (>= 2.3?) vserver patches it should be possible to create a guest<br />
with no interfaces by keeping the directory <tt>/etc/vservers/<guest-name>/interfaces/</tt> empty.<br />
<br />
However, this does '''not''' work with Debian etch (util-vserver 0.30.212 and vserver 2.2).<br />
Instead, you get a guest with all host interfaces available for outgoing network connections. At the same time the guest cannot bind a server to these interfaces so one cannot reach the guest from the network.<br />
<br />
To disable ''outgoing'' use of network interfaces under a <br />
kernel with the older (<= 2.2?) vserver patches, you<br />
proceed as follows. You create an interface directory (say<br />
<tt>/etc/vservers/<guest-name>/interfaces/0/</tt>) with the<br />
<tt>nodev</tt> configuration. Be sure to define an <tt>ip</tt> as this<br />
is verified first in <tt>/usr/lib/util-vserver/vserver.functions</tt>;<br />
the value in <tt>ip</tt> can be any IP address that is '''not'''<br />
an IP address of the host. (For example, an address like<br />
<tt>192.168.x.y</tt> or <tt>10.x.y.z</tt> which is chosen at random<br />
will not be a host address with some luck.)<br />
This will result in a non-existent host interface being "assigned" to<br />
the guest and thus "no" interface will be available to the guest.<br />
<br />
== Network-local guest ==<br />
We now describe a configuration that leads to a guest that can (''a priori'')<br />
only connect to the host and can be reached via the network only<br />
from the host.<br />
<br />
Define an interface using <tt>dummy0</tt> as the value of <tt>dev</tt> and an <tt>ip</tt><br />
value like <tt>192.168.x.y</tt> or <tt>10.x.y.z</tt> which is not an existing<br />
external-facing interface address for the host. (You may need to<br />
<tt>modprobe dummy</tt> in order to create such an interface.)<br />
<br />
The guest can now connect to '''any''' service on the host that is<br />
listening for connections to <tt><IP address>:80</tt>; where the IP address<br />
must be the one chosen above or the wildcard <tt>0.0.0.0</tt>. For example,<br />
if the host is running a web server that listens to <tt>0.0.0.0</tt>, then<br />
(in the guest) one can run the command<br />
<blockquote><br />
socat - TCP:192.168.x.y:80<br />
</blockquote><br />
to connect to this server; where as before <tt>192.168.x.y</tt> is the chosen IP address.<br />
On the guest, this command is '''equivalent''' to the command<br />
<blockquote><br />
socat - TCP:127.0.0.1:80<br />
</blockquote><br />
Note that the address 127.0.0.1 '''on the guest''' is '''equivalent''' to the chosen<br />
IP address but '''not''' on the host.<br />
<br />
Similarly, the guest can start servers that listen to<br />
<tt>192.168.x.y:8888</tt> or <tt>0.0.0.0:8888</tt> providing that there is no<br />
server that is already listening to this address (on the guest '''or'''<br />
on the host). The host can connect to such a server using the command<br />
<blockquote><br />
socat - TCP:192.168.x.y:80<br />
</blockquote><br />
Both the above type of connections, <tt>guest-to-host</tt> or <tt>host-to-guest</tt><br />
happen over the loopback network interface. <br />
<br />
Suppose you do not want the guest to access services on the host and<br />
vice versa. Then you use <tt>netfilter</tt> to limit connections over<br />
the loopback port. For example,<br />
<blockquote><br />
iptables -I INPUT -d ! 127.0.0.1 -i lo -j DROP<br />
</blockquote><br />
One can restrict specific services by more specific netfilter rules. <br />
For example, we can use<br />
<blockquote><br />
iptables -I INPUT -i lo -p tcp --dport 80 -j ACCEPT<br />
</blockquote><br />
to allow the guest to access the web server on the host and vice<br />
versa.<br />
<br />
'''Warning''': With this configuration the guest will "pollute" the<br />
network neighbourhood with packets whose source address is the given<br />
IP address. So it is best to use netfilter to prevent this with a<br />
configuration like<br />
<blockquote><br />
iptables -I OUTPUT -s 192.168.x.y -d ! lo -j DROP<br />
</blockquote><br />
<br />
== Network-global guest ==<br />
To allow the guest as configured above to have access to the wider<br />
network beyond the host, you can replace the <tt>dummy0</tt><br />
interface with a real one and the private IP address with a "real" IP<br />
address --- assuming such a static adddress is available.<br />
<br />
If your host has a dynamic external IP address and or interface,<br />
then one can instead use <tt>netfilter</tt> to translate the private<br />
address into a real one.<br />
<blockquote><br />
iptables -t nat -A POSTROUTING -o ! lo -j MASQUERADE<br />
</blockquote><br />
This allows the guest to access the internet without polluting the<br />
network neighbourhood with 192.168.x.y addresses.<br />
<br />
----<br />
[[User:Kapil|Kapil Hari Paranjape]] 13:09, 17 September 2007 (CEST)</div>Kapilhttp://linux-vserver.org/RestrictingVserverNetworkingTipsRestrictingVserverNetworkingTips2007-09-17T10:26:11Z<p>Kapil: VserverNetworkingTips moved to RestrictingVserverNetworkingTips: More appropriate title</p>
<hr />
<div>= Tips on Restricting Vserver Guest Network Access =<br />
<br />
These tips are being collected here because they seem scattered over<br />
the documentation. (Thanks to Bertl on <tt>#vserver</tt> for these tips).<br />
<br />
Before doing anything else with Vserver Networking you should repeat<br />
the following mantras many times:<br />
# Network routing policy is determined by the routing table on the host.<br />
# The first interface defined in each guest is treated as the address of the loopback interface for the guest. (The Great Flower Page talks about the <tt>lback</tt> configuration; how does that work?)<br />
# The guest can only establishing "listeners" on <tt><IP address>:<port></tt> combinations where <tt><IP address></tt> is an address that is "assigned" to the guest via an interface definition (or a call to <tt>naddress</tt>).<br />
# All guest interfaces are also available to the host.<br />
<br />
Most of the discussion below is based on vserver version 2.2 with<br />
util-vserver version 0.30.212. Newer versions have easier ways to<br />
achieve the same goals.<br />
<br />
== Network-less guest ==<br />
Strictly speaking this is an "interface-less" guest rather than<br />
a network-less one. This is a guest that cannot make network<br />
connections and cannot be reached from the network since it has<br />
''no'' network interfaces.<br />
<br />
On a kernel with newer (>= 2.3?) vserver patches it should be possible to create a guest<br />
with no interfaces by keeping the directory <tt>/etc/vservers/<guest-name>/interfaces/</tt> empty.<br />
<br />
However, this does '''not''' work with Debian etch (util-vserver 0.30.212 and vserver 2.2).<br />
Instead, you get a guest with all host interfaces available for outgoing<br />
network connections. At the same time the guest cannot bind a server<br />
to these interfaces so one cannot reach the guest from the network.<br />
<br />
To disable ''outgoing'' use of network interfaces under a <br />
kernel with the older (<= 2.2?) vserver patches, you<br />
proceed as follows. You create an interface directory (say<br />
<tt>/etc/vservers/<guest-name>/interfaces/0/</tt>) with the<br />
<tt>nodev</tt> configuration. Be sure to define an <tt>ip</tt> as this<br />
is verified first in <tt>/usr/lib/util-vserver/vserver.functions</tt>;<br />
the value in <tt>ip</tt> can be any IP address that is '''not'''<br />
an IP address of the host. (For example, an address like<br />
<tt>192.168.x.y</tt> or <tt>10.x.y.z</tt> which is chosen at random<br />
will not be a host address with some luck.)<br />
This will result in a non-existent host interface being "assigned" to<br />
the guest and thus "no" interface will be available to the guest.<br />
<br />
== Network-local guest ==<br />
We now describe a configuration that leads to a guest that can (''a priori'')<br />
only connect to the host and can be reached via the network only<br />
from the host.<br />
<br />
Define an interface using <tt>dummy0</tt> as the value of <tt>dev</tt> and an <tt>ip</tt><br />
value like <tt>192.168.x.y</tt> or <tt>10.x.y.z</tt> which is not an existing<br />
external-facing interface address for the host. (You may need to<br />
<tt>modprobe dummy</tt> in order to create such an interface.)<br />
<br />
The guest can now connect to '''any''' service on the host that is<br />
listening for connections to <tt><IP address>:80</tt>; where the IP address<br />
must be the one chosen above or the wildcard <tt>0.0.0.0</tt>. For example,<br />
if the host is running a web server that listens to <tt>0.0.0.0</tt>, then<br />
(in the guest) one can run the command<br />
<blockquote><br />
socat - TCP:192.168.x.y:80<br />
</blockquote><br />
to connect to this server; where as before <tt>192.168.x.y</tt> is the chosen IP address.<br />
On the guest, this command is '''equivalent''' to the command<br />
<blockquote><br />
socat - TCP:127.0.0.1:80<br />
</blockquote><br />
Note that the address 127.0.0.1 '''on the guest''' is '''equivalent''' to the chosen<br />
IP address but '''not''' on the host.<br />
<br />
Similarly, the guest can start servers that listen to<br />
<tt>192.168.x.y:8888</tt> or <tt>0.0.0.0:8888</tt> providing that there is no<br />
server that is already listening to this address (on the guest '''or'''<br />
on the host). The host can connect to such a server using the command<br />
<blockquote><br />
socat - TCP:192.168.x.y:80<br />
</blockquote><br />
Both the above type of connections, <tt>guest-to-host</tt> or <tt>host-to-guest</tt><br />
happen over the loopback network interface. <br />
<br />
Suppose you do not want the guest to access specific services on the<br />
host. Then you use <tt>iptables</tt> to limit connections over the<br />
loopback port. For example,<br />
<blockquote><br />
iptables -A INPUT -d ! 127.0.0.1 -i lo -j DROP<br />
</blockquote><br />
<br />
----<br />
(To be continued) [[User:Kapil|Kapil]] 12:24, 17 September 2007 (CEST)</div>Kapilhttp://linux-vserver.org/VserverNetworkingTipsVserverNetworkingTips2007-09-17T10:26:11Z<p>Kapil: VserverNetworkingTips moved to RestrictingVserverNetworkingTips: More appropriate title</p>
<hr />
<div>#REDIRECT [[RestrictingVserverNetworkingTips]]</div>Kapilhttp://linux-vserver.org/RestrictingVserverNetworkingTipsRestrictingVserverNetworkingTips2007-09-17T10:24:48Z<p>Kapil: First draft</p>
<hr />
<div>= Tips on Restricting Vserver Guest Network Access =<br />
<br />
These tips are being collected here because they seem scattered over<br />
the documentation. (Thanks to Bertl on <tt>#vserver</tt> for these tips).<br />
<br />
Before doing anything else with Vserver Networking you should repeat<br />
the following mantras many times:<br />
# Network routing policy is determined by the routing table on the host.<br />
# The first interface defined in each guest is treated as the address of the loopback interface for the guest. (The Great Flower Page talks about the <tt>lback</tt> configuration; how does that work?)<br />
# The guest can only establishing "listeners" on <tt><IP address>:<port></tt> combinations where <tt><IP address></tt> is an address that is "assigned" to the guest via an interface definition (or a call to <tt>naddress</tt>).<br />
# All guest interfaces are also available to the host.<br />
<br />
Most of the discussion below is based on vserver version 2.2 with<br />
util-vserver version 0.30.212. Newer versions have easier ways to<br />
achieve the same goals.<br />
<br />
== Network-less guest ==<br />
Strictly speaking this is an "interface-less" guest rather than<br />
a network-less one. This is a guest that cannot make network<br />
connections and cannot be reached from the network since it has<br />
''no'' network interfaces.<br />
<br />
On a kernel with newer (>= 2.3?) vserver patches it should be possible to create a guest<br />
with no interfaces by keeping the directory <tt>/etc/vservers/<guest-name>/interfaces/</tt> empty.<br />
<br />
However, this does '''not''' work with Debian etch (util-vserver 0.30.212 and vserver 2.2).<br />
Instead, you get a guest with all host interfaces available for outgoing<br />
network connections. At the same time the guest cannot bind a server<br />
to these interfaces so one cannot reach the guest from the network.<br />
<br />
To disable ''outgoing'' use of network interfaces under a <br />
kernel with the older (<= 2.2?) vserver patches, you<br />
proceed as follows. You create an interface directory (say<br />
<tt>/etc/vservers/<guest-name>/interfaces/0/</tt>) with the<br />
<tt>nodev</tt> configuration. Be sure to define an <tt>ip</tt> as this<br />
is verified first in <tt>/usr/lib/util-vserver/vserver.functions</tt>;<br />
the value in <tt>ip</tt> can be any IP address that is '''not'''<br />
an IP address of the host. (For example, an address like<br />
<tt>192.168.x.y</tt> or <tt>10.x.y.z</tt> which is chosen at random<br />
will not be a host address with some luck.)<br />
This will result in a non-existent host interface being "assigned" to<br />
the guest and thus "no" interface will be available to the guest.<br />
<br />
== Network-local guest ==<br />
We now describe a configuration that leads to a guest that can (''a priori'')<br />
only connect to the host and can be reached via the network only<br />
from the host.<br />
<br />
Define an interface using <tt>dummy0</tt> as the value of <tt>dev</tt> and an <tt>ip</tt><br />
value like <tt>192.168.x.y</tt> or <tt>10.x.y.z</tt> which is not an existing<br />
external-facing interface address for the host. (You may need to<br />
<tt>modprobe dummy</tt> in order to create such an interface.)<br />
<br />
The guest can now connect to '''any''' service on the host that is<br />
listening for connections to <tt><IP address>:80</tt>; where the IP address<br />
must be the one chosen above or the wildcard <tt>0.0.0.0</tt>. For example,<br />
if the host is running a web server that listens to <tt>0.0.0.0</tt>, then<br />
(in the guest) one can run the command<br />
<blockquote><br />
socat - TCP:192.168.x.y:80<br />
</blockquote><br />
to connect to this server; where as before <tt>192.168.x.y</tt> is the chosen IP address.<br />
On the guest, this command is '''equivalent''' to the command<br />
<blockquote><br />
socat - TCP:127.0.0.1:80<br />
</blockquote><br />
Note that the address 127.0.0.1 '''on the guest''' is '''equivalent''' to the chosen<br />
IP address but '''not''' on the host.<br />
<br />
Similarly, the guest can start servers that listen to<br />
<tt>192.168.x.y:8888</tt> or <tt>0.0.0.0:8888</tt> providing that there is no<br />
server that is already listening to this address (on the guest '''or'''<br />
on the host). The host can connect to such a server using the command<br />
<blockquote><br />
socat - TCP:192.168.x.y:80<br />
</blockquote><br />
Both the above type of connections, <tt>guest-to-host</tt> or <tt>host-to-guest</tt><br />
happen over the loopback network interface. <br />
<br />
Suppose you do not want the guest to access specific services on the<br />
host. Then you use <tt>iptables</tt> to limit connections over the<br />
loopback port. For example,<br />
<blockquote><br />
iptables -A INPUT -d ! 127.0.0.1 -i lo -j DROP<br />
</blockquote><br />
<br />
----<br />
(To be continued) [[User:Kapil|Kapil]] 12:24, 17 September 2007 (CEST)</div>Kapilhttp://linux-vserver.org/Problematic_ProgramsProblematic Programs2007-09-12T09:17:48Z<p>Kapil: /* screen inside a VServer */</p>
<hr />
<div>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).<br />
<br />
<br />
=== OpenGroupware Apache Module ===<br />
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)<br />
<br />
=== Hylafax (with CAPI) ===<br />
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):<pre>cp -aR /dev/capi* /vservers/your_vserver/dev</pre><br />
<br />
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):<pre>cp -aR /dev/null /vservers/your_vserver/var/spool/hylafax/dev</pre> <br />
Allright, now hylafax should have CAPI access and run properly.<br />
<br />
=== Links inside screen inside a V-Server ===<br />
Don't know why, but links crashes systematically being inside a screen session inside a V-Server started outside a V-Server. (please elaborate!) <br />
<br />
=== screen inside a VServer ===<br />
<br />
<pre>[root@ge root]# vserver zoe enter<br />
<br />
zoe:/# screen<br />
Cannot open your terminal '/dev/pts/5' - please check.<br />
<br />
zoe:/# strace screen <br />
...<br />
stat64("/dev/pts/5", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 5), ...}) = 0<br />
open("/dev/pts/5", O_RDWR|O_NONBLOCK) = -1 EACCES (Permission denied)</pre><br />
<br />
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)<br />
<br />
could not spot this problem with vserver (API 2.2 kernel 0.30.0076)<br />
as long as /dev/pts is mounted with the fstab entry <br />
<pre> none /dev/pts devpts gid=5,mode=620 0 0 </pre><br />
please elaborate.<br />
<br />
=== OpenLDAP Startup ===<br />
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. <br />
<br />
=== rndc ===<br />
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.<br />
<br />
=== Asterisk ===<br />
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". <br />
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 line argument to disable the read-time priority. Good doc on setting up Asterisk devices in the vserver: http://www.telephreak.org/papers/vpa/ (additional documentation for Asterisk 1.4 installation available here: https://customer.lylix.net/knowledgebase.php?action=displayarticle&catid=2&id=27)<br />
<br />
=== Open/FreeSwan ===<br />
Fails because of writing to /proc (requires patch) TODO: write me <br />
<br />
=== Samba ===<br />
Oplocks don't work as smbd insists on receiving break requests from 127.0.0.1<br />
Just patch source/smbd/oplock.c (commenting paranoid code)<br />
<pre><br />
+++ oplock.c.orig 2005-02-14 14:27:51.000000000 +0200<br />
--- oplock.c 2005-02-02 12:27:50.000000000 +0200<br />
@@ -181,14 +181,12 @@<br />
return False;<br />
}<br />
<br />
+#if 0<br />
/* Validate message from address (must be localhost). */<br />
if(from.sin_addr.s_addr != htonl(INADDR_LOOPBACK)) {<br />
DEBUG(0,("receive_local_message: invalid 'from' address \<br />
(was %lx should be 127.0.0.1)\n", (long)from.sin_addr.s_addr));<br />
return False;<br />
}<br />
+#endif<br />
<br />
/* Setup the message header */<br />
SIVAL(buffer,OPBRK_CMD_LEN_OFFSET,msg_len);<br />
</pre><br />
or if you don't want to patch the samba source code you can disable oplock in Samba and it will work too!<br />
<br />
Just put the following in your smb.conf:<br />
<pre><br />
kernel oplocks = no<br />
oplocks = no<br />
</pre><br />
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).<br />
<br />
==== Samba from Debian 3.1 ====<br />
<br />
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'<br />
<br />
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.<br />
<br />
==== Samba printer and file server with cups ====<br />
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 !):<br />
<pre><br />
# cat /etc/sysconfig/network<br />
NETWORKING=yes<br />
</pre><br />
Some more tweaking is needeed in ''/etc/smb.conf''<br />
<pre><br />
# cat /etc/smb.conf<br />
...<br />
# YOUR VSERVER IP/MASK HERE<br />
interfaces = xxx.xxx.xxx.xxx/mask<br />
...<br />
</pre><br />
<br />
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 !<br />
<pre><br />
# cat /etc/smb.conf<br />
...<br />
use client driver = no<br />
...<br />
</pre><br />
So, here is a full ''smb.conf'' file: <br />
<pre><br />
# cat /etc/samba/smb.conf | awk '!/^$/ && !/^\s*(#|;)/ {print $0}'<br />
[global]<br />
workgroup = MYDOMAIN<br />
netbios name = MYHOSTNAME<br />
server string = MYCOMMENT (Samba %v)<br />
printcap name = cups<br />
load printers = yes<br />
printing = cups<br />
printer admin = @adm<br />
log file = /var/log/samba/log.%m<br />
max log size = 50<br />
map to guest = bad user<br />
security = domain<br />
password server = *<br />
encrypt passwords = yes<br />
smb passwd file = /etc/samba/smbpasswd<br />
username map = /etc/samba/smbusers<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192<br />
interfaces = 127. MYVSERVERIP/MYVSERVERMASK<br />
wins server = MYWINSIP<br />
dns proxy = no<br />
# for french users:<br />
dos charset = 850<br />
unix charset = ISO8859-1<br />
[homes]<br />
comment = Home Directories<br />
browseable = no<br />
writable = no<br />
[printers]<br />
comment = All Printers<br />
path = /var/spool/samba<br />
browseable = no<br />
guest ok = no<br />
writable = no<br />
printable = yes<br />
create mode = 0700<br />
print command = lpr-cups -P %p -o raw %s -r # using client side printer drivers.<br />
use client driver = no<br />
[print$]<br />
path = /var/lib/samba/printers<br />
browseable = yes<br />
write list = @adm root<br />
guest ok = yes<br />
inherit permissions = yes<br />
</pre><br />
...And a working smbusers:<br />
<pre><br />
# Unix_name = SMB_name1 SMB_name2 ...<br />
root = administrator MYDOMAIN\administrator<br />
nobody = guest pcguest smbguest<br />
</pre><br />
<br />
=== Cups print server ===<br />
Symptoms: The Cups init script exits with:<br />
<pre><br />
Starting CUPS printing system: cupsd: Child exited with status 98!<br />
</pre> <br />
And the logs (''/var/log/cups/error_log'') show:<br />
<pre> <br />
E [date:hour...] StartListening: Unable to bind socket for address 0.0.0.0:631 - Address already in use.<br />
</pre> <br />
...Or something like this. <br />
<br />
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:<br />
<pre> <br />
LogLevel info<br />
TempDir /var/spool/cups/tmp<br />
# No 'Listen' directive !<br />
Port 631<br />
BrowseAddress @LOCAL<br />
BrowseDeny All<br />
BrowseAllow @LOCAL<br />
BrowseOrder deny,allow<br />
<Location /><br />
Order Deny,Allow<br />
Deny From All<br />
Allow From @LOCAL<br />
</Location><br />
<Location /admin><br />
AuthType Basic<br />
AuthClass System<br />
Order Deny,Allow<br />
Deny From All<br />
Allow From YOUR_NETWORK_ADDRESS/YOUR_NETMASK # Example: 172.16.0.0/24<br />
# Or<br />
Allow From @LOCAL<br />
</Location><br />
</pre> <br />
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) ! <br />
<br />
Remember to stop any Cupsd running in the host server, or to start it via a wrapper ''/etc/init.d/v_cups'' script: <br />
<pre> <br />
#!/bin/sh<br />
# chkconfig: 2345 15 60<br />
# description: Wrapper to start cups bound to a single IP<br />
USR_LIB_VSERVER=/usr/lib/util-vserver<br />
exec $USR_LIB_VSERVER/vsysvwrapper cups $*<br />
</pre> <br />
Do not forget to give a password to the root user, if you want to ba able to manage your printers from the web interface (http://yourcupsvserver:631)!<br />
<pre> <br />
# passwd root<br />
...<br />
</pre> <br />
If you use Mandriva 10.1 (And maybe some other distros), you&#8217;ll need to add the printers drivers for Cups, and reload it:<br />
<pre> <br />
# urpmi --root /vservers/yourcupsvserver/ cups-drivers<br />
# /etc/init.d/cups reload<br />
</pre> <br />
&#8230;It added 67 Mb of packages for me. <br />
<br />
Then use ''/etc/init.d/v_cups (re)start'' to launch Cups on the host server. <br />
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...<br />
<br />
=== Bind9 on Debian GNU/Linux Woody (3.0), Sarge (3.1), Etch (4.0) ===<br />
named provided by the bind9 binary packages fails to start because it is compiled with CAPs option. <br />
<br />
The debian way is to build** your own package without CAPs:<br />
<pre><br />
su -<br />
cd /usr/src<br />
apt-get build-dep bind9<br />
apt-get source bind9<br />
cd bind9-x.x.x<br />
vi debian/rules<br />
</pre> <br />
Insert the following line after "./configure --prefix=/usr \":<br />
<pre><br />
--disable-linux-caps \ <br />
</pre> <br />
On a NPTL-enabled system you alse have to replace <br />
<pre> <br />
--enable-threads \<br />
</pre> <br />
with<br />
<pre> <br />
--disable-threads \<br />
</pre> <br />
or bind might refuse to run with an other user than root. <br />
<br />
Save the file and go ahead with compiling/installing: <br />
<pre> <br />
dpkg-buildpackage<br />
dpkg -i ../bind9-x.x.x.deb<br />
echo "bind9 hold" | dpkg --set-selections<br />
</pre> <br />
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! <br />
<br />
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:<br />
<br />
[http://daniel.hozac.com/stuff/bind-9.3.2-caps-when-available.patch bind-9.3.2-caps-when-available.patch]<br />
<br />
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.<br />
<br />
Get my [http://linux-vserver.derjohn.de/bind9-packages/bind9-capacheck_9.3.2-2_i386.deb vserver-guest-ready Debian bind9 package] for Debian Sid guests. Feedback welcome: aj@net-lab.net<br />
<br />
''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.''<br />
<br />
''- 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''<br />
<br />
=== Zimbra Mail ===<br />
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<br />
<br />
=== xine ===<br />
won't start with no error message.<br />
<br />
"xine --verbose" shows this.<br />
<pre> <br />
ERROR: Could not determine network interfaces, you must use a interfaces config line<br />
</pre> <br />
This happens if you have the xineplug_inp_smb.so plugin. Delete it and everything is fine.<br />
<br />
=== 127.0.0.1 issues ===<br />
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 :<br />
<pre> <br />
dev lo <br />
ip 127.0.0.1 <br />
mask 255.0.0.0 <br />
name lo <br />
</pre> <br />
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<br />
<br />
Compiling nagios-1.4 within a vserver requires this, otherwise it hangs during the configure with "checking for ICMP ping syntax..."<br />
<br />
=== Hula-project ===<br />
Does not want to start. TODO: add more information.<br />
<br />
=== Postfix ===<br />
<br />
==== Postfix 2.1.5 (Debian Sarge) ====<br />
On a vserver with two interfaces (lo and eth0), and a postfix 2.1.5 listening on lo, postfix can't send emails : "Invalid argument"... Setting smtp_bind_address (http://www.postfix.org/postconf.5.html#smtp_bind_address) to the external address solves the issue. <br />
<br />
==== Postfix on Debian Etch (for local only mail) ====<br />
<br />
See [[Postfix local only problem]]<br />
<br />
==== Postfix Policy Daemon ====<br />
Running a Debian 3.1 Sarge with Backports I have several issues with the postfix-policyd because it wants to set the rlimits.<br />
<br />
Log returns: <br />
<pre> <br />
cannot set rlimit: Operation not permitted<br />
</pre> <br />
Strace tells us:<br />
<pre> <br />
setrlimit(RLIMIT_NOFILE, {rlim_cur=4097, rlim_max=4097}) = -1 EPERM (Operation not permitted)<br />
</pre> <br />
Output on the Host<br />
<pre> <br />
# ulimit -Ha<br />
...<br />
-n: file descriptors 1024<br />
...<br />
</pre><br />
Thats too little...<br />
<br />
Solution:<br />
<br />
The App has again a build in need to use CAP_SYS_RESOURCE (which is bad (tm)) so in the guest do:<br />
<pre><br />
# ulimit -HS -n 8192<br />
# ulimit -Ha<br />
.. shows us now the correct 8192 instead of 1024.<br />
<br />
# vserver $yourVserverName restart<br />
# vserver $yourVserverName enter<br />
<br />
$yourVserverName # ulimit -Ha<br />
...<br />
-n: file descriptors 8192<br />
...<br />
</pre><br />
Everything should be fine now !<br />
<br />
=== Dhcpd ===<br />
When starting dhcpd you are quite likely to see<br />
<pre><br />
Open a socket for LPF: Operation not permitted<br />
</pre><br />
Dhcpd needs raw network access to work, and to grant your vserver such privileges you need to do:<br />
<pre><br />
# echo NET_RAW >> /etc/vservers/yourvserver/bcapabilities<br />
</pre><br />
And restart your vserver.<br />
Keep in mind that it will lower security because it allows programs to forge packets.<br />
<br />
<br />
=== DB2 ===<br />
DB2 needs at least the following capabilities:<br />
CAP_NET_RAW<br />
CAP_NET_ADMIN<br />
CAP_SYS_ADMIN<br />
CAP_IPC_LOCK<br />
CAP_IPC_OWNER<br />
which will greatly reduce security.</div>Kapilhttp://linux-vserver.org/Problematic_ProgramsProblematic Programs2007-09-12T09:17:04Z<p>Kapil: /* screen inside a VServer */</p>
<hr />
<div>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).<br />
<br />
<br />
=== OpenGroupware Apache Module ===<br />
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)<br />
<br />
=== Hylafax (with CAPI) ===<br />
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):<pre>cp -aR /dev/capi* /vservers/your_vserver/dev</pre><br />
<br />
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):<pre>cp -aR /dev/null /vservers/your_vserver/var/spool/hylafax/dev</pre> <br />
Allright, now hylafax should have CAPI access and run properly.<br />
<br />
=== Links inside screen inside a V-Server ===<br />
Don't know why, but links crashes systematically being inside a screen session inside a V-Server started outside a V-Server. (please elaborate!) <br />
<br />
=== screen inside a VServer ===<br />
<br />
<pre>[root@ge root]# vserver zoe enter<br />
<br />
zoe:/# screen<br />
Cannot open your terminal '/dev/pts/5' - please check.<br />
<br />
zoe:/# strace screen <br />
...<br />
stat64("/dev/pts/5", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 5), ...}) = 0<br />
open("/dev/pts/5", O_RDWR|O_NONBLOCK) = -1 EACCES (Permission denied)</pre><br />
<br />
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)<br />
<br />
(could not spot this problem with vserver (API 2.2 kernel 0.30.0076)<br />
as long as /dev/pts is mounted with the fstab entry <br />
<PRE> none /dev/pts devpts gid=5,mode=620 0 0<br />
please elaborate.)<br />
<br />
=== OpenLDAP Startup ===<br />
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. <br />
<br />
=== rndc ===<br />
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. <br />
<br />
=== Asterisk ===<br />
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". <br />
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 line argument to disable the read-time priority. Good doc on setting up Asterisk devices in the vserver: http://www.telephreak.org/papers/vpa/ (additional documentation for Asterisk 1.4 installation available here: https://customer.lylix.net/knowledgebase.php?action=displayarticle&catid=2&id=27)<br />
<br />
=== Open/FreeSwan ===<br />
Fails because of writing to /proc (requires patch) TODO: write me <br />
<br />
=== Samba ===<br />
Oplocks don't work as smbd insists on receiving break requests from 127.0.0.1<br />
Just patch source/smbd/oplock.c (commenting paranoid code)<br />
<pre><br />
+++ oplock.c.orig 2005-02-14 14:27:51.000000000 +0200<br />
--- oplock.c 2005-02-02 12:27:50.000000000 +0200<br />
@@ -181,14 +181,12 @@<br />
return False;<br />
}<br />
<br />
+#if 0<br />
/* Validate message from address (must be localhost). */<br />
if(from.sin_addr.s_addr != htonl(INADDR_LOOPBACK)) {<br />
DEBUG(0,("receive_local_message: invalid 'from' address \<br />
(was %lx should be 127.0.0.1)\n", (long)from.sin_addr.s_addr));<br />
return False;<br />
}<br />
+#endif<br />
<br />
/* Setup the message header */<br />
SIVAL(buffer,OPBRK_CMD_LEN_OFFSET,msg_len);<br />
</pre><br />
or if you don't want to patch the samba source code you can disable oplock in Samba and it will work too!<br />
<br />
Just put the following in your smb.conf:<br />
<pre><br />
kernel oplocks = no<br />
oplocks = no<br />
</pre><br />
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).<br />
<br />
==== Samba from Debian 3.1 ====<br />
<br />
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'<br />
<br />
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.<br />
<br />
==== Samba printer and file server with cups ====<br />
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 !):<br />
<pre><br />
# cat /etc/sysconfig/network<br />
NETWORKING=yes<br />
</pre><br />
Some more tweaking is needeed in ''/etc/smb.conf''<br />
<pre><br />
# cat /etc/smb.conf<br />
...<br />
# YOUR VSERVER IP/MASK HERE<br />
interfaces = xxx.xxx.xxx.xxx/mask<br />
...<br />
</pre><br />
<br />
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 !<br />
<pre><br />
# cat /etc/smb.conf<br />
...<br />
use client driver = no<br />
...<br />
</pre><br />
So, here is a full ''smb.conf'' file: <br />
<pre><br />
# cat /etc/samba/smb.conf | awk '!/^$/ && !/^\s*(#|;)/ {print $0}'<br />
[global]<br />
workgroup = MYDOMAIN<br />
netbios name = MYHOSTNAME<br />
server string = MYCOMMENT (Samba %v)<br />
printcap name = cups<br />
load printers = yes<br />
printing = cups<br />
printer admin = @adm<br />
log file = /var/log/samba/log.%m<br />
max log size = 50<br />
map to guest = bad user<br />
security = domain<br />
password server = *<br />
encrypt passwords = yes<br />
smb passwd file = /etc/samba/smbpasswd<br />
username map = /etc/samba/smbusers<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192<br />
interfaces = 127. MYVSERVERIP/MYVSERVERMASK<br />
wins server = MYWINSIP<br />
dns proxy = no<br />
# for french users:<br />
dos charset = 850<br />
unix charset = ISO8859-1<br />
[homes]<br />
comment = Home Directories<br />
browseable = no<br />
writable = no<br />
[printers]<br />
comment = All Printers<br />
path = /var/spool/samba<br />
browseable = no<br />
guest ok = no<br />
writable = no<br />
printable = yes<br />
create mode = 0700<br />
print command = lpr-cups -P %p -o raw %s -r # using client side printer drivers.<br />
use client driver = no<br />
[print$]<br />
path = /var/lib/samba/printers<br />
browseable = yes<br />
write list = @adm root<br />
guest ok = yes<br />
inherit permissions = yes<br />
</pre><br />
...And a working smbusers:<br />
<pre><br />
# Unix_name = SMB_name1 SMB_name2 ...<br />
root = administrator MYDOMAIN\administrator<br />
nobody = guest pcguest smbguest<br />
</pre><br />
<br />
=== Cups print server ===<br />
Symptoms: The Cups init script exits with:<br />
<pre><br />
Starting CUPS printing system: cupsd: Child exited with status 98!<br />
</pre> <br />
And the logs (''/var/log/cups/error_log'') show:<br />
<pre> <br />
E [date:hour...] StartListening: Unable to bind socket for address 0.0.0.0:631 - Address already in use.<br />
</pre> <br />
...Or something like this. <br />
<br />
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:<br />
<pre> <br />
LogLevel info<br />
TempDir /var/spool/cups/tmp<br />
# No 'Listen' directive !<br />
Port 631<br />
BrowseAddress @LOCAL<br />
BrowseDeny All<br />
BrowseAllow @LOCAL<br />
BrowseOrder deny,allow<br />
<Location /><br />
Order Deny,Allow<br />
Deny From All<br />
Allow From @LOCAL<br />
</Location><br />
<Location /admin><br />
AuthType Basic<br />
AuthClass System<br />
Order Deny,Allow<br />
Deny From All<br />
Allow From YOUR_NETWORK_ADDRESS/YOUR_NETMASK # Example: 172.16.0.0/24<br />
# Or<br />
Allow From @LOCAL<br />
</Location><br />
</pre> <br />
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) ! <br />
<br />
Remember to stop any Cupsd running in the host server, or to start it via a wrapper ''/etc/init.d/v_cups'' script: <br />
<pre> <br />
#!/bin/sh<br />
# chkconfig: 2345 15 60<br />
# description: Wrapper to start cups bound to a single IP<br />
USR_LIB_VSERVER=/usr/lib/util-vserver<br />
exec $USR_LIB_VSERVER/vsysvwrapper cups $*<br />
</pre> <br />
Do not forget to give a password to the root user, if you want to ba able to manage your printers from the web interface (http://yourcupsvserver:631)!<br />
<pre> <br />
# passwd root<br />
...<br />
</pre> <br />
If you use Mandriva 10.1 (And maybe some other distros), you&#8217;ll need to add the printers drivers for Cups, and reload it:<br />
<pre> <br />
# urpmi --root /vservers/yourcupsvserver/ cups-drivers<br />
# /etc/init.d/cups reload<br />
</pre> <br />
&#8230;It added 67 Mb of packages for me. <br />
<br />
Then use ''/etc/init.d/v_cups (re)start'' to launch Cups on the host server. <br />
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...<br />
<br />
=== Bind9 on Debian GNU/Linux Woody (3.0), Sarge (3.1), Etch (4.0) ===<br />
named provided by the bind9 binary packages fails to start because it is compiled with CAPs option. <br />
<br />
The debian way is to build** your own package without CAPs:<br />
<pre><br />
su -<br />
cd /usr/src<br />
apt-get build-dep bind9<br />
apt-get source bind9<br />
cd bind9-x.x.x<br />
vi debian/rules<br />
</pre> <br />
Insert the following line after "./configure --prefix=/usr \":<br />
<pre><br />
--disable-linux-caps \ <br />
</pre> <br />
On a NPTL-enabled system you alse have to replace <br />
<pre> <br />
--enable-threads \<br />
</pre> <br />
with<br />
<pre> <br />
--disable-threads \<br />
</pre> <br />
or bind might refuse to run with an other user than root. <br />
<br />
Save the file and go ahead with compiling/installing: <br />
<pre> <br />
dpkg-buildpackage<br />
dpkg -i ../bind9-x.x.x.deb<br />
echo "bind9 hold" | dpkg --set-selections<br />
</pre> <br />
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! <br />
<br />
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:<br />
<br />
[http://daniel.hozac.com/stuff/bind-9.3.2-caps-when-available.patch bind-9.3.2-caps-when-available.patch]<br />
<br />
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.<br />
<br />
Get my [http://linux-vserver.derjohn.de/bind9-packages/bind9-capacheck_9.3.2-2_i386.deb vserver-guest-ready Debian bind9 package] for Debian Sid guests. Feedback welcome: aj@net-lab.net<br />
<br />
''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.''<br />
<br />
''- 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''<br />
<br />
=== Zimbra Mail ===<br />
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<br />
<br />
=== xine ===<br />
won't start with no error message.<br />
<br />
"xine --verbose" shows this.<br />
<pre> <br />
ERROR: Could not determine network interfaces, you must use a interfaces config line<br />
</pre> <br />
This happens if you have the xineplug_inp_smb.so plugin. Delete it and everything is fine.<br />
<br />
=== 127.0.0.1 issues ===<br />
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 :<br />
<pre> <br />
dev lo <br />
ip 127.0.0.1 <br />
mask 255.0.0.0 <br />
name lo <br />
</pre> <br />
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<br />
<br />
Compiling nagios-1.4 within a vserver requires this, otherwise it hangs during the configure with "checking for ICMP ping syntax..."<br />
<br />
=== Hula-project ===<br />
Does not want to start. TODO: add more information.<br />
<br />
=== Postfix ===<br />
<br />
==== Postfix 2.1.5 (Debian Sarge) ====<br />
On a vserver with two interfaces (lo and eth0), and a postfix 2.1.5 listening on lo, postfix can't send emails : "Invalid argument"... Setting smtp_bind_address (http://www.postfix.org/postconf.5.html#smtp_bind_address) to the external address solves the issue. <br />
<br />
==== Postfix on Debian Etch (for local only mail) ====<br />
<br />
See [[Postfix local only problem]]<br />
<br />
==== Postfix Policy Daemon ====<br />
Running a Debian 3.1 Sarge with Backports I have several issues with the postfix-policyd because it wants to set the rlimits.<br />
<br />
Log returns: <br />
<pre> <br />
cannot set rlimit: Operation not permitted<br />
</pre> <br />
Strace tells us:<br />
<pre> <br />
setrlimit(RLIMIT_NOFILE, {rlim_cur=4097, rlim_max=4097}) = -1 EPERM (Operation not permitted)<br />
</pre> <br />
Output on the Host<br />
<pre> <br />
# ulimit -Ha<br />
...<br />
-n: file descriptors 1024<br />
...<br />
</pre><br />
Thats too little...<br />
<br />
Solution:<br />
<br />
The App has again a build in need to use CAP_SYS_RESOURCE (which is bad (tm)) so in the guest do:<br />
<pre><br />
# ulimit -HS -n 8192<br />
# ulimit -Ha<br />
.. shows us now the correct 8192 instead of 1024.<br />
<br />
# vserver $yourVserverName restart<br />
# vserver $yourVserverName enter<br />
<br />
$yourVserverName # ulimit -Ha<br />
...<br />
-n: file descriptors 8192<br />
...<br />
</pre><br />
Everything should be fine now !<br />
<br />
=== Dhcpd ===<br />
When starting dhcpd you are quite likely to see<br />
<pre><br />
Open a socket for LPF: Operation not permitted<br />
</pre><br />
Dhcpd needs raw network access to work, and to grant your vserver such privileges you need to do:<br />
<pre><br />
# echo NET_RAW >> /etc/vservers/yourvserver/bcapabilities<br />
</pre><br />
And restart your vserver.<br />
Keep in mind that it will lower security because it allows programs to forge packets.<br />
<br />
<br />
=== DB2 ===<br />
DB2 needs at least the following capabilities:<br />
CAP_NET_RAW<br />
CAP_NET_ADMIN<br />
CAP_SYS_ADMIN<br />
CAP_IPC_LOCK<br />
CAP_IPC_OWNER<br />
which will greatly reduce security.</div>Kapil