txAdmin-ის გზამკვლევი: ადმინები, რესტარტები, ბანები და backup-ები

txAdmin არის ვებ პანელი, რომელიც ჩაშენებულია FXServer-ის ყველა artifact-ში: სერვერს +exec server.cfg-ის გარეშე უშვებ, ხსნი პორტს 40120, შეგყავს კონსოლში დაბეჭდილი PIN და გაქვს მთავარი ანგარიში, რომელიც აკონტროლებს სერვერს, მის რესტარტებს, მოთამაშეთა ბაზას და ადმინებს. უმეტესი სერვერი აქ ჩერდება და txAdmin-ის მხოლოდ მეათედს იყენებს. FiveM-ის community-ის პირველ წელს გადარჩენას ხშირად გადაწყვეტენ მოსაწყენი რამეები: ვიწრო უფლებების მქონე ადმინის ანგარიშები, გაფრთხილებებიანი რესტარტის განრიგი, ბანები, რომლებიც სახელის გარდა ტექნიკასაც ამოიცნობს, backup-ში მოხვედრილი txData საქაღალდე და ვებ პანელი, რომელიც სუსტი პაროლით მთელი ინტერნეტისთვის ღია არ არის.

ეს გზამკვლევი ვარაუდობს, რომ სერვერი უკვე გაქვს. ლიცენზიის გასაღების აღება, FXServer-ის დაყენება და server.cfg-ის დაწერა აღწერილია სტატიაში FiveM სერვერის დაყენება txAdmin-ით. აქ თემა თვითონ txAdmin-ია, გვერდ-გვერდ, მნიშვნელოვანი პარამეტრებით და იმ შეცდომებით, რომლებმაც ადამიანებს ban-სია დააკარგვინა.

რა არის txAdmin და სად დგას#

txAdmin არც resource-ია და არც ცალკე პროგრამა. 2020 წლის დასაწყისიდან ის FXServer-ში მოდის, და როცა FXServer-ი გასაშვები კონფიგურაციის გარეშე ირთვება, ის txAdmin-ს უშვებს, რომელიც შემდეგ FXServer-ს შვილობილი პროცესის სახით შენი კონფიგურაციით ამუშავებს. ეს მოწყობა მთელი არსია: txAdmin თამაშის სერვერის გარეთ დგას, ამიტომ შეუძლია შეამჩნიოს, რომ სერვერი გაიჭედა ან დაკრაშდა, გათიშოს და თავიდან ჩართოს, და რესტარტებს შორისაც შეინახოს ყველა მოთამაშის ჩანაწერი.

რას აკეთებს, ერთ სიაში:

• აყენებს სერვერებს recipe-ებით, მათ შორის სრულ framework-ის ინსტალაციას ბაზასთან ერთად.
• რესტარტს უკეთებს სერვერს განრიგით, თამაშში გაფრთხილებებით, და ავტომატურად crash-ის ან გაჭედვის შემდეგ.
• ინახავს საკუთარ მოთამაშეთა ბაზას, რომელიც MySQL კი არა, ფაილია: იდენტიფიკატორებით, თამაშის დროით, შენიშვნებით, გაფრთხილებებით და ბანებით.
• Whitelist-ს უკეთებს Discord-ის წევრობით, Discord-ის როლით, დამტკიცებული ლიცენზიით ან მხოლოდ ადმინებისთვის.
• აშვებს Discord ბოტს სტატუსის ცოცხალი embed-ით და whitelist ბრძანებით.
• აჩვენებს ცოცხალ კონსოლს, CPU-სა და მეხსიერების გრაფიკებს, tick-ის დროის დიაგრამას და სერვერის აქტივობის ჟურნალს.
• გვთავაზობს თამაშშიდა მენიუს (/tx) ადმინებისთვის: NoClip, teleport, spectate, freeze, heal, ტრანსპორტის ხელსაწყოები, ბანები და გაფრთხილებები.
• ასწორებს `server.cfg`-ს ბრაუზერში, ვალიდატორით.

ის ACE უფლებებს არ ცვლის. txAdmin-ის ადმინი მართავს ვებ პანელს და თამაშშიდა მენიუს; ACE მართავს თამაშშიდა ბრძანებებს და resource-ებს. ეს ორი ცალკე სისტემაა, და მათ დაკავშირებას განმარტავს Discord-ის უფლებების გზამკვლევი.

პირველი ჩართვა, PIN და მთავარი ანგარიში#

პირველ გაშვებაზე txAdmin ქმნის თავის მონაცემთა საქაღალდეს, იკავებს TCP 40120-ს და ბეჭდავს ოთხნიშნა PIN-ს და მისამართს გასახსნელად:

