PaperMC download API: Paper, Velocity და Folia jar-ების ჩამოტვირთვა სკრიპტით

თუ შენი სკრიპტი Paper-ს ჯერ კიდევ api.papermc.io/v2/...-დან იღებს, ის გაფუჭებულია: v2 API 2026 წლის 1 ივლისს გაუქმდა და მასზე ყოველი მოთხოვნა ახლა 410 Gone-ს აბრუნებს. შემცვლელი არის Fill API მისამართზე https://fill.papermc.io/v3/, და ცვლილება მცირეა, თუ იცი რა უნდა გააკეთო. მოთხოვნას უგზავნი /v3/projects/paper/versions/<version>/builds?channel=STABLE-ს, სიიდან პირველ build-ს იღებ, და JSON-ში გიბრუნდება fill-data.papermc.io-ზე მზა ჩამოტვირთვის ბმული sha256 საკონტროლო ჯამთან ერთად. გააგზავნე User-Agent, რომელიც შენს სკრიპტს ასახელებს და საკონტაქტო მონაცემს შეიცავს, შეამოწმე საკონტროლო ჯამი და დააფიქსირე ის build, რომელიც გამოსცადე, ახლის დევნის ნაცვლად. პოსტის დანარჩენი ნაწილი დეტალებია: ყველა საჭირო endpoint, არხების მნიშვნელობა, სრული განახლების სკრიპტი და შეცდომები, რომლებიც სერვერს ნახევრად ჩამოტვირთული jar-ით ტოვებს.

რა მოუვიდა api.papermc.io/v2-ს#

წლების განმავლობაში Paper-ის jar-ის ჩამოტვირთვის მისამართს ერთი კარგად ცნობილი ფორმა ჰქონდა და ათასობით სკრიპტს, Dockerfile-სა და სახელმძღვანელოს ის პირდაპირ ჰქონდა ჩაწერილი:

https://api.papermc.io/v2/projects/paper/versions/<ver>/builds/<build>/downloads/<file>.jar

მას სამი ნაწილისგან აგებდი - Minecraft-ის ვერსია, build-ის ნომერი და ფაილის სახელი, რომელიც ყოველთვის paper-<ver>-<build>.jar იყო - და თუ build უკვე იცოდი, API-სთვის წინასწარ არაფრის კითხვა არ გჭირდებოდა. ეს მოხერხებულობა აღარ არსებობს. PaperMC-მ ძველი სერვისი, სახელად Bibliothek, ახალით, Fill-ით, შეცვალა და v2 endpoint-ები გააუქმა. დღეს როგორც მეტამონაცემების endpoint-ები, ისე ძველი ჩამოტვირთვის მისამართები ასე პასუხობს:

HTTP/1.1 410 Gonesunset: Wed, 1 Jul 2026 00:00:00 GMT{"ok":false,"error":"sunset","message":"This API version has been sunset and isno longer available. To continue using the service, please upgrade to a supportedAPI version."}

გადამისამართება და გარდამავალი პერიოდი აღარ დარჩა. თუ სერვერის გაშვების სკრიპტი jar-ს ყოველ ჩართვაზე ჩამოტვირთავს, ან კონტეინერის იმიჯი Paper-ს აგების დროს იღებს, სიმპტომი ასეთია: wget ან უბრალო curl "წარმატებით" მუშაობს და შედეგად გრჩება 176 ბაიტიანი JSON ფაილი სახელად server.jar. შემდეგ Java უარს ამბობს მასზე შეტყობინებით Error: Invalid or corrupt jarfile server.jar, და ადამიანები Java-ს ვერსიებში ეძებენ მიზეზს, მისამართის ნაცვლად. curl -f (შეჩერდი HTTP შეცდომაზე) ამას ჩამოტვირთვის ეტაპზევე გასაგებ შეცდომად აქცევს, და ქვემოთ მოცემული სკრიპტი სწორედ ამით იწყებს.

