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 SP2 en POWER (nuevo: little endian) no se admiten.

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

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

Nota: omisión de los paquetes de servicio

La vía de actualización más sencilla es instalar de forma consecutiva todos los paquetes de servicio. Para la línea de productos de SUSE Linux Enterprise 15 (GA y los paquetes de servicio siguientes) se permite omitir un paquete de servicio al realizar la actualización. Por ejemplo, se puede actualizar de SLE 15 GA a SLE 15 SP2, o de SLE 15 SP1 a SLE 15 SP3.

Nota: actualización de versiones principales

Se recomienda realizar una instalación nueva al actualizar a una nueva versión principal; por ejemplo, de SUSE Linux Enterprise 12 a SUSE Linux Enterprise 15.

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

 

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 2.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 migración del cliente se describe en la Guía de actualización de SUSE Manager, disponible en https://documentation.suse.com/suma/.

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

SUSE presenta el siguiente ciclo de vida para los productos:

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 2.1, “Versiones principales y paquetes de servicio” se muestran algunos de los aspectos mencionados.

Figura 2.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: Figura 2.2, “Asistencia de paquetes de servicio a largo plazo (Long Term Service Pack Support, LTSS)”.

Figura 2.2: Asistencia de paquetes de servicio a largo plazo (Long Term Service Pack Support, LTSS) #

 

Para obtener más información, consulte 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:

root # systemctl enable lifecycle-report

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 2.1, “Actualizaciones de seguridad y correcciones de errores”.

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:

root # 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:

root # SUSEConnect -r REGCODE

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

root # SUSEConnect --de-register

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

root # SUSEConnect -s

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:

tux > 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>

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.

En las notas de la versión puede encontrar información adicional sobre los cambios realizados desde la versión previa de SUSE Linux Enterprise Server. Consulte las notas de versión para comprobar lo siguiente:

Las notas de la versión también proporcionan información que no pudo publicarse en el manual a tiempo y notas acerca de problemas conocidos.

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

Puede consultar la versión actual de las notas de la versión en línea en https://www.suse.com/releasenotes/.

También puede buscar las notas de la versión en el directorio docu del DVD de instalación.

Antes de actualizar, copie los archivos de configuración existentes en un medio independiente (un dispositivo de cinta, un disco duro extraíble, etc.) para realizar una copia de seguridad de los datos. 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 del directorio /home (los directorios HOME) en un medio de copia de seguridad. Haga una copia de seguridad de esos datos como usuario root. Solo los usuarios root disponen de permiso de lectura 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 seleccionar la inclusión de 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.

A menudo, 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.

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.

Cree un archivo denominado repositories.bak.repo que contenga una lista de todos los repositorios utilizados:

root # zypper lr -e repositories.bak

Cree también un archivo denominado installed-software.bak que contenga una lista de todos los paquetes instalados:

root # rpm -qa --queryformat '%{NAME}\n' > installed-software.bak

Realice una copia de seguridad de ambos archivos. Los repositorios y los paquetes instalados se pueden restaurar con los comandos siguientes:

root # zypper ar repositories.bak.repo
root # zypper install $(cat installed-software.bak)

Nota: el número de paquetes aumenta con una actualización a una nueva versión principal

Un sistema actualizado a una nueva versión principal (SLE X+1) puede contener más paquetes que el sistema inicial (SLE X). También contendrá más paquetes que una instalación nueva de SLE X+1 con la misma selección de patrón. Algunos de los posibles motivos son los siguientes:

• Los paquetes se han dividido para ofrecer una selección más precisa. Por ejemplo, los 37 paquetes de texlive de SLE 11 se dividieron en 3000 paquetes en SLE 15.

• Cuando un paquete se divide, se instalan todos los paquetes durante la actualización para conservar la misma funcionalidad de la versión anterior. Sin embargo, una instalación nueva de SLE X+1 podría no instalar por defecto todos los paquetes.

• Los paquetes heredados de SLE X podrían conservarse por razones de compatibilidad.

• Las dependencias de paquetes y el ámbito de los patrones pueden haber cambiado.

Si utiliza certificados MySQL, PostgreSQL o MD5 Java en SUSE Linux Enterprise Server 11 SP4, prepare el sistema tal como se describe en las siguientes secciones.

3.5.2 Migración de la base de datos de PostgreSQL #

 

Con SUSE Linux Enterprise Server 15 SP2 se incluye una versión más reciente de la base de datos de PostgreSQL. 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 y en /usr/lib/postgresql10/ para la versión 10. 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 tal 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 9.6 a la 10. 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:

1. Asegúrese de que se cumplen las siguientes condiciones previas:

   • Si aún no lo ha hecho, actualice todos los paquetes de la versión anterior de PostgreSQL a la más reciente mediante una actualización de mantenimiento.

   • Cree una copia de seguridad de la base de datos existente.

   • Instale los paquetes de la nueva versión principal de PostgreSQL. En el caso de SLE15 SP2, esto significa instalar postgresql10-server y todos los paquetes de los que depende.

   • Instale el paquete postgresql10-contrib que contiene el comando pg_upgrade.

   • Asegúrese de que dispone de suficiente espacio libre en el área de datos de PostgreSQL, que por defecto es /var/lib/pgsql/data. Si hay poco espacio, intente reducir el tamaño con los comandos siguientes de SQL en cada base de datos (esta operación puede tardar mucho tiempo):

     VACUUM FULL

2. Detenga el servidor de PostgreSQL con:

   root # /usr/sbin/rcpostgresql stop

   O bien

   root # systemctl stop postgresql.service

   (según la versión de SLE que utilice como versión de inicio para la actualización).