[txAdmin] Use the PIN below to register:[txAdmin]     1234[txAdmin] Open http://203.0.113.10:40120/ in your browser.

ანგარიშის შექმნამდე PIN ერთადერთი რამ არის, რაც სამყაროს შენი სერვერის ფლობისგან გიცავს. ნებისმიერს, ვისაც პორტ 40120-ზე წვდომა აქვს და PIN-ის წაკითხვა შეუძლია, მთავარი ანგარიშის მიტაცება შეუძლია, ამიტომ რეგისტრაცია დაუყოვნებლივ გააკეთე და ახალი სერვერი ღამით setup ეკრანზე არ დატოვო.

რეგისტრაცია ორ გზას გთავაზობს: დააკავშირე შენი Cfx.re ანგარიში (ის, რასაც ფორუმზე და keymaster-ზე იყენებ) ან შექმენი მომხმარებლის სახელი და პაროლი. მთავარი ანგარიშისთვის Cfx.re-ის დაკავშირება უკეთესია, რადგან txAdmin-ს შენი FiveM იდენტიფიკატორიც გადაეცემა, რომელიც თამაშშიდა მენიუს შენს ამოსაცნობად სჭირდება. სარეზერვო პაროლის დაყენება ანგარიშზე მოგვიანებითაც შეგიძლია.

აქ შექმნილი ანგარიში არის master. ის ზუსტად ერთია. მას ყველა უფლება აქვს, სხვა ადმინები მას ვერ წაშლიან, და ის ერთადერთი ანგარიშია, რომელსაც სხვა ადმინების უფლებების შეცვლა შეუძლია იმის გარეშეც, რომ თავად all_permissions ან manage.admins ჰქონდეს. მიუდექი როგორც root პაროლს: ერთი ადამიანი, ძლიერი მონაცემები, არასოდეს გაზიარებული.

რეგისტრაციის შემდეგ მოდის setup wizard. სერვერს ასახელებ და არჩევ დეპლოიმენტის ტიპს: პოპულარული recipe, დაშორებული recipe-ის URL, ჩასმული საკუთარი recipe ან არსებული სერვერის მონაცემები (server-data საქაღალდე, რომელიც უკვე გაქვს). ზუსტი წარწერები ვერსიებს შორის შეიცვალა, მაგრამ ეს ოთხი გზა სტაბილური იყო. არსებული სერვერისთვის მიუთითე საქაღალდე და მისი server.cfg, და txAdmin დანარჩენს თავის თავზე აიღებს.

მთავარი ანგარიში დაიკარგა

თუ master-ის პაროლი დაკარგულია და Cfx.re ანგარიში დაკავშირებული არ არის, გავრცელებული აღდგენა უხეშია. გააჩერე სერვერი, წაშალე txData/admins.json (ასლი შეინახე) და თავიდან გაუშვი; txAdmin ადმინებს ვერ პოულობს, ახალ PIN-ს ბეჭდავს და ახალ master-ს არეგისტრირებ. ამ ფაილთან ერთად ყველა სხვა ადმინის ანგარიშიც იკარგება, ამიტომ მათ მერე თავიდან ქმნი. სერვერი ჯერ გააჩერე: txAdmin ადმინთა სიას მეხსიერებაში ინახავს და უკან წერს, ამიტომ მუშაობისას ფაილში შეტანილი ცვლილებები ზემოდან გადაიწერება. Cfx.re ფორუმზე მოხსენებები გვიჩვენებს, რომ ქცევა ყველა ვერსიაში ერთნაირი არ ყოფილა, ამიტომ თუ აღწერილივით არ მუშაობს, მიმდინარე txAdmin დოკუმენტაცია გადაამოწმე.

ადმინები და უფლებები#

ყველა მოდერატორს საკუთარი txAdmin ანგარიში უნდა ჰქონდეს. გაზიარებული ლოგინები ანადგურებს იმას, რაც txAdmin-ს ყველაზე კარგად გამოსდის: მოქმედებების ჟურნალს, რომელიც გვეუბნება ვინ დააბანა ვის, ვინ გადატვირთა სერვერი შაბათს 21:00-ზე და ვინ გაუშვა კონსოლის ბრძანება.

ადმინებს ქმნის master ან ნებისმიერი, ვისაც manage.admins აქვს, Admins გვერდზე. თითოეულ ანგარიშს აქვს სახელი, არასავალდებულოდ დაკავშირებული Cfx.re და Discord ID, და უფლებების ნაკრები. უფლებების ID-ები ისე, როგორც txAdmin ინახავს:

და მოთამაშეებისა და მენიუს უფლებები:

უფლებები ინახება txData/admins.json-ში. გონივრული დანაწილება როლურ სერვერზე:

