Linux-ს ბევრი სახე აქვს: როგორ ვიმუშაოთ ნებისმიერ დისტრიბუციაზე

სარეზერვო აპლიკაციის შექმნა, რომელიც მუშაობს ნებისმიერ დისტრიბუციაზე, ადვილი საქმე არ არის. იმისათვის, რომ დარწმუნდეთ, რომ Veeam Agent for Linux მუშაობს დისტრიბუციებზე Red Hat 6-დან და Debian 6-დან, OpenSUSE 15.1-მდე და Ubuntu 19.04-მდე, თქვენ უნდა მოაგვაროთ მთელი რიგი პრობლემები, განსაკუთრებით იმის გათვალისწინებით, რომ პროგრამული პროდუქტი შეიცავს ბირთვის მოდულს.

სტატია შეიქმნა კონფერენციაზე გამოსული მასალების საფუძველზე Linux Peter 2019.

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

პაკეტის მენეჯერები. .deb vs .rpm

დავიწყოთ პროდუქტის სხვადასხვა დისტრიბუციაზე განაწილების აშკარა პრობლემით.
პროგრამული პროდუქტების გავრცელების ყველაზე ტიპიური გზაა პაკეტის საცავში განთავსება, რათა სისტემაში ჩაშენებულმა პაკეტების მენეჯერმა შეძლოს მისი ინსტალაცია იქიდან.
თუმცა, ჩვენ გვაქვს ორი პოპულარული პაკეტის ფორმატი: rpm и deb. ეს ნიშნავს, რომ ყველას მოუწევს მხარდაჭერა.

Deb პაკეტების სამყაროში, თავსებადობის დონე საოცარია. იგივე პაკეტი ინსტალირებულია და მუშაობს თანაბრად კარგად როგორც Debian 6-ზე, ასევე Ubuntu 19.04-ზე. პაკეტების შექმნისა და მათთან მუშაობის პროცესის სტანდარტები, რომლებიც ასახულია ძველ Debian დისტრიბუციებში, რჩება აქტუალური ახალ Linux Mint-სა და ელემენტარულ OS-ში. ამიტომ, Linux-ისთვის Veeam Agent-ის შემთხვევაში, საკმარისია ერთი დებ პაკეტი თითოეული აპარატურის პლატფორმისთვის.

მაგრამ rpm პაკეტების სამყაროში, განსხვავებები დიდია. პირველ რიგში, იმის გამო, რომ არსებობს ორი სრულიად დამოუკიდებელი დისტრიბუტორი, Red Hat და SUSE, რომელთა თავსებადობა სრულიად არასაჭიროა. მეორეც, ამ დისტრიბუტორებს აქვთ სადისტრიბუციო ნაკრები მათგან. მხარდაჭერა და ექსპერიმენტული. მათ შორის თავსებადობაც არ არის საჭირო. აღმოჩნდა, რომ el6, el7 და el8-ს აქვთ საკუთარი პაკეტები. ცალკე პაკეტი Fedora-სთვის. პაკეტები SLES11 და 12-ისთვის და ცალკე openSUSE-სთვის. მთავარი პრობლემა არის დამოკიდებულებები და პაკეტის სახელები.

დამოკიდებულების პრობლემა

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

EL7-სთვის:
SLES 12-ისთვის:

• libblkid
• libgcc
• libstdc++
• ncurses-libs
• დაუკრავენ-libs
• ფაილ-libs
• veeamsnap=3.0.2.1185

• libblkid1
• libgcc_s1
• libstdc++6
• libmagic1
• libfuse2
• veeamsnap-kmp=3.0.2.1185

შედეგად, დამოკიდებულებების სია უნიკალურია განაწილებისთვის.

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

მაგალითი:

პაკეტი განახლებულია Fedora 24-ში წყევლა მე-5 ვერსიიდან 6 ვერსიამდე. ჩვენი პროდუქტი შეიქმნა მე-5 ვერსიით, რათა უზრუნველყოფილიყო თავსებადობა ძველ დისტრიბუციებთან. Fedora 5-ზე ბიბლიოთეკის ძველი მე-24 ვერსიის გამოსაყენებლად, მომიწია პაკეტის გამოყენება ncurses-compat-libs.

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

უფრო საინტერესო. შემდეგი განაწილების განახლების შემდეგ, პაკეტი ncurses-compat-libs ბიბლიოთეკის მე-5 ვერსიით, ის მიუწვდომელია. დისტრიბუტორისთვის ძვირია ძველი ბიბლიოთეკების განაწილების ახალ ვერსიაში ჩათრევა. გარკვეული პერიოდის შემდეგ, პრობლემა განმეორდა SUSE დისტრიბუციებში.

