En esta sección se utilizan varios términos especializados. Para comprender la información, lea las siguientes definiciones:

SUSE tiene el siguiente ciclo de vida útil:

SUSE presta asistencia a los paquetes de servicio (Service Packs) previos 6 meses tras la nueva versión del nuevo paquete de servicio. En la Figura 1.1, “Versiones principales y paquetes de servicio” se muestran algunos de los aspectos mencionados.

Figura 1.1: Versiones principales y paquetes de servicio #

 

Si necesita más tiempo para diseñar, validar y probar sus planes de actualización, la asistencia de paquetes de servicio a largo plazo (Long Term Service Pack Support, LTSS) puede ampliar la asistencia hasta 12 o 36 meses en incrementos de 12 meses. Esto proporciona un total de 2 a 5 años de asistencia para cualquier paquete de servicio. Para obtener información, consulte la Figura 1.2, “Asistencia de paquetes de servicio a largo plazo”.

Figura 1.2: Asistencia de paquetes de servicio a largo plazo #

 

Para obtener más información, consulte la https://www.suse.com/products/long-term-service-pack-support/.

Consulte https://www.suse.com/lifecycle para obtener más información acerca del ciclo de vida, la frecuencia de las versiones y el período de asistencia superpuesto.

Para obtener una lista de módulos, sus dependencias y ciclos de vida, consulte Article “Modules and Extensions Quick Start”.

SUSE Linux Enterprise Server puede comprobar periódicamente los cambios en el estado de compatibilidad de todos los productos instalados y enviar el informe por correo electrónico en caso de que haya cambios. Para generar el informe, instale zypper-lifecycle-plugin con zypper in zypper-lifecycle-plugin.

Habilite la generación de informes en el sistema con systemctl:

> sudo systemctl enable lifecycle-report.timer

El destinatario y el asunto del correo electrónico del informe, así como la frecuencia de generación de informes, se pueden configurar en el archivo /etc/sysconfig/lifecycle-report con cualquier editor de textos. Los ajustes MAIL_TO y MAIL_SUBJ definen el destinatario y el asunto del correo, mientras que DAYS establece la periodicidad con la que se genera el informe.

El informe muestra los cambios de estado de compatibilidad después de que se produzcan, pero no por adelantado. Si el cambio se produce justo después de la generación del último informe, pueden transcurrir hasta 14 días hasta que se le notifique el cambio. Téngalo en cuenta al definir la opción DAYS. Cambie las entradas de configuración siguientes según sus necesidades:

MAIL_TO='root@localhost'
MAIL_SUBJ='Lifecycle report'
DAYS=14

El informe más reciente está disponible en el archivo /var/lib/lifecycle/report. El archivo contiene dos secciones. En la primera se informa sobre el fin de la asistencia de los productos usados. En la secunda sección se muestran paquetes con sus fechas de finalización de la asistencia y la disponibilidad de actualizaciones.

El intervalo de los niveles de asistencia extendidos empieza el décimo año y termina el decimotercero. Implica un diagnóstico continuado de nivel de ingeniería L3 y reacciones para solucionar errores críticos. Con estos niveles de asistencia, recibirá actualizaciones para vulnerabilidades de seguridad raíz fácilmente explotables en el núcleo y sobre otras vulnerabilidades raíz que se pueden ejecutar directamente sin la interacción del usuario. Además, son compatibles con las cargas de trabajo existentes, las pilas de software y el hardware con listas limitadas de exclusión de paquetes. Consulte una descripción general en la Tabla 1.1, “Actualizaciones de seguridad y correcciones de errores”.

¹ Para obtener más información sobre la directiva de actualización de SUSE Linux Enterprise, consulte knowledgebase article .

