The translation is temporarily closed for contributions due to maintenance, please come back later.

Translation

<prompt>%#</prompt> <userinput>topadduser</userinput>
(itstool) path: sect2/screen
English
<prompt>#</prompt> <userinput>adduser</userinput>
Context English Persian State
Issues with Using a Common WINE Prefix
Like most <trademark class="registered">UNIX</trademark>-like operating systems, FreeBSD is designed for multiple users to be logged in and working at the same time. On the other hand, <trademark class="registered">Windows</trademark> 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 <trademark class="registered">Windows</trademark> 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 acompatible environment means, unlike FreeBSD applications (including WINE itself), it will resemble this single-user environment.
So it follows that each user will have to maintain their 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 <filename>/mnt/windows-drive_d/</filename>. Creating new directories is described in man page for the <application>mkdir</application> 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 <literal>770</literal> (the section on Permissions in the FreeBSD Basics chapter of the Handbook illustrates this process).
Finally, add the location as a drive to the user's prefix using the <application>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 <trademark class="registered">UNIX</trademark>-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 <application>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>#</prompt> <userinput>adduser</userinput> <prompt>%</prompt> <userinput>top</userinput>
Enter the username (e.g., <replaceable>windows</replaceable>) and Full name ("Microsoft Windows"). Then accept the defaults for the remainder of the questions. Next, install the <application>sudo</application> utlity using binary packages with the following:
<prompt>#</prompt> <userinput>pkg install sudo</userinput>
Once installed, edit <filename>/etc/sudoers</filename> 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 <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.
Next provide access to the display back to the <emphasis>windows</emphasis> user, as whom the WINE programs will be running:
<prompt>%</prompt> <userinput>xhost +local:windows</userinput> <prompt>%</prompt> <userinput>top</userinput>
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 <literal>WINDOW_USERS</literal> in <filename>sudoers</filename> can run programs using the shared prefix with the following command:
it is 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.
WINE on FreeBSD FAQ FreeBSD چه می‌تواند انجام دهد؟
The following section describes some frequently asked questions, tips/tricks, or common issues in running WINE on FreeBSD, along with their respective answers.
Basic Installation and Usage
How to Install 32-bit and 64-bit WINE on the Same System?
As described earlier in this section, the <application>wine</application> and <application>i386-wine</application> packages conflict with one another, and therefore cannot be installed on the same system in the normal way. However, multiple installs can be achieved using mechanisms like chroots/jails, or by building WINE from source (note this does <emphasis>not</emphasis> mean building the port).
Can DOS Programs Be Run on WINE?

Loading…

User avatar None

Source string changed

FreeBSD Doc (Archived) / books_handbookPersian

<prompt>%#</prompt> <userinput>topadduser</userinput>
a month ago
Browse all component changes

Glossary

English Persian
Prompt پیام‌واره FreeBSD Doc (Archived)

Source information

Source string comment
(itstool) path: sect2/screen
Flags
no-wrap
Source string location
book.translate.xml:21017
String age
a month ago
Source string age
a month ago
Translation file
books/fa/handbook.po, string 3450