• სატესტო მოდერატორები: players.warn, players.kick, players.direct_message, players.spectate, menu.viewids. საკმარისია პრობლემასთან იმ წამს გასამკლავებლად, მაგრამ არა მუდმივი შედეგის შესაქმნელად.
• მოდერატორები: ზემოთქმული, ასევე players.ban, players.whitelist, players.freeze, players.teleport, players.heal, players.playermode და server.log.view, რომ მოქმედებამდე შეამოწმონ რა მოხდა.
• ადმინისტრატორები: ზემოთქმული, ასევე control.server, commands.resources, announcement, console.view და settings.view.
• დეველოპერები: console.view, console.write, commands.resources, server.cfg.editor. დეველოპერებს ბანის გაცემა იშვიათად სჭირდებათ.

ორ უფლებას სიფრთხილე სჭირდება. console.write ფაქტობრივად სრული კონტროლია: სერვერის კონსოლს შეუძლია resource-ების გაჩერება, convar-ების შეცვლა და ყველაფრის გაშვება, რასაც resource ბრძანებად ხსნის. server.cfg.editor-ს შეუძლია შეცვალოს ლიცენზიის გასაღები, ბაზასთან დაკავშირების სტრიქონი და ACE სია, ანუ ნებისმიერს შეუძლია თამაშშიდა უფლებები მისცეს. ეს ორი მხოლოდ იმას მიეცი, ვისაც master პაროლსაც მისცემდი. players.troll დაახლოებით ერთი კვირა სახალისოა და მერე საჩივრის თემა ხდება; უმეტესი სერიოზული სერვერი ამას ყველასთვის გამორთულს ტოვებს.

თამაშშიდა მენიუს მუშაობისთვის ადმინის ანგარიშს Discord ან Cfx.re იდენტიფიკატორი უნდა ჰქონდეს დაკავშირებული. ორივეს გარეშე /tx მათთვის არაფერს აკეთებს, და ეს არის ყველაზე გავრცელებული „მენიუ გაფუჭებულია“ შეტყობინება. ვიწრო წვდომის ზოგადი არგუმენტი იგივეა, რაც სტატიაშია subuser-ები და მინიმალური პრივილეგიები.

Recipe-ები და deployer#

Recipe არის YAML ფაილი, რომელიც deployer-ს ეუბნება, როგორ ააგოს სერვერი: რა ჩამოტვირთოს, სად ჩადოს, რომელი SQL გაუშვას და რა ჩაწეროს server.cfg-ში. setup wizard-ის პოპულარული recipe-ები (cfx-default, ESX, QBCore და სხვა) საჯარო repository-შია, და შეგიძლია საკუთარიც დაწერო სერვერისთვის, რომელსაც ხშირად აღადგენ.

$engine: 3$minFxVersion: 5181$onesync: onname: Longship baseversion: 1.0.0author: Longship staffdescription: Default resources plus our own core pack.tasks:  - action: download_github    src: https://github.com/citizenfx/cfx-server-data    subpath: resources    dest: ./resources/[cfx-default]  - action: download_file    url: https://example.com/longship-core.zip    path: ./tmp/core.zip  - action: unzip    src: ./tmp/core.zip    dest: ./resources/[core]  - action: connect_database  - action: query_database    file: ./resources/[core]/install.sql  - action: write_file    file: ./server.cfg    data: |      endpoint_add_tcp "{{serverEndpoints}}"      endpoint_add_udp "{{serverEndpoints}}"      sv_maxclients {{maxClients}}      sv_licenseKey "{{svLicense}}"      set mysql_connection_string "{{dbConnectionString}}"      ensure [cfx-default]      ensure [core]  - action: remove_path    path: ./tmp

ზემოთ მოცემული $engine, $minFxVersion და build ნომრები საილუსტრაციოა; მიმდინარე მნიშვნელობები txAdmin repository-ში recipe-ების დოკუმენტაციიდან აიღე. task-ების action-ები ფიქსირებული ნაკრებია: download_github, download_file, unzip, move_path, copy_path, remove_path, ensure_dir, write_file, replace_string, connect_database, query_database და load_vars. ცვლადები, როგორიცაა {{svLicense}}, {{dbConnectionString}}, {{serverEndpoints}} და {{maxClients}}, deployer-ში შენ მიერ შეყვანილი მონაცემებით ივსება.

