{"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\/es\/blog\/administrirovanie\/linux-mnogolikij-kak-rabotat-na-lyubom-distributive","title":{"rendered":"Linux tiene muchas caras: c\u00f3mo trabajar en cualquier distribuci\u00f3n","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Linux tiene muchas caras: c\u00f3mo trabajar en cualquier distribuci\u00f3n\" src=\"\/wp-content\/uploads\/2019\/10\/ee1aaad566204532c974a3ce8f13b915.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCrear una aplicaci\u00f3n de respaldo que funcione en cualquier distribuci\u00f3n es una tarea complicada. Para asegurar el funcionamiento de Veeam Agent for Linux en distribuciones desde Red Hat 6 y Debian 6 hasta OpenSUSE 15.1 y Ubuntu 19.04, es necesario resolver una serie de problemas, especialmente considerando que el producto incluye un m\u00f3dulo del n\u00facleo.<\/p>\n<p>Este art\u00edculo se basa en una presentaci\u00f3n en la conferencia <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 no es solo uno de los sistemas operativos m\u00e1s populares. De hecho, es una plataforma sobre la cual se puede construir algo \u00fanico, algo propio. Como resultado, existen numerosas distribuciones de Linux que se diferencian por su conjunto de componentes de software. Y aqu\u00ed surge un problema: para que el producto funcione en cualquier distribuci\u00f3n, es necesario tener en cuenta las particularidades de cada una.<\/p>\n<h2>Gestores de paquetes. .deb vs .rpm<\/h2>\n<p>\nEmpezaremos con el problema evidente de la distribuci\u00f3n del producto para diferentes distribuciones.<br \/>\nLa forma m\u00e1s t\u00edpica de distribuir productos de software es subir un paquete a un repositorio, de modo que el gestor de paquetes integrado en el sistema pueda instalarlo desde ah\u00ed.<br \/>\nSin embargo, hay dos formatos de paquetes populares: <i>rpm<\/i> y <i>deb<\/i>. Por lo tanto, ser\u00e1 necesario mantenerlos todos.<\/p>\n<p>En el mundo de los paquetes deb, el nivel de compatibilidad es impresionante. Un mismo paquete se instala y funciona igual de bien tanto en Debian 6 como en Ubuntu 19.04. Los est\u00e1ndares en el proceso de creaci\u00f3n de paquetes y su manejo, establecidos en antiguas distribuciones de Debian, siguen siendo relevantes en las modernas Linux Mint y elementary OS. Por lo tanto, en el caso de Veeam Agent for Linux, se requiere un \u00fanico paquete deb para cada plataforma de hardware.<\/p>\n<p>En cambio, en el mundo de los paquetes rpm, las diferencias son grandes. Primero, porque hay dos distribuidores completamente independientes, Red Hat y SUSE, que no requieren compatibilidad. En segundo lugar, estos distribuidores tienen distribuciones con soporte t\u00e9cnico y experimentales. Entre ellas, la compatibilidad tampoco es necesaria. Resulta que tenemos paquetes diferentes para el el6, el7 y el8. Un paquete separado para Fedora. Paquetes para SLES11 y 12 y otro para openSUSE. El principal problema son las dependencias y los nombres de los paquetes. <\/p>\n<h2>Problema de dependencias<\/h2>\n<p>\nLamentablemente, los mismos paquetes a menudo tienen nombres diferentes en distintas distribuciones. A continuaci\u00f3n, se presenta una lista no exhaustiva de las dependencias del paquete veeam.<\/p>\n<p>Para EL7:<br \/>\nPara 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>\nComo resultado, la lista de dependencias resulta ser \u00fanica para la distribuci\u00f3n. <\/p>\n<p>Es peor cuando una versi\u00f3n actualizada se oculta bajo el antiguo nombre del paquete. <\/p>\n<p><b>Ejemplo:<\/b><\/p>\n<p>En Fedora 24, se ha actualizado el paquete <i>ncurses<\/i> de la versi\u00f3n 5 a la versi\u00f3n 6. Nuestro producto fue compilado precisamente con la versi\u00f3n 5, para garantizar la compatibilidad con las distribuciones antiguas. Para utilizar la antigua versi\u00f3n 5 de la biblioteca en Fedora 24, fue necesario usar el paquete <i>ncurses-compat-libs<\/i>. <\/p>\n<p>Como resultado, aparecen dos paquetes para Fedora, con diferentes dependencias. <\/p>\n<p>La situaci\u00f3n se vuelve m\u00e1s interesante. Despu\u00e9s de otra actualizaci\u00f3n de la distribuci\u00f3n, el paquete <i>ncurses-compat-libs<\/i> con la versi\u00f3n 5 de la biblioteca resulta ser inaccesible. Para el distribuidor, es costoso cargar bibliotecas antiguas en la nueva versi\u00f3n de la distribuci\u00f3n. Pasado un tiempo, el problema se repiti\u00f3 tambi\u00e9n en las distribuciones de SUSE.<\/p>\n<p>Como resultado, para algunas distribuciones fue necesario renunciar a la dependencia expl\u00edcita de <i>ncurses-libs<\/i>, y ajustar el producto para que pueda funcionar con cualquier versi\u00f3n de la biblioteca.<\/p>\n<p>Por cierto, en la versi\u00f3n 8 de Red Hat ya no hay el metapaquete <i>python<\/i>, que hac\u00eda referencia a la buena y antigua. <i>python 2.7<\/i>. Hay <i>python2<\/i> y <i>python<\/i>3. <\/p>\n<h2>La alternativa a los gestores de paquetes<\/h2>\n<p>\nEl problema de las dependencias es antiguo y bien conocido. Recordemos, por ejemplo, el Dependency hell. <br \/>\nCombinar diversas bibliotecas y aplicaciones de manera que todas funcionen de forma estable y no entren en conflicto es precisamente la tarea que intenta resolver cualquier distribuidor de Linux.<\/p>\n<p>De una manera muy distinta, el gestor de paquetes <b>Snappy<\/b> de Canonical. La idea principal es: la aplicaci\u00f3n se ejecuta en una sandbox aislada y protegida del sistema principal. Si la aplicaci\u00f3n necesita bibliotecas, se proporcionan junto con la propia aplicaci\u00f3n.<\/p>\n<p><b>Flatpak<\/b> tambi\u00e9n permite ejecutar aplicaciones en una sandbox, utilizando Linux Containers. La idea de la sandbox es utilizada tambi\u00e9n por <b>AppImage<\/b>.<\/p>\n<p>Estas soluciones permiten crear un solo paquete para cualquier distribuci\u00f3n. En el caso de <b>Flatpak<\/b> la instalaci\u00f3n y ejecuci\u00f3n de la aplicaci\u00f3n es posible incluso sin el conocimiento del administrador.<\/p>\n<p>El problema principal es que no todas las aplicaciones pueden funcionar en una sandbox. Algunas requieren acceso directo a la plataforma. Ya ni hablar de los m\u00f3dulos del n\u00facleo que dependen estrictamente del n\u00facleo y que no encajan de ninguna manera en el concepto de sandbox. <\/p>\n<p>El segundo problema es que las distribuciones populares en el entorno empresarial de Red Hat y SUSE a\u00fan no contienen soporte para Snappy y Flatpak. <\/p>\n<p>Debido a esto, Veeam Agent for Linux no est\u00e1 disponible ni en <noindex><a rel=\"nofollow\" href=\"https:\/\/snapcraft.io\/\">snapcraft.io<\/a><\/noindex> ni en <noindex><a rel=\"nofollow\" href=\"https:\/\/flathub.org\/home\">flathub.org<\/a><\/noindex>.<\/p>\n<p>Para concluir la cuesti\u00f3n de los gestores de paquetes, mencionar\u00e9 que existe la opci\u00f3n de prescindir completamente de los gestores de paquetes, combinando en un solo paquete los archivos binarios y un script para su instalaci\u00f3n. <\/p>\n<p>Este paquete permite crear un solo instalador com\u00fan para diferentes distribuciones y plataformas, llevar a cabo un proceso de instalaci\u00f3n interactivo y realizar la personalizaci\u00f3n necesaria. He encontrado tales paquetes para Linux solo de VMware.<\/p>\n<h2>Problema de actualizaciones<\/h2>\n<p>\n<img decoding=\"async\" alt=\"Linux tiene muchas caras: c\u00f3mo trabajar en cualquier distribuci\u00f3n\" src=\"\/wp-content\/uploads\/2019\/10\/aa14b10a434c28541574421d97807de7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nIncluso si todos los problemas de dependencias est\u00e1n resueltos, el programa puede funcionar de manera diferente en la misma distribuci\u00f3n. Se debe a las actualizaciones.<\/p>\n<p>Existen 3 estrategias de actualizaci\u00f3n:<\/p>\n<ul>\n<li>La m\u00e1s sencilla es nunca actualizar. Configuraste el servidor y te olvidaste. \u00bfPara qu\u00e9 actualizaciones si todo funciona? Los problemas comienzan en la primera llamada al soporte t\u00e9cnico. El creador de la distribuci\u00f3n solo da soporte a la versi\u00f3n m\u00e1s actualizada. <\/li>\n<li>Se puede confiar en el distribuidor y configurar la actualizaci\u00f3n autom\u00e1tica. En este caso, la llamada al soporte t\u00e9cnico es probable justo despu\u00e9s de una actualizaci\u00f3n fallida.<\/li>\n<li>La opci\u00f3n de actualizaci\u00f3n manual solo despu\u00e9s de probarla en la infraestructura de pruebas es la m\u00e1s segura, pero costosa y laboriosa. No todos pueden permit\u00edrselo.<\/li>\n<\/ul>\n<p>\nDado que diferentes usuarios adoptan diferentes estrategias de actualizaci\u00f3n, es necesario soportar tanto la versi\u00f3n m\u00e1s reciente como todas las versiones anteriores. Esto complica tanto el proceso de desarrollo como el de prueba, y a\u00f1ade problemas al servicio de soporte.<\/p>\n<h2>Diversidad de plataformas de hardware<\/h2>\n<p>\nLas diversas plataformas de hardware son un problema que, en gran medida, es espec\u00edfico del c\u00f3digo nativo. Como m\u00ednimo, se debe compilar archivos binarios para cada plataforma soportada.<\/p>\n<p>En el proyecto Veeam Agent for Linux, no hemos podido soportar nada que sea RISC.<\/p>\n<p>No profundizar\u00e9 en este asunto. Solo se\u00f1alar\u00e9 los problemas principales: tipos dependientes de la plataforma, como <code>size_t<\/code>, alineaci\u00f3n de estructuras y orden de bytes.<\/p>\n<h2>Enlazado est\u00e1tico y\/o din\u00e1mico<\/h2>\n<p>\n<img decoding=\"async\" alt=\"Linux tiene muchas caras: c\u00f3mo trabajar en cualquier distribuci\u00f3n\" src=\"\/wp-content\/uploads\/2019\/10\/dc473aad4ea0818940af7eafdbc641fd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nSin embargo, la cuesti\u00f3n de \"\u00bfC\u00f3mo enlazar con bibliotecas: din\u00e1micamente o est\u00e1ticamente?\" merece ser discutida.<\/p>\n<p>Por lo general, las aplicaciones en C\/C++ en Linux utilizan enlace din\u00e1mico. Esto funciona muy bien si la aplicaci\u00f3n est\u00e1 compilada espec\u00edficamente para una distribuci\u00f3n concreta.<\/p>\n<p>Sin embargo, si el objetivo es abarcar diversas distribuciones con un solo archivo binario, se debe orientar hacia la distribuci\u00f3n m\u00e1s antigua que se soporte. Para nosotros, esto es Red Hat 6. Contiene gcc 4.4, que ni siquiera soporta completamente el est\u00e1ndar C++11. <noindex><a rel=\"nofollow\" href=\"https:\/\/gcc.gnu.org\/projects\/cxx-status.html\">completamente<\/a><\/noindex>.<\/p>\n<p>Compilamos nuestro proyecto con gcc 6.3, que soporta completamente C++14. Naturalmente, en tal caso, en Red Hat 6 se necesita llevar la biblioteca libstdc++ y boost con nosotros. Lo m\u00e1s sencillo es enlazarlas de manera est\u00e1tica.<\/p>\n<p>Pero, lamentablemente, no todas las bibliotecas se pueden enlazar est\u00e1ticamente.<\/p>\n<p>En primer lugar, bibliotecas del sistema como <i>libfuse<\/i>, <i>libblkid<\/i> deben enlazarse din\u00e1micamente para asegurar su compatibilidad con el n\u00facleo y sus m\u00f3dulos. <\/p>\n<p>En segundo lugar, hay un matiz con las licencias. <\/p>\n<p>La licencia GPL en principio permite enlazar bibliotecas solo con c\u00f3digo opensource. MIT y BSD permiten el enlace est\u00e1tico y permiten incluir bibliotecas en el proyecto. Pero LGPL, aunque parece no contradecir el enlace est\u00e1tico, exige proporcionar al p\u00fablico los archivos necesarios para el enlace. <\/p>\n<p>En general, usar enlace din\u00e1mico evitar\u00e1 la necesidad de proporcionar algo.<\/p>\n<h2>Construcci\u00f3n de aplicaciones en C\/C++<\/h2>\n<p>\nPara construir aplicaciones en C\/C++ para diferentes plataformas y distribuciones, basta con elegir o compilar una versi\u00f3n adecuada de gcc y usar compiladores cruzados para arquitecturas espec\u00edficas, y compilar todo el conjunto de bibliotecas. Esta tarea es totalmente factible, pero bastante complicada. No hay garant\u00edas de que el compilador y las bibliotecas elegidas aseguren un funcionamiento correcto. <\/p>\n<p>Una ventaja evidente: la infraestructura se simplifica mucho, ya que todo el proceso de construcci\u00f3n se puede realizar en una sola m\u00e1quina. Adem\u00e1s, solo es necesario compilar un conjunto de archivos binarios para una arquitectura y se pueden empaquetar en paquetes para diferentes distribuciones. As\u00ed es como se construyen los paquetes veeam para Veeam Agent for Linux.<\/p>\n<p>En lugar de esta opci\u00f3n, se puede simplemente preparar una granja de compilaci\u00f3n, es decir, varias m\u00e1quinas para la construcci\u00f3n. Cada una de estas m\u00e1quinas se encargar\u00e1 de compilar la aplicaci\u00f3n y empaquetar para una distribuci\u00f3n espec\u00edfica y una arquitectura determinada. En este caso, la compilaci\u00f3n se lleva a cabo con las herramientas que ha preparado el distribuidor. Es decir, la etapa de preparaci\u00f3n del compilador y la selecci\u00f3n de bibliotecas queda eliminada. Adem\u00e1s, el proceso de construcci\u00f3n puede ser f\u00e1cilmente paralelizado. <\/p>\n<p>Sin embargo, hay una desventaja en este enfoque: para cada distribuci\u00f3n dentro de una misma arquitectura, ser\u00e1 necesario compilar su propio conjunto de archivos binarios. Adem\u00e1s, es un inconveniente que se necesita mantener tantas m\u00e1quinas, asignar una gran cantidad de espacio en disco y memoria RAM. <\/p>\n<p>As\u00ed se construyen los paquetes KMOD del m\u00f3dulo del n\u00facleo veeamsnap para las distribuciones de Red Hat.<\/p>\n<h2>Open Build Service<\/h2>\n<p>\nLos colegas de SUSE intentaron implementar una especie de t\u00e9rmino medio en forma de un servicio especial para compilar aplicaciones y construir paquetes \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/openbuildservice.org\/\">openbuildservice<\/a><\/noindex>.<\/p>\n<p>En esencia, es un hipervisor que crea una m\u00e1quina virtual, instala todos los paquetes necesarios, realiza la compilaci\u00f3n de la aplicaci\u00f3n y construye el paquete en este entorno aislado, despu\u00e9s de lo cual la m\u00e1quina virtual es liberada.<\/p>\n<p><img decoding=\"async\" alt=\"Linux tiene muchas caras: c\u00f3mo trabajar en cualquier distribuci\u00f3n\" src=\"\/wp-content\/uploads\/2019\/10\/93d2a70c589a7186ecef85a7863e59e8.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEl programador implementado en OpenBuildService determinar\u00e1 por s\u00ed mismo cu\u00e1ntas m\u00e1quinas virtuales puede iniciar para una velocidad \u00f3ptima de construcci\u00f3n de paquetes. El mecanismo de firma integrado firmar\u00e1 los paquetes autom\u00e1ticamente y los publicar\u00e1 en el repositorio integrado. El sistema de control de versiones incorporado guardar\u00e1 el historial de cambios y compilaciones. Solo queda agregar sus fuentes en este sistema. Incluso no es necesario elevar el servidor uno mismo, se puede utilizar el de c\u00f3digo abierto.<\/p>\n<p>Aqu\u00ed, sin embargo, hay un problema: tal cosechadora es dif\u00edcil de integrar en la infraestructura existente. Por ejemplo, el control de versiones no es necesario, ya que tenemos el nuestro para las fuentes. El mecanismo de firma es diferente: se utiliza un servidor especial. El repositorio tambi\u00e9n es innecesario. <\/p>\n<p>Adem\u00e1s, el soporte para otras distribuciones \u2014 por ejemplo, Red Hat \u2014 est\u00e1 implementado de manera bastante limitada, lo cual es bastante comprensible.<\/p>\n<p>Una de las ventajas de este servicio es el r\u00e1pido soporte para la pr\u00f3xima versi\u00f3n de la distribuci\u00f3n SUSE. Antes del anuncio oficial del lanzamiento, los paquetes necesarios para la compilaci\u00f3n se cargan en el repositorio p\u00fablico. Aparece una nueva distribuci\u00f3n en la lista de distribuciones disponibles en OpenBuildService. Marcamos la casilla y se a\u00f1ade al plan de compilaci\u00f3n. De esta manera, la adici\u00f3n de una nueva versi\u00f3n de la distribuci\u00f3n se realiza pr\u00e1cticamente con un clic.<\/p>\n<p>En nuestra infraestructura, se compila toda la variedad de paquetes KMP del m\u00f3dulo de n\u00facleo veeamsnap para las distribuciones SUSE utilizando OpenBuildService.<\/p>\n<p>A continuaci\u00f3n, me gustar\u00eda detenerme en temas espec\u00edficos para los m\u00f3dulos de n\u00facleo.<\/p>\n<h2>kernel ABI<\/h2>\n<p>\nLos m\u00f3dulos del n\u00facleo de Linux se han distribuido hist\u00f3ricamente en forma de c\u00f3digo fuente. Esto se debe a que los creadores del n\u00facleo no se preocupan por mantener una API estable para los m\u00f3dulos del n\u00facleo, y mucho menos a nivel binario, es decir, el kABI.<\/p>\n<p>Para compilar un m\u00f3dulo para el n\u00facleo vanilla, son necesarios los headers de ese n\u00facleo en concreto, y solo funcionar\u00e1 en ese n\u00facleo. <\/p>\n<p>DKMS permite automatizar el proceso de compilaci\u00f3n de m\u00f3dulos al actualizar el n\u00facleo. Como resultado, los usuarios del repositorio Debian (y sus numerosos parientes) utilizan m\u00f3dulos del n\u00facleo ya sea del repositorio del distribuidor o compilados a partir de c\u00f3digo fuente con DKMS.<\/p>\n<p>Sin embargo, esta situaci\u00f3n no satisface particularmente al segmento empresarial. Los distribuidores de c\u00f3digo propietario desean distribuir el producto en forma de binarios compilados. <\/p>\n<p>Los administradores no quieren tener herramientas de desarrollo en servidores de producci\u00f3n por razones de seguridad. Los distribuidores de Enterprise Linux \u2014 como Red Hat y SUSE \u2014 han decidido que podr\u00e1n mantener un kABI estable para sus usuarios. Como resultado, surgieron paquetes KMOD para Red Hat y paquetes KMP para SUSE.<\/p>\n<p>La esencia de esta soluci\u00f3n es bastante simple. Para una versi\u00f3n espec\u00edfica de la distribuci\u00f3n, la API del n\u00facleo se 'congela'. El distribuidor declara que utiliza exactamente el n\u00facleo, por ejemplo, 3.10, e introduce solo correcciones y mejoras que no afectan a las interfaces del n\u00facleo, y los m\u00f3dulos compilados para el primer n\u00facleo pueden ser utilizados para todos los posteriores sin necesidad de recompilaci\u00f3n.<\/p>\n<p>Red Hat declara que existe compatibilidad kABI para su distribuci\u00f3n a lo largo de todo su ciclo de vida. Es decir, un m\u00f3dulo compilado para RHEL 6.0 (lanzado en noviembre de 2010) tambi\u00e9n deber\u00eda funcionar en la versi\u00f3n 6.10 (lanzada en junio de 2018). Esto representa casi 8 a\u00f1os. Naturalmente, esta tarea es bastante compleja. <br \/>\nHemos registrado varios casos donde, debido a problemas de compatibilidad kABI, el m\u00f3dulo veeamsnap dej\u00f3 de funcionar. <\/p>\n<p>Despu\u00e9s de que el m\u00f3dulo veeamsnap, compilado para RHEL 7.0, result\u00f3 ser incompatible con el n\u00facleo de RHEL 7.5 y, sin embargo, se cargaba y garantizaba que el servidor se ca\u00eda, decidimos no utilizar la compatibilidad kABI para RHEL 7 en absoluto. <\/p>\n<p>En la actualidad, el paquete KMOD para RHEL 7 contiene una compilaci\u00f3n para cada versi\u00f3n de lanzamiento y un script que asegura la carga del m\u00f3dulo.<\/p>\n<p>SUSE adopt\u00f3 un enfoque m\u00e1s cauteloso hacia la compatibilidad kABI. Solo garantizan la compatibilidad kABI dentro de un solo service pack. <\/p>\n<p>Por ejemplo, el lanzamiento de SLES 12 fue en septiembre de 2014. Y SLES 12 SP1 en diciembre de 2015, es decir, pas\u00f3 poco m\u00e1s de un a\u00f1o. A pesar de que ambas versiones utilizan el n\u00facleo 3.12, son incompatibles con kABI. Es evidente que mantener la compatibilidad kABI durante solo un a\u00f1o es mucho m\u00e1s f\u00e1cil. Un ciclo anual de actualizaci\u00f3n del m\u00f3dulo del n\u00facleo no deber\u00eda causar problemas a los creadores de m\u00f3dulos. <\/p>\n<p>Como resultado de esta pol\u00edtica de SUSE, no hemos registrado ning\u00fan problema de compatibilidad kABI con nuestro m\u00f3dulo veeamsnap. Sin embargo, el n\u00famero de paquetes para SUSE es casi un orden de magnitud mayor.<\/p>\n<h2>Parches y backports<\/h2>\n<p>\nA pesar de que los distribuidores intentan garantizar la compatibilidad kABI y la estabilidad del n\u00facleo, tambi\u00e9n buscan mejorar el rendimiento y corregir los defectos de este n\u00facleo estable. <\/p>\n<p>Al mismo tiempo, adem\u00e1s de su propio \"trabajo en errores\", los desarrolladores del n\u00facleo enterprise linux monitorean los cambios en el n\u00facleo vanilla y los trasladan a su propio \"estable\".<\/p>\n<p>A veces esto lleva a nuevos <noindex><a rel=\"nofollow\" href=\"https:\/\/access.redhat.com\/solutions\/3658111\">errores<\/a><\/noindex>.<\/p>\n<p>En el \u00faltimo lanzamiento de Red Hat 6, se cometi\u00f3 un error en una de las actualizaciones menores. Esto provoc\u00f3 que el m\u00f3dulo veeamsnap garantizara que el sistema se colapsara al liberar un snapshot. Al comparar las fuentes del n\u00facleo antes y despu\u00e9s de la actualizaci\u00f3n, descubrimos que todo era culpa de un backport. Se realiz\u00f3 una correcci\u00f3n similar en el n\u00facleo vanilla versi\u00f3n 4.19. Sin embargo, en el n\u00facleo vanilla esta correcci\u00f3n funcionaba correctamente, mientras que al trasladarla al \"estable\" 2.6.32 surgi\u00f3 un problema de bloqueo en spin.<\/p>\n<p>Por supuesto, todos cometemos errores en alg\u00fan momento, pero \u00bfval\u00eda la pena trasladar el c\u00f3digo de 4.19 a 2.6.32, arriesgando la estabilidad? No estoy seguro...<\/p>\n<p>Lo peor es cuando el marketing se involucra en la tensi\u00f3n entre \"estabilidad\" y \"modernizaci\u00f3n\". Al departamento de marketing le gustar\u00eda que el n\u00facleo de la distribuci\u00f3n actualizada fuera estable, y al mismo tiempo fuese mejor en rendimiento y contar con nuevas funciones. Esto lleva a compromisos extra\u00f1os. <\/p>\n<p>Cuando intent\u00e9 compilar un m\u00f3dulo en el n\u00facleo 4.4 de SLES 12 SP3, me sorprendi\u00f3 descubrir que ten\u00eda funcionalidades del n\u00facleo 4.8 vanilla. En mi opini\u00f3n, la implementaci\u00f3n de la entrada\/salida en bloque del n\u00facleo 4.4 de SLES 12 SP3 se asemeja m\u00e1s al n\u00facleo 4.8 que al lanzamiento anterior del n\u00facleo 4.4 estable de SLES12 SP2. No me atrevo a juzgar qu\u00e9 porcentaje del c\u00f3digo del n\u00facleo 4.8 se traslad\u00f3 al 4.4 de SLES para SP3, pero no puedo llamarlo simplemente un n\u00facleo estable 4.4. <\/p>\n<p>Lo m\u00e1s molesto de esto es que al escribir un m\u00f3dulo que funcione igual de bien en diferentes n\u00facleos, ya no se puede confiar en la versi\u00f3n del n\u00facleo. Tambi\u00e9n hay que tener en cuenta la distribuci\u00f3n. Es bueno que a veces se pueda basar en una definici\u00f3n que aparece junto con la nueva funcionalidad, pero esta oportunidad no siempre se presenta. <\/p>\n<p>Como resultado, el c\u00f3digo se llena de directivas peculiares de compilaci\u00f3n condicional.<\/p>\n<p>Tambi\u00e9n hay parches que cambian la API documentada del n\u00facleo. <br \/>\nMe encontr\u00e9 con una distribuci\u00f3n <noindex><a rel=\"nofollow\" href=\"https:\/\/neon.kde.org\/\">KDE neon<\/a><\/noindex> 5.16 y me sorprendi\u00f3 al ver que la llamada a lookup_bdev en esta versi\u00f3n del n\u00facleo cambi\u00f3 la lista de par\u00e1metros de entrada.<\/p>\n<p>Para compilar, tuve que a\u00f1adir un script en el makefile que verifica si el par\u00e1metro mask est\u00e1 presente en la funci\u00f3n lookup_bdev.<\/p>\n<h2>Firma de los m\u00f3dulos del n\u00facleo<\/h2>\n<p>\nPero volvamos a la cuesti\u00f3n de la distribuci\u00f3n de paquetes.<\/p>\n<p>Una de las ventajas del kABI estable es que los m\u00f3dulos del n\u00facleo en forma de archivo binario se pueden firmar. En este caso, el desarrollador puede estar seguro de que el m\u00f3dulo no ha sido da\u00f1ado accidentalmente o modificado intencionadamente. Esto se puede verificar con el comando modinfo. <\/p>\n<p>Las distribuciones de Red Hat y SUSE permiten verificar la firma de un m\u00f3dulo y cargarlo solo si el certificado correspondiente est\u00e1 registrado en el sistema. El certificado es una clave p\u00fablica con la que se firma el m\u00f3dulo. Lo distribuimos en forma de paquete separado.<\/p>\n<p>El problema aqu\u00ed es que los certificados pueden estar integrados en el n\u00facleo (los utilizan los distribuidores) o deben ser escritos en la memoria no vol\u00e1til de EFI mediante una utilidad. <i>mokutil<\/i>. Utilidad <i>mokutil<\/i> al instalar un certificado se requiere reiniciar el sistema y antes de cargar el n\u00facleo del sistema operativo, se le pide al administrador que permita la carga de un nuevo certificado. <\/p>\n<p>Por lo tanto, agregar un certificado requiere acceso f\u00edsico del administrador al sistema. Si la m\u00e1quina est\u00e1 en la nube o simplemente en un servidor remoto y solo se tiene acceso a trav\u00e9s de la red (por ejemplo, por ssh), ser\u00e1 imposible agregar el certificado. <\/p>\n<h2>EFI en m\u00e1quinas virtuales<\/h2>\n<p>\nA pesar de que EFI ha sido admitido por pr\u00e1cticamente todos los fabricantes de placas madre desde hace mucho tiempo, al instalar el sistema, el administrador puede no pensar en la necesidad de EFI, y este puede estar desactivado. <\/p>\n<p>No todos los hipervisores soportan EFI. VMWare vSphere lo soporta desde la versi\u00f3n 5. <br \/>\nMicrosoft Hyper-V tambi\u00e9n ha agregado soporte para EFI, comenzando con Hyper-V para Windows Server 2012R2. <\/p>\n<p>Sin embargo, en la configuraci\u00f3n predeterminada, esta funcionalidad para m\u00e1quinas Linux est\u00e1 desactivada, lo que significa que no se puede instalar el certificado. <\/p>\n<p>En vSphere 6.5, se puede habilitar la opci\u00f3n <b>Secure Boot<\/b> solo en la versi\u00f3n anterior de la interfaz web que funciona a trav\u00e9s de Flash. La interfaz web en HTML-5 a\u00fan est\u00e1 bastante rezagada.<\/p>\n<h2>Distribuciones experimentales<\/h2>\n<p>\nY por \u00faltimo, consideremos la cuesti\u00f3n de las distribuciones experimentales y aquellas sin soporte oficial. Por un lado, es poco probable que tales distribuciones se encuentren en los servidores de organizaciones serias. No hay soporte oficial para estas distribuciones. Por lo tanto, no se puede proporcionar soporte t\u00e9cnico del producto en tales distribuciones. <\/p>\n<p>Sin embargo, estas distribuciones se convierten en una plataforma \u00fatil para probar nuevas soluciones experimentales. Por ejemplo, Fedora, OpenSUSE Tumbleweed o versiones inestables de Debian. Son bastante estables. Siempre tienen las versiones m\u00e1s recientes de los programas y siempre un n\u00facleo nuevo. Dentro de un a\u00f1o, esta funcionalidad experimental puede aparecer en una nueva versi\u00f3n de RHEL, SLES o Ubuntu. <\/p>\n<p>As\u00ed que si algo no funciona en una distribuci\u00f3n experimental, es una raz\u00f3n para investigar el problema y resolverlo. Se debe estar preparado para que esta funcionalidad aparezca pronto en los servidores de producci\u00f3n de los usuarios.<\/p>\n<p>La lista actual de distribuciones oficialmente compatibles con la versi\u00f3n 3.0 se puede consultar. <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/agentforlinux\/userguide\/system_requirements.html?ver=30\">aqu\u00ed<\/a><\/noindex>Sin embargo, la lista real de distribuciones en las que nuestro producto puede funcionar es mucho m\u00e1s amplia.<\/p>\n<p>Personalmente, me interes\u00f3 el experimento con el sistema operativo 'Elbrus'. Despu\u00e9s de modificar el paquete veeam, nuestro producto se instal\u00f3 y funcion\u00f3. Escrib\u00ed sobre este experimento en Habr en <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/veeam\/blog\/447960\/\">el art\u00edculo<\/a><\/noindex>. <\/p>\n<p>La compatibilidad con nuevas distribuciones contin\u00faa. Esperamos el lanzamiento de la versi\u00f3n 4.0. La beta deber\u00eda salir pronto, as\u00ed que est\u00e9n atentos a <noindex><a rel=\"nofollow\" href=\"https:\/\/www.veeam.com\/whats-new-linux-agent.html\">whats-new<\/a><\/noindex>!<br \/>\n<br \/>Fuente: <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\/es\/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=\"es_ES\" \/>\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\/es\/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 es vers\u00e1til: c\u00f3mo trabajar en cualquier distribuci\u00f3n | ProHoster","description":"Crear una aplicaci\u00f3n de respaldo.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/linux-mnogolikij-kak-rabotat-na-lyubom-distributive","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","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\/es\/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\/es\/wp-json\/wp\/v2\/posts\/38929","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=38929"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/38929\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/29206"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=38929"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=38929"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=38929"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}