Se aplica a SUSE Linux Enterprise Server 15 SP5

3 Preparación de la actualización #

Antes de iniciar el procedimiento de actualización, asegúrese de que el sistema está debidamente preparado. Entre otros aspectos, los preparativos requieren realizar una copia de seguridad de los datos y comprobar las notas de la versión. El siguiente capítulo le guiará a través de estos pasos.

3.1 Comprobación de que el sistema está actualizado #

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.

3.2 Lectura de las notas de la versión #

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:

Si el hardware necesita consideraciones especiales
Si los paquetes de software usados han cambiado de forma significativa
Si la instalación requiere precauciones especiales

3.3 Creación de una copia de seguridad #

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.

3.4 Comprobación del espacio disponible en disco #

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.

3.4.1 Comprobación de espacio en disco en sistemas de archivos que no sean Btrfs #

Utilice el comando df para mostrar el espacio disponible en disco. Por ejemplo, en Ejemplo 3.1, “Lista con df -h”, la partición raíz es /dev/sda3 (montada como /).

Ejemplo 3.1: Lista con df -h #

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

3.4.2 Comprobación de espacio en disco en sistemas de archivos raíz Btrfs #

En un sistema de archivos Btrfs, el resultado de df puede inducir a error, ya que, además del espacio que asignan los datos en bruto, el sistema también asigna y utiliza espacio para los metadatos

Por lo tanto, un sistema de archivos Btrfs podría informar de que no queda espacio aunque parezca que aún hay mucho disponible. En tal caso, se utiliza todo el espacio asignado para los metadatos. Para obtener información detallada sobre cómo comprobar el espacio utilizado y disponible en un sistema de archivos Btrfs, consulte Section 1.2.2.3, “Checking for free space”. Para obtener más información, consulte la página man 8 btrfs-filesystem y https://btrfs.wiki.kernel.org/index.php/FAQ.

Si usa Btrfs como sistema de archivos raíz en su equipo, asegúrese de que hay suficiente espacio libre. Compruebe el espacio disponible en todas las particiones montadas. En el peor de los casos, una actualización necesitará tanto espacio en disco como el que ocupa el sistema de archivos raíz actual (sin /.snapshot) para realizar una instantánea nueva.

Se ha comprobado que las recomendaciones siguientes funcionan:

Para todos los sistemas de archivos, incluido Btrfs, se necesita espacio libre suficiente en el disco para descargar e instalar RPM de gran tamaño. El espacio de los RPM antiguos solo se libera después de que se instalen los RPM nuevos.
En el caso de los Btrfs con instantáneas, se necesita como mínimo el mismo espacio libre que el que ocupa la instalación actual. Se recomienda disponer del doble de espacio libre que el que ocupa la instalación actual.
Si no tiene espacio libre suficiente, puede intentar suprimir instantáneas antiguas con snapper:
```
# snapper list
      # snapper delete NUMBER
```
Sin embargo, esto podría no ser de ayuda en todos los casos. Antes de la migración, la mayoría de las instantáneas ocupan poco espacio.

3.5 Lista de los paquetes y repositorios instalados #

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.

Cree un archivo denominado repositories.bak.repo que contenga una lista de todos los repositorios utilizados:
```
# zypper lr -e repositories.bak
```
Cree también un archivo denominado installed-software.bak que contenga una lista de todos los paquetes instalados:
```
# 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:
```
# zypper ar repositories.bak.repo
# 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 ,37 paquetes 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 que en 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.

3.6 Inhabilitación de la extensión LTSS #

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.

Compruebe si la extensión LTSS está habilitada:

> sudo SUSEConnect --list-extensions | grep LTSS
SUSE Linux Enterprise Server LTSS 12 SP4 x86_64 (Installed)
Deactivate with: SUSEConnect -d -p SLES-LTSS/12.4/x86_64

Inhabilite la extensión LTSS con el comando resultante de SUSEConnect anterior:

> sudo SUSEConnect -d -p SLES-LTSS/12.4/x86_64
Deregistered SUSE Linux Enterprise Server LTSS 12 SP4 x86_64
To server: https://scc.suse.com/

Verifique que el repositorio LTSS ya no está presente con zypper lr.

3.7 Migración de la base de datos PostgreSQL #