შედეგად, ზოგიერთ დისტრიბუციას უნდა დაეტოვებინა აშკარა დამოკიდებულება ncurses-libsდა დააფიქსირეთ პროდუქტი ისე, რომ მას შეეძლოს იმუშაოს ბიბლიოთეკის ნებისმიერ ვერსიასთან.

სხვათა შორის, Red Hat-ის მე-8 ვერსიაში აღარ არის მეტა პაკეტი პითონი, რომელიც კარგ ძველს ეხებოდა პითონი 2.7. არსებობს python2 и პითონი3.

პაკეტის მენეჯერების ალტერნატივა

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

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

ბინაპაკეტი ასევე საშუალებას გაძლევთ გაუშვათ აპლიკაციები სავარჯიშოში Linux კონტეინერების გამოყენებით. ასევე გამოიყენება ქვიშის ყუთის იდეა AppImage.

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

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

მეორე პრობლემა ის არის, რომ Red Hat-ისა და SUSE-დან საწარმოს გარემოში პოპულარული დისტრიბუციები ჯერ არ შეიცავს Snappy-ისა და Flatpak-ის მხარდაჭერას.

ამასთან დაკავშირებით, Veeam Agent Linux-ისთვის მიუწვდომელია snapcraft.io არა flathub.org.

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

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

განახლების პრობლემა

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

განახლების 3 სტრატეგიაა:

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

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

ტექნიკის პლატფორმების მრავალფეროვნება

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

Veeam Agent for Linux პროექტში, ჩვენ ჯერ კიდევ არ შეგვიძლია რაიმე მსგავსი RISC-ის მხარდაჭერა.

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

სტატიკური და/ან დინამიური კავშირი

მაგრამ კითხვაა "როგორ დავაკავშიროთ ბიბლიოთეკები - დინამიურად თუ სტატიკურად?" ღირს განხილვა.

როგორც წესი, C/C++ აპლიკაციები Linux-ში იყენებენ დინამიურ კავშირს. ეს მშვენივრად მუშაობს, თუ აპლიკაცია შექმნილია სპეციალურად კონკრეტული განაწილებისთვის.

თუ ამოცანაა სხვადასხვა დისტრიბუციის დაფარვა ერთი ორობითი ფაილით, მაშინ ყურადღება უნდა გაამახვილოთ უძველეს მხარდაჭერილ განაწილებაზე. ჩვენთვის ეს არის Red Hat 6. შეიცავს gcc 4.4, რომელსაც C++11 სტანდარტიც კი არ უჭერს მხარს. სრულად.

ჩვენ ვაშენებთ ჩვენს პროექტს gcc 6.3-ის გამოყენებით, რომელიც სრულად უჭერს მხარს C++14-ს. ბუნებრივია, ამ შემთხვევაში, Red Hat 6-ზე თქვენ უნდა ატაროთ libstdc++ და გაზარდოთ ბიბლიოთეკები. უმარტივესი გზაა მათთან სტატიკურად მიბმა.

სამწუხაროდ, ყველა ბიბლიოთეკა არ შეიძლება სტატიკურად იყოს დაკავშირებული.

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

მეორეც, არის ლიცენზიების დახვეწილობა.

GPL ლიცენზია ძირითადად საშუალებას გაძლევთ დააკავშიროთ ბიბლიოთეკები მხოლოდ ღია კოდით. MIT და BSD იძლევა სტატიკურ კავშირს და საშუალებას აძლევს ბიბლიოთეკებს პროექტში ჩართოთ. მაგრამ LGPL, როგორც ჩანს, არ ეწინააღმდეგება სტატიკურ კავშირს, მაგრამ მოითხოვს, რომ ბმულისთვის საჭირო ფაილები გაზიარონ.

ზოგადად, დინამიური ბმულის გამოყენება ხელს შეგიშლით რაიმეს მიწოდებისგან.

C/C++ აპლიკაციების აგება

სხვადასხვა პლატფორმისთვის და დისტრიბუციისთვის C/C++ აპლიკაციების ასაგებად, საკმარისია აირჩიოთ ან შექმნათ gcc-ის შესაფერისი ვერსია და გამოიყენოთ ჯვარედინი შემდგენელები კონკრეტული არქიტექტურისთვის და შეკრიბოთ ბიბლიოთეკების მთელი ნაკრები. ეს სამუშაო საკმაოდ განხორციელებადია, მაგრამ საკმაოდ პრობლემური. და არ არსებობს გარანტია, რომ შერჩეული შემდგენელი და ბიბლიოთეკები უზრუნველყოფენ შესასრულებელ ვერსიას.

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

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

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

ასე არის შედგენილი veeamsnap ბირთვის მოდულის KMOD პაკეტები Red Hat დისტრიბუციისთვის.

გახსენით Build Service

SUSE-ს კოლეგები ცდილობდნენ განახორციელონ რაიმე საშუალო გზა სპეციალური სერვისის სახით აპლიკაციების შედგენისა და პაკეტების შეკრებისთვის - openbuildservice.

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

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

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