Recipe-ები დეპლოიმენტის საქაღალდეშია გამოკეტილი, ამიტომ recipe ვერ გადააწერს admins.json-ს ან სხვა რამეს მის გარეთ. ეს ზიანს ზღუდავს, მაგრამ უცნობი ადამიანის recipe-ს უსაფრთხოს არ ხდის: ის მაინც ჩამოტვირთავს და გაუშვებს ყველა resource-ს, რომელსაც ასახელებს, და ისინი სერვერის მხარეს სრული წვდომით მუშაობენ. მესამე მხარის recipe დეპლოიმენტამდე წაიკითხე, ისევე როგორც resource-ს წაიკითხავდი. recipe საწყისი წერტილია და არა framework-ის არჩევანი; რომელი გინდა, ამის გადასაწყვეტად framework-ების შედარება უკეთესი ადგილია.

თუ დეპლოიმენტი შუაში ჩავარდა, ჩვეულებრივი მიზეზებია GitHub-ის rate limit (recipe-ებმა, სადაც ბევრი download_github task-ია, ref უნდა დააფიქსირონ), ბაზა, რომელსაც deployer ვერ წვდება, ან გადასული ჩამოტვირთვის ბმული. deployer-ის ჟურნალი ჩავარდნილ task-ს ასახელებს; მიზეზი გამოასწორე და თავიდან დეპლოი ცარიელ საქაღალდეში გააკეთე.

ცოცხალი კონსოლი და სერვერის ჟურნალი#

Live Console გვერდი FXServer-ის საკუთარი გამოტანაა ბრაუზერში, ბრძანების ველით, ისტორიით და ძიებით. რასაც FXServer-ის ტერმინალში აკრეფ, აქაც მუშაობს: ensure myresource ერთი resource-ის გადასატვირთად, refresh ახალი resource საქაღალდის დასაფიქსირებლად, status დაკავშირებული მოთამაშეებისთვის. თითოეული გაგზავნილი ბრძანება მოქმედებების ჟურნალში იწერება იმ ადმინის სახელზე, ვინც გაგზავნა.

სერვერის ჟურნალი სხვა გვერდია და სხვა რამ: შესვლების, გასვლების, სიკვდილების, ჩატის, აფეთქებების და ადმინის მოქმედებების ქრონოლოგია. როცა ვინმე ბანს ასაჩივრებს, აქ ხედავ რა მოხდა ბანამდე, და სწორედ ამიტომ ღირს server.log.view-ის მიცემა მოდერატორებისთვის, რომლებიც ბანებს გასცემენ.

დაფის წარმადობის გრაფიკი აჩვენებს, რამდენს ანდომებს სერვერის მთავარი thread თითო tick-ზე, ჯგუფებად დაყოფილს, მოთამაშეთა რაოდენობასთან ერთად. ეს resource-ის პრობლემის ტევადობის პრობლემისგან გასარჩევად ყველაზე სწრაფი გზაა, და სათანადოდ განხილულია resmon-ისა და წარმადობის გზამკვლევში. კონსოლის კითხვა ზოგად უნარს ეხება: ხმაურიდან მნიშვნელოვანი ხაზების ამოღებას.

დაგეგმილი რესტარტები და crash-ის დამუშავება#

FXServer-ი და მასზე დაშენებული framework-ები კვირების განმავლობაში მუშაობისთვის არ არის შექმნილი. მეხსიერება იზრდება, entity-ების რაოდენობა გადახრილია, და რესტარტი ყოველ რამდენიმე საათში ჩვეულებრივი პრაქტიკაა ნებისმიერ დატვირთულ როლურ სერვერზე. txAdmin-ის Restarter პარამეტრები დროების სიას იღებს 24-საათიან HH:MM ფორმატში:

Restart schedule: 06:00, 14:00, 22:00

დროები მასპინძელი მანქანის დროის სარტყელშია, რომელიც ქირავნობით სერვერზე ხშირად შენი არ არის. განრიგს სანამ ენდობი, txAdmin-ის დაფაზე ნაჩვენები საათი შეამოწმე. ყოველი დაგეგმილი რესტარტის წინ txAdmin თამაშში აცხადებს 30, 15, 10, 5, 4, 3, 2 და 1 წუთზე, და იმავე ნიშნულებზე გასცემს txAdmin:events:scheduledRestart event-ს secondsRemaining მნიშვნელობით. Framework-ები და inventory resource-ები ამ event-ს და txAdmin:events:serverShuttingDown-ს უსმენენ, რომ პროცესის დასრულებამდე მოთამაშეთა მონაცემები შეინახონ, და სწორედ ამიტომ არის txAdmin-ის რესტარტი უსაფრთხო, გარედან kill კი არა.

AddEventHandler('txAdmin:events:scheduledRestart', function(data)  if data.secondsRemaining == 60 then    -- ერთი წუთი დარჩა: ყველა ახლავე შეინახე    TriggerEvent('longship:saveAllPlayers')  endend)

