FiveM-ის artifact-ები: FXServer-ის უსაფრთხო განახლება

FiveM სერვერის "artifact-ები" არის FXServer-ის build-ები, რომლებსაც Cfx.re აქვეყნებს runtime.fivem.net/artifacts/fivem/-ზე, ერთი სია Linux-ისთვის და ერთი Windows-ისთვის, თითოეულში მონიშნულია რეკომენდებული build და უფრო ახალი არჩევითი. გაუშვი რეკომენდებული build, განაახლე, როცა ის წინ წავა ან როცა framework ან escrow resource რაიმე უფრო ახალს ითხოვს, და ყოველთვის ისე განაახლე, რომ ახალი build ძველის გვერდით დადო და არა მის თავზე, რომ უკან დაბრუნება საქაღალდის სახელის შეცვლა იყოს. txAdmin artifact-ის შიგნით მოდის, ამიტომ მასთან ერთად ახლდება. შენი server-data საქაღალდე, შენი მონაცემთა ბაზა და txAdmin-ის საკუთარი მონაცემების საქაღალდე არის ის, რისი backup-იც ყოველ განახლებამდე უნდა გააკეთო - binary ერთჯერადია. ეს გზამკვლევი ხსნის, რა არის FiveM სერვერის ოთხი ცალკე ვერსიის ნომერი, როგორ წაიკითხო artifact-ების სია, განახლების პროცედურას ორივე პლატფორმაზე, ტესტირებას და რა ქნა, როცა build რამეს აფუჭებს.

ოთხი ვერსია, რომლებიც დამოუკიდებლად მოძრაობს#

"სერვერის განახლება" სხვადასხვა რამეს ნიშნავს იმის მიხედვით, ვინ ამბობს. FiveM სერვერს ოთხი ფენა აქვს, თითოეულს საკუთარი ვერსიითა და საკუთარი განრიგით:

ეს პოსტი პირველ ორზეა. თამაშის build აფიქსირებს, GTA Online-ის რომელ განახლებაზე უნდა იყვნენ კლიენტები, და აღწერილია FiveM-ის server.cfg-ის ახსნაში. framework-ის განახლებები ცალკე დისციპლინაა, აღწერილი FiveM-ის framework-ების შედარებაში. ოთხის თავში ცალ-ცალკე შენახვის მიზეზი ის არის, რომ "განახლებამ სერვერი გამიფუჭა"-ს ისტორიების უმეტესობა ერთსა და იმავე საღამოს შეცვლილი ორი მათგანია, და ვერავინ ხვდება, რომელმა გააკეთა ეს.

მოთამაშის FiveM კლიენტი თავად ახლდება და შენი სერვერის build-ზე მიბმული არ არის. როცა Rockstar GTA V-ს პატჩავს, კლიენტი ზოგჯერ ყველასთვის გაფუჭებულია, სანამ Cfx.re არ დაეწევა; შენი სერვერი აქ არაფერ შუაშია და ვერაფერი, რასაც განაახლებ, ამას ვერ გაასწორებს.

artifact-ების სიის კითხვა#

artifact-ების ინდექსს ორი გზა აქვს:

Linux:   https://runtime.fivem.net/artifacts/fivem/build_proot_linux/master/Windows: https://runtime.fivem.net/artifacts/fivem/build_server_windows/master/

თითოეული გვერდი build-ებს ნომრით ჩამოთვლის, უახლესი პირველი, და ორ მათგანს გამოყოფს:

• Latest recommended. build, რომელსაც Cfx.re production-ისთვის სტაბილურად მიიჩნევს. სწორედ ამას უშვებ.
• Latest optional. უფრო ახალი, გამოსწორებებითა და ფუნქციებით, რომლებსაც ამდენი გამოცდა ჯერ არ გაუვლია. გაუშვი სატესტო სერვერზე, თუ მასში რამე გჭირდება.

ყველაფერი ამათ ქვემოთ უფრო ძველია. build-ები, რომლებიც რეკომენდებულს ბევრად ჩამორჩება, კონსოლში გაფრთხილებებს იღებს, და Cfx.re-მ წარსულში შეწყვიტა ისეთი ძველი build-ების მხარდაჭერა, რომლებიც უსაფრთხოების ან თავსებადობის პრობლემა იყო, ასე რომ "არასოდეს განაახლო" არც სტრატეგიაა. build-ის ნომერი სერვერის გაშვებისას იბეჭდება:

FXServer-master SERVER v1.0.0.12345 linux

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

Cfx.re სერვერის build-ების changelog-ებს თავის ფორუმსა და დოკუმენტაციაში აქვეყნებს. გადაათვალიერე ისინი შენს build-სა და სამიზნეს შორის დიაპაზონისთვის: შენი resource-ების მიერ გამოყენებული native-ების ცვლილებები, OneSync-ის ქცევა და txAdmin-ის ვერსიის ზრდა - ეს ის ხაზებია, რომლებსაც მნიშვნელობა აქვს.

როდის განაახლო#

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

• რეკომენდებული build წინ წავიდა და შენ რამდენიმეთი ჩამორჩები. დარჩი რეკომენდებულიდან რამდენიმე კვირის ფარგლებში; ძალიან ჩამორჩენა ერთ პატარა განახლებას დიდად აქცევს.
• resource ამას მოითხოვს. მიმდინარე ბიბლიოთეკები და framework-ები სერვერის მინიმალურ build-ს უთითებს - Overextended-ის resource-ები ამაში მკაცრია - ხოლო escrow resource-ებს შესამოწმებლად საკმარისად ახალი build სჭირდება.
• გამოსწორება, რომელიც გჭირდება. changelog-ში ჩამოთვლილი ავარია ან სინქრონიზაციის ხარვეზი, რომელიც იმას ემთხვევა, რასაც ხედავ.
• უსაფრთხოების გამოსწორება. წაიკითხე განცხადება და დროულად განაახლე.

და მიზეზები, რომლებიც არ ღირს: ფორუმის პოსტი, რომელიც ამბობს, რომ უახლესი არჩევითი build უფრო სწრაფია, ან ახალი ფუნქცია, რომელიც არ გჭირდება.

binary-ის განახლება#

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

Linux-ზე

ჩვეულებრივი სტრუქტურა binary-ს შენი მონაცემებისგან ცალკე ინახავს, ასე რომ binary შეიძლება მთლიანად ჩანაცვლდეს:

/home/fivem/  server/          the artifact - replaced on update  server-data/     resources, server.cfg - backed up, never replaced  txData/          txAdmin's settings, admins, players, bans

განახლება, ძველი build-ის ახლის გვერდით შენახვით:

$ cd /home/fivem$ wget -O fx.tar.xz "https://runtime.fivem.net/artifacts/fivem/build_proot_linux/master/<build>/fx.tar.xz"$ mkdir server-new && tar xf fx.tar.xz -C server-new# stop the server cleanly here, then:$ mv server server-old && mv server-new server$ cd server-data && bash ../server/run.sh +exec server.cfg

ზუსტი ჩამოტვირთვის ბმული artifact-ის გვერდიდან აიღე; თითოეულ build-ს საკუთარი საქაღალდის სახელი აქვს. თუ ახალი build ცუდად იქცევა, გააჩერე და საქაღალდეების სახელები უკან გაცვალე. server-old მხოლოდ მას შემდეგ წაშალე, რაც ახალი build რეალური მოთამაშეებით მთელ საღამოს გაუძლებს.

თუ სერვერს txAdmin-ით უშვებ, გაუშვი run.sh +exec-ის გარეშე, როგორც ადრე; txAdmin თავის მონაცემების საქაღალდეს პოულობს და FXServer-ს შენი კონფიგურაციით უშვებს.

Windows-ზე

Windows-ის artifact არის server.7z არქივი, რომელიც შეიცავს FXServer.exe-ს და მის ფაილებს. პროცედურა არსებითად იგივეა: ამოარქივე ახალი build ახალ საქაღალდეში, გააჩერე სერვერი, ძველ საქაღალდეს სახელი გადაარქვი, რომ გზიდან ჩამოეცალოს, ახალს მისი ადგილის სახელი დაარქვი და გაუშვი იმავე shortcut-ით ან batch ფაილით. არასოდეს ამოარქივო ახალი build მომუშავეს თავზე; გამოყენებაში მყოფი ფაილები არ ჩანაცვლდება, და ორი build-ის ნარევს მიიღებ, რომელიც უცნაური გზებით ფუჭდება.