გარდა ამისა, სხვა დისტრიბუციების მხარდაჭერა - მაგალითად, Red Hat - საკმაოდ ცუდად არის განხორციელებული, რაც გასაგებია.

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

ჩვენს ინფრასტრუქტურაში, OpenBuildService-ის გამოყენებით, აწყობილია veeamsnap ბირთვის მოდულის KMP პაკეტების მთელი მრავალფეროვნება SUSE დისტრიბუციისთვის.

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

ბირთვის ABI

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

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

DKMS საშუალებას გაძლევთ ავტომატიზიროთ მოდულების აგების პროცესი ბირთვის განახლებისას. შედეგად, Debian საცავის მომხმარებლები (და მისი მრავალი ნათესავი) იყენებენ ბირთვის მოდულებს ან დისტრიბუტორის საცავიდან, ან შედგენილ წყაროდან DKMS-ის გამოყენებით.

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

ადმინისტრატორებს არ სურთ განვითარების ინსტრუმენტების შენარჩუნება წარმოების სერვერებზე უსაფრთხოების მიზეზების გამო. Enterprise Linux-ის დისტრიბუტორებმა, როგორიცაა Red Hat და SUSE, გადაწყვიტეს, რომ მათ შეეძლოთ სტაბილური kABI-ს მხარდაჭერა მათი მომხმარებლებისთვის. შედეგი იყო KMOD პაკეტები Red Hat-ისთვის და KMP პაკეტები SUSE-სთვის.

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

Red Hat აცხადებს kABI თავსებადობას განაწილებისთვის მთელი მისი სასიცოცხლო ციკლის განმავლობაში. ანუ, rhel 6.0-ის აწყობილი მოდული (გამოშვება 2010 წლის ნოემბერი) ასევე უნდა მუშაობდეს 6.10 ვერსიაზე (გამოშვება 2018 წლის ივნისი). და ეს თითქმის 8 წელია. ბუნებრივია, ეს ამოცანა საკმაოდ რთულია.
ჩვენ ჩავწერეთ რამდენიმე შემთხვევა, როდესაც veeamsnap მოდულმა შეწყვიტა მუშაობა kABI თავსებადობის პრობლემების გამო.

მას შემდეგ, რაც veeamsnap მოდული, შედგენილი RHEL 7.0-ისთვის, აღმოჩნდა შეუთავსებელი RHEL 7.5-ის ბირთვთან, მაგრამ ის ჩაიტვირთა და გარანტირებული ჰქონდა სერვერის ავარია, ჩვენ საერთოდ უარი თქვით RHEL 7-ისთვის kABI თავსებადობის გამოყენებაზე.

ამჟამად, KMOD პაკეტი RHEL 7-ისთვის შეიცავს ასამბლეას თითოეული გამოშვების ვერსიისთვის და სკრიპტს, რომელიც ატვირთავს მოდულს.

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

მაგალითად, SLES 12-ის გამოშვება მოხდა 2014 წლის სექტემბერში. ხოლო SLES 12 SP1 უკვე 2015 წლის დეკემბერში იყო, ანუ წელიწადზე ცოტა მეტი გავიდა. მიუხედავად იმისა, რომ ორივე გამოცემა იყენებს 3.12 ბირთვს, ისინი kABI შეუთავსებელია. ცხადია, kABI თავსებადობის შენარჩუნება მხოლოდ ერთი წლის განმავლობაში ბევრად უფრო ადვილია. ბირთვის მოდულის განახლების წლიურმა ციკლმა არ უნდა შეუქმნას პრობლემები მოდულის შემქმნელებს.

ამ SUSE პოლიტიკის შედეგად, ჩვენ არ დაგვიფიქსირებია kABI თავსებადობის პრობლემა ჩვენს veeamsnap მოდულში. მართალია, SUSE-სთვის პაკეტების რაოდენობა თითქმის სიდიდის ბრძანებით მეტია.

პატჩები და ზურგჩანთები

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

ამავდროულად, საკუთარი „შეცდომებზე მუშაობის“ გარდა, საწარმო Linux kernel-ის დეველოპერები აკვირდებიან ცვლილებებს ვანილის ბირთვში და გადააქვთ მათ „სტაბილურზე“.

ზოგჯერ ეს იწვევს ახალს შეცდომები.

Red Hat 6-ის უახლეს გამოშვებაში შეცდომა დაუშვა ერთ-ერთ უმნიშვნელო განახლებაში. ამან განაპირობა ის ფაქტი, რომ veeamsnap მოდულს გარანტირებული ჰქონდა სისტემის ავარია, როდესაც სნეპშოტი გამოვიდა. როდესაც შევადარეთ ბირთვის წყაროები განახლებამდე და მის შემდეგ, აღმოვაჩინეთ, რომ უკანა პორტი იყო დამნაშავე. მსგავსი შესწორება გაკეთდა ვანილის ბირთვის ვერსიაში 4.19. უბრალოდ, ამ შესწორებამ კარგად იმუშავა ვანილის ბირთვში, მაგრამ "სტაბილურ" 2.6.32-ზე გადატანისას პრობლემა გაჩნდა spinlock-თან დაკავშირებით.

