lxc-3.0.1/0000755061062106075000000000000013304304526007312 500000000000000lxc-3.0.1/doc/0000755061062106075000000000000013304304526010057 500000000000000lxc-3.0.1/doc/lxc-config.sgml.in0000644061062106075000000000576013304304316013326 00000000000000 ]> @LXC_GENERATE_DATE@ lxc-config 1 lxc-config query LXC system configuration lxc-config -l item Description lxc-config queries the lxc system configuration and lets you list all valid keys or query individual keys for their value. Options List all supported keys. Query the value of the specified key. &seealso; Author Stéphane Graber stgraber@ubuntu.com lxc-3.0.1/doc/lxc-execute.sgml.in0000644061062106075000000001303713304304316013517 00000000000000 ]> @LXC_GENERATE_DATE@ lxc-execute 1 lxc-execute run an application inside a container. lxc-execute -n name -d -f config_file -s KEY=VAL -- command Description lxc-execute runs the specified command inside the container specified by name. It will setup the container according to the configuration previously defined with the lxc-create command or with the configuration file parameter. If no configuration is defined, the default isolation is used. This command is mainly used when you want to quickly launch an application in an isolated environment. lxc-execute command will run the specified command into the container via an intermediate process, lxc-init. This lxc-init after launching the specified command, will wait for its end and all other reparented processes. (to support daemons in the container). In other words, in the container, lxc-init has the pid 1 and the first process of the application has the pid 2. The above lxc-init is designed to forward received signals to the started command. Options Specify the configuration file to configure the virtualization and isolation functionalities for the container. This configuration file if present will be used even if there is already a configuration file present in the previously created container (via lxc-create). Assign value VAL to configuration variable KEY. This overrides any assignment done in config_file. Run the container as a daemon. As the container has no more tty, if an error occurs nothing will be displayed, the log file can be used to check the error. Signal the end of options and disables further option processing. Any arguments after the -- are treated as arguments to command. This option is useful when you want specify options to command and don't want lxc-execute to interpret them. &commonoptions; Diagnostic The container is busy The specified container is already running an application. You should stop it before reuse this container or create a new one. &seealso; Author Daniel Lezcano daniel.lezcano@free.fr lxc-3.0.1/doc/lxc.sgml.in0000644061062106075000000003555213304304316012065 00000000000000 ]> @LXC_GENERATE_DATE@ lxc 7 Version @PACKAGE_VERSION@ lxc linux containers Overview The container technology is actively being pushed into the mainstream Linux kernel. It provides resource management through control groups and resource isolation via namespaces. lxc, aims to use these new functionalities to provide a userspace container object which provides full resource isolation and resource control for an applications or a full system. lxc is small enough to easily manage a container with simple command lines and complete enough to be used for other purposes. Requirements The kernel version >= 3.10 shipped with the distros, will work with lxc, this one will have less functionalities but enough to be interesting. lxc relies on a set of functionalities provided by the kernel. The helper script lxc-checkconfig will give you information about your kernel configuration, required, and missing features. Functional specification A container is an object isolating some resources of the host, for the application or system running in it. The application / system will be launched inside a container specified by a configuration that is either initially created or passed as a parameter of the commands. How to run an application in a container Before running an application, you should know what are the resources you want to isolate. The default configuration is to isolate PIDs, the sysv IPC and mount points. If you want to run a simple shell inside a container, a basic configuration is needed, especially if you want to share the rootfs. If you want to run an application like sshd, you should provide a new network stack and a new hostname. If you want to avoid conflicts with some files eg. /var/run/httpd.pid, you should remount /var/run with an empty directory. If you want to avoid the conflicts in all the cases, you can specify a rootfs for the container. The rootfs can be a directory tree, previously bind mounted with the initial rootfs, so you can still use your distro but with your own /etc and /home Here is an example of directory tree for sshd: [root@lxc sshd]$ tree -d rootfs rootfs |-- bin |-- dev | |-- pts | `-- shm | `-- network |-- etc | `-- ssh |-- lib |-- proc |-- root |-- sbin |-- sys |-- usr `-- var |-- empty | `-- sshd |-- lib | `-- empty | `-- sshd `-- run `-- sshd and the mount points file associated with it: [root@lxc sshd]$ cat fstab /lib /home/root/sshd/rootfs/lib none ro,bind 0 0 /bin /home/root/sshd/rootfs/bin none ro,bind 0 0 /usr /home/root/sshd/rootfs/usr none ro,bind 0 0 /sbin /home/root/sshd/rootfs/sbin none ro,bind 0 0 How to run a system in a container Running a system inside a container is paradoxically easier than running an application. Why? Because you don't have to care about the resources to be isolated, everything needs to be isolated, the other resources are specified as being isolated but without configuration because the container will set them up. eg. the ipv4 address will be setup by the system container init scripts. Here is an example of the mount points file: [root@lxc debian]$ cat fstab /dev /home/root/debian/rootfs/dev none bind 0 0 /dev/pts /home/root/debian/rootfs/dev/pts none bind 0 0 Container life cycle When the container is created, it contains the configuration information. When a process is launched, the container will be starting and running. When the last process running inside the container exits, the container is stopped. In case of failure when the container is initialized, it will pass through the aborting state. Configuration The container is configured through a configuration file, the format of the configuration file is described in lxc.conf 5 Creating / Destroying containers A persistent container object can be created via the lxc-create command. It takes a container name as parameter and optional configuration file and template. The name is used by the different commands to refer to this container. The lxc-destroy command will destroy the container object. lxc-create -n foo lxc-destroy -n foo Volatile container It is not mandatory to create a container object before starting it. The container can be directly started with a configuration file as parameter. Starting / Stopping container When the container has been created, it is ready to run an application / system. This is the purpose of the lxc-execute and lxc-start commands. If the container was not created before starting the application, the container will use the configuration file passed as parameter to the command, and if there is no such parameter either, then it will use a default isolation. If the application ended, the container will be stopped, but if needed the lxc-stop command can be used to stop the container. Running an application inside a container is not exactly the same thing as running a system. For this reason, there are two different commands to run an application into a container: lxc-execute -n foo [-f config] /bin/bash lxc-start -n foo [-f config] [/bin/bash] The lxc-execute command will run the specified command into a container via an intermediate process, lxc-init. This lxc-init after launching the specified command, will wait for its end and all other reparented processes. (to support daemons in the container). In other words, in the container, lxc-init has PID 1 and the first process of the application has PID 2. The lxc-start command will directly run the specified command in the container. The PID of the first process is 1. If no command is specified lxc-start will run the command defined in lxc.init.cmd or if not set, /sbin/init . To summarize, lxc-execute is for running an application and lxc-start is better suited for running a system. If the application is no longer responding, is inaccessible or is not able to finish by itself, a wild lxc-stop command will kill all the processes in the container without pity. lxc-stop -n foo -k Connect to an available tty If the container is configured with ttys, it is possible to access it through them. It is up to the container to provide a set of available ttys to be used by the following command. When the tty is lost, it is possible to reconnect to it without login again. lxc-console -n foo -t 3 Freeze / Unfreeze container Sometime, it is useful to stop all the processes belonging to a container, eg. for job scheduling. The commands: lxc-freeze -n foo will put all the processes in an uninteruptible state and lxc-unfreeze -n foo will resume them. This feature is enabled if the freezer cgroup v1 controller is enabled in the kernel. Getting information about container When there are a lot of containers, it is hard to follow what has been created or destroyed, what is running or what are the PIDs running in a specific container. For this reason, the following commands may be useful: lxc-ls -f lxc-info -n foo lxc-ls lists containers. lxc-info gives information for a specific container. Here is an example on how the combination of these commands allows one to list all the containers and retrieve their state. for i in $(lxc-ls -1); do lxc-info -n $i done Monitoring container It is sometime useful to track the states of a container, for example to monitor it or just to wait for a specific state in a script. lxc-monitor command will monitor one or several containers. The parameter of this command accepts a regular expression for example: lxc-monitor -n "foo|bar" will monitor the states of containers named 'foo' and 'bar', and: lxc-monitor -n ".*" will monitor all the containers. For a container 'foo' starting, doing some work and exiting, the output will be in the form: 'foo' changed state to [STARTING] 'foo' changed state to [RUNNING] 'foo' changed state to [STOPPING] 'foo' changed state to [STOPPED] lxc-wait command will wait for a specific state change and exit. This is useful for scripting to synchronize the launch of a container or the end. The parameter is an ORed combination of different states. The following example shows how to wait for a container if it successfully started as a daemon. cgroup settings for containers The container is tied with the control groups, when a container is started a control group is created and associated with it. The control group properties can be read and modified when the container is running by using the lxc-cgroup command. lxc-cgroup command is used to set or get a control group subsystem which is associated with a container. The subsystem name is handled by the user, the command won't do any syntax checking on the subsystem name, if the subsystem name does not exists, the command will fail. lxc-cgroup -n foo cpuset.cpus will display the content of this subsystem. lxc-cgroup -n foo cpu.shares 512 will set the subsystem to the specified value. &seealso; Author Daniel Lezcano daniel.lezcano@free.fr Christian Brauner christian.brauner@ubuntu.com Serge Hallyn serge@hallyn.com Stéphane Graber stgraber@ubuntu.com lxc-3.0.1/doc/examples/0000755061062106075000000000000013304304526011675 500000000000000lxc-3.0.1/doc/examples/seccomp-v2-blacklist.conf0000644061062106075000000000051613304304316016407 000000000000002 blacklist # v2 allows comments after the second line, with '#' in first column, # blacklist will allow syscalls by default # if 'errno 0' was not appended to 'mknod' below, then the task would # simply be killed when it tried to mknod. 'errno 0' means do not allow # the container to mknod, but immediately return 0. mknod errno 0 lxc-3.0.1/doc/examples/lxc-phys.conf.in0000644061062106075000000000046113304304316014636 00000000000000# Container with network virtualized using a physical network device with name # 'eth0' lxc.uts.name = gamma lxc.net.0.type = phys lxc.net.0.flags = up lxc.net.0.link = eth0 lxc.net.0.hwaddr = 4a:49:43:49:79:ff lxc.net.0.ipv4.address = 10.2.3.6/24 lxc.net.0.ipv6.address = 2003:db8:1:0:214:1234:fe0b:3297 lxc-3.0.1/doc/examples/lxc-macvlan.conf.in0000644061062106075000000000044113304304316015272 00000000000000# Container with network virtualized using the macvlan device driver lxc.uts.name = alpha lxc.net.0.type = macvlan lxc.net.0.flags = up lxc.net.0.link = eth0 lxc.net.0.hwaddr = 4a:49:43:49:79:bd lxc.net.0.ipv4.address = 10.2.3.4/24 lxc.net.0.ipv6.address = 2003:db8:1:0:214:1234:fe0b:3596 lxc-3.0.1/doc/examples/lxc-empty-netns.conf.in0000644061062106075000000000016713304304316016141 00000000000000# Container with new network withtout network devices lxc.uts.name = omega lxc.net.0.type = empty lxc.net.0.flags = up lxc-3.0.1/doc/examples/lxc-no-netns.conf.in0000644061062106075000000000012413304304316015410 00000000000000# Container with non-virtualized network lxc.net.0.type = none lxc.uts.name = delta lxc-3.0.1/doc/examples/seccomp-v1.conf0000644061062106075000000000255213304304316014442 000000000000001 whitelist 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 lxc-3.0.1/doc/examples/lxc-veth.conf.in0000644061062106075000000000051413304304316014620 00000000000000# Container with network virtualized using a pre-configured bridge named br0 and # veth pair virtual network devices lxc.uts.name = beta lxc.net.0.type = veth lxc.net.0.flags = up lxc.net.0.link = br0 lxc.net.0.hwaddr = 4a:49:43:49:79:bf lxc.net.0.ipv4.address = 10.2.3.5/24 lxc.net.0.ipv6.address = 2003:db8:1:0:214:1234:fe0b:3597 lxc-3.0.1/doc/examples/Makefile.in0000644061062106075000000004355013304304327013670 00000000000000# Makefile.in generated by automake 1.15.1 from Makefile.am. # @configure_input@ # Copyright (C) 1994-2017 Free Software Foundation, Inc. # This Makefile.in is free software; the Free Software Foundation # gives unlimited permission to copy and/or distribute it, # with or without modifications, as long as this notice is preserved. # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY, to the extent permitted by law; without # even the implied warranty of MERCHANTABILITY or FITNESS FOR A # PARTICULAR PURPOSE. @SET_MAKE@ VPATH = @srcdir@ am__is_gnu_make = { \ if test -z '$(MAKELEVEL)'; then \ false; \ elif test -n '$(MAKE_HOST)'; then \ true; \ elif test -n '$(MAKE_VERSION)' && test -n '$(CURDIR)'; then \ true; \ else \ false; \ fi; \ } am__make_running_with_option = \ case $${target_option-} in \ ?) ;; \ *) echo "am__make_running_with_option: internal error: invalid" \ "target option '$${target_option-}' specified" >&2; \ exit 1;; \ esac; \ has_opt=no; \ sane_makeflags=$$MAKEFLAGS; \ if $(am__is_gnu_make); then \ sane_makeflags=$$MFLAGS; \ else \ case $$MAKEFLAGS in \ *\\[\ \ ]*) \ bs=\\; \ sane_makeflags=`printf '%s\n' "$$MAKEFLAGS" \ | sed "s/$$bs$$bs[$$bs $$bs ]*//g"`;; \ esac; \ fi; \ skip_next=no; \ strip_trailopt () \ { \ flg=`printf '%s\n' "$$flg" | sed "s/$$1.*$$//"`; \ }; \ for flg in $$sane_makeflags; do \ test $$skip_next = yes && { skip_next=no; continue; }; \ case $$flg in \ *=*|--*) continue;; \ -*I) strip_trailopt 'I'; skip_next=yes;; \ -*I?*) strip_trailopt 'I';; \ -*O) strip_trailopt 'O'; skip_next=yes;; \ -*O?*) strip_trailopt 'O';; \ -*l) strip_trailopt 'l'; skip_next=yes;; \ -*l?*) strip_trailopt 'l';; \ -[dEDm]) skip_next=yes;; \ -[JT]) skip_next=yes;; \ esac; \ case $$flg in \ *$$target_option*) has_opt=yes; break;; \ esac; \ done; \ test $$has_opt = yes am__make_dryrun = (target_option=n; $(am__make_running_with_option)) am__make_keepgoing = (target_option=k; $(am__make_running_with_option)) pkgdatadir = $(datadir)/@PACKAGE@ pkgincludedir = $(includedir)/@PACKAGE@ pkglibdir = $(libdir)/@PACKAGE@ pkglibexecdir = $(libexecdir)/@PACKAGE@ am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd install_sh_DATA = $(install_sh) -c -m 644 install_sh_PROGRAM = $(install_sh) -c install_sh_SCRIPT = $(install_sh) -c INSTALL_HEADER = $(INSTALL_DATA) transform = $(program_transform_name) NORMAL_INSTALL = : PRE_INSTALL = : POST_INSTALL = : NORMAL_UNINSTALL = : PRE_UNINSTALL = : POST_UNINSTALL = : build_triplet = @build@ host_triplet = @host@ subdir = doc/examples ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 am__aclocal_m4_deps = $(top_srcdir)/config/acinclude.m4 \ $(top_srcdir)/config/ax_pthread.m4 \ $(top_srcdir)/config/libtool.m4 \ $(top_srcdir)/config/ltoptions.m4 \ $(top_srcdir)/config/ltsugar.m4 \ $(top_srcdir)/config/ltversion.m4 \ $(top_srcdir)/config/lt~obsolete.m4 \ $(top_srcdir)/config/tls.m4 $(top_srcdir)/configure.ac am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \ $(ACLOCAL_M4) DIST_COMMON = $(srcdir)/Makefile.am $(am__DIST_COMMON) mkinstalldirs = $(install_sh) -d CONFIG_HEADER = $(top_builddir)/src/config.h CONFIG_CLEAN_FILES = lxc-macvlan.conf lxc-vlan.conf lxc-no-netns.conf \ lxc-empty-netns.conf lxc-phys.conf lxc-veth.conf \ lxc-complex.conf CONFIG_CLEAN_VPATH_FILES = AM_V_P = $(am__v_P_@AM_V@) am__v_P_ = $(am__v_P_@AM_DEFAULT_V@) am__v_P_0 = false am__v_P_1 = : AM_V_GEN = $(am__v_GEN_@AM_V@) am__v_GEN_ = $(am__v_GEN_@AM_DEFAULT_V@) am__v_GEN_0 = @echo " GEN " $@; am__v_GEN_1 = AM_V_at = $(am__v_at_@AM_V@) am__v_at_ = $(am__v_at_@AM_DEFAULT_V@) am__v_at_0 = @ am__v_at_1 = SOURCES = DIST_SOURCES = am__can_run_installinfo = \ case $$AM_UPDATE_INFO_DIR in \ n|no|NO) false;; \ *) (install-info --version) >/dev/null 2>&1;; \ esac am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`; am__vpath_adj = case $$p in \ $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \ *) f=$$p;; \ esac; am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`; am__install_max = 40 am__nobase_strip_setup = \ srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'` am__nobase_strip = \ for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||" am__nobase_list = $(am__nobase_strip_setup); \ for p in $$list; do echo "$$p $$p"; done | \ sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \ $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \ if (++n[$$2] == $(am__install_max)) \ { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \ END { for (dir in files) print dir, files[dir] }' am__base_list = \ sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \ sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g' am__uninstall_files_from_dir = { \ test -z "$$files" \ || { test ! -d "$$dir" && test ! -f "$$dir" && test ! -r "$$dir"; } \ || { echo " ( cd '$$dir' && rm -f" $$files ")"; \ $(am__cd) "$$dir" && rm -f $$files; }; \ } am__installdirs = "$(DESTDIR)$(pkgexamplesdir)" DATA = $(noinst_DATA) $(pkgexamples_DATA) am__tagged_files = $(HEADERS) $(SOURCES) $(TAGS_FILES) $(LISP) am__DIST_COMMON = $(srcdir)/Makefile.in $(srcdir)/lxc-complex.conf.in \ $(srcdir)/lxc-empty-netns.conf.in \ $(srcdir)/lxc-macvlan.conf.in $(srcdir)/lxc-no-netns.conf.in \ $(srcdir)/lxc-phys.conf.in $(srcdir)/lxc-veth.conf.in \ $(srcdir)/lxc-vlan.conf.in DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) ACLOCAL = @ACLOCAL@ AMTAR = @AMTAR@ AM_DEFAULT_VERBOSITY = @AM_DEFAULT_VERBOSITY@ AR = @AR@ AUTOCONF = @AUTOCONF@ AUTOHEADER = @AUTOHEADER@ AUTOMAKE = @AUTOMAKE@ AWK = @AWK@ BINDIR = @BINDIR@ CAP_LIBS = @CAP_LIBS@ CC = @CC@ CCDEPMODE = @CCDEPMODE@ CFLAGS = @CFLAGS@ CPP = @CPP@ CPPFLAGS = @CPPFLAGS@ CYGPATH_W = @CYGPATH_W@ DATADIR = @DATADIR@ DEFAULT_CGROUP_PATTERN = @DEFAULT_CGROUP_PATTERN@ DEFS = @DEFS@ DEPDIR = @DEPDIR@ DLLTOOL = @DLLTOOL@ DOCDIR = @DOCDIR@ DSYMUTIL = @DSYMUTIL@ DUMPBIN = @DUMPBIN@ ECHO_C = @ECHO_C@ ECHO_N = @ECHO_N@ ECHO_T = @ECHO_T@ EGREP = @EGREP@ EXEEXT = @EXEEXT@ FGREP = @FGREP@ GNUTLS_LIBS = @GNUTLS_LIBS@ GREP = @GREP@ HAVE_DOXYGEN = @HAVE_DOXYGEN@ INCLUDEDIR = @INCLUDEDIR@ INSTALL = @INSTALL@ INSTALL_DATA = @INSTALL_DATA@ INSTALL_PROGRAM = @INSTALL_PROGRAM@ INSTALL_SCRIPT = @INSTALL_SCRIPT@ INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@ LD = @LD@ LDFLAGS = @LDFLAGS@ LIBDIR = @LIBDIR@ LIBEXECDIR = @LIBEXECDIR@ LIBOBJS = @LIBOBJS@ LIBS = @LIBS@ LIBTOOL = @LIBTOOL@ LIBTOOL_DEPS = @LIBTOOL_DEPS@ LIPO = @LIPO@ LN_S = @LN_S@ LOCALSTATEDIR = @LOCALSTATEDIR@ LOGPATH = @LOGPATH@ LTLIBOBJS = @LTLIBOBJS@ LT_SYS_LIBRARY_PATH = @LT_SYS_LIBRARY_PATH@ LXCBINHOOKDIR = @LXCBINHOOKDIR@ LXCHOOKDIR = @LXCHOOKDIR@ LXCINITDIR = @LXCINITDIR@ LXCPATH = @LXCPATH@ LXCROOTFSMOUNT = @LXCROOTFSMOUNT@ LXCTEMPLATECONFIG = @LXCTEMPLATECONFIG@ LXCTEMPLATEDIR = @LXCTEMPLATEDIR@ LXC_ABI = @LXC_ABI@ LXC_ABI_MAJOR = @LXC_ABI_MAJOR@ LXC_ABI_MICRO = @LXC_ABI_MICRO@ LXC_ABI_MINOR = @LXC_ABI_MINOR@ LXC_DEFAULT_CONFIG = @LXC_DEFAULT_CONFIG@ LXC_DEVEL = @LXC_DEVEL@ LXC_DISTRO_SYSCONF = @LXC_DISTRO_SYSCONF@ LXC_GENERATE_DATE = @LXC_GENERATE_DATE@ LXC_GLOBAL_CONF = @LXC_GLOBAL_CONF@ LXC_USERNIC_CONF = @LXC_USERNIC_CONF@ LXC_USERNIC_DB = @LXC_USERNIC_DB@ LXC_VERSION = @LXC_VERSION@ LXC_VERSION_BASE = @LXC_VERSION_BASE@ LXC_VERSION_BETA = @LXC_VERSION_BETA@ LXC_VERSION_MAJOR = @LXC_VERSION_MAJOR@ LXC_VERSION_MICRO = @LXC_VERSION_MICRO@ LXC_VERSION_MINOR = @LXC_VERSION_MINOR@ MAKEINFO = @MAKEINFO@ MANIFEST_TOOL = @MANIFEST_TOOL@ MKDIR_P = @MKDIR_P@ NM = @NM@ NMEDIT = @NMEDIT@ OBJDUMP = @OBJDUMP@ OBJEXT = @OBJEXT@ OTOOL = @OTOOL@ OTOOL64 = @OTOOL64@ PACKAGE = @PACKAGE@ PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@ PACKAGE_NAME = @PACKAGE_NAME@ PACKAGE_STRING = @PACKAGE_STRING@ PACKAGE_TARNAME = @PACKAGE_TARNAME@ PACKAGE_URL = @PACKAGE_URL@ PACKAGE_VERSION = @PACKAGE_VERSION@ PAM_CFLAGS = @PAM_CFLAGS@ PAM_LIBS = @PAM_LIBS@ PATH_SEPARATOR = @PATH_SEPARATOR@ PKG_CONFIG = @PKG_CONFIG@ PKG_CONFIG_LIBDIR = @PKG_CONFIG_LIBDIR@ PKG_CONFIG_PATH = @PKG_CONFIG_PATH@ PREFIX = @PREFIX@ PTHREAD_CC = @PTHREAD_CC@ PTHREAD_CFLAGS = @PTHREAD_CFLAGS@ PTHREAD_LIBS = @PTHREAD_LIBS@ RANLIB = @RANLIB@ RUNTIME_PATH = @RUNTIME_PATH@ SBINDIR = @SBINDIR@ SECCOMP_CFLAGS = @SECCOMP_CFLAGS@ SECCOMP_LIBS = @SECCOMP_LIBS@ SED = @SED@ SELINUX_LIBS = @SELINUX_LIBS@ SET_MAKE = @SET_MAKE@ SHELL = @SHELL@ STRIP = @STRIP@ SYSCONFDIR = @SYSCONFDIR@ SYSTEMD_UNIT_DIR = @SYSTEMD_UNIT_DIR@ VERSION = @VERSION@ abs_builddir = @abs_builddir@ abs_srcdir = @abs_srcdir@ abs_top_builddir = @abs_top_builddir@ abs_top_srcdir = @abs_top_srcdir@ ac_ct_AR = @ac_ct_AR@ ac_ct_CC = @ac_ct_CC@ ac_ct_DUMPBIN = @ac_ct_DUMPBIN@ am__include = @am__include@ am__leading_dot = @am__leading_dot@ am__quote = @am__quote@ am__tar = @am__tar@ am__untar = @am__untar@ ax_pthread_config = @ax_pthread_config@ bashcompdir = @bashcompdir@ bindir = @bindir@ build = @build@ build_alias = @build_alias@ build_cpu = @build_cpu@ build_os = @build_os@ build_vendor = @build_vendor@ builddir = @builddir@ datadir = @datadir@ datarootdir = @datarootdir@ db2xman = @db2xman@ docdir = @docdir@ docdtd = @docdtd@ dvidir = @dvidir@ exec_prefix = @exec_prefix@ host = @host@ host_alias = @host_alias@ host_cpu = @host_cpu@ host_os = @host_os@ host_vendor = @host_vendor@ htmldir = @htmldir@ includedir = @includedir@ infodir = @infodir@ install_sh = @install_sh@ libdir = @libdir@ libexecdir = @libexecdir@ localedir = @localedir@ localstatedir = @localstatedir@ mandir = @mandir@ mkdir_p = @mkdir_p@ oldincludedir = @oldincludedir@ pamdir = @pamdir@ pdfdir = @pdfdir@ prefix = @prefix@ program_transform_name = @program_transform_name@ psdir = @psdir@ runstatedir = @runstatedir@ sbindir = @sbindir@ sharedstatedir = @sharedstatedir@ srcdir = @srcdir@ sysconfdir = @sysconfdir@ target_alias = @target_alias@ top_build_prefix = @top_build_prefix@ top_builddir = @top_builddir@ top_srcdir = @top_srcdir@ @ENABLE_EXAMPLES_TRUE@pkgexamplesdir = $(docdir)/examples @ENABLE_EXAMPLES_TRUE@pkgexamples_DATA = \ @ENABLE_EXAMPLES_TRUE@ lxc-macvlan.conf \ @ENABLE_EXAMPLES_TRUE@ lxc-vlan.conf \ @ENABLE_EXAMPLES_TRUE@ lxc-no-netns.conf \ @ENABLE_EXAMPLES_TRUE@ lxc-empty-netns.conf \ @ENABLE_EXAMPLES_TRUE@ lxc-phys.conf \ @ENABLE_EXAMPLES_TRUE@ lxc-veth.conf \ @ENABLE_EXAMPLES_TRUE@ lxc-complex.conf \ @ENABLE_EXAMPLES_TRUE@ seccomp-v1.conf \ @ENABLE_EXAMPLES_TRUE@ seccomp-v2-blacklist.conf \ @ENABLE_EXAMPLES_TRUE@ seccomp-v2.conf noinst_DATA = \ lxc-macvlan.conf.in \ lxc-vlan.conf.in \ lxc-empty-netns.conf.in \ lxc-no-netns.conf.in \ lxc-phys.conf.in \ lxc-veth.conf.in \ lxc-complex.conf.in \ seccomp-v1.conf \ seccomp-v2-blacklist.conf \ seccomp-v2.conf EXTRA_DIST = \ seccomp-v1.conf \ seccomp-v2-blacklist.conf \ seccomp-v2.conf all: all-am .SUFFIXES: $(srcdir)/Makefile.in: $(srcdir)/Makefile.am $(am__configure_deps) @for dep in $?; do \ case '$(am__configure_deps)' in \ *$$dep*) \ ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \ && { if test -f $@; then exit 0; else break; fi; }; \ exit 1;; \ esac; \ done; \ echo ' cd $(top_srcdir) && $(AUTOMAKE) --gnu doc/examples/Makefile'; \ $(am__cd) $(top_srcdir) && \ $(AUTOMAKE) --gnu doc/examples/Makefile Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status @case '$?' in \ *config.status*) \ cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \ *) \ echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \ cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \ esac; $(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES) cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh $(top_srcdir)/configure: $(am__configure_deps) cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh $(ACLOCAL_M4): $(am__aclocal_m4_deps) cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh $(am__aclocal_m4_deps): lxc-macvlan.conf: $(top_builddir)/config.status $(srcdir)/lxc-macvlan.conf.in cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ lxc-vlan.conf: $(top_builddir)/config.status $(srcdir)/lxc-vlan.conf.in cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ lxc-no-netns.conf: $(top_builddir)/config.status $(srcdir)/lxc-no-netns.conf.in cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ lxc-empty-netns.conf: $(top_builddir)/config.status $(srcdir)/lxc-empty-netns.conf.in cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ lxc-phys.conf: $(top_builddir)/config.status $(srcdir)/lxc-phys.conf.in cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ lxc-veth.conf: $(top_builddir)/config.status $(srcdir)/lxc-veth.conf.in cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ lxc-complex.conf: $(top_builddir)/config.status $(srcdir)/lxc-complex.conf.in cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ mostlyclean-libtool: -rm -f *.lo clean-libtool: -rm -rf .libs _libs install-pkgexamplesDATA: $(pkgexamples_DATA) @$(NORMAL_INSTALL) @list='$(pkgexamples_DATA)'; test -n "$(pkgexamplesdir)" || list=; \ if test -n "$$list"; then \ echo " $(MKDIR_P) '$(DESTDIR)$(pkgexamplesdir)'"; \ $(MKDIR_P) "$(DESTDIR)$(pkgexamplesdir)" || exit 1; \ fi; \ for p in $$list; do \ if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \ echo "$$d$$p"; \ done | $(am__base_list) | \ while read files; do \ echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(pkgexamplesdir)'"; \ $(INSTALL_DATA) $$files "$(DESTDIR)$(pkgexamplesdir)" || exit $$?; \ done uninstall-pkgexamplesDATA: @$(NORMAL_UNINSTALL) @list='$(pkgexamples_DATA)'; test -n "$(pkgexamplesdir)" || list=; \ files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \ dir='$(DESTDIR)$(pkgexamplesdir)'; $(am__uninstall_files_from_dir) tags TAGS: ctags CTAGS: cscope cscopelist: distdir: $(DISTFILES) @srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \ topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \ list='$(DISTFILES)'; \ dist_files=`for file in $$list; do echo $$file; done | \ sed -e "s|^$$srcdirstrip/||;t" \ -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \ case $$dist_files in \ */*) $(MKDIR_P) `echo "$$dist_files" | \ sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \ sort -u` ;; \ esac; \ for file in $$dist_files; do \ if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \ if test -d $$d/$$file; then \ dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \ if test -d "$(distdir)/$$file"; then \ find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \ fi; \ if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \ cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \ find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \ fi; \ cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \ else \ test -f "$(distdir)/$$file" \ || cp -p $$d/$$file "$(distdir)/$$file" \ || exit 1; \ fi; \ done check-am: all-am check: check-am all-am: Makefile $(DATA) installdirs: for dir in "$(DESTDIR)$(pkgexamplesdir)"; do \ test -z "$$dir" || $(MKDIR_P) "$$dir"; \ done install: install-am install-exec: install-exec-am install-data: install-data-am uninstall: uninstall-am install-am: all-am @$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am installcheck: installcheck-am install-strip: if test -z '$(STRIP)'; then \ $(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \ install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \ install; \ else \ $(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \ install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \ "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'" install; \ fi mostlyclean-generic: clean-generic: distclean-generic: -test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES) -test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES) maintainer-clean-generic: @echo "This command is intended for maintainers to use" @echo "it deletes files that may require special tools to rebuild." clean: clean-am clean-am: clean-generic clean-libtool mostlyclean-am distclean: distclean-am -rm -f Makefile distclean-am: clean-am distclean-generic dvi: dvi-am dvi-am: html: html-am html-am: info: info-am info-am: install-data-am: install-pkgexamplesDATA install-dvi: install-dvi-am install-dvi-am: install-exec-am: install-html: install-html-am install-html-am: install-info: install-info-am install-info-am: install-man: install-pdf: install-pdf-am install-pdf-am: install-ps: install-ps-am install-ps-am: installcheck-am: maintainer-clean: maintainer-clean-am -rm -f Makefile maintainer-clean-am: distclean-am maintainer-clean-generic mostlyclean: mostlyclean-am mostlyclean-am: mostlyclean-generic mostlyclean-libtool pdf: pdf-am pdf-am: ps: ps-am ps-am: uninstall-am: uninstall-pkgexamplesDATA .MAKE: install-am install-strip .PHONY: all all-am check check-am clean clean-generic clean-libtool \ cscopelist-am ctags-am distclean distclean-generic \ distclean-libtool distdir dvi dvi-am html html-am info info-am \ install install-am install-data install-data-am install-dvi \ install-dvi-am install-exec install-exec-am install-html \ install-html-am install-info install-info-am install-man \ install-pdf install-pdf-am install-pkgexamplesDATA install-ps \ install-ps-am install-strip installcheck installcheck-am \ installdirs maintainer-clean maintainer-clean-generic \ mostlyclean mostlyclean-generic mostlyclean-libtool pdf pdf-am \ ps ps-am tags-am uninstall uninstall-am \ uninstall-pkgexamplesDATA .PRECIOUS: Makefile # Tell versions [3.59,3.63) of GNU make to not export all variables. # Otherwise a system limit (for SysV at least) may be exceeded. .NOEXPORT: lxc-3.0.1/doc/examples/seccomp-v2.conf0000644061062106075000000000122313304304316014435 000000000000002 whitelist trap # 'whitelist' would normally mean kill a task doing any syscall which is not # whitelisted below. By appending 'trap' to the line, we will cause a SIGSYS # to be sent to the task instead. 'errno 0' would mean don't allow the system # call but immediately return 0. 'errno 22' would mean return EINVAL immediately. [x86_64] open close read write mount umount2 # Since we are listing system calls by name, we can also ask to have them resolved # for another arch, i.e. for 32/64-bit versions. [x86] open close read write mount umount2 # Do note that this policy does not whitelist enough system calls to allow a # system container to boot. lxc-3.0.1/doc/examples/lxc-vlan.conf.in0000644061062106075000000000046413304304316014616 00000000000000# Container with network virtualized using the vlan device driver lxc.uts.name = alpha lxc.net.0.type = vlan lxc.net.0.vlan.id = 1234 lxc.net.0.flags = up lxc.net.0.link = eth0 lxc.net.0.hwaddr = 4a:49:43:49:79:bd lxc.net.0.ipv4.address = 10.2.3.4/24 lxc.net.0.ipv6.address = 2003:db8:1:0:214:1234:fe0b:3596 lxc-3.0.1/doc/examples/lxc-complex.conf.in0000644061062106075000000000131013304304316015314 00000000000000# Container with network a complex network mixing macvlan, veth and # physical network devices lxc.uts.name = complex lxc.net.0.type = veth lxc.net.0.flags = up lxc.net.0.link = br0 lxc.net.0.hwaddr = 4a:49:43:49:79:bf lxc.net.0.ipv4.address = 10.2.3.5/24 lxc.net.0.ipv6.address = 2003:db8:1:0:214:1234:fe0b:3597 lxc.net.0.type = macvlan lxc.net.0.flags = up lxc.net.0.link = eth0 lxc.net.0.hwaddr = 4a:49:43:49:79:bd lxc.net.0.ipv4.address = 10.2.3.4/24 lxc.net.0.ipv6.address = 2003:db8:1:0:214:1234:fe0b:3596 lxc.net.0.type = phys lxc.net.0.flags = up lxc.net.0.link = dummy0 lxc.net.0.hwaddr = 4a:49:43:49:79:ff lxc.net.0.ipv4.address = 10.2.3.6/24 lxc.net.0.ipv6.address = 2003:db8:1:0:214:1234:fe0b:3297 lxc-3.0.1/doc/examples/Makefile.am0000644061062106075000000000113213304304316013643 00000000000000if ENABLE_EXAMPLES pkgexamplesdir=$(docdir)/examples pkgexamples_DATA = \ lxc-macvlan.conf \ lxc-vlan.conf \ lxc-no-netns.conf \ lxc-empty-netns.conf \ lxc-phys.conf \ lxc-veth.conf \ lxc-complex.conf \ seccomp-v1.conf \ seccomp-v2-blacklist.conf \ seccomp-v2.conf endif noinst_DATA = \ lxc-macvlan.conf.in \ lxc-vlan.conf.in \ lxc-empty-netns.conf.in \ lxc-no-netns.conf.in \ lxc-phys.conf.in \ lxc-veth.conf.in \ lxc-complex.conf.in \ seccomp-v1.conf \ seccomp-v2-blacklist.conf \ seccomp-v2.conf EXTRA_DIST = \ seccomp-v1.conf \ seccomp-v2-blacklist.conf \ seccomp-v2.conf lxc-3.0.1/doc/lxc-usernsexec.sgml.in0000644061062106075000000001025213304304316014235 00000000000000 ]> @LXC_GENERATE_DATE@ lxc-usernsexec 1 lxc-usernsexec Run a task as root in a new user namespace. lxc-usernsexec -m uid-map -- command Description lxc-usernsexec can be used to run a task as root in a new user namespace. Options The uid map to use in the user namespace. Each map consists of four colon-separate values. First a character 'u', 'g' or 'b' to specify whether this map pertains to user ids, group ids, or both; next the first userid in the user namespace; next the first userid as seen on the host; and finally the number of ids to be mapped. More than one map can be specified. If no map is specified, then by default the full uid and gid ranges granted by /etc/subuid and /etc/subgid will be mapped to the uids and gids starting at 0 in the container. Note that lxc-usernsexec always tries to setuid and setgid to 0 in the namespace. Therefore uid 0 in the namespace must be mapped. Examples To spawn a shell with the full allotted subuids mapped into the container, use lxc-usernsexec To run a different shell than /bin/sh, use lxc-usernsexec -- /bin/bash If your user id is 1000, root in a container is mapped to 190000, and you wish to chown a file you own to root in the container, you can use: lxc-usernsexec -m b:0:1000:1 -m b:1:190000:1 -- /bin/chown 1:1 $file This maps your userid to root in the user namespace, and 190000 to uid 1. Since root in the user namespace is privileged over all userids mapped into the namespace, you are allowed to change the file ownership, which you could not do on the host using a simple chown. &seealso; Author Serge Hallyn serge.hallyn@ubuntu.com lxc-3.0.1/doc/lxc-copy.sgml.in0000644061062106075000000003220113304304316013021 00000000000000 ]> @LXC_GENERATE_DATE@ lxc-copy 1 lxc-copy copy an existing container. lxc-copy -n, --name name -P, --lxcpath path -N, --newname newname -p, --newpath newpath -B, --backingstorage backingstorage -s, --snapshot -K, --keepname -D, --keepdata -M, --keepmac -L, --fssize size [unit] -- hook arguments lxc-copy -n, --name name -P, --lxcpath path -N, --newname newname -p, --newpath newpath -e, --ephemeral -B, --backingstorage backingstorage -s, --snapshot -K, --keepname -D, --keepdata -M, --keepmac -L, --fssize size [unit] -- hook arguments lxc-copy -n, --name name -P, --lxcpath path -N, --newname newname -p, --newpath newpath -e, --ephemeral -B, --backingstorage backingstorage -s, --snapshot -t, --tmpfs -K, --keepname -M, --keepmac -- hook arguments lxc-copy -n, --name name -P, --lxcpath path -N, --newname newname -p, --newpath newpath -R, --rename Description lxc-copy creates and optionally starts (ephemeral or non-ephemeral) copies of existing containers. lxc-copy creates copies of existing containers. Copies can be complete clones of the original container. In this case the whole root filesystem of the container is simply copied to the new container. Or they can be snapshots, i.e. small copy-on-write copies of the original container. In this case the specified backing storage for the copy must support snapshots. This currently includes btrfs, lvm (lvm devices do not support snapshots of snapshots.), overlay, and zfs. The copy's backing storage will be of the same type as the original container. overlay snapshots of directory backed containers are exempted from this rule. When the -e flag is specified an ephemeral snapshot of the original container is created and started. Ephemeral containers will have lxc.ephemeral = 1 set in their config file and will be destroyed on shutdown. When -e is used in combination with -D a non-ephemeral snapshot of the original container is created and started. Ephemeral containers can also be placed on a tmpfs with -t flag. NOTE: If an ephemeral container that is placed on a tmpfs is rebooted all changes made to it will currently be lost! When -e is specified and no newname is given via -N a random name for the snapshot will be chosen. Containers created and started with -e can have custom mounts. These are specified with the -m flag. Currently two types of mounts are supported: bind, and overlay. Mount types are specified as suboptions to the -m flag and can be specified multiple times separated by commas. overlay mounts are currently specified in the format -m overlay=/src:/dest. When no destination dest is specified dest will be identical to src. Read-only bind mounts are specified -m bind=/src:/dest:ro and read-write bind mounts -m bind=/src:/dest:rw. Read-write bind mounts are the default and rw can be missing when a read-write mount is wanted. When dest is missing dest will be identical to src. An example for multiple mounts would be -m bind=/src1:/dest1:ro,bind=/src2:ro,overlay=/src3:/dest3. The mounts, their options, and formats supported via the -m flag are subject to change. Options The name for the copy. The path for the copy. Rename the original container. Create a snapshot of the original container. The backing storage for the copy must support snapshots. This currently includes btrfs, lvm, overlay, and zfs. Run the snapshot in the foreground. The snapshots console will be attached to the current tty. (This option can only be specified in conjunction with -e.) Run the snapshot as a daemon (This is the default mode for ephemeral containers.). As the container has no more tty, if an error occurs nothing will be displayed, the log file can be used to check the error. (This option can only be specified in conjunction with -e.) Specify a mount for a snapshot The opts argument for the mount type can by of type {bind, overlay}. For example (This option can currently only be specified in conjunction with -e.). When this option is specified the ephemeral container will be placed on a tmpfs. NOTE: Rebooting an ephemeral container that is located on a tmpfs will currently cause all changes made to it to be lost. This flag will only work for ephemeral containers created with the -e flag. The original container, from which the ephemeral snapshot is created, must be stored as a simple directory. Specify the backing storage type to be used for the copy where 'backingstorage' is of type 'btrfs', 'dir', 'lvm', 'loop', 'overlay', or 'zfs'. Specify the size for an 'lvm' filesystem. When this option is specified the hostname of the original container will be kept for the copy. When this option is specified with -e a non-ephemeral container is created and started. When this option is specified the MAC address of the original container will be kept for the copy. Copy hook If the container being copied has one or more lxc.hook.clone specified, then the specified hooks will be called for the new container. The first 3 arguments passed to the clone hook will be the container name, a section ('lxc'), and the hook type ('clone'). Extra arguments passed to lxc-copy will be passed to the hook program starting at argument 4. The LXC_ROOTFS_MOUNT environment variable gives the path under which the container's root filesystem is mounted. The configuration file pathname is stored in LXC_CONFIG_FILE, the new container name in LXC_NAME, the old container name in LXC_SRC_NAME, and the path or device on which the rootfs is located is in LXC_ROOTFS_PATH. &commonoptions; &seealso; Author Christian Brauner christian.brauner@mailbox.org lxc-3.0.1/doc/lxc-unshare.sgml.in0000644061062106075000000001425313304304316013523 00000000000000 ]> @LXC_GENERATE_DATE@ lxc-unshare 1 lxc-unshare Run a task in a new set of namespaces. lxc-unshare -s namespaces -u user -H hostname -i ifname -d -M command Description lxc-unshare can be used to run a task in a cloned set of namespaces. This command is mainly provided for testing purposes. Despite its name, it always uses clone rather than unshare to create the new task with fresh namespaces. Apart from testing kernel regressions this should make no difference. Options Specify the namespaces to attach to, as a pipe-separated list, e.g. NETWORK|IPC. Allowed values are MOUNT, PID, UTSNAME, IPC, USER and NETWORK. This allows one to change the context of the process to e.g. the network namespace of the container while retaining the other namespaces as those of the host. (The pipe symbol needs to be escaped, e.g. MOUNT\|PID or quoted, e.g. "MOUNT|PID".) Specify a userid which the new task should become. Set the hostname in the new container. Only allowed if the UTSNAME namespace is set. Move the named interface into the container. Only allowed if the NETWORK namespace is set. You may specify this argument multiple times to move multiple interfaces into container. Daemonize (do not wait for the container to exit before exiting) Mount default filesystems (/proc /dev/shm and /dev/mqueue) in the container. Only allowed if MOUNT namespace is set. Examples To spawn a new shell with its own UTS (hostname) namespace, lxc-unshare -s UTSNAME /bin/bash If the hostname is changed in that shell, the change will not be reflected on the host. To spawn a shell in a new network, pid, and mount namespace, lxc-unshare -s "NETWORK|PID|MOUNT" /bin/bash The resulting shell will have pid 1 and will see no network interfaces. After re-mounting /proc in that shell, mount -t proc proc /proc ps output will show there are no other processes in the namespace. To spawn a shell in a new network, pid, mount, and hostname namespace. lxc-unshare -s "NETWORK|PID|MOUNT|UTSNAME" -M -H slave -i veth1 /bin/bash The resulting shell will have pid 1 and will see two network interfaces (lo and veth1). The hostname will be "slave" and /proc will have been remounted. ps output will show there are no other processes in the namespace. &seealso; Author Daniel Lezcano daniel.lezcano@free.fr lxc-3.0.1/doc/lxc-cgroup.sgml.in0000644061062106075000000001000713304304316013346 00000000000000 ]> @LXC_GENERATE_DATE@ lxc-cgroup 1 lxc-cgroup manage the control group associated with a container lxc-cgroup -n name state-object value Description lxc-cgroup gets or sets the value of a state-object (e.g., 'cpuset.cpus') in the container's cgroup for the corresponding subsystem (e.g., 'cpuset'). If no value is specified, the current value of the state-object is displayed; otherwise it is set. Note that lxc-cgroup does not check that the state-object is valid for the running kernel, or that the corresponding subsystem is contained in any mounted cgroup hierarchy. Options Specify the state object name. Specify the value to assign to the state object. &commonoptions; Examples lxc-cgroup -n foo devices.list display the allowed devices to be used. lxc-cgroup -n foo cpuset.cpus "0,3" assign the processors 0 and 3 to the container. Diagnostic The container was not found The container is not running. &seealso; Author Daniel Lezcano daniel.lezcano@free.fr lxc-3.0.1/doc/lxc-monitor.sgml.in0000644061062106075000000001141713304304316013544 00000000000000 ]> @LXC_GENERATE_DATE@ lxc-monitor 1 lxc-monitor monitor the container state lxc-monitor -n name -Q name Description lxc-monitor monitors the state of containers. The name argument may be used to specify which containers to monitor. It is a regular expression, conforming with posix2, so it is possible to monitor all the containers, several of them or just one. If not specified, name will default to '.*' which will monitor all containers in lxcpath. The =PATH option may be specified multiple times to monitor more than one container path. Note however that containers with the same name in multiple paths will be indistinguishable in the output. Options Ask the lxc-monitord daemon on each given lxcpath to quit. After receiving this command, lxc-monitord will exit immediately as soon as it has no clients instead of waiting the normal 30 seconds for new clients. This is useful if you need to unmount the filesystem lxcpath is on. &commonoptions; Examples lxc-monitor -n foo will monitor the different states for container foo. lxc-monitor -n 'foo|bar' will monitor the different states for container foo and bar. lxc-monitor -n '[fb].*' will monitor the different states for container with the name beginning with letter 'f' or 'b'. lxc-monitor -n '.*' will monitor the different states for all containers. Diagnostic The container was not found The specified container was not created before with the lxc-create command. See Also regex 7 , &seealso; Author Daniel Lezcano daniel.lezcano@free.fr lxc-3.0.1/doc/lxc-info.sgml.in0000644061062106075000000001253513304304316013012 00000000000000 ]> @LXC_GENERATE_DATE@ lxc-info 1 lxc-info query information about a container lxc-info -n name -c KEY -s -p -i -S -H Description lxc-info queries and shows information about a container. Options Print a configuration key from the container. This option may be given multiple times to print out multiple key = value pairs. Just print the container's state. Just print the container's pid. Just print the container's IP addresses. Just print the container's statistics. Note that for performance reasons the kernel does not account kernel memory use unless a kernel memory limit is set. If a limit is not set, lxc-info will display kernel memory use as 0. A limit can be set by specifying lxc.cgroup.memory.kmem.limit_in_bytes = number in your container configuration file, see lxc.conf 5 . Print the container's statistics in raw, non-humanized form. The default is to print statistics in humanized form. &commonoptions; Examples lxc-info -n foo Show information for foo. lxc-info -n 'ubuntu.*' Show information for all containers whose name starts with ubuntu. lxc-info -n foo -c lxc.net.0.veth.pair prints the veth pair name of foo. &seealso; Author Stéphane Graber stgraber@ubuntu.com lxc-3.0.1/doc/lxc-stop.sgml.in0000644061062106075000000001360213304304316013040 00000000000000 ]> @LXC_GENERATE_DATE@ lxc-stop 1 lxc-stop stop the application running inside a container lxc-stop -n name -W -r -t timeout -k --nokill --nolock Description lxc-stop reboots, cleanly shuts down, or kills all the processes inside the container. By default, it will request a clean shutdown of the container by sending lxc.signal.halt (defaults to SIGPWR) to the container's init process, waiting up to 60 seconds for the container to exit, and then returning. If the container fails to cleanly exit in 60 seconds, it will be sent the lxc.signal.stop (defaults to SIGKILL) to force it to shut down. A request to reboot will send the lxc.signal.reboot (defaults to SIGINT) to the container's init process. The -W, -r, -k and --nokill options specify the action to perform. -W indicates that after performing the specified action, lxc-stop should immediately exit, while -t TIMEOUT specifies the maximum amount of time to wait for the container to complete the shutdown or reboot. Options Request a reboot of the container. Rather than requesting a clean shutdown of the container, explicitly kill all tasks in the container. This is the legacy lxc-stop behavior. Only request a clean shutdown, do not kill the container tasks if the clean shutdown fails. This option avoids the use of any of the API lxc locking, and should only be used if lxc-stop is hanging due to a bad system state. Simply perform the requestion action (reboot, shutdown, or hard kill) and exit. Wait TIMEOUT seconds before hard-stopping the container. Exit value 0 The container was successfully stopped. 1 An error occurred while stopping the container. 2 The specified container exists but was not running. Diagnostic The container was not found The specified container was not created before with the lxc-create command. &seealso; Author Daniel Lezcano daniel.lezcano@free.fr lxc-3.0.1/doc/lxc.container.conf0000644061062106075000000000251213304304316013412 00000000000000# the fstab mount file lxc.mount.fstab = ./fstab # the hostname to be set into the container lxc.utsname = virtnode # The network has several of kind of configuration: # # * veth : the network will use the veth virtual device, the specified # link must be a bridge # * macvlan : the network will use the macvlan device, the specified link # should be an existing interface, usually it is eth0 # * phys : the network will use a physical network device, the specified # link should be an existing interface lxc.net.0.type = macvlan # specify the flags to be used for the network, actually only is allowed # which mean the network should be set up when created. If the network is set # up, the loopback is automatically set up too. lxc.net.0.flags = up # specify the physical network device which will communicate with the # outside world lxc.net.0.link = eth0 # NIC ethernet mac address lxc.net.0.hwaddr = 4a:49:43:49:79:bd # specify the ipv4 address of the container. Several lines are allowed and # will mean several addresses will be assigned to the interface lxc.net.0.ipv4.address = 1.2.3.5/24 # specify the ipv6 address of the container. Several lines are allowed and # will mean several addresses will be assigned to the interface lxc.net.0.ipv6.address = 2003:db8:1:0:214:1234:fe0b:3596 lxc-3.0.1/doc/FAQ.txt0000644061062106075000000000300613304304316011143 00000000000000 Troubleshooting: =============== Error: ------ error while loading shared libraries reported after sudo make install and when trying to run lxc-execute. "lxc-execute -n foo -f /usr/local/etc/lxc/lxc-macvlan.conf /bin/bash" /usr/local/bin/lxc-execute: error while loading shared libraries: liblxc-0.5.0.so: cannot open shared object file: No such file or directory Answer: ------- update the ld cache by running ldconfig. Error: ------ error when starting a container. "lxc-start Invalid argument" "lxc-execute -n foo -f /usr/local/etc/lxc/lxc-macvlan.conf /bin/bash" "[syserr] lxc_start:96: Invalid argument - failed to fork into a new namespace" Answer: ------- read the lxc man page about kernel version prereq :) most probably your kernel is not configured to support the container options you want to use. Error: ------ On Ubuntu 8.10, if using the cvs source code rather than the provided tarball. Then make is failing with many errors similar to the line below: ========== ../../libtool: line 810: X--tag=CC: command not found ========== Answer: ------- This is related to a compatibility problem between the shipped config/ltmain.sh and the libtool version installed on your Ubuntu 8.10 machine. You have to replace the config/ltmain.sh from cvs head by the one from your libtool package, make some cleaning and reissue all the build process: ========== cd cp -f /usr/share/libtool/config/ltmain.sh config/ rm -f libtool ./bootstrap && ./configure && make && sudo make install ========== lxc-3.0.1/doc/lxc-start.sgml.in0000644061062106075000000001720313304304316013211 00000000000000 ]> @LXC_GENERATE_DATE@ lxc-start 1 lxc-start run an application inside a container. lxc-start -n name -f config_file -c console_device -L console_logfile -d -F -p pid_file -s KEY=VAL -C --share-[net|ipc|uts] name|pid command Description lxc-start runs the specified command inside the container specified by name. It will setup the container according to the configuration previously defined with the lxc-create command or with the configuration file parameter. If no configuration is defined, the default isolation is used. If no command is specified, lxc-start will use the command defined in lxc.init.cmd or if not set, the default "/sbin/init" command to run a system container. Options Run the container as a daemon. As the container has no more tty, if an error occurs nothing will be displayed, the log file can be used to check the error. (This is the default mode) Run the container in the foreground. In this mode, the container console will be attached to the current tty and signals will be routed directly to the container. Create a file with the process id. Specify the configuration file to configure the virtualization and isolation functionalities for the container. This configuration file if present will be used even if there is already a configuration file present in the previously created container (via lxc-create). Specify a device to use for the container's console, for example /dev/tty8. If this option is not specified the current terminal will be used unless is specified. Specify a file to log the container's console output to. Assign value VAL to configuration variable KEY. This overrides any assignment done in config_file. If any file descriptors are inherited, close them. If this option is not specified, then lxc-start will exit with failure instead. Note: --daemon implies --close-all-fds. Inherit a network namespace from a name container or a pid. The network namespace will continue to be managed by the original owner. The network configuration of the starting container is ignored and the up/down scripts won't be executed. Inherit an IPC namespace from a name container or a pid. Inherit a UTS namespace from a name container or a pid. The starting LXC will not set the hostname, but the container OS may do it anyway. &commonoptions; Diagnostic The container is busy The specified container is already running an application. You should stop it before reuse this container or create a new one. &seealso; Author Daniel Lezcano daniel.lezcano@free.fr lxc-3.0.1/doc/lxc.container.conf.sgml.in0000644061062106075000000030340413304304316014764 00000000000000 ]> @LXC_GENERATE_DATE@ lxc.container.conf 5 lxc.container.conf LXC container configuration file Description LXC is the well-known and heavily tested low-level Linux container runtime. It is in active development since 2008 and has proven itself in critical production environments world-wide. Some of its core contributors are the same people that helped to implement various well-known containerization features inside the Linux kernel. LXC's main focus is system containers. That is, containers which offer an environment as close as possible as the one you'd get from a VM but without the overhead that comes with running a separate kernel and simulating all the hardware. This is achieved through a combination of kernel security features such as namespaces, mandatory access control and control groups. LXC has supports unprivileged containers. Unprivileged containers are containers that are run without any privilege. This requires support for user namespaces in the kernel that the container is run on. LXC was the first runtime to support unprivileged containers after user namespaces were merged into the mainline kernel. In essence, user namespaces isolate given sets of UIDs and GIDs. This is achieved by establishing a mapping between a range of UIDs and GIDs on the host to a different (unprivileged) range of UIDs and GIDs in the container. The kernel will translate this mapping in such a way that inside the container all UIDs and GIDs appear as you would expect from the host whereas on the host these UIDs and GIDs are in fact unprivileged. For example, a process running as UID and GID 0 inside the container might appear as UID and GID 100000 on the host. The implementation and working details can be gathered from the corresponding user namespace man page. UID and GID mappings can be defined with the key. Linux containers are defined with a simple configuration file. Each option in the configuration file has the form key = value fitting in one line. The "#" character means the line is a comment. List options, like capabilities and cgroups options, can be used with no value to clear any previously defined values of that option. LXC namespaces configuration keys by using single dots. This means complex configuration keys such as expose various subkeys such as , , , and others for even more fine-grained configuration. Configuration In order to ease administration of multiple related containers, it is possible to have a container configuration file cause another file to be loaded. For instance, network configuration can be defined in one common file which is included by multiple containers. Then, if the containers are moved to another host, only one file may need to be updated. Specify the file to be included. The included file must be in the same valid lxc configuration file format. Architecture Allows one to set the architecture for the container. For example, set a 32bits architecture for a container running 32bits binaries on a 64bits host. This fixes the container scripts which rely on the architecture to do some work like downloading the packages. Specify the architecture for the container. Some valid options are , , , Hostname The utsname section defines the hostname to be set for the container. That means the container can set its own hostname without changing the one from the system. That makes the hostname private for the container. specify the hostname for the container Halt signal Allows one to specify signal name or number sent to the container's init process to cleanly shutdown the container. Different init systems could use different signals to perform clean shutdown sequence. This option allows the signal to be specified in kill(1) fashion, e.g. SIGPWR, SIGRTMIN+14, SIGRTMAX-10 or plain number. The default signal is SIGPWR. specify the signal used to halt the container Reboot signal Allows one to specify signal name or number to reboot the container. This option allows signal to be specified in kill(1) fashion, e.g. SIGTERM, SIGRTMIN+14, SIGRTMAX-10 or plain number. The default signal is SIGINT. specify the signal used to reboot the container Stop signal Allows one to specify signal name or number to forcibly shutdown the container. This option allows signal to be specified in kill(1) fashion, e.g. SIGKILL, SIGRTMIN+14, SIGRTMAX-10 or plain number. The default signal is SIGKILL. specify the signal used to stop the container Init command Sets the command to use as the init system for the containers. Absolute path from container rootfs to the binary to run by default. This mostly makes sense for lxc-execute. Absolute path from container rootfs to the binary to use as init. This mostly makes sense for lxc-start. Default is /sbin/init. Init working directory Sets the absolute path inside the container as the working directory for the containers. LXC will switch to this directory before executing init. Absolute path inside the container to use as the working directory. Init ID Sets the UID/GID to use for the init system, and subsequent commands. Note that using a non-root UID when booting a system container will likely not work due to missing privileges. Setting the UID/GID is mostly useful when running application containers. Defaults to: UID(0), GID(0) UID to use for init. GID to use for init. Proc Configure proc filesystem for the container. Specify the proc file name to be set. The file name available are those listed under /proc/PID/. Example: lxc.proc.oom_score_adj = 10 Ephemeral Allows one to specify whether a container will be destroyed on shutdown. The only allowed values are 0 and 1. Set this to 1 to destroy a container on shutdown. Network The network section defines how the network is virtualized in the container. The network virtualization acts at layer two. In order to use the network virtualization, parameters must be specified to define the network interfaces of the container. Several virtual interfaces can be assigned and used in a container even if the system has only one physical network interface. may be used without a value to clear all previous network options. specify what kind of network virtualization to be used for the container. Multiple networks can be specified by using an additional index after all keys. For example, and specify two different networks of the same type. All keys sharing the same index will be treated as belonging to the same network. For example, will belong to . Currently, the different virtualization types can be: will cause the container to share the host's network namespace. This means the host network devices are usable in the container. It also means that if both the container and host have upstart as init, 'halt' in a container (for instance) will shut down the host. will create only the loopback interface. a virtual ethernet pair device is created with one side assigned to the container and the other side attached to a bridge specified by the option. If the bridge is not specified, then the veth pair device will be created but not attached to any bridge. Otherwise, the bridge has to be created on the system before starting the container. lxc won't handle any configuration outside of the container. By default, lxc chooses a name for the network device belonging to the outside of the container, but if you wish to handle this name yourselves, you can tell lxc to set a specific name with the option (except for unprivileged containers where this option is ignored for security reasons). a vlan interface is linked with the interface specified by the and assigned to the container. The vlan identifier is specified with the option . a macvlan interface is linked with the interface specified by the and assigned to the container. specifies the mode the macvlan will use to communicate between different macvlan on the same upper device. The accepted modes are , , and . In mode, the device never communicates with any other device on the same upper_dev (default). In mode, the new Virtual Ethernet Port Aggregator (VEPA) mode, it assumes that the adjacent bridge returns all frames where both source and destination are local to the macvlan port, i.e. the bridge is set up as a reflective relay. Broadcast frames coming in from the upper_dev get flooded to all macvlan interfaces in VEPA mode, local frames are not delivered locally. In mode, it provides the behavior of a simple bridge between different macvlan interfaces on the same port. Frames from one interface to another one get delivered directly and are not sent out externally. Broadcast frames get flooded to all other bridge ports and to the external interface, but when they come back from a reflective relay, we don't deliver them again. Since we know all the MAC addresses, the macvlan bridge mode does not require learning or STP like the bridge module does. In mode, all frames received by the physical interface are forwarded to the macvlan interface. Only one macvlan interface in mode is possible for one physical interface. an already existing interface specified by the is assigned to the container. Specify an action to do for the network. activates the interface. Specify the interface to be used for real network traffic. Specify the maximum transfer unit for this interface. The interface name is dynamically allocated, but if another name is needed because the configuration files being used by the container use a generic name, eg. eth0, this option will rename the interface in the container. The interface mac address is dynamically allocated by default to the virtual interface, but in some cases, this is needed to resolve a mac address conflict or to always have the same link-local ipv6 address. Any "x" in address will be replaced by random value, this allows setting hwaddr templates. Specify the ipv4 address to assign to the virtualized interface. Several lines specify several ipv4 addresses. The address is in format x.y.z.t/m, eg. 192.168.1.123/24. Specify the ipv4 address to use as the gateway inside the container. The address is in format x.y.z.t, eg. 192.168.1.123. Can also have the special value , which means to take the primary address from the bridge interface (as specified by the option) and use that as the gateway. is only available when using the and network types. Specify the ipv6 address to assign to the virtualized interface. Several lines specify several ipv6 addresses. The address is in format x::y/m, eg. 2003:db8:1:0:214:1234:fe0b:3596/64 Specify the ipv6 address to use as the gateway inside the container. The address is in format x::y, eg. 2003:db8:1:0::1 Can also have the special value , which means to take the primary address from the bridge interface (as specified by the option) and use that as the gateway. is only available when using the and network types. Add a configuration option to specify a script to be executed after creating and configuring the network used from the host side. In addition to the information available to all hooks. The following information is provided to the script: LXC_HOOK_TYPE: the hook type. This is either 'up' or 'down'. LXC_HOOK_SECTION: the section type 'net'. LXC_NET_TYPE: the network type. This is one of the valid network types listed here (e.g. 'macvlan', 'veth'). LXC_NET_PARENT: the parent device on the host. This is only set for network types 'mavclan', 'veth', 'phys'. LXC_NET_PEER: the name of the peer device on the host. This is only set for 'veth' network types. Note that this information is only available when is set to 1. Whether this information is provided in the form of environment variables or as arguments to the script depends on the value of . If set to 1 then information is provided in the form of environment variables. If set to 0 information is provided as arguments to the script. Standard output from the script is logged at debug level. Standard error is not logged, but can be captured by the hook redirecting its standard error to standard output. Add a configuration option to specify a script to be executed before destroying the network used from the host side. In addition to the information available to all hooks. The following information is provided to the script: LXC_HOOK_TYPE: the hook type. This is either 'up' or 'down'. LXC_HOOK_SECTION: the section type 'net'. LXC_NET_TYPE: the network type. This is one of the valid network types listed here (e.g. 'macvlan', 'veth'). LXC_NET_PARENT: the parent device on the host. This is only set for network types 'mavclan', 'veth', 'phys'. LXC_NET_PEER: the name of the peer device on the host. This is only set for 'veth' network types. Note that this information is only available when is set to 1. Whether this information is provided in the form of environment variables or as arguments to the script depends on the value of . If set to 1 then information is provided in the form of environment variables. If set to 0 information is provided as arguments to the script. Standard output from the script is logged at debug level. Standard error is not logged, but can be captured by the hook redirecting its standard error to standard output. New pseudo tty instance (devpts) For stricter isolation the container can have its own private instance of the pseudo tty. If set, the container will have a new pseudo tty instance, making this private to it. The value specifies the maximum number of pseudo ttys allowed for a pts instance (this limitation is not implemented yet). Container system console If the container is configured with a root filesystem and the inittab file is setup to use the console, you may want to specify where the output of this console goes. Setting this option instructs liblxc to allocate an in-memory ringbuffer. The container's console output will be written to the ringbuffer. Note that ringbuffer must be at least as big as a standard page size. When passed a value smaller than a single page size liblxc will allocate a ringbuffer of a single page size. A page size is usually 4KB. The keyword 'auto' will cause liblxc to allocate a ringbuffer of 128KB. When manually specifying a size for the ringbuffer the value should be a power of 2 when converted to bytes. Valid size prefixes are 'KB', 'MB', 'GB'. (Note that all conversions are based on multiples of 1024. That means 'KB' == 'KiB', 'MB' == 'MiB', 'GB' == 'GiB'. Additionally, the case of the suffix is ignored, i.e. 'kB', 'KB' and 'Kb' are treated equally.) Setting this option instructs liblxc to place a limit on the size of the console log file specified in . Note that size of the log file must be at least as big as a standard page size. When passed a value smaller than a single page size liblxc will set the size of log file to a single page size. A page size is usually 4KB. The keyword 'auto' will cause liblxc to place a limit of 128KB on the log file. When manually specifying a size for the log file the value should be a power of 2 when converted to bytes. Valid size prefixes are 'KB', 'MB', 'GB'. (Note that all conversions are based on multiples of 1024. That means 'KB' == 'KiB', 'MB' == 'MiB', 'GB' == 'GiB'. Additionally, the case of the suffix is ignored, i.e. 'kB', 'KB' and 'Kb' are treated equally.) If users want to mirror the console ringbuffer on disk they should set equal to . Specify a path to a file where the console output will be written. Note that in contrast to the on-disk ringbuffer logfile this file will keep growing potentially filling up the users disks if not rotated and deleted. This problem can also be avoided by using the in-memory ringbuffer options and . Whether to rotate the console logfile specified in . Users can send an API request to rotate the logfile. Note that the old logfile will have the same name as the original with the suffix ".1" appended. Users wishing to prevent the console log file from filling the disk should rotate the logfile and delete it if unneeded. This problem can also be avoided by using the in-memory ringbuffer options and . Specify a path to a device to which the console will be attached. The keyword 'none' will simply disable the console. Note, when specifying 'none' and creating a device node for the console in the container at /dev/console or bind-mounting the hosts's /dev/console into the container at /dev/console the container will have direct access to the hosts's /dev/console. This is dangerous when the container has write access to the device and should thus be used with caution. Console through the ttys This option is useful if the container is configured with a root filesystem and the inittab file is setup to launch a getty on the ttys. The option specifies the number of ttys to be available for the container. The number of gettys in the inittab file of the container should not be greater than the number of ttys specified in this option, otherwise the excess getty sessions will die and respawn indefinitely giving annoying messages on the console or in /var/log/messages. Specify the number of tty to make available to the container. Console devices location LXC consoles are provided through Unix98 PTYs created on the host and bind-mounted over the expected devices in the container. By default, they are bind-mounted over /dev/console and /dev/ttyN. This can prevent package upgrades in the guest. Therefore you can specify a directory location (under /dev under which LXC will create the files and bind-mount over them. These will then be symbolically linked to /dev/console and /dev/ttyN. A package upgrade can then succeed as it is able to remove and replace the symbolic links. Specify a directory under /dev under which to create the container console devices. Note that LXC will move any bind-mounts or device nodes for /dev/console into this directory. /dev directory By default, lxc creates a few symbolic links (fd,stdin,stdout,stderr) in the container's /dev directory but does not automatically create device node entries. This allows the container's /dev to be set up as needed in the container rootfs. If lxc.autodev is set to 1, then after mounting the container's rootfs LXC will mount a fresh tmpfs under /dev (limited to 500k) and fill in a minimal set of initial devices. This is generally required when starting a container containing a "systemd" based "init" but may be optional at other times. Additional devices in the containers /dev directory may be created through the use of the hook. Set this to 0 to stop LXC from mounting and populating a minimal /dev when starting the container. Mount points The mount points section specifies the different places to be mounted. These mount points will be private to the container and won't be visible by the processes running outside of the container. This is useful to mount /etc, /var or /home for examples. NOTE - LXC will generally ensure that mount targets and relative bind-mount sources are properly confined under the container root, to avoid attacks involving over-mounting host directories and files. (Symbolic links in absolute mount sources are ignored) However, if the container configuration first mounts a directory which is under the control of the container user, such as /home/joe, into the container at some path, and then mounts under path, then a TOCTTOU attack would be possible where the container user modifies a symbolic link under his home directory at just the right time. specify a file location in the fstab format, containing the mount information. The mount target location can and in most cases should be a relative path, which will become relative to the mounted container root. For instance, proc proc proc nodev,noexec,nosuid 0 0 Will mount a proc filesystem under the container's /proc, regardless of where the root filesystem comes from. This is resilient to block device backed filesystems as well as container cloning. Note that when mounting a filesystem from an image file or block device the third field (fs_vfstype) cannot be auto as with mount 8 but must be explicitly specified. Specify a mount point corresponding to a line in the fstab format. Moreover lxc supports mount propagation, such as rslave or rprivate, and adds three additional mount options. don't fail if mount does not work. or to create dir (or file) when the point will be mounted. source path is taken to be relative to the mounted container root. For instance, dev/null proc/kcore none bind,relative 0 0 Will expand dev/null to ${}/dev/null, and mount it to proc/kcore inside the container. specify which standard kernel file systems should be automatically mounted. This may dramatically simplify the configuration. The file systems are: (or ): mount /proc as read-write, but remount /proc/sys and /proc/sysrq-trigger read-only for security / container isolation purposes. : mount /proc as read-write (or ): mount /sys as read-only but with /sys/devices/virtual/net writable. : mount /sys as read-only for security / container isolation purposes. : mount /sys as read-write : Mount a tmpfs to /sys/fs/cgroup, create directories for all hierarchies to which the container is added, create subdirectories in those hierarchies with the name of the cgroup, and bind-mount the container's own cgroup into that directory. The container will be able to write to its own cgroup directory, but not the parents, since they will be remounted read-only. : The option will cause LXC to perform the cgroup mounts for the container under all circumstances. Otherwise it is similar to . This is mainly useful when the cgroup namespaces are enabled where LXC will normally leave mounting cgroups to the init binary of the container since it is perfectly safe to do so. : similar to , but everything will be mounted read-only. : The option will cause LXC to perform the cgroup mounts for the container under all circumstances. Otherwise it is similar to . This is mainly useful when the cgroup namespaces are enabled where LXC will normally leave mounting cgroups to the init binary of the container since it is perfectly safe to do so. : similar to , but everything will be mounted read-write. Note that the paths leading up to the container's own cgroup will be writable, but will not be a cgroup filesystem but just part of the tmpfs of /sys/fs/cgroup : The option will cause LXC to perform the cgroup mounts for the container under all circumstances. Otherwise it is similar to . This is mainly useful when the cgroup namespaces are enabled where LXC will normally leave mounting cgroups to the init binary of the container since it is perfectly safe to do so. (without specifier): defaults to if the container retains the CAP_SYS_ADMIN capability, otherwise. : mount a tmpfs to /sys/fs/cgroup, create directories for all hierarchies to which the container is added, bind-mount the hierarchies from the host to the container and make everything read-only except the container's own cgroup. Note that compared to , where all paths leading up to the container's own cgroup are just simple directories in the underlying tmpfs, here /sys/fs/cgroup/$hierarchy will contain the host's full cgroup hierarchy, albeit read-only outside the container's own cgroup. This may leak quite a bit of information into the container. : The option will cause LXC to perform the cgroup mounts for the container under all circumstances. Otherwise it is similar to . This is mainly useful when the cgroup namespaces are enabled where LXC will normally leave mounting cgroups to the init binary of the container since it is perfectly safe to do so. : similar to , but everything will be mounted read-only. : The option will cause LXC to perform the cgroup mounts for the container under all circumstances. Otherwise it is similar to . This is mainly useful when the cgroup namespaces are enabled where LXC will normally leave mounting cgroups to the init binary of the container since it is perfectly safe to do so. : similar to , but everything will be mounted read-write. Note that in this case, the container may escape its own cgroup. (Note also that if the container has CAP_SYS_ADMIN support and can mount the cgroup filesystem itself, it may do so anyway.) : The option will cause LXC to perform the cgroup mounts for the container under all circumstances. Otherwise it is similar to . This is mainly useful when the cgroup namespaces are enabled where LXC will normally leave mounting cgroups to the init binary of the container since it is perfectly safe to do so. (without specifier): defaults to if the container retains the CAP_SYS_ADMIN capability, otherwise. If cgroup namespaces are enabled, then any auto-mounting request will be ignored, since the container can mount the filesystems itself, and automounting can confuse the container init. Note that if automatic mounting of the cgroup filesystem is enabled, the tmpfs under /sys/fs/cgroup will always be mounted read-write (but for the and cases, the individual hierarchies, /sys/fs/cgroup/$hierarchy, will be read-only). This is in order to work around a quirk in Ubuntu's mountall 8 command that will cause containers to wait for user input at boot if /sys/fs/cgroup is mounted read-only and the container can't remount it read-write due to a lack of CAP_SYS_ADMIN. Examples: lxc.mount.auto = proc sys cgroup lxc.mount.auto = proc:rw sys:rw cgroup-full:rw Root file system The root file system of the container can be different than that of the host system. specify the root file system for the container. It can be an image file, a directory or a block device. If not specified, the container shares its root file system with the host. For directory or simple block-device backed containers, a pathname can be used. If the rootfs is backed by a nbd device, then nbd:file:1 specifies that file should be attached to a nbd device, and partition 1 should be mounted as the rootfs. nbd:file specifies that the nbd device itself should be mounted. overlayfs:/lower:/upper specifies that the rootfs should be an overlay with /upper being mounted read-write over a read-only mount of /lower. For overlay multiple /lower directories can be specified. loop:/file tells lxc to attach /file to a loop device and mount the loop device. where to recursively bind before pivoting. This is to ensure success of the pivot_root 8 syscall. Any directory suffices, the default should generally work. extra mount options to use when mounting the rootfs. Control group The control group section contains the configuration for the different subsystem. lxc does not check the correctness of the subsystem name. This has the disadvantage of not detecting configuration errors until the container is started, but has the advantage of permitting any future subsystem. Specify the control group value to be set on a legacy cgroup hierarchy. The controller name is the literal name of the control group. The permitted names and the syntax of their values is not dictated by LXC, instead it depends on the features of the Linux kernel running at the time the container is started, eg. Specify the control group value to be set on the unified cgroup shierarchy. The controller name is the literal name of the control group. The permitted names and the syntax of their values is not dictated by LXC, instead it depends on the features of the Linux kernel running at the time the container is started, eg. specify a directory or path in which the container's cgroup will be created. For example, setting for a container named "c1" will create the container's cgroup as a sub-cgroup of "my-cgroup". For example, if the user's current cgroup "my-user" is located in the root cgroup of the cpuset controller in a cgroup v1 hierarchy this would create the cgroup "/sys/fs/cgroup/cpuset/my-user/my-cgroup/first/c1" for the container. Any missing cgroups will be created by LXC. This presupposes that the user has write access to its current cgroup. Capabilities The capabilities can be dropped in the container if this one is run as root. Specify the capability to be dropped in the container. A single line defining several capabilities with a space separation is allowed. The format is the lower case of the capability definition without the "CAP_" prefix, eg. CAP_SYS_MODULE should be specified as sys_module. See capabilities 7 . If used with no value, lxc will clear any drop capabilities specified up to this point. Specify the capability to be kept in the container. All other capabilities will be dropped. When a special value of "none" is encountered, lxc will clear any keep capabilities specified up to this point. A value of "none" alone can be used to drop all capabilities. Namespaces A namespace can be cloned (), kept () or shared (). Specify namespaces which the container is supposed to be created with. The namespaces to create are specified as a space separated list. Each namespace must correspond to one of the standard namespace identifiers as seen in the /proc/PID/ns directory. When is not explicitly set all namespaces supported by the kernel and the current configuration will be used. To create a new mount, net and ipc namespace set . Specify namespaces which the container is supposed to inherit from the process that created it. The namespaces to keep are specified as a space separated list. Each namespace must correspond to one of the standard namespace identifiers as seen in the /proc/PID/ns directory. The is a blacklist option, i.e. it is useful when enforcing that containers must keep a specific set of namespaces. To keep the network, user and ipc namespace set . Note that sharing pid namespaces will likely not work with most init systems. Note that if the container requests a new user namespace and the container wants to inherit the network namespace it needs to inherit the user namespace as well. Specify a namespace to inherit from another container or process. The suffix needs to be replaced with one of the namespaces that appear in the /proc/PID/ns directory. To inherit the namespace from another process set the to the PID of the process, e.g. . To inherit the namespace from another container set the to the name of the container, e.g. . To inherit the namespace from another container located in a different path than the standard liblxc path set the to the full path to the container, e.g. . In order to inherit namespaces the caller needs to have sufficient privilege over the process or container. Note that sharing pid namespaces between system containers will likely not work with most init systems. Note that if two processes are in different user namespaces and one process wants to inherit the other's network namespace it usually needs to inherit the user namespace as well. Resource limits The soft and hard resource limits for the container can be changed. Unprivileged containers can only lower them. Resources which are not explicitly specified will be inherited. Specify the resource limit to be set. A limit is specified as two colon separated values which are either numeric or the word 'unlimited'. A single value can be used as a shortcut to set both soft and hard limit to the same value. The permitted names the "RLIMIT_" resource names in lowercase without the "RLIMIT_" prefix, eg. RLIMIT_NOFILE should be specified as "nofile". See setrlimit 2 . If used with no value, lxc will clear the resource limit specified up to this point. A resource with no explicitly configured limitation will be inherited from the process starting up the container. Sysctl Configure kernel parameters for the container. Specify the kernel parameters to be set. The parameters available are those listed under /proc/sys/. Note that not all sysctls are namespaced. Changing Non-namespaced sysctls will cause the system-wide setting to be modified. sysctl 8 . If used with no value, lxc will clear the parameters specified up to this point. Apparmor profile If lxc was compiled and installed with apparmor support, and the host system has apparmor enabled, then the apparmor profile under which the container should be run can be specified in the container configuration. The default is lxc-container-default-cgns if the host kernel is cgroup namespace aware, or lxc-container-default othewise. Specify the apparmor profile under which the container should be run. To specify that the container should be unconfined, use lxc.apparmor.profile = unconfined If the apparmor profile should remain unchanged (i.e. if you are nesting containers and are already confined), then use lxc.apparmor.profile = unchanged Apparmor profiles are pathname based. Therefore many file restrictions require mount restrictions to be effective against a determined attacker. However, these mount restrictions are not yet implemented in the upstream kernel. Without the mount restrictions, the apparmor profiles still protect against accidental damager. If this flag is 0 (default), then the container will not be started if the kernel lacks the apparmor mount features, so that a regression after a kernel upgrade will be detected. To start the container under partial apparmor protection, set this flag to 1. SELinux context If lxc was compiled and installed with SELinux support, and the host system has SELinux enabled, then the SELinux context under which the container should be run can be specified in the container configuration. The default is unconfined_t, which means that lxc will not attempt to change contexts. See @DATADIR@/lxc/selinux/lxc.te for an example policy and more information. Specify the SELinux context under which the container should be run or unconfined_t. For example lxc.selinux.context = system_u:system_r:lxc_t:s0:c22 Seccomp configuration A container can be started with a reduced set of available system calls by loading a seccomp profile at startup. The seccomp configuration file must begin with a version number on the first line, a policy type on the second line, followed by the configuration. Versions 1 and 2 are currently supported. In version 1, the policy is a simple whitelist. The second line therefore must read "whitelist", with the rest of the file containing one (numeric) sycall number per line. Each syscall number is whitelisted, while every unlisted number is blacklisted for use in the container In version 2, the policy may be blacklist or whitelist, supports per-rule and per-policy default actions, and supports per-architecture system call resolution from textual names. An example blacklist policy, in which all system calls are allowed except for mknod, which will simply do nothing and return 0 (success), looks like: 2 blacklist mknod errno 0 Specify a file containing the seccomp configuration to load before the container starts. PR_SET_NO_NEW_PRIVS With PR_SET_NO_NEW_PRIVS active execve() promises not to grant privileges to do anything that could not have been done without the execve() call (for example, rendering the set-user-ID and set-group-ID mode bits, and file capabilities non-functional). Once set, this bit cannot be unset. The setting of this bit is inherited by children created by fork() and clone(), and preserved across execve(). Note that PR_SET_NO_NEW_PRIVS is applied after the container has changed into its intended AppArmor profile or SElinux context. Specify whether the PR_SET_NO_NEW_PRIVS flag should be set for the container. Set to 1 to activate. UID mappings A container can be started in a private user namespace with user and group id mappings. For instance, you can map userid 0 in the container to userid 200000 on the host. The root user in the container will be privileged in the container, but unprivileged on the host. Normally a system container will want a range of ids, so you would map, for instance, user and group ids 0 through 20,000 in the container to the ids 200,000 through 220,000. Four values must be provided. First a character, either 'u', or 'g', to specify whether user or group ids are being mapped. Next is the first userid as seen in the user namespace of the container. Next is the userid as seen on the host. Finally, a range indicating the number of consecutive ids to map. Container hooks Container hooks are programs or scripts which can be executed at various times in a container's lifetime. When a container hook is executed, additional information is passed along. The argument can be used to determine if the following arguments are passed as command line arguments or through environment variables. The arguments are: Container name. Section (always 'lxc'). The hook type (i.e. 'clone' or 'pre-mount'). Additional arguments. In the case of the clone hook, any extra arguments passed will appear as further arguments to the hook. In the case of the stop hook, paths to filedescriptors for each of the container's namespaces along with their types are passed. The following environment variables are set: LXC_CGNS_AWARE: indicator whether the container is cgroup namespace aware. LXC_CONFIG_FILE: the path to the container configuration file. LXC_HOOK_TYPE: the hook type (e.g. 'clone', 'mount', 'pre-mount'). Note that the existence of this environment variable is conditional on the value of . If it is set to 1 then LXC_HOOK_TYPE will be set. LXC_HOOK_SECTION: the section type (e.g. 'lxc', 'net'). Note that the existence of this environment variable is conditional on the value of . If it is set to 1 then LXC_HOOK_SECTION will be set. LXC_HOOK_VERSION: the version of the hooks. This value is identical to the value of the container's config item. If it is set to 0 then old-style hooks are used. If it is set to 1 then new-style hooks are used. LXC_LOG_LEVEL: the container's log level. LXC_NAME: is the container's name. LXC_[NAMESPACE IDENTIFIER]_NS: path under /proc/PID/fd/ to a file descriptor referring to the container's namespace. For each preserved namespace type there will be a separate environment variable. These environment variables will only be set if is set to 1. LXC_ROOTFS_MOUNT: the path to the mounted root filesystem. LXC_ROOTFS_PATH: this is the lxc.rootfs.path entry for the container. Note this is likely not where the mounted rootfs is to be found, use LXC_ROOTFS_MOUNT for that. LXC_SRC_NAME: in the case of the clone hook, this is the original container's name. Standard output from the hooks is logged at debug level. Standard error is not logged, but can be captured by the hook redirecting its standard error to standard output. To pass the arguments in new style via environment variables set to 1 otherwise set to 0 to pass them as arguments. This setting affects all hooks arguments that were traditionally passed as arguments to the script. Specifically, it affects the container name, section (e.g. 'lxc', 'net') and hook type (e.g. 'clone', 'mount', 'pre-mount') arguments. If new-style hooks are used then the arguments will be available as environment variables. The container name will be set in LXC_NAME. (This is set independently of the value used for this config item.) The section will be set in LXC_HOOK_SECTION and the hook type will be set in LXC_HOOK_TYPE. It also affects how the paths to file descriptors referring to the container's namespaces are passed. If set to 1 then for each namespace a separate environment variable LXC_[NAMESPACE IDENTIFIER]_NS will be set. If set to 0 then the paths will be passed as arguments to the stop hook. A hook to be run in the host's namespace before the container ttys, consoles, or mounts are up. A hook to be run in the container's fs namespace but before the rootfs has been set up. This allows for manipulation of the rootfs, i.e. to mount an encrypted filesystem. Mounts done in this hook will not be reflected on the host (apart from mounts propagation), so they will be automatically cleaned up when the container shuts down. A hook to be run in the container's namespace after mounting has been done, but before the pivot_root. A hook to be run in the container's namespace after mounting has been done and after any mount hooks have run, but before the pivot_root, if == 1. The purpose of this hook is to assist in populating the /dev directory of the container when using the autodev option for systemd based containers. The container's /dev directory is relative to the ${} environment variable available when the hook is run. A hook to be run in the host's namespace after the container has been setup, and immediately before starting the container init. A hook to be run in the container's namespace immediately before executing the container's init. This requires the program to be available in the container. A hook to be run in the host's namespace with references to the container's namespaces after the container has been shut down. For each namespace an extra argument is passed to the hook containing the namespace's type and a filename that can be used to obtain a file descriptor to the corresponding namespace, separated by a colon. The type is the name as it would appear in the /proc/PID/ns directory. For instance for the mount namespace the argument usually looks like mnt:/proc/PID/fd/12. A hook to be run in the host's namespace after the container has been shut down. A hook to be run when the container is cloned to a new one. See lxc-clone 1 for more information. A hook to be run when the container is destroyed. Container hooks Environment Variables A number of environment variables are made available to the startup hooks to provide configuration information and assist in the functioning of the hooks. Not all variables are valid in all contexts. In particular, all paths are relative to the host system and, as such, not valid during the hook. The LXC name of the container. Useful for logging messages in common log environments. [] Host relative path to the container configuration file. This gives the container to reference the original, top level, configuration file for the container in order to locate any additional configuration information not otherwise made available. [] The path to the console output of the container if not NULL. [] [] The path to the console log output of the container if not NULL. [] The mount location to which the container is initially bound. This will be the host relative path to the container rootfs for the container instance being started and is where changes should be made for that instance. [] The host relative path to the container root which has been mounted to the rootfs.mount location. [] Only for the clone hook. Is set to the original container name. Only for the stop hook. Is set to "stop" for a container shutdown or "reboot" for a container reboot. If unset, then this version of lxc is not aware of cgroup namespaces. If set, it will be set to 1, and lxc is aware of cgroup namespaces. Note this does not guarantee that cgroup namespaces are enabled in the kernel. This is used by the lxcfs mount hook. Logging Logging can be configured on a per-container basis. By default, depending upon how the lxc package was compiled, container startup is logged only at the ERROR level, and logged to a file named after the container (with '.log' appended) either under the container path, or under @LOGPATH@. Both the default log level and the log file can be specified in the container configuration file, overriding the default behavior. Note that the configuration file entries can in turn be overridden by the command line options to lxc-start. The level at which to log. The log level is an integer in the range of 0..8 inclusive, where a lower number means more verbose debugging. In particular 0 = trace, 1 = debug, 2 = info, 3 = notice, 4 = warn, 5 = error, 6 = critical, 7 = alert, and 8 = fatal. If unspecified, the level defaults to 5 (error), so that only errors and above are logged. Note that when a script (such as either a hook script or a network interface up or down script) is called, the script's standard output is logged at level 1, debug. The file to which logging info should be written. Send logging info to syslog. It respects the log level defined in lxc.log.level. The argument should be the syslog facility to use, valid ones are: daemon, local0, local1, local2, local3, local4, local5, local5, local6, local7. Autostart The autostart options support marking which containers should be auto-started and in what order. These options may be used by LXC tools directly or by external tooling provided by the distributions. Whether the container should be auto-started. Valid values are 0 (off) and 1 (on). How long to wait (in seconds) after the container is started before starting the next one. An integer used to sort the containers when auto-starting a series of containers at once. If not zero the mount namespace will be unshared from the host before initializing the container (before running any pre-start hooks). This requires the CAP_SYS_ADMIN capability at startup. Default is 0. A multi-value key (can be used multiple times) to put the container in a container group. Those groups can then be used (amongst other things) to start a series of related containers. Autostart and System Boot Each container can be part of any number of groups or no group at all. Two groups are special. One is the NULL group, i.e. the container does not belong to any group. The other group is the "onboot" group. When the system boots with the LXC service enabled, it will first attempt to boot any containers with lxc.start.auto == 1 that is a member of the "onboot" group. The startup will be in order of lxc.start.order. If an lxc.start.delay has been specified, that delay will be honored before attempting to start the next container to give the current container time to begin initialization and reduce overloading the host system. After starting the members of the "onboot" group, the LXC system will proceed to boot containers with lxc.start.auto == 1 which are not members of any group (the NULL group) and proceed as with the onboot group. Container Environment If you want to pass environment variables into the container (that is, environment variables which will be available to init and all of its descendents), you can use lxc.environment parameters to do so. Be careful that you do not pass in anything sensitive; any process in the container which doesn't have its environment scrubbed will have these variables available to it, and environment variables are always available via /proc/PID/environ. This configuration parameter can be specified multiple times; once for each environment variable you wish to configure. Specify an environment variable to pass into the container. Example: lxc.environment = APP_ENV=production lxc.environment = SYSLOG_SERVER=192.0.2.42 Examples In addition to the few examples given below, you will find some other examples of configuration file in @DOCDIR@/examples Network This configuration sets up a container to use a veth pair device with one side plugged to a bridge br0 (which has been configured before on the system by the administrator). The virtual network device visible in the container is renamed to eth0. lxc.uts.name = myhostname lxc.net.0.type = veth lxc.net.0.flags = up lxc.net.0.link = br0 lxc.net.0.name = eth0 lxc.net.0.hwaddr = 4a:49:43:49:79:bf lxc.net.0.ipv4.address = 10.2.3.5/24 10.2.3.255 lxc.net.0.ipv6.address = 2003:db8:1:0:214:1234:fe0b:3597 UID/GID mapping This configuration will map both user and group ids in the range 0-9999 in the container to the ids 100000-109999 on the host. lxc.idmap = u 0 100000 10000 lxc.idmap = g 0 100000 10000 Control group This configuration will setup several control groups for the application, cpuset.cpus restricts usage of the defined cpu, cpus.share prioritize the control group, devices.allow makes usable the specified devices. lxc.cgroup.cpuset.cpus = 0,1 lxc.cgroup.cpu.shares = 1234 lxc.cgroup.devices.deny = a lxc.cgroup.devices.allow = c 1:3 rw lxc.cgroup.devices.allow = b 8:0 rw Complex configuration This example show a complex configuration making a complex network stack, using the control groups, setting a new hostname, mounting some locations and a changing root file system. lxc.uts.name = complex lxc.net.0.type = veth lxc.net.0.flags = up lxc.net.0.link = br0 lxc.net.0.hwaddr = 4a:49:43:49:79:bf lxc.net.0.ipv4.address = 10.2.3.5/24 10.2.3.255 lxc.net.0.ipv6.address = 2003:db8:1:0:214:1234:fe0b:3597 lxc.net.0.ipv6.address = 2003:db8:1:0:214:5432:feab:3588 lxc.net.1.type = macvlan lxc.net.1.flags = up lxc.net.1.link = eth0 lxc.net.1.hwaddr = 4a:49:43:49:79:bd lxc.net.1.ipv4.address = 10.2.3.4/24 lxc.net.1.ipv4.address = 192.168.10.125/24 lxc.net.1.ipv6.address = 2003:db8:1:0:214:1234:fe0b:3596 lxc.net.2.type = phys lxc.net.2.flags = up lxc.net.2.link = dummy0 lxc.net.2.hwaddr = 4a:49:43:49:79:ff lxc.net.2.ipv4.address = 10.2.3.6/24 lxc.net.2.ipv6.address = 2003:db8:1:0:214:1234:fe0b:3297 lxc.cgroup.cpuset.cpus = 0,1 lxc.cgroup.cpu.shares = 1234 lxc.cgroup.devices.deny = a lxc.cgroup.devices.allow = c 1:3 rw lxc.cgroup.devices.allow = b 8:0 rw lxc.mount.fstab = /etc/fstab.complex lxc.mount.entry = /lib /root/myrootfs/lib none ro,bind 0 0 lxc.rootfs.path = dir:/mnt/rootfs.complex lxc.cap.drop = sys_module mknod setuid net_raw lxc.cap.drop = mac_override See Also chroot 1 , pivot_root 8 , fstab 5 , capabilities 7 &seealso; Author Daniel Lezcano daniel.lezcano@free.fr lxc-3.0.1/doc/lxc-user-nic.sgml.in0000644061062106075000000001111713304304316013577 00000000000000 ]> @LXC_GENERATE_DATE@ lxc-user-nic 1 lxc-user-nic Create and attach a nic to another network namespace. lxc-user-nic pid type bridge nicname Description lxc-user-nic is a setuid-root program with which unprivileged users may create network interfaces for use by a lxc container. It will consult the configuration file @LXC_USERNIC_CONF@ to determine the number of interfaces which the calling user is allowed to create, and which bridge he may attach them to. It tracks the number of interfaces each user has created using the file @LXC_USERNIC_DB@. It ensures that the calling user is privileged over the network namespace to which the interface will be attached. Options The process id for the task to whose network namespace the interface should be attached. The network interface type to attach. Currently only veth is supported. With this type, two interfaces representing each tunnel endpoint are created. One endpoint will be attached to the specified bridge, while the other will be passed into the container. The bridge to which to attach the network interface, for instance lxcbr0. The desired interface name in the container. This will be eth0 if unspecified. See Also lxc 1 , lxc-start 1 , lxc-usernet 5 Author Daniel Lezcano daniel.lezcano@free.fr lxc-3.0.1/doc/lxc-wait.sgml.in0000644061062106075000000000715513304304316013025 00000000000000 ]> @LXC_GENERATE_DATE@ lxc-wait 1 lxc-wait wait for a specific container state lxc-wait -n name -s states Description lxc-wait waits for a specific container state before exiting, this is useful for scripting. Options Specify the container state(s) to wait for. The container states can be ORed to specify several states. Wait timeout seconds for desired state to be reached. &commonoptions; Examples lxc-wait -n foo -s RUNNING exits when 'RUNNING' is reached. lxc-wait -n foo -s 'RUNNING|STOPPED' exits when 'RUNNING' or 'STOPPED' state is reached. Diagnostic The container was not found The specified container was not created before with the lxc-create command. &seealso; Author Daniel Lezcano daniel.lezcano@free.fr lxc-3.0.1/doc/lxc-ls.sgml.in0000644061062106075000000001535113304304316012474 00000000000000 ]> @LXC_GENERATE_DATE@ lxc-ls 1 lxc-ls list the containers existing on the system lxc-ls -1 --active --frozen --running --stopped --defined -f -F format -g groups --nesting=NUM --filter=regex Description lxc-ls list the containers existing on the system. Options Show one entry per line. (default when /dev/stdout isn't a tty) List only active containers (same as --frozen --running). List only frozen containers. List only running containers. List only stopped containers. List only defined containers. Use a fancy, column-based output. Comma separated list of columns to show in the fancy output. The list of accepted and default fields is listed in --help. Comma separated list of groups the container must have to be displayed. The parameter may be passed multiple times. Show nested containers. The number of nesting levels to be shown can be specified by passing a number as argument. The regular expression passed to lxc-ls will be applied to the container name. The format is a POSIX extended regular expression. It can also be given as additional argument without explicitly using . Examples lxc-ls --fancy list all the containers, listing one per line along with its name, state, ipv4 and ipv6 addresses. lxc-ls --active -1 list active containers and display the list in one column. &commonoptions; &seealso; History Written originally as a shell script by Daniel Lezcano and Serge Hallyn. Later reimplemented and extended in Python by Stéphane Graber and then reimplemented and extended in C by Christian Brauner. Author Christian Brauner christian.brauner@mailbox.org, Stéphane Graber stgraber@ubuntu.com lxc-3.0.1/doc/rootfs/0000755061062106075000000000000013304304526011373 500000000000000lxc-3.0.1/doc/rootfs/README0000644061062106075000000000027513304304316012174 00000000000000This directory must exist, even though it may be empty. It is used to temporary mount the rootfs of lxc in a private mount namespace only visible by the processes running in the container. lxc-3.0.1/doc/rootfs/Makefile.am0000644061062106075000000000005713304304316013346 00000000000000READMEdir=@LXCROOTFSMOUNT@ README_DATA=README lxc-3.0.1/doc/rootfs/Makefile.in0000644061062106075000000003731213304304327013365 00000000000000# Makefile.in generated by automake 1.15.1 from Makefile.am. # @configure_input@ # Copyright (C) 1994-2017 Free Software Foundation, Inc. # This Makefile.in is free software; the Free Software Foundation # gives unlimited permission to copy and/or distribute it, # with or without modifications, as long as this notice is preserved. # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY, to the extent permitted by law; without # even the implied warranty of MERCHANTABILITY or FITNESS FOR A # PARTICULAR PURPOSE. @SET_MAKE@ VPATH = @srcdir@ am__is_gnu_make = { \ if test -z '$(MAKELEVEL)'; then \ false; \ elif test -n '$(MAKE_HOST)'; then \ true; \ elif test -n '$(MAKE_VERSION)' && test -n '$(CURDIR)'; then \ true; \ else \ false; \ fi; \ } am__make_running_with_option = \ case $${target_option-} in \ ?) ;; \ *) echo "am__make_running_with_option: internal error: invalid" \ "target option '$${target_option-}' specified" >&2; \ exit 1;; \ esac; \ has_opt=no; \ sane_makeflags=$$MAKEFLAGS; \ if $(am__is_gnu_make); then \ sane_makeflags=$$MFLAGS; \ else \ case $$MAKEFLAGS in \ *\\[\ \ ]*) \ bs=\\; \ sane_makeflags=`printf '%s\n' "$$MAKEFLAGS" \ | sed "s/$$bs$$bs[$$bs $$bs ]*//g"`;; \ esac; \ fi; \ skip_next=no; \ strip_trailopt () \ { \ flg=`printf '%s\n' "$$flg" | sed "s/$$1.*$$//"`; \ }; \ for flg in $$sane_makeflags; do \ test $$skip_next = yes && { skip_next=no; continue; }; \ case $$flg in \ *=*|--*) continue;; \ -*I) strip_trailopt 'I'; skip_next=yes;; \ -*I?*) strip_trailopt 'I';; \ -*O) strip_trailopt 'O'; skip_next=yes;; \ -*O?*) strip_trailopt 'O';; \ -*l) strip_trailopt 'l'; skip_next=yes;; \ -*l?*) strip_trailopt 'l';; \ -[dEDm]) skip_next=yes;; \ -[JT]) skip_next=yes;; \ esac; \ case $$flg in \ *$$target_option*) has_opt=yes; break;; \ esac; \ done; \ test $$has_opt = yes am__make_dryrun = (target_option=n; $(am__make_running_with_option)) am__make_keepgoing = (target_option=k; $(am__make_running_with_option)) pkgdatadir = $(datadir)/@PACKAGE@ pkgincludedir = $(includedir)/@PACKAGE@ pkglibdir = $(libdir)/@PACKAGE@ pkglibexecdir = $(libexecdir)/@PACKAGE@ am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd install_sh_DATA = $(install_sh) -c -m 644 install_sh_PROGRAM = $(install_sh) -c install_sh_SCRIPT = $(install_sh) -c INSTALL_HEADER = $(INSTALL_DATA) transform = $(program_transform_name) NORMAL_INSTALL = : PRE_INSTALL = : POST_INSTALL = : NORMAL_UNINSTALL = : PRE_UNINSTALL = : POST_UNINSTALL = : build_triplet = @build@ host_triplet = @host@ subdir = doc/rootfs ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 am__aclocal_m4_deps = $(top_srcdir)/config/acinclude.m4 \ $(top_srcdir)/config/ax_pthread.m4 \ $(top_srcdir)/config/libtool.m4 \ $(top_srcdir)/config/ltoptions.m4 \ $(top_srcdir)/config/ltsugar.m4 \ $(top_srcdir)/config/ltversion.m4 \ $(top_srcdir)/config/lt~obsolete.m4 \ $(top_srcdir)/config/tls.m4 $(top_srcdir)/configure.ac am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \ $(ACLOCAL_M4) DIST_COMMON = $(srcdir)/Makefile.am $(am__DIST_COMMON) mkinstalldirs = $(install_sh) -d CONFIG_HEADER = $(top_builddir)/src/config.h CONFIG_CLEAN_FILES = CONFIG_CLEAN_VPATH_FILES = AM_V_P = $(am__v_P_@AM_V@) am__v_P_ = $(am__v_P_@AM_DEFAULT_V@) am__v_P_0 = false am__v_P_1 = : AM_V_GEN = $(am__v_GEN_@AM_V@) am__v_GEN_ = $(am__v_GEN_@AM_DEFAULT_V@) am__v_GEN_0 = @echo " GEN " $@; am__v_GEN_1 = AM_V_at = $(am__v_at_@AM_V@) am__v_at_ = $(am__v_at_@AM_DEFAULT_V@) am__v_at_0 = @ am__v_at_1 = SOURCES = DIST_SOURCES = am__can_run_installinfo = \ case $$AM_UPDATE_INFO_DIR in \ n|no|NO) false;; \ *) (install-info --version) >/dev/null 2>&1;; \ esac am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`; am__vpath_adj = case $$p in \ $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \ *) f=$$p;; \ esac; am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`; am__install_max = 40 am__nobase_strip_setup = \ srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'` am__nobase_strip = \ for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||" am__nobase_list = $(am__nobase_strip_setup); \ for p in $$list; do echo "$$p $$p"; done | \ sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \ $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \ if (++n[$$2] == $(am__install_max)) \ { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \ END { for (dir in files) print dir, files[dir] }' am__base_list = \ sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \ sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g' am__uninstall_files_from_dir = { \ test -z "$$files" \ || { test ! -d "$$dir" && test ! -f "$$dir" && test ! -r "$$dir"; } \ || { echo " ( cd '$$dir' && rm -f" $$files ")"; \ $(am__cd) "$$dir" && rm -f $$files; }; \ } am__installdirs = "$(DESTDIR)$(READMEdir)" DATA = $(README_DATA) am__tagged_files = $(HEADERS) $(SOURCES) $(TAGS_FILES) $(LISP) am__DIST_COMMON = $(srcdir)/Makefile.in README DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) ACLOCAL = @ACLOCAL@ AMTAR = @AMTAR@ AM_DEFAULT_VERBOSITY = @AM_DEFAULT_VERBOSITY@ AR = @AR@ AUTOCONF = @AUTOCONF@ AUTOHEADER = @AUTOHEADER@ AUTOMAKE = @AUTOMAKE@ AWK = @AWK@ BINDIR = @BINDIR@ CAP_LIBS = @CAP_LIBS@ CC = @CC@ CCDEPMODE = @CCDEPMODE@ CFLAGS = @CFLAGS@ CPP = @CPP@ CPPFLAGS = @CPPFLAGS@ CYGPATH_W = @CYGPATH_W@ DATADIR = @DATADIR@ DEFAULT_CGROUP_PATTERN = @DEFAULT_CGROUP_PATTERN@ DEFS = @DEFS@ DEPDIR = @DEPDIR@ DLLTOOL = @DLLTOOL@ DOCDIR = @DOCDIR@ DSYMUTIL = @DSYMUTIL@ DUMPBIN = @DUMPBIN@ ECHO_C = @ECHO_C@ ECHO_N = @ECHO_N@ ECHO_T = @ECHO_T@ EGREP = @EGREP@ EXEEXT = @EXEEXT@ FGREP = @FGREP@ GNUTLS_LIBS = @GNUTLS_LIBS@ GREP = @GREP@ HAVE_DOXYGEN = @HAVE_DOXYGEN@ INCLUDEDIR = @INCLUDEDIR@ INSTALL = @INSTALL@ INSTALL_DATA = @INSTALL_DATA@ INSTALL_PROGRAM = @INSTALL_PROGRAM@ INSTALL_SCRIPT = @INSTALL_SCRIPT@ INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@ LD = @LD@ LDFLAGS = @LDFLAGS@ LIBDIR = @LIBDIR@ LIBEXECDIR = @LIBEXECDIR@ LIBOBJS = @LIBOBJS@ LIBS = @LIBS@ LIBTOOL = @LIBTOOL@ LIBTOOL_DEPS = @LIBTOOL_DEPS@ LIPO = @LIPO@ LN_S = @LN_S@ LOCALSTATEDIR = @LOCALSTATEDIR@ LOGPATH = @LOGPATH@ LTLIBOBJS = @LTLIBOBJS@ LT_SYS_LIBRARY_PATH = @LT_SYS_LIBRARY_PATH@ LXCBINHOOKDIR = @LXCBINHOOKDIR@ LXCHOOKDIR = @LXCHOOKDIR@ LXCINITDIR = @LXCINITDIR@ LXCPATH = @LXCPATH@ LXCROOTFSMOUNT = @LXCROOTFSMOUNT@ LXCTEMPLATECONFIG = @LXCTEMPLATECONFIG@ LXCTEMPLATEDIR = @LXCTEMPLATEDIR@ LXC_ABI = @LXC_ABI@ LXC_ABI_MAJOR = @LXC_ABI_MAJOR@ LXC_ABI_MICRO = @LXC_ABI_MICRO@ LXC_ABI_MINOR = @LXC_ABI_MINOR@ LXC_DEFAULT_CONFIG = @LXC_DEFAULT_CONFIG@ LXC_DEVEL = @LXC_DEVEL@ LXC_DISTRO_SYSCONF = @LXC_DISTRO_SYSCONF@ LXC_GENERATE_DATE = @LXC_GENERATE_DATE@ LXC_GLOBAL_CONF = @LXC_GLOBAL_CONF@ LXC_USERNIC_CONF = @LXC_USERNIC_CONF@ LXC_USERNIC_DB = @LXC_USERNIC_DB@ LXC_VERSION = @LXC_VERSION@ LXC_VERSION_BASE = @LXC_VERSION_BASE@ LXC_VERSION_BETA = @LXC_VERSION_BETA@ LXC_VERSION_MAJOR = @LXC_VERSION_MAJOR@ LXC_VERSION_MICRO = @LXC_VERSION_MICRO@ LXC_VERSION_MINOR = @LXC_VERSION_MINOR@ MAKEINFO = @MAKEINFO@ MANIFEST_TOOL = @MANIFEST_TOOL@ MKDIR_P = @MKDIR_P@ NM = @NM@ NMEDIT = @NMEDIT@ OBJDUMP = @OBJDUMP@ OBJEXT = @OBJEXT@ OTOOL = @OTOOL@ OTOOL64 = @OTOOL64@ PACKAGE = @PACKAGE@ PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@ PACKAGE_NAME = @PACKAGE_NAME@ PACKAGE_STRING = @PACKAGE_STRING@ PACKAGE_TARNAME = @PACKAGE_TARNAME@ PACKAGE_URL = @PACKAGE_URL@ PACKAGE_VERSION = @PACKAGE_VERSION@ PAM_CFLAGS = @PAM_CFLAGS@ PAM_LIBS = @PAM_LIBS@ PATH_SEPARATOR = @PATH_SEPARATOR@ PKG_CONFIG = @PKG_CONFIG@ PKG_CONFIG_LIBDIR = @PKG_CONFIG_LIBDIR@ PKG_CONFIG_PATH = @PKG_CONFIG_PATH@ PREFIX = @PREFIX@ PTHREAD_CC = @PTHREAD_CC@ PTHREAD_CFLAGS = @PTHREAD_CFLAGS@ PTHREAD_LIBS = @PTHREAD_LIBS@ RANLIB = @RANLIB@ RUNTIME_PATH = @RUNTIME_PATH@ SBINDIR = @SBINDIR@ SECCOMP_CFLAGS = @SECCOMP_CFLAGS@ SECCOMP_LIBS = @SECCOMP_LIBS@ SED = @SED@ SELINUX_LIBS = @SELINUX_LIBS@ SET_MAKE = @SET_MAKE@ SHELL = @SHELL@ STRIP = @STRIP@ SYSCONFDIR = @SYSCONFDIR@ SYSTEMD_UNIT_DIR = @SYSTEMD_UNIT_DIR@ VERSION = @VERSION@ abs_builddir = @abs_builddir@ abs_srcdir = @abs_srcdir@ abs_top_builddir = @abs_top_builddir@ abs_top_srcdir = @abs_top_srcdir@ ac_ct_AR = @ac_ct_AR@ ac_ct_CC = @ac_ct_CC@ ac_ct_DUMPBIN = @ac_ct_DUMPBIN@ am__include = @am__include@ am__leading_dot = @am__leading_dot@ am__quote = @am__quote@ am__tar = @am__tar@ am__untar = @am__untar@ ax_pthread_config = @ax_pthread_config@ bashcompdir = @bashcompdir@ bindir = @bindir@ build = @build@ build_alias = @build_alias@ build_cpu = @build_cpu@ build_os = @build_os@ build_vendor = @build_vendor@ builddir = @builddir@ datadir = @datadir@ datarootdir = @datarootdir@ db2xman = @db2xman@ docdir = @docdir@ docdtd = @docdtd@ dvidir = @dvidir@ exec_prefix = @exec_prefix@ host = @host@ host_alias = @host_alias@ host_cpu = @host_cpu@ host_os = @host_os@ host_vendor = @host_vendor@ htmldir = @htmldir@ includedir = @includedir@ infodir = @infodir@ install_sh = @install_sh@ libdir = @libdir@ libexecdir = @libexecdir@ localedir = @localedir@ localstatedir = @localstatedir@ mandir = @mandir@ mkdir_p = @mkdir_p@ oldincludedir = @oldincludedir@ pamdir = @pamdir@ pdfdir = @pdfdir@ prefix = @prefix@ program_transform_name = @program_transform_name@ psdir = @psdir@ runstatedir = @runstatedir@ sbindir = @sbindir@ sharedstatedir = @sharedstatedir@ srcdir = @srcdir@ sysconfdir = @sysconfdir@ target_alias = @target_alias@ top_build_prefix = @top_build_prefix@ top_builddir = @top_builddir@ top_srcdir = @top_srcdir@ READMEdir = @LXCROOTFSMOUNT@ README_DATA = README all: all-am .SUFFIXES: $(srcdir)/Makefile.in: $(srcdir)/Makefile.am $(am__configure_deps) @for dep in $?; do \ case '$(am__configure_deps)' in \ *$$dep*) \ ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \ && { if test -f $@; then exit 0; else break; fi; }; \ exit 1;; \ esac; \ done; \ echo ' cd $(top_srcdir) && $(AUTOMAKE) --gnu doc/rootfs/Makefile'; \ $(am__cd) $(top_srcdir) && \ $(AUTOMAKE) --gnu doc/rootfs/Makefile Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status @case '$?' in \ *config.status*) \ cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \ *) \ echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \ cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \ esac; $(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES) cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh $(top_srcdir)/configure: $(am__configure_deps) cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh $(ACLOCAL_M4): $(am__aclocal_m4_deps) cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh $(am__aclocal_m4_deps): mostlyclean-libtool: -rm -f *.lo clean-libtool: -rm -rf .libs _libs install-READMEDATA: $(README_DATA) @$(NORMAL_INSTALL) @list='$(README_DATA)'; test -n "$(READMEdir)" || list=; \ if test -n "$$list"; then \ echo " $(MKDIR_P) '$(DESTDIR)$(READMEdir)'"; \ $(MKDIR_P) "$(DESTDIR)$(READMEdir)" || exit 1; \ fi; \ for p in $$list; do \ if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \ echo "$$d$$p"; \ done | $(am__base_list) | \ while read files; do \ echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(READMEdir)'"; \ $(INSTALL_DATA) $$files "$(DESTDIR)$(READMEdir)" || exit $$?; \ done uninstall-READMEDATA: @$(NORMAL_UNINSTALL) @list='$(README_DATA)'; test -n "$(READMEdir)" || list=; \ files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \ dir='$(DESTDIR)$(READMEdir)'; $(am__uninstall_files_from_dir) tags TAGS: ctags CTAGS: cscope cscopelist: distdir: $(DISTFILES) @srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \ topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \ list='$(DISTFILES)'; \ dist_files=`for file in $$list; do echo $$file; done | \ sed -e "s|^$$srcdirstrip/||;t" \ -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \ case $$dist_files in \ */*) $(MKDIR_P) `echo "$$dist_files" | \ sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \ sort -u` ;; \ esac; \ for file in $$dist_files; do \ if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \ if test -d $$d/$$file; then \ dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \ if test -d "$(distdir)/$$file"; then \ find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \ fi; \ if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \ cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \ find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \ fi; \ cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \ else \ test -f "$(distdir)/$$file" \ || cp -p $$d/$$file "$(distdir)/$$file" \ || exit 1; \ fi; \ done check-am: all-am check: check-am all-am: Makefile $(DATA) installdirs: for dir in "$(DESTDIR)$(READMEdir)"; do \ test -z "$$dir" || $(MKDIR_P) "$$dir"; \ done install: install-am install-exec: install-exec-am install-data: install-data-am uninstall: uninstall-am install-am: all-am @$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am installcheck: installcheck-am install-strip: if test -z '$(STRIP)'; then \ $(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \ install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \ install; \ else \ $(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \ install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \ "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'" install; \ fi mostlyclean-generic: clean-generic: distclean-generic: -test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES) -test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES) maintainer-clean-generic: @echo "This command is intended for maintainers to use" @echo "it deletes files that may require special tools to rebuild." clean: clean-am clean-am: clean-generic clean-libtool mostlyclean-am distclean: distclean-am -rm -f Makefile distclean-am: clean-am distclean-generic dvi: dvi-am dvi-am: html: html-am html-am: info: info-am info-am: install-data-am: install-READMEDATA install-dvi: install-dvi-am install-dvi-am: install-exec-am: install-html: install-html-am install-html-am: install-info: install-info-am install-info-am: install-man: install-pdf: install-pdf-am install-pdf-am: install-ps: install-ps-am install-ps-am: installcheck-am: maintainer-clean: maintainer-clean-am -rm -f Makefile maintainer-clean-am: distclean-am maintainer-clean-generic mostlyclean: mostlyclean-am mostlyclean-am: mostlyclean-generic mostlyclean-libtool pdf: pdf-am pdf-am: ps: ps-am ps-am: uninstall-am: uninstall-READMEDATA .MAKE: install-am install-strip .PHONY: all all-am check check-am clean clean-generic clean-libtool \ cscopelist-am ctags-am distclean distclean-generic \ distclean-libtool distdir dvi dvi-am html html-am info info-am \ install install-READMEDATA install-am install-data \ install-data-am install-dvi install-dvi-am install-exec \ install-exec-am install-html install-html-am install-info \ install-info-am install-man install-pdf install-pdf-am \ install-ps install-ps-am install-strip installcheck \ installcheck-am installdirs maintainer-clean \ maintainer-clean-generic mostlyclean mostlyclean-generic \ mostlyclean-libtool pdf pdf-am ps ps-am tags-am uninstall \ uninstall-READMEDATA uninstall-am .PRECIOUS: Makefile # Tell versions [3.59,3.63) of GNU make to not export all variables. # Otherwise a system limit (for SysV at least) may be exceeded. .NOEXPORT: lxc-3.0.1/doc/lxc-usernet.sgml.in0000644061062106075000000001072713304304316013545 00000000000000 ]> @LXC_GENERATE_DATE@ lxc-usernet 5 lxc-usernet unprivileged user network administration file. Description @LXC_USERNIC_CONF@ controls the limits which the program lxc-user-nic places on network interfaces which an unprivileged user may create. Configuration This file consists of multiple entries, one per line, of the form: user type bridge number or @group type bridge number Where is the username to whom this entry applies. is the groupname to which this entry applies. is the type of network interface being allowed. Only veth is currently supported. is the bridge to which the network interfaces may be attached, for instance lxcbr0. is the number or quota of network interfaces of the given type which the given user or group may attach to the given bridge, for instance 2. Since a user can be specified both by username as well as one or more usergroups, it is possible that several configuration lines enable that user to create network interfaces. In such cases, any interfaces create are counted towards the quotas of the user or group in the order in which they appear in the file. If the quota of one line is full, the rest will be parsed until one is found or the end of the file. See Also lxc 1 , lxc-user-nic 1 Author Daniel Lezcano daniel.lezcano@free.fr lxc-3.0.1/doc/lxc.conf.sgml.in0000644061062106075000000001031613304304316013000 00000000000000 ]> @LXC_GENERATE_DATE@ lxc.conf 5 lxc.conf Configuration files for LXC. Description LXC configuration is split in two parts. Container configuration and system configuration. Container configuration The container configuration is held in the config stored in the container's directory. A basic configuration is generated at container creation time with the default's recommended for the chosen template as well as extra default keys coming from the default.conf file. That default.conf file is either located at @LXC_DEFAULT_CONFIG@ or for unprivileged containers at ~/.config/lxc/default.conf. Details about the syntax of this file can be found in: lxc.container.conf 5 System configuration The system configuration is located at @LXC_GLOBAL_CONF@ or ~/.config/lxc/lxc.conf for unprivileged containers. This configuration file is used to set values such as default lookup paths and storage backend settings for LXC. Details about the syntax of this file can be found in: lxc.system.conf 5 See Also lxc 1 , lxc.container.conf 5 , lxc.system.conf 5 , lxc-usernet 5 Author Stéphane Graber stgraber@ubuntu.com lxc-3.0.1/doc/lxc-console.sgml.in0000644061062106075000000001075013304304316013516 00000000000000 ]> @LXC_GENERATE_DATE@ lxc-console 1 lxc-console Launch a console for the specified container lxc-console -n name -e escape character -t ttynum Description If the tty service has been configured and is available for the container specified as parameter, this command will launch a console allowing to log on the container. The available tty are free slots taken by this command. That means if the container has four ttys available and the command has been launched four times each taking a different tty, the fifth command will fail because no console will be available. The command will connect to a tty. If the connection is lost or broken, the command can be launched again and regain the tty at the state it was before the disconnection. A ttynum of 0 may be given to attach to the container's /dev/console instead of its dev/tty<ttynum>. A keyboard escape sequence may be used to disconnect from the tty and quit lxc-console. The default escape sequence is <Ctrl+a q>. Options Specify the escape sequence prefix to use instead of <Ctrl a>. This may be given as '^letter' or just 'letter'. For example to use <Ctrl+b q> as the escape sequence use -e '^b'. Specify the tty number to connect to or 0 for the console. If not specified the next available tty number will be automatically chosen by the container. &commonoptions; Diagnostic tty service denied No tty is available or there is not enough privilege to use the console. For example, the container belongs to user "foo" and "bar" is trying to open a console to it. &seealso; Author Daniel Lezcano daniel.lezcano@free.fr lxc-3.0.1/doc/lxc-snapshot.sgml.in0000644061062106075000000001235513304304316013716 00000000000000 ]> @LXC_GENERATE_DATE@ lxc-snapshot 1 lxc-snapshot Snapshot an existing container. lxc-snapshot -n, --name name -c, --comment file lxc-snapshot -n, --name name -d, -destroy snapshot-name lxc-snapshot -n, --name name -L, --list -C, --showcomments lxc-snapshot -n, --name name -r, -restore snapshot-name -N, --newname newname Description lxc-snapshot creates, lists, and restores container snapshots. Snapshots are stored as snapshotted containers under the container's configuration path. For instance, if the container's configuration path is /var/lib/lxc and the container is c1, then the first snapshot will be stored as container snap0 under the path /var/lib/lxc/c1/snaps. If /var/lib/lxcsnaps, as used by LXC 1.0, already exists, then it will continue to be used. Options Associate the comment in comment_file with the newly created snapshot. Destroy the named snapshot. If the named snapshot is ALL, then all snapshots will be destroyed. List existing snapshots. Show snapshot comments in the snapshots listings. Restore the named snapshot, meaning a full new container is created which is a copy of the snapshot. When restoring a snapshot, the last optional argument if not given explicitly via --newname is the name to use for the restored container. If the newname is identical to the original name of the container, then the original container will be destroyed and the restored container will take its place. Note that deleting the original snapshot is not possible in the case of overlayfs or zfs backed snapshots. &commonoptions; &seealso; Author Serge Hallyn serge.hallyn@ubuntu.com lxc-3.0.1/doc/lxc.system.conf0000644061062106075000000000065713304304316012764 00000000000000# LVM: volume group to use for new containers lxc.bdev.lvm.vg = lxc # LVM: thin pool to use for new containers lxc.bdev.lvm.thin_pool = lxc # ZFS: Root path lxc.bdev.zfs.root = lxc # Path to the containers lxc.lxcpath = /var/lib/lxc/ # Path to the default configuration file lxc.default_config = /etc/lxc/default.conf # Pattern to use for the cgroup path lxc.cgroup.pattern = lxc/%n # List of cgroups to use lxc.cgroup.use = lxc-3.0.1/doc/api/0000755061062106075000000000000013304304526010630 500000000000000lxc-3.0.1/doc/api/Doxyfile0000644061062106075000000030211213304304316012252 00000000000000# Doxyfile 1.8.5 # This file describes the settings to be used by the documentation system # doxygen (www.doxygen.org) for a project. # # All text after a double hash (##) is considered a comment and is placed in # front of the TAG it is preceding. # # All text after a single hash (#) is considered a comment and will be ignored. # The format is: # TAG = value [value, ...] # For lists, items can also be appended using: # TAG += value [value, ...] # Values that contain spaces should be placed between quotes (\" \"). #--------------------------------------------------------------------------- # Project related configuration options #--------------------------------------------------------------------------- # This tag specifies the encoding used for all characters in the config file # that follow. The default is UTF-8 which is also the encoding used for all text # before the first occurrence of this tag. Doxygen uses libiconv (or the iconv # built into libc) for the transcoding. See http://www.gnu.org/software/libiconv # for the list of possible encodings. # The default value is: UTF-8. DOXYFILE_ENCODING = UTF-8 # The PROJECT_NAME tag is a single word (or a sequence of words surrounded by # double-quotes, unless you are using Doxywizard) that should identify the # project for which the documentation is generated. This name is used in the # title of most generated pages and in a few other places. # The default value is: My Project. PROJECT_NAME = "LXC" # The PROJECT_NUMBER tag can be used to enter a project or revision number. This # could be handy for archiving the generated documentation or if some version # control system is used. PROJECT_NUMBER = # Using the PROJECT_BRIEF tag one can provide an optional one line description # for a project that appears at the top of each page and should give viewer a # quick idea about the purpose of the project. Keep the description short. PROJECT_BRIEF = # With the PROJECT_LOGO tag one can specify an logo or icon that is included in # the documentation. The maximum height of the logo should not exceed 55 pixels # and the maximum width should not exceed 200 pixels. Doxygen will copy the logo # to the output directory. PROJECT_LOGO = # The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) path # into which the generated documentation will be written. If a relative path is # entered, it will be relative to the location where doxygen was started. If # left blank the current directory will be used. OUTPUT_DIRECTORY = . # If the CREATE_SUBDIRS tag is set to YES, then doxygen will create 4096 sub- # directories (in 2 levels) under the output directory of each output format and # will distribute the generated files over these directories. Enabling this # option can be useful when feeding doxygen a huge amount of source files, where # putting all generated files in the same directory would otherwise causes # performance problems for the file system. # The default value is: NO. CREATE_SUBDIRS = NO # The OUTPUT_LANGUAGE tag is used to specify the language in which all # documentation generated by doxygen is written. Doxygen will use this # information to generate all constant output in the proper language. # Possible values are: Afrikaans, Arabic, Brazilian, Catalan, Chinese, Chinese- # Traditional, Croatian, Czech, Danish, Dutch, English, Esperanto, Farsi, # Finnish, French, German, Greek, Hungarian, Italian, Japanese, Japanese-en, # Korean, Korean-en, Latvian, Norwegian, Macedonian, Persian, Polish, # Portuguese, Romanian, Russian, Serbian, Slovak, Slovene, Spanish, Swedish, # Turkish, Ukrainian and Vietnamese. # The default value is: English. OUTPUT_LANGUAGE = English # If the BRIEF_MEMBER_DESC tag is set to YES doxygen will include brief member # descriptions after the members that are listed in the file and class # documentation (similar to Javadoc). Set to NO to disable this. # The default value is: YES. BRIEF_MEMBER_DESC = YES # If the REPEAT_BRIEF tag is set to YES doxygen will prepend the brief # description of a member or function before the detailed description # # Note: If both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the # brief descriptions will be completely suppressed. # The default value is: YES. REPEAT_BRIEF = YES # This tag implements a quasi-intelligent brief description abbreviator that is # used to form the text in various listings. Each string in this list, if found # as the leading text of the brief description, will be stripped from the text # and the result, after processing the whole list, is used as the annotated # text. Otherwise, the brief description is used as-is. If left blank, the # following values are used ($name is automatically replaced with the name of # the entity):The $name class, The $name widget, The $name file, is, provides, # specifies, contains, represents, a, an and the. ABBREVIATE_BRIEF = # If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then # doxygen will generate a detailed section even if there is only a brief # description. # The default value is: NO. ALWAYS_DETAILED_SEC = NO # If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all # inherited members of a class in the documentation of that class as if those # members were ordinary class members. Constructors, destructors and assignment # operators of the base classes will not be shown. # The default value is: NO. INLINE_INHERITED_MEMB = NO # If the FULL_PATH_NAMES tag is set to YES doxygen will prepend the full path # before files name in the file list and in the header files. If set to NO the # shortest path that makes the file name unique will be used # The default value is: YES. FULL_PATH_NAMES = NO # The STRIP_FROM_PATH tag can be used to strip a user-defined part of the path. # Stripping is only done if one of the specified strings matches the left-hand # part of the path. The tag can be used to show relative paths in the file list. # If left blank the directory from which doxygen is run is used as the path to # strip. # # Note that you can specify absolute paths here, but also relative paths, which # will be relative from the directory where doxygen is started. # This tag requires that the tag FULL_PATH_NAMES is set to YES. STRIP_FROM_PATH = # The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of the # path mentioned in the documentation of a class, which tells the reader which # header file to include in order to use a class. If left blank only the name of # the header file containing the class definition is used. Otherwise one should # specify the list of include paths that are normally passed to the compiler # using the -I flag. STRIP_FROM_INC_PATH = # If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter (but # less readable) file names. This can be useful is your file systems doesn't # support long names like on DOS, Mac, or CD-ROM. # The default value is: NO. SHORT_NAMES = NO # If the JAVADOC_AUTOBRIEF tag is set to YES then doxygen will interpret the # first line (until the first dot) of a Javadoc-style comment as the brief # description. If set to NO, the Javadoc-style will behave just like regular Qt- # style comments (thus requiring an explicit @brief command for a brief # description.) # The default value is: NO. JAVADOC_AUTOBRIEF = NO # If the QT_AUTOBRIEF tag is set to YES then doxygen will interpret the first # line (until the first dot) of a Qt-style comment as the brief description. If # set to NO, the Qt-style will behave just like regular Qt-style comments (thus # requiring an explicit \brief command for a brief description.) # The default value is: NO. QT_AUTOBRIEF = NO # The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make doxygen treat a # multi-line C++ special comment block (i.e. a block of //! or /// comments) as # a brief description. This used to be the default behavior. The new default is # to treat a multi-line C++ comment block as a detailed description. Set this # tag to YES if you prefer the old behavior instead. # # Note that setting this tag to YES also means that rational rose comments are # not recognized any more. # The default value is: NO. MULTILINE_CPP_IS_BRIEF = NO # If the INHERIT_DOCS tag is set to YES then an undocumented member inherits the # documentation from any documented member that it re-implements. # The default value is: YES. INHERIT_DOCS = YES # If the SEPARATE_MEMBER_PAGES tag is set to YES, then doxygen will produce a # new page for each member. If set to NO, the documentation of a member will be # part of the file/class/namespace that contains it. # The default value is: NO. SEPARATE_MEMBER_PAGES = NO # The TAB_SIZE tag can be used to set the number of spaces in a tab. Doxygen # uses this value to replace tabs by spaces in code fragments. # Minimum value: 1, maximum value: 16, default value: 4. TAB_SIZE = 4 # This tag can be used to specify a number of aliases that act as commands in # the documentation. An alias has the form: # name=value # For example adding # "sideeffect=@par Side Effects:\n" # will allow you to put the command \sideeffect (or @sideeffect) in the # documentation, which will result in a user-defined paragraph with heading # "Side Effects:". You can put \n's in the value part of an alias to insert # newlines. ALIASES = # This tag can be used to specify a number of word-keyword mappings (TCL only). # A mapping has the form "name=value". For example adding "class=itcl::class" # will allow you to use the command class in the itcl::class meaning. TCL_SUBST = # Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C sources # only. Doxygen will then generate output that is more tailored for C. For # instance, some of the names that are used will be different. The list of all # members will be omitted, etc. # The default value is: NO. OPTIMIZE_OUTPUT_FOR_C = YES # Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java or # Python sources only. Doxygen will then generate output that is more tailored # for that language. For instance, namespaces will be presented as packages, # qualified scopes will look different, etc. # The default value is: NO. OPTIMIZE_OUTPUT_JAVA = NO # Set the OPTIMIZE_FOR_FORTRAN tag to YES if your project consists of Fortran # sources. Doxygen will then generate output that is tailored for Fortran. # The default value is: NO. OPTIMIZE_FOR_FORTRAN = NO # Set the OPTIMIZE_OUTPUT_VHDL tag to YES if your project consists of VHDL # sources. Doxygen will then generate output that is tailored for VHDL. # The default value is: NO. OPTIMIZE_OUTPUT_VHDL = NO # Doxygen selects the parser to use depending on the extension of the files it # parses. With this tag you can assign which parser to use for a given # extension. Doxygen has a built-in mapping, but you can override or extend it # using this tag. The format is ext=language, where ext is a file extension, and # language is one of the parsers supported by doxygen: IDL, Java, Javascript, # C#, C, C++, D, PHP, Objective-C, Python, Fortran, VHDL. For instance to make # doxygen treat .inc files as Fortran files (default is PHP), and .f files as C # (default is Fortran), use: inc=Fortran f=C. # # Note For files without extension you can use no_extension as a placeholder. # # Note that for custom extensions you also need to set FILE_PATTERNS otherwise # the files are not read by doxygen. EXTENSION_MAPPING = # If the MARKDOWN_SUPPORT tag is enabled then doxygen pre-processes all comments # according to the Markdown format, which allows for more readable # documentation. See http://daringfireball.net/projects/markdown/ for details. # The output of markdown processing is further processed by doxygen, so you can # mix doxygen, HTML, and XML commands with Markdown formatting. Disable only in # case of backward compatibilities issues. # The default value is: YES. MARKDOWN_SUPPORT = YES # When enabled doxygen tries to link words that correspond to documented # classes, or namespaces to their corresponding documentation. Such a link can # be prevented in individual cases by by putting a % sign in front of the word # or globally by setting AUTOLINK_SUPPORT to NO. # The default value is: YES. AUTOLINK_SUPPORT = YES # If you use STL classes (i.e. std::string, std::vector, etc.) but do not want # to include (a tag file for) the STL sources as input, then you should set this # tag to YES in order to let doxygen match functions declarations and # definitions whose arguments contain STL classes (e.g. func(std::string); # versus func(std::string) {}). This also make the inheritance and collaboration # diagrams that involve STL classes more complete and accurate. # The default value is: NO. BUILTIN_STL_SUPPORT = NO # If you use Microsoft's C++/CLI language, you should set this option to YES to # enable parsing support. # The default value is: NO. CPP_CLI_SUPPORT = NO # Set the SIP_SUPPORT tag to YES if your project consists of sip (see: # http://www.riverbankcomputing.co.uk/software/sip/intro) sources only. Doxygen # will parse them like normal C++ but will assume all classes use public instead # of private inheritance when no explicit protection keyword is present. # The default value is: NO. SIP_SUPPORT = NO # For Microsoft's IDL there are propget and propput attributes to indicate # getter and setter methods for a property. Setting this option to YES will make # doxygen to replace the get and set methods by a property in the documentation. # This will only work if the methods are indeed getting or setting a simple # type. If this is not the case, or you want to show the methods anyway, you # should set this option to NO. # The default value is: YES. IDL_PROPERTY_SUPPORT = YES # If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC # tag is set to YES, then doxygen will reuse the documentation of the first # member in the group (if any) for the other members of the group. By default # all members of a group must be documented explicitly. # The default value is: NO. DISTRIBUTE_GROUP_DOC = YES # Set the SUBGROUPING tag to YES to allow class member groups of the same type # (for instance a group of public functions) to be put as a subgroup of that # type (e.g. under the Public Functions section). Set it to NO to prevent # subgrouping. Alternatively, this can be done per class using the # \nosubgrouping command. # The default value is: YES. SUBGROUPING = YES # When the INLINE_GROUPED_CLASSES tag is set to YES, classes, structs and unions # are shown inside the group in which they are included (e.g. using \ingroup) # instead of on a separate page (for HTML and Man pages) or section (for LaTeX # and RTF). # # Note that this feature does not work in combination with # SEPARATE_MEMBER_PAGES. # The default value is: NO. INLINE_GROUPED_CLASSES = NO # When the INLINE_SIMPLE_STRUCTS tag is set to YES, structs, classes, and unions # with only public data fields or simple typedef fields will be shown inline in # the documentation of the scope in which they are defined (i.e. file, # namespace, or group documentation), provided this scope is documented. If set # to NO, structs, classes, and unions are shown on a separate page (for HTML and # Man pages) or section (for LaTeX and RTF). # The default value is: NO. INLINE_SIMPLE_STRUCTS = NO # When TYPEDEF_HIDES_STRUCT tag is enabled, a typedef of a struct, union, or # enum is documented as struct, union, or enum with the name of the typedef. So # typedef struct TypeS {} TypeT, will appear in the documentation as a struct # with name TypeT. When disabled the typedef will appear as a member of a file, # namespace, or class. And the struct will be named TypeS. This can typically be # useful for C code in case the coding convention dictates that all compound # types are typedef'ed and only the typedef is referenced, never the tag name. # The default value is: NO. TYPEDEF_HIDES_STRUCT = NO # The size of the symbol lookup cache can be set using LOOKUP_CACHE_SIZE. This # cache is used to resolve symbols given their name and scope. Since this can be # an expensive process and often the same symbol appears multiple times in the # code, doxygen keeps a cache of pre-resolved symbols. If the cache is too small # doxygen will become slower. If the cache is too large, memory is wasted. The # cache size is given by this formula: 2^(16+LOOKUP_CACHE_SIZE). The valid range # is 0..9, the default is 0, corresponding to a cache size of 2^16=65536 # symbols. At the end of a run doxygen will report the cache usage and suggest # the optimal cache size from a speed point of view. # Minimum value: 0, maximum value: 9, default value: 0. LOOKUP_CACHE_SIZE = 0 #--------------------------------------------------------------------------- # Build related configuration options #--------------------------------------------------------------------------- # If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in # documentation are documented, even if no documentation was available. Private # class members and static file members will be hidden unless the # EXTRACT_PRIVATE respectively EXTRACT_STATIC tags are set to YES. # Note: This will also disable the warnings about undocumented members that are # normally produced when WARNINGS is set to YES. # The default value is: NO. EXTRACT_ALL = NO # If the EXTRACT_PRIVATE tag is set to YES all private members of a class will # be included in the documentation. # The default value is: NO. EXTRACT_PRIVATE = NO # If the EXTRACT_PACKAGE tag is set to YES all members with package or internal # scope will be included in the documentation. # The default value is: NO. EXTRACT_PACKAGE = NO # If the EXTRACT_STATIC tag is set to YES all static members of a file will be # included in the documentation. # The default value is: NO. EXTRACT_STATIC = NO # If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs) defined # locally in source files will be included in the documentation. If set to NO # only classes defined in header files are included. Does not have any effect # for Java sources. # The default value is: YES. EXTRACT_LOCAL_CLASSES = YES # This flag is only useful for Objective-C code. When set to YES local methods, # which are defined in the implementation section but not in the interface are # included in the documentation. If set to NO only methods in the interface are # included. # The default value is: NO. EXTRACT_LOCAL_METHODS = NO # If this flag is set to YES, the members of anonymous namespaces will be # extracted and appear in the documentation as a namespace called # 'anonymous_namespace{file}', where file will be replaced with the base name of # the file that contains the anonymous namespace. By default anonymous namespace # are hidden. # The default value is: NO. EXTRACT_ANON_NSPACES = NO # If the HIDE_UNDOC_MEMBERS tag is set to YES, doxygen will hide all # undocumented members inside documented classes or files. If set to NO these # members will be included in the various overviews, but no documentation # section is generated. This option has no effect if EXTRACT_ALL is enabled. # The default value is: NO. HIDE_UNDOC_MEMBERS = NO # If the HIDE_UNDOC_CLASSES tag is set to YES, doxygen will hide all # undocumented classes that are normally visible in the class hierarchy. If set # to NO these classes will be included in the various overviews. This option has # no effect if EXTRACT_ALL is enabled. # The default value is: NO. HIDE_UNDOC_CLASSES = NO # If the HIDE_FRIEND_COMPOUNDS tag is set to YES, doxygen will hide all friend # (class|struct|union) declarations. If set to NO these declarations will be # included in the documentation. # The default value is: NO. HIDE_FRIEND_COMPOUNDS = NO # If the HIDE_IN_BODY_DOCS tag is set to YES, doxygen will hide any # documentation blocks found inside the body of a function. If set to NO these # blocks will be appended to the function's detailed documentation block. # The default value is: NO. HIDE_IN_BODY_DOCS = NO # The INTERNAL_DOCS tag determines if documentation that is typed after a # \internal command is included. If the tag is set to NO then the documentation # will be excluded. Set it to YES to include the internal documentation. # The default value is: NO. INTERNAL_DOCS = NO # If the CASE_SENSE_NAMES tag is set to NO then doxygen will only generate file # names in lower-case letters. If set to YES upper-case letters are also # allowed. This is useful if you have classes or files whose names only differ # in case and if your file system supports case sensitive file names. Windows # and Mac users are advised to set this option to NO. # The default value is: system dependent. CASE_SENSE_NAMES = YES # If the HIDE_SCOPE_NAMES tag is set to NO then doxygen will show members with # their full class and namespace scopes in the documentation. If set to YES the # scope will be hidden. # The default value is: NO. HIDE_SCOPE_NAMES = NO # If the SHOW_INCLUDE_FILES tag is set to YES then doxygen will put a list of # the files that are included by a file in the documentation of that file. # The default value is: YES. SHOW_INCLUDE_FILES = YES # If the FORCE_LOCAL_INCLUDES tag is set to YES then doxygen will list include # files with double quotes in the documentation rather than with sharp brackets. # The default value is: NO. FORCE_LOCAL_INCLUDES = NO # If the INLINE_INFO tag is set to YES then a tag [inline] is inserted in the # documentation for inline members. # The default value is: YES. INLINE_INFO = YES # If the SORT_MEMBER_DOCS tag is set to YES then doxygen will sort the # (detailed) documentation of file and class members alphabetically by member # name. If set to NO the members will appear in declaration order. # The default value is: YES. SORT_MEMBER_DOCS = YES # If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the brief # descriptions of file, namespace and class members alphabetically by member # name. If set to NO the members will appear in declaration order. # The default value is: NO. SORT_BRIEF_DOCS = NO # If the SORT_MEMBERS_CTORS_1ST tag is set to YES then doxygen will sort the # (brief and detailed) documentation of class members so that constructors and # destructors are listed first. If set to NO the constructors will appear in the # respective orders defined by SORT_BRIEF_DOCS and SORT_MEMBER_DOCS. # Note: If SORT_BRIEF_DOCS is set to NO this option is ignored for sorting brief # member documentation. # Note: If SORT_MEMBER_DOCS is set to NO this option is ignored for sorting # detailed member documentation. # The default value is: NO. SORT_MEMBERS_CTORS_1ST = NO # If the SORT_GROUP_NAMES tag is set to YES then doxygen will sort the hierarchy # of group names into alphabetical order. If set to NO the group names will # appear in their defined order. # The default value is: NO. SORT_GROUP_NAMES = NO # If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be sorted by # fully-qualified names, including namespaces. If set to NO, the class list will # be sorted only by class name, not including the namespace part. # Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES. # Note: This option applies only to the class list, not to the alphabetical # list. # The default value is: NO. SORT_BY_SCOPE_NAME = NO # If the STRICT_PROTO_MATCHING option is enabled and doxygen fails to do proper # type resolution of all parameters of a function it will reject a match between # the prototype and the implementation of a member function even if there is # only one candidate or it is obvious which candidate to choose by doing a # simple string match. By disabling STRICT_PROTO_MATCHING doxygen will still # accept a match between prototype and implementation in such cases. # The default value is: NO. STRICT_PROTO_MATCHING = NO # The GENERATE_TODOLIST tag can be used to enable ( YES) or disable ( NO) the # todo list. This list is created by putting \todo commands in the # documentation. # The default value is: YES. GENERATE_TODOLIST = YES # The GENERATE_TESTLIST tag can be used to enable ( YES) or disable ( NO) the # test list. This list is created by putting \test commands in the # documentation. # The default value is: YES. GENERATE_TESTLIST = YES # The GENERATE_BUGLIST tag can be used to enable ( YES) or disable ( NO) the bug # list. This list is created by putting \bug commands in the documentation. # The default value is: YES. GENERATE_BUGLIST = YES # The GENERATE_DEPRECATEDLIST tag can be used to enable ( YES) or disable ( NO) # the deprecated list. This list is created by putting \deprecated commands in # the documentation. # The default value is: YES. GENERATE_DEPRECATEDLIST= YES # The ENABLED_SECTIONS tag can be used to enable conditional documentation # sections, marked by \if ... \endif and \cond # ... \endcond blocks. ENABLED_SECTIONS = # The MAX_INITIALIZER_LINES tag determines the maximum number of lines that the # initial value of a variable or macro / define can have for it to appear in the # documentation. If the initializer consists of more lines than specified here # it will be hidden. Use a value of 0 to hide initializers completely. The # appearance of the value of individual variables and macros / defines can be # controlled using \showinitializer or \hideinitializer command in the # documentation regardless of this setting. # Minimum value: 0, maximum value: 10000, default value: 30. MAX_INITIALIZER_LINES = 30 # Set the SHOW_USED_FILES tag to NO to disable the list of files generated at # the bottom of the documentation of classes and structs. If set to YES the list # will mention the files that were used to generate the documentation. # The default value is: YES. SHOW_USED_FILES = YES # Set the SHOW_FILES tag to NO to disable the generation of the Files page. This # will remove the Files entry from the Quick Index and from the Folder Tree View # (if specified). # The default value is: YES. SHOW_FILES = YES # Set the SHOW_NAMESPACES tag to NO to disable the generation of the Namespaces # page. This will remove the Namespaces entry from the Quick Index and from the # Folder Tree View (if specified). # The default value is: YES. SHOW_NAMESPACES = YES # The FILE_VERSION_FILTER tag can be used to specify a program or script that # doxygen should invoke to get the current version for each file (typically from # the version control system). Doxygen will invoke the program by executing (via # popen()) the command command input-file, where command is the value of the # FILE_VERSION_FILTER tag, and input-file is the name of an input file provided # by doxygen. Whatever the program writes to standard output is used as the file # version. For an example see the documentation. FILE_VERSION_FILTER = # The LAYOUT_FILE tag can be used to specify a layout file which will be parsed # by doxygen. The layout file controls the global structure of the generated # output files in an output format independent way. To create the layout file # that represents doxygen's defaults, run doxygen with the -l option. You can # optionally specify a file name after the option, if omitted DoxygenLayout.xml # will be used as the name of the layout file. # # Note that if you run doxygen from a directory containing a file called # DoxygenLayout.xml, doxygen will parse it automatically even if the LAYOUT_FILE # tag is left empty. LAYOUT_FILE = # The CITE_BIB_FILES tag can be used to specify one or more bib files containing # the reference definitions. This must be a list of .bib files. The .bib # extension is automatically appended if omitted. This requires the bibtex tool # to be installed. See also http://en.wikipedia.org/wiki/BibTeX for more info. # For LaTeX the style of the bibliography can be controlled using # LATEX_BIB_STYLE. To use this feature you need bibtex and perl available in the # search path. Do not use file names with spaces, bibtex cannot handle them. See # also \cite for info how to create references. CITE_BIB_FILES = #--------------------------------------------------------------------------- # Configuration options related to warning and progress messages #--------------------------------------------------------------------------- # The QUIET tag can be used to turn on/off the messages that are generated to # standard output by doxygen. If QUIET is set to YES this implies that the # messages are off. # The default value is: NO. QUIET = NO # The WARNINGS tag can be used to turn on/off the warning messages that are # generated to standard error ( stderr) by doxygen. If WARNINGS is set to YES # this implies that the warnings are on. # # Tip: Turn warnings on while writing the documentation. # The default value is: YES. WARNINGS = YES # If the WARN_IF_UNDOCUMENTED tag is set to YES, then doxygen will generate # warnings for undocumented members. If EXTRACT_ALL is set to YES then this flag # will automatically be disabled. # The default value is: YES. WARN_IF_UNDOCUMENTED = YES # If the WARN_IF_DOC_ERROR tag is set to YES, doxygen will generate warnings for # potential errors in the documentation, such as not documenting some parameters # in a documented function, or documenting parameters that don't exist or using # markup commands wrongly. # The default value is: YES. WARN_IF_DOC_ERROR = YES # This WARN_NO_PARAMDOC option can be enabled to get warnings for functions that # are documented, but have no documentation for their parameters or return # value. If set to NO doxygen will only warn about wrong or incomplete parameter # documentation, but not about the absence of documentation. # The default value is: NO. WARN_NO_PARAMDOC = YES # The WARN_FORMAT tag determines the format of the warning messages that doxygen # can produce. The string should contain the $file, $line, and $text tags, which # will be replaced by the file and line number from which the warning originated # and the warning text. Optionally the format may contain $version, which will # be replaced by the version of the file (if it could be obtained via # FILE_VERSION_FILTER) # The default value is: $file:$line: $text. WARN_FORMAT = "$file:$line: $text" # The WARN_LOGFILE tag can be used to specify a file to which warning and error # messages should be written. If left blank the output is written to standard # error (stderr). WARN_LOGFILE = #--------------------------------------------------------------------------- # Configuration options related to the input files #--------------------------------------------------------------------------- # The INPUT tag is used to specify the files and/or directories that contain # documented source files. You may enter file names like myfile.cpp or # directories like /usr/src/myproject. Separate the files or directories with # spaces. # Note: If this tag is empty the current directory is searched. INPUT = \ ../../src/lxc/lxccontainer.h \ ../../src/lxc/lxclock.h \ ../../src/lxc/attach_options.h # This tag can be used to specify the character encoding of the source files # that doxygen parses. Internally doxygen uses the UTF-8 encoding. Doxygen uses # libiconv (or the iconv built into libc) for the transcoding. See the libiconv # documentation (see: http://www.gnu.org/software/libiconv) for the list of # possible encodings. # The default value is: UTF-8. INPUT_ENCODING = UTF-8 # If the value of the INPUT tag contains directories, you can use the # FILE_PATTERNS tag to specify one or more wildcard patterns (like *.cpp and # *.h) to filter out the source-files in the directories. If left blank the # following patterns are tested:*.c, *.cc, *.cxx, *.cpp, *.c++, *.java, *.ii, # *.ixx, *.ipp, *.i++, *.inl, *.idl, *.ddl, *.odl, *.h, *.hh, *.hxx, *.hpp, # *.h++, *.cs, *.d, *.php, *.php4, *.php5, *.phtml, *.inc, *.m, *.markdown, # *.md, *.mm, *.dox, *.py, *.f90, *.f, *.for, *.tcl, *.vhd, *.vhdl, *.ucf, # *.qsf, *.as and *.js. FILE_PATTERNS = *.h # The RECURSIVE tag can be used to specify whether or not subdirectories should # be searched for input files as well. # The default value is: NO. RECURSIVE = NO # The EXCLUDE tag can be used to specify files and/or directories that should be # excluded from the INPUT source files. This way you can easily exclude a # subdirectory from a directory tree whose root is specified with the INPUT tag. # # Note that relative paths are relative to the directory from which doxygen is # run. EXCLUDE = # The EXCLUDE_SYMLINKS tag can be used to select whether or not files or # directories that are symbolic links (a Unix file system feature) are excluded # from the input. # The default value is: NO. EXCLUDE_SYMLINKS = NO # If the value of the INPUT tag contains directories, you can use the # EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude # certain files from those directories. # # Note that the wildcards are matched against the file with absolute path, so to # exclude all test directories for example use the pattern */test/* EXCLUDE_PATTERNS = # The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names # (namespaces, classes, functions, etc.) that should be excluded from the # output. The symbol name can be a fully qualified name, a word, or if the # wildcard * is used, a substring. Examples: ANamespace, AClass, # AClass::ANamespace, ANamespace::*Test # # Note that the wildcards are matched against the file with absolute path, so to # exclude all test directories use the pattern */test/* EXCLUDE_SYMBOLS = # The EXAMPLE_PATH tag can be used to specify one or more files or directories # that contain example code fragments that are included (see the \include # command). EXAMPLE_PATH = # If the value of the EXAMPLE_PATH tag contains directories, you can use the # EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp and # *.h) to filter out the source-files in the directories. If left blank all # files are included. EXAMPLE_PATTERNS = # If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be # searched for input files to be used with the \include or \dontinclude commands # irrespective of the value of the RECURSIVE tag. # The default value is: NO. EXAMPLE_RECURSIVE = NO # The IMAGE_PATH tag can be used to specify one or more files or directories # that contain images that are to be included in the documentation (see the # \image command). IMAGE_PATH = # The INPUT_FILTER tag can be used to specify a program that doxygen should # invoke to filter for each input file. Doxygen will invoke the filter program # by executing (via popen()) the command: # # # # where is the value of the INPUT_FILTER tag, and is the # name of an input file. Doxygen will then use the output that the filter # program writes to standard output. If FILTER_PATTERNS is specified, this tag # will be ignored. # # Note that the filter must not add or remove lines; it is applied before the # code is scanned, but not when the output code is generated. If lines are added # or removed, the anchors will not be placed correctly. INPUT_FILTER = # The FILTER_PATTERNS tag can be used to specify filters on a per file pattern # basis. Doxygen will compare the file name with each pattern and apply the # filter if there is a match. The filters are a list of the form: pattern=filter # (like *.cpp=my_cpp_filter). See INPUT_FILTER for further information on how # filters are used. If the FILTER_PATTERNS tag is empty or if none of the # patterns match the file name, INPUT_FILTER is applied. FILTER_PATTERNS = # If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using # INPUT_FILTER ) will also be used to filter the input files that are used for # producing the source files to browse (i.e. when SOURCE_BROWSER is set to YES). # The default value is: NO. FILTER_SOURCE_FILES = NO # The FILTER_SOURCE_PATTERNS tag can be used to specify source filters per file # pattern. A pattern will override the setting for FILTER_PATTERN (if any) and # it is also possible to disable source filtering for a specific pattern using # *.ext= (so without naming a filter). # This tag requires that the tag FILTER_SOURCE_FILES is set to YES. FILTER_SOURCE_PATTERNS = # If the USE_MDFILE_AS_MAINPAGE tag refers to the name of a markdown file that # is part of the input, its contents will be placed on the main page # (index.html). This can be useful if you have a project on for instance GitHub # and want to reuse the introduction page also for the doxygen output. USE_MDFILE_AS_MAINPAGE = #--------------------------------------------------------------------------- # Configuration options related to source browsing #--------------------------------------------------------------------------- # If the SOURCE_BROWSER tag is set to YES then a list of source files will be # generated. Documented entities will be cross-referenced with these sources. # # Note: To get rid of all source code in the generated output, make sure that # also VERBATIM_HEADERS is set to NO. # The default value is: NO. SOURCE_BROWSER = NO # Setting the INLINE_SOURCES tag to YES will include the body of functions, # classes and enums directly into the documentation. # The default value is: NO. INLINE_SOURCES = NO # Setting the STRIP_CODE_COMMENTS tag to YES will instruct doxygen to hide any # special comment blocks from generated source code fragments. Normal C, C++ and # Fortran comments will always remain visible. # The default value is: YES. STRIP_CODE_COMMENTS = YES # If the REFERENCED_BY_RELATION tag is set to YES then for each documented # function all documented functions referencing it will be listed. # The default value is: NO. REFERENCED_BY_RELATION = NO # If the REFERENCES_RELATION tag is set to YES then for each documented function # all documented entities called/used by that function will be listed. # The default value is: NO. REFERENCES_RELATION = NO # If the REFERENCES_LINK_SOURCE tag is set to YES and SOURCE_BROWSER tag is set # to YES, then the hyperlinks from functions in REFERENCES_RELATION and # REFERENCED_BY_RELATION lists will link to the source code. Otherwise they will # link to the documentation. # The default value is: YES. REFERENCES_LINK_SOURCE = YES # If SOURCE_TOOLTIPS is enabled (the default) then hovering a hyperlink in the # source code will show a tooltip with additional information such as prototype, # brief description and links to the definition and documentation. Since this # will make the HTML file larger and loading of large files a bit slower, you # can opt to disable this feature. # The default value is: YES. # This tag requires that the tag SOURCE_BROWSER is set to YES. SOURCE_TOOLTIPS = YES # If the USE_HTAGS tag is set to YES then the references to source code will # point to the HTML generated by the htags(1) tool instead of doxygen built-in # source browser. The htags tool is part of GNU's global source tagging system # (see http://www.gnu.org/software/global/global.html). You will need version # 4.8.6 or higher. # # To use it do the following: # - Install the latest version of global # - Enable SOURCE_BROWSER and USE_HTAGS in the config file # - Make sure the INPUT points to the root of the source tree # - Run doxygen as normal # # Doxygen will invoke htags (and that will in turn invoke gtags), so these # tools must be available from the command line (i.e. in the search path). # # The result: instead of the source browser generated by doxygen, the links to # source code will now point to the output of htags. # The default value is: NO. # This tag requires that the tag SOURCE_BROWSER is set to YES. USE_HTAGS = NO # If the VERBATIM_HEADERS tag is set the YES then doxygen will generate a # verbatim copy of the header file for each class for which an include is # specified. Set to NO to disable this. # See also: Section \class. # The default value is: YES. VERBATIM_HEADERS = YES #--------------------------------------------------------------------------- # Configuration options related to the alphabetical class index #--------------------------------------------------------------------------- # If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index of all # compounds will be generated. Enable this if the project contains a lot of # classes, structs, unions or interfaces. # The default value is: YES. ALPHABETICAL_INDEX = YES # The COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns in # which the alphabetical index list will be split. # Minimum value: 1, maximum value: 20, default value: 5. # This tag requires that the tag ALPHABETICAL_INDEX is set to YES. COLS_IN_ALPHA_INDEX = 5 # In case all classes in a project start with a common prefix, all classes will # be put under the same header in the alphabetical index. The IGNORE_PREFIX tag # can be used to specify a prefix (or a list of prefixes) that should be ignored # while generating the index headers. # This tag requires that the tag ALPHABETICAL_INDEX is set to YES. IGNORE_PREFIX = #--------------------------------------------------------------------------- # Configuration options related to the HTML output #--------------------------------------------------------------------------- # If the GENERATE_HTML tag is set to YES doxygen will generate HTML output # The default value is: YES. GENERATE_HTML = YES # The HTML_OUTPUT tag is used to specify where the HTML docs will be put. If a # relative path is entered the value of OUTPUT_DIRECTORY will be put in front of # it. # The default directory is: html. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_OUTPUT = html # The HTML_FILE_EXTENSION tag can be used to specify the file extension for each # generated HTML page (for example: .htm, .php, .asp). # The default value is: .html. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_FILE_EXTENSION = .html # The HTML_HEADER tag can be used to specify a user-defined HTML header file for # each generated HTML page. If the tag is left blank doxygen will generate a # standard header. # # To get valid HTML the header file that includes any scripts and style sheets # that doxygen needs, which is dependent on the configuration options used (e.g. # the setting GENERATE_TREEVIEW). It is highly recommended to start with a # default header using # doxygen -w html new_header.html new_footer.html new_stylesheet.css # YourConfigFile # and then modify the file new_header.html. See also section "Doxygen usage" # for information on how to generate the default header that doxygen normally # uses. # Note: The header is subject to change so you typically have to regenerate the # default header when upgrading to a newer version of doxygen. For a description # of the possible markers and block names see the documentation. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_HEADER = # The HTML_FOOTER tag can be used to specify a user-defined HTML footer for each # generated HTML page. If the tag is left blank doxygen will generate a standard # footer. See HTML_HEADER for more information on how to generate a default # footer and what special commands can be used inside the footer. See also # section "Doxygen usage" for information on how to generate the default footer # that doxygen normally uses. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_FOOTER = # The HTML_STYLESHEET tag can be used to specify a user-defined cascading style # sheet that is used by each HTML page. It can be used to fine-tune the look of # the HTML output. If left blank doxygen will generate a default style sheet. # See also section "Doxygen usage" for information on how to generate the style # sheet that doxygen normally uses. # Note: It is recommended to use HTML_EXTRA_STYLESHEET instead of this tag, as # it is more robust and this tag (HTML_STYLESHEET) will in the future become # obsolete. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_STYLESHEET = # The HTML_EXTRA_STYLESHEET tag can be used to specify an additional user- # defined cascading style sheet that is included after the standard style sheets # created by doxygen. Using this option one can overrule certain style aspects. # This is preferred over using HTML_STYLESHEET since it does not replace the # standard style sheet and is therefor more robust against future updates. # Doxygen will copy the style sheet file to the output directory. For an example # see the documentation. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_EXTRA_STYLESHEET = # The HTML_EXTRA_FILES tag can be used to specify one or more extra images or # other source files which should be copied to the HTML output directory. Note # that these files will be copied to the base HTML output directory. Use the # $relpath^ marker in the HTML_HEADER and/or HTML_FOOTER files to load these # files. In the HTML_STYLESHEET file, use the file name only. Also note that the # files will be copied as-is; there are no commands or markers available. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_EXTRA_FILES = # The HTML_COLORSTYLE_HUE tag controls the color of the HTML output. Doxygen # will adjust the colors in the stylesheet and background images according to # this color. Hue is specified as an angle on a colorwheel, see # http://en.wikipedia.org/wiki/Hue for more information. For instance the value # 0 represents red, 60 is yellow, 120 is green, 180 is cyan, 240 is blue, 300 # purple, and 360 is red again. # Minimum value: 0, maximum value: 359, default value: 220. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_COLORSTYLE_HUE = 220 # The HTML_COLORSTYLE_SAT tag controls the purity (or saturation) of the colors # in the HTML output. For a value of 0 the output will use grayscales only. A # value of 255 will produce the most vivid colors. # Minimum value: 0, maximum value: 255, default value: 100. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_COLORSTYLE_SAT = 100 # The HTML_COLORSTYLE_GAMMA tag controls the gamma correction applied to the # luminance component of the colors in the HTML output. Values below 100 # gradually make the output lighter, whereas values above 100 make the output # darker. The value divided by 100 is the actual gamma applied, so 80 represents # a gamma of 0.8, The value 220 represents a gamma of 2.2, and 100 does not # change the gamma. # Minimum value: 40, maximum value: 240, default value: 80. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_COLORSTYLE_GAMMA = 80 # If the HTML_TIMESTAMP tag is set to YES then the footer of each generated HTML # page will contain the date and time when the page was generated. Setting this # to NO can help when comparing the output of multiple runs. # The default value is: YES. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_TIMESTAMP = YES # If the HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML # documentation will contain sections that can be hidden and shown after the # page has loaded. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_DYNAMIC_SECTIONS = NO # With HTML_INDEX_NUM_ENTRIES one can control the preferred number of entries # shown in the various tree structured indices initially; the user can expand # and collapse entries dynamically later on. Doxygen will expand the tree to # such a level that at most the specified number of entries are visible (unless # a fully collapsed tree already exceeds this amount). So setting the number of # entries 1 will produce a full collapsed tree by default. 0 is a special value # representing an infinite number of entries and will result in a full expanded # tree by default. # Minimum value: 0, maximum value: 9999, default value: 100. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_INDEX_NUM_ENTRIES = 100 # If the GENERATE_DOCSET tag is set to YES, additional index files will be # generated that can be used as input for Apple's Xcode 3 integrated development # environment (see: http://developer.apple.com/tools/xcode/), introduced with # OSX 10.5 (Leopard). To create a documentation set, doxygen will generate a # Makefile in the HTML output directory. Running make will produce the docset in # that directory and running make install will install the docset in # ~/Library/Developer/Shared/Documentation/DocSets so that Xcode will find it at # startup. See http://developer.apple.com/tools/creatingdocsetswithdoxygen.html # for more information. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. GENERATE_DOCSET = NO # This tag determines the name of the docset feed. A documentation feed provides # an umbrella under which multiple documentation sets from a single provider # (such as a company or product suite) can be grouped. # The default value is: Doxygen generated docs. # This tag requires that the tag GENERATE_DOCSET is set to YES. DOCSET_FEEDNAME = "Doxygen generated docs" # This tag specifies a string that should uniquely identify the documentation # set bundle. This should be a reverse domain-name style string, e.g. # com.mycompany.MyDocSet. Doxygen will append .docset to the name. # The default value is: org.doxygen.Project. # This tag requires that the tag GENERATE_DOCSET is set to YES. DOCSET_BUNDLE_ID = org.doxygen.Project # The DOCSET_PUBLISHER_ID tag specifies a string that should uniquely identify # the documentation publisher. This should be a reverse domain-name style # string, e.g. com.mycompany.MyDocSet.documentation. # The default value is: org.doxygen.Publisher. # This tag requires that the tag GENERATE_DOCSET is set to YES. DOCSET_PUBLISHER_ID = org.doxygen.Publisher # The DOCSET_PUBLISHER_NAME tag identifies the documentation publisher. # The default value is: Publisher. # This tag requires that the tag GENERATE_DOCSET is set to YES. DOCSET_PUBLISHER_NAME = Publisher # If the GENERATE_HTMLHELP tag is set to YES then doxygen generates three # additional HTML index files: index.hhp, index.hhc, and index.hhk. The # index.hhp is a project file that can be read by Microsoft's HTML Help Workshop # (see: http://www.microsoft.com/en-us/download/details.aspx?id=21138) on # Windows. # # The HTML Help Workshop contains a compiler that can convert all HTML output # generated by doxygen into a single compiled HTML file (.chm). Compiled HTML # files are now used as the Windows 98 help format, and will replace the old # Windows help format (.hlp) on all Windows platforms in the future. Compressed # HTML files also contain an index, a table of contents, and you can search for # words in the documentation. The HTML workshop also contains a viewer for # compressed HTML files. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. GENERATE_HTMLHELP = NO # The CHM_FILE tag can be used to specify the file name of the resulting .chm # file. You can add a path in front of the file if the result should not be # written to the html output directory. # This tag requires that the tag GENERATE_HTMLHELP is set to YES. CHM_FILE = # The HHC_LOCATION tag can be used to specify the location (absolute path # including file name) of the HTML help compiler ( hhc.exe). If non-empty # doxygen will try to run the HTML help compiler on the generated index.hhp. # The file has to be specified with full path. # This tag requires that the tag GENERATE_HTMLHELP is set to YES. HHC_LOCATION = # The GENERATE_CHI flag controls if a separate .chi index file is generated ( # YES) or that it should be included in the master .chm file ( NO). # The default value is: NO. # This tag requires that the tag GENERATE_HTMLHELP is set to YES. GENERATE_CHI = NO # The CHM_INDEX_ENCODING is used to encode HtmlHelp index ( hhk), content ( hhc) # and project file content. # This tag requires that the tag GENERATE_HTMLHELP is set to YES. CHM_INDEX_ENCODING = # The BINARY_TOC flag controls whether a binary table of contents is generated ( # YES) or a normal table of contents ( NO) in the .chm file. # The default value is: NO. # This tag requires that the tag GENERATE_HTMLHELP is set to YES. BINARY_TOC = NO # The TOC_EXPAND flag can be set to YES to add extra items for group members to # the table of contents of the HTML help documentation and to the tree view. # The default value is: NO. # This tag requires that the tag GENERATE_HTMLHELP is set to YES. TOC_EXPAND = NO # If the GENERATE_QHP tag is set to YES and both QHP_NAMESPACE and # QHP_VIRTUAL_FOLDER are set, an additional index file will be generated that # can be used as input for Qt's qhelpgenerator to generate a Qt Compressed Help # (.qch) of the generated HTML documentation. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. GENERATE_QHP = NO # If the QHG_LOCATION tag is specified, the QCH_FILE tag can be used to specify # the file name of the resulting .qch file. The path specified is relative to # the HTML output folder. # This tag requires that the tag GENERATE_QHP is set to YES. QCH_FILE = # The QHP_NAMESPACE tag specifies the namespace to use when generating Qt Help # Project output. For more information please see Qt Help Project / Namespace # (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#namespace). # The default value is: org.doxygen.Project. # This tag requires that the tag GENERATE_QHP is set to YES. QHP_NAMESPACE = org.doxygen.Project # The QHP_VIRTUAL_FOLDER tag specifies the namespace to use when generating Qt # Help Project output. For more information please see Qt Help Project / Virtual # Folders (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#virtual- # folders). # The default value is: doc. # This tag requires that the tag GENERATE_QHP is set to YES. QHP_VIRTUAL_FOLDER = doc # If the QHP_CUST_FILTER_NAME tag is set, it specifies the name of a custom # filter to add. For more information please see Qt Help Project / Custom # Filters (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom- # filters). # This tag requires that the tag GENERATE_QHP is set to YES. QHP_CUST_FILTER_NAME = # The QHP_CUST_FILTER_ATTRS tag specifies the list of the attributes of the # custom filter to add. For more information please see Qt Help Project / Custom # Filters (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom- # filters). # This tag requires that the tag GENERATE_QHP is set to YES. QHP_CUST_FILTER_ATTRS = # The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes this # project's filter section matches. Qt Help Project / Filter Attributes (see: # http://qt-project.org/doc/qt-4.8/qthelpproject.html#filter-attributes). # This tag requires that the tag GENERATE_QHP is set to YES. QHP_SECT_FILTER_ATTRS = # The QHG_LOCATION tag can be used to specify the location of Qt's # qhelpgenerator. If non-empty doxygen will try to run qhelpgenerator on the # generated .qhp file. # This tag requires that the tag GENERATE_QHP is set to YES. QHG_LOCATION = # If the GENERATE_ECLIPSEHELP tag is set to YES, additional index files will be # generated, together with the HTML files, they form an Eclipse help plugin. To # install this plugin and make it available under the help contents menu in # Eclipse, the contents of the directory containing the HTML and XML files needs # to be copied into the plugins directory of eclipse. The name of the directory # within the plugins directory should be the same as the ECLIPSE_DOC_ID value. # After copying Eclipse needs to be restarted before the help appears. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. GENERATE_ECLIPSEHELP = NO # A unique identifier for the Eclipse help plugin. When installing the plugin # the directory name containing the HTML and XML files should also have this # name. Each documentation set should have its own identifier. # The default value is: org.doxygen.Project. # This tag requires that the tag GENERATE_ECLIPSEHELP is set to YES. ECLIPSE_DOC_ID = org.doxygen.Project # If you want full control over the layout of the generated HTML pages it might # be necessary to disable the index and replace it with your own. The # DISABLE_INDEX tag can be used to turn on/off the condensed index (tabs) at top # of each HTML page. A value of NO enables the index and the value YES disables # it. Since the tabs in the index contain the same information as the navigation # tree, you can set this option to YES if you also set GENERATE_TREEVIEW to YES. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. DISABLE_INDEX = NO # The GENERATE_TREEVIEW tag is used to specify whether a tree-like index # structure should be generated to display hierarchical information. If the tag # value is set to YES, a side panel will be generated containing a tree-like # index structure (just like the one that is generated for HTML Help). For this # to work a browser that supports JavaScript, DHTML, CSS and frames is required # (i.e. any modern browser). Windows users are probably better off using the # HTML help feature. Via custom stylesheets (see HTML_EXTRA_STYLESHEET) one can # further fine-tune the look of the index. As an example, the default style # sheet generated by doxygen has an example that shows how to put an image at # the root of the tree instead of the PROJECT_NAME. Since the tree basically has # the same information as the tab index, you could consider setting # DISABLE_INDEX to YES when enabling this option. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. GENERATE_TREEVIEW = NO # The ENUM_VALUES_PER_LINE tag can be used to set the number of enum values that # doxygen will group on one line in the generated HTML documentation. # # Note that a value of 0 will completely suppress the enum values from appearing # in the overview section. # Minimum value: 0, maximum value: 20, default value: 4. # This tag requires that the tag GENERATE_HTML is set to YES. ENUM_VALUES_PER_LINE = 4 # If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be used # to set the initial width (in pixels) of the frame in which the tree is shown. # Minimum value: 0, maximum value: 1500, default value: 250. # This tag requires that the tag GENERATE_HTML is set to YES. TREEVIEW_WIDTH = 250 # When the EXT_LINKS_IN_WINDOW option is set to YES doxygen will open links to # external symbols imported via tag files in a separate window. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. EXT_LINKS_IN_WINDOW = NO # Use this tag to change the font size of LaTeX formulas included as images in # the HTML documentation. When you change the font size after a successful # doxygen run you need to manually remove any form_*.png images from the HTML # output directory to force them to be regenerated. # Minimum value: 8, maximum value: 50, default value: 10. # This tag requires that the tag GENERATE_HTML is set to YES. FORMULA_FONTSIZE = 10 # Use the FORMULA_TRANPARENT tag to determine whether or not the images # generated for formulas are transparent PNGs. Transparent PNGs are not # supported properly for IE 6.0, but are supported on all modern browsers. # # Note that when changing this option you need to delete any form_*.png files in # the HTML output directory before the changes have effect. # The default value is: YES. # This tag requires that the tag GENERATE_HTML is set to YES. FORMULA_TRANSPARENT = YES # Enable the USE_MATHJAX option to render LaTeX formulas using MathJax (see # http://www.mathjax.org) which uses client side Javascript for the rendering # instead of using prerendered bitmaps. Use this if you do not have LaTeX # installed or if you want to formulas look prettier in the HTML output. When # enabled you may also need to install MathJax separately and configure the path # to it using the MATHJAX_RELPATH option. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. USE_MATHJAX = NO # When MathJax is enabled you can set the default output format to be used for # the MathJax output. See the MathJax site (see: # http://docs.mathjax.org/en/latest/output.html) for more details. # Possible values are: HTML-CSS (which is slower, but has the best # compatibility), NativeMML (i.e. MathML) and SVG. # The default value is: HTML-CSS. # This tag requires that the tag USE_MATHJAX is set to YES. MATHJAX_FORMAT = HTML-CSS # When MathJax is enabled you need to specify the location relative to the HTML # output directory using the MATHJAX_RELPATH option. The destination directory # should contain the MathJax.js script. For instance, if the mathjax directory # is located at the same level as the HTML output directory, then # MATHJAX_RELPATH should be ../mathjax. The default value points to the MathJax # Content Delivery Network so you can quickly see the result without installing # MathJax. However, it is strongly recommended to install a local copy of # MathJax from http://www.mathjax.org before deployment. # The default value is: http://cdn.mathjax.org/mathjax/latest. # This tag requires that the tag USE_MATHJAX is set to YES. MATHJAX_RELPATH = http://cdn.mathjax.org/mathjax/latest # The MATHJAX_EXTENSIONS tag can be used to specify one or more MathJax # extension names that should be enabled during MathJax rendering. For example # MATHJAX_EXTENSIONS = TeX/AMSmath TeX/AMSsymbols # This tag requires that the tag USE_MATHJAX is set to YES. MATHJAX_EXTENSIONS = # The MATHJAX_CODEFILE tag can be used to specify a file with javascript pieces # of code that will be used on startup of the MathJax code. See the MathJax site # (see: http://docs.mathjax.org/en/latest/output.html) for more details. For an # example see the documentation. # This tag requires that the tag USE_MATHJAX is set to YES. MATHJAX_CODEFILE = # When the SEARCHENGINE tag is enabled doxygen will generate a search box for # the HTML output. The underlying search engine uses javascript and DHTML and # should work on any modern browser. Note that when using HTML help # (GENERATE_HTMLHELP), Qt help (GENERATE_QHP), or docsets (GENERATE_DOCSET) # there is already a search function so this one should typically be disabled. # For large projects the javascript based search engine can be slow, then # enabling SERVER_BASED_SEARCH may provide a better solution. It is possible to # search using the keyboard; to jump to the search box use + S # (what the is depends on the OS and browser, but it is typically # , /