პანელიან ჰოსტზე

Pterodactyl-ზე დაფუძნებულ პანელზე artifact სერვერის საკუთარ ფაილებში ცხოვრობს და ინსტალაციის სკრიპტით ჩამოიტვირთება. FiveM-ის egg-ები ჩვეულებრივ გასაშვებ build-ს Startup ჩანართზე ცვლადად აჩვენებს - ვერსიის ველი, რომელიც იღებს build-ის ნომერს ან საკვანძო სიტყვას, როგორიცაა recommended - ხოლო ინსტალაციის ან განახლების ნაბიჯი მას ჩამოტვირთავს. ვარაუდამდე შეხედე შენი სერვერის Startup ჩანართს, რომ ნახო, რას გთავაზობს.

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

txAdmin განახლებებს შორის#

txAdmin artifact-ის ნაწილია, ამიტომ ახალ build-ს ხშირად ახალი txAdmin მოაქვს. ის საკუთარ მონაცემებს artifact-ის გარეთ ინახავს - პარამეტრებს, ადმინის ანგარიშებს, მოთამაშეების ბაზას, ბანებს, გაფრთხილებებს, whitelist-ის დამტკიცებებს - txData საქაღალდეში (ან პანელის ან გაშვების სკრიპტის მიერ დაყენებულ ადგილას). ამ საქაღალდის დავიწყება ადვილია და დაკარგვა მტკივნეული: მისი დაკარგვა ნიშნავს შენი ბანების სიისა და ადმინის ანგარიშების დაკარგვას.

• გააკეთე `txData`-ს backup ყოველ განახლებამდე, server-data-სთან ერთად.
• მოელოდე ცალმხრივ მიგრაციებს. უფრო ახალმა txAdmin-მა შეიძლება თავისი შენახული მონაცემები პირველი გაშვებისას განაახლოს. ამის შემდეგ ძველ build-ზე დაბრუნებამ შეიძლება txAdmin მათი წაკითხვის უნარის გარეშე დატოვოს, ამიტომ უკან დაბრუნებამ txData-ს backup-იც უნდა აღადგინოს.
• წაიკითხე txAdmin-ის გამოშვების შენიშვნები, როცა მისი მთავარი ვერსია იცვლება. პარამეტრები გვერდებს შორის გადაადგილდება და ზოგჯერ მნიშვნელობას იცვლის; Discord-ის whitelist-ის პარამეტრები ბოლოდროინდელი მაგალითია, აღწერილი FiveM-ის Discord whitelist-სა და უფლებებში.

ტესტირება production-მდე#

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

1. გასცე მეორე ლიცენზიის key იმავე Cfx.re ანგარიშიდან. ამ ანგარიშის კუთვნილი escrow resource-ები ორივე key-ზე მუშაობს, როგორც FiveM-ის escrow და asset-ების ლიცენზირება ხსნის.
2. დააკოპირე `server-data` სატესტო სერვერზე და მიუთითე მონაცემთა ბაზის ასლზე, არასოდეს ცოცხალზე.
3. გაუშვი ახალი build იქ. გაუშვი, წაიკითხე კონსოლი თავიდან შეცდომებზე, შედი და გაიარე ნაწილები, რომლებსაც მოთამაშეები იყენებენ: პერსონაჟის შექმნა, ინვენტარი, სამუშაო, გარაჟი, მაღაზია.
4. გააკეთე პროფილირება. build-ის შეცვლამ შეიძლება წარმადობა შეცვალოს. შეადარე პროფილი ცოცხალ სერვერს მსგავსი დატვირთვისას, როგორც აღწერილია FiveM სერვერის წარმადობაში.
5. მხოლოდ ამის შემდეგ განაახლე production, მშვიდ საათზე, ძველი საქაღალდის შენახვით.

