SFTP და file manager: ფაილების გადატანა შენს სერვერზე

ყველა სერვერზე გაქვს სრული file manager ბრაუზერში და SFTP მონაცემები იმ ინსტრუმენტებისთვის, რომლებსაც უკვე იყენებ. ისინი ერთი ფაილური სისტემის ორი კარია და მათ შორის არჩევანი რედაქტირების ზომაზეა დამოკიდებული და არა პრეფერენციაზე: config-ის ერთი მნიშვნელობა file manager-ის საქმეა, plugin-ების საქაღალდე ოთხასი ფაილით SFTP-ის, და პირიქით გაკეთება ისაა, რითაც ხალხი მთელ ნაშუადღევს კარგავს.

პრობლემას არჩევანი არ ქმნის. ის რამდენიმე რამ არის, რომელიც სერვერზე შენი საკუთარი მანქანისგან განსხვავებულად იქცევა: ფაილები, რომლებსაც გაშვებული პროცესი ღიად ინახავს, executable bit, რომლის დაყენებაც ბრაუზერის ატვირთვას არ შეუძლია, Windows-ის ხაზის დასასრული shell სკრიპტში და ათასობით პატარა ფაილი, რომლებიც ისეთ პროტოკოლზე ცოცავენ, რომელიც თითოეულისთვის ახალ მოთხოვნას ხსნის. ეს პოსტი ორივე ინსტრუმენტს სათანადოდ ფარავს და შემდეგ ამ ხაფანგებს იმ თანმიმდევრობით, რა თანმიმდევრობითაც შეხვდები.

ორი კარი ერთ ფაილურ სისტემაზე#

ცალკე „ატვირთვის ზონა“ არ არსებობს. file manager და SFTP იმავე დირექტორიაში წერენ, საიდანაც შენი სერვერის პროცესი კითხულობს, იმავე მომენტში. ფაილი, რომელიც ერთში ჩნდება, მეორეშიც გამოჩნდება შემდეგ განახლებაზე, უფლებებიანად.

ამას შედეგი აქვს, რომელიც სხვა ყველაფრამდე პირდაპირ უნდა ითქვას: არ არსებობს შუალედური ეტაპი და არც გაუქმება. file manager-ში სამყაროს საქაღალდის წაშლა მას შლის. server.properties-ის გადაწერა SFTP-ით მას გადაწერს. ერთადერთი, რაც შეცდომასა და თავიდან აგებას შორის დგას, backup-ია, რომელიც წინასწარ აიღე, ამიტომ ყველაფერი სტრუქტურულისთვის თანმიმდევრობა ყოველთვის ასეა: backup, stop, ცვლილება, start - ამ რიგით, ყოველ ჯერზე. Backup-ები, რომლებიც მართლა აღდგება არგუმენტია, რატომ არ არის პირველი ნაბიჯი არჩევითი.

File manager, ისეთი რედაქტირებისთვის, რომელსაც ხედავ#

ბრაუზერის file manager რეალური editor-ია და არა მხოლოდ მნახველი. მას აქვს სინტაქსის გამოკვეთა იმ ფორმატებისთვის, რომლებსაც სერვერზე შეხვდები, ის ადგილზე ინახავს და PDF-ებსა და სურათებს ჩვენებს, რომ დარწმუნდე, რენდერი ან სერვერის icon მართლა მოვიდა და არა ფაილის ზომიდან იმის გამოცნობა.

რაში არის ის ნამდვილად უკეთესი:

• ერთი მნიშვნელობის რედაქტირება. view-distance-ის ან პორტის ნომრის შეცვლა. ჩამოტვირთვის ნაბიჯი არ არის, ხელახლა ატვირთვის ნაბიჯი არ არის და შანსი არ არის, გუშინდელი ფაილი დღევანდელს გადააწერო.
• რაღაცის დათვალიერება. latest.log-ის გახსნა stack trace-ის სანახავად, config ფაილის ვალიდურობის დადასტურება ინსტალაციის შემდეგ, იმის ნახვა, plugins საქაღალდე შეიცავს თუ არა იმას, რასაც ფიქრობ.
• ფაილების ჩაგდება. Drag-and-drop მუშაობს ფაილებისთვისაც და მთელი საქაღალდეებისთვისაც, რაც „ერთი jar“-ის შემთხვევას სავსებით კარგად ფარავს.
• არქივები. ატვირთე .zip ან .tar.gz და გახსენი ადგილზე. ეს მისი ყველაზე სასარგებლო ფუნქციაა და მიზეზი ნელი გადაცემების ქვეთავშია ქვემოთ.

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

