Wine და Proton: Windows-ის სერვერები Linux-ზე

მხოლოდ Windows-ის გამოყოფილი სერვერი Linux-ზე ჩვეულებრივ Wine-ის ქვეშ ეშვება და რეცეპტი მოკლეა: Windows-ის build ჩამოტვირთე SteamCMD-ით, რომელსაც Windows-ის პლატფორმა ძალით აქვს მითითებული, შექმენი 64-ბიტიანი Wine prefix, დააყენე Visual C++ runtime, რომელსაც სერვერი იყენებს, დაამატე ვირტუალური დისპლეი, თუ ამას მოითხოვს, და .exe wine-ით გაუშვი. headless სერვერები Wine-ისთვის გაცილებით მარტივია, ვიდრე თამაშის კლიენტები, რადგან მათ არც გრაფიკა სჭირდებათ, არც ხმა და Windows-იდან ძალიან ცოტა. ეს კარგად მუშაობს ბევრ survival სერვერზე - Enshrouded, V Rising, Abiotic Factor, Sons of the Forest და სხვები ხშირად სწორედ ასე ეშვება - და ცუდად რამდენიმეზე, რომელთა შორის ცნობილი რთული შემთხვევა Space Engineers-ია. ეს სტატია აღწერს აწყობას, Proton-ის ალტერნატივას და შეცდომებს, რომლებიც თითქმის ყველა ჩავარდნილ მცდელობას ხსნის.

თუ ჯერ კიდევ წყვეტ, ამის რომელიმე ნაწილი გჭირდება თუ არა, სტატია Linux თუ Windows თამაშის სერვერებისთვის ჩამოთვლის, რომელ სერვერებს აქვს Linux build. თუ ნატიური არსებობს, ის გამოიყენე; Wine მაშინაა, როცა ის არ არსებობს.

რას აკეთებს Wine სინამდვილეში#

Wine არც ემულატორია და არც ვირტუალური მანქანა. ეს Windows API-ის ხელახალი რეალიზაციაა Linux-ზე: როცა Windows-ის პროგრამა CreateFileW-ს იძახებს ან Winsock-ით socket-ს ხსნის, ამ გამოძახებას Wine-ის საკუთარი ბიბლიოთეკები ამუშავებს და Linux-ის ეკვივალენტად თარგმნის. CPU პროგრამის მანქანურ კოდს პირდაპირ ასრულებს, და ამიტომაა წარმადობის დანაკარგი მცირე.

გამოყოფილი სერვერი კარგი კანდიდატია, რადგან Windows-ის ვიწრო ნაწილს იყენებს: ფაილებს, thread-ებს, socket-ებს, კონსოლს და C++ runtime-ს. Wine-ის ის ნაწილები, რომლებიც თამაშებს პრობლემებს უქმნის - DirectX-ის თარგმნა, აუდიო, კონტროლერები, anti-cheat-ის დრაივერები - აქ ძირითადად ჩართული არ არის. როცა სერვერები მაინც ვარდება, ჩვეულებრივ ოთხიდან ერთ-ერთის ბრალია: აკლია runtime DLL, დამოკიდებულია .NET Framework-ზე, დისპლეის მოითხოვს მაშინაც კი, როცა არაფერს ხატავს, ან სერვერის მხარის anti-cheat კომპონენტს ნამდვილი Windows უნდა.

Proton არის Valve-ის Wine-ის დისტრიბუცია, დამატებითი patch-ებითა და ბიბლიოთეკებით Steam-ის თამაშებისთვის. სერვერებისთვის ის იმავე რამის ალტერნატიული build-ია, ხან უფრო თავსებადი, ხან ნაკლებად. დაიწყე ჩვეულებრივი Wine-ით და Proton-ს (პრაქტიკაში, საზოგადოების GE-Proton build-ებს) მიმართე, თუ ცნობილია, რომ კონკრეტულ სერვერს ის სჭირდება.

Wine-ისა და სერვერის ინსტალაცია#

დისტრიბუციის პაკეტები მუშაობს, მაგრამ ხშირად რამდენიმე რელიზით ჩამორჩება. ბოლო ერთი-ორი წლის თამაშის სერვერებს ზოგჯერ უფრო ახალი Wine სჭირდება, ვიდრე სტაბილური დისტრიბუცია აწვდის, ამიტომ ჩვეულებრივი არჩევანი WineHQ-ის რეპოზიტორიაა:

