Index: en_US.ISO8859-1/books/handbook/wine/chapter.xml =================================================================== --- en_US.ISO8859-1/books/handbook/wine/chapter.xml +++ en_US.ISO8859-1/books/handbook/wine/chapter.xml @@ -0,0 +1,182 @@ + + + WINE in Multi-User &os; Installations + + + Issues with Using a Common WINE Prefix + + Like most &os.unix;-like operating systems, &os; is + designed for multiple users to be logged in and working at the + same time. On the other hand, &os.windows; is multi-user in + the sense that there can be multiple user accounts set up on one + system. But the expectation is that only one will be using the + physical machine (a desktop or laptop PC) at any given moment. + + More recent consumer versions of &os.windows; have taken + some steps to improve the OS in multi-user scenarios. But it is + still largely structured around a single-user experience. + Furthermore, the measures the WINE project has taken to create a + compatible environment means, unlike &os; applications + (including WINE itself), it will resemble this single-user + environment + + So it follows that each user will have to maintain his/her own + set of configurations, which is potentially good. Yet it is + advantageous to install applications, particularly large ones + like office suites or games, only once. Two examples of reasons + to do this are maintenance (software updates need only be + applied once) and efficiency in storage (no duplicated files). + + There are two strategies to minimze the impact of multiple WINE + users in the system. + + + + Installing Applications to a Common Drive + + As shown in the section on WINE Configuration, WINE provides the + ability to attach additional drives to a given prefix. In this + way, applications can be installed to a common location, while + each user will still have an prefix where individual settings + may be kept (depending on the program). This is a good setup if + there are relatively few applications to be shared between + users, and they are programs that require few custom tweaks + changes to the prefix in order to function. + + The steps to make install applications in this way are as + follows: + + + + First, set up a shared location on the system where the + files will be stored, such as /mnt/windows-drive_d/. + Creating new directories is described in man page for the + mkdir command. + + + + Next, set permissions for this new directory to allow only + desired users to access it. One approach to this is to + create a new group such as "windows," add the + desired users to that group (see the sub-section on groups + in the Handbook's Users and Basic Account Management + section), and set to the permissions on the directory to + "770" (the section on Permissions in the &os; + Basics chapter of the Handbook illustrates this process). + + + + Finally, add the location as a drive to the user's prefix + using the winecfg</application> as + described in the above section on WINE Configuration in this + chapter. + + + + Once complete, applications can be installed to this location, + and subsequently run using the assigned drive letter (or the + standard &os.unix;-style directory path). However, as noted + above, only one user should be running these applications (which + may be accessing files within their installation directory) at + the same time. Some applications may also exhibit unexpected + behavior when run by a user who is not the owner, despite being + a member of the group that should have full + "read/write/execute" permissions for the entire + directory. + + + + Using a Common Installation of WINE + + If, on the other hand, there are many applications to be shared, + or they require specific tuning in order to work correctly, a + different approach may be required. In this method, a completely + separate user is created specifically for the purposes of + storing the WINE prefix and all its installed applications. + Individual users are then granted permission to run programs as + this user using the su</application> + command. The result is that these users can launch a WINE + application as they normally would, only it will act as though + launched by the newly-created user, and therefore use the + centrally-maintained prefix containing both settings and + programs. To accomplish this, take the following steps. + + Create a new user with the following command (as root), which + will step through the required details: + +&prompt.root;adduser + + Enter the username (e.g. "windows") and Full name + ("Microsoft Windows"). Then accept the defaults for + the remainder of the questions. Next, install the + sudo</application> utlity using binary + packages with the following: + +&prompt.root;pkg install sudo + + Once installed, edit the/etc/sudoers file + as follows: + +# User alias specification + +# define which users can run the wine/windows programs +User_Alias WINDOWS_USERS = user1,user2 + +# define which users can administrate (become root) +User_Alias ADMIN = user1 + +# Cmnd alias specification + +# define which commands the WINDOWS_USERS may run +Cmnd_Alias WINDOWS = /usr/bin/wine,/usr/bin/winecfg + +# Defaults +Defaults:WINDOWS_USERS env_reset +Defaults:WINDOWS_USERS env_keep += DISPLAY +Defaults:WINDOWS_USERS env_keep += XAUTHORITY +Defaults !lecture,tty_tickets,!fqdn + +# User privilege specification +root ALL=(ALL) ALL + +# Members of the admin user_alias, defined above, may gain root privileges +ADMIN ALL=(ALL) ALL + +# The WINDOWS_USERS may run WINDOWS programs as user windows without a password +WINDOWS_USERS ALL = (windows) NOPASSWD: WINDOWS + + The result of these changes is the users named in the + User_Alias section + are permitted to run the programs listed in the + CmndAlias section + using the resources listed in the Defaults + section (the current display) as if they were the user listed in + the final line of the file. In other words, users designates as + WINDOWS_USERS can run the wine + and winecfg applications as + user windows. As a bonus, the configuration + here means they will not be required to enter the password for + the windows user. + + Next provide access to the display back to the + windows user, as whom the WINE programs + will be running: + + +&prompt;xhost +local:windows + + This should be added to the list of commands run either at login + or when the default graphical environment starts. Once all the + above are complete, a user configured as one of the + "WINDOW_USERS" in the sudoers file can + run programs using the shared prefix with the followihng command: + + It's worth noting that multiple users accessing this shared + environment at the same time is still risky. However, consider + also that the shared environment can itself contain multiple + prefixes. In this way an administrator can create a tested and + verified set of programs, each with its own prefix. At the same + time, one user can play a game while another works with office + programs without the need for redundant software installations. + +