intro.txt (65183B)
1 2 1. [1]Introduction [new.gif] 3 1.1 [2]Who needs that [new.gif] 4 2. [3]Principles [new.gif] 5 2.1 [4]Non reversible isolation [new.gif] 6 2.2 [5]Isolation areas [new.gif] 7 2.3 [6]New system calls [new.gif] 8 2.4 [7]Limiting super-user: The capabilities system [new.gif] 9 2.5 [8]Enhancing the capability system [new.gif] 10 2.6 [9]Playing with the new system calls [new.gif] 11 2.6.1 [10]Playing with /usr/sbin/chcontext [new.gif] 12 2.6.2 [11]Playing with /usr/sbin/chcontext as root [new.gif] 13 2.6.3 [12]Playing with /usr/sbin/chbind [new.gif] 14 2.6.4 [13]Playing with /usr/sbin/reducecap [new.gif] 15 2.7 [14]Unification [new.gif] 16 3. [15]Applications [new.gif] 17 3.1 [16]Virtual server [new.gif] 18 3.2 [17]Per user fire-wall [new.gif] 19 3.3 [18]Secure server/Intrusion detection [new.gif] 20 3.4 [19]Fail over servers [new.gif] 21 4. [20]Installation [new.gif] 22 4.1 [21]The packages [new.gif] 23 4.2 [22]Setting a virtual server [new.gif] 24 4.3 [23]Basic configuration of the virtual server [new.gif] 25 4.4 [24]Entering the virtual server [new.gif] 26 4.5 [25]Configuring the services [new.gif] 27 4.6 [26]Starting/Stopping the virtual server [new.gif] 28 4.7 [27]Starting/Stopping all the virtual servers [new.gif] 29 4.8 [28]Restarting a virtual server from inside [new.gif] 30 4.9 [29]Executing tasks at vserver start/stop time [new.gif] 31 4.10 [30]Issues [new.gif] 32 4.11 [31]How real is it ? [new.gif] 33 5. [32]Features [new.gif] 34 6. [33]Future directions [new.gif] 35 6.1 [34]User controlled security box [new.gif] 36 6.2 [35]Kernel enhancements [new.gif] 37 6.2.1 [36]Per context disk quota [new.gif] 38 6.2.2 [37]Global limits [new.gif] 39 6.2.3 [38]Scheduler [new.gif] 40 6.2.4 [39]Security issues [new.gif] 41 6.2.4.1 [40]/dev/random [new.gif] 42 6.2.4.2 [41]/dev/pts [new.gif] 43 6.2.4.3 [42]Network devices [new.gif] 44 7. [43]Alternative technologies [new.gif] 45 7.1 [44]Virtual machines [new.gif] 46 7.2 [45]Partitioning [new.gif] 47 7.3 [46]Limitation of those technologies [new.gif] 48 8. [47]Conclusion [new.gif] 49 9. [48]Download [new.gif] 50 10. [49]References [new.gif] 51 52 Virtual private servers and security contexts 53 54 Running independent Linux servers inside a single PC is now possible. 55 They offer many advantages, including higher security, flexibility and 56 cost reduction. 57 58 NEW 59 60 Introduction 61 62 Linux computers are getting faster every day. So we should probably 63 end up with less, more powerful servers. Instead we are seeing more 64 and more servers. While there are many reasons for this trend (more 65 services offered), the major issue is more related to security and 66 administrative concerns. 67 68 Is it possible to split a Linux server into virtual ones with as much 69 isolation as possible between each one, looking like real servers, yet 70 sharing some common tasks (monitoring, backup, ups, hardware 71 configuration, ...) ? 72 73 We think so ... NEW 74 75 Who needs that 76 77 The short answer is everybody, or everybody managing a server. Here 78 are some applications: 79 80 * Hosting: Complete general purpose hosting (Running many 81 independent servers in one box). 82 * Experimentation: You are toying with a new services and do not 83 want to impact the production services on the same machine. 84 * Education: Each student has its own server with root password. 85 * Personal security box: Run un-trusted applications with complete 86 control over their interaction with the rest of the computer and 87 the network. 88 * Managing several "versions" of the same server/project and turning 89 on/off each version independantly. 90 91 Just think about all the viruses and worms out there, you end up with 92 a big everybody using a computer needs this. :-) NEW 93 94 Principles 95 96 NEW 97 98 Non reversible isolation 99 100 Unix and Linux have always had the chroot() system call. This call was 101 used to trap a process into a sub-directory. After the system-call, 102 the process is led to believe that the sub-directory is now the root 103 directory. This system call can't be reversed. In fact, the only thing 104 a process can do is trap itself further and further in the file-system 105 (calling chroot() again). 106 107 The strategy is to introduce new system calls trapping the processes 108 in other areas within the server. NEW 109 110 Isolation areas 111 112 A virtual server is isolated from the rest of the server in 5 areas: 113 114 * File system 115 The vserver is trapped into a sub-directory of the main server and 116 can't escape. This is done by the standard chroot() system call 117 found on all Unix and Linux boxes. 118 * Processes 119 The vserver can only see the processes in the same security 120 context. Even the root server can't see the processes in vservers, 121 making the root server less "dangerous" to use. A special 122 mechanism (context number 1) exists to view all processes though 123 (Limited to root in the root server). 124 * Networking 125 The vserver is assigned a host name and an IP number. The server 126 can only use this IP number to establish services and client 127 connection. Further, this restriction is transparent. 128 * Super user capabilities 129 The super user running in a vserver has less privileges than the 130 normal Linux root user. For example, it can't reconfigure the 131 networking and many aspect of the system. It can't mount devices, 132 can't access block devices and so on. 133 Roughly. the vserver super-user has full control over all files 134 and processes in the vserver and that's pretty much it. 135 * System V inter process communications 136 Sysv IPC resources are private to each vserver. The security 137 context is used as an extra key to select and assign resources. 138 139 Those facilities are used together to create a runtime environment for 140 virtual servers. But they can be used independently to achieve various 141 goals. NEW 142 143 New system calls 144 145 The new system calls, as well as the existing chroot() system call are 146 sharing one common feature: Their effect can't be reversed. Once you 147 have executed one of those system call (chroot, new_s_context, 148 set_ipv4root), you can't get back. This affects the current process 149 and all the child processes. The parent process is not influenced. 150 151 * new_s_context (int ctx) 152 This system call sets a new security context for the current 153 process. It will be inherited by all child processes. The security 154 context is just an id, but the system call makes sure a new unused 155 one is allocated. 156 A process can only see other processes sharing the same security 157 context. When the system boot, the original security context is 0. 158 But this one is not privileged in anyway. Processes member of the 159 security context 0 can only interact (and see) processes member of 160 context 0. 161 This system call isolates the processes space. 162 * Setting the capabilities ceiling 163 This is handle by the new_s_context system call as well. This 164 reduces the ceiling capabilities of the current process. Even 165 setuid sub-process can't grab more capabilities. The capability 166 system found since Linux 2.2 is explained later in this document. 167 * set_ipv4root(unsigned long ip) 168 This system call locks the process (and children) into using a 169 single IP when they communicate and when they installs a service. 170 This system call is a one shot. Once a process have set its IPV4 171 (Internet Protocol Version 4) address to something different from 172 0.0.0.0, it can't change it anymore. Children can't change it 173 either. 174 If a process tries to bind a specific IP number, it will succeed 175 only if this corresponds to the ipv4root (if different from 176 0.0.0.0). If the process bind to any address, it will get the 177 ipv4root. 178 Basically, once a process is locked to a given ipv4root it is 179 forced to use this IP address to establish a service and 180 communicate. The restriction on services is handy: Most service 181 (Web servers, SQL servers) are binding to address 0.0.0.0. With 182 the ipv4root sets to a given IP you can have two virtual servers 183 using the exact same general/vanilla configuration for a given 184 services and running without any conflict. 185 This system calls isolate the IP network space. 186 187 Those system calls are not privileged. Any user may issue them. NEW 188 189 Limiting super-user: The capabilities system 190 191 Once you have created a virtual environment where processes have a 192 limited view of the file-system, can't see processes outside of their 193 world and can only use a single IP number, you still must limit the 194 damages those processes can do. The goal is to run virtual 195 environments and provide some root privileges. 196 197 How do you limit those root processes from taking over the system, or 198 even just re-booting it. Enter the capability system. This is not new, 199 but we suspect many people have never heard of it. 200 201 In the old Unix/Linux days, user root (user ID 0) could do things 202 other user ID could not. All over the place in the kernel, system 203 calls were denying access to some resources unless the user ID of the 204 process (effective ID in fact) was 0. Plain zero. 205 206 The only way a process with user ID 0 could loose some privileges was 207 by changing to another ID. Unfortunately this was an all or nothing 208 deal. Enter the capabilities. 209 210 Today, the difference between root and the other users is the 211 capability set. User root has all capabilities and the other users 212 have none. The user ID 0 does not mean anything special anymore. There 213 are around 30 capabilities defined currently. A process may request to 214 loose a capability forever. It won't be able to get it back. 215 216 Capabilities allows a root process to diminish its power. This is 217 exactly what we need to create custom super-user. A super-user process 218 in a virtual server would have some privileges such as binding port 219 below 1024, but would not be able to reconfigure the network or reboot 220 the machine. Check the file /usr/include/linux/capability.h to learn 221 which one are available. 222 223 Note that the new system calls (new_s_context and set_ipv4root) are 224 not controlled by capabilities. They are by nature irreversible. Once 225 a virtual server is trapped in a chroot/s_context/ipv4root box, it 226 can't escape from the parameters of this trap. 227 228 NEW 229 230 Enhancing the capability system 231 232 The Linux capability system, is still a work in progress. At some 233 point, we expect to see capabilities attached to programs, 234 generalizing the setuid concept. A setuid program would become a 235 program with all capability granted. 236 237 For now, this is not available. As explained above a process may 238 request to loose capabilities and its child process will be trapped 239 with a smaller capability set. 240 241 Well, ..., it does not work that way. Unfortunately, until 242 capabilities could be assigned to program, we still need a way to get 243 back capabilities even in a child process. So the irreversible logic 244 of the capabilities is kind of short circuited in the kernel. 245 246 To solve this, we have introduced a new per-process capability ceiling 247 (cap_bset). This one represents the capability set inherited by child 248 process, including setuid root child process. Lowering this ceiling is 249 irreversible for a process and all its child. 250 251 This ceiling is handled by the new_s_context system call and the 252 reducecap and chcontext utilities (part of the vserver package). 253 254 Using this, we can setup a virtual server environment where root has 255 less capabilities, so can't reconfigure the main server. 256 257 NEW 258 259 Playing with the new system calls 260 261 The vserver package provides 3 utilities to make use of the new system 262 calls. We will describe shortly how they work and provide few example. 263 We invite the reader to try those example, so it has a better feel and 264 trust. 265 266 After re-booting with a kernel implementing the new system calls, and 267 installing the vserver package, one is ready to do experiment. You do 268 not need to be root to test those new utilities. None of them is 269 setuid either. NEW 270 271 Playing with /usr/sbin/chcontext 272 273 The /usr/sbin/chcontext utility is used to enter into a new security 274 context. The utility switch the security context and execute a 275 program, specified on the command line. This program is now isolated 276 and can't see the other processes running on the server. 277 278 The experiment with this, start two command windows (xterm), as the 279 same user ID. In each window execute the following commands: 280 281 xterm 282 283 Using chcontext: first window 284 285 /usr/sbin/chcontext /bin/sh 286 pstree 287 killall xterm 288 exit 289 290 Using chcontext: second window 291 In the first window, you start the xterm command (or any command you 292 like). In the second window you execute chcontext. This starts a new 293 shell. You execute pstree and see very little. You attempt to kill the 294 xterm and you fail. You exit this shell and you are back seeing all 295 processes. 296 297 Here is another example. You switch context and you get a new shell. 298 In this shell you start an xterm. Then you switch context again and 299 start another sub-shell. Now the sub-shell is again isolated. 300 301 /usr/sbin/chcontext /bin/sh 302 pstree 303 xterm & 304 pstree 305 # Ok now you see your xterm 306 /usr/sbin/chcontext /bin/sh 307 pstree 308 # the xterm is not there, killall will fail 309 killall xterm 310 # Now we exit the shell 311 exit 312 pstree 313 # the xterm is there 314 killall xterm 315 # Ok, it is gone 316 exit 317 # We are back to the initial security context 318 319 Using chcontext several times 320 Processes isolated using chcontext are doubly isolated: They can't see 321 the other processes on the server, but the other processes can't see 322 them either. The original security context (0) when you boot is no 323 better than the other: It sees only process in security context 0. 324 325 While playing with chcontext, you will notice an exception. The 326 process 1 is visible from every security context. It is visible to 327 please utilities like pstree. But only root processes in security 328 context 0 are allowed to interact with it. NEW 329 330 Playing with /usr/sbin/chcontext as root 331 332 The new_s_context system call has a special semantic for root 333 processes running in security context 0 and having the CAP_SYS_ADMIN 334 capability: They can switch to any context they want. 335 336 Normally, new_s_context allocates a new security context by selecting 337 an unused one. It walks all processes and find an ID (an integer) not 338 currently in use. 339 340 But root in security context 0 is allowed to select the context it 341 wants. This allow the main server to control the virtual server. The 342 chcontext utility has the --ctx option to specify the context ID you 343 want. 344 345 To help manage several virtual server, given that the security context 346 0 can't see processes in other security context, it is a good thing 347 root in the main server (security context 0) is allowed to select a 348 specific context. Cool. But we also need a way to have a global 349 picture showing all processes in all security context. The security 350 context 1 is reserved for this. Security context 1 is allowed to see 351 all processes on the server but is not allowed to interact with them 352 (kill them). 353 354 This special feature was allocated to security context 1 and not 0 355 (the default when you boot) to isolate virtual servers from the main. 356 This way, while maintaining services on the main server, you won't 357 kill service in vservers accidentally. 358 359 Here is an example showing those concepts: 360 361 # You must be root, running X 362 # We start an xterm in another security context 363 /usr/sbin/chcontext xterm & 364 # We check, there is no xterm running, yet we can 365 # see it. 366 ps ax | grep xterm 367 # Are we running in security context 0 368 # We check the s_context line in /proc/self/status 369 cat /proc/self/status 370 # Ok we in security context 0 371 # Try the security context 1 372 /usr/sbin/chcontext --ctx 1 ps ax | grep xterm 373 # Ok, we see the xterm, we try to kill it 374 /usr/sbin/chcontext --ctx 1 killall xterm 375 # No, security context 1 can see, but can't kill 376 # let's find out in which security context this 377 # xterm is running 378 /usr/sbin/chcontext --ctx 1 ps ax | grep xterm 379 # Ok, this is PID XX. We need the security context 380 /usr/sbin/chcontext --ctx 1 cat /proc/XX/status 381 # We see the s_context, this is SS. 382 # We want to kill this process 383 /usr/sbin/chcontext --ctx SS killall xterm 384 385 chcontext as root 386 The /usr/sbin/vpstree and /usr/sbin/vps commands are supplied by the 387 vserver package. They simply runs ps and pstree in security context 1. 388 NEW 389 390 Playing with /usr/sbin/chbind 391 392 The chbind utility is used to lock a process and its children into 393 using a specific IP number. This applies to services and client 394 connection as well. Here are few examples. Execute them as root: 395 396 # httpd is running 397 netstat -atn | grep ":80 " 398 # We see a line like this 399 # tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 400 # Now we restart httpd, but we lock it so it 401 # uses only the main IP of eth0 402 /usr/sbin/chbind --ip eth0 /etc/rc.d/init.d/httpd restart 403 netstat -atn | grep ":80 " 404 # Now we see a line like 405 # tcp 0 192.168.1.1:80 0.0.0.0:* LISTEN 406 # httpd.conf was not changed. 407 # Now, restart it normally 408 /etc/rc.d/init.d/httpd restart 409 # Now we experiment with client socket 410 # Log using telnet 411 telnet localhost 412 # Once logged in 413 netstat -atn | grep ":23 " 414 # You should see a line showing a connection from 415 # 127.0.0.1 to 127.0.0.1 like this 416 # tcp 0 0 127.0.0.1:23 127.0.0.1:32881 ESTABLISHED 417 exit 418 # Now we do the telnet again, bug forcing it to select a specific IP 419 /usr/sbin/chbind --ip eth0 telnet localhost 420 # Log in and then execute 421 netstat -atn | grep ":23 " 422 # You will get something like 423 # tcp 0 0 127.0.0.1:23 192.168.3.9:32883 ESTABLISHED 424 425 Using /usr/sbin/chbind 426 NEW 427 428 Playing with /usr/sbin/reducecap 429 430 The reducecap utility is used to lower the capability ceiling of a 431 process and child process. Even setuid program won't be able to grab 432 more capabilities. 433 434 # You are not root now 435 # What is the current capability ceiling 436 cat /proc/self/status 437 # The capBset line presents mostly 1s. 438 /usr/sbin/reducecap --secure /bin/sh 439 cat /proc/self/status 440 # The capBset now shows many more 0s. 441 # The capEff shows all 0s, you have no privilege now 442 # We su to root 443 su 444 cat /proc/self/status 445 # capEff is much better now, but there are still many 0s 446 # Now we try to see if we are really root 447 tail /var/log/messages 448 # So far so good, we see the content 449 /sbin/ifconfig eth0 450 /sbin/ifconfig eth0 down 451 # No way, we can't configure the interface. In fact 452 # we have lost most privilege normally assigned to root 453 exit 454 455 Using /usr/sbin/reducecap 456 NEW 457 458 Unification 459 460 Installing a virtual private server copies a linux installation inside 461 a sub-directory. It is a linux inside linux. If you intend to run 462 several vservers on the same box (which you will certainly do :-) ), 463 you will end up using a lot of disk space needlessly: Each vserver is 464 made up hundreds of megabytes of the same stuff. This is a big waste 465 of disk space. 466 467 A solution is to use hard links to connect together common files. 468 Using the package information, we can tell which packages are shared 469 between various vservers, which files are configuration files and 470 which are not (binaries, libraries, resource files, ...). Non 471 configuration files may be linked together saving a huge amount of 472 disk space: A 2 GIG rh7.2 installation shrinks to 38megs. 473 474 Using hard links is cool, but may be a problem. If one vserver 475 overwrite one file, say /bin/ls, then every vserver will inherit that 476 change. Not fun! The solution is to set the immutable bit on every 477 linked file. A file with such a bit on can't be modified, even by 478 root. The only way to modify it is to turn off the bit first. But 479 within a vserver environment, even root is not allowed to perform this 480 task. So linked file, turned immutable, are now safe: They can be 481 shared between vservers without side effects: Cool! 482 483 Well, there is still another side effect. All vservers are now locked 484 with the same files. We are saving a lot of disk space, but we pay a 485 very heavy price for that: Vservers can't evolve independantly. 486 487 A solution was found. A new bit call immutable-linkage-invert was 488 added. Combined with the immutable bit, a file may not be modified, 489 but may be unlinked. Unlinking a file in Unix/Linux means 490 disconnecting the name from the data and removing the name from the 491 directory. If the data is still referenced by one or more vservers, it 492 continue to exist on disk. So doing "rm /bin/ls" on a vserver, removes 493 the file /bin/ls for that vserver and that's all. If all vservers 494 perform this task, then /bin/ls (the data) will be forgotten completly 495 and the disk space will be recovered. 496 497 Using this trick, a vserver gets back its independance. It becomes 498 possible to update packages by using the unlink/update sequence: 499 Unlink /bin/ls first and then put a new copy in place. Luckily, 500 package manager works this way. 501 502 To keep this story short (probably too late :-) ), a unified vserver: 503 * Uses little disk space 504 * Can't interfere with other vservers by changing one of its file. 505 * Can perform package update/deletion normally using standard 506 practice. 507 508 NEW 509 510 Applications 511 512 NEW 513 514 Virtual server 515 516 The first goal of this project is to create virtual servers sharing 517 the same machine. A virtual server operate like a normal Linux server. 518 It runs normal services such as telnet, mail servers, web servers, SQL 519 servers. In most cases, the services run using standard configuration: 520 The services are running unaware of the virtual server concept. 521 522 Normal system administration is performed with ordinary admin tool. 523 Virtual servers have users account and a root account. 524 525 Packages are installed using standard packages (RPMs for example). 526 527 There are few exceptions. Some configuration can't be done inside a 528 virtual server. Notably the network configuration and the file-system 529 (mount/umount) can't be performed from a virtual server. 530 531 NEW 532 533 Per user fire-wall 534 535 The set_ipv4root() system call may be used to differentiate the 536 various users running on an application server. If you want to setup a 537 fire-wall limiting what each user is doing, you have to assign one IP 538 per user, even if they are running application on the same server. The 539 chbind utility may be used to achieve that. NEW 540 541 Secure server/Intrusion detection 542 543 While it can be interesting to run several virtual servers in one box, 544 there is one concept potentially more generally useful. Imagine a 545 physical server running a single virtual server. The goal is isolate 546 the main environment from any service, any network. You boot in the 547 main environment, start very few services and then continue in the 548 virtual server. The service in the main environment could be 549 550 * Un-reachable from the network. 551 * The system log daemon. While virtual server could log messages, 552 they would be unable to change/erase the logs. So even a cracked 553 virtual server would not be able the edit the log. 554 * Some intrusion detection facilities, potentially spying the state 555 of the virtual server. For example tripwire could run there and it 556 would be impossible to circumvent its operation or trick it. 557 558 NEW 559 560 Fail over servers 561 562 One key feature of a virtual server is the independence from the 563 actual hardware. Most hardware issues are irrelevant for the virtual 564 server installation. For example: 565 566 * Disk layout, partitions and the /etc/fstab configuration. The 567 virtual server has a dummy /etc/fstab. 568 * Network devices. 569 * Processor type, number of processor (kernel selection). 570 571 The main server acts as a host and takes care of all those details. 572 The virtual server is just a client and ignores all the details. As 573 such, the client can be moved to another physical server will very few 574 manipulations. For example, to move the virtual server v1 from one 575 physical one computer to another, you do 576 577 * Turn it off 578 /usr/sbin/vserver v1 stop 579 * Copy the file /etc/vservers/v1.conf to the new server. 580 * Copy all files in /vservers/v1 to the new server 581 * On the new server, start the vserver v1 582 /usr/sbin/vserver v1 start 583 584 As you see, there is no adjustment to do: 585 586 * No user account merging. 587 * No hardware configuration to fix. 588 589 This opens the door to fail over servers. Imagine a backup server 590 having a copy of many virtual servers. It can take over their tasks 591 with a single command. Various options exists for managing this backup 592 server: 593 594 * rsync to synchronize the data. 595 * Network block devices to synchronize the data in real time. 596 * Sharing the installation over a SAN (storage area network). 597 * Heartbeat for automatic monitoring/fail over. 598 599 NEW 600 601 Installation 602 603 NEW 604 605 The packages 606 607 * The kernel 608 We are supplying a patched 2.4.20 kernel. You will find [50]here 609 the kernel, the .config and the patch. 610 To install the kernel, just untar it. This will create a file 611 /boot/kernel-2.4.20ctx-17 (ctx stands for security context) and a 612 directory /lib/modules/2.4.20ctx-17. 613 Then, you need to update your boot loader. For lilo, you add a 614 section like this at the end of the file /etc/lilo.conf 615 616 617 image=/boot/vmlinuz-2.4.20ctx-17 618 label=linux2.4.20ctx-17 619 read-only 620 root=current 621 622 lilo.conf section to add 623 Change the /dev/XXXX to your root partition. Then execute 624 /sbin/lilo. 625 Reboot and select the proper kernel. This kernel is fully 626 compatible with a normal 2.4.20 and will perform without any new 627 configuration. Note that the supplied kernel does not carry all 628 the features and modules found on the various distributions. 629 * The vserver package 630 This package provides the various utilities to make use of those 631 new system calls. The package also provides a complete solution to 632 implement virtual servers. We describe the major components here. 633 + /usr/sbin/chcontext 634 This is the utility to request a new security context. It can 635 be used to lower the capability ceiling. Execute it to learn 636 more. 637 + /usr/sbin/chbind 638 This is the utility to select one IP number and assign it to 639 a process and its children. 640 + /usr/sbin/newvserver (in vserver-admin) 641 Front-end to help create new virtual servers. 642 + /usr/sbin/reducecap 643 This utility is used to lower the capability ceiling of 644 children processes. 645 + /usr/sbin/vdu 646 A trimmed down "du" command reporting space usage of files 647 with a single link. Useful to tell how much space a unified 648 vserver is using. 649 + /usr/sbin/vkill 650 Locate the security context associated with a process, enter 651 it and kill the process. Generally used after you have 652 located a process with vtop, vpstree or vps. 653 + /usr/sbin/vps 654 Execute the ps command in security context 1 so all processes 655 in all vservers are shown. The security context and vserver 656 name are mapped inside the report. 657 + /usr/sbin/vpstree 658 Execute the pstree command in security context 1 so all 659 processes in all vservers are shown. 660 + /usr/sbin/vrpm 661 Apply an rpm command in several (or all) vservers. Useful 662 when you wish to update many vservers with the same package. 663 /usr/sbin/vrpm server1 server2 -- -Uvh /tmp/*.rpm 664 /usr/sbin/vrpm ALL -- -Uvh /tmp/*.rpm 665 After updating many packages in different vservers you may 666 want to re-unify them to recover disk space (and increase 667 cache effectivity). You can do this using the vunify command, 668 or simply by using the --unify option to the vrpm command. 669 After performing the rpm updates, vrpm will trigger the 670 vunify utility on the vservers for the updated packages. 671 /usr/sbin/vrpm --unify server1 server2 -- -Uvh /tmp/*.rpm 672 + /usr/sbin/vserver 673 This is the wrapper to start, stop and administer virtual 674 servers. 675 + /usr/sbin/vserver-stat 676 Produce a small report showing the activity in active 677 security context. The report presents the number of process 678 in each active security context as well as the name of the 679 vserver associated with this context. 680 + /usr/sbin/vtop 681 Execute the top command in security context 1 so all 682 processes in all vservers are shown. 683 + /etc/rc.d/init.d/vservers 684 This is an init script used to start all virtual servers at 685 boot time and stop them at shutdown time. Only virtual 686 servers with ONBOOT=yes are started at boot time. All 687 vservers are stopped at shutdown time. 688 + /etc/rc.d/init.d/rebootmgr 689 This is a daemon listening to requests from virtual servers. 690 It can either restart or stop a virtual server. The 691 /sbin/vreboot and /sbin/vhalt utilities are used to send 692 request to the reboot manager. 693 + /sbin/vreboot and /sbin/vhalt 694 Those utilities are copied in each virtual server. They 695 connect to the reboot manager (rebootmgr) server using the 696 /dev/reboot Unix domain socket and request either a restart 697 or a stop of the virtual server. The reboot manager issue 698 either a "/usr/sbin/vserver vserver restart" or 699 "/usr/sbin/vserver vserver stop" command. This allows the 700 virtual server administrator to test if all automatic service 701 are properly restarted at boot time. 702 + /usr/lib/vserver/vdu 703 This is a limited clone of the du command. It skips file with 704 more than one link. It is used to evaluate the disk usage of 705 an unified vserver. Using the normal du for this task is 706 misleading since it will count all unified files. 707 708 NEW 709 710 Setting a virtual server 711 712 To set a virtual server, you need to copy in a sub-directory a Linux 713 installation. One way to achieve that is to copy some parts of the the 714 current server by issuing the command vserver XX build, where XX is 715 the name of the virtual server (pick one). This basically does (Well, 716 it does a little more than that, but this give you an idea): 717 718 mkdir /vservers/XX 719 cd /vservers/XX 720 cp -ax /sbin /bin /etc /usr /var /dev /lib . 721 mkdir proc tmp home 722 chmod 1777 tmp 723 724 Building a virtual server 725 726 This is normally done using the command /usr/sbin/newvserver. This is 727 a text mode/graphical front-end allowing to setup the vserver runtime 728 and configure it. NEW 729 730 Basic configuration of the virtual server 731 732 A virtual private server has a few settings. They are defined in the 733 file /etc/vservers/XX.conf where XX is the name of the virtual server. 734 This is a simple script like configuration. Here are the various 735 parameters: 736 737 * IPROOT 738 In general, each virtual server is tied to one IP using the new 739 set_ipv4root system call. This way several servers may run the 740 same services without conflict. Enter the IP number (a name is 741 also valid if defined in the DNS). 742 Since kernel ctx-12, you can assign more than one IP number to a 743 vserver. Enter them separated by spaces and don't forget to 744 enclose them with quotes. 745 Bu default, all IPs are configured as an IP alias on the IPROOTDEV 746 device (if defined). If you want to attach the various IP numbers 747 to different devices, specify the device as a prefix to the IP 748 number like this: 749 750 IPROOT="eth0:192.168.1.2 eth1:192.168.3.1 192.168.1.4" 751 752 IPROOT using multiple devices 753 In the example above, the IP 192.168.1.4 will be installed as an 754 IP alias on the device IPROOTDEV. 755 Use "IPROOT=0.0.0.0" or "IPROOT=" if you do not want to tie the 756 vserver at all. It will be allowed to use any IP available on the 757 server. 758 * IPROOTDEV 759 This is the network device use to setup the IP alias defined by 760 IPROOT. This is generally eth0. If you define this variable, the 761 IP alias will be configured when you start the virtual server and 762 un-configure when you stop it. 763 * IPROOTMASK 764 Netmask used to setup the IP alias. Uses the netmask of the 765 IPROOTDEV device by default. Seldom used. 766 If you have several IPs on one vserver and want to have different 767 netmask for each, use the following syntax: 768 769 IPROOT="eth0:192.168.1.2 eth1:192.168.3.1/255.255.255.192" 770 771 IPROOT using different netmask 772 192.168.1.2 will use the netmask of eth0, while 192.168.3.1 will 773 use the specified netmask: 255.255.255.192. 774 * IPROOTBCAST 775 Broadcast address used to setup the IP alias. Uses the broadcast 776 of the IPROOTDEV device by default. Seldom used. 777 * ONBOOT 778 The vserver package supplies the vservers service. This service is 779 installed in the main server. It is used to start and stop the 780 virtual server at boot and shutdown time. 781 Virtual server with ONBOOT=yes will be started and stopped 782 properly like any other services of the main server. 783 Once a virtual server is properly configured, it is a good idea to 784 set this parameter to yes. 785 * S_CAPS 786 You enter here the various capability you want to grant to the 787 vserver. By default, a vserver is left with much less capabilities 788 than the root server. For example, a vserver is not allowed to use 789 raw socket. This explains why the ping command fails. S_CAPS lets 790 you enumerate the capability you want to keep in the vserver. 791 CAP_NET_RAW will give back ping ability for example. 792 * S_CONTEXT 793 This is optional. In general the security context ID is selected 794 by the kernel. An unused one is selected. If you select an ID (an 795 integer greater than 1), make sure you select a different one for 796 each server. Again, in most cases, you do not need to select one. 797 Leave the line commented. 798 * S_DOMAINNAME 799 A virtual server may have a different NIS domainname than the main 800 server. You set it here. If you leave the field empty, the vserver 801 will inherit the same NIS domain as the root server. Enter "none" 802 to reset the NIS domain name for this vserver. 803 * S_HOSTNAME 804 Many services (Apache for one) use the host name to setup some 805 defaults. A virtual server may have a different host name than the 806 main server. It is a good idea to fill this line. 807 * S_NICE 808 The is an optional priority level. It is an integer ranging 809 between from -20 to 19. Well it is the nice level in fact, so -20 810 means the highest priority and 19 the lowest (the highest nice 811 level). All processes in the virtual server will be locked to this 812 level (or higher niceness). 813 Event root is locked and can't get more priority. 814 Note that this has limited usefulness. The kernel does not 815 differentiate processes running in different security context for 816 scheduling (for now :-) ). This means that a virtual servers 817 running many low priority processes may nevertheless claim a large 818 share of CPU. 819 * S_FLAGS 820 This is used to set various flags. Here are the supported flags: 821 + lock 822 This flags prevents the vserver from setting new security 823 contexts. 824 + sched 825 It kind of unifies the processes in a vserver from a 826 scheduler view point. All processes are weighted as single 827 one when compared to other processes in the real server. This 828 prevents a vserver from taking to much CPU resources. 829 + nproc 830 Make the ulimit maximum user process global to the vserver. 831 + private 832 Once set on a vserver security context, no other process can 833 enter it. Even the root server is unable to enter the 834 context. It can see the process list using security context 835 1, but can't signal or trace the process. 836 + fakeinit 837 This assigned the current process so it works like the 838 process number 1. Using this trick, a normal /sbin/init may 839 be run in a vserver. The /usr/sbin/vserver command will use 840 /sbin/init to start and stop a vserver. A properly configured 841 /etc/inittab is needed though. 842 o Processes loosing their parent are reparent to this 843 process. 844 o getppid() done by child process of this process returns 845 1. 846 o getpid() done by this process returns 1. 847 o This process is not shown in /proc since process number 848 1 is always shown. 849 o An "initpid" entry is available in /proc/*/status to 850 tell which process is the fake init process. 851 * ULIMIT 852 This contains the command line option to the ulimit shell command. 853 You enter here whatever parameters accepted by ulimit. Here is the 854 default when you create a new vserver: 855 856 ULIMIT="-H -u 1000" 857 858 Default vserver ulimit 859 Normally ulimit settings only affects users independantly. So 860 limiting a vserver this way, limit each user processes 861 independantly in the vserver. Using special flags in the S_FLAGS 862 option, you can make those ulimit settings global to the vserver. 863 The example above used with the nproc parameter make the maximum 864 number of process global. In this case, a maximum of 1000 865 processes is available to all users in the vserver. 866 867 NEW 868 869 Entering the virtual server 870 871 It is possible to enter a virtual server context from the main server 872 just by executing /usr/sbin/vserver XX enter (where XX is the virtual 873 server name). 874 875 This creates a shell. From there you can execute anything 876 administrative you normally do on a Linux server. 877 878 NEW 879 880 Configuring the services 881 882 The virtual server can run pretty much any services. Many pseudo 883 services, such as network configuration are useless (the server is 884 already configured). After building the environment, enter it (without 885 starting the virtual server) using the vserver name enter command. 886 Then using a tool like Linuxconf (control/control service activity) , 887 or ntsysv, browse all service and keep only the needed ones. 888 889 So after building the server, you enter it and you select the service 890 you need in that server. Many services such as network, and apmd are 891 either useless or won't run at all in the virtual server. They will 892 fail to start completely. NEW 893 894 Starting/Stopping the virtual server 895 896 Virtual server with ONBOOT=yes will be started and stopped like any 897 other services of the main server. But you can stop and start a 898 virtual server at any time. Starting a server means that all 899 configured service will be started. Stopping it means that all 900 configured services will be stopped and then all remaining process 901 will be killed. 902 903 Oddly, starting a virtual server does not mean much. There is no 904 overhead. No monitoring process or proxy or emulator. Starting a 905 virtual server with 4 services is the same as running those 4 services 906 in the main server, at least performance wise (the service inside a 907 virtual server are locked inside the security context). 908 909 The following commands may be used to control a virtual server: 910 911 * /usr/sbin/vserver server start 912 * /usr/sbin/vserver server stop 913 * /usr/sbin/vserver server restart 914 * /usr/sbin/vserver server running 915 * /usr/sbin/vserver server enter 916 * /usr/sbin/vserver server exec some commands ... 917 * /usr/sbin/vserver server suexec user some commands ... 918 * /usr/sbin/vserver server service service-name 919 start/stop/restart/status 920 * /usr/sbin/vserver server status 921 922 The running command prints if there are any processes running in the 923 virtual server context. 924 925 Please note 926 927 The processes running in a virtual server are invisible from the main 928 server. The opposite is true. This is very important. Managing the 929 main server must not cause problems to the various virtual servers. 930 For example, doing killall httpd will kill all the httpd processes in 931 the current context ( the main server or a virtual one). 932 933 NEW 934 935 Starting/Stopping all the virtual servers 936 937 The sysv script /etc/rc.d/init.d/vserver is used to start and stop the 938 virtual server at boot and shutdown time. It may be used at any time 939 to operate all virtual servers. The following commands are supported: 940 941 * /etc/rc.d/init.d/vservers start 942 * /etc/rc.d/init.d/vservers stop 943 * /etc/rc.d/init.d/vservers restart 944 * /etc/rc.d/init.d/vservers status 945 946 The status command reports the running status of every virtual server. 947 NEW 948 949 Restarting a virtual server from inside 950 951 A virtual server administrator is not allowed to reboot the machine 952 (the kernel). But it is useful to restart his virtual server from 953 scratch. This allow him to make sure all the services are properly 954 configured to start at boot time. 955 956 The /sbin/vreboot and /sbin/vhalt utilities are installed in each 957 virtual server so they can request a restart or stop. 958 959 The rebootmgr service must be enabled in the main server. 960 961 NEW 962 963 Executing tasks at vserver start/stop time 964 965 You can setup a script called /etc/vservers/XX.sh where XX is the name 966 of the virtual server. This script will be called four time: 967 968 * Before starting the vserver 969 * After starting it. 970 * Before stopping it. 971 * After stopping it. 972 973 You generally perform tasks such as mounting file system (mapping some 974 directory in the vserver root using "mount --bind"). 975 976 Here is an example where you map the /home directory as the vserver 977 /home directory. 978 979 #!/bin/sh 980 case $1 in 981 pre-start) 982 mount --bind /home /vservers/$2/home 983 ;; 984 post-start) 985 ;; 986 pre-stop) 987 ;; 988 post-stop) 989 umount /vservers/$2/home 990 ;; 991 esac 992 993 /etc/vservers/XX.sh 994 NEW 995 996 Issues 997 998 There are some common problem you may encounter. Here they are. 999 1000 * The main server is not tied (by default) to any ipv4root. So if 1001 the main server has already some service running they are probably 1002 binding some UDP or TCP ports using the address 0.0.0.0. Once a 1003 process has bound a service with the address 0.0.0.0 (see the 1004 LISTEN lines when executing the "netstat -a" command), no other 1005 process can bind the same port, even with a specific address. 1006 The solution is to start the services of the main server using the 1007 chbind utility to trap them in one ipv4root. For example 1008 1009 /sbin/chbind --ip eth0 /etc/rc.d/init.d/httpd start 1010 1011 Assigning on IP to a service 1012 will limit Apache to the IP address of the eth0 interface. without 1013 configuration changes (in httpd.conf). It is probably a good idea 1014 to start the following services in the main server this way, 1015 because they will be run by virtual servers as well. 1016 1017 * httpd 1018 * sshd 1019 * xinetd 1020 1021 To ease this, the vserver package supplies the following services: 1022 v_httpd, v_sshd, v_smb and v_xinetd. Disable the corresponding 1023 services and enable the v_ services and you will lock those services 1024 on a single IP. 1025 1026 Cleanup rc.local. This is probably not doing anything useful. 1027 1028 NEW 1029 1030 How real is it ? 1031 1032 The project is new. So far, experiments have shown very little 1033 restrictions. Service works the same in a virtual server. Further, 1034 performance is the same. And there is a high level of isolation 1035 between the various virtual servers and the main server. NEW 1036 1037 Features 1038 1039 There are various tricks one can use to make the virtual servers more 1040 secure. 1041 1042 * Putting a fire-wall on the box and limiting access to a virtual 1043 services from another one. 1044 * Using port redirection to allow one virtual server to logically 1045 bind several IPs. One virtual server could run several web virtual 1046 host this way. 1047 1048 NEW 1049 1050 Future directions 1051 1052 NEW 1053 1054 User controlled security box 1055 1056 By combining the capabilities, the s_context, the ipv4root and the 1057 AclFS (component of the [51]virtualfs package), we can produce a user 1058 level tool allowing controlled access to the user own resources. For 1059 example the user may download any program he wants and execute them 1060 under control. Whenever the program tries to access something not 1061 specified by the user, a popup is presented and the user may choose to 1062 terminate the program or allow the access. 1063 1064 NEW 1065 1066 Kernel enhancements 1067 1068 We expect to see some wider usage of the virtual servers. As usage 1069 grow, we expect to see needs for more control. Here are some ideas. 1070 1071 NEW 1072 1073 Per context disk quota 1074 1075 If one installs virtual servers and grant access to less trusted 1076 users, he may want to limit the disk space used. Since a virtual 1077 server may create new user accounts and run processes with any user ID 1078 it wants, the current kernel disk quota is not powerful enough. First, 1079 it can't differentiate between user ID 100 in one virtual server and 1080 user ID 100 in another one. 1081 1082 Further, the main administrator may want to control disk space 1083 allocated to the virtual server on a server per server basis, 1084 unrelated to the various user ID in use in those virtual servers. 1085 1086 The kernel has already user and group disk quota. Adding security 1087 context disk quota should be easily done. 1088 1089 To differentiate between user IDs in virtual servers, the kernel could 1090 coin together the security context and the user id to create a unique 1091 ID. The kernel 2.4 now supports 32 user ID, so combining security 1092 context and user ID in a single 32 bits number should be acceptable. 1093 1094 NEW 1095 1096 Global limits 1097 1098 The kernel has supports for user limit (memory, processes file 1099 handles). With virtual server, we may want to limit the resources used 1100 by all processes in the virtual server. The security context would be 1101 used as the key here. The following resources could be limited on a 1102 security context basis (as opposed to user or process basis) 1103 1104 * Memory used 1105 * Processes number 1106 (Done: This is now supported with the nproc flag in the kernel 1107 2.4.16ctx-4. By default a new vserver is limited to 1000 processes 1108 maximum, configurable). 1109 * File handles 1110 1111 NEW 1112 1113 Scheduler 1114 1115 The scheduler may become security context aware. It could potentially 1116 use this to provide some fairness and control priority based on 1117 context. Currently the scheduler is process oriented and does not 1118 group process together to qualify their priorities. For example, a 1119 user running 10 compilations will get more CPU than another user 1120 running a single compilation. 1121 1122 Currently, it is possible to raise the nice (lower priority) for all 1123 processes in a virtual server. This can't be reversed, so you are 1124 setting an upper limit on priority (Just set the S_NICE variable in 1125 the vserver configuration file). Note that a virtual server may still 1126 start many low priority processes and this can grab significant share 1127 of the CPU. A global per security context might be needed to really 1128 provide more control and fairness between the various virtual servers. 1129 1130 Done: The sched security context flag group all process in a vserver 1131 so their priority is kind of unified. If you have 50 processes running 1132 full speed in one vserver, they will take as much CPU resource than a 1133 single process in the root server. A vserver can't starve the other... 1134 NEW 1135 1136 Security issues 1137 1138 The current kernel + patch provides a fair level of isolation between 1139 the virtual servers. User root can't take over the system: He sees 1140 only his processes, has only access to his area of the file system 1141 (chroot) and can't reconfigure the kernel. Yet there are some 1142 potential problems. They are fixable. As usage grows, we will know if 1143 they are real problems. Comments are welcome: 1144 1145 NEW 1146 1147 /dev/random 1148 1149 Writing to /dev/random is not limited by any capability. Any root user 1150 (virtual included) is allowed to write there. Is this a problem ? 1151 1152 (kernel expert think it is ok) NEW 1153 1154 /dev/pts 1155 1156 /dev/pts is a virtual file-system used to allocate pseudo-tty. It 1157 presents all the pseudo-tty in use on the server (including all 1158 virtual server). User root is allowed to read and write to any 1159 pseudo-tty, potentially causing problems on other vservers. 1160 1161 Starting with the ctx-6 patch, /dev/pts is virtualised. Although the 1162 file numbers are allocated from a single pool, a vserver only see the 1163 pseudo-tty it owns. NEW 1164 1165 Network devices 1166 1167 Anyone can list the network devices configurations. This may inform a 1168 virtual user that another vserver is on the same physical server. By 1169 using as much resources as possible in his own vservers, a malicious 1170 user could slow down the other server. Modification to the scheduler 1171 explained above could stop this. 1172 1173 Starting with the ctx-6 patch, a vserver only see the device 1174 corresponding to its IP number. NEW 1175 1176 Alternative technologies 1177 1178 Using virtual servers may be a cost effective alternative to several 1179 independent real servers. You get the administrative independence of 1180 independent servers, but share some costs including operation costs. 1181 1182 Other technologies exist offering some of the advantages talked in 1183 this document as well as other. Two technologies are available on 1184 various hardware platform: Virtual machines and partitioning, NEW 1185 1186 Virtual machines 1187 1188 This has been available for mainframes for a while now. You can boot 1189 several different OS at once on the same server. This is mainly used 1190 to isolate environments. For example, you can install the new version 1191 of an OS on the same server, even while the server is running the 1192 current version. This allows you to test and do a roll-out gracefully. 1193 1194 The advantages of virtual machines are: 1195 1196 * Total flexibility. You can run many different OS and different 1197 version of the same OS, all at once. 1198 * Robustness. You have total isolation. One OS may crash without 1199 affecting the other. 1200 * Resource management. You can effectively limit the resources taken 1201 by one OS. 1202 * Hardware Independence. The client OS is using virtual disks 1203 provided by the host OS. 1204 1205 This technology is not directly available on PCs. The Intel x86 1206 architecture does not support visualization natively. Some products 1207 nevertheless have appeared and provide this. You can run Linux inside 1208 Linux, or this other OS (Which BTW has a logo showing a window flying 1209 in pieces, which quite frankly tells everything about it). 1210 1211 The solutions available on PCs carry most of the advantages of the 1212 virtual machines found on mainframe, except for performance. You can't 1213 run that many virtual Linux's using this technology and expect it to 1214 fly. One example of this technology is [52]vmware, which is quite 1215 useful, especially if you must run this other OS... vmware may be used 1216 to run Linux inside Linux, even test Linux installation while running 1217 linux... NEW 1218 1219 Partitioning 1220 1221 Partitioning (domains ?) is a way to split the resources of a large 1222 server so you end up with independent servers. For example, you can 1223 take a 20 CPUs server and create 3 servers, two with 4 CPUs and one 1224 with 12. You can very easily re-assign CPUs to servers in case you 1225 need more for a given tasks. 1226 1227 This technology provides full Independence, but much less flexibility. 1228 If your 12 CPUs server is not working much, the 4 CPUs one can't 1229 borrow some CPUs for 5 minutes. NEW 1230 1231 Limitation of those technologies 1232 1233 Oddly, one disadvantage of those technologies is a side effect of 1234 their major advantage: Total Independence. Each virtual server is 1235 running its own kernel. Cool. This makes the following tasks more 1236 difficult or impossible: 1237 1238 * Sharing administrative tasks such as backup. The virtual servers 1239 are using volumes in the host server. The host server can't handle 1240 the files in those volumes directly without interfering with the 1241 client OS. It has to use some services of the client OS to access 1242 the file. 1243 The vserver solution does not have this limitation since the 1244 virtual servers are living in the same file-system, sharing the 1245 same kernel. 1246 * Task monitoring. The virtual servers run their own kernel. As 1247 such, the host OS can't spy on the tasks and check for intrusion 1248 for example. 1249 * Disk space. Virtual servers are using either volumes or full 1250 devices in the host server. This space is pre-allocated to the 1251 maximum needed by the server. You end up with a lot of wasted disk 1252 space. Imagine running 100 virtual servers this way and allocating 1253 say 10 gigs to each. You get the picture. The vserver solution is 1254 sharing a common file-system so the free disk space is available 1255 to all. 1256 Further, if you are running the same Linux distribution in the 1257 virtual servers, you can unify the disk space using hard link and 1258 immutable attributes. The /usr/lib/vserver/vunify was created to 1259 test that. Using information found in the rpm package the script 1260 links the files, except configuration ones. 1261 Testing vunify on a vserver installed with a RedHat 6.2 1262 distribution, unifying the packages glibc, binutils, perl, and 1263 bash saved 60 megs. Quite a few packages are not changing often 1264 and could be unified. 1265 Vservers do not need kernel packages and hardware configuration 1266 tools. This also contribute to save disk space. 1267 * File system sharing 1268 A little the same as above. You can't share file system easily 1269 between vservers unless you use network services (often slower). 1270 Using "mount --bind", it is very easy to "map" any directory of 1271 the root server in several vservers, providing raw speed access 1272 (and even sharing the disk cache). 1273 1274 NEW 1275 1276 Conclusion 1277 1278 Virtual servers are interesting because they can provide a higher 1279 level of security while potentially reducing the administration task. 1280 Common operation such as backup, are shared between all servers. 1281 Services such as monitoring may be configured once. 1282 1283 A Linux server can run many services at once with a high level of 1284 reliability. As servers are evolving, more and more services are 1285 added, often unrelated. Unfortunately there are few details here and 1286 there, making the server more complex than it is in reality. When one 1287 wants to move one service to another server, it is always a little 1288 pain: Some user accounts have to be moved and some configuration 1289 files. A lot of hand tweaking. 1290 1291 By installing services in separate virtual servers, it becomes much 1292 easier to move services around (just by moving a directory although a 1293 big one). 1294 1295 Virtual servers may become a preferred way to install common Linux 1296 servers. NEW 1297 1298 Download 1299 1300 The ftp site for this project is 1301 [53]ftp://ftp.solucorp.qc.ca/pub/vserver . You will find there the 1302 following components. 1303 1304 * [54]kernel-2.4.20ctx-17.tar.gz 1305 [55]kernel-2.4.20ctxsmp-17.tar.gz 1306 A pre-compiled kernel for Pentium class machine and up. An SMP 1307 kernel is also supplied. 1308 * [56]vserver-0.22-1.src.rpm 1309 The source RPM for the vserver utilities 1310 * [57]vserver-0.22-1.i386.rpm 1311 A compiled rpm for RedHat 7.x and up. Should work on any recent 1312 distribution (glibc 2.2). You need a recent distribution to 1313 operate a kernel 2.4 anyway. 1314 * [58]vserver-admin-0.22-1.i386.rpm 1315 Contains the command /usr/sbin/newvserver. It is a GUI to create 1316 vservers. It requires the linuxconf-utils and linuxconf-lib 1317 packages. You can get them from [59]here. linuxconf itself is not 1318 needed though. 1319 * [60]vserver-0.22.src.tar.gz 1320 The vserver utilities source 1321 * [61]patch-2.4.20ctx-17.gz 1322 The patch against Linux 2.4.20 1323 * [62]patches 1324 The various relative patches (ctxN-ctxN+1) 1325 1326 NEW 1327 1328 References 1329 1330 This project is maintained by Jacques Gelinas [63]jack@solucorp.qc.ca 1331 1332 The vserver package is licensed under the GNU PUBLIC LICENSE. 1333 1334 A FAQ can be found at 1335 [64]http://www.solucorp.qc.ca/howto.hc?projet=vserver 1336 1337 A mailing list has been created to exchange about this project. It is 1338 [65]vserver@solucorp.qc.ca .You can subscribe [66]here 1339 1340 The mailing list is archived [67]here. 1341 1342 The change logs for the vserver package are [68]here . 1343 1344 The official copy of this document is found at 1345 [69]http://www.solucorp.qc.ca/miscprj/s_context.hc 1346 1347 This document was produced using the [70]TLMP documentation system 1348 1349 [71]Top 1350 [72]Back to project page 1351 [73]About tlmpdoc and cookies 1352 Document maintained by Jacques Gélinas ([74]jack@solucorp.qc.ca) 1353 Last update: Wed Apr 16 11:22:22 2003 1354 1355 Références 1356 1357 1. http://remtk/solucor/miscprj/s_context.hc?s1=1&s2=0&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1358 2. http://remtk/solucor/miscprj/s_context.hc?s1=1&s2=1&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1359 3. http://remtk/solucor/miscprj/s_context.hc?s1=2&s2=0&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1360 4. http://remtk/solucor/miscprj/s_context.hc?s1=2&s2=1&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1361 5. http://remtk/solucor/miscprj/s_context.hc?s1=2&s2=2&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1362 6. http://remtk/solucor/miscprj/s_context.hc?s1=2&s2=3&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1363 7. http://remtk/solucor/miscprj/s_context.hc?s1=2&s2=4&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1364 8. http://remtk/solucor/miscprj/s_context.hc?s1=2&s2=5&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1365 9. http://remtk/solucor/miscprj/s_context.hc?s1=2&s2=6&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1366 10. http://remtk/solucor/miscprj/s_context.hc?s1=2&s2=6&s3=1&s4=0&full=0&prjstate=1&nodoc=0 1367 11. http://remtk/solucor/miscprj/s_context.hc?s1=2&s2=6&s3=2&s4=0&full=0&prjstate=1&nodoc=0 1368 12. http://remtk/solucor/miscprj/s_context.hc?s1=2&s2=6&s3=3&s4=0&full=0&prjstate=1&nodoc=0 1369 13. http://remtk/solucor/miscprj/s_context.hc?s1=2&s2=6&s3=4&s4=0&full=0&prjstate=1&nodoc=0 1370 14. http://remtk/solucor/miscprj/s_context.hc?s1=2&s2=7&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1371 15. http://remtk/solucor/miscprj/s_context.hc?s1=3&s2=0&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1372 16. http://remtk/solucor/miscprj/s_context.hc?s1=3&s2=1&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1373 17. http://remtk/solucor/miscprj/s_context.hc?s1=3&s2=2&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1374 18. http://remtk/solucor/miscprj/s_context.hc?s1=3&s2=3&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1375 19. http://remtk/solucor/miscprj/s_context.hc?s1=3&s2=4&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1376 20. http://remtk/solucor/miscprj/s_context.hc?s1=4&s2=0&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1377 21. http://remtk/solucor/miscprj/s_context.hc?s1=4&s2=1&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1378 22. http://remtk/solucor/miscprj/s_context.hc?s1=4&s2=2&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1379 23. http://remtk/solucor/miscprj/s_context.hc?s1=4&s2=3&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1380 24. http://remtk/solucor/miscprj/s_context.hc?s1=4&s2=4&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1381 25. http://remtk/solucor/miscprj/s_context.hc?s1=4&s2=5&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1382 26. http://remtk/solucor/miscprj/s_context.hc?s1=4&s2=6&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1383 27. http://remtk/solucor/miscprj/s_context.hc?s1=4&s2=7&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1384 28. http://remtk/solucor/miscprj/s_context.hc?s1=4&s2=8&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1385 29. http://remtk/solucor/miscprj/s_context.hc?s1=4&s2=9&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1386 30. http://remtk/solucor/miscprj/s_context.hc?s1=4&s2=10&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1387 31. http://remtk/solucor/miscprj/s_context.hc?s1=4&s2=11&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1388 32. http://remtk/solucor/miscprj/s_context.hc?s1=5&s2=0&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1389 33. http://remtk/solucor/miscprj/s_context.hc?s1=6&s2=0&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1390 34. http://remtk/solucor/miscprj/s_context.hc?s1=6&s2=1&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1391 35. http://remtk/solucor/miscprj/s_context.hc?s1=6&s2=2&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1392 36. http://remtk/solucor/miscprj/s_context.hc?s1=6&s2=2&s3=1&s4=0&full=0&prjstate=1&nodoc=0 1393 37. http://remtk/solucor/miscprj/s_context.hc?s1=6&s2=2&s3=2&s4=0&full=0&prjstate=1&nodoc=0 1394 38. http://remtk/solucor/miscprj/s_context.hc?s1=6&s2=2&s3=3&s4=0&full=0&prjstate=1&nodoc=0 1395 39. http://remtk/solucor/miscprj/s_context.hc?s1=6&s2=2&s3=4&s4=0&full=0&prjstate=1&nodoc=0 1396 40. http://remtk/solucor/miscprj/s_context.hc?s1=6&s2=2&s3=4&s4=1&full=0&prjstate=1&nodoc=0 1397 41. http://remtk/solucor/miscprj/s_context.hc?s1=6&s2=2&s3=4&s4=2&full=0&prjstate=1&nodoc=0 1398 42. http://remtk/solucor/miscprj/s_context.hc?s1=6&s2=2&s3=4&s4=3&full=0&prjstate=1&nodoc=0 1399 43. http://remtk/solucor/miscprj/s_context.hc?s1=7&s2=0&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1400 44. http://remtk/solucor/miscprj/s_context.hc?s1=7&s2=1&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1401 45. http://remtk/solucor/miscprj/s_context.hc?s1=7&s2=2&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1402 46. http://remtk/solucor/miscprj/s_context.hc?s1=7&s2=3&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1403 47. http://remtk/solucor/miscprj/s_context.hc?s1=8&s2=0&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1404 48. http://remtk/solucor/miscprj/s_context.hc?s1=9&s2=0&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1405 49. http://remtk/solucor/miscprj/s_context.hc?s1=10&s2=0&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1406 50. ftp://ftp.solucorp.qc.ca/pub/vserver 1407 51. http://www.solucorp.qc.ca/virtualfs 1408 52. http://www.vmware.com/ 1409 53. ftp://ftp.solucorp.qc.ca/pub/vserver 1410 54. ftp://ftp.solucorp.qc.ca/pub/vserver/kernel-2.4.20ctx-17.tar.gz 1411 55. ftp://ftp.solucorp.qc.ca/pub/vserver/kernel-2.4.20ctxsmp-17.tar.gz 1412 56. ftp://ftp.solucorp.qc.ca/pub/vserver/vserver-0.22-1.src.rpm 1413 57. ftp://ftp.solucorp.qc.ca/pub/vserver/vserver-0.22-1.i386.rpm 1414 58. ftp://ftp.solucorp.qc.ca/pub/vserver/vserver-admin-0.22-1.i386.rpm 1415 59. http://www.solucorp.qc.ca/linuxconf/download.hc 1416 60. ftp://ftp.solucorp.qc.ca/pub/vserver/vserver-0.22.src.tar.gz 1417 61. ftp://ftp.solucorp.qc.ca/pub/vserver/patch-2.4.20ctx-17.gz 1418 62. ftp://ftp.solucorp.qc.ca/pub/vserver/patches 1419 63. mailto:jack@solucorp.qc.ca 1420 64. http://www.solucorp.qc.ca/howto.hc?projet=vserver 1421 65. mailto:vserver@solucorp.qc.ca 1422 66. http://www.solucorp.qc.ca/mlist/index.hc?list=vserver 1423 67. http://www.paul.sladen.org/vserver/archives/ 1424 68. http://www.solucorp.qc.ca/changes.hc?projet=vserver 1425 69. http://www.solucorp.qc.ca/miscprj/s_context.hc 1426 70. http://www.solucorp.qc.ca/tlmp 1427 71. http://remtk/solucor/miscprj/s_context.hc?s1=0&s2=0&s3=0&s4=0&full=0&prjstate=1&nodoc=0 1428 72. http://remtk/solucor/miscprj/s_context.hc 1429 73. http://www.solucorp.qc.ca/tlmp/tlmpdoc.hc 1430 74. mailto:jack@solucorp.qc.ca