Durante el registro, el sistema recibe repositorios del Centro de servicios al cliente de SUSE (consulte https://scc.suse.com/) o de un proxy de registro local como SMT. Los nombres de repositorios corresponden a URI específicos del centro del cliente. Para ver todos los repositorios disponibles del sistema, utilice zypper tal como se describe a continuación:

# zypper repos -u

Esto proporciona una lista de todos los repositorios disponibles en el sistema. Cada repositorio se indica según su alias, su nombre y si está habilitado y se actualizará. La opción -u también proporciona el URI desde donde se origina.

Para registrar el equipo, ejecute SUSEConnect, por ejemplo:

# SUSEConnect -r REGCODE

Para anular el registro del equipo, también puede usar SUSEConnect:

# SUSEConnect --de-register

Para comprobar los productos instalados localmente y su estado, utilice el comando siguiente:

# SUSEConnect -s

La asistencia de paquetes de servicio a largo plazo (Long Term Service Pack Support, LTSS por sus siglas en inglés) amplía la vida útil de SUSE Linux Enterprise Server. Está disponible como extensión. Para obtener más información acerca de LTSS, consulte https://www.suse.com/products/long-term-service-pack-support/

Si necesita identificar la versión de una instalación de SLE, compruebe el contenido del archivo /etc/os-release.

Puede utilizar zypper para obtener una salida XML que pueda leer su equipo:

> zypper --no-remote --no-refresh --xmlout --non-interactive products -i
<?xml version='1.0'?>
<stream>
<product-list>
<product name="SLES" version="15" release="0" epoch="0" arch="x86_64" vendor="SUSE" summary="SUSE Linux Enterprise Server 15" repo="@System" productline="sles" registerrelease="" shortname="SLES15" flavor="" isbase="true" installed="true"><endoflife time_t="0" text="0"/><registerflavor/><description>SUSE Linux Enterprise offers [...]</description></product>
</product-list>
</stream>

SUSE admite la actualización entre dos versiones principales de SUSE Linux Enterprise Server. Determinar si es mejor actualizar o realizar una instalación nueva depende de la situación específica. Aunque las actualizaciones implican menos trabajo, las nuevas instalaciones garantizan que se beneficiará de todas las nuevas funciones de una versión, como los cambios en la distribución del disco, las funciones específicas del sistema de archivos y otras mejoras. Por lo tanto, para obtener el máximo rendimiento del sistema, SUSE recomienda nuevas instalaciones en la mayoría de los casos.

En ambos casos, tanto la actualización como la instalación nueva, los clientes deben comprobar si los ajustes del sistema y los valores por defecto siguen siendo válidos para sus requisitos.

Para las actualizaciones de un paquete de servicio de una versión específica a otro del mismo flujo codificado, SUSE recomienda hacerlo in situ y no realizar una instalación nueva. Sin embargo, puede haber razones y situaciones en las que un cliente tenga que realizar una instalación nueva. Solo el cliente puede decidir cuál es la forma de instalación más adecuada.

Antes de realizar cualquier migración, consulte el Capítulo 3, Preparación de la actualización.

Importante: no se admiten actualizaciones de arquitecturas cruzadas

Las actualizaciones de arquitecturas cruzadas, como actualizar de una versión 32 bits de SUSE Linux Enterprise Server a la versión 64 bits, o actualizar de big-endian a little-endian, no se admiten.

Específicamente, SLE 11 en POWER (big endian) a SLE 15 SP6 en POWER (nuevo: little endian) no se admiten.

Además, como SUSE Linux Enterprise 15 es solo de 64 bits, las actualizaciones de cualquier sistema de 32 bits de SUSE Linux Enterprise 11 a SUSE Linux Enterprise 15 no se admiten.

Para realizar una actualización entre arquitecturas, deberá realizar una instalación nueva.

Nota: omisión de paquetes de servicio

La vía de actualización más sencilla es instalar consecutivamente todos los paquetes de servicio. Para la línea de productos SUSE Linux Enterprise 15 (GA y los paquetes de servicio posteriores), también se admite la omisión de hasta dos paquetes de servicio durante la actualización. Por ejemplo, se admite la actualización de SLE 15 SP3 a 15 SP6 (siempre que se admita SLE 15 SP3).

Figura 2.1: Resumen de las vías de actualización admitidas #

 

Aviso: actualización de bases de datos

Las vías de actualización descritas aquí solo se aplican a SUSE Linux Enterprise como sistema operativo de un equipo, no a todas las aplicaciones que ejecuta. Si tiene cargas de trabajo como las bases de datos PostgreSQL o MariaDB, es posible que se requieran actualizaciones intermedias del sistema operativo para actualizar las aplicaciones.

Antes de actualizar el sistema operativo, consulte las Release Notes para obtener información sobre las versiones de la base de datos. Si se envía una nueva versión principal, consulte el Capítulo 3, Preparación de la actualización para obtener instrucciones de actualización.

Nota: compatibilidad con la superposición de paquetes de servicios extendidos (ESPOS)

Para algunos productos, SUSE ofrece Extended Service Pack Overlap Support (ESPOS) en las mismas condiciones que LTSS. Para obtener más información sobre ESPOS, consulte la documentación del producto SUSE Linux Enterprise correspondiente y la página Web Product Lifecycle Support Policies.

SUSE admite los siguientes métodos de actualización y migración. Para obtener más información acerca de la terminología, consulte la Sección 1.1, “Terminología”. Los métodos son los siguientes:

Importante: clientes de SUSE Manager

Si el equipo se gestiona mediante SUSE Manager, actualícelo tal y como se describe en la documentación de SUSE Manager. El procedimiento de Client Migration se describe en el SUSE Manager Upgrade Guide, disponible en https://documentation.suse.com/suma/.

Solo se admite la actualización del sistema desde el parche más reciente. Asegúrese de que estén instaladas las últimas actualizaciones del sistema, ya sea ejecutando zypper patch o iniciando el módulo Actualización en línea de YaST.

Nota: nueva clave de firma de 4096 bits para SUSE Linux Enterprise 15

A mediados de 2023, la familia de productos SUSE Linux Enterprise 15 pasó de una clave de firma RSA de 2048 bits a una nueva clave RSA de 4096 bits. Este cambio cubre los paquetes RPM, los repositorios de paquetes y las firmas ISO. Los repositorios antiguos que ya no se actualizan y los RPM publicados hasta la fecha del cambio permanecerán firmados con la clave antigua de 2048 bits.

Si actualiza el sistema, la nueva clave se importa automáticamente en el anillo de claves RPM desde el paquete suse-build-key en SLE 15 SP4 y SP5, así como en las versiones LTSS de SLE 15 SP1, SP2 y SP3.

Si la clave aún no se ha importado, puede hacerlo manualmente con:

> sudo rpm --import /usr/lib/rpm/gnupg/keys/gpg-pubkey-3fa1d6ce-63c9481c.asc

Si está ejecutando una versión anterior de SLE o no ha importado la clave nueva, se le pedirá que confíe en ella durante la actualización. Asegúrese de que la huella digital coincide:

pub   rsa4096/0xF74F09BC3FA1D6CE 2023-01-19 [SC] [expires: 2027-01-18]
Key fingerprint = 7F00 9157 B127 B994 D5CF  BE76 F74F 09BC 3FA1 D6CE
uid           SUSE Package Signing Key <build@suse.de>

Además, se importó una clave RSA de reserva de 4096 bits para fines de recuperación tras fallos:

pub   rsa4096/0xA1BFC02BD588DC46 2023-01-19 [SC] [expires: 2033-01-16]
Key fingerprint = B56E 5601 41D8 F654 2DFF  3BF9 A1BF C02B D588 DC46
uid           SUSE Package Signing Key (reserve key) <build@suse.de>

Esta clave se puede importar manualmente mediante:

> sudo rpm --import /usr/lib/rpm/gnupg/keys/gpg-pubkey-d588dc46-63c939db.asc

Ambas claves también se pueden encontrar en los medios de instalación y en el sitio Web de SUSE en https://www.suse.com/support/security/keys/.

Encontrará una lista de todos los cambios, las funciones nuevas y los problemas conocidos en las release notes. Las notas de la versión también se encuentran en el medio de instalación, en el directorio docu.

Normalmente, las notas solo contienen los cambios entre dos versiones consecutivas. Si va a omitir uno o varios paquetes de servicio, compruebe también las notas de la versión de esos paquetes.

Consulte las notas de la versión para comprobar si se aplica lo siguiente:

Antes de actualizar, realice una copia de seguridad de los datos copiando los archivos de configuración existentes en un medio independiente (como un dispositivo de cinta, un disco duro extraíble, etc). Esta recomendación se aplica fundamentalmente a los archivos almacenados en /etc y en algunos directorios y archivos de /var y /opt. También puede ser conveniente escribir los datos de usuario en /home (los directorios HOME) en un medio de copia de seguridad.

Haga una copia de seguridad de todos los datos como usuario root. Solo los usuarios root disponen de permiso suficiente para todos los archivos locales.

Si ha seleccionado Actualizar un sistema existente como modo de instalación en YaST, puede optar por realizar una copia de seguridad (del sistema) en un momento posterior. Puede optar por incluir todos los archivos modificados y los archivos del directorio /etc/sysconfig. Sin embargo, no se trata de una copia de seguridad completa, ya que faltarían otros directorios importantes mencionados anteriormente. Busque la copia de seguridad en el directorio /var/adm/backup.

El software tiende a crecer de una versión a la siguiente. Por lo tanto, antes de actualizar debe saber de cuánto espacio dispone en la partición. Si sospecha que se está quedando sin espacio en disco, realice una copia de seguridad de los datos antes de aumentar el espacio disponible, por ejemplo al cambiar de tamaño las particiones. No existe ninguna regla general sobre cuánto espacio debe tener cada partición. Los requisitos de espacio dependen de cada perfil de particiones concreto y del software que se seleccione.

Nota: comprobación automática del espacio disponible en YaST

Durante el procedimiento de actualización, YaST comprueba cuánto espacio libre hay disponible en el disco y muestra una advertencia al usuario si la instalación puede superar esa cantidad. En ese caso, llevar a cabo la actualización puede producir que el sistema no puede usarse. Únicamente si sabe exactamente lo que está haciendo (por haberlo probado con antelación), puede omitir la advertencia y continuar la actualización.

Filesystem     Size  Used Avail Use% Mounted on
     /dev/sda3       74G   22G   53G  29% /
     tmpfs          506M     0  506M   0% /dev/shm
     /dev/sda5      116G  5.8G  111G   5% /home
     /dev/sda1       44G    4G   40G   9% /data

Resulta útil guardar una lista de paquetes instalados, por ejemplo, al realizar una instalación nueva de una versión principal nueva de SLE o al revertir a una versión anterior.

Nota

Tenga en cuenta que no todos los paquetes instalados ni los repositorios utilizados están disponibles en las versiones más recientes de SUSE Linux Enterprise. Puede que algunos hayan cambiado de nombre o que se hayan sustituido. También es posible que algunos paquetes sigan estando disponibles por compatibilidad con versiones anteriores o que otros se utilicen por defecto. Por lo tanto, podría ser necesario realizar alguna modificación manual de los archivos. Esto se puede realizar con cualquier editor de textos.

Si actualiza un sistema SUSE Linux Enterprise Server con LTSS (asistencia de paquetes de servicio a largo plazo) a una versión que aún recibe asistencia general, la actualización fallará con el error No migration available (No hay ninguna migración disponible). Esto ocurre porque zypper migration intenta migrar todos los repositorios, pero todavía no hay ningún repositorio LTSS para la nueva versión.

Para solucionar este problema, inhabilite la extensión LTSS antes de la actualización.

SUSE Linux Enterprise Server 15 SP6 incluye las versiones 14 y 15 de la base de datos PostgreSQL. Aunque la versión 15 es la versión por defecto, la versión 14 aún se proporciona a través del módulo Legacy para las actualizaciones desde versiones anteriores de SUSE Linux Enterprise Server.

Debido al trabajo de migración necesario de la base de datos, no existe un proceso de actualización automático. Por lo tanto, el cambio de una versión a otra se debe realizar manualmente.

El proceso de migración se realiza mediante el comando pg_upgrade, que es un método alternativo al clásico de volcado y recarga. En comparación con el método de “volcado y recarga”, con pg_upgrade la migración tarda menos tiempo.

Los archivos de programa de cada versión de PostgreSQL se almacenan en directorios distintos según dicha versión. Por ejemplo, en /usr/lib/postgresql96/ para la versión 9.6, en /usr/lib/postgresql10/ para la versión 10 y en /usr/lib/postgres13/ para la versión 13. Tenga en cuenta que la directiva de control de versiones de PostgreSQL ha cambiado entre las versiones principales 9.6 y 10. Para obtener información, consulte https://www.postgresql.org/support/versioning/.

Importante: actualización desde SLE 11

Al actualizar desde SLE 11, postgresql94 se desinstalará y no se podrá usar para la migración de la base de datos a una versión superior de PostgreSQL. Por lo tanto, en este caso, asegúrese de migrar la base de datos PostgreSQL antes de actualizar el sistema.

El procedimiento siguiente describe la migración de la base de datos de la versión 12 a la 13. Si se utiliza una versión distinta como inicio o destino, sustituya los números de versión según sea preciso.

Para realizar la migración de la base de datos, siga el siguiente procedimiento:

Para obtener más información sobre la actualización de bases de datos o el uso de métodos alternativos, como la réplica lógica, consulte la documentación oficial de PostgreSQL en https://www.postgresql.org/docs/13/upgrading.html.

A partir de la versión SUSE Linux Enterprise 12, SUSE cambió de MySQL a MariaDB. Antes de empezar cualquier actualización, se recomienda encarecidamente realizar una copia de seguridad de la base de datos.

Para realizar la migración de la base de datos, siga el siguiente procedimiento:

Como medida de seguridad, los certificados basados en MD5 ya no se admiten en Java. Si dispone de certificados creados como MD5, emplee los pasos siguientes para volver a crear los certificados:

Si el equipo hace de servidor host de máquina virtual para KVM o Xen, asegúrese de apagar correctamente cualquier máquina virtual invitada en ejecución antes de actualizar. De lo contrario, quizá no pueda acceder a los sistemas invitados tras la actualización.

Si el equipo que desea actualizar se ha registrado como cliente en un servidor SMT, tenga en cuenta lo siguiente:

Compruebe si la versión del guion clientSetup4SMT.sh del host está actualizada. El guion clientSetup4SMT.sh de versiones anteriores de SMT no puede gestionar clientes de SMT 12. Si se aplican parches de software con regularidad en el servidor SMT, siempre encontrará la versión más reciente de clientSetup4SMT.sh en <SMT_HOSTNAME>/repo/tools/clientSetup4SMT.sh.

Si no consigue actualizar el equipo a una versión superior de SUSE Linux Enterprise Server, anule el registro del equipo del servidor SMT como se describe en el Procedimiento 3.1. A continuación, reinicie el proceso de actualización.

Para obtener información sobre cómo migrar los perfiles de AutoYaST, consulte Book “AutoYaST Guide”, .

Un servidor que ejecuta SMT requiere un procedimiento de actualización especial. Consulte Book “Repository Mirroring Tool Guide”, Chapter 3 “Migrate from SMT to RMT” en la Guía de la Herramienta de duplicación de repositorios.

SUSE Linux Enterprise Server permite instalar varias versiones del núcleo habilitando sus ajustes correspondientes en /etc/zypp/zypp.conf. Para actualizar un paquete de servicio, hay que inhabilitar de forma temporal la compatibilidad con esta función. Cuando la actualización finalice correctamente, la compatibilidad multiversión se puede volver a habilitar. Para inhabilitar la compatibilidad multiversión, comente las líneas correspondientes en /etc/zypp/zypp.conf. El resultado debe ser similar a este:

#multiversion = provides:multiversion(kernel)
#multiversion.kernels = latest,running

Para volver a activar esta función después de una actualización correcta, elimine el signo de comentario. Para obtener más información acerca de la compatibilidad multiversión, consulte el Book “Administration Guide”, Chapter 27 “Installing multiple kernel versions”, Section 27.1 “Enabling and configuring multiversion support”.

En los sistemas que se han instalado con SUSE Linux Enterprise Server 12 o versiones anteriores, la línea de comandos del kernel por defecto en /etc/default/grub puede contener un parámetro resume que utilice un nombre de nodo de dispositivo como /dev/sda1 para hacer referencia al dispositivo de hibernación (suspensión en disco). Dado que los nombres de los nodos de los dispositivos no son permanentes y pueden cambiar entre rearranques, se recomienda encarecidamente solucionar este problema. De lo contrario, el sistema actualizado puede bloquearse al rearrancar.

Si el sistema no utiliza la hibernación, basta con eliminar el parámetro resume y actualizar la configuración de arranque.

Para actualizar una instalación de SUSE Linux Enterprise en IBM Z, es necesario introducir el parámetro de núcleo Upgrade=1, por ejemplo mediante un archivo parmfile. Consulte el Book “Guía de distribución”, Chapter 5 “Instalación en IBM Z y LinuxONE”, Section 5.5 “Archivo parmfile: automatización de la configuración del sistema”.

En SLES 12 para IBM POWER, el gestor de pantalla está configurado para que no inicie un X Server local por defecto. Este valor se cambió en SLES 12 SP1: el gestor de pantalla inicia ahora un X Server.

Para evitar problemas durante la actualización, los ajustes de SUSE Linux Enterprise Server no cambian automáticamente. Si desea que el gestor de pantalla inicie un X Server después de la actualización, cambie la configuración de DISPLAYMANAGER_STARTS_XSERVER en /etc/sysconfig/displaymanager como se indica a continuación:

DISPLAYMANAGER_STARTS_XSERVER="yes"

Antes de actualizar el sistema, lea el Capítulo 3, Preparación de la actualización.

Para actualizar el sistema, arranque desde un origen de instalación, como haría en el caso de una instalación nueva. Sin embargo, cuando aparece la pantalla de arranque, debe seleccionar la opción Actualizar (en lugar de Instalación). La actualización se puede iniciar desde:

El procedimiento siguiente describe el arranque desde un DVD, pero también es posible usar otro medio de instalación local, como una imagen ISO o un dispositivo de almacenamiento masivo USB. El medio y el método de arranque que seleccione dependerán de la arquitectura del sistema y de si el equipo dispone de BIOS tradicional o UEFI.

Para iniciar una actualización desde un origen de instalación de red, compruebe que se cumplen los siguientes requisitos:

Antes de actualizar el sistema, lea el Capítulo 3, Preparación de la actualización. Para realizar una migración automatizada, proceda como se indica:

Nota: centro de servicios al cliente de SUSE y conexión a Internet

Si el sistema que desea actualizar está registrado en el Centro de servicios al cliente de SUSE, asegúrese de que dispone de conexión a Internet durante el procedimiento siguiente.

1. Después de arrancar (ya sea desde un medio de instalación o desde la red), seleccione la opción Actualizar en la pantalla de arranque.

   

   Aviso: una elección equivocada puede provocar la pérdida de datos

   Asegúrese de que ha seleccionado Actualizar. En caso de que seleccione Instalación por error, la partición de datos se sobrescribirá con una instalación nueva.

   YaST inicia el sistema de instalación.

2. En la pantalla Bienvenido, seleccione el Idioma y el Teclado. Haga clic en Siguiente.

   YaST comprueba en las particiones si hay sistemas SUSE Linux Enterprise ya instalados.

3. En la pantalla Seleccionar para actualizar, seleccione la partición que desea actualizar y haga clic en Siguiente.

4. YaST monta la partición seleccionada y muestra el acuerdo de licencia del producto actualizado. Para continuar, acepte la licencia.

5. En la pantalla Repositorios usados anteriormente, ajuste el estado de los repositorios. Por defecto se eliminan todos los repositorios. Si no ha añadido ningún repositorio personalizado, no modifique los valores. Los paquetes para la actualización se instalarán desde el DVD y, opcionalmente, podrá habilitar los repositorios en línea por defecto en el paso siguiente.

   Si tiene repositorios personalizados, dispondrá de dos opciones:

   • Deje el repositorio en estado Eliminado. El software que se haya instalado desde este repositorio se eliminará durante la actualización. Utilice este método si no hay ninguna versión del repositorio que coincida con la nueva versión.

   • Actualice y habilite el repositorio si coincide con la nueva versión. Cambie la URL haciendo clic en el repositorio en la lista y, a continuación, en Cambiar. Habilite el repositorio marcando la casilla de verificación Cambiar estado hasta que aparezca la opción Habilitar.

   No conserve los repositorios de la versión anterior, ya que el sistema puede dejar de ser estable o dejar de funcionar. Para continuar, haga clic en Siguiente.

6. El siguiente paso depende de si el sistema actualizado está registrado o no en el Centro de servicios al cliente de SUSE.

   1. Si el sistema no está registrado en el Centro de servicios al cliente de SUSE, YaST muestra un mensaje emergente que sugiere utilizar un segundo medio de instalación, la imagen SLE-15-SP6-Full-ARCH-GM-media1.iso.

      Si no dispone de ese medio, no es posible actualizar el sistema sin registro.

   2. Si el sistema está registrado, YaST mostrará destinos de migración posibles y un resumen.

      Seleccione un destino de migración de la lista y haga clic en Siguiente.

7. En el recuadro de diálogo siguiente, puede añadir opcionalmente un medio de instalación adicional. Si dispone de medios de instalación adicionales, active la opción Deseo instalar otro producto adicional y especifique el tipo de medio.

8. Revise la Configuración de la instalación de la actualización.

9. Si está de acuerdo con todos los valores, inicie el procedimiento de instalación y eliminación haciendo clic en Actualizar.

   

   Sugerencia: fallo de actualización en clientes SMT

   Si el equipo que desea actualizar es un cliente SMT y no se puede realizar la actualización, consulte el Procedimiento 3.1, “Anulación de un cliente de SUSE Linux Enterprise desde un servidor SMT” y reinicie el procedimiento de actualización más tarde.

10. Después de que el proceso de actualización haya finalizado correctamente, realice los pasos posteriores a la actualización descritos en el Capítulo 6, Finalización de la actualización.

El proceso de actualización se puede ejecutar de forma automática. Para obtener información, consulte el Book “AutoYaST Guide”, Chapter 4 “Configuration and installation options”, Section 4.11 “Upgrade”.

SUSE Manager es una solución de servidor para proporcionar actualizaciones, parches y soluciones de seguridad para los clientes de SUSE Linux Enterprise. Incorpora un conjunto de herramientas y una interfaz de usuario Web para tareas de gestión. Consulte https://www.suse.com/products/suse-manager/ para obtener más información sobre SUSE Manager.

Puede realizar una actualización del sistema mediante SUSE Manager. La tecnología AutoYaST permite realizar actualizaciones de una versión principal a la siguiente.

Si el equipo se gestiona mediante SUSE Manager, actualícelo tal y como se describe en la documentación de SUSE Manager. El procedimiento de Client Migration se describe en SUSE Manager Upgrade Guide, disponible en https://documentation.suse.com/suma/.

Cuando se realiza una actualización del paquete de servicio, es necesario cambiar la configuración en el servidor de registro para proporcionar acceso a los nuevos repositorios. Si el proceso de actualización se interrumpe o se revierte (mediante la restauración desde una copia de seguridad o de una instantánea), la información del servidor de registro será incoherente con el estado del sistema. Esto puede producir que se impida al usuario el acceso a los repositorios de actualización o que se usen repositorios incorrectos en el cliente.

Cuando se realiza una operación de reversión mediante Snapper, se notifica al servidor de registro para garantizar que el acceso a los repositorios correctos se haya configurado durante el proceso de arranque. Si se ha restaurado el sistema con otro método o la comunicación con el servidor de registro falla, active la reversión manualmente en el cliente. Un ejemplo de activación manual de una reversión puede ser que el servidor no estaba disponible debido a problemas de red. Para llevar a cabo una reversión, ejecute:

> sudo snapper rollback

Se recomienda comprobar siempre que los repositorios correctos están configurados en el sistema, sobre todo después de actualizar el servicio con el comando:

> sudo zypper ref -s

Esta función está disponible en el paquete rollback-helper.

Si el sistema no se ha registrado antes de ejecutar la actualización, puede registrarlo en cualquier momento mediante el módulo Registro del producto de YaST.

Registrar los sistemas presenta las ventajas siguientes:

SUSE publica nuevos paquetes de servicio para la familia de SUSE Linux Enterprise a intervalos regulares. Para facilitar a los clientes la migración a un nuevo paquete de servicio y reducir el tiempo de inactividad, SUSE admite la migración en línea mientras se esté ejecutando el sistema.

A partir de SLE 12, YaST Wagon se ha sustituido por la migración de YaST (GUI) y la migración de Zypper (línea de comandos). Esto presenta las siguientes ventajas:

Aviso: la migración en línea no es compatible con las versiones principales

La migración en línea solo es compatible con la migración entre paquetes de servicio. La migración en línea no es compatible con la actualización a nuevas versiones principales. Para obtener información, consulte el Capítulo 2, Vías y métodos de actualización.

Utilice la migración sin conexión para realizar la actualización a una nueva versión principal. Para obtener información, consulte el Capítulo 4, Actualización sin conexión.

Importante: actualización de clientes de SUSE Manager

Si el sistema que va a actualizar es un cliente de SUSE Manager, no se puede actualizar mediante la migración en línea de YaST ni mediante zypper migration. En su lugar, utilice el procedimiento de Client Migration. Se describe en SUSE Manager Upgrade Guide.

Es posible ejecutar una migración del paquete de servicio mediante YaST, zypper o AutoYaST.

Antes de que pueda iniciar una migración de paquete de servicio, el sistema debe estar registrado en el Centro de servicio al cliente de SUSE o en un servidor RMT local. También puede utilizarse SUSE Manager.

Independientemente del método utilizado, la migración de un paquete de servicio consta de los pasos siguientes:

La lista de destinos de migración depende de los productos que haya instalado y registrado. Si tiene una extensión instalada para la que aún no haya disponible un paquete de servicio nuevo, puede que no se le ofrezca ningún destino de migración.

La lista de destinos de migración disponibles para el host siempre se recupera desde el Centro de servicios al cliente de SUSE y depende de los productos o extensiones instalados.

La migración del paquete de servicio solo se puede cancelar en etapas concretas durante el proceso de migración:

Para realizar la migración de un paquete de servicio con YaST, use la herramienta Migración en línea. Por defecto, YaST no instala ningún paquete desde repositorios de otros fabricantes. Si se ha instalado un paquete desde un repositorio de otro fabricante, YaST impide que los paquetes se sustituyan por los mismos paquetes provenientes de SUSE.

Nota: reducción del tamaño de la instalación

Al realizar la migración del paquete de servicio, YaST instala todos los paquetes recomendados. Especialmente en el caso de las instalaciones mínimas personalizadas, esto puede aumentar el tamaño de instalación del sistema considerablemente.

Para cambiar este comportamiento por defecto y permitir solo los paquetes necesarios, ajuste la opción solver.onlyRequires en /etc/zypp/zypp.conf.

solver.onlyRequires = true

Además, edite el archivo /etc/zypp/zypper.conf y cambie la opción installRecommends.

installRecommends=false

Esto cambia el comportamiento de todas las operaciones del paquete, como la instalación de parches o nuevos paquetes. Para cambiar el comportamiento de Zypper en una única invocación, utilice el parámetro --no-recommends.

Para iniciar la migración del paquete de servicio, haga lo siguiente:

Para realizar la migración de un paquete de servicio con Zypper, use la herramienta de línea de comandos zypper migration del paquete zypper-migration-plugin.

Nota: reducción del tamaño de la instalación

Al realizar la migración del paquete de servicio, YaST instala todos los paquetes recomendados. Especialmente en el caso de las instalaciones mínimas personalizadas, esto puede aumentar el tamaño de instalación del sistema considerablemente.

Para cambiar este comportamiento por defecto y permitir solo los paquetes necesarios, ajuste la opción solver.onlyRequires en /etc/zypp/zypp.conf.

solver.onlyRequires = true

Además, edite el archivo /etc/zypp/zypper.conf y cambie la opción installRecommends.

installRecommends=false

Esto cambia el comportamiento de todas las operaciones del paquete, como la instalación de parches o nuevos paquetes. Para cambiar el comportamiento de Zypper en una única invocación, utilice el parámetro --no-recommends.

Para iniciar la migración del paquete de servicio, haga lo siguiente:

Si el sistema no se registra porque el usuario no tiene acceso a Internet ni a un servidor de registro, no es posible migrar a un nuevo paquete de servicio con la migración de YaST ni con zypper migration. En ese caso, puede realizar la migración a un nuevo paquete de servicio con Zypper simple y algunas interacciones manuales.

Importante: solo para sistemas no registrados

Esta vía de migración a un nuevo paquete de servicio solo se admite en los sistemas no registrados que no tienen acceso a Internet o a un servidor de registro. Por ejemplo, puede ser el caso de equipos que se encuentren en una red especialmente protegida. En caso de que tenga un sistema registrado, utilice la migración de YaST o de Zypper.

Importante: orígenes de instalación

Esta vía de migración requiere que el sistema que se va a migrar tenga acceso a los orígenes de instalación. Por ejemplo, esto se puede hacer configurando un servidor RMT o un servidor SLP.

También es necesario que el sistema tenga acceso a un repositorio de actualización que esté al día para la versión del producto instalada.

Si un paquete de servicio no funciona, SUSE Linux Enterprise permite revertir el sistema a su estado anterior antes de iniciar la migración. Uno de los requisitos previos es una partición de raíz Btrfs con las instantáneas habilitadas (se trata de la opción por defecto desde SLES 12). Consulte el Book “Administration Guide”, Chapter 10 “System recovery and snapshot management with Snapper” para obtener más información.

Ya ha revertido correctamente el sistema al estado que se capturó inmediatamente antes de que se iniciara la migración del paquete de servicios.

SUSE Manager es una solución de servidor para proporcionar actualizaciones, parches y soluciones de seguridad para los clientes de SUSE Linux Enterprise. Incorpora un conjunto de herramientas y una interfaz de usuario Web para tareas de gestión. Consulte https://www.suse.com/products/suse-manager/ para obtener más información sobre SUSE Manager.

Con este método, puede migrar desde un paquete de servicio (SP) a otro dentro de una versión principal (por ejemplo, de SLES 15 GA a SLES 15 SP6).

Si el equipo se gestiona mediante SUSE Manager, actualícelo tal y como se describe en la documentación de SUSE Manager. El procedimiento de Client Migration se describe en el SUSE Manager Upgrade Guide, disponible en https://documentation.suse.com/suma/.

Puede actualizar una instalación de openSUSE Leap a SUSE Linux Enterprise Server. Para averiguar qué versiones de Leap son compatibles con la migración, consulte la Sección 2.2, “Vías de actualización y migración a SLES 15 SP6 admitidas”.

Aviso: no todos los paquetes de openSUSE se pueden migrar

openSUSE proporciona más paquetes que SUSE Linux Enterprise Server. La mayoría de los paquetes adicionales están disponibles a través de SUSE Package Hub y se migrarán. Los paquetes adicionales que no estén disponibles a través de SUSE Package Hub dejarán de recibir actualizaciones después de la migración y, por lo tanto, deberán eliminarse posteriormente.

Asegúrese de que todos los paquetes que necesita para que funcione el sistema están disponibles en los repositorios de SUSE Linux Enterprise Server y de SUSE Package Hub. Para obtener más información sobre SUSE Package Hub, consulte https://packagehub.suse.com/.

Use zypper packages para comprobar si hay paquetes huérfanos o innecesarios.

Los paquetes huérfanos ya no están disponibles en ninguno de los repositorios de paquetes configurados. Ya no se pueden actualizar y han dejado de admitirse.

Para obtener una lista de paquetes huérfanos, ejecute:

> zypper packages --orphaned

Los paquetes innecesarios son dependencias de paquetes que fueron instalados explícitamente por el usuario o implícitamente como parte de un patrón o producto, y que se han eliminado desde entonces. Ya no suelen ser necesarios y también deben eliminarse.

Para obtener una lista de paquetes innecesarios, ejecute:

> zypper packages --unneeded

Sugerencia

Para evitar paquetes innecesarios, use zypper rm con la opción --clean-deps o YaST con Opciones › Limpiar al eliminar los paquetes habilitado.

Puede combinar ambas listas en una sola:

> zypper packages --orphaned --unneeded

Utilice estas listas para determinar qué paquetes siguen siendo necesarios y cuáles se pueden eliminar de forma segura.

Aviso: no elimine los paquetes que necesite

Si los paquetes se renombran o se eliminan de un patrón o producto, es posible que zypper ya considere que están instalados explícitamente y los marque como innecesarios, aunque sigan siendo cruciales para la instalación.

Revise atentamente la lista de paquetes que va a eliminar.

Para eliminar todos los paquetes huérfanos e innecesarios con un solo comando, ejecute:

> sudo zypper rm $(zypper --no-refresh packages --orphaned --unneeded | gawk '{print $5}' | tail -n +5)

Para excluir un único paquete o patrón para que no se desinstale:

> sudo zypper rm $(zypper --no-refresh packages --orphaned --unneeded | gawk '{print $5}' | tail -n +5 | grep -v PACKAGE_TO_EXCLUDE)

Para excluir varios paquetes definidos en un archivo de texto, separados por una línea nueva:

> sudo zypper rm $(zypper --no-refresh packages --orphaned --unneeded | gawk '{print $5}' | tail -n +5 | grep -v -f /PACKAGES/TO/KEEP.txt)

Compruebe si hay archivos *.rpmnew y *.rpmsave. Si una actualización incluye cambios en un archivo de configuración por defecto que se ha modificado después de la instalación del paquete, en lugar de sobrescribir el archivo, se crea uno de estos tipos de archivo. *.rpmnew contiene la nueva configuración por defecto y no toca el archivo original, pero *.rpmsave es una copia de la configuración original modificado que se ha sustituido por el nuevo archivo por defecto.

Si encuentra alguno de estos archivos, examine su contenido y combine los cambios que desee. No es necesario buscar en todo el sistema de archivos, solo en el directorio /etc. Utilice el comando siguiente:

> find /etc/ -name "*.rpmnew" -o -name "*.rpmsave"

SUSE Linux Enterprise Server 15 utiliza Python 3.6 por defecto. Como alternativa más reciente, en SLES 15 SP3 se añadió Python 3.9. Esta versión ya no se admite a partir de SLES 15 SP4. En su lugar, las versiones recientes de Python con actualizaciones importantes y correcciones de seguridad están disponibles mediante el módulo Python 3.

Si ha instalado Python 3.9 en SUSE Linux Enterprise Server 15 SP3, habilite el módulo Python 3 con:

> sudo SUSEConnect -p sle-module-python3/15.6/x86_64.

Como alternativa, puede volver a la versión por defecto de Python eliminando la versión 3.9 con zypper remove -u python39.

SUSE Linux Enterprise Server admite el “formato en disco” (v5) del sistema de archivos XFS. Las principales ventajas de este formato son las sumas de comprobación automáticas de todos los metadatos de XFS, la compatibilidad con tipos de archivos y la compatibilidad con un mayor número de listas de control de acceso para un archivo.

Tenga en cuenta que este formato no es compatible con los núcleos de SUSE Linux Enterprise anteriores a la versión 3.12, con xfsprogs anterior a la versión 3.2.0 ni con versiones de GRUB 2 anteriores a SUSE Linux Enterprise 12.

Importante: V4 ya no se admite

XFS está abandonando los sistemas de archivos con el formato V4. Este formato de sistema de archivos se creó con el comando:

> sudo mkfs.xfs -m crc=0 DEVICE

El formato se utilizó en SLE 11 y versiones anteriores, y actualmente crea un mensaje de advertencia de dmesg:

Deprecated V4 format (crc=0) will not be supported after September 2030

Si ve el mensaje anterior como resultado del comando dmesg, se recomienda que actualice el sistema de archivos al formato V5:

1. Realice una copia de seguridad de los datos en otro dispositivo.

2. Cree el sistema de archivos en el dispositivo.

   > sudo mkfs.xfs -m crc=1 DEVICE

3. Restaure los datos de la copia de seguridad en el dispositivo actualizado.

A los desarrolladores en sentido ascendente les preocupa sobre todo que avance el software que están creando. A menudo, combinan las soluciones de errores con nuevas funciones que todavía no se han sometido a pruebas exhaustivas y pueden introducir nuevos fallos.

Para los desarrolladores de distribuciones, es importante distinguir entre:

Normalmente, los desarrolladores de distribuciones no siguen todos los cambios en sentido ascendente cuando un paquete forma parte de una distribución publicada. Normalmente se limitan a la versión en sentido ascendente que han publicado inicialmente y crean parches basados en los cambios para solucionar errores. Esta práctica se conoce como backport.

Normalmente, los desarrolladores de distribuciones solo introducen nuevas versiones del software en dos casos:

SUSE usa ampliamente el enfoque de actualización retroactiva (backport), ya que nos permite ofrecer un buen equilibrio respecto a numerosas consideraciones que afectan al software de empresa. Las más importantes son las siguientes:

Es una regla general de nuestras directivas no introducir nuevas versiones en sentido ascendente de un paquete en los productos de empresa. Sin embargo, no es una regla inexcusable. En el caso de ciertos tipos de paquetes, especialmente los de software antivirus, las consideraciones de seguridad tienen prioridad sobre el enfoque conservador, preferible desde el punto de vista de las garantías de calidad. Para los paquetes de esa clase, ocasionalmente se introducen nuevas versiones en una versión publicada de una línea de productos de empresa.

A veces, para otros tipos de paquetes, también se decide introducir una nueva versión en lugar del enfoque de backport. Esta decisión se toma cuando el backport no es económicamente factible o cuando hay un motivo técnico relevante para introducir la nueva versión.

Debido al enfoque de backport, no es posible comparar sencillamente los números de versiones para determinar si un paquete de SUSE contiene una solución para un problema en concreto o se le ha añadido una función determinada. Con el backport, la parte de sentido ascendente del número de versión de un paquete de SUSE solamente indica en qué versión de sentido ascendente se basa el paquete de SUSE. Puede incluir correcciones de errores y funciones que no estén en la versión de sentido ascendente que corresponda, pero que se hayan incluido en el paquete de SUSE a través de backport.

Un aspecto en concreto que puede provocar problemas en lo que respecta al valor limitado de los números de versión en relación con el enfoque de backport, es el de las herramientas de seguridad. Algunas herramientas de seguridad (o determinadas pruebas de dichas herramientas) solo emplean la información de versiones. Estas herramientas y pruebas, por tanto, son susceptibles de generar “falsos positivos” (cuando una parte del software se identifica como vulnerable de forma errónea) cuando hay versiones de backport implicadas. Al evaluar informes de herramientas de análisis de seguridad, compruebe siempre si una entrada se basa en un número de versión o en una prueba real de vulnerabilidad.

La información acerca de las funciones y las correcciones de errores con versiones anteriores se almacena en varias ubicaciones: