{"id":38929,"date":"2019-10-31T22:26:48","date_gmt":"2019-10-31T19:26:48","guid":{"rendered":"https:\/\/prohoster.info\/blog\/linux-mnogolikij-kak-rabotat-na-lyubom-distributive\/"},"modified":"2019-10-31T22:26:48","modified_gmt":"2019-10-31T19:26:48","slug":"linux-mnogolikij-kak-rabotat-na-lyubom-distributive","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/linux-mnogolikij-kak-rabotat-na-lyubom-distributive","title":{"rendered":"Linux, multiple facettes : comment travailler sur n'importe quelle distribution","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Linux, multiple facettes : comment travailler sur n&#039;importe quelle distribution\" src=\"\/wp-content\/uploads\/2019\/10\/ee1aaad566204532c974a3ce8f13b915.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCr\u00e9er une application de sauvegarde fonctionnant sur n'importe quelle distribution est un d\u00e9fi. Assurer le fonctionnement de Veeam Agent for Linux sur des distributions allant de Red Hat 6 et Debian 6 \u00e0 OpenSUSE 15.1 et Ubuntu 19.04 n\u00e9cessite de r\u00e9soudre un \u00e9ventail de probl\u00e8mes, surtout si l'on consid\u00e8re que le produit comprend un module noyau.<\/p>\n<p>Cet article est bas\u00e9 sur les mat\u00e9riaux pr\u00e9sent\u00e9s lors de la conf\u00e9rence <noindex><a rel=\"nofollow\" href=\"https:\/\/linuxpiter.com\/materials\/2636\"> LinuxPiter 2019<\/a><\/noindex>.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nLinux n'est pas seulement l'un des syst\u00e8mes d'exploitation les plus populaires. En r\u00e9alit\u00e9, c'est une plateforme sur laquelle on peut cr\u00e9er quelque chose d'unique, quelque chose qui nous appartient. Gr\u00e2ce \u00e0 cela, Linux a de nombreuses distributions qui diff\u00e8rent par leur ensemble de composants logiciels. Et ici se pose un probl\u00e8me : pour qu'un produit fonctionne sur n'importe quelle distribution, il faut prendre en compte les particularit\u00e9s de chacune d'entre elles.<\/p>\n<h2>Gestionnaires de paquets. .deb vs .rpm<\/h2>\n<p>\nCommen\u00e7ons par le probl\u00e8me \u00e9vident de la distribution du produit pour diff\u00e9rentes distributions.<br \/>\nLa m\u00e9thode la plus typique de distribution des produits logiciels consiste \u00e0 t\u00e9l\u00e9charger un paquet sur un d\u00e9p\u00f4t, afin que le gestionnaire de paquets int\u00e9gr\u00e9 au syst\u00e8me puisse l'installer \u00e0 partir de l\u00e0.<br \/>\nCependant, nous avons deux formats de paquets populaires : <i>rpm<\/i> et <i>deb<\/i>. Cela signifie qu'il faut supporter chacun d'eux.<\/p>\n<p>Dans le monde des paquets deb, le niveau de compatibilit\u00e9 est incroyable. Un m\u00eame paquet s'installe et fonctionne \u00e9galement bien sur Debian 6 et Ubuntu 19.04. Les standards du processus de construction des paquets et de travail avec eux, \u00e9tablis dans les anciennes distributions Debian, demeurent pertinents dans les distributions modernes comme Linux Mint et elementary OS. Ainsi, pour Veeam Agent for Linux, un seul paquet deb est suffisant pour chaque plateforme mat\u00e9rielle.<\/p>\n<p>En revanche, dans le monde des paquets rpm, les diff\u00e9rences sont consid\u00e9rables. Tout d'abord, parce qu'il existe deux distributeurs compl\u00e8tement ind\u00e9pendants, Red Hat et SUSE, pour lesquels la compatibilit\u00e9 n'est pas n\u00e9cessaire. Deuxi\u00e8mement, ces distributeurs ont des distributions avec support technique et exp\u00e9rimentales. Entre elles, la compatibilit\u00e9 n'est pas non plus n\u00e9cessaire. Nous nous retrouvons donc avec des paquets distincts pour el6, el7 et el8. Un paquet s\u00e9par\u00e9 pour Fedora. Des paquets pour SLES11 et 12 ainsi qu'un s\u00e9par\u00e9 pour openSUSE. Le principal probl\u00e8me r\u00e9side dans les d\u00e9pendances et les noms des paquets. <\/p>\n<h2>Probl\u00e8me des d\u00e9pendances<\/h2>\n<p>\nMalheureusement, les m\u00eames paquets apparaissent souvent sous des noms diff\u00e9rents selon les distributions. Voici une liste non exhaustive des d\u00e9pendances du paquet veeam.<\/p>\n<p>Pour EL7 :<br \/>\nPour SLES 12 :<\/p>\n<ul>\n<li>libblkid<\/li>\n<li>libgcc<\/li>\n<li>libstdc++<\/li>\n<li>ncurses-libs<\/li>\n<li>fuse-libs<\/li>\n<li>file-libs<\/li>\n<li>veeamsnap = 3.0.2.1185<\/li>\n<\/ul>\n<ul>\n<li>libblkid1<\/li>\n<li>libgcc_s1<\/li>\n<li>libstdc++6<\/li>\n<li>libmagic1<\/li>\n<li>libfuse2<\/li>\n<li>veeamsnap-kmp = 3.0.2.1185<\/li>\n<\/ul>\n<p>\nEn cons\u00e9quence, la liste des d\u00e9pendances est unique pour la distribution. <\/p>\n<p>C'est encore pire lorsque la nouvelle version se cache sous l'ancien nom du paquet. <\/p>\n<p><b>Exemple :<\/b><\/p>\n<p>Dans Fedora 24, le paquet a \u00e9t\u00e9 mis \u00e0 jour <i>ncurses<\/i> de la version 5 \u00e0 la version 6. Notre produit \u00e9tait construit pr\u00e9cis\u00e9ment avec la version 5 pour assurer la compatibilit\u00e9 avec les anciennes distributions. Pour pouvoir utiliser l'ancienne version 5 de la biblioth\u00e8que sur Fedora 24, il a fallu utiliser le paquet <i>ncurses-compat-libs<\/i>. <\/p>\n<p>En cons\u00e9quence, deux paquets apparaissent pour Fedora, avec des d\u00e9pendances diff\u00e9rentes. <\/p>\n<p>C'est encore plus int\u00e9ressant. Apr\u00e8s une nouvelle mise \u00e0 jour de la distribution, le paquet <i>ncurses-compat-libs<\/i> avec la version 5 de la biblioth\u00e8que devient indisponible. Pour le distributeur, il est co\u00fbteux de tirer les anciennes biblioth\u00e8ques vers la nouvelle version de la distribution. Apr\u00e8s un certain temps, le probl\u00e8me s'est r\u00e9p\u00e9t\u00e9 dans les distributions SUSE.<\/p>\n<p>En cons\u00e9quence, pour certaines distributions, il a fallu renoncer \u00e0 une d\u00e9pendance explicite envers <i>ncurses-libs<\/i>, et ajuster le produit pour qu'il puisse fonctionner avec n'importe quelle version de la biblioth\u00e8que.<\/p>\n<p>\u00c0 propos, dans la 8e version de Red Hat, il n'y a plus de m\u00e9ta-paquet <i>python<\/i>, qui faisait r\u00e9f\u00e9rence au bon vieux <i>python 2.7<\/i>. Il y a <i>python2<\/i> et <i>python<\/i>3. <\/p>\n<h2>L'alternative aux gestionnaires de paquets<\/h2>\n<p>\nLe probl\u00e8me des d\u00e9pendances est ancien et \u00e9vident depuis longtemps. Il suffit de se souvenir de l'enfer des d\u00e9pendances. <br \/>\nUnir diverses biblioth\u00e8ques et applications de mani\u00e8re \u00e0 ce qu'elles fonctionnent toutes de mani\u00e8re stable et sans conflit \u2014 c'est pr\u00e9cis\u00e9ment ce que tout distributeur Linux tente de r\u00e9soudre.<\/p>\n<p>C'est d'une mani\u00e8re compl\u00e8tement diff\u00e9rente que le gestionnaire de paquets <b>Snappy<\/b> de Canonical tente de r\u00e9soudre ce probl\u00e8me. L'id\u00e9e principale : l'application s'ex\u00e9cute dans un bac \u00e0 sable isol\u00e9 et prot\u00e9g\u00e9 du syst\u00e8me principal. Si l'application a besoin de biblioth\u00e8ques, elles sont fournies avec l'application elle-m\u00eame.<\/p>\n<p><b>Flatpak<\/b> permet \u00e9galement de lancer des applications dans un bac \u00e0 sable, en utilisant les conteneurs Linux. L'id\u00e9e du bac \u00e0 sable est \u00e9galement utilis\u00e9e par <b>AppImage<\/b>.<\/p>\n<p>Ces solutions permettent de cr\u00e9er un paquet unique pour toutes les distributions. Dans le cas de <b>Flatpak<\/b> l'installation et le lancement de l'application sont possibles m\u00eame sans la connaissance de l'administrateur.<\/p>\n<p>Le principal probl\u00e8me est que toutes les applications ne peuvent pas fonctionner dans un bac \u00e0 sable. Certaines n\u00e9cessitent un acc\u00e8s direct \u00e0 la plateforme. Je ne parle m\u00eame pas des modules du noyau, qui d\u00e9pendent strictement du noyau et ne s'int\u00e8grent pas du tout dans le concept du bac \u00e0 sable. <\/p>\n<p>Le deuxi\u00e8me probl\u00e8me est que les distributions populaires dans le milieu des entreprises de Red Hat et SUSE ne supportent pas encore Snappy et Flatpak. <\/p>\n<p>En raison de cela, Veeam Agent for Linux n'est pas disponible sur <noindex><a rel=\"nofollow\" href=\"https:\/\/snapcraft.io\/\">snapcraft.io<\/a><\/noindex> ni sur <noindex><a rel=\"nofollow\" href=\"https:\/\/flathub.org\/home\">flathub.org<\/a><\/noindex>.<\/p>\n<p>En conclusion de la question sur les gestionnaires de paquets, je note qu'il est possible de se passer compl\u00e8tement des gestionnaires de paquets, en regroupant dans un seul package des fichiers binaires et un script pour leur installation. <\/p>\n<p>Un tel bundle permet de cr\u00e9er un package unique pour diff\u00e9rentes distributions et plateformes, de produire un processus d'installation interactif tout en r\u00e9alisant la personnalisation n\u00e9cessaire. J'ai rencontr\u00e9 de tels packages pour Linux uniquement de la part de VMware.<\/p>\n<h2>Probl\u00e8me des mises \u00e0 jour<\/h2>\n<p>\n<img decoding=\"async\" alt=\"Linux, multiple facettes : comment travailler sur n&#039;importe quelle distribution\" src=\"\/wp-content\/uploads\/2019\/10\/aa14b10a434c28541574421d97807de7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nM\u00eame si tous les probl\u00e8mes de d\u00e9pendances sont r\u00e9solus, un programme peut fonctionner diff\u00e9remment sur une m\u00eame distribution. C'est une question de mises \u00e0 jour.<\/p>\n<p>Il existe 3 strat\u00e9gies de mise \u00e0 jour :<\/p>\n<ul>\n<li>La plus simple consiste \u00e0 ne jamais mettre \u00e0 jour. On configure le serveur et on oublie. Pourquoi mettre \u00e0 jour si tout fonctionne ? Les probl\u00e8mes commencent d\u00e8s le premier appel au support technique. Le cr\u00e9ateur de la distribution ne prend en charge que la version mise \u00e0 jour. <\/li>\n<li>On peut faire confiance au distributeur et configurer une mise \u00e0 jour automatique. Dans ce cas, un appel au support est probable imm\u00e9diatement apr\u00e8s une mise \u00e0 jour rat\u00e9e.<\/li>\n<li>L'option de mise \u00e0 jour manuelle uniquement apr\u00e8s des tests sur l'infrastructure de test est la plus fiable, mais elle est co\u00fbteuse et laborieuse. Tout le monde ne peut pas se le permettre.<\/li>\n<\/ul>\n<p>\n\u00c9tant donn\u00e9 que les utilisateurs appliquent diff\u00e9rentes strat\u00e9gies de mise \u00e0 jour, il est \u00e9galement n\u00e9cessaire de maintenir \u00e0 la fois la version la plus r\u00e9cente et toutes les versions pr\u00e9c\u00e9demment publi\u00e9es. Cela complique \u00e0 la fois le processus de d\u00e9veloppement et le processus de test, ajoutant des maux de t\u00eate au service d'assistance.<\/p>\n<h2>Diversit\u00e9 des plateformes mat\u00e9rielles<\/h2>\n<p>\nLes diff\u00e9rentes plateformes mat\u00e9rielles repr\u00e9sentent un probl\u00e8me en grande partie sp\u00e9cifique au code natif. Au minimum, il faut compiler des binaires pour chaque plateforme prise en charge.<\/p>\n<p>Dans le projet Veeam Agent for Linux, nous n'avons toujours pas pu prendre en charge quoi que ce soit d'aussi RISC.<\/p>\n<p>Je ne m'attarderai pas longuement sur cette question. Je soulignerai simplement les principaux probl\u00e8mes : types d\u00e9pendants de la plateforme, tels que <code>size_t<\/code>, alignement des structures et ordre des octets.<\/p>\n<h2>Liaison statique et\/ou dynamique<\/h2>\n<p>\n<img decoding=\"async\" alt=\"Linux, multiple facettes : comment travailler sur n&#039;importe quelle distribution\" src=\"\/wp-content\/uploads\/2019\/10\/dc473aad4ea0818940af7eafdbc641fd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nLa question \u00ab Comment se lier aux biblioth\u00e8ques - dynamiquement ou statiquement ? \u00bb m\u00e9rite d'\u00eatre discut\u00e9e.<\/p>\n<p>En g\u00e9n\u00e9ral, les applications C\/C++ sous Linux utilisent une liaison dynamique. Cela fonctionne tr\u00e8s bien si l'application est compil\u00e9e sp\u00e9cifiquement pour une distribution donn\u00e9e.<\/p>\n<p>Si l'objectif est de couvrir divers distributions avec un seul fichier binaire, il faut se baser sur la distribution la plus ancienne prise en charge. Pour nous, cela serait Red Hat 6. Il contient gcc 4.4, qui ne supporte m\u00eame pas la norme C++11. <noindex><a rel=\"nofollow\" href=\"https:\/\/gcc.gnu.org\/projects\/cxx-status.html\">enti\u00e8rement<\/a><\/noindex>.<\/p>\n<p>Nous compilons notre projet avec gcc 6.3, qui supporte enti\u00e8rement C++14. Naturellement, dans ce cas, il faut apporter avec soi la biblioth\u00e8que libstdc++ et boost sur Red Hat 6. Il est le plus simple de les lier statiquement.<\/p>\n<p>Mais malheureusement, il n'est pas possible de lier statiquement avec toutes les biblioth\u00e8ques.<\/p>\n<p>Tout d'abord, les biblioth\u00e8ques syst\u00e8me, telles que <i>libfuse<\/i>, <i>libblkid<\/i> doivent \u00eatre li\u00e9es dynamiquement, afin d'assurer leur compatibilit\u00e9 avec le noyau et ses modules. <\/p>\n<p>Deuxi\u00e8mement, il existe une subtilit\u00e9 concernant les licences. <\/p>\n<p>La licence GPL permet en principe de lier les biblioth\u00e8ques uniquement avec du code opensource. MIT et BSD autorisent la liaison statique et permettent d'inclure des biblioth\u00e8ques dans le projet. Par contre, LGPL ne semble pas s'opposer \u00e0 la liaison statique, mais exige que les fichiers n\u00e9cessaires \u00e0 la liaison soient mis \u00e0 disposition du public. <\/p>\n<p>En g\u00e9n\u00e9ral, l'utilisation de la liaison dynamique \u00e9vitera d'avoir \u00e0 fournir quoi que ce soit.<\/p>\n<h2>Compilation d'applications C\/C++<\/h2>\n<p>\nPour compiler des applications C\/C++ pour diff\u00e9rentes plateformes et distributions, il suffit de s\u00e9lectionner ou de compiler gcc dans une version appropri\u00e9e et d'utiliser des compilateurs crois\u00e9s pour des architectures sp\u00e9cifiques, de rassembler l'ensemble des biblioth\u00e8ques. Cela peut \u00eatre r\u00e9alis\u00e9, mais c'est plut\u00f4t compliqu\u00e9. Et il n'y a aucune garantie que le compilateur et les biblioth\u00e8ques choisis fourniront une version fonctionnelle. <\/p>\n<p>L'avantage \u00e9vident : l'infrastructure est consid\u00e9rablement simplifi\u00e9e, puisque l'ensemble du processus de compilation peut \u00eatre effectu\u00e9 sur une seule machine. De plus, il suffit de compiler un ensemble de fichiers binaires pour une architecture et on peut les empaqueter dans des paquets pour diff\u00e9rentes distributions. C'est ainsi que les paquets veeam pour Veeam Agent for Linux sont construits.<\/p>\n<p>En revanche, il est possible de pr\u00e9parer simplement une ferme de construction, c'est-\u00e0-dire plusieurs machines d\u00e9di\u00e9es \u00e0 la compilation. Chaque machine sera responsable de la compilation de l'application et de la cr\u00e9ation du package pour une distribution sp\u00e9cifique et une architecture pr\u00e9cise. Dans ce cas, la compilation se fait avec les outils fournis par le distributeur. Ainsi, l'\u00e9tape de pr\u00e9paration du compilateur et de s\u00e9lection des biblioth\u00e8ques est \u00e9limin\u00e9e. De plus, le processus de construction peut \u00eatre facilement parall\u00e9lis\u00e9. <\/p>\n<p>Cependant, ce type d'approche a un inconv\u00e9nient : pour chaque distribution au sein d'une m\u00eame architecture, il faudra assembler un ensemble de fichiers binaires distinct. Un autre inconv\u00e9nient est qu'il faut g\u00e9rer ce grand nombre de machines, ce qui n\u00e9cessite une quantit\u00e9 importante d'espace disque et de m\u00e9moire vive. <\/p>\n<p>C'est ainsi que les paquets KMOD du module noyau veeamsnap sont construits pour les distributions Red Hat.<\/p>\n<h2>Open Build Service<\/h2>\n<p>\nLes coll\u00e8gues de SUSE ont essay\u00e9 de trouver un juste milieu avec un service sp\u00e9cial pour la compilation d'applications et la cr\u00e9ation de paquets \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/openbuildservice.org\/\">openbuildservice<\/a><\/noindex>.<\/p>\n<p>Il s'agit essentiellement d'un hyperviseur qui cr\u00e9e une machine virtuelle, installe tous les paquets n\u00e9cessaires, effectue la compilation de l'application et assemble le package dans cet environnement isol\u00e9, apr\u00e8s quoi la machine virtuelle est lib\u00e9r\u00e9e.<\/p>\n<p><img decoding=\"async\" alt=\"Linux, multiple facettes : comment travailler sur n&#039;importe quelle distribution\" src=\"\/wp-content\/uploads\/2019\/10\/93d2a70c589a7186ecef85a7863e59e8.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLe planificateur impl\u00e9ment\u00e9 dans OpenBuildService d\u00e9terminera lui-m\u00eame combien de machines virtuelles il peut lancer pour optimiser la vitesse de cr\u00e9ation des paquets. Le m\u00e9canisme de signature int\u00e9gr\u00e9 signera automatiquement les paquets et les d\u00e9posera dans le d\u00e9p\u00f4t int\u00e9gr\u00e9. Le syst\u00e8me de contr\u00f4le de version int\u00e9gr\u00e9 sauvegardera l'historique des modifications et des constructions. Il suffit d'ajouter ses propres sources \u00e0 ce syst\u00e8me. Il n'est m\u00eame pas n\u00e9cessaire de configurer un serveur soi-m\u00eame ; on peut utiliser un service ouvert.<\/p>\n<p>Cependant, il y a un probl\u00e8me : un tel combine s'int\u00e8gre difficilement dans l'infrastructure existante. Par exemple, le contr\u00f4le de version n'est pas n\u00e9cessaire, car nous avons d\u00e9j\u00e0 le n\u00f4tre pour les sources. Le m\u00e9canisme de signature diff\u00e8re : un serveur sp\u00e9cial est utilis\u00e9. Le d\u00e9p\u00f4t n'est pas non plus n\u00e9cessaire. <\/p>\n<p>De plus, le support d'autres distributions \u2014 par exemple, Red Hat \u2014 est plut\u00f4t limit\u00e9, ce qui est assez compr\u00e9hensible.<\/p>\n<p>L'un des avantages de ce service est le support rapide de la derni\u00e8re version de la distribution SUSE. Avant l'annonce officielle de la sortie, les paquets n\u00e9cessaires \u00e0 la compilation sont mis \u00e0 disposition dans un r\u00e9f\u00e9rentiel public. Un nouveau distributeur appara\u00eet dans la liste des distributions disponibles sur OpenBuildService. Nous cochons la case, et il est ajout\u00e9 au plan de compilation. Ainsi, l'ajout d'une nouvelle version de la distribution se fait presque en un clic.<\/p>\n<p>Dans notre infrastructure utilisant OpenBuildService, toute la diversit\u00e9 des paquets KMP du module noyau veeamsnap pour les distributions SUSE est compil\u00e9e.<\/p>\n<p>Je voudrais maintenant aborder des questions sp\u00e9cifiques li\u00e9es aux modules du noyau.<\/p>\n<h2>ABI du noyau<\/h2>\n<p>\nLes modules du noyau Linux ont historiquement \u00e9t\u00e9 distribu\u00e9s sous forme de code source. En effet, les cr\u00e9ateurs du noyau ne se soucient pas de la prise en charge d'une API stable pour les modules du noyau, et encore moins \u00e0 un niveau binaire, que l'on appelle kABI.<\/p>\n<p>Pour compiler un module pour un noyau vanilla, il faut obligatoirement les en-t\u00eates de ce noyau, et il ne fonctionnera que sur ce noyau. <\/p>\n<p>DKMS permet d'automatiser le processus de compilation des modules lors de la mise \u00e0 jour du noyau. En cons\u00e9quence, les utilisateurs du r\u00e9f\u00e9rentiel Debian (et de ses nombreux d\u00e9riv\u00e9s) utilisent des modules du noyau soit provenant du r\u00e9f\u00e9rentiel du distributeur, soit compil\u00e9s \u00e0 partir des sources \u00e0 l'aide de DKMS.<\/p>\n<p>Cependant, cette situation ne satisfait pas vraiment le segment des entreprises. Les distributeurs de code propri\u00e9taire souhaitent distribuer leur produit sous forme de binaires compil\u00e9s. <\/p>\n<p>Les administrateurs ne souhaitent pas maintenir des outils de d\u00e9veloppement sur les serveurs de production pour des raisons de s\u00e9curit\u00e9. Les distributeurs d'Enterprise Linux, tels que Red Hat et SUSE, ont d\u00e9cid\u00e9 qu'ils pourraient supporter une kABI stable pour leurs utilisateurs. En cons\u00e9quence, des paquets KMOD pour Red Hat et des paquets KMP pour SUSE sont apparus.<\/p>\n<p>Le principe de cette solution est assez simple. Pour une version sp\u00e9cifique de la distribution, l'API du noyau est gel\u00e9e. Le distributeur annonce qu'il utilise exactement le noyau, par exemple, 3.10, et n'apporte que des corrections et des am\u00e9liorations qui n'affectent en rien les interfaces du noyau, et les modules compil\u00e9s pour le tout premier noyau peuvent \u00eatre utilis\u00e9s pour tous les suivants sans recompilation.<\/p>\n<p>Red Hat annonce la compatibilit\u00e9 kABI pour sa distribution tout au long de son cycle de vie. Cela signifie qu'un module compil\u00e9 pour RHEL 6.0 (sortie de novembre 2010) doit \u00e9galement fonctionner sur la version 6.10 (sortie de juin 2018). Cela repr\u00e9sente presque 8 ans. Naturellement, cette t\u00e2che est assez complexe. <br \/>\nNous avons constat\u00e9 plusieurs cas o\u00f9, en raison de probl\u00e8mes de compatibilit\u00e9 kABI, le module veeamsnap cessait de fonctionner. <\/p>\n<p>Apr\u00e8s que le module veeamsnap, compil\u00e9 pour RHEL 7.0, se soit r\u00e9v\u00e9l\u00e9 incompatible avec le noyau de RHEL 7.5, tout en se chargeant et garantissant de faire planter le serveur, nous avons abandonn\u00e9 l'utilisation de la compatibilit\u00e9 kABI pour RHEL 7 dans son int\u00e9gralit\u00e9. <\/p>\n<p>Actuellement, le paquet KMOD pour RHEL 7 contient une compilation pour chaque version de release et un script qui assure le chargement du module.<\/p>\n<p>SUSE a abord\u00e9 la question de la compatibilit\u00e9 kABI avec plus de prudence. Ils assurent la compatibilit\u00e9 kABI uniquement au sein d'un m\u00eame service pack. <\/p>\n<p>Par exemple, la sortie de SLES 12 a eu lieu en septembre 2014. Et SLES 12 SP1 est sorti en d\u00e9cembre 2015, soit un peu plus d'un an plus tard. Bien que les deux versions utilisent le noyau 3.12, elles ne sont pas compatibles kABI. Il est \u00e9vident que maintenir la compatibilit\u00e9 kABI pendant seulement un an est beaucoup plus simple. Un cycle de mise \u00e0 jour annuel du module de noyau ne devrait pas poser de probl\u00e8mes pour les cr\u00e9ateurs de modules. <\/p>\n<p>En raison de cette politique de SUSE, nous n'avons constat\u00e9 aucun probl\u00e8me de compatibilit\u00e9 kABI avec notre module veeamsnap. Cependant, le nombre de paquets pour SUSE est presque dix fois plus \u00e9lev\u00e9.<\/p>\n<h2>Correctifs et backports<\/h2>\n<p>\nBien que les distributeurs s'efforcent d'assurer la compatibilit\u00e9 kABI et la stabilit\u00e9 du noyau, ils cherchent \u00e9galement \u00e0 am\u00e9liorer les performances et \u00e0 corriger les d\u00e9fauts de ce noyau stable. <\/p>\n<p>En outre, en plus de leur propre \u00ab travail sur les erreurs \u00bb, les d\u00e9veloppeurs du noyau de Linux Enterprise suivent les modifications dans le noyau vanilla et les portent dans leur version \u00ab stable \u00bb.<\/p>\n<p>Parfois, cela conduit \u00e0 de nouveaux <noindex><a rel=\"nofollow\" href=\"https:\/\/access.redhat.com\/solutions\/3658111\">probl\u00e8mes.<\/a><\/noindex>.<\/p>\n<p>Dans la derni\u00e8re version de Red Hat 6, une erreur a \u00e9t\u00e9 introduite dans l'une des mises \u00e0 jour mineures. Cela provoquait le fait que le module veeamsnap faisait syst\u00e9matiquement planter le syst\u00e8me lors de la lib\u00e9ration d'un instantan\u00e9. En comparant les sources du noyau avant et apr\u00e8s la mise \u00e0 jour, nous avons d\u00e9couvert que cela \u00e9tait d\u00fb \u00e0 un backport. Un correctif similaire avait \u00e9t\u00e9 appliqu\u00e9 dans le noyau vanilla version 4.19. Cependant, dans le noyau vanilla, ce correctif fonctionnait correctement, alors que lors de son transfert dans le \u00ab stable \u00bb 2.6.32, un probl\u00e8me de blocage s'est produit.<\/p>\n<p>Bien s\u00fbr, des erreurs peuvent survenir \u00e0 tout le monde, mais \u00e9tait-il judicieux de transf\u00e9rer le code de 4.19 vers 2.6.32, en risquant la stabilit\u00e9 ?... Je ne suis pas s\u00fbr...<\/p>\n<p>Le pire, c'est quand le marketing s'implique dans le tir \u00e0 la corde entre \"stabilit\u00e9\"  \"modernisation\". Le d\u00e9partement marketing a besoin que le noyau de la distribution mise \u00e0 jour soit stable d'une part, tout en \u00e9tant plus performant et dot\u00e9 de nouvelles fonctionnalit\u00e9s d'autre part. Cela conduit \u00e0 des compromis \u00e9tranges. <\/p>\n<p>Lorsque j'ai essay\u00e9 de compiler un module avec le noyau 4.4 de SLES 12 SP3, j'ai \u00e9t\u00e9 surpris de trouver des fonctionnalit\u00e9s issues du noyau vanilla 4.8. \u00c0 mon avis, l'impl\u00e9mentation du bloc d'entr\u00e9e\/sortie du noyau 4.4 de SLES 12 SP3 ressemble plus \u00e0 celle du noyau 4.8 qu'\u00e0 la version pr\u00e9c\u00e9dente stable du noyau 4.4 de SLES12 SP2. Je ne me prononcerai pas sur le pourcentage de code transf\u00e9r\u00e9 du noyau 4.8 vers le 4.4 de SLES pour SP3, mais je n'arrive pas \u00e0 appeler le noyau le m\u00eame stable 4.4. <\/p>\n<p>Le plus d\u00e9sagr\u00e9able, c'est qu'en \u00e9crivant un module qui doit fonctionner de mani\u00e8re uniforme sur diff\u00e9rents noyaux, on ne peut plus se fier \u00e0 la version du noyau. Il faut aussi tenir compte de la distribution. Heureusement, on peut parfois se baser sur un define qui appara\u00eet avec une nouvelle fonctionnalit\u00e9, mais cette possibilit\u00e9 n'est pas toujours pr\u00e9sente. <\/p>\n<p>En cons\u00e9quence, le code devient charg\u00e9 de directives de compilation conditionnelle \u00e9tranges.<\/p>\n<p>Il existe \u00e9galement des patches qui modifient l'API document\u00e9e du noyau. <br \/>\nJe suis tomb\u00e9 sur la distribution <noindex><a rel=\"nofollow\" href=\"https:\/\/neon.kde.org\/\">KDE neon<\/a><\/noindex> 5.16 et j'ai \u00e9t\u00e9 tr\u00e8s surpris de voir que l'appel \u00e0 lookup_bdev dans cette version du noyau a modifi\u00e9 la liste des param\u00e8tres d'entr\u00e9e.<\/p>\n<p>Pour compiler, j'ai d\u00fb ajouter dans le makefile un script qui v\u00e9rifie s'il y a un param\u00e8tre mask pour la fonction lookup_bdev.<\/p>\n<h2>Signature des modules du noyau<\/h2>\n<p>\nRevenons \u00e0 la question de la distribution des paquets.<\/p>\n<p>Un des avantages du kABI stable est que les modules du noyau en tant que fichiers binaires peuvent \u00eatre sign\u00e9s. Dans ce cas, le d\u00e9veloppeur peut \u00eatre s\u00fbr que le module n'a pas \u00e9t\u00e9 accidentellement corrompu ou intentionnellement modifi\u00e9. On peut v\u00e9rifier cela avec la commande modinfo. <\/p>\n<p>Les distributions Red Hat et SUSE permettent de v\u00e9rifier la signature d'un module et de le charger uniquement si le certificat correspondant est enregistr\u00e9 dans le syst\u00e8me. Le certificat est une cl\u00e9 publique avec laquelle le module est sign\u00e9. Nous le distribuons sous forme de paquet s\u00e9par\u00e9.<\/p>\n<p>Le probl\u00e8me ici est que les certificats peuvent \u00eatre soit int\u00e9gr\u00e9s dans le noyau (utilis\u00e9s par les distributeurs), soit doivent \u00eatre \u00e9crits dans la m\u00e9moire non volatile EFI \u00e0 l'aide d'un utilitaire. <i>mokutil<\/i>indique que <i>mokutil<\/i> lors de l'installation du certificat, il demande de red\u00e9marrer le syst\u00e8me et, avant m\u00eame le chargement du noyau du syst\u00e8me d'exploitation, propose \u00e0 l'administrateur d'autoriser le chargement du nouveau certificat. <\/p>\n<p>Ainsi, l'ajout d'un certificat n\u00e9cessite un acc\u00e8s physique de l'administrateur au syst\u00e8me. Si la machine est h\u00e9berg\u00e9e quelque part dans le cloud ou dans un serveur distant avec un acc\u00e8s uniquement via le r\u00e9seau (par exemple, par ssh), il sera impossible d'ajouter le certificat. <\/p>\n<h2>EFI sur les machines virtuelles<\/h2>\n<p>\nBien que l'EFI soit maintenant largement support\u00e9 par presque tous les fabricants de cartes m\u00e8res, lors de l'installation du syst\u00e8me, l'administrateur peut ne pas penser \u00e0 la n\u00e9cessit\u00e9 de l'EFI, et celui-ci peut \u00eatre d\u00e9sactiv\u00e9. <\/p>\n<p>Tous les hyperviseurs ne supportent pas l'EFI. VMWare vSphere prend en charge l'EFI depuis la version 5. <br \/>\nMicrosoft Hyper-V a \u00e9galement acquis le support de l'EFI, \u00e0 partir de Hyper-V pour Windows Server 2012R2. <\/p>\n<p>Cependant, dans la configuration par d\u00e9faut, cette fonctionnalit\u00e9 est d\u00e9sactiv\u00e9e pour les machines Linux, ce qui signifie qu'il est impossible d'installer le certificat. <\/p>\n<p>Dans vSphere 6.5, il est possible de d\u00e9finir l'option <b>Secure Boot<\/b> uniquement dans l'ancienne version de l'interface web, qui fonctionne via Flash. L'interface Web en HTML-5 est encore tr\u00e8s en retard.<\/p>\n<h2>Distributions exp\u00e9rimentales<\/h2>\n<p>\nEnfin, examinons la question des distributions exp\u00e9rimentales et des distributions sans support officiel. D'une part, ces distributions ne se rencontrent gu\u00e8re sur les serveurs d'organisations s\u00e9rieuses. Ces distributions n'ont pas de support officiel. Par cons\u00e9quent, il n'est pas possible d'assurer le support technique du produit sur une telle distribution. <\/p>\n<p>Cependant, ces distributions deviennent une plateforme pratique pour essayer de nouvelles solutions exp\u00e9rimentales. Par exemple, Fedora, OpenSUSE Tumbleweed ou les versions instables de Debian. Elles sont assez stables. Elles contiennent toujours de nouvelles versions de logiciels et toujours un nouveau noyau. Dans un an, cette fonctionnalit\u00e9 exp\u00e9rimentale pourrait appara\u00eetre dans une version mise \u00e0 jour de RHEL, SLES ou Ubuntu. <\/p>\n<p>Ainsi, si quelque chose ne fonctionne pas sur une distribution exp\u00e9rimentale, c'est une occasion de comprendre le probl\u00e8me et de le r\u00e9soudre. Il faut \u00eatre pr\u00eat \u00e0 ce que cette fonctionnalit\u00e9 apparaisse bient\u00f4t sur les serveurs de production des utilisateurs.<\/p>\n<p>Vous pouvez consulter la liste actuelle des distributions officiellement prises en charge pour la version 3.0. <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/agentforlinux\/userguide\/system_requirements.html?ver=30\">ici<\/a><\/noindex>Mais la liste r\u00e9elle des distributions sur lesquelles notre produit peut fonctionner est bien plus \u00e9tendue.<\/p>\n<p>Personnellement, j'\u00e9tais int\u00e9ress\u00e9 par l'exp\u00e9rience avec le syst\u00e8me d'exploitation \u00ab Elbrus \u00bb. Apr\u00e8s des travaux suppl\u00e9mentaires sur le paquet veeam, notre produit a \u00e9t\u00e9 install\u00e9 et a fonctionn\u00e9. J'ai \u00e9crit \u00e0 ce sujet sur Habr dans <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/veeam\/blog\/447960\/\">article<\/a><\/noindex>. <\/p>\n<p>La prise en charge de nouvelles distributions se poursuit. Nous attendons la sortie de la version 4.0. Une version b\u00eata devrait bient\u00f4t \u00eatre disponible, alors restez \u00e0 l'\u00e9coute pour des <noindex><a rel=\"nofollow\" href=\"https:\/\/www.veeam.com\/whats-new-linux-agent.html\">whats-new<\/a><\/noindex>!<br \/>\n<br \/>Source : <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/veeam\/blog\/471226\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0421\u043e\u0437\u0434\u0430\u0442\u044c \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u0434\u043b\u044f \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u0433\u043e \u043a\u043e\u043f\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f, \u0440\u0430\u0431\u043e\u0442\u0430\u044e\u0449\u0435\u0435 \u043d\u0430 \u043b\u044e\u0431\u043e\u043c \u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432\u0435 \u2014 \u0437\u0430\u0434\u0430\u0447\u043a\u0430 \u043d\u0435\u043f\u0440\u043e\u0441\u0442\u0430\u044f. \u0427\u0442\u043e\u0431\u044b \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0438\u0442\u044c \u0440\u0430\u0431\u043e\u0442\u0443 Veeam Agent for Linux \u043d\u0430 \u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432\u0430\u0445 \u043e\u0442 Red Hat 6 \u0438 Debian 6, \u0434\u043e OpenSUSE 15.1 \u0438 Ubuntu 19.04 \u043f\u0440\u0438\u0445\u043e\u0434\u0438\u0442\u0441\u044f \u0440\u0435\u0448\u0430\u0442\u044c \u0441\u043f\u0435\u043a\u0442\u0440 \u043f\u0440\u043e\u0431\u043b\u0435\u043c, \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e \u0435\u0441\u043b\u0438 \u0443\u0447\u0435\u0441\u0442\u044c, \u0447\u0442\u043e \u0432 \u0441\u043e\u0441\u0442\u0430\u0432 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u0430 \u0432\u0445\u043e\u0434\u0438\u0442 \u043c\u043e\u0434\u0443\u043b\u044c \u044f\u0434\u0440\u0430. \u0421\u0442\u0430\u0442\u044c\u044f \u0441\u043e\u0437\u0434\u0430\u043d\u0430 \u043f\u043e \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u0430\u043c \u0432\u044b\u0441\u0442\u0443\u043f\u043b\u0435\u043d\u0438\u044f \u043d\u0430 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":29206,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-38929","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0421\u043e\u0437\u0434\u0430\u0442\u044c \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u0434\u043b\u044f \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u0433\u043e.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/linux-mnogolikij-kak-rabotat-na-lyubom-distributive\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"fr_FR\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Linux \u043c\u043d\u043e\u0433\u043e\u043b\u0438\u043a\u0438\u0439: \u043a\u0430\u043a \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u043d\u0430 \u043b\u044e\u0431\u043e\u043c \u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432\u0435 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0421\u043e\u0437\u0434\u0430\u0442\u044c \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u0434\u043b\u044f \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u0433\u043e.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/linux-mnogolikij-kak-rabotat-na-lyubom-distributive\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:26:48+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:26:48+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Linux est polyvalent : comment travailler sur n'importe quelle distribution | ProHoster","description":"Cr\u00e9er une application de sauvegarde.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/linux-mnogolikij-kak-rabotat-na-lyubom-distributive","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Linux \u043c\u043d\u043e\u0433\u043e\u043b\u0438\u043a\u0438\u0439: \u043a\u0430\u043a \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u043d\u0430 \u043b\u044e\u0431\u043e\u043c \u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432\u0435 | ProHoster","og:description":"\u0421\u043e\u0437\u0434\u0430\u0442\u044c \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u0434\u043b\u044f \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u0433\u043e.","og:url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/linux-mnogolikij-kak-rabotat-na-lyubom-distributive","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:26:48+00:00","article:modified_time":"2019-10-31T19:26:48+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"38929","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 23:59:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:00:26","updated":"2026-01-23 23:59:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/38929","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=38929"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/38929\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/29206"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=38929"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=38929"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=38929"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}