ადმინს შეუძლია დაფიდან შემდეგი დაგეგმილი რესტარტი გამოტოვოს, როცა ღონისძიება გაიწელა; გამოტოვება ცხადდება txAdmin:events:scheduledRestartSkipped-ით. რესტარტის დროები შენი პიკის გარშემო აირჩიე და არა მის შიგნით. რესტარტის განრიგები, რომლებიც ეხმარება მათ არჩევას განიხილავს.

Crash-ის დამუშავება ავტომატურია. თუ FXServer-ი გამოვა, txAdmin მას თავიდან უშვებს. თუ სერვერი პასუხს წყვეტს (მთავარი thread დაბლოკილია, heartbeat გაჩუმებულია), txAdmin timeout-ის შემდეგ ანადგურებს და თავიდან ჩართავს. თუ სერვერი გაჭედვის გამო განმეორებით რესტარტდება, timeout-ს ნუ გაზრდი: რაღაც მთავარ thread-ს წამებით ბლოკავს, და გამოსწორება მისი პროფილირებაა.

RE:NODE-ზე პანელის Schedules ტაბს შეუძლია backup-ებისა და power action-ების გაშვება cron გამოსახულებით. FiveM-ისთვის რესტარტები txAdmin-ს დაუტოვე, პანელის განრიგი კი ღამის backup-ისთვის გამოიყენე, txAdmin-ის რესტარტიდან რამდენიმე წუთის შემდეგ, როცა ბაზა მშვიდადაა.

მოთამაშეები, გაფრთხილებები და ბანები#

txAdmin იწერს ყველა მოთამაშეს, ვინც უკავშირდება, ყველა იდენტიფიკატორით, რასაც კლიენტი გვთავაზობს: license, discord, fivem, steam (თუ Steam ჩართულია), live, xbl და IP. ასევე იწერს ტექნიკის token-ებს (HWID), რომლებიც ნებისმიერ ანგარიშზე რთულად იცვლება. მოთამაშეთა ბაზა txData-ის შიგნით ფაილია და არა MySQL, ამიტომ ბაზის გარეშეც მუშაობს და framework-ის შეცვლას უძლებს.

მოთამაშეზე დაჭერა მის ჩანაწერს ხსნის: თამაშის დრო, პირველად და ბოლოს ნანახი, ყველა იდენტიფიკატორი, პერსონალის დატოვებული შენიშვნები, გაფრთხილებებისა და ბანების ისტორია. შენიშვნებს ნაკლებად აფასებენ: შენიშვნა „სიტყვიერად გააფრთხილეს VDM-ზე, 14 ოქტ“ ხელს უშლის იმას, რომ ერთი და იგივე საუბარი ოთხჯერ ოთხ სხვადასხვა მოდერატორთან მოხდეს.

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

ბანებს აქვს მიზეზი და ვადა: ერთ-ერთი წინასწარი ვარიანტი, საკუთარი ხანგრძლივობა ან მუდმივი. ბანი ეკვრის იდენტიფიკატორებს და, თუ ბანის პარამეტრებში HWID ბანი ჩართულია, ტექნიკის token-ებსაც, ამიტომ დაბანილი მოთამაშე, რომელიც ახალ Rockstar და Discord ანგარიშს შექმნის, მაინც ხვდება. ბოლო ვერსიებში შეგიძლია ბანის შაბლონები შეინახო (მიზეზისა და ვადის წყვილები, მაგალითად „Combat logging, 2 days“), რომ მოდერატორებმა ერთი და იგივე წესი ერთნაირად გამოიყენონ. ყოველ ბანს აქვს action ID, რომელსაც მოთამაშე უარყოფის შეტყობინებაში ხედავს, და სწორედ ამ ID-ს ასახელებს გასაჩივრებისას.

ბანები იხსნება მოთამაშის ჩანაწერიდან ან ისტორიის გვერდიდან, და მოხსნა იწერება მის შემსრულებელ ადმინზე. თუ ბანმა უდანაშაულო ადამიანი დაიჭირა, რომელიც ბანდადებულთან ერთ სახლს ან ტექნიკას იზიარებს, players.remove_ids საშუალებას აძლევს უფროს ადმინს ჩანაწერიდან კონკრეტული იდენტიფიკატორი ან HWID მოაშოროს ორიგინალის ბანის მოხსნის ნაცვლად.

txAdmin-ს საკუთარი ბაზის გასუფთავებაც შეუძლია: ხანგრძლივად არააქტიური მოთამაშეები და ძველი გაფრთხილებები, ბანები და whitelist ჩანაწერები, ბაზის პარამეტრებში. სერვერზე, სადაც ათიათასობით ერთჯერადი სტუმარია, ეს ფაილსა და მოთამაშეთა ძიებას სწრაფს ინარჩუნებს. გასუფთავება ჩანაწერებს სამუდამოდ შლის, ამიტომ ჯერ backup გააკეთე. თაღლითების შემდეგ დასჯის ნაცვლად დასაჭერად იხილე FiveM anticheat-ის ვარიანტები.

