Jeff Hanson:
> The aufs mount point. That is what the users will be working with.
Do you mean only the directory?
If so, aufs does copyup the dir only, and I don't think it fills up the
rw branch.
> "Some" is the problem. I can't predict which files out of the ro
:::
Right. "How many files will be copied-up?" will be a problem.
But I don't think the problem will be solved even if aufs supports
uid-mapping (or faking).
> Using Diablo II (http://en.wikipedia.org/wiki/Diablo_II) as an example
:::
Ok, you don't want to spend 11GB, and you could reduce to 2.3GB by
mounting aufs for each user.
> For deployment, I copy ".wine-Diablo_II" to
> "/srv/wine/.wine-Diablo_II" and remove symlinks specific to wineadmin
> which are for special folders like "My Documents". Diablo license
> keys in this copy of the Wine registry are purged. All
> files/directories are owned by wineadmin with file permissions of 644
> (rw-r--r--) and directory permissions of 755 (rwx-r-xr-x).
> Next I need to install a popular mod, Median XL
:::
Ok, you made changes to the original Diablo II files with changing the
dir. While I don't know where the original ~wineadmin/.wine-Diablo_II
went, but I hope users who are playing Diablo II right now can keep
playing.
By the way, if you want, you may be able to provide both of the original
Diablo II and Median XL-ed one by aufs.
- you already have $srv/Diablo_II which contains the original
one. create a new $srv/Diablo_II_Median_XL with keeping $srv/Diablo_II
unchanged.
mkdir $srv/Diablo_II_Median_XL
mount -t aufs -o br:$srv/Diablo_II_Median_XL:$srv/Diablo_II \
none $srv/Diablo_II_Median_XL
(apply Median XL and the changed files are stored in $srv/Diablo_II_Median_XL)
mount -o remount,ro $srv/Diablo_II_Median_XL
(now you have $srv/Diablo_II and $srv/Diablo_II_Median_XL which are to
be shared and provied to users. and $srv/Diablo_II_Median_XL holds
the "diff from the original" only)
- provide users the original.
mount -t aufs -o br:~user/Diablo_II:$srv/Diablo_II none ~user/Diablo_II
- provide users the Median XL-ed one.
mount -t aufs -o br:~user/Diablo_II_Median_XL:$srv/Diablo_II_Median_XL \
none ~user/Diablo_II_Median_XL
Additionally, because you may want to keep the shared files unchanged,
there are options to make them readonly. For example, make an ext2
image.
dd if=/dev/null of=Diablo_II.ext2 bs=... count=...
mkfs -t ext2 Diablo_II.ext2
mount -o loop Diablo_II.ext2 /mnt
cp -pr $srv/Diablo_II /mnt
umount /mnt
losetup -r /dev/loop0 Diablo_II.ext2
mount -o ro /dev/loop0 $srv/Diablo_II
Now you have $srv/Diablo_II dir from a single file Diablo_II.ext2. And
the mount option 'ro' is specified. Also /dev/loop0 is bound as readonly
too (losetup -r). So under $srv/Diablo_II no one can make modification
even if you set all permissions to world-writable.
Of course, you can make any filesystem instead of ext2. You may want to
try isofs, squashfs or something.
> The problem is that none of this actually functions with the current
> aufs. The "/home/administrator/.wine-Diablo_II" directory and files
> are owned by "wineadmin" so the "administrator" account can't modify
> the Wine registry or any files even though it owns
> "/home/administrator/.wine-Diablo_II_rw". The only solution is to
:::
Then I'd suggest you to try the approach like above, world-writable
files and readonly mount for the ro branch.
> Correct although in my example the ro branch is owned by wineadmin.
It doesn't matter.
J. R. Okajima
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
