util-vserver:Vhashify - Revision history

Tallungulate: Update location of style file.

2011-10-29T11:39:35Z

Update location of style file.

Glenn: catspec

2011-10-21T21:17:46Z

catspec

Glenn: +space

2011-10-21T21:10:45Z

+space

Glenn: more

2011-10-21T21:10:32Z

Glenn: +bold

2011-10-21T21:06:05Z

+bold

Glenn: +cat

2011-10-21T21:05:03Z

+cat

217.196.45.116: /* Mini FAQ */ exclude ~ description

2011-03-18T14:23:32Z

‎Mini FAQ: exclude ~ description

Gebura: /* Mini FAQ */

2009-03-31T22:37:14Z

‎Mini FAQ

Gebura: /* Mini FAQ */

2009-03-31T22:32:19Z

‎Mini FAQ

Gebura: /* Mini FAQ */

2009-03-31T22:32:01Z

‎Mini FAQ

@@ Line 11: / Line 11: @@
   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.
+* 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.

← Older revision		Revision as of 21:17, 21 October 2011
Line 78:		Line 78:
	* [[Frequently_Asked_Questions#What_is_unification_.28vunify.29.3F]]		* [[Frequently_Asked_Questions#What_is_unification_.28vunify.29.3F]]

−	[[Category:~~Documentation~~]]	+	[[Category:Configuration]]

@@ Line 3: / Line 3: @@
 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).
+* '''"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.

@@ Line 3: / Line 3: @@
 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).
+* '''"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.

@@ Line 3: / Line 3: @@
 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).
+* '''"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.
+* '''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:

← Older revision		Revision as of 21:05, 21 October 2011
Line 77:		Line 77:
	* [[util-vserver:Documentation]] or maybe rather the [http://www.nongnu.org/util-vserver/doc/conf/configuration.html "Flower Page"]		* [[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]]		* [[Frequently_Asked_Questions#What_is_unification_.28vunify.29.3F]]
		+
		+	[[Category:Documentation]]

@@ Line 56: / Line 56: @@
 * - Means exclude : Default operation (same as no modifier)
 * + Means include : Allow you to include file/folder in a excluded folder
-* ~ Means skip : ??
+* ~ Means exclude : however, vcopy also looks at this exclude file and with ~ the file/folder is copied instead of hardlinked.

@@ Line 61: / Line 61: @@
 Q: I have got the message "Duplicate hash-dir entry 'root' found"
-A:
 * looks like you already had the symlink setup.
 <code>ls -l /etc/vservers/.defaults/apps/vunify/hash</code>

@@ Line 69: / Line 69: @@
 <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 -> /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