რა თქმა უნდა, შეცდომები ყველას აქვს ყოველთვის, მაგრამ ღირდა თუ არა კოდის გადატანა 4.19-დან 2.6.32-მდე, სტაბილურობის რისკი?.. დარწმუნებული არ ვარ...

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

როდესაც ვცადე მოდულის აგება ბირთვზე 4.4 SLES 12 SP3-დან, გამიკვირდა მასში ვანილის 4.8-ის ფუნქციონალობა. ჩემი აზრით, SLES 4.4 SP12-დან 3 ბირთვის ბლოკის I/O განხორციელება უფრო ჰგავს 4.8 ბირთვს, ვიდრე SLES4.4 SP12-დან სტაბილური 2 ბირთვის წინა გამოშვება. მე ვერ ვიმსჯელებ, კოდის რა პროცენტი გადავიდა 4.8-დან SLES 4.4-ზე SP3-ისთვის, მაგრამ ბირთვს ვერც კი ვუწოდებ იგივე სტაბილურ 4.4-ს.

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

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

ასევე არის პატჩები, რომლებიც ცვლის დოკუმენტირებული ბირთვის API-ს.
დისტრიბუციას წავაწყდი KDE Neon 5.16 და ძალიან გამიკვირდა, რომ დაინახა, რომ lookup_bdev ზარმა ამ ბირთვის ვერსიაში შეცვალა შეყვანის პარამეტრების სია.

მის გასაერთებლად, მომიწია სკრიპტის დამატება makefile-ში, რომელიც ამოწმებს, აქვს თუ არა lookup_bdev ფუნქციას ნიღბის პარამეტრი.

ბირთვის მოდულების ხელმოწერა

მაგრამ დავუბრუნდეთ პაკეტის განაწილების საკითხს.

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

Red Hat და SUSE დისტრიბუციები საშუალებას გაძლევთ შეამოწმოთ მოდულის ხელმოწერა და ჩატვირთოთ ის მხოლოდ იმ შემთხვევაში, თუ შესაბამისი სერტიფიკატი რეგისტრირებულია სისტემაში. სერთიფიკატი არის საჯარო გასაღები, რომლითაც მოდული გაფორმებულია. ვანაწილებთ ცალკე შეფუთვით.

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

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

EFI ვირტუალურ მანქანებზე

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

ყველა ჰიპერვიზორს არ უჭერს მხარს EFI. VMWare vSphere მხარს უჭერს EFI-ს 5 ვერსიიდან დაწყებული.
Microsoft Hyper-V-მა ასევე მოიპოვა EFI მხარდაჭერა დაწყებული Hyper-V-ით Windows Server 2012R2-ისთვის.

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

vSphere 6.5-ში დააყენეთ ვარიანტი უსაფრთხო ჩატვირთვისას შესაძლებელია მხოლოდ ვებ ინტერფეისის ძველ ვერსიაში, რომელიც მუშაობს Flash-ის საშუალებით. ვებ UI HTML-5-ზე ჯერ კიდევ ჩამორჩება.

ექსპერიმენტული განაწილებები

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

თუმცა, ასეთი დისტრიბუციები ხდება მოსახერხებელი პლატფორმა ახალი ექსპერიმენტული გადაწყვეტილებების გამოსაცდელად. მაგალითად, Fedora, OpenSUSE Tumbleweed ან Debian-ის არასტაბილური ვერსიები. ისინი საკმაოდ სტაბილურები არიან. მათ ყოველთვის აქვთ პროგრამების ახალი ვერსიები და ყოველთვის ახალი ბირთვი. ერთი წლის შემდეგ, ეს ექსპერიმენტული ფუნქცია შეიძლება დასრულდეს განახლებულ RHEL, SLES ან Ubuntu-ში.

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

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

პირადად მე მაინტერესებდა Elbrus OS-ის ექსპერიმენტი. Veeam-ის პაკეტის დასრულების შემდეგ ჩვენი პროდუქტი დამონტაჟდა და მუშაობდა. მე დავწერე ამ ექსპერიმენტის შესახებ ჰაბრეზე მუხლი.

ისე, ახალი დისტრიბუციების მხარდაჭერა გრძელდება. ველოდებით 4.0 ვერსიის გამოშვებას. ბეტა მალე გამოჩნდება, ასე რომ თვალი ადევნეთ რა არის ახალი!

წყარო: www.habr.com