Table of Contents
Copyright (c) 2005 RAD GNU/Linux project, Peter V. Saveliev.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license can be found on the project homepage and on the GNU site.
Author acknowledges these people:
And all the people from the RAD GNU/Linux maillists for their significant help in testing. Thank you.
This document describes a common security model implemented in RAD GNU/Linux and how it can be used for a virtual hosting or to running additional services. Further information about virtual contexts can be found on the VServer project site
One of key tasks of a system administrator is to achieve stable work of the operated system. But this cannot be done without a reliable mechanism of resource management. For instance, when a web application blocks the system by eating all memory, frequently there is no way out but hardware reset. In this case neither blocking application, nor terminal access from which the sysadmin could be able to terminate such application, doesn't work. There are two separate aspects in the situation described. One is to improve the poor application, but this aspect is beyond the scope of this HOWTO. The second way is to provide a managed service with guaranteed resource limits.
RAD GNU/Linux uses VServer to control system resources. In every case, each
service ... produces new virtual
private context to run a defined service. Such contexts
are completely isolated from each other. This means that processes
from one context don't "see" processes from other as if they are running
on separate machines. Moreover, each context, although running on
the same filesystem the other contexts do, has its own union with
this filesystem. So, file changes done in one context don't affect
all other contexts. This is implemented using UnionFS
Beside of memory usage limit and process space and filesystem namespace division, VServer secures each context with processor usage limit and provides a way to limit IP addresses visible to the context. All these features are listed in the example below.
Example 1. Configuration: resource limits for a service
! service pptp ! ! bind resource-list, see comments in the ! section below. Cause of "address" directives ! in the resource-list, one may omit "address" ! directive here resource-list test ! ! use the scheme with ARP proxying, providing ! IP addresses from the same range the LAN uses remote 10.0.0.128-254,192.168.0.128-254 option proxyarp ! ! use MPPE/MPPC and local athorization via MS ! CHAP v2 option require-mschap-v2 option mppe required ! ! only 5 concurrent sessions allowed session-limit 5 ! resource-list test ! ! bind context to these addresses only address 10.0.0.1/24 address 192.168.0.1/24 ! ! beside of "session-limit", use the system ! mechanisms to guarantee memory consumption limit data 20480 limit rss 1024 ! ! set hard scheduler with CPU utilization ! not more than 2% for the context scheduler hard 2% !
There are two mechanisms to set a priority for CPU utilization, with
prio scheduler. The latter defines relative CPU limits,
allowing a service to use CPU over limit in the case that there are no other
hard scheduler doesn't allow overlimits and locks
a context within defined boundaries.
The scheme described above allows reliable control over any RAD GNU/Linux service and can guarantee that there will be no downtime caused by a resource shortage. The destitute service won't be able to run more properly even with resource management, but in RAD GNU/Linux it will not cause the whole sytem to hang.
Despite the fact that RAD GNU/Linux' primary goal is to provide a flexible and
reliable gateway solution, VServer resource management allows to use it as
a hosting platform. RAD GNU/Linux is able to run so called "virtual servers",
process trees that run in separate root filesystems and look each as
dedicated GNU/Linux server. With the same
option each virtual server can be limited in memory, CPU and IP address
Example 2. Configuration: virtual servers
! ! shared resource-list for hosting ! resource-list hosting limit data 64000 limit rss 10000 scheduler hard 6% ! ! virtual-specific bindings ! resource-list test0 address 10.0.0.4/24 ! resource-list test1 address 10.0.0.5/24 ! virtual test0 size 512M resource-list hosting resource-list test0 ! virtual test1 size 1G resource-list hosting resource-list test1 !
virtual server runs on its own virtual
partition (also called "logical volume") that resides on a common disk
storage. The size of the partition is defined in the configuration and it
can be resized to satisfy client's requirements. The partition size
changes, done in the configuration, will take place the next time the
To install a new
virtual, one has to define it in
the configuration first. After the new section is defined,
one can use install virtual from ...
command to download a skeleton system and install it onto
newly created virtual partition.
Example 3. Virtual server installation process
Define the virtual:
radlinux$ configure editor
... ! virtual test size 300M ! ...
radlinux$ configure commit
committed: initiated: virtual test rt-network: root: Committed
Install it from a remote location:
radlinux$ install virtual name test from ftp://...
New security context is 49157
Check if it is running:
radlinux$ show xid running
CTX PROC VSZ UPTIME NAME 0 34 87M 8m14s32 root server 49154 1 1.9M <skip/> 7m01s82 syslog-default 49155 5 43.9M 7m01s90 netflow-default 49157 1 1.4M 5m02s60 test ^^^^^ ^^^^
Check LVM partitions:
radlinux$ exec lvm
lvm> lvs LV VG Attr LSize ... system.backup system -wi-ao 128.00M test system -wi-ao 300.00M ^^^^ ^^^^^^^
Frequently there is a necessity to manage disk quotas within a virtual server. It can take place, for instance, when running standard Apache+MySQL+PHP+FTP virtual hosting inside a virtual server. Virtual server has no permissions to access quota information, therefore, the only way to do it is to use RAD GNU/Linux' shell.
Edit disk quotas for
group ... in
One has to use numeric UIDs and GIDs unless the virtual has
Show installed quotas for
virtual ... or
for all running virtual servers, if
option is omitted.
Example 4. Output of the "show disk quota" command
*** Report for user quotas on device /dev/system/test Block grace time: 7days; Inode grace time: 7days Block limits File limits User used soft hard grace used soft hard grace ---------------------------------------------------------------------- #0 -- 34697 0 0 21021 0 0 #500 -- 5000 0 5000 3 0 128
Example 5. Output of the "show disk quota for groups" command
*** Report for group quotas on device /dev/system/test Block grace time: 7days; Inode grace time: 7days Block limits File limits Group used soft hard grace used soft hard grace ---------------------------------------------------------------------- #0 -- 34697 0 0 21021 0 0 #500 -- 5000 0 10000 3 0 0
The way a virtual server stats up is slightly different from a real system does. The virtual server has no access to physical devices such as harddisks or network interface cards. It can not mount or umount partitions, can not set ip addresses or routing. The virtual server even has no permission to set a hostname.
All these restrictions are implied by VServer's "safe" security context mode and affect on a startup and shutdown processes. Moreover, normal init(8) program can not work in virtual environment at all. Cause of this, RAD GNU/Linux uses its own simple init(8) which reads inittab(5) of the virtual server.
RAD GNU/Linux' virtual init(8) supports limited
set of inittab(5) tokens. These tokens are
sysinit and runlevel
l0..6). All other tokens are ignored
during virtual server initialization.
Example 6. Virtual server's inittab format
# /etc/inittab: init(8) configuration. # The default runlevel. id:3:initdefault: # Boot-time system configuration/initialization script. # This is run first except when booting in emergency (-b) mode. si::sysinit:/etc/rc.d/scripts/cleanup # /etc/rc.d/rc executes the S and K scripts upon change of runlevel. # # Runlevel 0 is halt. # Runlevel 1 is single-user. # Runlevels 2-5 are multi-user. # Runlevel 6 is reboot. l0:0:wait:/etc/rc.d/rc 0 l1:1:wait:/etc/rc.d/rc 1 l2:2:wait:/etc/rc.d/rc 2 l3:3:wait:/etc/rc.d/rc 3 l4:4:wait:/etc/rc.d/rc 4 l5:5:wait:/etc/rc.d/rc 5 l6:6:wait:/etc/rc.d/rc 6
Note that in the
sysinit line is not rc.sysinit
but cleanup script, because rc.sysinit fails
to start in the virtual environment and tries to run single mode. It is not
that one can expect from the virtual server's startup.
If such behavior is unwelcome, one can specify an init command by using
init option in the config. By the same way a default shell
can be specified by
shell option. This shell will be used
in the virtual command.
Other shell commands that can be useful in the virtual server's maintenance:
Show processes running within a virtual server. If no xid is specified, show processes for all contexts, including the system ones.
Enter the virtual server. One has to define virtual server's name, e.g. virtual test