BeamMP-Server Linux-ზე თითო დისტრიბუტივზე ერთი მზა binary-ია - არა პაკეტი და არც ის, რასაც SteamCMD აყენებს. ჩამოტვირთე შენს release-სა და CPU-ს შესაბამისი ფაილი - BeamMP-Server.ubuntu.24.04.x86_64, BeamMP-Server.debian.12.x86_64 და ა.შ. - დააყენე ერთადერთი საჭირო runtime ბიბლიოთეკა, liblua5.3-0, გახადე ფაილი executable და ერთხელ გაუშვი. ის თავისთან ახლოს ჩაწერს ნაგულისხმევ ServerConfig.toml-ს და გაჩერდება, რადგან auth key ცარიელია. ჩასვი key BeamMP Keymaster-იდან, ისევ გაუშვი ცალკე მომხმარებლით systemd unit-ის მეშვეობით, გახსენი 30814 როგორც TCP-ზე, ისე UDP-ზე და სერვერი ერთ-ორ წუთში საჯარო სიაში გამოჩნდება. განახლება ამ ერთი ფაილის ჩანაცვლებაა.
სულ ეს არის, და სუფთა მანქანაზე ათი წუთი ჩადის. პოსტის დანარჩენი ნაწილი იმ დეტალებზეა, რომლებიც განსაზღვრავს, იმუშავებს თუ არა ყველაფერი შემდეგი გადატვირთვის, BeamNG-ის შემდეგი patch-ისა და იმ დღის შემდეგაც, როცა სხვას მოუწევს ამის გარჩევა. ის, თუ რა იწერება ServerConfig.toml-ში - რუკები, MaxCars, მოდები, თითოეული key-ის მნიშვნელობა - აღწერილია BeamMP სერვერის გზამკვლევში; ეს პოსტი კი სერვერის გაშვების Linux-ის მხარეზეა.
რა გჭირდება დაწყებამდე#
BeamMP სერვერი პატარა native C++ პროგრამაა. ის მანქანებს არ სიმულირებს, მხოლოდ მათ მდგომარეობას გადასცემს, ამიტომ CPU-სა და მეხსიერებას ცოტას მოიხმარს, ხოლო გამავალ არხს ბევრს. ნებისმიერ თანამედროვე VDS-ს ან VPS-ს შეუძლია მისი გაშვება; მთავარია, ოპერაციული სისტემა ისეთი იყოს, რომლისთვისაც პროექტი აგებს build-ებს.
| რესურსი | მინიმუმი | კომფორტული |
|---|---|---|
| RAM | 1 GB თავისუფალი | 2 GB თავისუფალი 10-20 მოთამაშისთვის |
| CPU | 1 ბირთვი | 2 ბირთვი, თუ Lua plugin-ები სერიოზულ სამუშაოს აკეთებს |
| დისკი | 100 MB პლუს მოდები | მოდების ზომა გამრავლებული ორზე |
| ქსელი | TCP და UDP 30814 | კარგი გამავალი არხი, დაბალი latency |
დისკის სტრიქონში შეცდომა არ არის. სერვერის binary რამდენიმე ათეული მეგაბაიტია; იზრდება Resources/Client საქაღალდე, სადაც მოდების zip-ები დევს, და ბოლო მუშა მოდების კომპლექტის ასლის შენახვა rollback-ისთვის მას ორმაგს ხდის. რეალური შეზღუდვა გამტარუნარიანობაა: თითოეული მანქანის განახლება ყველა კლიენტთან მიდის, ხოლო ყველა ახალი შემოსული მთელ კლიენტურ მოდ-პაკეტს ჩამოტვირთავს.
გჭირდება ასევე:
- მხარდაჭერილი დისტრიბუტივი. ამ წერილის დროისთვის ოფიციალური release-ები აგებულია Debian 12, Debian 13, Ubuntu 22.04 და Ubuntu 24.04-ისთვის, თითოეული
x86_64-ისა დაarm64-ის ვარიანტით. დანარჩენ შემთხვევაში საჭიროა წყაროდან აწყობა. - sudo მანქანაზე - ბიბლიოთეკის დასაყენებლად, მომხმარებლის შესაქმნელად და unit ფაილის ჩასაწერად.
- auth key BeamMP Keymaster-იდან, მიბმული შენს BeamMP ანგარიშზე. key-ის გარეშე სერვერი არ ეშვება. როგორ მიიღო, წერია BeamMP სერვერის გზამკვლევში.
თუ მანქანა სრულიად ახალია, სანამ რომელიმე game server დაიდგმება, გააკეთე საბაზისო საქმეები - არა-root მომხმარებლით შესვლა, SSH key-ები, განახლებები. ორივე ახსნილია პოსტებში პირველი საათი ახალ VDS-ზე და SSH key-ები და დაცვა. თუ ჯერ ვერ გადაგიწყვეტია, საერთოდ გჭირდება თუ არა საკუთარი Linux მანქანა, VDS-სა და game panel-ს შორის არჩევანი პატიოსანი შედარებაა.
სწორი release binary-ის არჩევა#
BeamMP თითო დისტრიბუტივზე, release-სა და არქიტექტურაზე ერთ ფაილს აქვეყნებს BeamMP-Server-ის GitHub releases გვერდზე. v3.9 release-ებიდან Linux ფაილებს ასე ჰქვია:
BeamMP-Server.debian.12.x86_64BeamMP-Server.debian.12.arm64BeamMP-Server.debian.13.x86_64BeamMP-Server.debian.13.arm64BeamMP-Server.ubuntu.22.04.x86_64BeamMP-Server.ubuntu.22.04.arm64BeamMP-Server.ubuntu.24.04.x86_64BeamMP-Server.ubuntu.24.04.arm64მათ გვერდით შესაბამისი debuginfo.* ფაილებია. ეს crash-ანგარიშებისთვის განკუთვნილი debug სიმბოლოებია და გასაშვებად არ გჭირდება. BeamMP-Server.exe Windows-ის build-ია.
რომელი ფაილია შენი, ორი ბრძანება გეტყვის:
$ grep -E '^(ID|VERSION_ID)=' /etc/os-releaseID=ubuntuVERSION_ID="24.04"$ uname -mx86_64ID და VERSION_ID გვაძლევს დისტრიბუტივსა და release-ს; uname -m - არქიტექტურას. x86_64 ჩვეულებრივი Intel და AMD აპარატურაა. aarch64 64-ბიტიანი ARM-ია - Ampere-ის cloud instance-ები, Raspberry Pi 4 ან 5 64-ბიტიან ოპერაციულ სისტემაზე - და arm64 ფაილს შეესაბამება.
binary-ები აგებულია თითოეული release-ის სისტემურ ბიბლიოთეკებზე, ამიტომ არის თითო დისტრიბუტივზე ერთი ფაილი და არა ერთი მთელი Linux-ისთვის. შეუსაბამო ფაილი ჩვეულებრივ გაშვებისას ვარდება ჩივილით დაკარგულ ან ძალიან ძველ GLIBC ან GLIBCXX სიმბოლოზე. შუალედურ release-ზე, მაგალითად Ubuntu 24.10 ან 25.04-ზე, ყველაზე ახლო ძველი LTS-ის build ხშირად მუშაობს, მაგრამ ამას არავინ გპირდება; თუ არ გაეშვა, ან გადადი მხარდაჭერილ release-ზე, ან ააწყვე წყაროდან. Fedora, Arch და Alpine წყაროდან აწყობის ტერიტორიაა - README-ში build-ის დამოკიდებულებებია ჩამოთვლილი, ხოლო ARM build-ისთვის ჯერ უნდა გააკეთო VCPKG_FORCE_SYSTEM_BINARIES=1 export.
დამოკიდებულების დაყენება და ცალკე მომხმარებელი#
release binary სისტემურ Lua 5.3 ბიბლიოთეკას უკავშირდება, რომელსაც მინიმალური სერვერის image-ები არ შეიცავს. Debian-სა და Ubuntu-ზე ეს ერთი პაკეტია:
$ sudo apt update$ sudo apt install liblua5.3-0 ca-certificates curlca-certificates და curl binary-ის ჩამოსატვირთად და სერვერის საკუთარი HTTPS მოთხოვნებისთვისაა BeamMP backend-თან; ორივე უმეტეს image-ზე უკვე არის. თუ Lua ბიბლიოთეკას გამოტოვებ, სერვერი მაშინვე ვარდება შეტყობინებით error while loading shared libraries: liblua5.3.so.0: cannot open shared object file. ldd binary-ზე ჩამოთვლის ყველა საჭირო ბიბლიოთეკას და გამოტოვებულებს not found-ით აღნიშნავს - სხვა პრობლემის ძიებამდე შესამოწმებლად ეს ყველაზე სწრაფი გზაა.
შემდეგი ნაბიჯი მომხმარებელია, რომელიც სერვერს ფლობს და სხვას არაფერს. თავად BeamMP-ის დოკუმენტაცია ამბობს, რომ სერვერი არ უნდა გაუშვა root-ით, sudo-თი ან შენი პირადი ანგარიშით, და მიზეზი ჩვეულებრივია: Lua plugin-ები სერვერის უფლებებით სრულდება, ამიტომ root-ით გაშვებული მავნე ან დაუდევრად დაწერილი plugin მთელ მანქანას აკონტროლებს.
$ sudo useradd --system --create-home --home-dir /opt/beammp \ --shell /usr/sbin/nologin beammplogin shell-ის გარეშე system ანგარიშით SSH-ით შესვლა შეუძლებელია, და სერვერის ყველა ჩანაწერი /opt/beammp-ში მოხვდება. ამ საქაღალდეში ამ მომხმარებლის სახელით სამუშაოდ ბრძანებების წინ დაწერე sudo -u beammp, ან shell-ისთვის - sudo -u beammp -s /bin/bash.
ჩამოტვირთვა და პირველი გაშვება#
binary პირდაპირ სერვერის საქაღალდეში ჩამოტვირთე. GitHub-ის latest/download მისამართი ყოველთვის უახლეს release-ს ეძებს, ამიტომ ქვემოთ მოცემულ ბრძანებას ვერსიის ნომერი არ სჭირდება - ფაილის სახელი შენს დისტრიბუტივზე შეცვალე:
$ cd /opt/beammp$ sudo -u beammp curl -fL -o BeamMP-Server \ https://github.com/BeamMP/BeamMP-Server/releases/latest/download/BeamMP-Server.ubuntu.24.04.x86_64$ sudo -u beammp chmod +x BeamMP-Server$ sudo -u beammp ./BeamMP-Server --versionმარტივი სახელით BeamMP-Server შენახვა გრძელი release-ის სახელის ნაცვლად განზრახულია. მაშინ systemd unit-ი და ნებისმიერი განახლების სკრიპტი ერთ მუდმივ გზას მიუთითებს, და განახლება unit-ის რედაქტირების ნაცვლად ფაილის ჩანაცვლებაა.
--version ბეჭდავს ვერსიას და ამთავრებს მუშაობას, რაც ადასტურებს, რომ binary და მისი ბიბლიოთეკები იტვირთება. სხვა flag-ები, რომლებსაც სერვერი იღებს, არის --help, --config=/path/to/ServerConfig.toml და --working-directory=/path/to/folder. თუ სერვერს საკუთარი საქაღალდიდან უშვებ, როგორც ქვემოთ მოცემული unit აკეთებს, ისინი არ დაგჭირდება.
ახლა პირველი ნამდვილი გაშვება:
$ cd /opt/beammp$ sudo -u beammp ./BeamMP-Serverსერვერი ქმნის თავის ფაილებს, ბეჭდავს გაშვების სტრიქონებს და ჩივის, რომ auth key არ არის. თუ თავისით არ გამოვიდა, გააჩერე Ctrl+C-ით. საქაღალდე ახლა ასე გამოიყურება:
/opt/beammp/ BeamMP-Server ServerConfig.toml Server.log Resources/ Client/ Server/გახსენი ServerConfig.toml, ჩასვი შენი key AuthKey-ში, დააყენე Name და Port = 30814 დატოვე, თუ შეცვლის მიზეზი არ გაქვს:
$ sudo -u beammp nano /opt/beammp/ServerConfig.toml[General]Port = 30814AuthKey = "paste-your-keymaster-key-here"Name = "Linux test server"Private = trueMaxPlayers = 8MaxCars = 2ტესტირებისას Private = true სერვერს საჯარო სიას არ აჩვენებს; დაუკავშირდები პირდაპირ მისამართით. ./BeamMP-Server ხელით კიდევ ერთხელ გაუშვი. ჯანსაღი გაშვება აგრძელებს მუშაობას და [ERROR] სტრიქონებს არ ბეჭდავს; [WARN] სტრიქონები წასაკითხია, მაგრამ იშვიათად ფატალური. Ctrl+C სერვერს სუფთად გათიშვას სთხოვს - ის გამოიძახებს Lua-ს onShutdown event-ს და plugin-ებს რამდენიმე წამს აძლევს დასასრულებლად - ხოლო განმეორებით დაჭერა გამოსვლას აიძულებს. როცა ეს ინტერაქტიულად მუშაობს, გადაეცი systemd-ს.
ფაილს binary აგენერირებს და ეს მნიშვნელოვანია: ვერსიის მიერ ჩაწერილ key-ებს თავადვე კითხულობს. ძველი ფორუმის პოსტიდან ServerConfig.toml-ის ახალ სერვერზე გადაკოპირება [General]-ისთვის მუშაობს, მაგრამ ისეთი სექციები, როგორიცაა [Misc] (განახლების შეხსენებები) და არასავალდებულო HTTP ბლოკი, ვერსიების მიხედვით განსხვავდება. ეჭვის შემთხვევაში სერვერს ახალი ფაილი დააგენერირებინე და შენი მნიშვნელობები გადაიტანე.
systemd სერვისი BeamMP-სთვის#
SSH სესიაში გაშვებული სერვერი სესიასთან ერთად კვდება, tmux-ში გაშვებული კი - გადატვირთვასთან ერთად. unit ფაილი ორივეს ჭრის და გამოტანას journal-ში წერს. systemd სერვისები შენი აპებისთვის ყველა დირექტივას განმარტავს; ეს BeamMP-ის ვერსიაა:
[Unit]Description=BeamMP serverWants=network-online.targetAfter=network-online.target[Service]Type=simpleUser=beammpGroup=beammpWorkingDirectory=/opt/beammpExecStart=/opt/beammp/BeamMP-ServerKillSignal=SIGINTTimeoutStopSec=30Restart=on-failureRestartSec=10NoNewPrivileges=trueProtectSystem=fullPrivateTmp=true[Install]WantedBy=multi-user.targetსტრიქონები, რომლებიც ამ სერვერისთვისაა სპეციფიკური:
- `WorkingDirectory=/opt/beammp`. სერვერი
ServerConfig.toml-სა დაResourcesსაქაღალდეს იმ ადგილთან მიმართებით ეძებს, საიდანაც გაეშვა. ამ სტრიქონის გარეშე ის/-ში დაიწყებდა, კონფიგურაციას ვერ ნახავდა და ახალს იმ ადგილას ჩაწერას შეეცდებოდა, სადაც უფლება არ აქვს. - `After=network-online.target`. სერვერი გაშვებისას BeamMP backend-ს უკავშირდება key-ის დასადასტურებლად. ქსელამდე გაშვება ყოველ ჩატვირთვაზე გაუგებარ ავტორიზაციის შეცდომას იწვევს.
- `KillSignal=SIGINT`. იგივე სიგნალია, რაც Ctrl+C, ანუ სერვერის დოკუმენტირებული გათიშვის გზა. ის plugin-ებს
onShutdownhandler-ების გაშვების საშუალებას აძლევს.TimeoutStopSec=30არის დრო, რომელსაც systemd ელოდება, სანამ დანებდება და პროცესს გააჩერებს. - `Restart=on-failure` crash-ის შემდეგ ხელახლა უშვებს, განზრახ გაჩერების შემდეგ - არა.
RestartSec=10გაფუჭებულ კონფიგურაციას სერვერის ჩქარ ციკლში გადატვირთვას უშლის - თუ key არასწორია, ვარდება, ელოდება, ისევ ვარდება და systemd-ის start limit-ს აღწევს, რაც სწორედ გინდა.
სამი დამცავი სტრიქონი იაფია. NoNewPrivileges უშლის სერვერის მიერ გაშვებულ ყველაფერს უფლებების მიღებას, ProtectSystem=full /usr, /boot და /etc-ს მისთვის read-only-ს ხდის, ხოლო PrivateTmp საკუთარ /tmp-ს აძლევს. სერვერი მხოლოდ თავის სამუშაო საქაღალდეში წერს, ამიტომ არც ერთი მათგანი ხელს არ უშლის.
ჩატვირთვა და გაშვება:
$ sudo systemctl daemon-reload$ sudo systemctl enable --now beammp$ systemctl status beammpenable --now მას დაუყოვნებლივ და ყოველ ჩატვირთვაზე უშვებს. unit-ის ნებისმიერი რედაქტირების შემდეგ გადატვირთვამდე ისევ გაუშვი daemon-reload, თორემ systemd ძველ ვერსიას აგრძელებს.
ერთი კომპრომისი უნდა იცოდე: BeamMP-ის კონსოლი ბრძანებებს იღებს - list, kick <name> [reason], say <message>, status, lua, exit - მაგრამ მხოლოდ ინტერაქტიულ ტერმინალში. systemd-ის ქვეშ ტერმინალი მიბმული არ არის, ამიტომ ყოველდღიური მოდერაცია Lua plugin-ებით ან თამაშის შიგნით admin ხელსაწყოებით ხდება. თუ კონსოლი ხანდახან გჭირდება, გააჩერე სერვისი და binary ხელით გაუშვი beammp მომხმარებლით. თუ გამუდმებით გჭირდება, შესაძლებელია სერვერის unit-იდან გაშვებულ tmux-ში გაშვება, მაგრამ ეს უკან აბრუნებს თითქმის ყველაფერს, რისი მოცილებაც unit-ს უნდა ემსახურა; სერვერის მფლობელების უმეტესობა საბოლოოდ plugin-ს იყენებს. BeamMP Lua plugin-ები და რბოლები გვიჩვენებს, როგორ იწერება ჩატის ბრძანებები.
პორტი 30814-ის გახსნა ufw-ით#
BeamMP ერთ პორტის ნომერს ორ პროტოკოლზე იყენებს: TCP - კავშირის დასამყარებლად და მოდების ჩამოსატვირთად, UDP - მანქანების მდგომარეობისთვის. თუ მხოლოდ TCP გახსენი, მოთამაშეები დაუკავშირდებიან, რუკას ჩატვირთავენ და იქ გაიჭედებიან, ყველა სხვა მანქანა გაყინული იქნება, რადგან მდგომარეობის ნაკადი არ მოდის.
თუ ufw ჯერ ჩართული არ არის, ჩართვამდე SSH დაუშვი, თორემ საკუთარ თავს გამოკეტავ:
$ sudo ufw allow OpenSSH$ sudo ufw allow 30814/tcp comment 'BeamMP'$ sudo ufw allow 30814/udp comment 'BeamMP'$ sudo ufw enable$ sudo ufw status verboseორი წესია და არა ufw allow 30814 პროტოკოლის გარეშე, რომელიც ასევე იმუშავებდა, მაგრამ მოგვიანებით უფრო ადვილი გასაგებია არასწორად. comment ჩანს ufw status-ში და გიშველის, ექვსი თვის შემდეგ არ ეძებო, რისთვის იყო პორტი. თუ კონფიგურაციაში Port შეცვალე, ორივე წესში ახალი ნომერი გამოიყენე. სერვერი ასევე აკეთებს გამავალ HTTPS კავშირებს BeamMP backend-თან ავტორიზაციისა და სერვერების სიისთვის; ufw-ის ნაგულისხმევი პოლიტიკა გამავალ ტრაფიკს უშვებს, ამიტომ დასამატებელი არაფერია, თუ ეს არ გაგიმკაცრებია. UFW firewall-ის გზამკვლევი სრულად მოიცავს ნაგულისხმევ პოლიტიკებს, წესების რიგითობას და Docker-ის ხაფანგს.
ufw მხოლოდ მანქანის firewall-ია. ბევრ cloud პროვაიდერს instance-ის წინ ასევე აქვს ქსელური firewall ან security group, და მასაც იგივე ორი წესი სჭირდება. თუ სერვერი თავად მანქანიდან პასუხობს, მაგრამ გარედან - არა, ჩვეულებრივ ეს გარე ფენაა მიზეზი. Game server-ის პორტები განმარტებული ზოგად სურათს გვაძლევს.
რომ დარწმუნდე, სერვერი ორივე პროტოკოლზე უსმენს:
$ sudo ss -tulpn | grep 30814უნდა დაინახო ერთი tcp სტრიქონი LISTEN მდგომარეობაში და ერთი udp სტრიქონი, ორივე BeamMP-Server-ის კუთვნილი. თუ მხოლოდ ერთია, სერვერი მეორე პროტოკოლზე არ უსმენს და ვერც ერთი firewall წესი ვერ უშველის - შეამოწმე IP პარამეტრი კონფიგურაციაში, რომელიც ყველა მისამართისთვის :: ან 0.0.0.0 უნდა იყოს.
ლოგები: journalctl და Server.log#
ლოგები ორ ადგილას ინახება და ორივე გამოსადეგია.
journal-ში ინახება ყველაფერი, რასაც სერვერი კონსოლში ბეჭდავს, დროის ნიშნულებითა და სერვისის მოვლენებით, როგორიცაა crash-ები და გადატვირთვები:
$ journalctl -u beammp -f$ journalctl -u beammp --since "1 hour ago"$ journalctl -u beammp -b -p warning-f პირდაპირ მიჰყვება, --since დროის ფანჯარას ავიწროებს, -b მიმდინარე ჩატვირთვით ზღუდავს. journal-შივე ჩანს systemd-ის თვალსაზრისიც - "Main process exited, code=exited, status=1/FAILURE", "Start request repeated too quickly" - რასაც სერვერის საკუთარი ლოგი ვერ გეტყვის.
Server.log სამუშაო საქაღალდეში სერვერის საკუთარი ფაილია. ყოველ გაშვებაზე სერვერი წინას Server.old.log-ად გადაარქმევს და ახალ Server.log-ს იწყებს, ამიტომ ყოველთვის გაქვს მიმდინარე გაშვება და წინა, მეტი - არა. თუ სერვერი დაიკრაშა და გადაიტვირთა, crash-მდელი ჩანაწერები Server.old.log-შია. თუ ორჯერ გადაიტვირთა, ჩანაწერები წასულია. სწორედ ამიტომ ღირს ისტორიისთვის journal-ზე დაყრდნობა: ის ყველა გაშვებას ინახავს და ბრუნავს ზომით და არა გადატვირთვით.
კონფიგურაციაში LogChat = true ჩატს ლოგში წერს, რაც მოდერაციის ყველაზე იაფი მტკიცებულებაა. Debug = true ლოგს გაცილებით ვრცელს ხდის; ჩართე პრობლემის საძებნელად და მერე გამორთე, რადგან სწრაფად იზრდება.
თუ პატარა VDS-ზე journal დიდი გახდა, /etc/systemd/journald.conf-ში შეზღუდე SystemMaxUse=-ით და გადატვირთე systemd-journald. პოსტში Linux ბრძანებები სერვერის ადმინისტრატორებისთვის ლოგების წასაკითხი დანარჩენი ინსტრუმენტებია - grep, tail, less - როცა Server.log-ს ხელით ეძებ.
BeamMP-Server-ის განახლება#
BeamMP-ის release-ები BeamNG.drive-ის განახლებებს მიჰყვება, და ახალ პროტოკოლზე მყოფმა კლიენტმა შეიძლება ძველ სერვერზე შესვლაზე უარი თქვას. განახლება ჩვეულებრივ თამაშის patch-იდან რამდენიმე დღეში გჭირდება, ანუ სწორედ მაშინ, როცა ხალხს თამაში უნდა, ამიტომ პროცესი გლუვი უნდა იყოს.
განახლება ასეთია: გაჩერება, backup, binary-ის ჩანაცვლება, გაშვება.
$ sudo systemctl stop beammp$ cd /opt/beammp$ sudo -u beammp cp BeamMP-Server BeamMP-Server.previous$ sudo -u beammp cp ServerConfig.toml ServerConfig.toml.bak$ sudo -u beammp curl -fL -o BeamMP-Server \ https://github.com/BeamMP/BeamMP-Server/releases/latest/download/BeamMP-Server.ubuntu.24.04.x86_64$ sudo -u beammp chmod +x BeamMP-Server$ sudo -u beammp ./BeamMP-Server --version$ sudo systemctl start beammp$ journalctl -u beammp -f.previous ასლი შენი rollback-ია: თუ ახალი ვერსია ცუდად იქცევა, გააჩერე სერვისი, ძველი binary დააბრუნე და ისევ გაუშვი. curl -f წარუმატებელ ჩამოტვირთვას შეცდომით ამთავრებს და GitHub-ის შეცდომის გვერდს შენი სერვერის binary-ად არ ინახავს, ხოლო გაშვებამდე --version გაფუჭებულ ფაილს იჭერს, სანამ systemd მის გაშვებას სცდის.
მთავარ ვერსიებს შორის განახლებამდე წაიკითხე release notes. Lua API-ის სიგნატურები მთავარ ვერსიებს შორის ადრეც შეცვლილა, და plugin, რომელიც ძველ build-ზე მუშაობდა, ახალზე უხმოდ შეიძლება გატყდეს - სერვერი ეშვება, plugin კი არაფერს აკეთებს. ბოლო კონფიგურაციების [Misc] სექციაში არის ImScaredOfUpdates და UpdateReminderTime key-ები, რომლებიც სერვერის მიერ დაბეჭდილ განახლების შეხსენებას აკონტროლებს; ისინი შეტყობინებას აკონტროლებს და არა თავად განახლებას. BeamMP თავისით არ ახლდება, და ეს კარგია - შენ წყვეტ, როდის შეიცვლება მუშა სერვერი.
გაუძელი ცდუნებას, ჩამოტვირთვის სტრიქონი cron job-ში ჩადო. სესიის შუაში მოსული ავტომატური განახლება, ან ისეთი release, რომლისთვისაც შენი plugin-ები მზად არ არის, უფრო ძვირი ჯდება, ვიდრე ხელით ვერსიის ორი წუთი. თუ სერვერი იმდენად დატვირთულია, რომ განახლების დროს მნიშვნელობა აქვს, გამოაცხადე ფანჯარა, განაახლე და გახსნამდე პირდაპირი კავშირით გამოსცადე. რა უნდა გააკეთო, როცა მოდის განახლება ყველაფერს არღვევს ზოგადი დისციპლინაა.
backup-ები, რომლებიც ღირს
BeamMP-ში world save არ არსებობს, რაც backup-ებს პატარას და გამოსატოვებლად ადვილს ხდის. ის, რისი თავიდან ჩამოტვირთვაც არ შეგიძლია, არის ServerConfig.toml, ყველაფერი Resources/Server-ის ქვეშ (შენი plugin-ები და მათ მიერ შენახული მონაცემები) და Resources/Client-ში არსებული მოდების zip-ების ზუსტად ის კომპლექტი, რომელიც ამჟამად ერთად მუშაობს. /opt/beammp-ის ღამის tar-ი binary-ის გარეშე, მანქანიდან გარეთ გადაკოპირებული, ყველაფერს ფარავს. Backup-ები, რომლებიც ნამდვილად აღდგება განმარტავს, რატომ არის მანქანიდან გარეთ შენახვა სავალდებულო.
პრობლემების გადაჭრა Linux-ზე#
`error while loading shared libraries: liblua5.3.so.0`. runtime დამოკიდებულება აკლია. sudo apt install liblua5.3-0, მერე ისევ სცადე. არა-Debian დისტრიბუტივზე დააყენე იმ დისტრიბუტივის Lua 5.3 ბიბლიოთეკა ან ააწყვე წყაროდან.
`version 'GLIBC_2.xx' not found` ან `GLIBCXX` შეცდომები. ჩამოტვირთე binary უფრო ახალი დისტრიბუტივისთვის, ვიდრე გაქვს. შეამოწმე /etc/os-release და აიღე შესაბამისი ფაილი.
`Exec format error`. არქიტექტურის შეუსაბამობაა - arm64 binary x86_64-ზე ან პირიქით. შეამოწმე uname -m.
`Permission denied` გაშვებისას. ფაილი executable არ არის, ან საქაღალდის მფლობელი ის მომხმარებელი არ არის, რომელიც ამუშავებს. chmod +x BeamMP-Server და sudo chown -R beammp:beammp /opt/beammp.
სერვისი ვარდება "Start request repeated too quickly"-ით. სერვერი ყოველ გაშვებაზე გადის და systemd-მა ცდა შეწყვიტა. ნამდვილი მიზეზი journalctl -u beammp-ში რამდენიმე სტრიქონით ზემოთაა - თითქმის ყოველთვის auth key ან TOML სინტაქსის შეცდომა. გაასწორე, მერე sudo systemctl reset-failed beammp და ისევ გაუშვი.
სერვერი ხელით ეშვება, სერვისად - არა. ჩვეულებრივ WorkingDirectory აკლია ან არასწორია, ამიტომ სერვისი კონფიგურაციას ვერ პოულობს, ან root-მა ხელით გაშვებისას შექმნა ფაილები და beammp მომხმარებელს მათში ჩაწერა არ შეუძლია. ls -l /opt/beammp გეტყვის, რომელია; მეორეს chown ასწორებს.
მუშაობს, მოთამაშეები ვერ შედიან. შეამოწმე ss -tulpn ორივე პროტოკოლზე, მერე ufw status, მერე პროვაიდერის firewall. სერვერების სიაზე ეჭვის წინ გარედან პირდაპირი კავშირით გამოსცადე.
Address already in use. 30814 სხვას უჭირავს - ხშირად ეს არის ასლი, რომელიც სხვა ტერმინალში ხელით გაუშვი და დაგავიწყდა. ss -tulpn | grep 30814 პროცესს დაასახელებს.
სერვერი შეცდომის გარეშე ჩერდება. პატარა VDS-ზე ხშირად ეს kernel-ის OOM killer-ია, ჩვეულებრივ მანქანაზე სხვა რამის გამო. journalctl -k | grep -i oom ადასტურებს. Linux swap და OOM killer განმარტავს, რა გააკეთო.
გაშვება RE:NODE-ზე#
ყველაფერი ზემოთქმული ეხება ნებისმიერ Linux მანქანას, რომელსაც აკონტროლებ, მათ შორის i9-9900K VDS ხაზს, რომელიც ხელით 24 საათში მზადდება და გონივრული სახლია, თუ BeamMP-ის გაშვება გინდა შენს სხვა სერვისებთან ერთად.
თუ მხოლოდ BeamMP სერვერი გჭირდება, BeamMP game ხაზი Linux-ის ნაწილს შენ მაგივრად აკეთებს: სერვერი იქმნება გადახდის დადასტურებისას, პორტი ორივე პროტოკოლზე გამოიყოფა, ServerConfig.toml ბრაუზერის ფაილ მენეჯერში რედაქტირდება, ხოლო მოდ-პაკეტები SFTP-ით იტვირთება. ეს იმ თამაშებიდანაა, რომლებსაც შენი საკუთარი credential სჭირდება, ამიტომ ინსტალაცია Setup ჩანართზე ელოდება, სანამ Keymaster key-ს ჩასვამ. მეხსიერების ლიმიტზე კონტეინერი ჩერდება და სუფთად გადაიტვირთება და არა swap-ზე გადადის, ხოლო სერვერი, რომელიც არაერთხელ იკრაშება, გაფრთხილებასა და ticket-ს ქმნის. VDS-თან შედარებით იკარგება root წვდომა და დისტრიბუტივის არჩევანი, რაც BeamMP-ისთვის იშვიათად აქვს მნიშვნელობა.
FAQ#
რომელი BeamMP-Server ფაილი ჩამოვტვირთო Ubuntu 24.04-ისთვის?
BeamMP-Server.ubuntu.24.04.x86_64 ჩვეულებრივ Intel ან AMD აპარატურაზე, ან BeamMP-Server.ubuntu.24.04.arm64 ARM-ზე. uname -m გეტყვის, რომელია; aarch64 ნიშნავს arm64 ფაილს.
მუშაობს თუ არა BeamMP Linux-ზე Wine-ის გარეშე?
დიახ. BeamMP-Server native Linux პროგრამაა, ოფიციალური build-ებით Debian-სა და Ubuntu-ზე. BeamNG.drive მხოლოდ მოთამაშეებს სჭირდებათ, სერვერი მას არასდროს უშვებს.
რატომ ამთავრებს სერვერი მუშაობას პირველი გაშვებისთანავე?
იმიტომ, რომ ახლახან ჩაწერა ნაგულისხმევი ServerConfig.toml ცარიელი AuthKey-ით. დაამატე key Keymaster-იდან და ისევ გაუშვი. თუ მაინც გადის, ლოგის სტრიქონი გეტყვის, key არის მიზეზი თუ TOML სინტაქსი.
შემიძლია ერთ მანქანაზე ერთზე მეტი BeamMP სერვერის გაშვება?
დიახ. თითოეულს მიეცი საკუთარი საქაღალდე, საკუთარი Port კონფიგურაციაში, საკუთარი auth key, საკუთარი unit ფაილი და firewall წესების საკუთარი წყვილი. განლაგებას აღწერს რამდენიმე game server ერთ VDS-ზე.
admin ბრძანებებისთვის კონსოლი გამოვიყენო თუ Lua?
systemd-ის ქვეშ კონსოლი არაფერზეა მიბმული, ამიტომ პრაქტიკაში kick-ებს, ban-ებსა და განცხადებებს Lua plugin-ები უზრუნველყოფს. კონსოლი ხელით ტესტირებისთვის დატოვე.
განახლდება თუ არა BeamMP-Server თავისით?
არა. შეუძლია შეგახსენოს, რომ ახალი ვერსია არსებობს, მაგრამ binary-ის ჩანაცვლება შენი საქმეა. ეს გაჩერება, ჩამოტვირთვა და გაშვებაა, და ხელით გაკეთება ღირს.