SFTP, ყველაფრისთვის, რასაც სტრუქტურა აქვს#

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

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

მონაცემები თითო სერვერზე გაიცემა და არა თითო ანგარიშზე. ეს მიზანია და არა უხერხულობა: ვინმესთვის საერთო სერვერზე SFTP წვდომის მიცემა მას ამ სერვერს აძლევს და სხვა არაფერს, და ის შეიძლება ჩამოერთვას შენი სხვა რამის შეხების გარეშე.

კავშირის დეტალები ნაჩვენებია სერვერის პარამეტრებში პანელზე: host, პორტი, რომელიც 22 არ არის, და username. პორტი ყურადღების ღირსია, რადგან firewall-ის ძალიან ბევრი წესი და კორპორატიული ქსელი 22-ს უშვებს და სხვას არაფერს, და პირველი სიმპტომი კლიენტია, რომელიც ჩერდება და არა ის, რომელიც უარს იღებს.

დაკავშირება და სკრიპტირება#

ნებისმიერი SFTP კლიენტი მუშაობს. FileZilla, WinSCP და Cyberduck გრაფიკულ შემთხვევას ფარავს; sftp ბრძანების ხაზზე დაყენებულია ყველა Linux და macOS მანქანაზე და Windows-ზე OpenSSH-ით.

# Interactive, with the port from the panel$ sftp -P 2022 username@node.example.comsftp> cd pluginssftp> put -r ./build/EssentialsX.jarsftp> get latest.logsftp> bye

ყველაფრისთვის, რაც მეორდება, სკრიპტით მართე. sftp -b batch ფაილს კითხულობს, ხოლო lftp მთელ დირექტორიას პარალელურად ასახავს, რაც ყველაზე ახლოა rsync-თან, რომელიც აქ მუშაობს:

# Push a local plugins folder up, four transfers at a time$ lftp -u "$SFTP_USER,$SFTP_PASS" sftp://node.example.com:2022 \    -e "mirror -R --parallel=4 --delete ./plugins /plugins; quit"

ორი მნიშვნელოვანი ლიმიტი იმისა, რისი გაკეთებაც ბრძანების ხაზს შეუძლია:

`rsync` არ მუშაობს. მას სჭირდება, რომ თავისი ასლი მეორე ბოლოზე SSH shell-ით გაუშვას, ხოლო პანელის SFTP ფაილების გადაცემის სერვისია მიმაგრებული shell-ის გარეშე. გასასწორებელი არაფერია; გამოიყენე lftp mirror, რომელიც იმავე დირექტორიების შედარების საქმეს SFTP-ით აკეთებს.

`scp` ვერსიაზეა დამოკიდებული. OpenSSH-ის ახალი გამოშვებები scp-ით გადაცემას SFTP პროტოკოლით აკეთებენ და არა ძველი remote-exec გზით, ამიტომ შეიძლება იმუშაოს; ძველები ისევე ჩავარდება, როგორც rsync. sftp და lftp ყოველთვის მუშაობს, ამიტომ სკრიპტებში ისინი გამოიყენე და თავი დაიზოგე debug-ისგან.

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

ეს ისაა, რასაც ხალხს სამყაროები და ბაზები უჯდება.

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

წესი: გააჩერე სერვერი, სანამ იმას შეეხები, რაც მას ეკუთვნის. ეს ნიშნავს სამყაროებსა და save-ებს, SQLite ან level ბაზებს, მოთამაშის მონაცემებს და უმეტეს თამაშში config ფაილებსაც, რადგან ისინი start-ზე ერთხელ იკითხება. შემდეგ:

1. აიღე backup. ეს ერთი ღილაკია და ერთადერთი ვერსიაა წინა მდგომარეობისა, რომელსაც მიიღებ.
2. გააჩერე სერვერი და დაელოდე, სანამ console დაადასტურებს, რომ ის მართლა გაჩერდა და არა უბრალოდ ღილაკი დააჭირე. სუფთა stop არის ის, რაც საბოლოო save-ს იწვევს.
3. ატვირთე ან შეცვალე.
4. გაუშვი და უყურე console-ს ჩატვირთვის ხაზისთვის, რომელიც ასახელებს, რა ჩაიტვირთა.

კითხვა უსაფრთხოა, სანამ სერვერი მუშაობს. latest.log-ის გახსნა file manager-ში, config-ის ასლის ჩამოტვირთვა სანახავად, იმის შემოწმება, რომ მოდის jar სწორი ზომისაა - არცერთი ეს არ ერევა. console-ის კითხვა ფარავს, რას უნდა დააკვირდე start-ის გამოტანაში, როცა შეცვლილმა ფაილმა არ იმოქმედა, ხოლო სამყაროს გადატანის პროცედურა Valheim-ის dedicated სერვერის გზამკვლევში იგივე ცეკვაა კონკრეტულ თამაშში.