$ sudo dpkg --add-architecture i386$ sudo mkdir -pm755 /etc/apt/keyrings$ sudo wget -O /etc/apt/keyrings/winehq-archive.key \    https://dl.winehq.org/wine-builds/winehq.key$ sudo wget -NP /etc/apt/sources.list.d/ \    https://dl.winehq.org/wine-builds/ubuntu/dists/noble/winehq-noble.sources$ sudo apt update$ sudo apt install --install-recommends winehq-stable$ sudo apt install winetricks xvfb cabextract

noble შენი რელიზის კოდური სახელით შეცვალე (WineHQ sources ფაილს ყოველი მხარდაჭერილი Debian-ისა და Ubuntu-ს რელიზისთვის აქვეყნებს). winehq-stable კონსერვატიული არჩევანია; winehq-staging შეიცავს patch-ებს, რომლებიც stable-ში ჯერ არ მოხვედრილა, და ზოგჯერ სწორედ ესაა, რაც ახლად გამოსულ სერვერს სჭირდება. რა მიიღე, შეამოწმე wine --version-ით.

ყველაფერი, რაც შემდეგ მოდის, გაუშვი იმავე არაპრივილეგირებული მომხმარებლით, რომელსაც სერვერის ფაილები ეკუთვნის. Wine prefix, რომელიც root-მა შექმნა და შემდეგ სხვა მომხმარებელი იყენებს, საიმედო გზაა, რომ საათი წვდომის შეცდომებზე დახარჯო.

Windows-ის build-ის ჩამოტვირთვა SteamCMD-ით

SteamCMD Linux-ზე Steam-ს ნაგულისხმევად Linux-ის depot-ებს სთხოვს. მხოლოდ Windows-ის სერვერისთვის ეს მოთხოვნა ან Invalid Platform-ით ვარდება, ან არაფერს გამოსადეგს არ ჩამოტვირთავს. პლატფორმა login-მდე ძალით მიუთითე:

$ ./steamcmd.sh +@sSteamCmdForcePlatformType windows \    +force_install_dir /srv/enshrouded \    +login anonymous \    +app_update 2278520 validate +quit

@sSteamCmdForcePlatformType windows პარამეტრი მთელი იმ სესიისთვის მოქმედებს, ამიტომ პირველი დააყენე. თუ იმავე SteamCMD-იდან ნატიურ Linux სერვერებსაც უშვებ, ეს ცალკე სკრიპტში შეინახე, რომ შემთხვევით მათი Windows build-ები არ ჩამოტვირთო. გავრცელებული მხოლოდ Windows-ის თამაშების სერვერის app ID-ები მოცემულია სტატიაში SteamCMD app ID-ები და beta ბრენჩები.

Wine prefix#

prefix არის საქაღალდე, რომელიც ერთ ყალბ Windows-ის ინსტალაციას ინახავს: drive_c-ს, რეესტრს, დაყენებულ runtime-ებს. Wine ~/.wine-ს იყენებს, თუ სხვას არ მიუთითებ. ყოველ სერვერს საკუთარი prefix მიეცი, რომ ერთისთვის დაყენებულმა runtime-მა მეორე ვერ გააფუჭოს:

$ export WINEPREFIX=/srv/enshrouded/.wine$ export WINEARCH=win64$ export WINEDEBUG=-all$ export WINEDLLOVERRIDES="mscoree,mshtml="$ wineboot --init

რას აკეთებს თითოეული:

WINEARCH მხოლოდ შექმნისას მნიშვნელობს. 32-ბიტიანად შექმნილი prefix 32-ბიტიანი რჩება და მასში გაშვებული 64-ბიტიანი სერვერი ვარდება შეცდომით, რომ შესრულებადი ფაილის ჩატვირთვა ან პოვნა ვერ მოხერხდა. თუ ასეთს მიიღებ, წაშალე prefix და თავიდან შექმენი WINEARCH=win64-ით.

