Changeset 562
- Timestamp:
- 02/21/07 22:09:28 (2 years ago)
- Files:
-
- trunk/doc/manual/cmdref/vcc.tex (modified) (1 diff)
- trunk/doc/manual/cmdref/vcd.tex (modified) (1 diff)
- trunk/doc/manual/cmdref/vcdadm.tex (modified) (1 diff)
- trunk/doc/manual/cmdref/vce.tex (modified) (1 diff)
- trunk/doc/manual/cmdref/vshelper.tex (modified) (1 diff)
- trunk/doc/manual/intro/intro.tex (modified) (7 diffs)
- trunk/doc/manual/intro/vcd.tex (modified) (12 diffs)
- trunk/doc/manual/intro/vserver.tex (modified) (5 diffs)
- trunk/doc/manual/manual.bib (modified) (1 diff)
- trunk/doc/manual/manual.tex (modified) (4 diffs)
- trunk/doc/manual/rpcref/commands.tex (modified) (3 diffs)
- trunk/doc/manual/rpcref/helper.tex (modified) (1 diff)
- trunk/doc/manual/rpcref/intro.tex (modified) (1 diff)
- trunk/doc/manual/rpcref/vcd.tex (modified) (1 diff)
- trunk/doc/manual/rpcref/vx.tex (modified) (1 diff)
- trunk/doc/manual/rpcref/vxdb.tex (modified) (1 diff)
Legend:
- Unmodified
- Added
- Removed
- Modified
- Copied
- Moved
trunk/doc/manual/cmdref/vcc.tex
r527 r562 1 1 \chapter{VServer Control Client} 2 \label{ch:cmdref:vcc} trunk/doc/manual/cmdref/vcd.tex
r527 r562 1 1 \chapter{VServer Control Daemon} 2 \label{ch:cmdref:vcd} trunk/doc/manual/cmdref/vcdadm.tex
r527 r562 1 1 \chapter{VServer Control Daemon Administration Tool} 2 \label{ch:cmdref:vcdadm} trunk/doc/manual/cmdref/vce.tex
r527 r562 1 1 \chapter{VServer Configuration Editor} 2 \label{ch:cmdref:vce} trunk/doc/manual/cmdref/vshelper.tex
r527 r562 1 1 \chapter{VServer Kernel Helper} 2 \label{ch:cmdref:vshelper} trunk/doc/manual/intro/intro.tex
r522 r562 1 1 \chapter{Introduction to virtualization} 2 2 \label{ch:intro:intro} 3 3 4 4 5 5 \section{What is virtualization?} 6 \label{sec:intro:intro:whatis} 6 7 7 8 Today, virtualization is a broad term that refers to the abstraction computer … … 62 63 63 64 \section{Simulation} 65 \label{sec:intro:intro:simulation} 64 66 65 67 A \textit{computer simulation} is an attempt to model a real-life situation on … … 80 82 81 83 \section{Emulation} 84 \label{sec:intro:intro:emulation} 82 85 83 86 A \textit{Software Emulator} allows computer programs to run on a platform … … 111 114 112 115 \section{Simulation vs. Emulation} 116 \label{sec:intro:intro:simvsemu} 113 117 114 118 There is a lot of confusion between emulators and simulators, in fact, the … … 171 175 172 176 \section{Native Virtualization} 177 \label{sec:intro:intro:native} 173 178 174 179 Native virtualization, in which the Virtual Machine simulates complete hardware … … 196 201 197 202 \section{Para-virtualization} 203 \label{sec:intro:intro:para} 198 204 199 205 However, native virtualization may incur a performance penalty. The VM monitor … … 236 242 237 243 \section{Operating System-Level Virtualization} 244 \label{sec:intro:intro:oslevel} 238 245 239 246 \textit{Operating System-Level Virtualization} is a server virtualization trunk/doc/manual/intro/vcd.tex
r524 r562 1 1 \chapter{The VServer Control Daemon} 2 \label{ch:intro:vcd} 2 3 3 4 4 5 \section{Abstract} 6 \label{sec:intro:vcd:abstract} 5 7 6 8 In order to ease management of Virtual Private Servers a central instance is 7 9 needed to provide an open and well-known \emph{Application Programming 8 Interface (API)}. The \emph{VServer Control Daemon (VCD)} is a daemon running 9 in the host context providing the aforementioned API via \emph{XMLRPC}, a 10 Interface (API)} not only for local, but especially for remote usage and 11 execution. The \emph{VServer Control Daemon (VCD)} is a daemon running 12 in the host context and provides the aforementioned API using \emph{XML-RPC}, a 10 13 simple protocol for \emph{Remote Procedure Calls (RPC)} using the XML Markup 11 14 Language. … … 13 16 14 17 \section{Rationale} 18 \label{sec:intro:vcd:rationale} 15 19 16 20 The current user-space implementation of the Linux-VServer kernel API suffers a … … 26 30 27 31 \section{Architecture} 28 29 The VServer Control Daemon consists of five major parts: the configuration 30 database (\emph{VXDB}), the \emph{XMLRPC Server}, the \emph{XMLRPC Clients}, 31 the \emph{Template Management} as well as a light-weight \emph{Statistics 32 Collector}. 33 34 \begin{figure}[H] 32 \label{sec:intro:vcd:architecture} 33 34 The complete VServer Control Daemon package consists of four independent 35 modules: 36 37 \begin{labeling}[~~]{\labelingfont{vwrappers}} 38 \labelingitem{libvserver} The libvserver module contains a library that implements 39 the Linux-VServer system call in the C language. It provides a convenient 40 way to execute Linux-VServer commands in other programs or libraries. 41 Additionally basic low-level command-line tools are provided to work with 42 these commands. 43 44 \labelingitem{vcd} The VServer Control Daemon module uses -- among other 45 libraries -- libvserver to implement the core of the package. This modules 46 includes the configuration storage backend, the XML-RPC server, 47 command-line clients and the kernel user-space helper. 48 49 \labelingitem{vwrappers} The vwrappers module contains a lot of wrappers for 50 coreutils/util-linux/procps and other system packages. This provides a 51 convenient way to execute commands inside virtual private servers. 52 Additionally, some utilities for the extended filesystem attributes are 53 provided enhancing the versions in libvserver with recursion and various 54 other options. 55 56 \labelingitem{vstatd} The VServer Statistics Daemon module contains a \emph{very} 57 small daemon that keeps track of resource utilization of virtual private 58 servers. For statistical analysis all collected data is stored in a 59 round-robin database (RRD), the industry standard data logging and graphing 60 application. 61 \end{labeling} 62 63 A detailed descriptions of these modules can be found in the next sections. 64 However, the reader may skip to part~\ref{pt:install} on 65 page~\pageref{pt:install} for the installation guide and jump back here 66 occasionally once a more detailed module explanation is needed. 67 68 69 \section{Linux-VServer system call library} 70 \label{sec:intro:vcd:libvserver} 71 72 The Linux-VServer project provides an interface to the various virtualization 73 and configuration commands that have been added to the kernel. This interface 74 between the operating system and the user programs or libraries is known as 75 \emph{system call}. 76 77 For a long time the Linux-VServer project used a few different system calls to 78 accomplish different aspects of virtualization and configuration. However, the 79 number of commands grew rapidly and a few system calls were simply not enough to 80 handle every aspect of virtualization. Therefore, the Linux-VServer system call 81 now uses a system call multiplexer based on a command identifier, which has 82 similar semantics like the \texttt{ioctl} system call. 83 84 The Linux kernel maintainers have reserved a system call number for the 85 Linux-VServer project on most architectures meanwhile and while the opinion on 86 system call multiplexing might differ from developer to developer, it was 87 generally considered a good decision not to have more than one syscall \ldots 88 89 The advantage of different system calls would be simpler handling on different 90 architectures. However, this has not been a problem so far, as the data passed 91 to and from the kernel has strong typed fields conforming to the C99 types. 92 93 The Linux-VServer system call requires three arguments regardless of what the 94 actual command is: 95 96 \begin{quote} 97 \texttt{sys\_vserver(uint32\_t cmd, uint32\_t id, void \_\_user *data);} 98 \end{quote} 99 100 \begin{labeling}{\labelingfont{data}} 101 \labelingitem{cmd} a command number 102 \labelingitem{id} an identifier 103 \labelingitem{data} a user-space data-structure of yet unknown size 104 \end{labeling} 105 106 To allow for some structure for debugging purposes and some kind of command 107 versioning, the command number is split into three parts: the lower 12 bit 108 contain a version number, then 4 bits are reserved, the upper 16 bits are 109 divided into 8 bit for the command number and 6 bit for category number, again 110 reserving 2 bits for the future. 111 112 In theory, there are 64 categories with up to 256 commands in each category, 113 allowing for 4096 revisions of each command, which is far more than will ever be 114 required. 115 116 The following categories and commands are defined in the Linux-VServer 2.2.0 117 release: 118 119 \begin{center} 120 \small 121 \begin{verbatim} 122 |VERSION|CREATE |MODIFY |MIGRATE|CONTROL|EXPERIM| |SPECIAL|SPECIAL| 123 |STATS |DESTROY|ALTER |CHANGE |LIMIT |TEST | | | | 124 |INFO |SETUP | |MOVE | | | | | | 125 -------+-------+-------+-------+-------+-------+-------+ +-------+-------+ 126 SYSTEM |VERSION|VSETUP |VHOST | | | | |DEVICES| | 127 HOST | 00| 01| 02| 03| 04| 05| | 06| 07| 128 -------+-------+-------+-------+-------+-------+-------+ +-------+-------+ 129 CPU | |VPROC |PROCALT|PROCMIG|PROCTRL| | |SCHED. | | 130 PROCESS| 08| 09| 10| 11| 12| 13| | 14| 15| 131 -------+-------+-------+-------+-------+-------+-------+ +-------+-------+ 132 MEMORY | | | | | | | |SWAP | | 133 | 16| 17| 18| 19| 20| 21| | 22| 23| 134 -------+-------+-------+-------+-------+-------+-------+ +-------+-------+ 135 NETWORK| |VNET |NETALT |NETMIG |NETCTL | | |SERIAL | | 136 | 24| 25| 26| 27| 28| 29| | 30| 31| 137 -------+-------+-------+-------+-------+-------+-------+ +-------+-------+ 138 DISK | | | | |DLIMIT | | |INODE | | 139 VFS | 32| 33| 34| 35| 36| 37| | 38| 39| 140 -------+-------+-------+-------+-------+-------+-------+ +-------+-------+ 141 OTHER |VSTAT | | | | | | |VINFO | | 142 | 40| 41| 42| 43| 44| 45| | 46| 47| 143 =======+=======+=======+=======+=======+=======+=======+ +=======+=======+ 144 SPECIAL|EVENT | | | |FLAGS | | | | | 145 | 48| 49| 50| 51| 52| 53| | 54| 55| 146 -------+-------+-------+-------+-------+-------+-------+ +-------+-------+ 147 SPECIAL|DEBUG | | | |RLIMIT |SYSCALL| | |COMPAT | 148 | 56| 57| 58| 59| 60|TEST 61| | 62| 63| 149 -------+-------+-------+-------+-------+-------+-------+ +-------+-------+ 150 \end{verbatim} 151 \end{center} 152 153 While a single system call is advantageous from the kernel point of view, 154 user programs and libraries tend to have a single function per command, although 155 this is not always the case for multiplexed system calls, as can be seen with 156 \texttt{ioctl}. Nevertheless, the libvserver module implements a function for 157 each command the Linux-VServer multiplexer knows about. 158 159 For this purpose, the library uses acustom syscall implementation written by 160 Herbert Pötzl in inline assembler rather than using the syscall macros provided 161 by \texttt{libc} to make the library as self-contained as possible. 162 163 The complete documentation of the libvserver API can be found on the projects 164 website~\cite{libvserver-doc} and is not discussed in further detail here. 165 166 167 \section{VServer Control Daemon} 168 \label{sec:intro:vcd:vcd} 169 170 The Vserver Control Daemon is the core of the the package and implements all 171 aspects of virtual server management using libvserver to issue Linux-VServer 172 system calls, xmlrpc-c to implement the XML-RPC protocol and SQLite3 for 173 data storage. Figure~\ref{fig:vcd-overview} illustrates the basic relationship 174 between libraries, methods and clients. 175 176 \begin{figure}[hbt] 35 177 \center 36 178 \includegraphics[scale=0.4]{intro/vcd} 37 179 \caption{VServer Control Daemon Architecture Overview} 180 \label{fig:vcd-overview} 38 181 \end{figure} 39 182 40 183 41 42 184 \subsection{Configuration Database - VXDB} 43 185 44 186 The configuration database (\emph{VXDB}) stores all virtual private server 45 related configuration data like disk limits, CPU scheduler , or network46 adresses. Furthermore the daemon stores information about its users and their47 permissions as well as owned virtual servers in the database. For convenience48 and size reasons the database is implemented using \emph{SQLite}.49 50 SQLite is a small C library that implements a self-contained, embeddable,187 related configuration data like disk limits, CPU scheduler buckets, or network 188 adresses. Furthermore the daemon stores information about its users and access 189 control as well as owner information in the database. For convenience and size 190 reasons the database is implemented using \emph{SQLite3}. 191 192 SQLite3 is a small C library that implements a self-contained, embeddable, 51 193 zero-configuration SQL database engine. The decision for using SQLite as 52 194 database backend is based on the following key-features of SQLite: … … 66 208 \end{itemize} 67 209 68 \subsection{The XML RPC Server}69 70 The \emph{XML RPC Server} is the core of the VServer Control Daemon and71 implements the XML RPC standard for Remote Procedure Calls (RPC). XMLRPC is a210 \subsection{The XML-RPC Server} 211 212 The \emph{XML-RPC Server} is the core of the VServer Control Daemon and 213 implements the XML-RPC standard for Remote Procedure Calls (RPC). XMLRPC is a 72 214 specification and a set of implementations that allow software running on 73 215 disparate operating systems, running in different environments to make … … 76 218 77 219 78 \subsubsection{The XML RPC Protocol}79 80 XML RPC is a wire protocol that describes an XML serialization format that220 \subsubsection{The XML-RPC Protocol} 221 222 XML-RPC is a wire protocol that describes an XML serialization format that 81 223 clients and servers use to pass remote procedure calls to each other. There are 82 224 two features that make this protocol worth knowing. The first is that the … … 84 226 and servers don't need to be written in the same language. 85 227 86 XMLRPC is designed to be as simple as possible, while allowing complex data 87 structures to be transmitted, processed and returned. 88 89 \begin{figure}[H] 228 XML-RPC is designed to be as simple as possible, while allowing complex data 229 structures to be transmitted, processed and returned. Figure~\ref{fig:xmlrpc} 230 illustrates the serialzation/deserialization in an XML-RPC session. 231 232 \begin{figure}[hbt] 90 233 \center 91 234 \includegraphics[scale=0.5]{intro/xmlrpc} 92 235 \caption{XMLRPC data flow} 236 \label{fig:xmlrpc} 93 237 \end{figure} 94 95 238 96 239 Here are some examples of remote procedure call (RPC) style communications: … … 120 263 121 264 Based on XML nearly any application can be enabled to call methods defined by 122 the XMLRPC Server. The fact that XML is written in plain-text and also easily 123 readable by humans allows tracing and debugging with no additional overhead or 124 learning curve. 125 126 The server defines a global registry of methods accessible by its clients. 127 These methods are devided in several logical parts and seperated by a dot in 128 their method name. For a list of available methods see below. 129 265 the XML-RPC Server. Additionally, the fact that XML is written in plain-text 266 and also easily parsable by humans allows easy tracing and debugging of XML-RPC 267 sessions in case of failure or other strange behaviour. 268 269 On startup, the server defines a global registry of methods accessible by its 270 clients. In order to allow structure for the amount of methods currently 271 defined, all methods are devided in logical units -- also known as namespaces -- 272 and prefixed with the namespace and a dot, like \verb,vx.start, or 273 \verb,helper.shutdown, for the start and shutdown methods of the vx and helper 274 namespace, respectively. 275 276 Refer to part~\ref{pt:rpcref} on page~\pageref{pt:rpcref} for a detailed 277 description of the XML-RPC protocol and the request and response format used 278 for defined methods. 130 279 131 280 \subsubsection{Authentication} … … 134 283 function \emph{WHIRLPOOL}. WHIRLPOOL is a cryptographic hash function designed 135 284 by Vincent Rijmen and Paulo S. L. M. Barreto. The hash has been recommended by 136 the NESSIE project. It has also been adopted by the International Organization285 the NESSIE project. It has also been adopted by the International Organization 137 286 for Standardization (ISO) and the International Electrotechnical Commission 138 287 (IEC) as part of the joint ISO/IEC 10118-3 international standard. … … 144 293 145 294 For security reasons the clear-text password is never stored in VXDB. The 146 client will send the password as plain-text - the server then creates a295 client will send the password as plain-text -- the server then creates a 147 296 WHIRLPOOL hash using the submitted password and compares its result with the 148 hash stored in VXDB. 297 hash stored in VXDB. It is also possible to create the hash on the client side, 298 prefix the result with \verb,WHIRLPOOLENC//, and send the result to the server 299 for authentication. The server then compares the hash after the prefix. 300 301 Note that an attacker can still authenticate against the server with the hash 302 only, he just cannot retreive the original password again. Therefore, the server 303 should \emph{never} listen on an untrusted network if no other security measures 304 have been setup, like an SSL or VPN tunnel. 149 305 150 306 … … 152 308 153 309 For a fine-grained access control the server implements its own set of 154 capabilities. A capability is a lot like the keys on your key ring. As an155 example, consider your car key. It works on a specific car (it designates a 156 particular object), and anyone holding the key can perform certain actions 157 (locking or unlocking the car, starting the car, opening the glove 158 compartment). You can hand your car key to me, after which I can open, lock, or 159 start the car, but only on your car. Holding your car key won't let me test 160 drive my neighbor's Lamborghini. 161 310 capabilities. A capability is a lot like a drivers license. As an example, 311 consider your car license. It allows you to drive a certain set of 312 vehicles (it designates a particular object set, in our case XML-PRC methods), 313 and anyone holding a car license is allowed to drive the same set of objects 314 (cars). 315 316 Refer to part~\ref{pt:rpcref} on page~\pageref{pt:rpcref} for a detailed 317 description of available access restrictions and their usage in defined methods. 162 318 163 319 \subsubsection{Owner Checks} 164 320 165 To ensure the distinction between your car and the Lamborghini another access 166 control system has to be implemented. Therefore the server also implements 167 owner checks for most of its methods. This results in an extension to the 168 capability model explained above. Instead of using one key per car, you can now 169 drive multiple cars using just one key. 170 171 Still, this model has a noticable flaw: Imagine your company has two hundred 172 cars and your top management should have access to all cars. Adding all members 321 To ensure the distinction between your car and your neighbours Lamborghini 322 another access control system has to be implemented. Therefore the server also 323 implements owner checks for most of its methods. This results in an extension to 324 the capability model explained above. The server implements another object set 325 based on the ownership information stored in the database. Instead of allowing 326 everyone holding a certain capability to operate on all virtual servers, only 327 the intersection of both object sets is permitted for operation. 328 329 Still, this model has a noticable flaw: Imagine a company has two hundred cars 330 and the top management should have access to all cars. Adding all members 173 331 of the management to the owner list of every single car can become a pain in 174 the ass very quickly. Therefore the user database in VXDB implements the 175 adminstrator flag. Using this flag all owner checks are passed without even 176 consulting the owner lists in VXDB. 177 178 179 \subsection{XMLRPC Clients} 180 181 The \emph{XMLRPC Clients} on the other hand connect to the XMLRPC Server using 182 the HTTP protocol. They need to pass authentication information, the method 183 name they wish to call and optionally parameters specific to the called method. 332 the ass very quickly. Therefore the user database in VXDB implements an 333 additional configuration option~--~the adminstrator flag. Using this flag all 334 owner checks are passed without even consulting the owner lists in the database. 335 336 337 \subsection{XML-RPC Clients} 338 339 The \emph{XML-RPC Clients} provided in the VServer Control Daemon module 340 provide facilities to connect and execute methods on remote servers. Several 341 clients exist for different purpose, in most cases they are aligned with the 342 method namespaces mentioned above. 343 184 344 It is important to know that the connection between server and client is not 185 345 persistent, i.e. you send one request, get one answer, and the connection will … … 189 349 method specific return value. 190 350 191 351 Refer to part~\ref{pt:rpcref} on page~\pageref{pt:rpcref} for a detailed 352 description of the XML-RPC protocol and the request and response format used 353 for defined methods asw well as error codes and their meaning. 354 355 356 % FIXME: more info needed here 192 357 \subsection{The Template Management} 193 358 … … 198 363 199 364 200 \subsection{The Statistics Collector} 365 % FIXME: more info needed here 366 \section{VServer Statistics Daemon} 367 \label{sec:intro:vcd:vstatd} 201 368 202 369 The \emph{Statistics Collector} is a very light-weight daemon used to collect trunk/doc/manual/intro/vserver.tex
r522 r562 1 1 \chapter{The Linux-VServer Project} 2 \label{ch:intro:vserver} 2 3 3 4 … … 20 21 21 22 \section{Rationale} 23 \label{sec:intro:vserver:rationale} 22 24 23 25 Over the years, computers have become sufficiently powerful to use … … 50 52 51 53 \section{The Concept} 54 \label{sec:intro:vserver:concept} 52 55 53 56 At a basic level, a Linux server consists of three building blocks: hardware, … … 91 94 92 95 \section{Usage Scenarios} 96 \label{sec:intro:vserver:usage} 93 97 94 98 The primary goal of this project is to create virtual servers sharing the same … … 290 294 % TODO: more info needed here 291 295 \section{History} 296 \label{sec:intro:vserver:history} 292 297 293 298 \textbf{Jacques Gélinas} created the VServer project a number of years back. trunk/doc/manual/manual.bib
r518 r562 36 36 37 37 @Misc{wp-iss, 38 author = {Wikipedia}, 39 title = {Instruction Set Simulator --- 40 {W}ikipedia{,} The Free Encyclopedia}, 41 year = {Feb 2007}, 42 note = {\url{http://en.wikipedia.org/wiki/Instruction_Set_Simulator}} 38 author = {Wikipedia}, 39 title = {Instruction Set Simulator -- Wikipedia, The Free Encyclopedia}, 40 year = {Feb 2007}, 41 note = {\url{http://en.wikipedia.org/wiki/Instruction_Set_Simulator}} 43 42 } 44 43 45 44 @Misc{wp-native-virt, 46 author = {Wikipedia}, 47 title = {Native Virtualization --- 48 {W}ikipedia{,} The Free Encyclopedia}, 49 year = {Feb 2007}, 50 note = {\url{http://en.wikipedia.org/wiki/Native_virtualization}} 45 author = {Wikipedia}, 46 title = {Instruction Set Simulator -- Wikipedia, The Free Encyclopedia}, 47 year = {Feb 2007}, 48 note = {\url{http://en.wikipedia.org/wiki/Native_virtualization}} 51 49 } 52 50 53 51 @Misc{wp-os-virt, 54 author = {Wikipedia}, 55 title = {Operating system-level virtualization --- 56 {W}ikipedia{,} The Free Encyclopedia}, 57 year = {2007}, 58 note = {\url{http://en.wikipedia.org/wiki/ 52 author = {Wikipedia}, 53 title = {Instruction Set Simulator -- Wikipedia, The Free Encyclopedia}, 54 year = {2007}, 55 note = {\url{http://en.wikipedia.org/wiki/ 59 56 Operating_system-level_virtualization}} 60 57 } 61 58 62 59 @Misc{emu-vs-simu, 63 author = {Ed Thelen},64 title = {Emulation/Simulation},65 year = {2007},66 note = {\url{http://ed-thelen.org/comp-hist/emulation.html}}60 author = {Ed Thelen}, 61 title = {Emulation/Simulation}, 62 year = {2007}, 63 note = {\url{http://ed-thelen.org/comp-hist/emulation.html}} 67 64 } 68 65 69 66 @Misc{vmware-intro, 70 author = {VMWare Inc.},71 title = {Intro to Virtualization},72 year = {2007},73 note = {\url{http://www.vmware.com/virtualization/}}67 author = {VMWare Inc.}, 68 title = {Intro to Virtualization}, 69 year = {2007}, 70 note = {\url{http://www.vmware.com/virtualization/}} 74 71 } 72 73 @Book{tannenbaum-osdesign, 74 author = {Andrew S. Tannenbaum}, 75 title = {Operating Systems Design and Implementation}, 76 publisher = {Prentice Hall}, 77 year = {2006} 78 } trunk/doc/manual/manual.tex
r528 r562 31 31 \renewcommand{\cftsecaftersnum}{.} 32 32 33 % provide shortcut for nice labels 34 \newcommand{\labelingfont}[1]{\usekomafont{descriptionlabel}#1} 35 \newcommand{\labelingitem}[1]{\item[\labelingfont{#1}]} 36 33 37 \title{VServer Control Daemon\\Reference Manual} 34 38 \author{Benedikt Böhm \texttt{<hollow@gentoo.org>}} … … 46 50 \mainmatter 47 51 \part{Introduction} 52 \label{pt:intro} 48 53 \input{intro/intro.tex} 49 54 \input{intro/vserver.tex} … … 51 56 52 57 \part{Installation} 58 \label{pt:install} 53 59 54 60 \part{Configuration and Maintenance} 61 \label{pt:config} 55 62 56 63 \part{Command Reference} 64 \label{pt:cmdref} 57 65 \input{cmdref/vcc.tex} 58 66 \input{cmdref/vcd.tex} … … 62 70 63 71 \part{XML-RPC Method Reference} 72 \label{pt:rpcref} 64 73 \input{rpcref/commands.tex} 65 74 \input{rpcref/intro.tex} trunk/doc/manual/rpcref/commands.tex
r531 r562 17 17 \end{quote} 18 18 19 \begin{labeling}{00 .00.0000}19 \begin{labeling}{000000000} 20 20 }{ 21 21 \end{labeling} 22 22 } 23 23 24 \newcommand{\rpcparam}[2]{\ item [{\texttt{#1}}] #2}24 \newcommand{\rpcparam}[2]{\labelingitem{#1}{#2}} 25 25 26 26 % access restrictions … … 59 59 \end{quote} 60 60 61 \begin{labeling}{00 .00.0000}61 \begin{labeling}{000000000} 62 62 }{ 63 63 \end{labeling} 64 64 } 65 65 66 \newcommand{\rpcreturnparam}[2]{\ item [{\texttt{#1}}] #2}66 \newcommand{\rpcreturnparam}[2]{\labelingitem{#1}{#2}} 67 67 68 68 % errors … … 79 79 specific errors: 80 80 81 \begin{labeling}{00 .00.0000}81 \begin{labeling}{000000000} 82 82 }{ 83 83 \end{labeling} 84 84 } 85 85 86 \newcommand{\rpcerror}[2]{\ item [{\texttt{#1}}] #2}86 \newcommand{\rpcerror}[2]{\labelingitem{#1}{#2}} trunk/doc/manual/rpcref/helper.tex
r529 r562 1 1 \chapter{Helper Methods} 2 \label{ch:rpcref:helper} 2 3 3 4 trunk/doc/manual/rpcref/intro.tex
r539 r562 1 1 \chapter{Introduction} 2 \label{ch:rpcref:intro} 2 3 3 4 trunk/doc/manual/rpcref/vcd.tex
r529 r562 1 1 \chapter{Daemon Administration Methods} 2 \label{ch:rpcref:vcd} 2 3 3 4 trunk/doc/manual/rpcref/vx.tex
r529 r562 1 1 \chapter{General Maintenance Methods} 2 \label{ch:rpcref:vx} 2 3 3 4 The vx family of functions provide general maintenance facilities for virtual trunk/doc/manual/rpcref/vxdb.tex
r539 r562 1 1 \chapter{Database Manipulation Methods} 2 \label{ch:rpcref:vxdb} 2 3 3 4 The \texttt{vxdb} family of functions provide manipulation facilities for the
