Difference between revisions of "util-vserver:Vhashify"
From Linux-VServer
(I never see vpkg being run) |
(I've actually been misleading myself by printing to stdout) |
||
| Line 13: | Line 13: | ||
* 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. | * 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"). ( | + | * 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.) |
Revision as of 17:34, 8 February 2007
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 vserver enter; 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 scripts/vpkg (lib/util-vserver/vpkg 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 echo "$0 $@ called.." >&2 statement at the top of that script. Note the redirection to stderr.)
See also:
