Page MenuHomeFreeBSD
Files F149171791

D27232.diff
No OneTemporary
Actions

D27232.diff
View Options

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 @@
+ <!-- START SECTION 8: MULTI-USER WINE -->
+ <sect1 xml:id="wine-in-multi-user-os-installations">
+ <title>WINE in Multi-User &amp;os; Installations</title>
+
+ <sect2 xml:id="issues-with-using-a-common-wine-prefix">
+ <title>Issues with Using a Common WINE Prefix</title>
+
+ <para>Like most &amp;os.unix;-like operating systems, &amp;os; is
+ designed for multiple users to be logged in and working at the
+ same time. On the other hand, &amp;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.</para>
+
+ <para>More recent consumer versions of &amp;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 &amp;os; applications
+ (including WINE itself), it will resemble this single-user
+ environment</para>
+
+ <para>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).</para>
+
+ <para>There are two strategies to minimze the impact of multiple WINE
+ users in the system.</para>
+ </sect2>
+
+ <sect2 xml:id="installing-applications-to-a-common-drivesettings">
+ <title>Installing Applications to a Common Drive</title>
+
+ <para>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.</para>
+
+ <para>The steps to make install applications in this way are as
+ follows:</para>
+
+ <orderedlist spacing="compact">
+ <listitem>
+ <para>First, set up a shared location on the system where the
+ files will be stored, such as <filename>/mnt/windows-drive_d/</filename>.
+ Creating new directories is described in man page for the
+ <application>mkdir</application> command.</para>
+ </listitem>
+
+ <listitem>
+ <para>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 &quot;windows,&quot; 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
+ &quot;770&quot; (the section on Permissions in the &amp;os;
+ Basics chapter of the Handbook illustrates this process).</para>
+ </listitem>
+
+ <listitem>
+ <para>Finally, add the location as a drive to the user's prefix
+ using the <application>winecfg&lt;/application&gt; as
+ described in the above section on WINE Configuration in this
+ chapter.</para>
+ </listitem>
+ </orderedlist>
+
+ <para>Once complete, applications can be installed to this location,
+ and subsequently run using the assigned drive letter (or the
+ standard &amp;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
+ &quot;read/write/execute&quot; permissions for the entire
+ directory.</para>
+ </sect2>
+
+ <sect2 xml:id="using-a-common-installation-of-wine">
+ <title>Using a Common Installation of WINE</title>
+
+ <para>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 <application>su&lt;/application&gt;
+ 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.</para>
+
+ <para>Create a new user with the following command (as root), which
+ will step through the required details:</para>
+
+<screen>&prompt.root;<userinput>adduser</userinput></screen>
+
+ <para>Enter the username (e.g. &quot;windows&quot;) and Full name
+ (&quot;Microsoft Windows&quot;). Then accept the defaults for
+ the remainder of the questions. Next, install the
+ <application>sudo&lt;/application&gt; utlity using binary
+ packages with the following:</para>
+
+<screen>&prompt.root;<userinput>pkg install sudo</userinput></screen>
+
+ <para>Once installed, edit the<filename>/etc/sudoers</filename> file
+ as follows:</para>
+
+<programlisting># 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</programlisting>
+
+ <para>The result of these changes is the users named in the
+ <emphasis>User_Alias</emphasis> section
+ are permitted to run the programs listed in the
+ <emphasis>Cmnd<subscript>Alias</subscript></emphasis> section
+ using the resources listed in the <emphasis>Defaults</emphasis>
+ section (the current display) as if they were the user listed in
+ the final line of the file. In other words, users designates as
+ <emphasis>WINDOWS_USERS</emphasis> can run the <application>wine
+ </application> and <application>winecfg</application> applications as
+ user <emphasis>windows</emphasis>. As a bonus, the configuration
+ here means they will not be required to enter the password for
+ the <emphasis>windows</emphasis> user.</para>
+
+ <para>Next provide access to the display back to the
+ <emphasis>windows</emphasis> user, as whom the WINE programs
+ will be running:
+ </para>
+
+<screen>&prompt;<userinput>xhost +local:windows</userinput></screen>
+
+ <para>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
+ &quot;WINDOW_USERS&quot; in the <filename>sudoers</filename> file can
+ run programs using the shared prefix with the followihng command:</para>
+
+ <para>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.</para>
+ </sect2>
+ </sect1>

File Metadata

Mime Type
text/plain
Expires
Mon, Mar 23, 6:15 PM (20 h, 21 m)
Storage Engine
blob
Storage Format
Raw Data
Storage Handle
30198216
Default Alt Text
D27232.diff (9 KB)

Event Timeline