უფლებები, ხაზის დასასრულები და არქივები#

სამი მექანიკური პრობლემა, რომელიც ბაგებს ჰგავს და არ არის.

Executable bit. .sh სკრიპტი, ატვირთული ბრაუზერით, execute უფლების გარეშე ჩამოდის და სერვერი permission denied-ს იტყობინება, როცა მის გაშვებას ცდილობს. გრაფიკულ SFTP კლიენტებს ამის გასწორება შეუძლიათ: FileZilla-ს აქვს File permissions მარჯვენა ღილაკის მენიუში, WinSCP-ს - Properties. დააყენე ფაილზე 0755. თუ შენს კლიენტს უფლებების დაყენება არ შეუძლია, chmod sftp prompt-იდან მუშაობს:

sftp> chmod 755 start.shsftp> ls -l start.sh-rwxr-xr-x    1 container container      412 Sep 21 09:14 start.sh

Windows-ის ხაზის დასასრულები. Notepad-ში რედაქტირებული და ატვირთული ფაილი carriage return-ებს ინარჩუნებს, და shell სკრიპტი მათთან ერთად ვარდება შეტყობინებით, რომელიც ოცდაათი წელია ხალხს ატყუებს:

bash: ./start.sh: /bin/bash^M: bad interpreter: No such file or directory

^M carriage return-ია. გაასწორე ის editor-ისთვის LF ხაზის დასასრულებით შენახვის თქმით - VS Code სტატუს ზოლში აჩვენებს CRLF-ს ან LF-ს და გადართვა ერთი დაწკაპუნებაა - ან ფაილის რედაქტირებით პანელის file manager-ში, რომელიც LF-ს წერს. იგივე პრობლემა YAML კონფიგურაციებს უფრო დახვეწილად ტეხავს, ამიტომ editor-ის ნაგულისხმევი ერთხელ დაყენება ღირს.

არქივები. ერთი 200 MB არქივის ატვირთვა და ადგილზე გახსნა 4000 ფაილის ატვირთვაზე დრამატულად სწრაფია, რადგან პატარა ფაილების გადაცემის ნელი ნაწილი ფაილზე ერთი round trip-ია და არა ბაიტები. მოდპაკი, რომელსაც ფაილ-ფაილ ორმოცი წუთი სჭირდება, zip-ად ორ წუთს იღებს. ორი რამ დასამახსოვრებელია: ადგილი გჭირდება როგორც არქივისთვის, ისე მისი შიგთავსისთვის, ამიტომ ჯერ შეამოწმე შენი გეგმის დისკის მაჩვენებელი, და არქივი შემდეგ წაშალე. Minecraft-ის მოდები ჩავარდნების გარეშე ამას ყოველი პაკეტის ინსტალაციისთვის ეყრდნობა.

ვისაც კიდევ შეუძლია ამ ფაილებთან მიღწევა#

ფაილურ სისტემაზე წვდომა სრული წვდომაა. ვინც ფაილების წაკითხვა შეუძლია, შეუძლია წაიკითხოს შენი .env, შენი ბაზის მონაცემები და შენი მოთამაშეების მონაცემები; ვინც მათი ჩაწერა შეუძლია, შეუძლია ჩაანაცვლოს jar, რომელიც start-ზე გაეშვება. ისე მოექეცი.

• ფაილებზე წვდომა მიეცი subuser-ებით და არა მონაცემების გაზიარებით. როლები აქ დეტალურია, ამიტომ „მხოლოდ ფაილები, console-ის გარეშე, ბილინგის გარეშე“ რეალური უფლებების ნაკრებია და დროში შეიძლება შეიზღუდოს. Subuser-ები და მინიმალური პრივილეგია მოდელს შეიცავს.
• თითო სერვერზე არსებობს activity ლოგი. თუ ოდესმე არ იცი, ვინ წაშალა რაღაც, შეხედე, სანამ გამოიცნობ.
• SFTP მონაცემები თითო სერვერზეა. მათი გადაცემა მხოლოდ ერთ სერვერს ეხება და მათი გაუქმება სხვა არაფერს არ არღვევს, რასაც უშვებ.
• ჩართე 2FA ანგარიშზე, რომელიც ამ ყველაფერს ფლობს. authenticator კოდი განსხვავებაა იმას შორის, გაჟონილი პაროლი უხერხულობაა თუ ინციდენტი. იხილე ორფაქტორიანი ავთენტიფიკაცია შენს პანელის ანგარიშზე.
• შეამოწმე, რას ტვირთავ. ფორუმის პოსტიდან აღებულ jar-ს ფაილურ სისტემაზე წვდომა აქვს იმ წამიდან, როცა სერვერი მას გაუშვებს, და მთელი შეტევა ესაა. მოდიფიცირებული სერვერის სისუფთავე სწორედ ამ ჩვევაზეა.

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

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