Whitelist-ის რეჟიმები და Discord ბოტი#

whitelist-ის რეჟიმებია Disabled, Admin-only, Discord server member, Discord server roles და Approved license. ისინი მოთამაშეთა მენეჯერის პარამეტრებშია, და მათი დაყენება Discord-ის როლებით, ბოტის token-ის, guild ID-ისა და members intent-ის ჩათვლით, ეტაპობრივად აღწერილია FiveM-ის Discord whitelist-ის გზამკვლევში. აქ დასამატებელია ორი წერტილი:

• Admin-only შენი ტექნიკური სამუშაოების ჩამრთველია. ჩართე განახლებამდე ან ბაზის შეკეთებამდე; უკვე დაკავშირებული მოთამაშეები რჩებიან, ახალებს ეუბნებიან, რომ სერვერი დახურულია. მერე უკან გადართე, რადგან დავიწყება ადვილია.
• Approved license ქმნის მოთხოვნას მოკლე ID-ით, როცა უცნობი მოთამაშე შესვლას ცდილობს. ადმინები, რომლებსაც players.whitelist აქვთ, მას Whitelist გვერდზე ან Discord ბოტით ამტკიცებენ. ვინმეს წინასწარ დამტკიცებაც შეგიძლია პირველ შესვლამდე.

Discord ბოტი სამ საქმეს აკეთებს, როგორც კი Settings, Discord Bot-ში მისი token და guild დაყენდება. ის აქვეყნებს სტატუსის embed-ს, რომელიც წუთში ერთხელ განახლდება მოთამაშეთა რაოდენობით, uptime-ითა და შემდეგი დაგეგმილი რესტარტით: არხში, სადაც გინდა, აკრიფე /status add და ბოტს ამ არხში Send Messages უფლება მიეცი. ის იღებს whitelist ბრძანებას მოთამაშეთა Discord-იდან დასამტკიცებლად. და შეუძლია მოთამაშის ინფორმაციის მოძიება. embed-ის შინაარსი და მისი ღილაკები (ხუთამდე, ჩვეულებრივ „Connect“ და „Rules“) JSON-ის სახით რედაქტირდება იმავე პარამეტრების გვერდზე. txAdmin შენახვისას ამ JSON-ს არ ამოწმებს, ამიტომ თუ embed-ი აღარ ახლდება, System Logs გვერდზე შეცდომა მოძებნე. ბოტების შესახებ ზოგადად მეტი წერია სტატიაში Discord ბოტები თამაშის სერვერის ადმინისტრირებისთვის.

txData: რა არის შიგნით და როგორ გავაკეთოთ backup#

txAdmin-ისთვის ცნობილი ყველაფერი ერთ საქაღალდეშია, txData, artifact-ისგან და შენი server-data-სგან განცალკევებით:

txData/  admins.json          admin accounts and their permissions  default/             the server profile    config.json        txAdmin settings (restarter, bot, whitelist...)    data/              player database, bans, warnings, whitelist    logs/              txAdmin, server and FXServer logs

პროფილის საქაღალდის შიგა სტრუქტურა მთავარ ვერსიებს შორის შეიცვალა, ამიტომ ხე გზამკვლევად აღიქვი და საკუთარ ასლს შეხედე. მთავარია, რომ მთელი საქაღალდე ერთი ერთეულია: backup ერთად გააკეთე, ერთად აღადგინე.

სად მდებარეობს ნაგულისხმევად, სწორედ ეს დეტალი აკარგვინებს ადამიანებს ban-სიებს. txAdmin 8-იდან ნაგულისხმევი არის ../txData FXServer-თან შედარებით Windows-ზე (artifact საქაღალდის გვერდით) და ../../../txData FXServer-ის binary-დან Linux-ზე, რაც ამოარქივებული artifact საქაღალდის შიგნით ხვდება. თუ Linux-ზე განახლებისას ამ საქაღალდეს მთლიანად ცვლი, txData მასთან ერთად მიდის. ან გადაიტანე და txAdmin ახალ მდებარეობაზე TXHOST_DATA_PATH გარემოს ცვლადით მიუთითე, ან ყოველ განახლებამდე ასლი გადაიღე.

ეს გარემოს ცვლადები txAdmin 8-ში გაჩნდა და ანაცვლებს ძველ გაშვების convar-ებს +set txDataPath, +set txAdminPort და +set txAdminInterface, რომლებიც ჯერ კიდევ მუშაობს, მაგრამ მოძველებულია. თუ ორივე დაყენებულია, TXHOST_ მნიშვნელობა იმარჯვებს.