პატარა სერვერისთვის სატესტო გაშვება შეიძლება იყოს ცოცხალი სერვერი დილის 6 საათზე, txAdmin-ის whitelist-ით ერთი საათით admin-only-ზე. ეს მეორე სერვერივით კარგი არ არის, მაგრამ გაცილებით უკეთესია, ვიდრე პიკისას განახლება და სამოცი მაყურებლის თვალწინ შედეგის გაგება.

რას უყურო პირველ საღამოს

განახლება, რომელიც სუფთად ეშვება, დატვირთვისას მაინც შეიძლება ჩავარდეს. ახალ build-ზე პირველი დატვირთული საღამოს განმავლობაში თვალი ადევნე:

• hitch-ის გაფრთხილებებს კონსოლში. build, რომელმაც სინქრონიზაციის ან ქსელის ქცევა შეცვალა, პირველად აქ ჩანს, როგორც server, sync ან network thread-ის hitch-ები, რომლებიც ადრე არ იყო.
• txAdmin-ის tick-ის გრაფიკს. შეადარე ფორმა წინა საღამოს. ნელი tick-ების ახალი კუდი მოთამაშეების იმავე რაოდენობისას build-ია ან resource, რომელიც მასზე რეაგირებს.
• მეხსიერებას სესიის განმავლობაში. build-ის მიერ შემოტანილი გაჟონვა ნელა იზრდება; შეამოწმე გრაფიკი საღამოს დასაწყისში და ბოლოს.
• მოთამაშეების შეტყობინებებს კონკრეტულ ქმედებებზე. "ჩემი მანქანა გაქრა", "მაღაზიამ ჩემი ფული არ აიღო" - ეს მიუთითებს OneSync-ის ან native-ების ცვლილებებზე, რომლებიც მხოლოდ რეალური მოთამაშეების რეალური ქმედებებისას ჩანს.

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

განახლების საკონტროლო სია#

1. ჩაიწერე მიმდინარე build-ის ნომერი გაშვების ხაზიდან.
2. წაიკითხე changelog მასსა და სამიზნეს შორის.
3. გამოაცხადე ტექნიკური სამუშაოების ფანჯარა; დააყენე txAdmin-ის whitelist admin-only-ზე, თუ გინდა, რომ ტესტირებისას სერვერი დაკეტილი იყოს.
4. გააჩერე სერვერი სუფთად, რომ framework-მა მოთამაშეების მონაცემები შეინახოს.
5. გააკეთე server-data-ს, txData-სა და მონაცემთა ბაზის backup. ჩაკეტე backup, თუ შენი პანელი ამის საშუალებას იძლევა.
6. დადე ახალი build ძველის გვერდით და გაცვალე.
7. გაუშვი და წაიკითხე კონსოლი პირველი ხაზიდან ბოლო resource-მდე.
8. შედი და გამოცადე გზები, რომლებსაც მოთამაშეები ყველაზე ხშირად იყენებენ.
9. ხელახლა გახსენი სერვერი; უყურე კონსოლს და txAdmin-ის tick-ის გრაფიკს პირველი დატვირთული საღამოს განმავლობაში.
10. წაშალე ძველი build რამდენიმე უპრობლემო დღის შემდეგ.

ერთ ჯერზე ერთი ფენა შეცვალე. თუ framework-საც აქვს განახლება, სხვა დღეს გააკეთე. როცა რამე გაფუჭდება, მაშინ გეცოდინება, რომელმა ცვლილებამ გააფუჭა.

უკან დაბრუნება#

როცა ახალი build აფუჭებს რამეს, რასაც წუთებში ვერ გაასწორებ:

1. გააჩერე სერვერი.
2. გაცვალე საქაღალდეები უკან: server ახალი build-ის სახელს იღებს, server-old ხდება server.
3. თუ txAdmin-მა თავისი მონაცემები მიგრირა, აღადგინე txData განახლებამდელი backup-იდან.
4. თუ ახალ build-ზე მოთამაშეები გარკვეული დრო იყვნენ, გადაწყვიტე მონაცემთა ბაზის შესახებ: აღდგენა მას შემდეგ ყველაფერს კარგავს, შენარჩუნება კი ჩვეულებრივ ნორმალურია, რადგან მონაცემთა ბაზის სქემა framework-ს ეკუთვნის და არა FXServer-ს.
5. გაუშვი, დაადასტურე, რომ გაშვების ხაზი ძველი build-ის ნომერს აჩვენებს, და ხელახლა გახსენი.