კლიენტი უკავშირდება და ჩერდება „listing directory“-ზე. თითქმის ყოველთვის passive-mode ან firewall-ის ჩარევაა კორპორატიულ ან სასტუმროს ქსელში. სცადე ტელეფონის hotspot-იდან; თუ იქ მუშაობს, ქსელია და არა სერვერი.

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

ფაილი აიტვირთა, მაგრამ სერვერი მას უგულებელყოფს. სამი კანდიდატი: სერვერი მუშაობდა და გადააწერა, ფაილი არასწორ დირექტორიაშია (mods და plugins საქაღალდეები თამაშისეულია და შეუბრალებელი), ან სახელია არასწორი. Linux-ზე რეგისტრი მნიშვნელოვანია - Plugins არ არის plugins - ხოლო Windows ცნობილ გაფართოებებს მალავს, ამიტომ config.yml.txt კლასიკაა.

ფაილს, რომელიც ატვირთე, ვერ ხედავ. ის წერტილით იწყება. .env, .htaccess და .git უმეტეს კლიენტში ნაგულისხმევად დამალულია; FileZilla-ს აქვს „Force showing hidden files“ Server-ის ქვეშ, და პანელის file manager მათ ჩამოთვლის.

ყველაფერი დაიმსხვრა config-ის რედაქტირების შემდეგ. აღადგინე .bak ასლი, რომელიც გააკეთე, ან აღადგინე backup. შემდეგ შეცვალე ერთი რამ ერთდროულად. YAML ფაილი ერთი არასწორი ინდენტაციით ისევე სრულად ვარდება, როგორც ორმოცდაათით, და შეცდომა იშვიათად ასახელებს ხაზს, რომელსაც შეეხე - რა უნდა გააკეთო, როცა მოდის განახლება ტყდება ამ სახის საქმის bisect-ის ზოგადი მეთოდია.

FAQ#

შემიძლია rsync-ის გამოყენება ჰოსტინგ პანელთან?

არა. rsync თავის ასლს დისტანციურ მხარეს SSH shell-ით უშვებს, ხოლო პანელის SFTP სერვისს ის არ აქვს. გამოიყენე lftp mirror, რომელიც დირექტორიებს ადარებს და უბრალო SFTP-ით მხოლოდ იმას გადასცემს, რაც განსხვავდება, ან შენი გრაფიკული კლიენტის synchronise ფუნქცია. sftp -b batch ფაილით სკრიპტირებულ ატვირთვებს ფარავს.

რა არის SFTP პაროლი?

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

უნდა გავაჩერო სერვერი ფაილების ასატვირთად?

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

რატომ წერს ჩემი shell სკრიპტი „bad interpreter“?

ფაილს Windows-ის ხაზის დასასრულები აქვს, ამიტომ პირველ ხაზზე interpreter-ის გზა უხილავი carriage return-ით მთავრდება. შეინახე ფაილი LF დასასრულებით შენი editor-იდან, ან შეცვალე პანელის file manager-ში, რომელიც LF-ს წერს. იგივე ხარვეზს შეუძლია კონფიგურაციის ფაილები შეტყობინების გარეშე დააზიანოს.

file manager იმდენივე შესაძლებლობისაა, რამდენიც SFTP?

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

როგორ ავიღო მთელი სერვერის ასლი ლოკალურად?

დაუკავშირდი SFTP-ით და ჩამოტვირთე root დირექტორია, ან გაუშვი lftp mirror-ით ჩამოტვირთვის მიმართულებით. დიდ თამაშის სერვერზე ეს ათეულობით გიგაბაიტია და დრო დასჭირდება, ამიტომ ღირს ერთხელ არქივად გაკეთება და არა ყოველ ღამე. რუტინული დაცვისთვის გამოიყენე გეგმასთან ერთად მოსული backup სლოტები - ისინი იმ მანქანის გარეთ ინახება, რომელსაც იცავენ, რასაც იმავე დისკზე ასლი ვერ აკეთებს.