backup, რომელსაც მნიშვნელობა აქვს, სამი ნაწილისგან შედგება: txData, server-data და ბაზა. სამივე გააკეთე artifact-ის ყოველ განახლებამდე, რადგან ახალმა txAdmin-მა შეიძლება მონაცემები ისე მიგრირებინოს, რომ ძველმა ვერ წაიკითხოს; განახლების პროცედურა თავად artifact-ების გზამკვლევშია. სერვერი გააჩერე, ან სულ მცირე რესტარტისას ნუ გააკეთებ backup-ს, რომ config.json და მოთამაშეთა ბაზა ჩაწერის შუაში არ მოხვდეს. მერე ერთხელ აღადგინე სატესტო ასლზე - backup, რომელიც არავის აღუდგენია, ჰიპოტეზაა, როგორც ამას განმარტავს backup-ები, რომლებიც ნამდვილად აღდგება.

RE:NODE-ზე პანელიდან გაკეთებული backup-ები მთელი სერვერის ფაილებს მოიცავს, txData-ს ჩათვლით, ინახება მანქანის გარეთ, შეიძლება დაიბლოკოს, რომ როტაციამ განახლებამდელი ასლი არასოდეს წაშალოს, და აღდგება ერთი ღილაკით. ბაზა თავის სლოტშია და საკუთარი ექსპორტი სჭირდება.

ვებ პანელის დაცვა#

txAdmin-ის ვებ ინტერფეისი უბრალო HTTP-ია 40120-ზე და ნაგულისხმევად ყველა ინტერფეისზე ბმება. ვებ პანელი, რომელსაც კონსოლის ბრძანებების გაშვება შეუძლია, მაღალი ღირებულების სამიზნეა, და ინტერნეტი სავსეა სკანერებით, რომლებმაც პორტის ნომერი იციან.

• გამოიყენე Cfx.re ლოგინი ან გრძელი, უნიკალური პაროლები. txAdmin-ს საკუთარი TOTP არ აქვს, ამიტომ ორფაქტორიანი ავტორიზაციით Cfx.re ანგარიში თითოეული ადმინისთვის ყველაზე ძლიერი ლოგინია.
• შეზღუდე პორტი. თუ firewall შენ გიკონტროლებია, 40120 მხოლოდ იმ მისამართებიდან დაუშვი, რომლებსაც შენი პერსონალი იყენებს, ან txAdmin TXHOST_INTERFACE-ით 127.0.0.1-ზე მიაბი და SSH tunnel-ით შედი. SSH tunnel-ები და პორტების გადამისამართება ერთსტრიქონიან ბრძანებას აჩვენებს, ხოლო firewall-ის წესები, რომლებსაც მნიშვნელობა აქვს დანარჩენს მოიცავს.
• თუ საჯარო უნდა იყოს, წინ HTTPS დააყენე. სერტიფიკატიანი reverse proxy პაროლებს ქსელში ღიად გავლას უშლის. რას აკეთებს reverse proxy მოწყობას განმარტავს.
• txAdmin არასოდეს გადაიტანო `30120`-ზე. ისედაც უარყოფილია; ეს თამაშის პორტია და FXServer-ს ეკუთვნის.
• ადმინებს გაუწყვიტე. როცა მოდერატორი მიდის, მისი ანგარიში იმავე დღეს წაშალე. მისი Discord როლი და ACE ჯგუფი ცალკეა, ამიტომ ისინიც მოაშორე.
• წაიკითხე მოქმედებების ჟურნალი. ყოველკვირეული თვალის გადავლება იმაზე, ვინ გაუშვა კონსოლის ბრძანება, როგორც შეცდომებს, ისე გატეხილ ანგარიშებს იჭერს.
• FXServer განახლებული გქონდეს. txAdmin-ის უსაფრთხოების გასწორებები artifact-ებშია, ამიტომ სამი თვით ჩამორჩენილი სერვერი პანელითაც სამი თვით ჩამორჩება.

იგივე მიდგომა ეხება ძველ RCON კონსოლს: rcon_password დაუყენებელი დატოვე, რადგან txAdmin ყველაფერს უკეთეს არხზე აკეთებს. ზოგადი შემთხვევა აღწერილია სტატიაში RCON-ის უსაფრთხო გამოყენება.

RE:NODE-ზე FiveM გეგმებს ორი პორტის გამოყოფა მოჰყვება, და როცა txAdmin-ს საკუთარი პორტი სჭირდება, მეტის დამატება Network ტაბზე შეიძლება. ჰოსტინგ პანელის საკუთარი subuser-ები ცალკე ფენაა: მოდერატორს მხოლოდ txAdmin-ზე მიეცი წვდომა, პანელზე წვდომა (ფაილები, SFTP, backup-ები) კი იმათთვის შეინახე, ვისაც სხვაგვარად master ანგარიში დასჭირდებოდა.

