RAD GNU/Linux private contexts and virtual hosting HOWTO


Table of Contents

RAD GNU/Linux private contexts and virtual hosting HOWTO
License
Thanks
Introduction
Resource management
Virtual hosting with RAD GNU/Linux
Virtual server installation
Disk quota management
Inittab and custom startup and shell programs
Related shell commands

RAD GNU/Linux private contexts and virtual hosting HOWTO

License

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[1] and on the GNU site[2].

Thanks

Author acknowledges these people:

  • Lidia V. Starostina - documentation proofreading

And all the people from the RAD GNU/Linux maillists for their significant help in testing. Thank you.

Introduction

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[3]

Resource management

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 section 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[4]

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 hard and prio scheduler. The latter defines relative CPU limits, allowing a service to use CPU over limit in the case that there are no other tasks. The 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.

Virtual hosting with RAD GNU/Linux

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 resource-list option each virtual server can be limited in memory, CPU and IP address usage.

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 installation

Each 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 virtual restarts.

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

Disk quota management

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.

disk quota

Edit disk quotas for user ... or group ... in virtual .... One has to use numeric UIDs and GIDs unless the virtual has getent(1) command.

show disk quota

Show installed quotas for virtual ... or for all running virtual servers, if virtual ... 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       
			

Inittab and custom startup and shell programs

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 initdefault, sysinit and runlevel definitions (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.

Example 7. Configuration: custom init and shell for a virtual

!
virtual test
	size 1G
	init /usr/local/sbin/my_init
	shell /bin/pdksh
!
			

Related shell commands

Other shell commands that can be useful in the virtual server's maintenance:

show xid processes

Show processes running within a virtual server. If no xid is specified, show processes for all contexts, including the system ones.

virtual

Enter the virtual server. One has to define virtual server's name, e.g. virtual test