SUSE® Linux Enterprise (SLE) permite actualizar un sistema existente a la nueva versión, por ejemplo, de SLE 11 SP4 a SLE 12. No es preciso realizar una nueva instalación. Los datos que ya existan, como los directorios personales y la configuración del sistema, permanecen intactos. La actualización se puede realizar desde una unidad local de CD o DVD o desde un origen de instalación de red.
En este capítulo se explica cómo actualizar manualmente el sistema SUSE Linux Enterprise, ya sea mediante un DVD, la red, un proceso automatizado o SUSE Manager.
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 12 SP2 en POWER (nuevo: ¡little endian!), no se admite.
Además, como SUSE Linux Enterprise 12 es solo de 64 bits, las actualizaciones de cualquier sistema de 32 bits de SUSE Linux Enterprise 11 a SUSE Linux Enterprise 12 no se admiten.
Si desea realizar una actualización entre arquitecturas, necesitará realizar una instalación nueva.
Antes de realizar cualquier migración, consulte la Sección 18.3, “Preparación del sistema”.
La vía de actualización más segura es instalar de forma consecutiva todos los paquetes de servicio. En algunos casos, se admite la omisión de uno o dos paquetes de servicios durante la actualización. Sin embargo, se recomienda no omitir ninguno de ellos.
Se recomienda realizar una instalación nueva al actualizar a una nueva versión principal; por ejemplo, de SUSE Linux Enterprise 11 a SUSE Linux Enterprise 12.
No se admite ninguna vía de migración directa a SUSE Linux Enterprise 12. En este caso, se recomienda realizar una instalación nueva.
No se admite ninguna vía de migración directa a SUSE Linux Enterprise 12. Debe tener instalado al menos SLE 11 SP4 para poder continuar a SLE 12 SP3.
Si no es posible realizar una instalación nueva, actualice primero el paquete de servicios de SLE 11 instalado a SLE 11 SP4. Estos pasos se describen en la Guía de distribución de SUSE Linux Enterprise 11.
A continuación, siga con la Sección 18.2, “Actualización con conexión y sin conexión”.
La actualización de SLE 11 a SLE 12 SP3 solo se admite a través de una actualización sin conexión. Consulte la Sección 18.2, “Actualización con conexión y sin conexión” para obtener más detalles.
No se admite la actualización directa de SLE 12 GA a SP3. Actualice primero a SLE 12 SP2.
Se admite la actualización desde SUSE Linux Enterprise 12 SP1 o SP2 a SP3
Se admite la actualización de cualquier versión anterior de SLE 12 LTSS a SP3.
SUSE admite dos métodos de actualización y migración. Para obtener más información acerca de la terminología, consulte la Sección 17.1, “Terminología”. Los métodos son los siguientes:
Se considera que todas las actualizaciones que se ejecutan desde el sistema en ejecución son actualizaciones con conexión. Ejemplos: se ha conectado a través del Centro de servicios al cliente de SUSE, la Herramienta de gestión de suscripciones (SMT), SUSE Manager con YaST o zypper.
Al migrar de un paquete de servicios a otro de la misma versión principal, se recomienda seguir la Sección 20.4, “Actualización con la herramienta de migración en línea (YaST)” o la Sección 20.5, “Actualización con Zypper”.
En los métodos sin conexión, normalmente se arranca otro sistema operativo desde el que se actualiza la versión instalada de SLE. Algunos ejemplos son: DVD, unidades USB, imágenes ISO, AutoYaST, “RPM normal” o el arranque PXE.
La actualización de SUSE Linux Enterprise 11 SP4 a SUSE Linux Enterprise 12 SP3 solo se admite mediante una actualización sin conexión. Consulte el Capítulo 19, Actualización sin conexión
La actualización desde cualquier versión de SUSE Linux Enterprise 12 LTSS o SUSE Linux Enterprise 12 SP1 o SP2 a SP3 se admite con cualquier método con conexión y sin conexión. Consulte el Capítulo 19, Actualización sin conexión y el Capítulo 20, Actualización con conexió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.
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:
si el hardware necesita consideraciones especiales,
si los paquetes de software usados han cambiado de forma significativa,
si es necesario tomar precauciones especiales para la instalación.
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.
Encontrará las notas de la versión en el directorio /usr/share/doc/release-notes
o en línea en https://www.suse.com/releasenotes/.
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 /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 disponer de 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
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.bakroot #
zypper
install $(cat installed-software.bak)
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:
Entre a la sesión en el equipo con SUSE Linux Enterprise 11.
Cree un archivo de volcado de memoria:
root #
mysqldump
-u root -p --all-databases > 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://dev.mysql.com/doc/refman/5.5/en/mysqldump.html.
Guarde el archivo de volcado de memoria, el archivo de configuración /etc/my.cnf
y el directorio /etc/mysql/
para su investigación posterior (NO para la instalación) en un lugar seguro.
Realice la actualización. 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:
root #
systemctl
start mysql
Si desea iniciar el servidor de MariaDB cada vez que arranque, habilite el servicio:
root #
systemctl
enable mysql
Conéctese a la base de datos para verificar que MariaDB se está ejecutando correctamente:
root #
mysql
-u root -p
En SLE11 SP3 y SLE12 GA hay una nueva versión de la base de datos PostgreSQL como actualización de mantenimiento. 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.
En cada versión de PostgreSQL, los archivos se almacenan de forma distinta en directorios que varían según la versión. Después de actualizar, los directorios cambiarán a:
/usr/lib/postgresql91/
a /usr/lib/postgresql94/
/usr/lib/postgresql93/
a /usr/lib/postgresql94/
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. En el caso de SLE12, esto significa instalar postgresql94-server y todos los paquetes de los que depende.
Instale el paquete
postgresql94-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:
root #
/usr/sbin/rcpostgresql
stop
Renombre el directorio de datos anterior:
root #
mv
/var/lib/pgsql/data /var/lib/pgsql/data.old
Cree un directorio de datos nuevo:
root #
mkdir
-p /var/lib/pgsql/data
Si ha cambiado los archivos de configuración en la versión anterior, copie los archivos postgresql.conf
pg_hba.conf
al nuevo directorio data
:
root #
cp
/var/lib/pgsql/data.old/*.conf \ /var/lib/pgsql/data
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
startroot #
/usr/sbin/rcpostgresql
stop
Inicie el proceso de migración y sustituya el espacio reservado OLD con la versión anterior:
root #
pg_upgrade
\ --old-datadir "/var/lib/pgsql/data.old" \ --new-datadir "/var/lib/pgsql/data" \ --old-bindir "/usr/lib/postgresqlOLD/bin/" \ --new-bindir "/usr/lib/postgresql94/bin/"
Inicie la nueva instancia de la base de datos:
root #
/usr/sbin/rcpostgresql
start
Compruebe si la migración se ha realizado correctamente. No existe ninguna herramienta general para automatizar este paso. La extensión de las pruebas y los elementos que se someterán a ellas dependerán de su situación de uso concreto.
Elimine todos los paquetes anteriores de PostgreSQL y el directorio de datos antiguo:
root #
zypper
search -s postgresqlOLD | xargs zypper rm -uroot #
rm
-rf /var/lib/pgsql/data.old
Durante la actualización de SP1 a SP2, se han inhabilitado basada en MD5 certificados como parte de una solución de seguridad. Si dispone de certificados que se crea como MD5, vuelva a crear los certificados con los siguientes pasos:
Abra un terminal y entre como usuario root
.
Cree una clave privada:
root #
openssl
genrsa -out server.key 1024
Si desea que un intercambio de clave, más seguro1024
con un número más elevado, por ejemplo,4096
.
Cree una petición de firma de certificado (CSR):
root #
openssl
req -new -key server.key -out server.csr
Autofirmar el certificado:
root #
openssl
x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
Cree el archivo PEM:
root #
cat
server.key server.crt > server.pem
Coloque los archivosServer.CRT
,Server.CSR
,Server.Key
, yServer.PEM
en los directorios respectivos las claves que puede que encuentran. Para Tomcat, por ejemplo, este directorio es/ etc/tomcat/ssl /
.
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.
clientSetup4SMT.sh
guión en los clientes SMT #
Si va a migrar el sistema operativo que está registrado un servidor SMT del cliente, tiene que comprobar si la versión de laclientSetup4SMT.sh
guión en el host está actualizado. clientSetup4SMT.sh
de versiones anteriores de SMT no pueden gestionar a 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.sh
en< SMT_HOSTNAME>/repo/tools/clientSetup4SMT.sh
.
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.
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.
Utilice el comando df
para mostrar el espacio disponible en disco. Por ejemplo, en Ejemplo 18.1, “Lista que se obtiene con df -h
”, la partición raíz es /dev/sda3
(montada como /
).
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
Si usa Btrfs como sistema de archivos raíz en su equipo, asegúrese de que hay suficiente espacio libre. 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. Para mostrar el disco de espacio disponible, use este comando:
root #
df
-h /
Compruebe también el espacio disponible en todas las demás particiones montadas. 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 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
:
root #
snapper
listroot #
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.
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 la Sección 14.1, “Habilitación y configuración de la compatibilidad multiversión”.
Para actualizar una instalación de SUSE Linux Enterprise en z Systems es necesario introducir el parámetro del núcleo Upgrade=1
, por ejemplo mediante un parmfile. Consulte la Sección 4.3, “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"