ასევე გაითვალისწინე, რომ api.papermc.io/v3 არ არსებობს; ახალი API სხვა ჰოსტზე, fill.papermc.io-ზეა, ხოლო თვითონ jar-ები მესამეზე, fill-data.papermc.io-ზე. თუ შენს firewall-ს ან proxy-ს გამავალი ტრაფიკისთვის დაშვებული სია აქვს, სამივე სახელი შეიცვალა.

Fill v3-ის endpoint-ები#

v3 API პატარა REST ხეა ძველის ფორმით - პროექტები, ვერსიები, build-ები - და ყველგან JSON-ია. სკრიპტს რეალურად ეს მოთხოვნები სჭირდება:

ყველა მათგანი https://fill.papermc.io-ს მიეკუთვნება. პროექტის id-ებია paper, folia და velocity; გაუქმებული waterfall და travertine proxy-ები ძველი build-ების გამო მაინც ჩანს სიაში, მაგრამ მათთვის ახალი არაფერი ქვეყნდება.

პროექტის endpoint ვერსიებს ოჯახებად აჯგუფებს, ახალი ოჯახი პირველია და თითოეულ ოჯახში ახალი ვერსია პირველია:

{"project":{"id":"paper","name":"Paper"}, "versions":{"26.3":["26.3","26.3-rc-3"],             "26.2":["26.2","26.2-rc-2"],             "26.1":["26.1.2","26.1.1"],             "1.21":["1.21.11","1.21.11-rc3", "...", "1.21"]}}

ყურადღება მიაქციე ორ რამეს. Minecraft-ის საკუთარი ვერსიის ნომრები 2026 წელს წლის მიხედვით აგებულ სქემაზე გადავიდა, ამიტომ სია 26.3-დან 1.21.11-მდე და უფრო უკან მიდის, და ყველაფერი, რაც ვერსიებს სტრიქონებად ალაგებს, არასწორ რიგს მიიღებს. და release candidate-ები და pre-release-ები (26.3-rc-3, 1.21.11-pre5) რეალურ რელიზებთან ერთ სიაშია. სკრიპტი, რომელიც "სიის პირველ ვერსიას" იღებს, ერთ დღესაც release candidate-ს აიღებს. თუ ყველაზე ახალი რელიზის ავტომატურად აღება გინდა, გამოფილტრე id-ები, რომლებიც --ს შეიცავს - თუმცა, როგორც ქვემოთ იქნება ნათქვამი, Minecraft-ის ვერსიის ავტომატურად არჩევა ისედაც ცუდი იდეაა.

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

{"version":{"id":"1.21.4",            "support":{"status":"UNSUPPORTED","end":"2025-07-17"},            "java":{"version":{"minimum":21},                    "flags":{"recommended":["-XX:+UseG1GC", "..."]}}}, "builds":[232, 231, "..."]}

support.status გეუბნება, აგრძელებს თუ არა PaperMC ამ ვერსიის მხარდაჭერას (SUPPORTED ან UNSUPPORTED, დასრულების თარიღით), ხოლო java.version.minimum - რომელი Java სჭირდება jar-ს: 21 - 1.21 ხაზისთვის, 25 - 26.x რელიზებისთვის. სკრიპტს შეუძლია უარი თქვას ისეთი jar-ის დაყენებაზე, რომელსაც მანქანის Java ვერ გაუშვებს, და ეს გაცილებით მეგობრულია, ვიდრე გაშვებისას მიღებული UnsupportedClassVersionError. რეკომენდებული flag-ები ცნობილი G1-ის ნაკრებია; Minecraft JVM flags and Java versions განმარტავს, თითოეული რას აკეთებს.

build-ის ობიექტი ყველაფერს შეიცავს, რაც jar-ის ჩამოსატვირთად და შესამოწმებლად გჭირდება:

{"id":189, "time":"2026-10-14T20:17:18Z", "channel":"STABLE", "commits":[{"sha":"a48059a2...","message":"Correctly serialise decorated pod ..."}], "downloads":{"server:default":{    "name":"paper-26.3-189.jar",    "checksums":{"sha256":"3a90c2ea79a81cd0ce641c9954c616828be6d32255385aef3b2022f80b91e8b5"},    "size":55150184,    "url":"https://fill-data.papermc.io/v1/objects/3a90c2ea.../paper-26.3-189.jar"}}}

