|
|
|
Configuration file:
|
umvs_conf.xml
|
|
Descritption:
|
umvs_conf.xml is the main configuration file for umvs.
XML nodes and attributes
/umvs/umvs-config
uid: The user id used to set directory permissions.gid: The group id used to set directory permissions.uml_spec: The path and name of the spec file.home: The path(/[ID]/ will be appended) where the COW and swap files should be created in.uml_dir: The path(/[ID]/ will be appended) where the UNIX sockets should be saved in.log: The path(/[ID]/ will be appended) where the log files should be saved in.append_log: (True/False)Should the UML output be appended to the log file.timeout: The time to wait for a UML to shutdown.default_template: The name and path of the default template.
/umvs/umvs-network
uid: User id used when starting the switch daemon and when
creating the tap devices.eth-device:[Optional] When specified the device will
be configured(added) to the specified bridge(refer to
dia1). When not specified, the
'tap-device' option below will be ignored(refer to
dia2) and a tap device for
each UML will be created. Note: When not specified, the bridge will not
be configured with any other devices.tap-device:[Optional]When specified, the uml_switch daemon
will be used(refer to dia1)
instead of a seperate tap device for each UML(refer to
dia3).bridge: The name of the bridge to configure.router: The IP address of the router, used when configuring
the bridge(this will normally be the IP address of the specified
'eth-device').subnet: The subnet mask of the network.netmask: The netmask of the network.dhcpd_conf: The path and name of the dhcpd.conf file.dhcpd_init: The path and name of the dhcpd init script.
/umvs/umls/uml
The following entries will be automatically added when running
'umvs -a [ID]':
id:The id of the UML.hostname:[Optional] The hostname to use. When not specified
the hostname of the host will be used prepended with 'id.'.template:[Optional] The template to use. When not specified,
the default template will be used.
dhcpd.conf
The dhcpd.conf will always take precedence over the umvs_config.xml,
in other words, all changes made to dhcpd.conf will be reflected in
umvs_conf.xml and be applied to the UMLs at the next start up.
Entries in umvs_conf.xml that can be affected by making changes in
dhcpd.conf are:
Entries in umvs_spec.xml that can be affected are:
The following is an example of a host entry that will be written
to the dhcpd.conf file or printed out to stdout when a new UML is
added:
host william {
hardware ethernet 00:02:44:30:2C:C3;
fixed-address 192.168.1.20;
option host-name "william.miles.dk";
}
Note: Entries in dhcpd.conf will be read and added, but not
modified/removed by umvs, that will be included in the next
version.
|
|
Network Topologies:
|
dia1
Each UML is connected to a uml_switch daemon, where the uml_switch
daemon and the hosts' ethernet device are connected to a virtual bridge.
|
dia2
The UMLs, using a tap device for each UML, are connected to a virtual bridge.
|
dia3
The UMLs, using a tap device for each UML, and the hosts' ethernet
device are connected to a virtual bridge.
|
|
|
Example:
|
|
|
|
Configuration file:
|
umvs_template.xml
|
|
Descritption:
|
The templating system makes it possible to use different kernels, filesystems and kernel switches
for different UMLs.
XML nodes and attributes
/umvs-template/kernel: The path to the uml kernel to use.
/umvs-template/root-fs: The uml filesystem to use.
/umvs-template/devfs: (true/false) Should devfs be used.
/umvs-template/swapfs: The size of the swap file to create, if empty then
no swap will be used.
The following descriptions of the kernel switches have been borrowed from the
user-mode
linux home page.
/umvs-template/cons/con: con=channel attaches one or more UML consoles to
the named channel. The format of the channel is described at
http://user-mode-linux.sourceforge.net/input.html.
con needs to be written in the following format:
con=option
con0=fd:0,fd:1
/umvs-template/debug: (true/false/go/parent) Starts up the kernel under the control of gdb.
See the kernel debugging tutorial (http://user-mode-linux.sourceforge.net/debugging.html)
and the debugging session (http://user-mode-linux.sourceforge.net/debug-session.html)
pages for more information. Another form of this switch is debug=go which is
the same as debug except that the kernel runs instead of stopping at the
beginning of start_kernel.
If you're using ddd to debug UML, you will want to specify debug=parent as
well as gdb-pid (see below).
This switch is specific to
tt(http://user-mode-linux.sourceforge.net/skas.html) mode and has no effect
in skas mode.
/umvs-template/debug-trace: (true/false) Causes the tracing thread to pause until it is attached by a debugger and
continued. This is mostly for debugging crashes early during boot, and should
be pretty much obsoleted by the debug switch.
This switch is specific to
tt(http://user-mode-linux.sourceforge.net/skas.html) mode and has no effect
in skas mode.
/umvs-template/dsp: dsp=host dsp tells the UML sound driver what the filename of the host dsp is
so that it can relay to it. The default is "/dev/sound/dsp".
/umvs-template/fake-hd: (true/false) Causes the ubd device to put its partition information in /proc/partitions
under the device name "hd" rather than "ubd". Again, this is to fake out
installation procedures which are overly picky in their sanity-checking.
/umvs-template/fake-ide: (true/false) fake_ide causes the ubd driver to install realistic-looking entries into
/proc/ide. This is useful for convincing some distribution installation
procedures to run inside UML.
/umvs-template/gbd-pid: gdb-pid=pid , when used with debug, specifies the pid of an already running
debugger that UML should attach to. This can be used to debug UML with a gdb
wrapper such as emacs or ddd, as well as with debuggers other than gdb. See
the debugging page(http://user-mode-linux.sourceforge.net/debugging.html) for
more information.
This switch is specific to tt(http://user-mode-linux.sourceforge.net/skas.html)
mode and has no effect in skas mode.
/umvs-template/honeypot: (true/false) honeypot causes UML to rearrange its address space in order to put process
stacks in the same location as on the host. This allows stack smash exploits
to work against UML just as they do against the host. This option enables
jail, since it is most unlikely that a honeypot UML should run without it
enabled.
This switch is specific to tt(http://user-mode-linux.sourceforge.net/skas.html)
mode and has no effect in skas mode. Honeypots should be run in skas mode anyway,
since they will perform far better, and the security model is much simpler,
making it less likely that there will be exploitable bugs that will allow an
attacker to break out.
/umvs-template/initrd: initrd=image sets the filename of the initrd image that UML will boot from.
/umvs-template/iomem: iomem=name,file makes file available to be mapped by a driver inside UML.
See http://user-mode-linux.sourceforge.net/iomem.html for more information.
/umvs-template/jail: (true/false) jail enables protection of UML kernel memory from UML processes. This is
disabled by default for performance reasons. Without it, it is fairly simple
to break out of UML by changing the right pieces of UML kernel data.
This switch is specific to tt(http://user-mode-linux.sourceforge.net/skas.html)
mode and has no effect in skas mode. skas mode doesn't have the same problems
with processes being able to break out to the host, so this switch isn't
needed. Effectively, 'jail' mode is always enabled in skas mode.
/umvs-template/mconsole: mconsole=notify:socket asks the mconsole driver to send the name of its socket
to the Unix socket named by this switch. This is intended for the use of
scripts which want to know when they can start using the mconsole and what
socket they should send commands to.
/umvs-template/mem: mem=size controls how much "physical" memory the kernel allocates for the
system. The size is specified as a number followed by one of 'k', 'K", 'm',
'M", which have the obvious meanings. This is not related to the amount of
memory in the physical machine. It can be more, and the excess, if it's ever
used, will just be swapped out.
In its default configuration, UML has a maximum physical memory size of just
under 512M. If you specify more than that, it will be shrunk, and a warning
printed out. If your UML is configured with highmem support (CONFIG_HIGHMEM)
enabled, then any physical memory beyond what can be directly mapped in to
the kernel address space will become highmem. In this case, the current limit
on UML physical memory is 4G.
Something to note if you have a small /tmp is that UML creates a file in /tmp
which is the same size as the memory you specified. It is not visible because
UML unlinks it after creating it. This can cause /tmp to mysteriously become
full. UML respects the TMP, TEMP, and TMPDIR environment variables, so you can
avoid this problem by specifying an alternate temp directory.
Something else to note is that UML is noticably faster with a tmpfs /tmp than
with a disk-based /tmp such as ext2 or ext3.
/umvs-template/mixer: mixer=host mixer tells the UML sound driver what the filename of the host
mixer is so that it can relay to it. The default is "/dev/sound/mixer".
/umvs-template/mode-tt: (true/false) mode=tt forces UML to run in tt mode even when skas support is built in to UML
and the host. Using this switch without both tt and skas modes built in to UML
will have no effect aside from producing a warning during boot.
See http://user-mode-linux.sourceforge.net/skas.html for more information.
/umvs-template/ncpus: ncpus=number tells an SMP kernel how many virtual processors to start. This
switch will only take effect if CONFIG_UML_SMP is enabled in the UML
configuration.
/umvs-template/ssls/ssl: ssl=channel attaches one or more UML serial lines to the named channel. The
format of the channel is described at
http://user-mode-linux.sourceforge.net/input.html.
/umvs-template/root: root=root device is actually used by the generic kernel in exactly the same
way as in any other kernel. If you configure a number of block devices and
want to boot off something other than ubd0, you would use something like:
root=/dev/ubd5
/umvs-template/tty-log-dir: tty_log_dir=directory changes the directory to which UML writes tty logging
files. This requires that tty logging be configured into UML.
See http://user-mode-linux.sourceforge.net/tty_logging.html for more details.
/umvs-template/tty-log-fd: tty_log_fd=file descriptor causes tty logging records to be written to the
file descriptor specified. This descriptor must be opened before UML is run
and passed in to UML.
See http://user-mode-linux.sourceforge.net/tty_logging.html for more details.
/umvs-template/ubd-number: ubd=number causes the ubd device to take over a different major number than
the one assigned to it. This is useful for making it appear to be an "hd"
device.
/umvs-template/ubds/ubd: ubdn=filename is used to associate a device with a file in the underlying
filesystem. Usually, there is a filesystem in the file, but that's not
required. Swap devices containing swap files can be specified like this.
Also, a file which doesn't contain a filesystem can have its contents read in
the virtual machine by running dd on the device. n must be in the range 0 to
7. Appending an 'r' to the number will cause that device to be mounted
read-only. Appending an 's' will cause that device to do all IO to the host
synchronously. If both 'r' and 's' are specified, it must be as 'rs'.
Inside UML, if you are not using devfs, the devices are accessible with minor
numbers 0, 16, ..., with the other minor numbers being used for partitions.
So, the device that is ubd1 on the UML command line becomes /dev/ubd16 inside
UML.
Note: "ubd0=/umvs/umvs_www/*.cow, root_fs" is allready specified and does not need to
be entered here.
/umvs-template/xterm: xterm=terminal emulator,title switch,exec switch allows you to specify an
alternate terminal emulator for UML to use for the debugger, consoles, and
serial lines. terminal emulator is the emulator itself, title switch is the
switch it uses to set its title, and exec switch is the switch it uses to
specify a command line to exec. The two switches need to have the same syntax
and semantics of xterm's "-T" and "-e". The default value is
"xterm=xterm,-T,-e". To use gnome-terminal, you would specify
"xterm=gnome-terminal,-t,-x". If any fields are left blank, the default
values will be used. So, to use "myxterm", which has the same switches as
xterm, "xterm=myxterm" will suffice.
|
|
Example:
|
|
|
|
Configuration file:
|
umvs_spec.xml
|
|
Descritption:
|
The spec file contains UML specifications and is ideal to be used
by third party application(eg. webmin) to get hold of the
specifications of the different UMLs. The specfile also adds room
for expansion later on when it is needed.
Everytime umvs is run, the umvs_spec.xml file will be regenerated,
and the dhcpd.conf file will be updated. The dhcpd.conf file will also be
reread everytime umvs is run to make shure the updates gets processed
properly.
The only specification we need to retreive from the specfile at the
moment, is to see if the uml is enabled or disabled(The default is
enabled).
XML nodes and attributes
/umvs-specs/umvs-spec/
id: From the existing umvs_config object.templ: From the existing umvs_config object.ip: From parsing the dhcpd.conf.hostname: From the existing umvs_config object or ID + host's hostname.enabled: From the specfile, default is true.mac: From parsing the dhcpd.conf or generated by umvs.tap: umvs generated - the name of the tap device if applied, otherwise null.screen: umvs generated - the name of the screen session.
|
|
Example:
|
|
|
|
|
|
|
