Applicationem subsidiariam creare quae in qualibet distributione operatur difficile est. Ut operationem Veeam Agent pro... Linux in distributionibus ex Red Hat 6 et Debian 6, usque ad OpenSUSE 15.1 et Ubuntu Versione 19.04 seriem difficultatum tractandarum habet, praesertim cum programmatum modulum nuclei includat.
Articulus creatus est ex materia ex oratione in colloquio .
Linux — non solum unum ex systematibus operandis popularissimis est. Est essentialiter suggestum in quo aliquid singulare, aliquid tuum proprium, creare potes. Gratias huic, Linux Multae distributiones sunt, quarum unaquaeque suum proprium programmatum apparatum habet. Et hic problema oritur: ut programmatum in quavis distributione fungatur, cuiusque propriae proprietates considerandae sunt.
Sarcina mancipes. .deb .rpm . vs
Incipiamus cum manifesto problemate distribuendi productum per diversas distributiones.
Modus typicus ad programmatum distribuendum est sarcina in promptuario imponenda ut sarcina procurator in systema aedificatum inde instituere possit.
Sed duas formas involucrum vulgaris habemus: rPM и deb. Hoc modo quisque erit auxilio.
In mundo fasciculorum deb, gradus compatibilitatis est mirabilis. Idem fasciculus aeque bene in utroque instituitur et operatur. Debian VI, et deinceps Ubuntu 19.04. Normae de processu construendi fasciculos et operandi cum eis, in vetere statutae. Debian distributiones, manent pertinentes in novis Linux Mint et systema operandi elementarium. Ergo, in casu Veeam Agent pro... Linux Unus fasciculus "deb" sufficit pro singulis systematibus apparatuum.
Sed in mundo rpm fasciculorum magnae sunt differentiae. Uno modo, propter hoc quod sunt duo distributores omnino independentes, Rubrum Hat et SUSE, propter quod convenientia omnino necessaria est. Secundo, hi distributores habent ab his ornamenta distribuendi. auxilio et experimentis. Non est opus inter eos vel convenientiam. Contigit quod el6, el7 et el8 suas sarcinas habent. Involucrum separatum pro Fedora. Sarcinae pro SLES11 et 12 et singulae pro openSUSE. Praecipua quaestio est clientelas et sarcina nomina.
Dependentia problema
Infeliciter, iidem fasciculi saepe sub diversis nominibus in diversis distributionibus evadunt. Infra indicem partialem veeam involucrum clientelas est.
Nam EL7;
pro SLES XII;
- libblkid
- libgcc
- libstdc ++
- ncurses-libs
- fuse-libs
- file-libs
- veeamsnap=3.0.2.1185
- libblkid1
- libgcc_s1
- libstdc++6
- libmagic1
- libfuse2
- veeamsnap-kmp=3.0.2.1185
Quam ob rem index clientium singulare est distributioni.
Quod peius est, cum renovatio versionis incipit sub veteri sarcina nomine latens.
exempli gratia:
Sarcina renovata in Fedora 24 ncurses a versione 5 ad versionem 6. Productum nostrum cum versione 5 constructum est ut convenientiam cum distributionibus vetustioribus curet. Uti vetere 5th versione bibliothecae in Fedora 24, Ego uti involucrum habui ncurses-compat-libs.
Quam ob rem duae fasciculi Fedora cum diversis dependentiis sunt.
Praeterea magis placet. Distributio altera post update, sarcina ncurses-compat-libs cum versione 5 bibliothecae evenit ut perpendat. Carum est distributorem vetustas bibliothecas in novam distributionem trahere. Post aliquod tempus quaestio in distributionibus SUSE se repetita est.
Quam ob rem nonnullas distributiones suas explicite dependentiae deponendi erant ncurses-libsac productum ut in quavis versione bibliothecae possit operari.
Obiter in versione 8 rubrae Hat iam non est meta sarcina pythonquae referuntur ad bonum vetus python 2.7. sunt python2 и python3.
Alter ad sarcina managers
Difficultas clientelas vetus est et iam diu patet. Iustus memor Dependentiae inferni.
Varias bibliothecas et applicationes coniungere ut omnes stabile operentur neque inter se discrepent, re vera munus est quod omnis distributor solvere conatur. Linux.
Procurator sarcinarius hoc problema omnino alio modo solvere conatur. RAPIDUS de Canonicis. Praecipua idea: applicatio in sandbox separatim et a principali systematis praesidio decurrit. Si applicatio bibliothecas requirit, ipsi applicatione suppleantur.
Flatpak Etiam tibi permittit applicationes in area probatoria exsequi utens Linux Vasa. Idea areae sabulosae etiam ab AppImage.
Hae solutiones permittunt te unam sarcinam pro quavis distributione creare. In casu Flatpak installation et applicationis fieri potest etiam sine cognitione administratoris.
Praecipuum problema est quod non omnes applicationes in sandbox currere possunt. Quidam recta aditus ad suggestum opus. Nolo quidem de modulis nucleis loqui, quae stricte a nucleo pendent et in conceptu sandbox non conveniunt.
Secundum problema est quod distributiones populares in incepti ambitus a Red Hat et SUSE nondum subsidium Snappy et Flatpak continent.
Hoc respectu, Veeam Agent for Linux nullus est non on- .
Ut quaestionem de actoribus involucris concludas, notare vellem optionem esse ut mancipes sarcinas deserendi omnino componendo binarii fasciculi et scriptum ut eas in unam sarcinam instituas.
Hic fasciculus tibi permittit ut fasciculum unum communemque pro distributionibus et suggestis diversis crees, processum institutionis interactivum perficias, et customizationem necessariam impleas. Tales fasciculos inveni pro... Linux solum a VMware.
Update quaestio
Etiamsi omnes quaestiones dependentiae solvuntur, ratio potest aliter currere in eadem distributione. Res updates est.
Sunt III update consilia:
- Simplicissimum est numquam update. Erexi servo et oblitus est. Cur renovatio si omnia operatur? Problemata incipiunt primum contactum auxilium. Distributionis creator solus renovationem emissionem sustinet.
- Distributori confidere potes et in updates automatice erigere. Hoc in casu, invitatio ad sustentationem statim post infelicis renovationis rationem verisimile est.
- Optio adaequationis manualis solum post currit eam in infrastructura test certissima est, sed pretiosa et temporis edax. Quisque non efficitur est.
Cum diversi utentes utantur diversis rationibus renovationis, necesse est tam recentissimam missionem et omnes antea emissas sustinere. Hoc implicat et processum et evolutionem et probationem et adiungit dolores ad equos sustentandos.
Variis hardware platforms
Tabulae ferrariae variae problemati sunt quae late specificae in codice indigenae sunt. Ad minimum, binarios colligere debebis pro quolibet suggestu sustentato.
In Agente Veeam pro proiecto Linux Nihil adhuc simile RISC sustinere possumus.
Non moror in hac re singillatim. Tantum praecipua problemata effingam: catasta-dependens genera, qualia sunt size_t, structure alignment and byte order.
Static et / vel dynamica conjunctio
Sed quaestio est "Quomodo cum bibliothecis ligare - dynamice vel immobiliter?" discutere dignum est.
Regula generali est ut applicationes C/C++ sint Linux Utere nexibus dynamicis. Hoc optime operatur si applicatio specialiter pro distributione specifica constructa est.
Si negotium est varias distributiones uno fasciculo binario operire, tunc vetustissimam distributionem sustentatam intendunt. Pro nobis hoc pileum rubrum est 6. Continet gcc 4.4, quod etiam vexillum C++11 non sustinet .
Exstruimus consilium nostrum gcc 6.3, quod plene C++14 sustinet. Nempe in hoc casu, in Red Hat 6 libstdc ++ ferre debes et bibliothecas apud te boost. Facillima via est illis immobiliter nectere.
Sed heu, non omnes bibliothecae immobiliter coniungi possunt.
Uno modo, ratio bibliothecarum ut libfuse, libblkid dynamice coniungi necesse est ut eorum compatibilitatem cum nucleo et modulis eius curet.
Secundo subtilitas dissentiet.
Licentia GPL fundamentaliter permittit ut bibliothecas coniungas tantum cum codice opensource. MIT et BSD permittunt nexus stabilis et bibliothecas in materia includi permittunt. Sed LGPL non videtur nexus stabilis contradicere, sed postulat ut fasciculi necessarii ad connexionem communicandam sint.
In genere, per conjunctionem dynamicam prohibebit te habere aliquid providere.
Building C/C++ applications
Ad C/C++ applicationes pro diversis suggestis et distributionibus condere, satis est aptam versionem gcc eligere vel edificare, et compilatores ad specificas architecturas uti, et integram bibliothecam congregare. Hoc opus est satis posse, sed satis molestum. Et nulla est cautio quod delectus compilator et bibliothecae versionem operabilem praebebunt.
Commodum manifestum: infrastructura valde simplificatur, cum totus processus constructionis in una machina perfici possit. Praeterea, sufficit unum fasciculum binariorum pro una architectura construere, et haec fasciculi pro distributionibus diversis includi possunt. Hoc modo Veeam fasciculos pro Veeam Agent pro... Linux.
Obsistenti huic optioni, fundum construere simpliciter potes, id est, plures machinas ad conventum. Quaelibet talis machina applicationem compilationem et sarcinam conventuum praebebit pro certa distributione et specifica architectura. In hoc casu compilatio exercetur instrumentis a distributore praeparatis. Hoc est, scaena apparandi compilator et bibliothecarum selectio eximitur. Praeterea processus aedificandi facile parabilis est.
Est tamen accessus ad hunc descendendum: nam singulae distributio intra eandem architecturam debebis ex fasciculis binariis propriis colligendis. Aliud incommodum est quod tam magnus numerus machinarum conservandus est et magna vis spatii orbis et RAM collocari debet.
Hoc est quomodo KMOD fasciculi nuclei veeamsnap moduli pro distributionibus rubrum Hat compigantur.
Open Service aedificate
Collegae ab SUSE medium quoddam instrumentum efficere conati sunt in forma peculiaris servitii ad applicationes componendas et fasciculos colligendos -. .
Essentialiter hypervisor est qui virtualem machinam creat, omnes sarcinas necessarias in eo installat, applicationem componit et sarcinam in hoc ambitu solitario aedificat, post quem virtualis apparatus emittitur.
Tabularium in OpenBuildService perficiendum decernet quot machinis virtualis in meliorem sarcinam aedificandi celeritatem mittere possit. Constructum in mechanismo signando fasciculos signabit et eas imposuisti in repositorio constructo. Constructum-in versionis ratio imperium servabit historiam mutationum et aedificat. Reliquum est ut fontes tuos huic systemi simpliciter adiiciam. Servum te ne statuas quidem, patenti uti potes.
Difficultas tamen est: talis messor difficile est aptare infrastructuram existentem. Exempli gratia, versionis moderatio non est necessaria, iam nostra habemus ad fontes codicis. Nostra subscriptio mechanismus alia est: speciali servo utimur. Repositorium etiam non opus est.
Praeterea subsidium aliarum distributionum - exempli gratia Red Hat - male impletur, quod intellegibile est.
Talis servitii utilitas celerius subsidium est pro altera versione SUS distributio. Ante nuntium officialem emissionis fasciculi necessarii ad conventum in reposito publico collocantur. Novum apparet in indice distributionum available in OpenBuildService. Arcam reprimimus et consilium aedificandi additur. Ita nova distributio fit in clic fere addita versione.
In nostra infrastructura, utens OpenBuildService, tota varietas sarcinarum KMP fasciculorum nuclei veeamsnap nuclei pro SUSE distributionibus colligitur.
Deinceps de rebus nucleo modulorum specificis immorari vellem.
nucleus ABI
Moduli nuclei Linux Historice, in forma codicis fontis distributae sunt. Problema est quod creatores nuclei non curant API stabilem pro modulis nuclei conservare, nedum in gradu binario (deinceps kABI).
Modulum pro vanilla nucleo condere, certo nucleo capitis huius maxime indigere, et in hoc nucleo tantum operari.
DKMS automationem constructionis modulorum per renovationes nuclei permittit. Quam ob rem, usores repositorii... Debian (et multae cognatae eius) modulos nuclei vel ex repositorio distributoris vel ex fonte per DKMS compilatos utuntur.
Nihilominus, haec condicio segmento Enterprise non apprime convenit. Codicis proprietarii distributores productum distribuere volunt binarios compilato.
Administratores instrumenta progressionis in servitoribus productionis propter rationes securitatis servare nolunt. Distributores Societatum. Linux — velut Red Hat et SUSE — constituerunt se kABI stabilem pro usoribus suis sustinere posse. Propterea, fasciculi KMOD pro Red Hat et fasciculi KMP pro SUSE creati sunt.
Essentia huius solutionis est omnino simplex. Ad certam versionem distributionis, API nucleus constringitur. Distributor asserit se nucleo utatur, exempli gratia, 3.10, et correctiones tantum et emendationes facit quae nuclei interfaces non tangunt, et moduli ad primum nucleum collecti omnibus subsequentibus sine recompilatione adhiberi possunt.
Red Hat petit congruentiam kABI pro distributione per totam vitam suam. Id est, moduli conglobati pro rhel 6.0 (dimittere November 2010) debet etiam in versione 6.10 operari (dimittere Iunii 2018). Et hoc est fere VIII annis. Naturaliter hoc negotium est difficillimum.
Plures casus notavimus, ubi moduli veeamsnap laborare desierunt propter quaestiones convenientiae kABI.
Post moduli veeamsnap, pro RHEL 7.0 compilata, e Rhel 7.5 nucleo repugnare evasit, sed onustus et confirmatus est in calculonis servi, usum kABI convenientiae pro RHEL 7 omnino deseruimus.
In statu, sarcina KMOD pro RHEL 7 conventum continet pro versione emissione et scriptum quod moduli onerat.
SUSE negotium kABI convenientiae diligentius accessit. Compatibilitatem kABI praebent tantum intra unum sarcinam servitii.
Exempli gratia, emissio SLES 12 mense Septembri 2014. SLES 12 facta est iam mense Decembri 1, hoc est paulo plus quam annus praeteriit. Etiamsi utraque emissio 2015 nucleo utatur, kABI repugnant. Patet, congruentiam servans kABI per annum tantum facilius est. Annuus cycli nuclei moduli renovatio quaestionibus modulis creatoribus causare non debet.
Propter hoc SUSUM consilium, unicum problema cum kABI compatibilitate in moduli veeamsnap nostro not scriptum est. Verum, numerus fasciculorum pro SUSI magnitudine fere maior est.
Resarcio et backports
Etsi distributores conantur ut kABI convenientiam et stabilitatem nuclei, ipsi etiam operas et vitia nuclei huius stabilis eliminare conantur.
Eodem tempore, praeter suos "labores de erroribus", tincidunt incepti monitor nuclei Linux in vanilla nucleos mutat et ad suum "stabulum" unum transferunt.
Interdum hoc ducit ad novos .
In recentissima emissione Rubrum Hat 6, error in una e updates minoris facta est. Hoc factum est ut modulus veeamsnap praestitus est ad systema fragoris cum emissum snapshot. Comparatis fontibus nuclei ante et post renovationem, invenimus backportum reprehendere. Similis fix in vanilla kernel versio 4.19 facta est. Haec fix bene in vanilla nucleo laboravit, sed cum eam ad "stabulum" 2.6.32 transferens, quaestio orta est cum spinlock.
Utique omnes errores semper habet, sed trahere valebat codicem ab 4.19 ad 2.6.32, stabilitatem periclitans?.. Non sum certus...
Gravissimum est cum venalicium implicatur in trahitis bellum inter "stabilitatem" et "modernizationem". Negotiatio venalicium medium eget distributionis renovatae ut stabilis sit, ex una parte, et simul melius in agendis et novas habere lineamenta. Inde novos moderans.
Cum modulum in nucleo 4.4 ex SLES 12 SP3 aedificare conabar, functionalitatem ex vanilla 4.8 in ea invenire miratus sum. Opinor, clausus I/O exsecutio 4.4 nuclei ex SLES 12 SP3 similior est 4.8 nucleo quam prior emissio stabilis 4.4 nuclei ex SLES12 SP2. Quid recipis codicis a nucleo 4.8 ad SLES 4.4 pro SP3 translatum esse iudicare non possum, sed nucleum quidem stabile 4.4.
Incommodum de hoc est quod cum moduli scribentis qui in diversis nucleis aeque bene operaretur, amplius versioni nucleo confidere non possis. Habes etiam rationem distributionis. Bonum est quod interdum in definitione quae cum novis functionibus videtur implicari potes, sed haec opportunitas non semper apparet.
Quam ob rem signum compilation condiciones condicionalis fatum obsita fit.
Sunt etiam inaequalis quae nucleum API mutant in documentis.
Veni per distributionem 5.16 et valde miratus est videre quod lookup_bdev nomen in hac versione nucleo mutavisse indicem parametri input.
Ut simul illud, addere debebam scripturam fabricationis quae impedit num munus lookup_bdev larvatum habeat modulum.
Signing nucleus modulorum
Sed ad eventum distributionis sarcinae revertamur.
Una commoda kABI stabilis est illa moduli nuclei ut fasciculi binarii signari possunt. Hoc in casu, elit certa esse potest modulum non per accidens laesum aut ex intentione mutatum esse. Hoc cum imperio modinfo inspicere potes.
Red Hat and SUSE distributiones sinunt te subscriptionem moduli reprimere et eam onerare tantum si libellum respondentem in systemate relatus sit. Testimonium est clavis publicus quo modulus signatur. Ut sarcina singula distribuimus.
Problema hic est, quod testimoniales vel in nucleo aedificari possunt (distributores illis utuntur) vel scribi debent ad memoriam non-volatilem EFFI utentem utilitatem. mokutil. utilitas mokutil Cum libellum instituens, te requirit ut systema reboet et, etiam antequam nucleum operativae oneraverit, administratorem suggerit ut novum libellum onerandum permittat.
Ita libellum addit accessum ad systema administratorem physicum requirit. Si machina alicubi sita est in nube vel simpliciter in remoto servo cubiculi et accessus est tantum per reticulum (exempli gratia via ssh), tunc impossibile erit libellum addere.
Efi in virtualis machinis
Quamvis hoc quod efi iamdiu ab omnibus fere matricis fabricantibus sustentatum sit, cum systema instituat, administrator cogitare non potest de necessitate efi, et debilitari potest.
Non omnes hypervisores adiuvant efi. VMWare vSphere adminiculum efi incipiens a litera 5 .
Microsoft Hyper-V etiam auxilium EFI accepit, incipiens ab Hyper-V pro Windows Server 2012R2.
Attamen, in configuratione praedefinita haec functio est ad Linux Machina extincta est, quod significat certificatum institui non posse.
In vSphere 6.5, pone optionem Booz vero secure tantum fieri potest in antiqua versione interfaciei interreti, quae per Flash decurrit. Web UI in HTML-V adhuc longe post est.
Distributiones experimentales
Ac denique experimentorum distributionum et distributionum exitus sine subsidio officiali consideremus. Ex altera parte, huiusmodi distributiones in servientibus gravium institutionum reperiri non possunt. Nulla officialis subsidia talibus distributionibus. Eos itaque provident. Productum tali distributione sustineri non potest.
Attamen tales distributiones fiunt suggestum commodum ad novas solutiones experimentales tentandas. Exempli gratia, Fedora, OpenSUSE Tumbleweed, vel versiones Unstable. DebianSatis stabiles sunt. Semper novas programmatum versiones et semper novum nucleum habent. Post annum, haec functio experimentalis in RHEL, SLES, vel renovato inveniri potest. Ubuntu.
Si ergo aliquid in distributione experimentali non operatur, causa est quaestionis figurae et solvendae. Opus est ad hoc parari quod haec functionalitas mox apparebit in servientibus productionis usorum.
Potes studere currenti indicem publice sustentari distributionibus pro versione 3.0 . Sed verus index distributionum in quibus opus nostrum productum potest multo latius patet.
Ipse ego experimentum quaerebam cum Elbrus OS. Post veeam sarcina finalisata, productum nostrum inauguratus est et laborat. Scripsi de hoc experimento in Habre in .
Bene, subsidia novarum distributionum prosequitur. Exspectamus versionem 4.0 dimitti. Beta apparitura est, ita oculum observare !
Source: www.habr.com