3. Renombre el directorio de datos anterior:

   root # mv /var/lib/pgsql/data /var/lib/pgsql/data.old

4. Inicialice la nueva instancia de la base de datos manualmente con initdb o iniciando y deteniendo PostgreSQL, con lo que el proceso se realizará automáticamente:

   root # /usr/sbin/rcpostgresql start
   root # /usr/sbin/rcpostgresql stop

   O bien

   root # systemctl start postgresql.service
   root # systemctl stop postgresql.service

   (según la versión de SLE que utilice como versión de inicio para la actualización).

5. Si ha cambiado los archivos de configuración en la versión anterior, plantéese la posibilidad de transferir esos cambios a los nuevos archivos de configuración. Esto puede afectar a los archivos postgresql.auto.conf, postgresql.conf, pg_hba.conf y pg_ident.conf. Las versiones anteriores de estos archivos se encuentra en /var/lib/pgsql/data.old/ y las versiones nuevas en /var/lib/pgsql/data.

   Tenga en cuenta que no se recomienda copiar simplemente los archivos de configuración antiguos, ya que se podrían sobrescribir las opciones nuevas, los valores por defecto nuevos y los comentarios que se hayan modificado.

6. Inicie el proceso de migración como el usuario postgres:

   root # su - postgres
   postgres > pg_upgrade \
     --old-datadir "/var/lib/pgsql/data.old" \
     --new-datadir "/var/lib/pgsql/data" \
     --old-bindir "/usr/lib/postgresql96/bin/" \
     --new-bindir "/usr/lib/postgresql10/bin/"

7. Inicie la nueva instancia de base de datos con:

   root # /usr/sbin/rcpostgresql start

   O bien

   root # systemctl start postgresql.service

   (según la versión de SLE que utilice como versión de inicio para la actualización).

8. Compruebe si la migración se ha realizado correctamente. El ámbito de la prueba depende del uso que haga y no existe ninguna herramienta general para automatizar este paso.

9. Elimine todos los paquetes anteriores de PostgreSQL y el directorio de datos antiguo:

   root # zypper search -s postgresql96 | xargs zypper rm -u
   root # rm -rf /var/lib/pgsql/data.old

Si el equipo hace de Host VM Server para KVM o Xen, asegúrese de apagar correctamente cualquier Guest VM 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 declientSetup4SMT.shen<nombre_del_host_de_SMT>/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.

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

Un servidor que ejecuta SMT requiere un procedimiento de actualización especial. Consulte el Book “Repository Mirroring Tool Guide”, Chapter 2 “Migrate from SMT to RMT” en la Guía de la Herramienta de gestió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 “Guía de distribución”, Chapter 21 “Instalación de varias versiones del núcleo”, Section 21.1 “Habilitación y configuración de la compatibilidad multiversión”.

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 Sección 5.4, “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, YaST muestra un mensaje emergente que sugiere utilizar un segundo medio de instalación, la imagen SLE-15-SP2-Full-ARQUITECTURA-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 del registro 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 las comprobaciones posteriores a la actualización descritas en la Sección 4.4.1, “Comprobaciones posteriores a 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.10 “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.

Con SUSE Manager, puede realizar una actualización del sistema. Con la tecnología integrada de AutoYaST, es posible actualizar desde 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 migración del cliente se describe en la Guía de actualización de SUSE Manager, 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 ha fallado, 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:

tux > 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:

tux > 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: Capítulo 1, 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: 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 la migración de zypper. Utilice en su lugar el procedimiento de migración de cliente. Se describe en la Guía de actualización de SUSE Manager.

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 para una sola llamada, añada el parámetro --no-recommends en la línea de comandos.

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 para una sola llamada, añada el parámetro --no-recommends en la línea de comandos.

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 la migración de zypper. 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 se proporcionen los orígenes de instalación para el nuevo paquete de servicio en una ubicación a la que pueda acceder el equipo que va a migrar. Puede hacerlo, por ejemplo, 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). Para obtener más información, consulte: Book “Administration Guide”, Chapter 7 “System Recovery and Snapshot Management with Snapper”.

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 SP1).

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 migración del cliente se describe en la Guía de actualización de SUSE Manager, disponible en https://documentation.suse.com/suma/.

Puede actualizar una instalación de openSUSE en línea a SUSE Linux Enterprise Server. El procedimiento es similar al descrito en la Sección 5.5, “Actualización con Zypper”, pero se requieren algunos pasos adicionales. Antes de ejecutar este procedimiento en el sistema de producción, se recomienda ejecutarlo en un sistema de prueba en el que se replique la configuración de producción.

Para ver qué versiones de openSUSE Leap admiten la migración, lea la Sección 1.1, “Vías de actualización a SLE 15 SP2 admitidas”.

Aviso: no todos los paquetes de openSUSE se pueden migrar

Los repositorios de openSUSE proporcionan más paquetes que los disponibles en los repositorios de SUSE Linux Enterprise Server. Si tiene alguno de estos paquetes instalado, dejará de recibir actualizaciones después de la migración. Estos paquetes se eliminarán si lleva a cabo el procedimiento descrito a continuación.

Asegúrese de que todos los paquetes que necesita para que funcione el sistema están disponibles en el repositorio SUSE Linux Enterprise Server. También puede comprobar si los paquetes están disponibles en el repositorio SUSE Package Hub. Para obtener información, consulte: Book “Guía de distribución”, Chapter 20 “Instalación de módulos, extensiones y productos adicionales de otros fabricantes”, Section 20.3 “SUSE Package Hub”.

Para migrar desde openSUSE Leap, ejecute el siguiente procedimiento:

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.

Hay varias ubicaciones en las que se almacena la información relacionada con las funciones y soluciones de errores: