On Tue, Feb 8, 2011 at 10:34 PM, <sf...@users.sourceforge.net> wrote: > > What did you chown?
The aufs mount point. That is what the users will be working with. They could access the rw branch directly since it is in their home but that is unlikely since it is hidden. > My asummption is > - you have all common files in the ro branch. > (if your "common" files should be run by multiple users at the same > time as Michael S. Zick pointed, then you should not do that) > - users customize some of files, and these files are put in his rw > branch. > - finally the rw branch has only the "difference". > "Some" is the problem. I can't predict which files out of the ro branch they will want to modify. Many Windows applications have their own on-line update utilities for patching so any file can be changed by the user account. With games there are many third-party modifications that can be added and I can't tell which games the users will play or which mods they will add. > > If the difference is so large and the rw branch cannot have all of them > due to its space, then you just need to expand the size of rw branch. > > If you have chwon-ed the common files, then that must be unnecessary. > Using Diablo II (http://en.wikipedia.org/wiki/Diablo_II) as an example of installation for multiple users, this is what I want to do. To function without the CDs a full installation is needed which is about 2.2GB total. With five users that is 11GB for one game. If I use aufs and share one installation then it's closer to 2.3GB total for all five users. I have a special user account "wineadmin" which is identical to other user accounts except that it owns "/srv/wine". I login as wineadmin and I create a directory "~/.wine-Diablo_II" and install Diablo II into it (WINEPREFIX=/home/wineadmin/.wine-Diablo_II). The latest Diablo updates and patches are applied. 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). For each user ("administrator" in this example) I create "~/.wine-Diablo_II" and "~/.wine-Diablo_II_rw" and mount the shared copy with aufs: mount -v -t aufs -o br:/home/administrator/.wine-Diablo_II_rw=rw:/srv/wine/.wine-Diablo_II=ro none /home/administrator/.wine-Diablo_II Wine symlinks for administrator are recreated in "~/.wine-Diablo_II/dosdevices" and "~/.wine-Diablo_II/drive_c/users/administrator". Registry entries for wineadmin in the administrator copy of the registry (~/.wine-Diablo_II/*.reg) are fixed with sed and regex. XDG/fdo menu entries are added in "~/.config/menus" and "~/.local/share/applications". The game is started and new license keys are entered. This process is repeated for each user. When a user updates Diablo II from its built-in updater, the changes only affect them as they are contained in their rw branch. When they play the game, the save files are located in the Diablo II application directory in "~/.wine-Diablo_II/drive_c/Program Files/Diablo II/save/" and game settings are either in *.ini files or in the Wine registry. Next I need to install a popular mod, Median XL (http://modsbylaz.hugelaser.com). It consists of a replacement "Patch_D2.mpq" file. Because it greatly changes and complicates the game, I need to maintain the original installation for beginners. I log back into wineadmin. I move "/home/wineadmin/.wine-Diablo_II" and a create a new empty directory "~/.wine-Diablo_II" and ".wine-Diablo_II_rw". I mount the "/srv/wine/.wine-Diablo_II" the same as I did for administrator. I then install the Median XL mpq file. I then unmount ".wine-Diablo_II" and copy the contents of ".wine-Diablo_II_rw" (excluding .wh.*) to "/srv/wine/.wine-Diablo_II_Median_XL". In the "administrator" home, I create two new directories, ".wine-Diablo_II_Median_XL" and ".wine-Diablo_II_Median_XL_rw" then mount them with aufs: mount -v -t aufs -o br:/home/administrator/.wine-Diablo_II_Median_XL_rw=rw:/srv/wine/.wine-Diablo_II=ro:/srv/wine/.wine-Diablo_II_Median_XL=ro none /home/administrator/.wine-Diablo_II_Median_XL I then fix the registry, links, and menu entries. The user now has two different Diablo II installations, original and Median XL. They act completely independent of each other which is important because game save files from Median XL are not compatible with the original game. Total size for one user is 2.3GB and very little additional space for five users (or many more). For a single-file modification this may seem overcomplicated but modifications in other games have hundreds of files that are changed including changes in the Wine registry. With registry changes I normally create a diff of them and patch it back in for each user. I have shell scripts that perform some of the work. When the users update the game or add more third-party modifications the space usage will increase but not all users will do that so the total is still much less than separate Diablo II installations. The next step is to add more ro branches to the mounts for accessory applications like an archive manager. Many modifications and updates are distributed in archive files (zip, rar, 7z). These are intended to be extracted into the application directories, overwriting existing files. Most *nix filesystems are case-sensitive and Windows applications are designed to be case-insensitive. These archives can't be installed reliably into the Wine application directories as many have mismatched filename cases, which isn't a problem on Windows but on *nix the files from the archive won't overwrite the existing files as intended. The only solution is to use a Windows-based archive tool like 7-Zip (GUI version). When it is used to extract the files, Wine will normalize the filename case and correctly overwrite the original files. Installation of 7-Zip (and other accessory applications) is performed the same way as Median XL, resulting in another ro branch in the final aufs mount. 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 export "/srv/wine" with Samba and then mount it back with CIFS, set the UID/GID to "administrator", then use this mount for the ro branch. This has to be repeated for each user (and probably for each branch ro like Median XL but I haven't tried that yet). The CIFS mount target is "~/.wine-Diablo_II_uid": mount -t cifs //localhost/.wine-Diablo_II /home/administrator/.wine-Diablo_II_uid -o uid=administrator,gid=administrator,ro Thanks to the Gnome gvfs bug the CIFS ro mounts are shown as mounted volumes in Nautilus even though they are useless to the users. Next they have to be mount as ro through aufs: mount -v -t aufs -o br:/home/administrator/.wine-Diablo_II_rw=rw:/home/administrator/.wine-Diablo_II_uid=ro none /home/administrator/.wine-Diablo_II If I install a dozen games and applications through Wine for all users, this gets to be a real mess. I would like to do the mounts at login through pam_mount but I don't think that is possible with the dependency of the aufs mounts on the CIFS mounts. > > Aufs never write to the ro branch. > If it happens, it must a bug. > Correct although in my example the ro branch is owned by wineadmin. > > Jeff, > I don't think your discussion style is good. You send mails to me > directly, personally and I replied to you. Later you forwarded your > messages only to the aufs ML. It might be your simple failure of > operating mail software. But it is not only once. I won't reply to your > personal mails. > I noticed that the list wasn't CC in the last few emails. I'm not sure why that happened so I forwarded them manually. Maybe it's a Gmail bug. ------------------------------------------------------------------------------ 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