ჩამოტვირთვის გასაღები სამივე პროექტისთვის server:default-ია (v2-ში application იყო), და გასაღები ორწერტილს შეიცავს, ამიტომ jq-ში ის ბრჭყალებში უნდა ჩაისვას: .downloads."server:default".url. თვითონ URL content-addressed-ია - მისამართი jar-ის sha256-ს შეიცავს - ამიტომ მოცემული build-ისთვის ის არასდროს იცვლება და უსაფრთხოდ შეიძლება მისი cache-ირება. ეს URL თვითონ ნუ ააგებ; API-დან წაიკითხე. ეს არის მთავარი განსხვავება v2-სგან, სადაც URL-ის აგება ვერსიიდან და build-იდან ნორმალური მუშაობის წესი იყო.

შეცდომები JSON-ის სახით ბრუნდება error კოდითა და სწორი HTTP სტატუსით: build, რომელიც არ არსებობს, იძლევა 404-ს და build_not_found-ს, უცნობი ვერსია - version_not_found-ს. API-ს ასევე აქვს GraphQL endpoint მისამართზე https://fill.papermc.io/graphql მათთვის, ვისაც ის ურჩევნია; ამ პოსტში ყველაფერი REST-ზეა, რადგან curl და jq ყველა Linux მანქანაზეა.

არხები: ALPHA, BETA და STABLE#

v2-ში ორი არხი იყო, default და experimental. Fill-ში სამია და ყველა build-ს ერთი აქვს:

Minecraft-ის ახალი რელიზი ALPHA build-ების სერიით იწყება, გამოსადეგი რომ გახდება, BETA-ზე გადადის, და STABLE ხდება, როცა PaperMC კმაყოფილია. 26.3-ზე წერის დროისთვის 48 alpha build იყო, 38 beta და 15 stable, რაც წარმოდგენას გაძლევს, რამდენ ხანს გრძელდება არასტაბილური მონაკვეთი. release candidate-ებს, როგორიცაა 26.3-rc-3, შეიძლება stable build საერთოდ არასდროს ჰქონდეთ.

PaperMC-ის საკუთარი დოკუმენტაცია ამაზე პირდაპირია: გამოიყენე stable build-ები და production-ში არ გაუშვა არასტაბილური build-ები ან ავტომატური განმაახლებლები, რადგან ექსპერიმენტული build-ები შეცდომებისკენაა მიდრეკილი და მხარდაჭერას არ იღებს. ეს სიტყვასიტყვით უნდა მიიღო. Discord-ზე შეტყობინებას, რომელიც იწყება სიტყვებით "alpha build-ზე ვარ", ერთი პასუხი აქვს.

builds-ის სიაზე channel ფილტრი რამდენიმე მნიშვნელობასაც იღებს (?channel=STABLE&channel=BETA), რაც გამოდგება staging სერვერისთვის, რომელმაც beta-ები უნდა გამოსცადოს, სანამ production-ამდე მივლენ.

User-Agent-ის ეტიკეტი და რატომ გახდა ის წესი#

v2-ში User-Agent თავაზიანობა იყო. Fill-ში ის სავალდებულოა. PaperMC-ის ჩამოტვირთვების დოკუმენტაცია ადგენს, რომ ყველა მოთხოვნას უნდა ახლდეს User-Agent, რომელიც ნათლად ასახელებს შენს პროგრამას ან ორგანიზაციას, არ არის ზოგადი ნაგულისხმევი, როგორიცაა curl/8.5.0 ან Wget/1.21, და შეიცავს საკონტაქტო URL-ს ან ელფოსტის მისამართს. მათი მაგალითი ის არის, რომელსაც პოპულარული Docker იმიჯი იყენებს:

mc-image-helper/1.39.11 (https://github.com/itzg/docker-minecraft-server)

მოთხოვნამ, რომელსაც ის არ ახლავს, დღეს შეიძლება იმუშაოს, განსაკუთრებით cache-დან მიღებული პასუხებისთვის - მაგრამ ამაზე დაყრდნობა ნიშნავს იმის თავზე აგებას, რასაც ოპერატორები ამბობენ, რომ არ ითვლება დასაშვებად, და დაბლოკილი სკრიპტი ზუსტად ისევე ბნელად ვარდება, როგორც v2-ის გაუქმებისას. წესის დამაკმაყოფილებელი ფორმატია name/version (contact):

$ curl -A "smp-updater/1.2 (admin@example.net)" \    https://fill.papermc.io/v3/projects/paper

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

• ნუ აკეთებ polling-ს. დღეში ერთხელ ან ყოველი დაგეგმილი restart-ის წინ ერთხელ შემოწმება სავსებით საკმარისია. Paper-ს ერთ საღამოში რამდენიმე build-ის გამოქვეყნება შეუძლია; ყველა მათგანი წუთებში არ გჭირდება.
• ნუ ჩამოტვირთავ იმას, რაც უკვე გაქვს. შეადარე build id (ან sha256) დაყენებულს და თუ ემთხვევა, გაჩერდი. ქვემოთ მოცემული სკრიპტი ამას აკეთებს.
• პატივი ეცი cache header-ებს. მეტამონაცემების პასუხებს აქვს cache-control: max-age=1800. ნახევარ საათზე უფრო ხშირად კითხვა იმავე პასუხს მოგცემს.
• jar ჩამოტვირთე ერთხელ თითო მანქანაზე, და არა ერთხელ სერვერის ყოველ გაშვებაზე. ქსელმა, რომელიც ერთი მანქანიდან რვა backend-ს უშვებს, ერთი jar უნდა ჩამოტვირთოს და დააკოპიროს.

build-ის დაფიქსირება თუ უახლესის დევნა#

"Paper-ის განახლებაში" შეიძლება ორი სრულიად განსხვავებული რამ გულისხმობდე, და სკრიპტმა მხოლოდ ერთი უნდა დააავტომატოს.

build-ები ერთი Minecraft ვერსიის ფარგლებში ძირითადად შეცდომების გასწორებები და წარმადობის სამუშაოა. 26.3-ის 187-ე build-იდან 189-ზე გადასვლა სამყაროს არ გარდაქმნის და plugin API-ს არ ცვლის, და სკრიპტი, რომელიც ფიქსირებული ვერსიის უახლეს stable build-ს მიჰყვება, ბევრი სერვერისთვის გონივრულია. აქაც, დროდადრო რომელიმე build ცვლის ქცევას, რომელსაც plugin ეყრდნობოდა, ან ამკაცრებს იმას, რაც ბოროტად გამოიყენებოდა - 26.3-ის ბოლო build, რომელმაც plugin-ებს main thread-ის გარეთ ხარშვის რეცეპტების განულება შეუზღუდა, სწორედ ასეთი ცვლილებაა. მცირე ჯგუფის სერვერისთვის stable build-ების კვირაში ერთხელ მიყოლა კარგია. სერვერისთვის, რომელსაც ათობით plugin აქვს, დააფიქსირე build, რომელიც გამოსცადე, და წინ შეგნებულად გადაადგილე.

Minecraft-ის ახალი ვერსია სრულიად სხვა მოვლენაა. სამყარო პირველ ჩატვირთვაზე გარდაიქმნება და ძველი ვერსიით მისი გახსნა აღარ შეიძლება, ძველ ვერსიაზე შედგენილი plugin-ები ხშირად ფუჭდება, და კლიენტები უნდა ემთხვეოდეს. ეს არასდროს უნდა მოხდეს იმის გამო, რომ სკრიპტმა ვერსიების სიის თავში ახალი ჩანაწერი შეამჩნია. Minecraft-ის ვერსია დატოვე ფიქსირებულ პარამეტრად, რომელსაც ადამიანი ირჩევს, და როცა ცვლი, გაიარე Minecraft version upgrades.

პრაქტიკაში დაფიქსირება build-ის ჩაწერას ნიშნავს. ან ზუსტი build id შეინახე კონფიგურაციის ფაილში და სკრიპტს ის id დააყენებინე, ან სკრიპტს stable build-ებს გაატარებინე, მაგრამ ყოველი დაყენება ჩაიწერე ჟურნალში, რომ იცოდე, რომელ build-ზე დაბრუნდე. ვერსიის endpoint ყველა არსებულ build id-ს ჩამოთვლის, ამიტომ დაფიქსირებული id ყოველთვის ჩამოსატვირთი რჩება. წინა jar მიმდინარესთან ერთად შეინახე; იმავე Minecraft ვერსიის ფარგლებში build-ზე უკან დაბრუნება ფაილის გადარქმევაა, თუ სამყარო არ გარდაქმნილა.

curl და jq განახლების სკრიპტი#

ეს სკრიპტი ერთი ფიქსირებული Minecraft ვერსიის უახლეს stable build-ს აყენებს, ან დაფიქსირებულს, თუ მას მიუთითებ. ცოცხალ jar-ს შეხებამდე ამოწმებს საკონტროლო ჯამს, rollback-ისთვის წინა jar-ს ინახავს და საერთოდ არაფერს აკეთებს, თუ დაყენებული build უკვე მიმდინარეა. მას სჭირდება bash, curl, jq და sha256sum.

#!/usr/bin/env bash# Usage: update-paper.sh <minecraft-version> [build]set -euo pipefailPROJECT="${PROJECT:-paper}"            # paper, folia or velocityVERSION="${1:?usage: $0 <minecraft-version> [build]}"PIN="${2:-}"                           # optional exact build idDIR="${DIR:-/home/mc/server}"JAR="$DIR/server.jar"STATE="$DIR/.${PROJECT}-build"UA="smp-updater/1.2 (admin@example.net)"API="https://fill.papermc.io/v3/projects/$PROJECT/versions/$VERSION"if [[ -n "$PIN" ]]; then  build=$(curl -fsS -A "$UA" "$API/builds/$PIN")else  build=$(curl -fsS -A "$UA" "$API/builds?channel=STABLE" | jq -e '.[0]') \    || { echo "No stable $PROJECT build for $VERSION" >&2; exit 1; }fiid=$(jq -r '.id' <<<"$build")url=$(jq -r '.downloads."server:default".url' <<<"$build")sha=$(jq -r '.downloads."server:default".checksums.sha256' <<<"$build")name=$(jq -r '.downloads."server:default".name' <<<"$build")if [[ -f "$STATE" && "$(cat "$STATE")" == "$id" ]]; then  echo "$PROJECT $VERSION build $id already installed"; exit 0fitmp=$(mktemp "$DIR/.download.XXXXXX")trap 'rm -f "$tmp"' EXITcurl -fsS -A "$UA" -o "$tmp" "$url"echo "$sha  $tmp" | sha256sum -c --quiet -[[ -f "$JAR" ]] && cp -p "$JAR" "$JAR.prev"mv "$tmp" "$JAR"echo "$id" > "$STATE"echo "$(date -Is) installed $name" >> "$DIR/update.log"

გაუშვი ./update-paper.sh 1.21.11, რომ 1.21.11-ის stable build-ებს მიჰყვე, ან ./update-paper.sh 1.21.11 132, რომ ზუსტად 132-ე build დააყენო. იგივე სკრიპტი Velocity-სა და Folia-საც ემსახურება PROJECT ცვლადის მეშვეობით:

$ PROJECT=velocity DIR=/home/mc/proxy ./update-paper.sh 4.2.0$ PROJECT=folia ./update-paper.sh 26.3

რატომ არის თითოეული ნაწილი იქ:

• curl -f HTTP შეცდომას არანულოვან გასვლის კოდად აქცევს, ამიტომ 410, 404 ან დაბლოკილი მოთხოვნა სკრიპტს აჩერებს და jar-ის სახელის მქონე JSON ფაილს არ ქმნის. -sS გამოსვლას წყნარს ტოვებს, მაგრამ რეალურ შეცდომებს მაინც ბეჭდავს.
• jq -e '.[0]' არანულოვანი კოდით გადის, როცა მასივი ცარიელია - ვერსია, რომელსაც stable build ჯერ არ აქვს - ამიტომ სკრიპტი შეტყობინებით ჩერდება და null URL-ს არ ითხოვს.
• ჩამოტვირთვა იმავე დირექტორიაში დროებით ფაილში მიდის და ცოცხალ jar-ს მხოლოდ საკონტროლო ჯამის გავლის შემდეგ ანაცვლებს. server.jar-ზე პირდაპირ ჩაწერა ნიშნავს, რომ გაწყვეტილი კავშირი შეკვეცილ jar-სა და სერვერს გიტოვებს, რომელიც არ ჩაირთვება. დროებითი ფაილის იმავე ფაილურ სისტემაზე შენახვა საბოლოო mv-ს ატომურს ხდის.
• sha256sum -c ელის ორ ჰარს ჰეშსა და ფაილის სახელს შორის. ერთი ჰარით ის შეუსაბამობის ნაცვლად ფორმატის შეცდომას აცხადებს, რაც copy-paste-ის გავრცელებული პრობლემაა.
• state ფაილი დაყენებული build id-ს ინახავს, ამიტომ სკრიპტის ზედიზედ ორჯერ გაშვება მეორედ არაფერს ჩამოტვირთავს.

გაუშვი, სანამ სერვერი გაჩერებულია, ან სულ მცირე restart დაუყოვნებლივ გააკეთე: JVM-ს ძველი jar გახსნილი აქვს, და Paper დამუშავებულ კლასებს იმ cache დირექტორიიდან კითხულობს, რომელსაც პირველ გაშვებაზე აგებს. ახალი build ძალაში შემდეგ გაშვებაზე შედის, როცა Paperclip ახალ jar-ს შეამჩნევს და თავიდან დააპატჩებს, რაც პირველ ჩართვას რამდენიმე წამს მატებს.

macOS-ზე sha256sum შეიძლება არ იყოს; shasum -a 256 -c იგივე შესატანს იღებს. Windows-ზე ექვივალენტური შემოწმებაა Get-FileHash -Algorithm SHA256 PowerShell-ში, რომელსაც sha256 ველს ადარებ.

Folia-სა და Velocity-ს თავისებურებები#

API დანარჩენი ორი პროექტისთვის იდენტურია, მაგრამ შედეგით შენი მოქმედება - არა.

Velocity-ს ვერსიები proxy-ის საკუთარი ვერსიის ნომრებია და არა Minecraft-ის ვერსიები. პროექტში ოჯახებია 4.0.0 და 3.0.0 ისეთი ჩანაწერებით, როგორიცაა 4.2.0, 3.5.0 და 3.6.0-SNAPSHOT. snapshot ვერსიებს ბევრი build აქვს; რელიზის ვერსიებს - ძალიან ცოტა: 4.2.0-ს წერის დროს ერთადერთი build ჰქონდა, ნომერი 30, ზოგი უფრო ძველი რელიზის id კი, მაგალითად 3.5.0, build-ებს საერთოდ არ ჩამოთვლის, ამიტომ დაფიქსირებამდე შეამოწმე. proxy-ის ვერსია backend-ის ვერსიისგან დამოუკიდებელია, და ერთი Velocity build ზოგადად კლიენტის ვერსიების დიაპაზონს უჭერს მხარს, ამიტომ მისი განახლება Paper-ის განახლებაზე ნაკლებად საფრთხილოა - თუმცა proxy-ის განახლება მაინც ერთბაშად წყვეტს ქსელის ყველა მოთამაშეს. დაგეგმე, ნუ დაუშვებ, რომ ის საღამოს ტაიმერით მოხდეს. ასევე გაითვალისწინე, რომ 4.x ხაზს Java 25 სჭირდება. Building a Velocity proxy network განმარტავს, როგორ ერწყმის proxy და backend-ები ერთმანეთს.

Folia-ს Paper-ზე გაცილებით ნაკლები ვერსია და build აქვს, და მხოლოდ ისეთ ვერსიებზე, რომლებზეც PaperMC-მ ის გადაიტანა. მისი plugin-თავსებადობა რეალური შეზღუდვაა: Folia-ს განახლებაზე უფრო მნიშვნელოვანია, აცხადებენ თუ არა შენი plugin-ები საერთოდ Folia-ს მხარდაჭერას. დააფიქსირე Folia-ს build-ები და გამოსცადე ისინი, როგორც უფრო დეტალურად განმარტავს Folia's regionised multithreading.

ფორკები, როგორიცაა Purpur და Pufferfish, PaperMC-ის API-ს არ ეკუთვნის. მათ საკუთარი ჩამოტვირთვის სერვისები აქვს საკუთარი URL სქემებით; Purpur and Pufferfish forks განმარტავს, რას ცვლიან და რატომ შეიძლება გინდოდეს ისინი.

გაშვება განრიგით, რამის გაფუჭების გარეშე#

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

1. სამყაროს backup ყოველთვის პირველი სრულდება. build, რომელიც chunk-ს აზიანებს, იშვიათია, მაგრამ იშვიათი არ ნიშნავს არასდროს, და backup იაფია. Minecraft world backup and restore განმარტავს, რა უნდა შევიდეს მასში.
2. განახლების სკრიპტი სრულდება ფიქსირებული Minecraft ვერსიითა და stable არხით.
3. სერვერი მშვიდ საათზე restart-დება, ჩატში გაფრთხილების შემდეგ.
4. რაღაც ამოწმებს, რომ სერვერი ისევ ამოვიდა - ლოგის ხაზი Done (...)! For help, type "help" გაშვებიდან რამდენიმე წუთში - და თუ არა, ადამიანს აფრთხილებს.

# 04:30 daily: back up, update within 1.21.11, restart30 4 * * * /home/mc/backup.sh && /home/mc/update-paper.sh 1.21.11 && systemctl restart minecraft

&& ჯაჭვს მნიშვნელობა აქვს: backup არ არის - განახლებაც არ არის; ჩამოტვირთვა ან საკონტროლო ჯამი ჩავარდა - restart არ არის. Automating game server updates განიხილავს ზოგად პოლიტიკას - რომელ სერვერებს შეუძლია თავისით განახლება და რომელს არა - ხოლო restart schedules that help restart-ის მხარეს ეხება.

RE:NODE-ზე Minecraft სერვერები Paper-ითა და შესაბამისი Java ვერსიით ყენდება, EULA მიღებულია და სამყარო დაგენერირებულია, ამიტომ პირველი ჩამოტვირთვა შენთვის უკვე გაკეთებულია. jar-ის მოგვიანებით ჩანაცვლება ფაილური ოპერაციაა: ატვირთე შემოწმებული build ფაილების მენეჯერით ან SFTP-ით (SFTP and the file manager დეტალებს შეიცავს), და Schedules ჩანართს შეუძლია backup, ჩატის გაფრთხილება და restart თანმიმდევრობით, შორის დაყოვნებებით, ჯაჭვად დააკავშიროს. backup-ის სლოტები Minecraft-ის ყველა გეგმას მოყვება, ამიტომ განახლებამდე ნაბიჯი ერთი ღილაკია.

შეცდომები, რომლებსაც ადამიანები რეალურად ხვდებიან#

`Error: Invalid or corrupt jarfile server.jar`. ფაილი jar არ არის. გაუშვი head -c 200 server.jar: თუ ის {"ok":false-ით იწყება, ჩამოტვირთვის URL ძველი v2 იყო ან მოთხოვნა უარყვეს. გადადი v3 endpoint-ებზე და curl-ს დაუმატე -f, რომ ეს ისევ უხმოდ ვეღარ მოხდეს.

`410 Gone` და `"error":"sunset"`. შენ api.papermc.io/v2-ზე ხარ. გამოსწორება მხოლოდ fill.papermc.io/v3-ზე გადასვლაა. შეამოწმე სკრიპტები, Dockerfile-ები, Ansible როლები და ყველა გაშვების სკრიპტი, რომელიც ჩართვაზე ჩამოტვირთავს - ისინი ხშირად ავიწყდებათ, რადგან წლები მუშაობდნენ.

`jq: error: Cannot index array with "downloads"`. builds-ის სია გამოიძახე, მაგრამ შედეგს ერთ build-ად მოეპყარი. სია მასივია; ჯერ აიღე .[0]. ერთი build-ის endpoint-ები (builds/189, builds/latest) ობიექტს აბრუნებს.

სკრიპტმა alpha დააყენა. მან builds/latest გამოიყენა, რომელიც არხებს უგულებელყოფს. გამოიყენე builds?channel=STABLE და პირველი ელემენტი.

ცარიელი მასივი `?channel=STABLE`-დან. ვერსიას stable build-ები ჯერ არ აქვს - Minecraft-ის რელიზის შემდეგ ერთი კვირა ან მეტი ხნით ეს ხშირია, release candidate-ებისთვის კი მუდმივია. დაელოდე, ან წინა ვერსიაზე დარჩი. alpha-ზე ავტომატურად ნუ დაბრუნდები.

`sha256sum: WARNING: 1 computed checksum did NOT match`. ჩამოტვირთვა გზაში შეწყდა ან შეიცვალა. ნუ დააყენებ; წაშალე ფაილი და თავიდან ჩამოტვირთე. თუ განმეორებით ვარდება, შეადარე ფაილის ზომა build JSON-ის size ველს - ჩვეულებრივი მიზეზი შუაში მდგომი proxy ან captive portal-ია.

`UnsupportedClassVersionError` განახლების შემდეგ. გადახვედი Minecraft-ის ვერსიაზე, რომლის jar-საც უფრო ახალი Java სჭირდება - 26.x-ს Java 25 სჭირდება. დაყენებამდე ვერსიის endpoint-იდან წაიკითხე java.version.minimum.

FAQ#

ძველი api.papermc.io v2 URL ძველ build-ებზე ისევ მუშაობს?

არა. ყველა v2 გზა, წლების წინ გამოქვეყნებული build-ების პირდაპირი jar ჩამოტვირთვების ჩათვლით, 410 Gone-ს აბრუნებს. ძველი build-ები v3-ით ისევ ხელმისაწვდომია: ვერსიის endpoint ყველა build id-ს ჩამოთვლის, და თითოეული build-ის JSON-ს ჩამოტვირთვის URL აქვს.

User-Agent მართლა სავალდებულოა თუ მხოლოდ რეკომენდებულია?

PaperMC-ის დოკუმენტაცია ამბობს, რომ ყველა მოთხოვნას უნდა ახლდეს User-Agent, რომელიც შენს პროგრამას ასახელებს და კონტაქტს იძლევა, და რომ ზოგადი ნაგულისხმევები, როგორიცაა curl/..., მიუღებელია. ზოგ მოთხოვნას ის გარეშეც შეიძლება უპასუხონ, მაგრამ ეს არ არის ის, რაზეც სკრიპტი უნდა აგო.

სკრიპტმა Minecraft-ის უახლესი ვერსია ავტომატურად უნდა აირჩიოს?

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

როგორ მივიღო კონკრეტული უფრო ძველი Paper build-ის ჩამოტვირთვის ბმული?

მოითხოვე https://fill.papermc.io/v3/projects/paper/versions/<version>/builds/<build> და წაიკითხე .downloads."server:default".url. URL-ის აგებას ვერსიისა და build-ის ნომრიდან ნუ ეცდები - v3-ში გზა ფაილის საკონტროლო ჯამს შეიცავს, ამიტომ მისი გამოცნობა შეუძლებელია.

Velocity Minecraft-ის ვერსიის ნომრებს მიჰყვება?

არა. Velocity-ს ვერსიები (3.5.0, 4.2.0 და ა.შ.) proxy-ის საკუთარი რელიზებია, და თითოეული კლიენტის ვერსიების დიაპაზონს უჭერს მხარს. დიაპაზონისთვის წაიკითხე release notes და ნომრებს ნუ შეადარებ.

ღირს საკონტროლო ჯამის შემოწმება დამატებით ხაზად?

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