Eng Backup-Applikatioun erstellen déi op all Verdeelung funktionnéiert ass keng einfach Aufgab. Fir sécherzestellen datt Veeam Agent fir Linux op Verdeelunge vu Red Hat 6 an Debian 6, op OpenSUSE 15.1 an Ubuntu 19.04 funktionnéiert, musst Dir eng Rei vu Probleemer léisen, besonnesch wann Dir bedenkt datt de Softwareprodukt e Kernelmodul enthält.
Den Artikel gouf erstallt op Basis vu Materialien aus enger Ried op der Konferenz .
Linux ass net nëmmen ee vun de populäersten Betribssystemer. Weesentlechen ass dëst eng Plattform op der Basis vun där Dir eppes eenzegaarteg, eppes vun Ärem eegene maachen kann. Dank dësem huet Linux vill Verdeelungen déi sech an hirem Set vu Softwarekomponenten ënnerscheeden. An hei entsteet e Problem: fir datt e Softwareprodukt op all Verdeelung funktionnéiert, musst Dir d'Features vun all eenzel berücksichtegen.
Package Manager. .deb vs .rpm
Loosst eis mam offensichtleche Problem ufänken fir de Produkt iwwer verschidde Verdeelungen ze verdeelen.
Déi typeschst Manéier fir Softwareprodukter ze verdeelen ass de Package op e Repository ze setzen, sou datt de Package Manager, deen an de System agebaut ass, et vun do aus installéiere kann.
Wéi och ëmmer, mir hunn zwee populär Package Formater: rpm и deb. Dëst bedeit datt jidderee muss ënnerstëtzen.
An der Welt vun Deb Packagen ass den Niveau vun der Kompatibilitéit erstaunlech. Deeselwechte Package installéiert a funktionnéiert gläich gutt op Debian 6 an Ubuntu 19.04. D'Standarden fir de Prozess vu Paketen ze bauen a mat hinnen ze schaffen, festgeluecht an alen Debian Verdeelungen, bleiwen relevant am neie Linux Mint an elementar OS. Dofir, am Fall vum Veeam Agent fir Linux, ass een Deb Package fir all Hardwareplattform genuch.
Awer an der Welt vun Rpm Packagen sinn d'Ënnerscheeder grouss. Éischtens, wéinst der Tatsaach datt et zwee komplett onofhängeg Distributeuren sinn, Red Hat an SUSE, fir déi d'Kompatibilitéit komplett onnéideg ass. Zweetens, dës Distributeuren hunn Verdeelungskits vun deenen. Ënnerstëtzung an experimentell. Et ass och kee Besoin fir Kompatibilitéit tëscht hinnen. Et huet sech erausgestallt datt el6, el7 an el8 hir eege Packagen hunn. Separat Package fir Fedora. Packagen fir SLES11 an 12 an eng separat fir openSUSE. Den Haaptproblem ass Ofhängegkeeten a Paketnamen.
Ofhängegkeet Problem
Leider kommen déiselwecht Packagen dacks ënner verschiddenen Nimm a verschiddene Verdeelungen. Drënner ass eng deelweis Lëscht vu veeam Package Ofhängegkeeten.
Fir EL7:
Fir SLES 12:
- libbl
- libgcc
- libstdc++
- ncurses-libs
- fuse-libs
- Datei-libs
- veeamsnap=3.0.2.1185
- libbl 1
- libgcc_s1
- libstdc++6
- libmagic1
- libfus2
- veeamsnap-kmp=3.0.2.1185
Als Resultat ass d'Lëscht vun Ofhängegkeeten eenzegaarteg fir d'Verdeelung.
Wat méi schlëmm gëtt ass wann eng aktualiséiert Versioun ufänkt ënner dem alen Package Numm ze verstoppen.
Beispill:
De Package gouf am Fedora 24 aktualiséiert ncurses vun der Versioun 5 bis Versioun 6. Eist Produkt gouf mat der Versioun gebaut 5 fir Kompatibilitéit mat eelere Verdeelungen ze garantéieren. Fir déi al 5. Versioun vun der Bibliothéik op Fedora 24 ze benotzen, muss ech de Package benotzen ncurses-compat-libs.
Als Resultat ginn et zwee Packagen fir Fedora, mat verschiddenen Ofhängegkeeten.
Weider méi interessant. Nom nächste Verdeelungsupdate gëtt de Package ncurses-compat-libs mat der Versioun 5 vun der Bibliothéik stellt sech eraus datt et net verfügbar ass. Et ass deier fir en Distributeur al Bibliothéiken an eng nei Versioun vun der Verdeelung ze zéien. No enger Zäit huet de Problem sech a SUSE Verdeelungen widderholl.
Als Resultat hunn e puer Verdeelungen hir explizit Ofhängegkeet misse falen ncurses-libs, a fixéiert de Produit sou datt et mat all Versioun vun der Bibliothéik funktionnéiert.
Iwwregens, an der Versioun 8 vum Red Hat gëtt et kee Meta Package méi Python, déi op déi gutt al bezeechent Python 2.7... do ass python2 и Python3.
Alternativ zu Package Manager
De Problem mat Ofhängegkeeten ass al an ass laang offensichtlech. Erënneren Just Ofhängegkeet Hell.
Fir verschidde Bibliothéiken an Uwendungen ze kombinéieren sou datt se all stabil funktionnéieren an net konflikt sinn - tatsächlech ass dat d'Aufgab déi all Linux Distributeur probéiert ze léisen.
De Package Manager probéiert dëse Problem op eng ganz aner Manéier ze léisen. Snappy aus Canonical. D'Haaptidee: d'Applikatioun leeft an enger Sandkëscht isoléiert a geschützt vum Haaptsystem. Wann eng Applikatioun Bibliothéike erfuerdert, gi se mat der Applikatioun selwer geliwwert.
Flatpak erlaabt Iech och Uwendungen an enger Sandkëscht mat Linux Container ze lafen. D'Sandbox Iddi gëtt och benotzt AppImage.
Dës Léisungen erlaben Iech ee Package fir all Verdeelung ze kreéieren. Am Fall vun Flatpak Installatioun a Start vun der Applikatioun ass méiglech och ouni d'Wëssen vum Administrator.
Den Haaptproblem ass datt net all Applikatiounen an enger Sandkëscht lafen kënnen. E puer Leit brauchen direkten Zougang zu der Plattform. Ech schwätzen net mol vu Kernel Moduler, déi strikt vum Kernel ofhängeg sinn an net an d'Sandboxkonzept passen.
Den zweete Problem ass datt d'Verdeelunge populär an der Enterprise-Ëmfeld vu Red Hat a SUSE nach keng Ënnerstëtzung fir Snappy a Flatpak enthalen.
An dëser Hisiicht ass Veeam Agent fir Linux net verfügbar net op .
Fir d'Fro iwwer Packagemanager ofzeschléissen, wëll ech bemierken datt et eng Optioun ass fir Packagemanager ganz opzeginn andeems Dir binär Dateien an e Skript kombinéiere fir se an ee Package z'installéieren.
Sou e Bündel erlaabt Iech e gemeinsame Package fir verschidde Verdeelungen a Plattformen ze kreéieren, en interaktiven Installatiounsprozess auszeféieren, déi néideg Personnalisatioun auszeféieren. Ech hunn nëmmen esou Pakete fir Linux vu VMware begéint.
Update Problem
Och wann all Ofhängegkeetsprobleemer geléist sinn, kann de Programm op der selwechter Verdeelung anescht lafen. Et ass eng Fro vun Updates.
Et ginn 3 Updatestrategien:
- Am einfachsten ass et ni ze aktualiséieren. Ech hunn de Server opgeriicht an hunn et vergiess. Firwat update wann alles funktionnéiert? Probleemer fänken un déi éischte Kéier wann Dir Support kontaktéiert. Den Ersteller vun der Verdeelung ënnerstëtzt nëmmen déi aktualiséiert Verëffentlechung.
- Dir kënnt den Distributeur vertrauen an automatesch Updates opsetzen. An dësem Fall ass en Uruff fir Ënnerstëtzung méiglecherweis direkt no engem net erfollegräichen Update.
- D'Optioun fir manuell Aktualiséierung nëmmen nodeems se op enger Testinfrastruktur lafen ass déi zouverlässeg, awer deier an Zäitopwendeg. Net jiddereen kann et leeschten.
Well verschidde Benotzer verschidden Updatestrategien benotzen, ass et néideg souwuel déi lescht Verëffentlechung wéi och all déi virdrun verëffentlecht ze ënnerstëtzen. Dëst komplizéiert souwuel den Entwécklungs- an Testprozess a füügt Kappwéi fir d'Ënnerstëtzungsteam.
Varietéit vun Hardware Plattformen
Verschidde Hardwareplattformen sinn e Problem dee gréisstendeels spezifesch ass fir gebierteg Code. Op e Minimum musst Dir Binäre fir all ënnerstëtzt Plattform sammelen.
Am Veeam Agent fir Linux Projet kënne mir nach ëmmer näischt wéi dësen RISC ënnerstëtzen.
Ech wäert net iwwer dëst Thema am Detail schwächen. Ech wäert nëmmen d'Haaptproblemer skizzéieren: Plattform-ofhängeg Typen, wéi z size_t, Struktur Ausrichtung an Byte Uerdnung.
Statesch an / oder dynamesch Verknëppung
Awer d'Fro ass "Wéi verlinkt ech mat Bibliothéiken - dynamesch oder statesch?" wäert diskutéieren.
Als Regel, benotzen C / C ++ Uwendungen ënner Linux dynamesch Verknëppung. Dëst funktionnéiert super wann d'Applikatioun speziell fir eng spezifesch Verdeelung gebaut ass.
Wann d'Aufgab ass verschidde Verdeelunge mat enger binärer Datei ze decken, da musst Dir op déi eelst ënnerstëtzt Verdeelung konzentréieren. Fir eis ass dëst Red Hat 6. Et enthält gcc 4.4, wat och den C++11 Standard net ënnerstëtzt .
Mir bauen eise Projet mat gcc 6.3, deen C++14 voll ënnerstëtzt. Natierlech, an dësem Fall, op Red Hat 6 musst Dir de libstdc ++ droen an d'Bibliothéike mat Iech stäerken. Deen einfachste Wee ass fir se statesch ze verbannen.
Awer leider, net all Bibliothéike kënne statesch verlinkt ginn.
Als éischt, Systembibliothéiken wéi libfuse, libbl et ass néideg dynamesch ze verbannen fir hir Kompatibilitéit mam Kernel a senge Moduler ze garantéieren.
Zweetens gëtt et eng Subtilitéit mat Lizenzen.
D'GPL Lizenz erlaabt Iech grondsätzlech Bibliothéiken nëmme mat Opensource Code ze verbannen. MIT an BSD erlaben statesch Verknëppung an erlaben Bibliothéiken an engem Projet abegraff. Awer d'LGPL schéngt net statesch Verknëppung widdersprécht, awer erfuerdert datt d'Fichier'en déi néideg sinn fir ze verbannen, gedeelt ginn.
Am Allgemengen, benotzt dynamesch Verknëppung verhënnert datt Dir eppes musst ubidden.
C / C ++ Uwendungen bauen
Fir C/C++ Uwendungen fir verschidde Plattformen a Verdeelungen ze bauen, ass et genuch fir eng gëeegent Versioun vu gcc ze wielen oder ze bauen a Cross-Compiler fir spezifesch Architekturen ze benotzen an de ganze Set vu Bibliothéiken ze sammelen. Dës Aarbecht ass ganz machbar, awer zimlech lästeg. An et gëtt keng Garantie datt de gewielte Compiler a Bibliothéiken eng funktionéierbar Versioun ubidden.
En offensichtleche Virdeel: d'Infrastruktur ass immens vereinfacht, well de ganze Bauprozess op enger Maschinn ofgeschloss ka ginn. Zousätzlech ass et genuch fir e Set vu Binären fir eng Architektur ze sammelen an Dir kënnt se a Packagen fir verschidde Verdeelungen packen. Dëst ass wéi veeam Packagen fir Veeam Agent fir Linux gebaut ginn.
Am Géigesaz zu dëser Optioun, kënnt Dir einfach e bauen Bauerenhaff preparéieren, dat ass, e puer Maschinnen fir Assemblée. All esou Maschinn gëtt Applikatioun Kompilatioun a Pak Assemblée fir eng spezifesch Verdeelung an eng spezifesch Architektur. An dësem Fall gëtt d'Kompilatioun duerchgefouert mat de Mëttele virbereet vum Distributeur. Dat ass, d'Bühn vum Compiler virzebereeden a Bibliothéiken auswielen ass eliminéiert. Zousätzlech kann de Bauprozess einfach paralleliséiert ginn.
Et gëtt awer en Nodeel fir dës Approche: fir all Verdeelung an der selwechter Architektur musst Dir Ären eegene Set vu binäre Dateien sammelen. En aneren Nodeel ass datt sou eng grouss Zuel vu Maschinnen erhale muss ginn an eng grouss Quantitéit un Disk Space an RAM muss zougedeelt ginn.
Dëst ass wéi KMOD Packagen vum veeamsnap Kernel Modul fir Red Hat Verdeelungen kompiléiert sinn.
Open Build Service
D'Kollege vun der SUSE hu probéiert e Mëttelwee ëmzesetzen a Form vun engem speziellen Service fir Uwendungen ze kompiléieren a Packagen ze sammelen - .
Wesentlech ass et en Hypervisor deen eng virtuell Maschinn erstellt, all déi néideg Pakete dran installéiert, d'Applikatioun kompiléiert an de Package an dësem isoléierten Ëmfeld baut, duerno gëtt déi virtuell Maschinn verëffentlecht.
De Scheduler, deen am OpenBuildService implementéiert ass, wäert bestëmmen wéivill virtuell Maschinnen et fir eng optimal Packagebaugeschwindegkeet lancéiere kann. Den agebaute Ënnerschrëftmechanismus ënnerschreift d'Packagen an lued se an de agebaute Repository erop. Den agebaute Versiounskontrollsystem späichert d'Geschicht vun den Ännerungen a Builds. Alles wat bleift ass einfach Är Quellen un dëse System ze addéieren. Dir musst net emol de Server selwer opstellen; Dir kënnt en oppene benotzen.
Et gëtt awer e Problem: esou eng Ernte ass schwéier an déi bestehend Infrastruktur ze passen. Zum Beispill ass d'Versiounskontroll net néideg; mir hu schonn eis eege Quellcodes. Eis Ënnerschrëft Mechanismus ass anescht: mir benotzen e spezielle Server. E Repository ass och net néideg.
Zousätzlech ass Ënnerstëtzung fir aner Verdeelungen - zum Beispill Red Hat - zimlech schlecht ëmgesat, wat verständlech ass.
De Virdeel vun esou engem Service ass séier Ënnerstëtzung fir déi nächst Versioun vun der SUSE Verdeelung. Virun der offizieller Ukënnegung vun der Verëffentlechung ginn d'Packagen, déi fir d'Versammlung néideg sinn, op engem ëffentleche Repository gepost. En neien erschéngt an der Lëscht vun verfügbare Verdeelungen op OpenBuildService. Mir kontrolléieren d'Këscht an et gëtt an de Bauplang bäigefüügt. Also gëtt eng nei Versioun vun der Verdeelung bäigefüügt a bal engem Klick gemaach.
An eiser Infrastruktur, mat OpenBuildService, gëtt déi ganz Varietéit vu KMP Packagen vum veeamsnap Kernel Modul fir SUSE Verdeelungen zesummegesat.
Als nächst géif ech gär op Themen wunnen spezifesch fir Kernel Moduler.
kernel ABI
Linux Kernel Moduler sinn historesch a Quellform verdeelt ginn. D'Tatsaach ass datt d'Creatoren vum Kernel sech net belaaschten mat der Suerg fir eng stabil API fir Kernelmoduler z'ënnerstëtzen, a besonnesch um binäre Niveau, weider als kABI bezeechent.
Fir e Modul fir e Vanillekär ze bauen, braucht Dir definitiv d'Header vun dësem speziellen Kernel, an et funktionnéiert nëmmen op dësem Kernel.
DKMS erlaabt Iech de Prozess vum Bau vun Moduler ze automatiséieren wann Dir de Kernel aktualiséiert. Als Resultat benotzen d'Benotzer vum Debian Repository (a seng vill Verwandten) Kernel Moduler entweder aus dem Distributeur Repository oder kompiléiert aus Quell mat DKMS.
Wéi och ëmmer, dës Situatioun passt net besonnesch dem Enterprise Segment. Propriétaire Code Distributeuren wëllen d'Produkt als kompiléiert Binäre verdeelen.
Administrateuren wëllen net Entwécklungsinstrumenter op Produktiounsserver aus Sécherheetsgrënn halen. Enterprise Linux Distributeuren wéi Red Hat an SUSE hunn decidéiert datt se stabile kABI fir hir Benotzer ënnerstëtzen. D'Resultat war KMOD Packagen fir Red Hat a KMP Packagen fir SUSE.
D'Essenz vun dëser Léisung ass ganz einfach. Fir eng spezifesch Versioun vun der Verdeelung gëtt de Kernel API gefruer. Den Distributeur seet datt hien de Kernel benotzt, zum Beispill 3.10, a mécht nëmme Korrekturen a Verbesserungen, déi d'Kernel-Interfaces net beaflossen, an d'Moduler, déi fir den alleréischte Kernel gesammelt ginn, kënne fir all spéider ouni Rekompiléierung benotzt ginn.
Red Hat behaapt kABI Kompatibilitéit fir d'Verdeelung duerch säi ganze Liewenszyklus. Dat ass, de versammelt Modul fir rhel 6.0 (Verëffentlechung November 2010) soll och op Versioun 6.10 (Verëffentlechung Juni 2018) schaffen. An dat ass bal 8 Joer. Natierlech ass dës Aufgab zimlech schwéier.
Mir hunn e puer Fäll opgeholl wou de veeamsnap Modul opgehalen huet ze schaffen wéinst kABI Kompatibilitéitsprobleemer.
Nom veeamsnap Modul, kompiléiert fir RHEL 7.0, huet sech als inkompatibel mam Kernel aus RHEL 7.5 erausgestallt, awer et ass gelueden a war garantéiert de Server ze crashen, hu mir d'Benotzung vu kABI Kompatibilitéit fir RHEL 7 ganz opginn.
De Moment enthält de KMOD Package fir RHEL 7 eng Versammlung fir all Verëffentlechungsversioun an e Skript deen de Modul lued.
SUSE huet d'Aufgab vun der kABI Kompatibilitéit méi suergfälteg ugeholl. Si bidden kABI Kompatibilitéit nëmmen an engem Service Pack.
Zum Beispill huet d'Verëffentlechung vu SLES 12 am September 2014 stattfonnt. A SLES 12 SP1 war schonn am Dezember 2015, dat heescht e bësse méi wéi ee Joer ass vergaangen. Och wa béid Verëffentlechungen den 3.12 Kernel benotzen, si se kABI inkompatibel. Natierlech ass d'KABI Kompatibilitéit fir just ee Joer vill méi einfach. Den alljährlechen Kernel Modul Update Zyklus sollt keng Probleemer fir Modul Creatoren verursaachen.
Als Resultat vun dëser SUSE Politik hu mir keen eenzege Problem mat kABI Kompatibilitéit an eisem veeamsnap Modul opgeholl. Richteg, d'Zuel vun de Packagen fir SUSE ass bal eng Uerdnung vun der Gréisst méi grouss.
Patches a Backports
Obwuel Distributeuren probéieren d'KABI Kompatibilitéit an d'Kernelstabilitéit ze garantéieren, probéieren se och d'Performance ze verbesseren an Mängel vun dësem stabile Kernel ze eliminéieren.
Zur selwechter Zäit, zousätzlech zu hiren eegene "Aarbecht op Feeler", iwwerwaachen d'Entwéckler vum Enterprise Linux Kernel Ännerungen am Vanillekär an iwwerdroen se op hir "stabil".
Heiansdo féiert dat zu neier .
An der leschter Verëffentlechung vu Red Hat 6 gouf e Feeler an engem vun de klengen Updates gemaach. Et huet zu der Tatsaach gefouert datt de veeamsnap Modul garantéiert war fir de System ze crashen wann de Snapshot verëffentlecht gouf. Nodeems mir d'Kernelquellen virum an nom Update verglach hunn, hu mir erausfonnt datt de Backport d'Schold war. Eng ähnlech Fix gouf an der Vanillekär Versioun 4.19 gemaach. Et ass just datt dës Fix gutt am Vanillekär geschafft huet, awer wann Dir et op de "Stall" 2.6.32 transferéiert, ass e Problem mam Spinlock entstanen.
Natierlech huet jiddereen ëmmer Feeler, awer war et derwäert de Code vun 4.19 op 2.6.32 ze zéien, Stabilitéit riskéieren?.. Ech sinn net sécher ...
Dat Schlëmmst ass, wann de Marketing sech an den Tug-of-Krich tëscht "Stabilitéit" an "Moderniséierung" bedeelegt. D'Marketing Departement brauch de Kär vun der aktualiséierter Verdeelung fir stabil ze sinn, engersäits, a gläichzäiteg besser an der Leeschtung an nei Fonctiounen ze hunn. Dëst féiert zu komeschen Kompromëss.
Wann ech probéiert e Modul op Kernel 4.4 aus SLES 12 SP3 ze bauen, Ech war iwwerrascht Funktionalitéit vun Vanill 4.8 an et ze fannen. Menger Meenung no ass d'Block I / O Implementatioun vum 4.4 Kernel vum SLES 12 SP3 méi ähnlech wéi den 4.8 Kernel wéi déi fréier Verëffentlechung vum stabilen 4.4 Kernel vum SLES12 SP2. Ech kann net beurteelen wéi ee Prozentsaz vum Code vum Kernel 4.8 op SLES 4.4 fir SP3 transferéiert gouf, awer ech kann de Kernel net emol déiselwecht stabil 4.4 nennen.
Déi onangenehmst Saach iwwer dëst ass datt wann Dir e Modul schreift deen gläich gutt op verschiddene Kärelen funktionnéiert, kënnt Dir net méi op d'Kernelversioun vertrauen. Dir musst och d'Verdeelung berücksichtegen. Et ass gutt datt Dir heiansdo an enger Definitioun involvéiert kënnt, déi zesumme mat neier Funktionalitéit erschéngt, awer dës Geleeënheet erschéngt net ëmmer.
Als Resultat gëtt de Code iwwerwältegt mat komeschen bedingte Kompiléierungsdirektiven.
Et ginn och Patches déi den dokumentéierten Kernel API änneren.
Ech sinn op d'Verdeelung komm 5.16 a war ganz iwwerrascht ze gesinn datt de Lookup_bdev Uruff an dëser Kernel Versioun d'Lëscht vun den Inputparameter geännert huet.
Fir et zesummen ze kréien, hunn ech e Skript an d'Makefile missen addéieren, déi iwwerpréift ob d'lookup_bdev Funktioun e Maskparameter huet.
Ënnerschreiwe Kernel Moduler
Awer loosst eis zréck op d'Fro vun der Packageverdeelung.
Ee vun de Virdeeler vu stabile kABI ass datt Kernelmoduler als binär Datei ënnerschriwwe kënne ginn. An dësem Fall kann den Entwéckler sécher sinn datt de Modul net zoufälleg beschiedegt oder bewosst geännert gouf. Dir kënnt dëst mam Modinfo Kommando kontrolléieren.
Red Hat an SUSE Verdeelungen erlaben Iech d'Ënnerschrëft vum Modul z'iwwerpréiwen an ze lueden nëmmen wann de entspriechende Zertifika um System registréiert ass. De Certificat ass den ëffentleche Schlëssel mat deem de Modul ënnerschriwwen ass. Mir verdeelen et als separat Package.
De Problem hei ass datt Certificaten entweder an de Kernel gebaut kënne ginn (Verdeeler benotzen se) oder mussen op EFI net-flüchteg Erënnerung geschriwwe ginn mat engem Utility mokutil. Utility mokutil Wann Dir e Certificat installéiert, erfuerdert Dir de System nei ze starten an, och ier Dir de Kernel vum Betribssystem lued, freet den Administrator fir en neien Zertifika ze lueden.
Also, e Certificat derbäizefügen erfuerdert kierperlechen Administrateur Zougang zum System. Wann d'Maschinn iergendwou an der Wollek oder einfach an engem Remote Serverraum läit an den Zougang nëmmen iwwer d'Netzwierk ass (zum Beispill iwwer ssh), da wäert et onméiglech sinn en Zertifika ze addéieren.
EFI op virtuelle Maschinnen
Trotz der Tatsaach, datt EFI laang duerch bal all Motherboard Hiersteller ënnerstëtzt gouf, wann Dir e System installéiert, kann den Administrator net iwwer d'Bedierfnes fir EFI denken, an et kann ausgeschalt ginn.
Net all Hypervisoren ënnerstëtzen EFI. VMWare vSphere ënnerstëtzt EFI ab Versioun 5.
Microsoft Hyper-V krut och EFI Ënnerstëtzung ugefaange mat Hyper-V fir Windows Server 2012R2.
Wéi och ëmmer, an der Standardkonfiguratioun ass dës Funktionalitéit fir Linux Maschinnen ausgeschalt, dat heescht datt de Certificat net installéiert ka ginn.
An vSphere 6.5, Formatioun der Optioun Secure Boot nëmmen méiglech an der aler Versioun vun der Web Interface, déi leeft iwwer Flash. Web UI op HTML-5 ass nach ëmmer wäit hannendrun.
Experimentell Verdeelungen
A schliisslech, loosst eis d'Thema vun experimentellen Verdeelungen a Verdeelungen ouni offiziell Ënnerstëtzung betruechten. Engersäits sinn esou Verdeelungen onwahrscheinlech op de Servere vu seriöen Organisatiounen ze fannen. Et gëtt keng offiziell Ënnerstëtzung fir sou Verdeelungen. Dofir, gitt déi. De Produit kann net op esou enger Verdeelung ënnerstëtzt ginn.
Wéi och ëmmer, sou Verdeelunge ginn eng praktesch Plattform fir nei experimentell Léisungen auszeprobéieren. Zum Beispill Fedora, OpenSUSE Tumbleweed oder Unstable Versioune vun Debian. Si sinn zimlech stabil. Si hunn ëmmer nei Versioune vu Programmer an ëmmer en neie Kärel. An engem Joer kann dës experimentell Funktionalitéit an engem aktualiséierten RHEL, SLES oder Ubuntu ophalen.
Also wann eppes net un enger experimenteller Verdeelung funktionnéiert, ass dëst e Grond fir de Problem erauszefannen an ze léisen. Dir musst op d'Tatsaach virbereet sinn datt dës Funktionalitéit geschwënn op de Produktiounsserver vun de Benotzer erschéngt.
Dir kënnt déi aktuell Lëscht vun offiziell ënnerstëtzte Verdeelunge fir Versioun 3.0 studéieren . Awer déi richteg Lëscht vu Verdeelungen op deenen eise Produkt ka schaffen ass vill méi breet.
Perséinlech war ech interesséiert am Experiment mam Elbrus OS. Nodeems de Veeam Package finaliséiert gouf, gouf eise Produkt installéiert a funktionnéiert. Ech hunn iwwer dëst Experiment op Habré geschriwwen .
Gutt, Ënnerstëtzung fir nei Verdeelunge geet weider. Mir waarden op d'Versioun 4.0 fir verëffentlecht ze ginn. Beta ass amgaang ze erschéngen, also kuckt op !
Source: will.com