Editing
Util-vserver:Vhashify
From Linix VServer
Jump to navigation
Jump to search
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
== All about vunify / vhashify == Some collected wisdom about the vunify/vhashify functionality: * '''"unification"''' ('''vunify''') 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 <tt>/etc/vservers/<vserver-name>/apps/init/style</tt> for finding out which distribution a guest is running (can this be a problem?) -> open questions to be looked at. * To prevent vhashify from getting a list of config files from the packagemgt system, see the <tt>pkgmgmt-ignore</tt> and <tt>pkgmgmt-force</tt> options in <tt>/etc/vservers/.defaults/apps/vunify</tt> or per-vserver configuration directory. If you disable this, you might want to set a manual exclude list, when the default <tt>/usr/lib/util-vserver/defaults/vunify-exclude</tt> is not sufficient. * See <tt>/etc/vservers/<vserver-name>/apps/vunify/exclude</tt> on the flower page for a meaning of the <tt>exclude</tt> file. <!-- I think this is no longer relevant (* 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.)). From looking at the code, vpkg is always run when pkgmgmt is enabled for --> === 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.) === Cleanup === Remove non referenced files find /vservers/.hash -type f -links 1 -exec rm -v '{}' ';' === Mini FAQ === 1Q: <serek> so after cloning, i need to dist-upgrade each vserver separately but finally they will use the same files, right? 1A: <Bertl> you can upgrade all at once or separately, whenever you run vhashify on them, identical data will be linked together 2Q: <serek> may vhashify two existing hosts as well, right? 2A: <Bertl> yep, anytime 3Q: <fluor-> < Bertl> you can upgrade all at once or separately <- what would the "all at once" method be? 3A: <Bertl> depends on the package management, for most common management mechanisms, there is vapt, vyum, and vrpm Note that "all at once" doesn't mean "simultaneously", just "with a single command". When you mass upgrade your vservers, their identical files won't be hardlinked together until you run vserver hashify again on each of them. This means you'll need a lot more disk space until you vhashify. And don't forget to remove hashed files that no longer have other hard links. 4Q: What does the syntax -/+/~ refer to in the vunify-exclude file ? 4A: * - Means exclude : Default operation (same as no modifier) * + Means include : Allow you to include file/folder in a excluded folder * ~ Means exclude : however, vcopy also looks at this exclude file and with ~ the file/folder is copied instead of hardlinked. 5Q: I have got the message "Duplicate hash-dir entry 'root' found" 5A: * looks like you already had the symlink setup. <code>ls -l /etc/vservers/.defaults/apps/vunify/hash</code> <code>[...]</code> <code>lrwxrwxrwx 1 root root 23 mar 1 00:19 00 -> /var/lib/vservers/.hash </code> <code>lrwxrwxrwx 1 root root 15 avr 1 00:00 root -> /var/lib/vservers/.hash </code> * Remove the link /etc/vservers/.defaults/apps/vunify/hash/root === 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]] [[Category:Configuration]]
Summary:
Please note that all contributions to Linix VServer may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see
Linix VServer:Copyrights
for details).
Do not submit copyrighted work without permission!
Cancel
Editing help
(opens in new window)
Navigation menu
Page actions
Page
Discussion
Read
Edit
History
Page actions
Page
Discussion
More
Tools
Personal tools
Not logged in
Talk
Contributions
Create account
Log in
About
Overview
Paper
News
Developers
Donations
Search
Getting Started
Downloads
FAQs
Documentation
Support
Participate
How to participate
Report a Bug
Communicate
Teams/Projects
Hall of Fame
Resources
Archives
Recent Wiki Changes
Pastebin
Related Projects
VServer Hosting
Happy VServer Users
Tools
What links here
Related changes
Special pages
Page information