WINEDEBUG=-all ახსნას იმსახურებს. მის გარეშე Wine ბეჭდავს fixme: ხაზებს ყოველი Windows-ის ფუნქციისთვის, რომელსაც მხოლოდ ნაწილობრივ ახორციელებს. ისინი თითქმის ყოველთვის უვნებელია, მაგრამ სერვერის საკუთარ გამონატანს მარხავს, და ხალხი მათ საათობით სდევს. ნაგულისხმევად გამორთე და ხელახლა ჩართე (WINEDEBUG=err+all გონივრული შუალედია) მხოლოდ მაშინ, როცა თავად Wine-ს ამოწმებ.

Runtime-ები: Visual C++ და .NET#

Unreal-ისა და Unity-ის სერვერების უმეტესობა Microsoft-ის Visual C++ toolchain-ით იგება და მისი runtime DLL-ები სჭირდება - vcruntime140.dll, msvcp140.dll და მსგავსი. Wine ზოგიერთი მათგანის საკუთარ ჩანაცვლებას აწვდის, რომელიც ბევრ პროგრამაზე მუშაობს, ზოგზე კი არა. თუ სერვერი გაშვებისას ამ ოჯახის დაკარგული ან გაფუჭებული DLL-ით ვარდება, prefix-ში ნამდვილი runtime დააყენე:

$ WINEPREFIX=/srv/enshrouded/.wine winetricks -q vcrun2022

vcrun2022 მიმდინარე გაერთიანებულ 2015-2022 redistributable-ს აყენებს; winetricks-ის ძველ ვერსიებში მას vcrun2019 ჰქვია. თუ ეს verb აკლია, თავად winetricks განაახლე - დისტრიბუციის რეპოზიტორიაში არსებული ასლი ხშირად ძველია, და winetricks --self-update-ის გაშვება ან პროექტის GitHub რელიზიდან ინსტალაცია ამას აგვარებს.

.NET Framework უფრო რთულია. სერვერს, რომელსაც ის სჭირდება (Space Engineers-ს .NET Framework 4.8 სჭირდება), winetricks -q dotnet48 უნდა, რასაც დიდი დრო მიაქვს, ზოგჯერ შუა გზაზე ვარდება და ქმნის prefix-ს, რომელიც Wine-ის ვერსიის ცვლილებებზე მგრძნობიარეა. როცა სერვერს .NET Framework სჭირდება, საკუთარის აწყობამდე მოძებნე ამ კონკრეტული თამაშისთვის შენახული საზოგადოებრივი კონტეინერი ან egg; ჩვეულებრივ ვიღაცას უკვე უპოვია Wine-ის ვერსიისა და runtime-ების მომუშავე კომბინაცია.

ვირტუალური დისპლეები და სერვერის გაშვება#

ზოგიერთი Windows სერვერი ფანჯარას "headless" რეჟიმშიც ქმნის, Wine-ს კი მის შესაქმნელად X დისპლეი სჭირდება. მის გარეშე მიიღებ შეცდომებს, რომ დისპლეის გახსნა ვერ მოხერხდა, ან პროცესი მაშინვე დასრულდება. Xvfb ვირტუალური X სერვერია, რომელიც მეხსიერებაში ხატავს, ხოლო xvfb-run მას ბრძანების მუშაობის ხანგრძლივობით უშვებს:

$ cd /srv/enshrouded$ xvfb-run --auto-servernum --server-args="-screen 0 640x480x24" \    wine enshrouded_server.exe

ჯერ xvfb-run-ის გარეშე სცადე. ბევრ სერვერს ის არ სჭირდება და ეს ერთი მოძრავი ნაწილით ნაკლებია. დაამატე, თუ სერვერი დისპლეის გარეშე არ ეშვება.

V Rising არგუმენტებიანი ტიპური მაგალითია:

$ cd /srv/vrising$ xvfb-run --auto-servernum wine VRisingServer.exe \    -persistentDataPath ./save-data -logFile ./logs/VRisingServer.log

