Editing
Paper
(section)
From Linix VServer
Jump to navigation
Jump to search
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
== Additional Modifications == In addition to the bare minimum, there are a number of modifications that are not mandatory, but have proven extremely useful over time. === Context Flags === It was very soon discovered that some features require a flag, a kind of switch to turn them on and off separately for each Linux-VServer, so a simple flag-word was added. This flag-word supports quite a number of flags, a flag-word mask, which allows to tell what flags are available, and a special trigger mechanism, providing one-time flags, set on startup, that can only be cleared once, usually causing a special action or event. Here is a list of planned and mostly implemented Context Flags, available in the development branch of Linux-VServer: {| class="wikitablenowrap" ! [0] VXF_INFO_LOCK | (legacy, obsoleted) |- ! [1] VXF_INFO_SCHED | schedule all processes in a context as if they where one. (legacy, obsoleted) |- ! [2] VXF_INFO_NPROC | limit the number of processes in a context to the initial NPROC value. (legacy, obsoleted) |- ! [3] VXF_INFO_PRIVATE | do not allow to join this context from outside. (legacy) |- ! [4] VXF_INFO_INIT | show the init process with pid '1' (legacy) |- ! [5] VXF_INFO_HIDE | (legacy, obsoleted) |- ! [6] VXF_INFO_ULIMIT | (legacy, obsoleted) |- ! [7] VXF_INFO_NSPACE | (legacy, obsoleted) |- ! [8] VXF_SCHED_HARD | activate the Hard CPU scheduling |- ! [9] VXF_SCHED_PRIO | use the context token bucket for calculating the process priorities |- ! [10] VXF_SCHED_PAUSE | put all processes in this context on the hold queue, not scheduling them any longer |- ! [16] VXF_VIRT_MEM | virtualize the memory information so that the VM and RSS limits are used for meminfo and friends |- ! [17] VXF_VIRT_UPTIME | virtualize the uptime, beginning with the time of context creation |- ! [18] VXF_VIRT_CPU | |- ! [24] VXF_HIDE_MOUNT | show empty proc/{pid}/mounts |- ! [25] VXF_HIDE_NETIF | hide network interfaces and addresses not permitted by the network context |} === Context Capabilities === As the Linux Capabilities have almost reached the maximum number that is possible without heavy modifications to the kernel, it was a natural step to add a context-specific capability system. The Linux-VServer context capability set acts as a mechanism to fine tune existing Linux capabilities. It is not visible to the processes within a context, as they would not know how to modify or verify it. In general there are two ways to use those capabilities: * Require one or a number of context capabilities to be set in addition to a given Linux capability, each one controlling a distinct part of the functionality.For example the CAP_NET_ADMIN could be split into RAW and PACKET sockets, so you could take away each of them separately by not providing the required context capability. * Consider the context capability sufficient for a specified functionality, even if the Linux Capability says something different.For example mount() requires CAP_SYS_ADMIN which adds a dozen other things we do not want, so we define a CCAP_MOUNT to allow mounts for certain contexts. The difference between the Context Flags and the Context Caps is more an abstract logical separation than a functional one, because they are handled very similarly. Again, a list of the Context Capabilities and their purpose: {| class="wikitablenowrap" ! [0] VXC_SET_UTSNAME | allow the context to change the host and domain name with the appropriate kernel Syscall |- ! [1] VXC_SET_RLIMIT | allow the context to modify the resource limits (within the vserver limits). |- ! [8] VXC_RAW_ICMP | allow raw icmp packets in a secure way (this makes ping work from inside) |- ! [16] VXC_SECURE_MOUNT | permit secure mounts, which at the moment means that the nodev mount option is added. |} === Context Accounting === Some properties of a context are useful to the admin, either for keeping an overview of the resources, to get a feeling for the capacity of the host, or for billing them in some way to a customer. There are two different kinds of accountable properties, those having a current value which represents the state of the system (for example the speed of a vehicle), and those which monotonically increase over time (like the mileage). Most of the state type of properties also qualify for applying some limits, so they are handled specially. this is described in more detail in the following section. Good candidates for Context Accounting are: * Amount of CPU Time spent * Number of Forks done * Socket Messages by Type * Network Packets Transmitted and Received === Context Limits === Most properties related to system resources, might it be the memory consumption, the number of processes or file-handles, or the current network bandwidth, qualify for imposing limits on them. To provide a general framework for all kinds of limits, Context Limits allow the configuration of three different values for each limit-able resource: the minimum, a soft limit and a hard limit (maximum). At the time this is written, only the hard limits are supported and not all of them are actually enforced, but here is a list of current and planned Context Limits: * process limits * scheduler limits * memory limits * per-context disk limits * per-context user/group quota Additionally the context limit system keeps track of observed maxima and resource limit hits, to provide some feedback for the administrator. === Virtualization === One major difference between the Linux-VServer approach and Virtual Machines is that you do not have the virtualization part as a side-effect, so you have to do that by hand where it makes sense. For example, a Virtual Machine does not need to think about uptime, because naturally the running OS was started somewhere in the past and will not have any problem to tell the time it thinks it began running. A context can also store the time when it was created, but that will be different from the systems uptime, so in addition, there has to be some function, which adjusts the values passed from kernel to user-space depending on the context the process belongs to. This is what for Linux-VServer is known as Virtualization (actually it's more faking some values passed to and from the kernel to make the processes think that they are on a different machine). Currently modified for the purpose of Virtualization are: * System Uptime * Host and Domain Name * Machine Type and Kernel Version * Context Memory Availability * Context Disk Space === Improved Security === Proc-FS Security provides a mechanism to protect dynamic entries in the proc filesystem from being seen in every context. The system consists of three flags for each Proc-FS entry: Admin, Watch and Hide. The Hide flag enables or disables the entire feature, so any combination with the Hide flag cleared will mean total visibility. The Admin and Watch flags determine where the hidden entry remains visible; so for example if Admin and Hidden are set, the Host Context will be the only one able to see this specific entry. === Kernel Helper === For some purposes, it makes sense to have an user-space tool to act on behalf of the kernel, when a process inside a context requests something usually available on a real server, but naturally not available inside a context. The best, and currently only example for this is the Reboot Helper, which handles the reboot() system call, invoked from inside a context on behalf of the Kernel. It is executed, in Host side user-space to take appropriate actions - either reboot or just shutdown (halt) the specified context. While the helper is designed to be flexible and handle different things in a similar way there are no other users of this helper at the moment. It might be replaced by an event interface in near future.
Summary:
Please note that all contributions to Linix VServer may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see
Linix VServer:Copyrights
for details).
Do not submit copyrighted work without permission!
Cancel
Editing help
(opens in new window)
Navigation menu
Page actions
Page
Discussion
Read
Edit
History
Page actions
Page
Discussion
More
Tools
Personal tools
Not logged in
Talk
Contributions
Create account
Log in
About
Overview
Paper
News
Developers
Donations
Search
Getting Started
Downloads
FAQs
Documentation
Support
Participate
How to participate
Report a Bug
Communicate
Teams/Projects
Hall of Fame
Resources
Archives
Recent Wiki Changes
Pastebin
Related Projects
VServer Hosting
Happy VServer Users
Tools
What links here
Related changes
Special pages
Page information