პრობლემების მოგვარება#

PIN არ ჩანს. სერვერი +exec server.cfg-ით ირთვება, რაც txAdmin-ს მთლიანად გამოტოვებს. ამოიღე გაშვების ბრძანებიდან. თუ txData-ში ადმინი უკვე არის, PIN-იც არ იქნება: txAdmin პირდაპირ ლოგინის გვერდზე გადადის.

txAdmin გვერდი არ იტვირთება. TCP 40120 გარედან მიუწვდომელია, ან txAdmin 127.0.0.1-ზეა მიბმული. შეამოწმე ჩატვირთვისას დაბეჭდილი მისამართი და პორტი სხვა ქსელიდან გამოსცადე.

თამაშშიდა მენიუ არაფერს აკეთებს. ადმინის ანგარიშს Discord ან Cfx.re იდენტიფიკატორი დაკავშირებული არ აქვს, ან იდენტიფიკატორი არ ემთხვევა იმას, რასაც კლიენტი აგზავნის. მოთამაშის ჩანაწერში შეამოწმე, რომელი იდენტიფიკატორებით უკავშირდება რეალურად.

პარამეტრები და ადმინები განახლების შემდეგ გაქრა. txAdmin სხვა, ცარიელ txData-ს კითხულობს, ჩვეულებრივ იმიტომ, რომ Linux-ზე artifact საქაღალდე ჩანაცვლდა. აღადგინე საქაღალდე ან TXHOST_DATA_PATH მასზე მიუთითე.

დაგეგმილი რესტარტები არასწორ საათზე ხდება. მასპინძლის დროის სარტყელი შენსას განსხვავდება. დროები txAdmin-ის ნაჩვენებ საათზე გადათვალე.

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

Discord embed-მა განახლება შეწყვიტა. embed-ის JSON არასწორია, ან ბოტმა ამ არხში Send Messages უფლება დაკარგა. System Logs გვერდი შეცდომას ასახელებს.

FAQ#

რომელ პორტს იყენებს txAdmin?

ნაგულისხმევად TCP 40120. შეცვალე გარემოს ცვლადით TXHOST_TXA_PORT txAdmin 8-სა და უფრო ახალში, ან უფრო ძველი txAdminPort convar-ით ადრეულ ვერსიებზე. ის თამაშთან ერთად 30120-ს ვერ გაიზიარებს.

რამდენი მთავარი ანგარიში შეიძლება ჰქონდეს txAdmin-ს?

ერთი. სხვა ადმინებს შეიძლება all_permissions მიეცეს, რაც ყველა მოქმედებას იძლევა, მაგრამ master ანგარიში უნიკალურია და აღდგენა სწორედ მასზეა დამოკიდებული. მისი მონაცემები ერთ ადამიანთან და პაროლების მენეჯერში შეინახე.

სჭირდება თუ არა txAdmin-ს MySQL?

არა. მისი მოთამაშეთა ბაზა, ბანები, გაფრთხილებები და whitelist ფაილებში ინახება txData-ის შიგნით. შენს framework-ს მაინც სჭირდება საკუთარი ბაზა; txAdmin მას არ იყენებს.

ზიარდება თუ არა txAdmin-ის ბანები სერვერებს შორის?

ავტომატურად არა. თითოეულ txData პროფილს საკუთარი მოთამაშეთა ბაზა აქვს, ამიტომ ერთ სერვერზე გაცემულ ბანს სხვა სერვერი ვერ ხედავს, თუ გარე ბანის სისტემას არ იყენებ ან იდენტიფიკატორით თავიდან არ გასცემ.

უსაფრთხოა თუ არა მოდერატორებისთვის კონსოლზე წვდომის მიცემა?

მხოლოდ წასაკითხი კონსოლის წვდომა, console.view, უმეტესი პერსონალისთვის კარგია. console.write ნებისმიერ სერვერის ბრძანებას აძლევს, resource-ების გაჩერების ჩათვლით, ამიტომ მხოლოდ იმას მიეცი, ვისაც master ანგარიშსაც ანდობდი.

რა ემართება მოთამაშეთა შეუნახავ მონაცემებს txAdmin-ის რესტარტისას?

txAdmin ჯერ მოთამაშეებს აფრთხილებს და გასცემს რესტარტისა და გათიშვის event-ებს, ამიტომ framework, რომელიც მათ უსმენს, ყველას ინახავს. txAdmin-ის გარედან მოკლული პროცესი გაფრთხილებას არ იღებს, და ყველაფერი, რაც ჯერ არ შენახულა, იკარგება.