სერვერის საკუთარი კონფიგურაცია ზუსტად ისე მუშაობს, როგორც Windows-ზე - JSON ან ini ფაილებს Windows-ის პროგრამა კითხულობს, რომელმაც არ იცის, რომ Linux-ზეა. ამ კონფიგებში გზები შეიძლება იყოს Windows-ის ფორმით (C:\..., რომელიც prefix-ში drive_c-ს შეესაბამება), Wine-ის Z: დისკით (რომელიც Linux-ის root-ს შეესაბამება, ასე რომ Z:\srv\vrising არის /srv/vrising) ან ფარდობითი. ფარდობითი გზები ყველაზე ნაკლებად დამაბნეველია. JSON და ini ფაილებს, რომლებსაც ეს სერვერები იყენებს, აღწერს სტატია თამაშის სერვერის კონფიგურაციის ფაილის ფორმატები.

პორტები განსაკუთრებულ მოპყრობას არ საჭიროებს. Wine-ის Winsock-ის გამოძახებები ჩვეულებრივ Linux socket-ებად იქცევა, ამიტომ სერვერი თავის კონფიგში მითითებულ პორტებს უსმენს და ჩვეულებრივი firewall-ის წესები მოქმედებს - იხილე თამაშის სერვერის პორტები - ახსნა.

სერვისად გაშვება

საკუთარ მანქანაზე systemd unit სერვერს გამოსვლის შემდეგაც მუშაობის რეჟიმში ტოვებს და ჩატვირთვისას უშვებს. გარემოს ცვლადები unit-ში იწერება, რომ ყოველმა გაშვებამ ერთი და იგივე prefix გამოიყენოს:

[Unit]Description=Enshrouded server (Wine)After=network-online.target[Service]User=steamWorkingDirectory=/srv/enshroudedEnvironment=WINEPREFIX=/srv/enshrouded/.wine WINEDEBUG=-allExecStart=/usr/bin/wine enshrouded_server.exeKillSignal=SIGINTTimeoutStopSec=60Restart=on-failure[Install]WantedBy=multi-user.target

KillSignal=SIGINT ითხოვს ყველაზე რბილ გაჩერებას, რისი გაგზავნაც systemd-ს შეუძლია, ხოლო TimeoutStopSec სერვერს წუთს აძლევს შესანახად, სანამ kill-ს მიიღებს. ინახავს თუ არა თამაში რეალურად ამ სიგნალზე Wine-ის ქვეშ, ცალკე საკითხია, რომელიც ქვემოთ, სუფთა გაჩერების ნაწილშია განხილული. unit ფაილის დანარჩენ ნაწილს systemd სერვისები შენი აპლიკაციებისთვის ხსნის.

გაშვება Proton-ით#

თუ ცნობილია, რომ სერვერს Proton სჭირდება, ჩამოტვირთე GE-Proton-ის რელიზი, გახსენი და სერვერი მისი proton სკრიპტით გაუშვი. Proton ორ გარემოს ცვლადს ელის, რომლებსაც ჩვეულებრივ Steam აყენებს:

$ export STEAM_COMPAT_CLIENT_INSTALL_PATH=/home/steam/steamcmd$ export STEAM_COMPAT_DATA_PATH=/srv/abiotic/proton-data$ mkdir -p "$STEAM_COMPAT_DATA_PATH"$ /opt/GE-Proton/proton run AbioticFactor/Binaries/Win64/AbioticFactorServer-Win64-Shipping.exe \    -log -PORT=7777 -QueryPort=27015

STEAM_COMPAT_DATA_PATH ის ადგილია, სადაც Proton თავის prefix-ს ინახავს (შიგნით pfx-ს ქმნის), ასე რომ ის WINEPREFIX-ის როლს ასრულებს. კლიენტის ინსტალაციის გზას მხოლოდ არსებობა სჭირდება; ჩვეულებრივ SteamCMD-ის საქაღალდეზე მიუთითებენ. Proton პირველ ჯერზე wineboot-ს თავად უშვებს, რაც პირველ გაშვებას ანელებს.

კომპრომისი: Proton შეიცავს გასწორებებს, რომლებსაც სხვაგვარად winetricks-ით დააყენებდი, მაგრამ ის უფრო დიდი მოძრავი ნაწილია, მისი ვერსიები GE-ის რელიზების რიტმზეა მიბმული, და მისი debug ნიშნავს Wine-ის debug-ს, ზემოდან დამატებითი ფენებით. სერვერების უმეტესობისთვის ჩვეულებრივი Wine უფრო მარტივია.

სუფთა გაჩერება, save-ები და პანელი#