შემდეგ ხელახლა ცდამდე გაარკვიე მიზეზი. მოძებნე ჩავარდნილი build-ის კონსოლის გამონატანში პირველი შეცდომა და არა ბოლო; წაიკითხე changelog იმ native-ებისთვის, რომლებსაც ჩავარდნილი resource იყენებს; ჰკითხე resource-ის ავტორს build-ის ნომრით ხელში. ამის ზოგადი ვერსია, სხვადასხვა თამაშისთვის, არის რა ქნა, როცა მოდის განახლება რამეს აფუჭებს.

პრობლემების მოგვარება განახლების შემდეგ#

resource ვერ ეშვება შეცდომებით დაკარგული ფუნქციის ან native-ის შესახებ. resource ეყრდნობა ქცევას, რომელიც შეიცვალა, ან მოითხოვს უფრო ახალ build-ს, ვიდრე დააყენე. შეამოწმე მისი მითითებული მინიმალური build.

escrow resource-ები ვერ იტვირთება. build escrow-ისთვის ზედმეტად ძველია, ან განახლება key-ის შეცვლას დაემთხვა. გაუშვი რეკომენდებული build და შეამოწმე key.

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

სერვერი ეშვება, მოთამაშეები უერთდებიან, და სინქრონიზაცია უარესია. OneSync-ის ქცევის ცვლილება. შეადარე ძველ build-ს სატესტო სერვერზე და შეატყობინე build-ის ნომრებით.

განახლების შემდეგ მოთამაშეები ვერ შედიან, მაგრამ სერვერი წესრიგში ჩანს. ჩვეულებრივ artifact-თან კავშირი არ აქვს: შეიცვალა server.cfg-ში იძულებით დაყენებული თამაშის build, ან რომელიმე resource შესვლის პროცესში ვარდება. წაიკითხე კონსოლი, სანამ ვინმე უერთდება.

FAQ#

რა არის FiveM სერვერის artifact-ები?

ეს არის Cfx.re-ის მიერ გამოქვეყნებული FXServer-ის build-ები, ერთი სია Linux-ისთვის და ერთი Windows-ისთვის. თითოეული build სრული სერვერის binary-ია ჩაშენებული txAdmin-ით. შენი resource-ები და კონფიგურაცია ცალკე ცხოვრობს და artifact-ის ნაწილი არ არის.

რეკომენდებული უნდა გამოვიყენო თუ FiveM-ის უახლესი build?

რეკომენდებული ნებისმიერი ცოცხალი სერვერისთვის. უფრო ახალი არჩევითი build-ები გამოსწორებებისა და ფუნქციების გამოსაცდელადაა, სანამ რეკომენდებული გახდება. გამოიყენე მხოლოდ მაშინ, როცა მასში არსებული რამე გჭირდება, და ჯერ გამოცადე.

რამდენად ხშირად უნდა განვაახლო FXServer?

იმდენად ხშირად, რომ რეკომენდებული build-იდან რამდენიმე კვირის ფარგლებში დარჩე, და ყოველთვის, როცა resource, რომელსაც ეყრდნობი, უფრო ახალს მოითხოვს. ყოველი build-ის გამოჩენისთანავე განახლებას სარგებელი არ აქვს.

სერვერის განახლება ჩემს resource-ებს წაშლის?

არა, თუ artifact-სა და server-data-ს ცალკე საქაღალდეებში ინახავ, როგორც ჩვეულებაა. artifact ჩანაცვლდება; შენს resource-ებს, server.cfg-სა და მონაცემთა ბაზას არავინ ეხება. მაინც გააკეთე მათი backup.

FXServer-ის განახლება txAdmin-საც ანახლებს?

დიახ. txAdmin artifact-ის შიგნით მოდის. მისი მონაცემების საქაღალდე განახლებას უძლებს, მაგრამ უფრო ახალმა txAdmin-მა შეიძლება ეს მონაცემები ისე მიგრიროს, რომ ძველმა ვერ წაიკითხოს, ამიტომ განახლებამდე backup გააკეთე.