SUSE Linux Enterprise Server 15 SP5 incluye las versiones 13 y 14 de la base de datos PostgreSQL. Aunque la versión 14 es la versión por defecto, la versión 13 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:

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 Para SLE 15 SP5, esto significa instalar postgresql13-server y todos los paquetes de los que depende.
- Instale el paquete postgresql13-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
```
Detenga el servidor de PostgreSQL con:
```
# /usr/sbin/rcpostgresql stop
```
o bien
```
# systemctl stop postgresql.service
```
(según la versión de SLE que utilice como versión de inicio para la actualización).

Renombre el directorio de datos anterior:

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

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:
```
# /usr/sbin/rcpostgresql start
# /usr/sbin/rcpostgresql stop
```
o bien
```
# systemctl start postgresql.service
# systemctl stop postgresql.service
```
(según la versión de SLE que utilice como versión de inicio para la actualización).
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 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.

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

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

Inicie la nueva instancia de base de datos con:
```
# /usr/sbin/rcpostgresql start
```
o bien
```
# systemctl start postgresql.service
```
(según la versión de SLE que utilice como versión de inicio para la actualización).
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.

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

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

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.

3.8 Migración de la base de datos MySQL o MariaDB #

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:

Cree un archivo de volcado de memoria:
```
# mysqldump -u root -p --all-databases --add-drop-database > mysql_backup.sql
```
Por defecto, mysqldump no realiza el volcado de INFORMATION_SCHEMA ni de la base de datos performance_schema. Para obtener más información, consulte https://mariadb.com/kb/en/mariadb-dumpmysqldump/.
Guarde el archivo de volcado de memoria, el archivo de configuración /etc/my.cnf y el directorio /etc/mysql/ para investigarlos posteriormente (no para instalarlos) en un lugar seguro.
Realice la actualización de SUSE Linux Enterprise Server. Después de la actualización, el archivo de configuración anterior /etc/my.cnf seguirá intacto. Encontrará la nueva configuración en el archivo /etc/my.cnf.rpmnew.
Configure la base de datos MariaDB según sus necesidades. No use el archivo de configuración ni el directorio anterior, en su lugar, empléelos como recordatorios y adáptelos.
Asegúrese de iniciar el servidor de MariaDB:
```
# systemctl start mariadb
```
Si desea iniciar el servidor de MariaDB cada vez que arranque, habilite el servicio:
```
# systemctl enable mariadb
```
Conéctese a la base de datos para verificar que MariaDB se está ejecutando correctamente:
```
# mariadb -u root -p
```

3.9 Creación de certificados de servidor no MD5 para aplicaciones de Java #

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:

Abra un terminal y entre como usuario root.
Cree una clave privada:
```
# openssl genrsa -out server.key 1024
```
Si desea una clave más sólida, sustituya 1024 por un número más elevado, por ejemplo, 4096.

Cree una petición de firma de certificado (CSR):

# openssl req -new -key server.key -out server.csr

Autofirme el certificado:

# openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

Cree el archivo PEM:

# cat server.key server.crt > server.pem

Coloque los archivos server.crt, server.csr, server.key y server.pem en los directorios respectivos donde se encuentran las claves. Para Tomcat, por ejemplo, este directorio es /etc/tomcat/ssl/.

3.10 Apagado de máquinas virtuales de invitado #

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.

3.11 Ajuste de la configuración del cliente SMT #

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.

Procedimiento 3.1: Anulación de un cliente de SUSE Linux Enterprise desde un servidor SMT #

Entre en el equipo cliente.

El paso siguiente depende del sistema operativo del cliente:

Para SUSE Linux Enterprise 11, ejecute los comandos siguientes:

> sudo suse_register -E
> sudo rm -f /etc/SUSEConnect
> sudo rm -rf /etc/zypp/credentials.d/*
> sudo rm -rf /etc/zypp/repos.d/*
> sudo rm -f /etc/zypp/services.d/*
> sudo rm -f /var/cache/SuseRegister/*
> sudo rm -f /etc/suseRegister*
> sudo rm -f /var/cache/SuseRegister/lastzmdconfig.cache
> sudo rm -f /etc/zmd/deviceid
> sudo rm -f /etc/zmd/secret

Para SUSE Linux Enterprise 12, ejecute los comandos siguientes:

> sudo SUSEConnect --de-register
> sudo SUSEConnect --cleanup
> sudo rm -f /etc/SUSEConnect
> sudo rm -rf /etc/zypp/credentials.d/*
> sudo rm -rf /etc/zypp/repos.d/*
> sudo rm -f /etc/zypp/services.d/*

Entre en el servidor SMT.
Compruebe si se ha anulado correctamente el registro del cliente mostrando todos los registros del cliente:
```
> sudo smt-list-registrations
```
Si el nombre de host del cliente sigue apareciendo con este comando, anote el Unique ID del cliente de la primera columna (puede que el cliente aparezca con varios ID).

Suprima el registro de ese cliente:

> sudo smt-delete-registration -g UNIQUE_ID

Si el cliente se muestra con varios ID, repita el paso anterior para cada uno de sus ID exclusivos.
Compruebe si ya se ha anulado correctamente el registro del cliente volviendo a ejecutar:
```
> sudo smt-list-registrations
```

3.12 Cambios en los perfiles de AutoYaST de SLE 12 a 15 #

Para obtener información sobre cómo migrar los perfiles de AutoYaST, consulte Appendix D, Differences between AutoYaST profiles in SLE 12 and 15.

3.13 Actualización de un servidor de la Herramienta de gestión de suscripciones (SMT) #

Un servidor que ejecuta SMT requiere un procedimiento de actualización especial. Consulte Chapter 3, Migrate from SMT to RMT en Repository Mirroring Tool Guide.

3.14 Inhabilitación temporal de la compatibilidad multiversión del núcleo #

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 Section 27.1, “Enabling and configuring multiversion support”.

3.15 Actualización en IBM Z #

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.5, “Archivo parmfile: automatización de la configuración del sistema”.

3.16 IBM POWER: inicio de un X Server #

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"