ეს ის ნაწილია, რომელიც სერვერის გაშვების შემდეგ ყველაზე მნიშვნელოვანია, რადგან სწორედ აქ იკარგება სამყაროები.

Linux-ზე გაჩერება სიგნალია. ნატიური Linux სერვერი SIGINT-ს ან SIGTERM-ს იღებს, ინახავს და გამოდის. Windows-ის პროგრამა Wine-ის ქვეშ ამის ნაცვლად თარგმნილ კონსოლის მოვლენას იღებს, და რეაგირებს თუ არა ისე, როგორც Windows-ზე Ctrl+C-ზე, პროგრამაზეა დამოკიდებული. ზოგი სუფთად ინახავს და გამოდის. ზოგი მას იგნორირებს, სანამ kill-ს არ მიიღებს. ზოგი მაშინვე გამოდის შენახვის გარეშე.

ეს შეამოწმე, სანამ ენდობი:

1. გაუშვი სერვერი და სამყაროში ისეთი ცვლილება შეიტანე, რომელსაც ამოიცნობ.
2. გააჩერე ისე, როგორც შენი პანელი ან service manager აჩერებს.
3. ხელახლა გაუშვი და ნახე, გადარჩა თუ არა ცვლილება.

თუ არ გადარჩა, ყოველი გაჩერების წინ თამაშის საკუთარი save ბრძანება გაგზავნე - ამ სერვერების უმეტესობას ის RCON-ში ან კონსოლში აქვს - და autosave-ის ინტერვალი შეამცირე, რომ kill-მა ნახევარი საათის ნაცვლად წუთები დაკარგოს. ამ ინტერვალის კომპრომისები აღწერილია სტატიაში თამაშის სერვერის autosave-ის ინტერვალები.

Pterodactyl-ის პანელზე მხოლოდ Windows-ის თამაშები შიგნით ჩვეულებრივ სწორედ ასე ეშვება: egg Wine-იან image-ს იყენებს, ინსტალაციის სკრიპტი Windows-ის build-ს ჩამოტვირთავს, ხოლო გაშვების ხაზი .exe-ს wine-ში ახვევს. ამისთვის საზოგადოებრივი image-ები ghcr.io/parkervcp/yolks-ის ქვეშ Wine-ის tag-ებით ქვეყნდება, თუმცა tag-ების სახელები და შიგთავსი დროთა განმავლობაში იცვლება. egg ასევე განსაზღვრავს გაჩერების ბრძანებას, და ამიტომაა, რომ ერთი და იგივე Stop ღილაკი ერთ Wine თამაშზე სუფთად ინახავს, მეორეზე კი არა. სად ყენდება ეს, აღწერს სტატია Pterodactyl-ის egg-ები თამაშის სერვერებისთვის.

RE:NODE-ზე ისეთი თამაშები, როგორიცაა Sons of the Forest, The Forest და Abiotic Factor, პანელიდან ყენდება და ეშვება ისე, რომ Wine-ს საერთოდ არ ეხები, ხოლო ყველა გეგმას აქვს backup-ის სლოტები და Schedules ჩანართი, ასე რომ save ბრძანება და შემდეგ backup ტაიმერით შეიძლება გაეშვას, მიუხედავად იმისა, რას უშვრება თამაში გაჩერების სიგნალს.

მეხსიერება და წარმადობა Wine-ის ქვეშ#

ფასი რეალურია, მაგრამ ზომიერი. მოელოდე რამდენიმე ასეული მეგაბაიტით მეტ მეხსიერებას, ვიდრე იგივე სერვერი Windows-ზე გამოიყენებდა, ძირითადად Wine-ის სერვერის პროცესისა და ჩატვირთული ბიბლიოთეკების ხარჯზე. CPU-ის დანახარჯი ჩვეულებრივ მცირეა, რადგან პროგრამის კოდი ნატიურად სრულდება და თარგმნაზე მხოლოდ სისტემური გამოძახებები გადის. პირველი გაშვება უფრო ნელია, სანამ Wine prefix-ს აწყობს და, Proton-ის შემთხვევაში, საკუთარ კომპონენტებს აკომპილირებს; შემდგომი გაშვებები ნორმალურია.

