Linux-VServer - User contributions [en]

Debugging

2008-02-07T21:16:34Z

Pflanze: add qemu command line

In the case that the core developers cannot reproduce a problem you're running into, it's recommended to use Qemu and known filesystem and kernel images and go from there, then providing the necessary changes (probably a tar file or maybe patch of the changed files).

NOTE: I ([[User:pflanze]]) couldn't get through all of this yet, this is just a start, this page needs to be completed.

* install qemu (preferably >= 9.0 since that supposedly has (even) easier networking) on any machine (no need to run vserver). You don't need the qemu acceleration kernel module.
* get a kernel image (needs something (what?) configured to be able to run under Qemu?), for example, http://vserver.13thfloor.at/Stuff/QEMU/bzImage-2.6.22.16-vs2.2.0.6
* get a root image from http://vserver.13thfloor.at/Stuff/QEMU/?C=M&O=D
<Bertl> the 32M_public2 img should suffice
* since that image has outdated tools, get http://vserver.13thfloor.at/Stuff/QEMU/util-vserver-0.30.214_bin.tar.bz2 (to be unpacked under / in the root image)
* start qemu like this:
qemu -nographic -m 64 -hda TEST_32M_public2.img -kernel bzImage-2.6.22.16-vs2.2.0.6 -append "rw root=/dev/hda1 init=/bin/bash"
* to get the above tar ball into the running Qemu, get networking to work. How to do that is to be done in another session.

User:Pflanze

2008-02-07T21:11:31Z

Pflanze: one-line user page

Seems there is no default user page.

You can reach me at christian at pflanze, mine, nu (s/, /./ and s/at/@/).

How to participate

2008-02-07T21:08:09Z

Pflanze: Add secion and link about Debuggin (with Qemu)

[[image:Opensource-110x95.png|left]] The basic idea behind open source is very simple: When programmers can read, redistribute, and modify the source code for a piece of software, the software evolves. People improve it, people adapt it, people fix bugs. And this can happen at a speed that, if one is used to the slow pace of conventional software development, seems astonishing.

We in the open source community have learned that this rapid evolutionary process produces better software than the traditional closed model, in which only a very few programmers can see the source and everybody else must blindly use an opaque block of bits.

Whether you're an experienced Linux developer or an end user just getting started with Linux-VServer, there are many ways for you to participate in the Linux-VServer project. Join the mailing list to get help or help others, find and report bugs, review the documentation, send your wish list for new features, create and submit patches, or find other creative ways to contribute.

== Improve the Wiki ==

As long as you edit anything on the wiki you are de facto member of the [[Wiki Team]].

This page is built with MediaWiki. The concept of a Wiki is that anybody may add and modify content. Please see the [[Wiki Team]] page if you want to contribute to our Wiki. Refer to the [http://meta.wikimedia.org/wiki/Help:Contents Wikimedia Manual] for instructions how to create and format wiki pages. Please make sure that you follow overall look and feel of the wiki.

We added a [[Sandbox]] and we would kindly ask all that wannabe hackers use that page for the very challenging task of wiki hacking (TIA:).

== Help other users ==

There are many ways to help other Linux-VServer users. Take a look at [[Communicate]] to learn about all our communication methods.

== Test new releases ==

You can help improve Linux-VServer by finding and reporting bugs. Like many other projects we don't maintain Bugzilla or similar but instead handle bugs on the mailing list. If you have never written a bug report, please refer to [[Report a Bug]] to learn what kinds of information make the report most useful.

== Help narrow down problems ==

If there's a problem the developers cannot reproduce, the [[Debugging]] page shows how to proceed to help them get to that point.

== Suggest new features ==

If you feel like a feature is missing feel free to contact the Linux-VServer community with your wishlist. Take a look at [[Communicate]] to learn about all our communication methods.

== Review or write new documentation ==

Visit the [[Documentation]] page to contribute or read articles and manuals. If you've got instructions, solutions to common problems, neat tips and tricks, or just a good way to explain something, we'd love to hear from you.

== Send patches ==

The most obvious way to participate in the development of Linux-VServer is to post a patch as a suggested solution to an existing bug on the mailing list.

Debugging

2008-02-07T21:06:38Z

Pflanze: Unfinished start

In the case that the core developers cannot reproduce a problem you're running into, it's recommended to use Qemu and known filesystem and kernel images and go from there, then providing the necessary changes (probably a tar file or maybe patch of the changed files).

NOTE: I ([[User:pflanze]]) couldn't get through all of this yet, this is just a start, this page needs to be completed.

* install qemu (preferably >= 9.0 since that supposedly has (even) easier networking) on any machine (no need to run vserver). You don't need the qemu acceleration kernel module.
* get a kernel image (needs something (what?) configured to be able to run under Qemu?), for example, http://vserver.13thfloor.at/Stuff/QEMU/bzImage-2.6.22.16-vs2.2.0.6
* get a root image from http://vserver.13thfloor.at/Stuff/QEMU/?C=M&O=D
<Bertl> the 32M_public2 img should suffice
* since that image has outdated tools, get http://vserver.13thfloor.at/Stuff/QEMU/util-vserver-0.30.214_bin.tar.bz2 (to be unpacked under / in the root image)
* to get the above into the running Qemu, get networking to work. How to do that is to be done in another session.

util-vserver:Vhashify

2007-02-19T22:42:23Z

Pflanze: exclude lists don't prevent from vserver exec, and other corrections

== All about vunify / vhashify ==

Some collected wisdom about the vunify/vhashify functionality:

* "unification" is the process of replacing files with hardlinks to identical files in other vservers (or, in the case of vhashify, more precisely to a common base); for security, the files are then supplied with immutable-but-unlinkable flags (a vserver speciality), and recently COW link capability has been added to vserver (2.2+), which means that when such a file is being modified, the hardlink is automatically dissolved and the contents copied (CONFIG_VSERVER_COWBL).

* vhashify is the successor to vunify; vunify only looks at files at identical relative paths and links them if they are identical; vhashify builds hash values over the contents of ''all'' (non-excluded) files and links them into a common base directory, or unifies them with pre-existing links there. So running hashification on multiple vservers will effectively hard link their identical files.

* You don't call the vhashify tool directly (which lives in lib/util-vserver/), but let the "vserver" multipurpose script do the work:

vserver <vserver-name> hashify

* The guest needs to be running for the above because vhashify may try to figure out what files not to hashify by calling the package manager of the guest via <tt>vserver exec</tt>; the reason for this is that it tries not to unify config files because they couldn't be written to afterwards unless COW links are supported (which is a recent addition), which may be a hassle (unlike with program/library files which are not overwritten but replaced on upgrades). The details of how the list of config files is retrieved can be found in <tt>scripts/vpkg</tt> (<tt>lib/util-vserver/vpkg</tt> after installation), which is called by the vhashify program (through MatchList_initManually). Currently this means redhat|mandrake and debian are supported. It is looking at a XXX/style file (what's XXX?) for finding out which distribution a guest is running (can this be a problem?) -> open questions to be looked at.

(* If one configures exclude lists, vhashify is supposed ''not'' to use package management for getting the config file list ''-> actually it turns out this is not the case, vserver exec is even being called with an exclude file present''. (One can check whether vpkg is being run by adding an <tt>echo "$0 $@ called.." >&2</tt> statement at the top of that script. Note the redirection to stderr.))

=== Backups ===

Be careful to restore the link flags when making or restoring from backups, or vservers won't be safely parted anymore. Do either of the following:

* use tools which backup and restore the link flags ("dump" and "restore" might work, the writer of these lines has not tested them)

* back up the directory containing the hashes, too (<tt>/vservers/.hash</tt> when following the suggested configuration directives); for restoring from the backup, also restore the .hash directory, then run setattr over all files contained therein; this should work (not yet tested!):

find /vservers/.hash -type f -print0|xargs -0 setattr --iunlink --

* (back up and) restore each vserver individually, so no hardlinks to other vservers are created. Then run hashify. (Be aware that you need more space until hashify has run, so restoring from a backup onto a partition of equal size might not work.)

=== See also ===

* [[util-vserver:Documentation]] or maybe rather the [http://www.nongnu.org/util-vserver/doc/conf/configuration.html "Flower Page"]
* [[Frequently_Asked_Questions#What_is_unification_.28vunify.29.3F]]

util-vserver:Fstab

2007-02-10T17:31:22Z

Pflanze: Add link to logging page, note about fsck'ing on the host, hint about discussion

== About /etc/vservers/<name>/fstab ==

The file has the format as described by man 5 fstab *except*:

* the fifth and sixth fields (fs_freq and fs_passno) are ignored. If you need fsck to run on a device before mounting it, you have to do so by a separate means, e.g. by running it from <tt>scripts/initialize</tt> (*not* prepre-start as fstab entries are already mounted at the time prepre-start is being run). But be sure that either fsck's input/outputs are tied to some tty (by setting <tt>/etc/vservers/guest/apps/init/tty</tt> or <tt>/etc/vservers/.defaults/apps/init/tty</tt>), or you supply one of the -y or -n options (man e2fsck) so that it can run non-interactively. But a better idea might be to run fsck from a startup script during the *host* boot process.

<small>There has been some discussion between <tt>Bertl</tt>, <tt>daniel_hozac</tt> and <tt>pflanze</tt> on #vserver on 2007/02/10 about adding support for the "fs_passno" ("fsck") field, but the benefit is not entirely clear.</small>

=== See also ===

* [[util-vserver:Logging]] on how stdin/out/err are being setup when booting vservers

util-vserver:Logging

2007-02-10T17:19:45Z

Pflanze: the intermediate result of my investigations

== Accessing vserver startup output ==

Where is the startup output of vservers going?

==== (A) when using vserver init styles others than "plain": ====

(for example without any /etc/vservers/<name>/apps/init/style setting)

* "vserver <name> <command>" by itself will not do any redirection, thus print and read to/from the current terminal/whatever.

* <tt>/etc/init.d/vservers</tt> will typically run <tt>lib/util-vserver/vserver-wrapper</tt> which will redirect stdin/out/err from/to the value at <tt>/etc/vservers/guest/apps/init/tty</tt>, <tt>/etc/vservers/.defaults/apps/init/tty</tt> or if neither is set, /dev/null. NOTE: just linking to a normal file will log to that file, but currently also open stdin from that file, which may have bad consequences if some programs actually reads from stdin (it may even create an endless loop appending and reading from the file). (<tt>pflanze</tt> has started looking into changing this (opening stdin from /dev/null if the link is pointing to a file) but has run out of energy right now.)

You have to keep this in mind: if for some reason a vserver does not start upon host reboot, but starts without problems with "vserver <name> start", that could be because a program in your vserver's scripts/* directory depends on having access to a terminal. This is (like it is with every system service) one of the differences between starting vservers from host's init process or from a login shell (others being resource limits and environment variables).

==== (B) when using vserver init style "plain" ====

(what is different to (A)? to be investigated/documented)

util-vserver:Logging

2007-02-10T17:06:50Z

Pflanze: some reformatting and more detail

== Accessing vserver startup output ==

Where is the startup output of vservers going?

(A) when using init styles others than "plain" (for example without any style setting):

* "vserver <name> <command>" by itself will not do any redirection, thus print and read to/from the current terminal/whatever.

* <tt>/etc/init.d/vservers</tt> will typically run <tt>lib/util-vserver/vserver-wrapper</tt> which will redirect stdin/out/err from/to the value at <tt>/etc/vservers/guest/apps/init/tty</tt>, <tt>/etc/vservers/.defaults/apps/init/tty</tt> or if neither is set, /dev/null. NOTE: just linking to a normal file will log to that file, but currently also open stdin from that file, which may have bad consequences if some programs actually reads from stdin (it may even create an endless loop appending and reading from the file).

You have to keep this in mind: if for some reason a vserver does not start upon host reboot, but starts without problems with "vserver <name> start", that could be because a program in your vserver's scripts/* directory depends on having access to a terminal. This is (like it is with every system service) one of the differences between starting vservers from host's init process or from a login shell (others being resource limits and environment variables).

util-vserver:Logging

2007-02-10T16:12:31Z

Pflanze:

== Accessing vserver startup output ==

Where is the startup output of vservers going?

* when using init styles others than "plain" (for example without any style setting):

** "vserver <name> start" will not do any redirection, thus print to the current output.

** "/etc/init.d/vservers start" will typically run <tt>lib/util-vserver/vserver-wrapper</tt> which will redirect stdin/out/err from/to the value at /etc/vservers/guest/apps/init/tty, /etc/vservers/.defaults/apps/init/tty or if neither is set, /dev/null. NOTE: just linking to a normal file will log to that file, but currently also open stdin from that file, which may have bad consequences if some programs actually reads from stdin (it may even create an endless loop appending and reading from the file).

util-vserver:Fstab

2007-02-10T13:12:13Z

Pflanze:

util-vserver:Vhashify

2007-02-08T17:58:39Z

Pflanze: /* Backups */

== All about vunify / vhashify ==

Some collected wisdom about the vunify/vhashify functionality:

* "unification" is the process of replacing files with hardlinks to identical files in other vservers (or, in the case of vhashify, more precisely to a common base); for security, the files are then supplied with immutable-but-unlinkable flags (a vserver speciality), and recently COW link capability has been added to vserver (2.2+), which means that when such a file is being modified, the hardlink is automatically dissolved and the contents copied (CONFIG_VSERVER_COWBL).

* vhashify is the successor to vunify; vunify only looks at files at identical relative paths and links them if they are identical; vhashify builds hash values over the contents of ''all'' (non-excluded) files and links them into a common base directory, or unifies them with pre-existing links there. So running hashification on multiple vservers will effectively hard link their identical files.

* You don't call the vhashify tool directly (which lives in lib/util-vserver/), but let the "vserver" multipurpose script do the work:

vserver <vserver-name> hashify

* The guest needs to be running for the above because vhashify may try to figure out what files not to hashify by calling the package manager of the guest via <tt>vserver enter</tt>; the reason for this is that it tries not to unify config files because they couldn't be written to afterwards unless COW links are supported (which is a recent addition), which may be a hassle unlike with program/library files which are replaced on upgrades. The details of how the list of config files is retrieved can be found in <tt>scripts/vpkg</tt> (<tt>lib/util-vserver/vpkg</tt> after installation), which is called by the vhashify program (through MatchList_initManually). Currently this means redhat|mandrake and debian are supported. It is looking at a XXX/style file (what's XXX?) for finding out which distribution a guest is running (can this be a problem?) -> open questions to be looked at.

* If one configures exclude lists, vhashify is supposed ''not'' to use package management for getting the config file list (daniel_hozac says: "that's the idea, i haven't verified it though"). (One can check whether vpkg is being run by adding an <tt>echo "$0 $@ called.." >&2</tt> statement at the top of that script. Note the redirection to stderr.)

=== Backups ===

Be careful to restore the link flags when making or restoring from backups, or vservers won't be safely parted anymore. Do either of the following:

* use tools which backup and restore the link flags ("dump" and "restore" might work, the writer of these lines has not tested them)

* back up the directory containing the hashes, too (<tt>/vservers/.hash</tt> when following the suggested configuration directives); for restoring from the backup, also restore the .hash directory, then run setattr over all files contained therein; this should work (not yet tested!):

find /vservers/.hash -type f -print0|xargs -0 setattr --iunlink --

* (back up and) restore each vserver individually, so no hardlinks to other vservers are created. Then run hashify. (Be aware that you need more space until hashify has run, so restoring from a backup onto a partition of equal size might not work.)

=== See also ===

* [[util-vserver:Documentation]]
* [[Frequently_Asked_Questions#What_is_unification_.28vunify.29.3F]]

util-vserver:Vhashify

2007-02-08T17:53:18Z

Pflanze: How to handle backups

== All about vunify / vhashify ==

Some collected wisdom about the vunify/vhashify functionality:

* "unification" is the process of replacing files with hardlinks to identical files in other vservers (or, in the case of vhashify, more precisely to a common base); for security, the files are then supplied with immutable-but-unlinkable flags (a vserver speciality), and recently COW link capability has been added to vserver (2.2+), which means that when such a file is being modified, the hardlink is automatically dissolved and the contents copied (CONFIG_VSERVER_COWBL).

* vhashify is the successor to vunify; vunify only looks at files at identical relative paths and links them if they are identical; vhashify builds hash values over the contents of ''all'' (non-excluded) files and links them into a common base directory, or unifies them with pre-existing links there. So running hashification on multiple vservers will effectively hard link their identical files.

* You don't call the vhashify tool directly (which lives in lib/util-vserver/), but let the "vserver" multipurpose script do the work:

vserver <vserver-name> hashify

* The guest needs to be running for the above because vhashify may try to figure out what files not to hashify by calling the package manager of the guest via <tt>vserver enter</tt>; the reason for this is that it tries not to unify config files because they couldn't be written to afterwards unless COW links are supported (which is a recent addition), which may be a hassle unlike with program/library files which are replaced on upgrades. The details of how the list of config files is retrieved can be found in <tt>scripts/vpkg</tt> (<tt>lib/util-vserver/vpkg</tt> after installation), which is called by the vhashify program (through MatchList_initManually). Currently this means redhat|mandrake and debian are supported. It is looking at a XXX/style file (what's XXX?) for finding out which distribution a guest is running (can this be a problem?) -> open questions to be looked at.

* If one configures exclude lists, vhashify is supposed ''not'' to use package management for getting the config file list (daniel_hozac says: "that's the idea, i haven't verified it though"). (One can check whether vpkg is being run by adding an <tt>echo "$0 $@ called.." >&2</tt> statement at the top of that script. Note the redirection to stderr.)

=== Backups ===

Be careful to restore the link flags when making or restoring from backups, or vservers won't be safely parted anymore. Use either of the following:

* use tools which backup and restore the link flags ("dump" and "restore" might work, the writer of these lines has not tested them)

* back up the directory containing the hashes, too (<tt>/vservers/.hash</tt> when following the suggested configuration directives); for restoring from the backup, also restore the .hash directory, then run setattr over all files contained therein; this should work (not yet tested!):

find /vservers/.hash -type f -print0|xargs -0 setattr --iunlink --

* (back up and) restore each vserver individually, so no hardlinks to other vservers are created. Then run hashify. (Be aware that you need more space until hashify has run, so restoring from a backup onto a partition of equal size might not work.)

See also:

* [[util-vserver:Documentation]]
* [[Frequently_Asked_Questions#What_is_unification_.28vunify.29.3F]]

Help:Editing

2007-02-08T17:51:25Z

Pflanze:

See [http://www.mediawiki.org/wiki/Help:Contents Mediawiki Help pages]

util-vserver:Vhashify

2007-02-08T16:34:54Z

Pflanze: I've actually been misleading myself by printing to stdout

util-vserver:Vhashify

2007-02-08T15:53:03Z

Pflanze: I never see vpkg being run

== All about vunify / vhashify ==

Some collected wisdom about the vunify/vhashify functionality:

* "unification" is the process of replacing files with hardlinks to identical files in other vservers (or, in the case of vhashify, more precisely to a common base); for security, the files are then supplied with immutable-but-unlinkable flags (a vserver speciality), and recently COW link capability has been added to vserver (2.2+), which means that when such a file is being modified, the hardlink is automatically dissolved and the contents copied (CONFIG_VSERVER_COWBL).

* vhashify is the successor to vunify; vunify only looks at files at identical relative paths and links them if they are identical; vhashify builds hash values over the contents of ''all'' (non-excluded) files and links them into a common base directory, or unifies them with pre-existing links there. So running hashification on multiple vservers will effectively hard link their identical files.

* You don't call the vhashify tool directly (which lives in lib/util-vserver/), but let the "vserver" multipurpose script do the work:

vserver <vserver-name> hashify

* The guest needs to be running for the above because vhashify may try to figure out what files not to hashify by calling the package manager of the guest via <tt>vserver enter</tt>; the reason for this is that it tries not to unify config files because they couldn't be written to afterwards unless COW links are supported (which is a recent addition), which may be a hassle unlike with program/library files which are replaced on upgrades. The details of how the list of config files is retrieved can be found in <tt>scripts/vpkg</tt> (<tt>lib/util-vserver/vpkg</tt> after installation), which is called by the vhashify program (through MatchList_initManually). Currently this means redhat|mandrake and debian are supported. It is looking at a XXX/style file (what's XXX?) for finding out which distribution a guest is running (can this be a problem?) -> open questions to be looked at.

* If one configures exclude lists, vhashify is supposed ''not'' to use package management for getting the config file list (daniel_hozac says: "that's the idea, i haven't verified it though"). (Actually, in pflanze's experience with 0.30.212 (and Debian host/guests), vpkg is not even being run without exclude lists, as can be verified by adding an echo statement at the top of that script, it is not shown when running <tt>vserver <name> hashify</tt>)

See also:

* [[util-vserver:Documentation]]
* [[Frequently_Asked_Questions#What_is_unification_.28vunify.29.3F]]

util-vserver:Vhashify

2007-02-06T00:59:19Z

Pflanze:

Linux-VServer - User contributions [en]

Debugging

User:Pflanze

How to participate

Debugging

Archives

util-vserver:Vhashify

util-vserver:Fstab

util-vserver:Logging

util-vserver:Logging

util-vserver:Logging

util-vserver:Fstab

util-vserver:Vhashify

util-vserver:Vhashify

Help:Editing

util-vserver:Vhashify

util-vserver:Vhashify

util-vserver:Vhashify