ორი რამ წარმადობას იმაზე უარესს ხდის, ვიდრე უნდა იყოს:

• Debug გამონატანი. მოლაპარაკე სერვერზე WINEDEBUG-ის დაუყენებლობა ლოგში წუთში ათასობით fixme: ხაზს წერს, რაც დისკსა და ცოტა CPU-ს ხარჯავს.
• ძველი Wine. Wine-ის ახალი რელიზები thread-ებსა და ფაილურ I/O-ს რეგულარულად აუმჯობესებს. თუ სერვერი Wine-ის ქვეშ ჭედავს, Windows-ის ჰოსტებზე კი გლუვად მუშაობს, თამაშის მორგებამდე სცადე უფრო ახალი stable ან staging build.

შეცდომები და რას ნიშნავს ისინი#

ორი ჩვევა debug-ს მნიშვნელოვნად ამოკლებს. წაიკითხე სერვერის საკუთარი ლოგ ფაილი და არა Wine-ის გამონატანი, რადგან სასარგებლო შეცდომა ჩვეულებრივ თამაშისაა. და როცა სერვერი, რომელიც გუშინ მუშაობდა, დღეს ვარდება, ჰკითხე საკუთარ თავს, რა შეიცვალა - თამაშის განახლება, Wine-ის განახლება თუ prefix, რომელსაც ვიღაც შეეხო - სანამ რამეს თავიდან დააყენებ. კონსოლის კითხვა აქაც ზუსტად ისე მოქმედებს, როგორც ნატიურ სერვერებზე.

FAQ#

ეწინააღმდეგება Wine-ის ქვეშ სერვერის გაშვება თამაშის წესებს?

წესისამებრ, არა. შენ დეველოპერის საკუთარ სერვერის ბინარს უშვებ; Wine მხოლოდ ოპერაციული სისტემის ფენას იძლევა. რასაც ვერ იღებ, დეველოპერის მხარდაჭერაა, ამიტომ ბაგებზე მხოლოდ მას შემდეგ შეატყობინე, რაც მათ Windows-ზე გაიმეორებ.

Wine თუ Proton - რომელი გამოვიყენო თამაშის სერვერისთვის?

დაიწყე Wine-ით WineHQ-ის რეპოზიტორიიდან და იმ runtime-ებით, რომლებიც სერვერს სჭირდება. GE-Proton-ზე გადადი, როცა ცნობილია, რომ კონკრეტული სერვერი მასთან უკეთ მუშაობს, ან როცა Wine ისე ვარდება, რომ უფრო ახალი build-იც ვერ შველის.

მუშაობს Wine anti-cheat-იან სერვერებზე?

იმაზეა დამოკიდებული, რა მუშაობს სერვერზე. სერვერის მხარის კომპონენტები, რომლებსაც მხოლოდ ჩვეულებრივი ქსელი სჭირდებათ, ხშირად მუშაობს. ყველაფერი, რაც kernel-ის დრაივერს ან Windows-თან ღრმა ინტეგრაციას ელის, არ მუშაობს, და ზოგი თამაში Wine-ის ქვეშ თავის anti-cheat-ს საერთოდ არ უშვებს.

შემიძლია ერთი Wine prefix რამდენიმე სერვერს შორის გავიყო?

შეგიძლია, მაგრამ ნუ გააკეთებ. ერთი სერვერისთვის runtime-ის ან რეესტრის ცვლილებამ მეორე შეიძლება გააფუჭოს, ხოლო გაფუჭებული prefix-ის წაშლა მხოლოდ ერთ თამაშზე უნდა მოქმედებდეს. prefix-ები იაფია; ყოველ სერვერს საკუთარი მიეცი.

რატომ იყენებს ჩემი Wine სერვერი იმაზე მეტ მეხსიერებას, ვიდრე მოთხოვნებშია?

მოთხოვნები Windows-ისთვისაა დაწერილი. Wine საკუთარ სერვერის პროცესსა და ბიბლიოთეკებს ამატებს, ჩვეულებრივ რამდენიმე ასეულ მეგაბაიტს. გეგმა ამ მარაგით შეარჩიე, განსაკუთრებით თამაშებისთვის, რომლებიც ისედაც მეხსიერების ლიმიტთან ახლოს არიან.