Saltar a contenidoSaltar a navegación de páginas: página anterior [tecla acceso p]/página siguiente [tecla acceso n]
Se aplica a SUSE Linux Enterprise Server 11 SP4

7 Actualización de SUSE Linux Enterprise

SUSE® Linux Enterprise (SLE) proporciona la posibilidad de actualizar un sistema existente a la nueva versión sin realizar una reinstalación completa. 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. Durante el ciclo de vida del producto, puede aplicar paquetes de servicios para mejorar la seguridad del sistema, corregir defectos de software y acceder a nuevas funciones. La instalación se puede realizar desde una unidad local de CD o DVD o desde un origen de instalación de red.

7.1 Terminología

Esta capítulo utiliza varios términos especializados. Para comprender la información, lea las siguientes definiciones:

Backport

El proceso de backport significa adaptar cambios específicos de una versión reciente del software y aplicarlos a una versión anterior. El caso más habitual es reparar problemas de seguridad en componentes de software con cierta antigüedad. Normalmente, forma parte de un modelo de mantenimiento que consiste en ofrecer mejoras o (con menor frecuencia) nuevas funciones.

Deltarpm

Un paquete deltarpm está compuesto únicamente por los archivos binarios que no tienen en común dos versiones definidas de un mismo paquete, por lo que presenta el tamaño de descarga más pequeño. Antes de la instalación, el paquete RPM completo se reconstruye en el equipo local.

Sentido descendente

Una metáfora del modo en que se desarrolla el software en el mundo del código abierto (consulte también "sentido ascendente"). El término "sentido descendente" hace referencia a personas u organizaciones como SUSE, que integran el código que "viene de arriba" con otros productos de software para crear distribuciones que luego emplean los usuarios finales. Así, el software fluye en "sentido descendente" desde sus desarrolladores hasta los usuarios finales, pasando por los integradores.

Migración en línea

Actualización a un paquete de servicios o Service Pack (SP) mediante las herramientas de actualización en línea (en vez de los medios de instalación) para instalar los parches correspondientes. Actualiza todos los paquetes de los sistemas instalados a la última versión (actualizaciones incluidas) de actualizaciones SP3 más SP2.

Paquete

Un paquete es un archivo comprimido en formato rpm que contiene todos los archivos de un programa en concreto, incluidos componentes opcionales como configuraciones, ejemplos y documentación.

Parche

Un parche consiste en uno o más paquetes y puede aplicarse mediante deltarpms. También puede introducir dependencias de paquetes que aún no estén instalados.

Paquetes de servicios (Service Packs)

Combina varios parches en un formato que es fácil de instalar o distribuir. Los paquetes de servicios están numerados y suelen incluir soluciones de seguridad, actualizaciones o mejoras de programas.

Sentido ascendente

Una metáfora del modo en que se desarrolla el software en el mundo del código abierto (consulte también "sentido descendente"). El término "sentido ascendente" hace referencia al proyecto original o al autor o persona que mantiene un software distribuido como código fuente. Los comentarios, los parches, las mejoras de funciones u otras mejoras fluyen desde los usuarios finales o colaboradores hasta los desarrolladores en "sentido ascendente". Los desarrolladores deciden si las peticiones deben integrarse o rechazarse.

Si los miembros del proyecto deciden integrar una petición, se incluirá en las versiones más recientes del software. Las peticiones aceptadas benefician a todas las partes implicadas.

Si una petición no se acepta, puede deberse a diferentes motivos. Puede que incumpla las directrices del proyecto, que no sea válido, que ya esté integrado o que no sea de interés o se desvíe del plan de ruta del proyecto. Una petición no aceptada dificulta el trabajo de los desarrolladores en sentido ascendente, ya que tienen que mantener sus parches sincronizados con el código en sentido ascendente. Esta práctica suele evitarse, pero a veces es necesario emplearla.

Actualización

Instalación de una nueva versión menor de un paquete.

Actualización (upgrade)

Instalación de una nueva versión importante de un paquete o una distribución que incorpora nuevas funciones.

7.2 Modelo de mantenimiento de SUSE Linux Enterprise 11

El modelo de mantenimiento de SUSE Linux Enterprise 11 combina flexibilidad y control de los paquetes de servicios. Ofrece las siguientes ventajas:

  • Los paquetes de servicios son más ligeros y fáciles de probar y distribuir.

  • Es posible conservar las versiones anteriores, pero con compatibilidad para el sistema completo.

  • Se ofrece una respuesta a las necesidades del mercado entre paquetes de servicios, mediante mejoras selectivas y la posibilidad de ofrecer más actualizaciones en el repositorio general. Al seleccionar las mejoras se reducen los períodos prolongados entre los sucesivos paquetes de servicios.

7.2.1 Información básica

En los últimos años, con un claro deseo de mejora basado en los comentarios de los clientes, SUSE ha implementado diversos cambios en relación con el modo en que proporcionamos actualizaciones a nuestros usuarios:

  • En SLES 9, tan solo existía un repositorio de actualizaciones que las reunía todas. La versión más reciente era la única que se ofrecía.

  • A partir de SLES 10 SP1, se introdujo el concepto de un repositorio específico para cada SP. Esto significa que todas las actualizaciones de un Service Pack concreto se entregan desde un repositorio específico. Cuando los usuarios migran a un Service Pack más reciente, pierden acceso a los repositorios anteriores si se han registrado directamente en el Centro de servicios al cliente de Novell. Como es habitual, los usuarios de SMT o SUSE Manager pueden suscribirse libremente a cualquier canal de Service Pack. El motivo principal de este cambio es el concepto de periodo de solapamiento de 6 meses (asistencia para el Service Pack n-1), a fin de permitir la validación del Service Pack publicado y ofrecer una ventana de migración para los clientes, durante la cual pueden seguir disfrutando de asistencia y mantenimiento total para el SP anterior.

  • SLES 11 GA y SLES 11 SP1 siguieron el modelo de SLES 10. Con SLES 11 SP2, incorporamos un nuevo modelo de repositorios basado en lo siguiente:

    1. Se mantienen las suscripciones del repositorio de actualizaciones de SLES 11 SP1. Todas las actualizaciones aplicables también al SP2 se publicaban además o en exclusiva en el repositorio de actualizaciones del SP1. Esto significa que todas las actualizaciones que no afectaran a la compatibilidad ABI y API se seguían entregando desde allí.

    2. El repositorio de actualizaciones de SLES 11 SP2 solo incluye las actualizaciones más recientes e innovadoras que no se pueden aplicar desde el repositorio de actualizaciones del SP1 (por diversos motivos). Además, hemos añadido un repositorio central que proporciona un hueco para los paquetes que no se han publicado en los repositorios de actualizaciones del SP1 ni el SP2.

    3. SLES 11 SP4 contará con un modelo de canal similar al de SLES 10. El modelo se consideró la forma más fácil y rápida de enviar actualizaciones para un paquete de servicios específico. Todas las actualizaciones se enviarán a través de un canal de actualización especial. Habrá disponibles canales adicionales en la máquina, pero los canales antiguos se eliminarán.

La Figura 7.1, “Evolución de la entrega de mantenimiento (también aplicable a SLED)” muestra algunos de los aspectos mencionados.

Evolución de la entrega de mantenimiento (también aplicable a SLED)
Figura 7.1: Evolución de la entrega de mantenimiento (también aplicable a SLED)

Nuestros productos tienen un ciclo de vida de 10 años: 10 años de asistencia general y 3 años de asistencia extendida. Publicamos versiones principales cada 4 años y paquetes de servicios cada 18 meses. La asistencia de paquetes de servicios a largo plazo (Long Term Service Pack Support o LTSS) es un plazo extendido o una ampliación del ciclo de vida de las versiones principales Figura 7.2, “Asistencia de paquetes de servicios a largo plazo (Long Term Service Pack Support, LTSS)”).

Asistencia de paquetes de servicios a largo plazo (Long Term Service Pack Support, LTSS)
Figura 7.2: Asistencia de paquetes de servicios a largo plazo (Long Term Service Pack Support, LTSS)

LTSS requiere una suscripción activa, ya sea normal o prioritaria. No afecta a los plazos de suscripción L1 y L2. Las actualizaciones de seguridad se gestionan de forma proactiva: se trata de vulnerabilidades críticas que no dependen del usuario, vulnerabilidades locales en el núcleo u otras vulnerabilidades del sistema raíz ejecutables directamente sin interacción del usuario.

7.2.2 Niveles de asistencia

El intervalo de los niveles de asistencia extendidos empieza el octavo año y termina el décimo. Implica un diagnóstico continuado de nivel de ingeniería L3 y reacciones para solucionar errores críticos. Estos niveles de asistencia técnica actualizan de forma proactiva las vulnerabilidades del sistema raíz en el núcleo y cualquier otra vulnerabilidad ejecutable directamente sin 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 7.1, “Actualizaciones de seguridad y correcciones de errores”.

Tabla 7.1: Actualizaciones de seguridad y correcciones de errores
 

—Asistencia general—

Asistencia técnica ampliada

Tema

SP actual

SP (n-1) 6 meses

SP (n-1) con LTSS

Años 6 y 7 con LTSS

Años 8, 9 y 10 con LTSS

Servicios técnicos L1/L2

Mantenimiento proactivo

 

 

Actualizaciones de controladores mediante PLDP

  

Actualizaciones de seguridad proactivas

 

Compatibilidad con ingeniería L3

Versiones anteriores disponibles

 

7.2.3 Modelo de canales

Con el modelo de mantenimiento anterior, SUSE Linux Enterprise Server tenía dos canales asignados: SLES11-SPx-Pool y SLES11-SPx-Updates. Durante una migración en línea a SPx+1, estos canales se reemplazaron temporalmente por SLES11-SPx-Online.

Con SUSE Linux Enterprise SP 2, la disposición de los canales ha cambiado para ofrecer las ventajas del nuevo modelo de mantenimiento. Tabla 7.2, “Disposición de canales para SUSE Linux Enterprise 11 SP1, SP2 y SP3” incluye una lista de todos los canales desde el SP1 hasta el SP3.

Tabla 7.2: Disposición de canales para SUSE Linux Enterprise 11 SP1, SP2 y SP3

Tipo

SLES

SLED

Canales obligatorios

SP1

SLES11-SP1-Pool
SLES11-SP1-Updates

SP2

SLES11-SP1-Pool
SLES11-SP1-Updates
SLES11-SP2-Core
SLES11-SP2-Updates

SP3

SLES11-SP3-Pool
SLES11-SP3-Updates

SP4

SLES11-SP4-Pool
SLES11-SP4-Updates

SP1

SLED11-SP1-Pool
SLED11-SP1-Updates

SP2

SLED11-SP1-Pool
SLED11-SP1-Updates
SLED11-SP2-Core
SLED11-SP2-Updates

SP3

SLED11-SP3-Pool
SLED11-SP3-Updates

SP4

SLED11-SP4-Pool
SLED11-SP4-Updates

Canales opcionales

SP1

SLES11-SP1-Debuginfo-Pool
SLES11-SP1-Debuginfo-Updates

SP2

SLES11-SP2-Debuginfo-Core
SLES11-SP2-Debuginfo-Updates
SLES11-Extras
SLES11-SP2-Extension-Store

SP3

SLES11-SP3-Debuginfo-Core
SLES11-SP3-Debuginfo-Updates
SLES11-SP3-Extension-Store
SLES11-Extra

SP4

SLES11-SP4-Debuginfo-Pool
SLES11-SP4-Debuginfo-Updates
SLES11-Extra
SLES11-Security-Module

SP1

SLED11-SP1-Debuginfo-Pool
SLED11-SP1-Debuginfo-Updates

SP2

SLED11-SP2-Debuginfo-Core
SLED11-SP2-Debuginfo-Updates
SLED11-Extras
SLED11-SP2-Extension-Store

SP3

SLED11-SP3-Debuginfo-Core
SLED11-SP3-Debuginfo-Updates
SLED11-SP3-Extension-Store
SLED11-Extra

SP4

SLED11-SP4-Debuginfo-Pool
SLED11-SP4-Debuginfo-Updates

Específicos de productos (ejemplos)

SLES11-WebYaST-SP2-Pool
SLES11-WebYaST-SP2-Updates
SLED11-MSI-Updates
Descripción de canales obligatorios
Core (núcleo)

Un subconjunto de los medios de instalación descomprimidos. Solo contiene los paquetes que se consideran el núcleo del SPx (aproximadamente un 30% del total de paquetes). Los repositorios de SP solo contienen los paquetes específicos de un SP y sus temas (por ejemplo, compatibilidad de hardware). Solo existe en el SP2.

Actualizaciones

Actualizaciones de mantenimiento de los paquetes del repositorio Core o Pool correspondiente.

Repositorio

Contiene todos los RPM binarios de los medios de instalación, además de información de patrones y metadatos de estado de compatibilidad.

Descripción de canales opcionales
Debuginfo-Pool, Debuginfo-Updates

Estos canales tienen contenido estático. Sin embargo, solo el canal Debuginfo-Updates recibe actualizaciones. Habilite estos canales si tiene que instalar bibliotecas con información de depuración en caso de que se produzcan problemas.

Extension-Store

De momento, no se utiliza. La idea es que contenga paquetes para (futuros) productos complementarios. El canal de almacén de extensiones se eliminará a partir de SLES 11 SP4.

LTSS-Updates

Actualizaciones de mantenimiento para paquetes del repositorio Pool correspondiente para instalaciones con servicio de asistencia a largo plazo (LTSS). Este canal específico requiere un contrato LTSS.

7.2.3.1 Origen de paquetes

SUSE Linux Enterprise 11 SP3/SP4. Con la instalación de SP3, solo hay dos canales disponibles: SLES11-SP3-Pool y SLES11-SP3-Updates. Los canales anteriores del SP2 son visibles, pero no están habilitados. Los canales inhabilitados solo resultarán útiles para usuarios con unas necesidades muy concretas.

7.2.3.2 Cómo trabajar con los canales

En el registro, el sistema recibe canales del Centro de servicios al cliente de Los nombres de canales corresponden a URI específicos del centro del cliente (ver http://scc.suse.com). Para ver todos los canales disponibles del sistema, utilice zypper tal como se describe a continuación:

zypper repos -u

Esto proporciona una lista de todos los canales disponibles en el sistema. Cada canal 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.

Si desea eliminar canales antiguos (por ejemplo, del SP1), utilice zypper removerepo y los nombres de los canales. Por ejemplo, para eliminar los canales antiguos del SP1 y el SP2, utilice el siguiente comando:

zypper removerepo SLES11-SP1-Pool SLES11-SP1-Updates \
  SLE11-SP1-Debuginfo-Pool SLE11-SP1-Debuginfo-Updates \
  SLES11-SP2-Core SLES11-SP2-Updates \
  SLE11-SP2-Debuginfo-Core SLES11-SP2-Extension-Store\
  SLE11-SP2-Debuginfo-Updates

Si desea volver a añadir algunos de los canales, entre a la sesión en http://www.novell.com/ncc y seleccione el menú Mis productos › Duplicar credenciales. Desde allí podrá ver una lista de URI. Solo es posible añadir los canales de esta lista de productos. Por ejemplo, para añadir el almacén de extensiones del SP2, utilice el siguiente comando (una línea, sin barra invertida):

zypper addrepo -n SLES11-SP2-Extension-Store \
 https://nu.novell.com/repo/$RCE/SLES11-SP2-Extension-Store/nu_novell_com:SLES11-SP2-Extension-Store

7.3 Vías de actualización a SLE SP4 admitidas

Actualizar SLES 8, SLES 9 y NLD 9

No se admite ninguna vía de actualización directa para estas versiones. En vez de actualizar, es preferible realizar una instalación nueva.

Actualizar de SUSE Linux Enterprise 10 (cualquier paquete de servicios)

Existen varias formas de actualizar de SLES 10 GA y SPx o de SLES 11 GA y SP1 a SLES 11 SP3, lo que puede requerir de pasos intermedios:

  • SLES 10 GA -> SLES 10 SP1 -> SLES 10 SP2 -> SLES 10 SP3 -> SLES 10 SP4 -> SLES 11 SP3 o

  • SLES 11 GA -> SLES 11 SP1 -> SLES 11 SP2 -> SLES 11 SP3 -> SLES 11 SP4

Se admite la actualización desde SLES 10 SP4 a través de un medio de arranque (incluido el arranque PXE). Para obtener más información, consulte las notas de la versión, que encontrará en https://www.suse.com/releasenotes/x86_64/SUSE-SLES/11-SP4/#Update.General.Sequence.

Atención para los usuarios de SLED: algunos paquetes de desarrollo se han trasladado del medio de instalación de SLED11-SP2 al repositorio SLED11-Extras. A fin de evitar conflictos de dependencias durante la actualización, habilite este repositorio antes de realizar la actualización en sí. Ejecute los repositorios de yast2 y habilite SLED11-Extras en ellos. En SLES, este paso adicional no es necesario.

Actualizar desde SUSE Linux Enterprise 11 GA

No se admite ninguna vía de migración directa a SUSE Linux Enterprise 11 SP3. Es necesario realizar primero una actualización de SUSE Linux Enterprise 11 GA a SP1. Continúe con Sección 7.5, “Actualizar SLE 11 SP1 a SLE 11 SP2” y, después, con Sección 7.6, “Actualizar SLE 11 SP2 a SLE 11 SP3”.

Actualizar de SUSE Linux Enterprise 11 SP1

Consulte la Sección 7.5, “Actualizar SLE 11 SP1 a SLE 11 SP2” para obtener más detalles.

Actualizar de SUSE Linux Enterprise 11 SP2

Consulte la Sección 7.6, “Actualizar SLE 11 SP2 a SLE 11 SP3” para obtener más detalles.

Actualizar de SUSE Linux Enterprise 11 SP3

Consulte la Sección 7.7, “Actualizar SLE 11 SP3 a SLE 11 SP4” para obtener más detalles.

Importante
Importante: no se admiten actualizaciones de arquitecturas cruzadas

No se admiten las actualizaciones entre arquitecturas (de 32 bits a 64 bits y viceversa).

7.4 Preparativos generales para 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.

7.4.1 Creación de una copia de seguridad

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, además de a 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.

7.4.2 Particionamiento y espacio en disco

Antes de empezar el proceso de actualización, anote la partición raíz. El comando df / muestra el nombre de dispositivo de la partición raíz. En el Ejemplo 7.1, “Lista que se obtiene con df -h, la partición raíz que se debe escribir es /dev/sda3 (montada como /).

Ejemplo 7.1: Lista que se obtiene 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

El software tiende a crecer de una versión a la siguiente. Por ello, antes de actualizar debe saber de cuánto espacio dispone en la partición, empleando para ello el comando df. Si sospecha que no dispone de mucho espacio en el disco, asegure los datos antes de actualizar el sistema y volver a particionarlo. 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.

7.4.3 Apagado de máquinas virtuales

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.

7.4.4 Requisitos específicos de versiones

Para conocer los requisitos específicos, consulte las notas de la versión incluidas con la actualización. En las notas de la versión encontrará información adicional sobre los procedimientos de actualización.

Puede consultar en línea la versión actual del documento de notas de la versión de SUSE Linux Enterprise Servercon la información más reciente en http://www.suse.com/doc/sles11/#additional.

7.5 Actualizar SLE 11 SP1 a SLE 11 SP2

Hay dos modos diferentes de actualizar un sistema SUSE Linux Enterprise 11 SP1 al Service Pack 2. Puede emplear las herramientas de actualización en línea para instalar los parches correspondientes (migración en línea), o bien realizar el proceso desde el medio de instalación del Service Pack. Además, las actualizaciones se pueden realizar mediante servidores en los que se encuentre Subscription Management Tool o SUSE Manager.

La migración en línea es compatible con las siguientes herramientas:

  • YaST wagon (interfaz gráfica de usuario)

  • zypper (línea de comandos)

Si lo prefiere, puede descargar el medio con el Service Pack completo (imagen ISO de DVD). Inicie el proceso de actualización arrancando desde el medio físico del Service Pack o un origen de instalación de red.

7.5.1 Migración en línea

La actualización del sistema mediante la migración en línea se realiza desde el sistema en ejecución. Solo es necesario reiniciar una vez, cuando la actualización ha finalizado.

7.5.1.1 Requisitos

Para efectuar una actualización en línea, deben cumplirse los requisitos descritos a continuación. No olvide leer también la Sección 7.4, “Preparativos generales para la actualización”.

Registro del producto

Para que sea posible conectar con los canales de actualización, el producto debe estar registrado. Si no es el caso, ejecute el módulo Configuración del Centro de servicios al cliente de Novell en YaST o la herramienta de línea de comandos suse_register para iniciar el registro.

Ejecución de una actualización en línea

Asegúrese de que la versión instalada actualmente dispone de los parches más recientes. Ejecute una actualización en línea antes de la migración en línea. Si utiliza una interfaz gráfica, inicie la actualización en línea de YaST, o el applet de actualización. En la línea de comandos, ejecute los siguientes comandos (el último debe ejecutarse dos veces):

zypper ref -s
zypper update -t patch
zypper update -t patch

Reinicie el sistema si es necesario.

Consulte el Chapter 1, YaST Online Update o la Section 6.1.3, “Updating Software with Zypper” para obtener más información sobre las herramientas de actualización en línea.

Software de otros fabricantes

Si la configuración afecta a software de otros fabricantes o a software complementario, pruebe este procedimiento en otro equipo para asegurarse de que no se rompen las dependencias durante la actualización.

Importante
Importante: ejecute siempre una migración en línea completa

La migración en línea siempre debe completarse de principio a fin. Si una migración en línea se interrumpe, el sistema sufrirá daños irrecuperables.

7.5.1.2 Migración en línea con YaST Wagon

Si tiene un sistema SLES 11 SP1, encontrará los pasos necesarios en https://www.suse.com/support/kb/doc.php?id=7011872. El procedimiento siguiente se aplica a la migración en línea de SP2 a SP3.

  1. Si se cumplen todos los requisitos (consulte la Sección 7.5.1.1, “Requisitos”), el applet de actualización de la bandeja del sistema mostrará un mensaje para indicar que hay una actualización de la distribución disponible. Haga clic en él para iniciar YaST Wagon Si lo prefiere, ejecute /usr/sbin/wagon como raíz desde la línea de comandos.

  2. Confirme el diálogo de Bienvenida con la opción Siguiente.

  3. Si Wagon detecta que no se cumplen los requisitos (hay actualizaciones de mantenimiento obligatorias disponibles pero no instaladas), realizará una actualización automática, lo que podría requerir un reinicio. Siga las instrucciones que aparecen en pantalla.

  4. Seleccione el método de actualización en el siguiente diálogo. Seleccione Centro de servicios al cliente para usar la configuración por defecto (recomendada).

    Haga clic en URL personalizada para elegir manualmente los canales de software que se deben emplear para la migración en línea. Se mostrará una lista de canales que le permitirá habilitar, inhabilitar, añadir o suprimir canales manualmente. Añada los orígenes de actualizaciones de SP2. Puede ser el medio de instalación de SP2 o los canales SP2-Core y SP2-Updates. Haga clic en Aceptar para volver al diálogo Método de actualización.

    Si desea revisar los cambios en la configuración de canales causados por el proceso de actualización, seleccione Comprobar cambios automáticos del repositorio.

    Haga clic en Siguiente.

  5. El sistema se volverá a registrar. Durante este proceso, los canales SP2-Core y SP2-Updates se añadirán al sistema (consulte Sección 7.2.3, “Modelo de canales” para obtener más información). Confirme la adición de los canales.

  6. Si ha seleccionado Comprobar cambios automáticos del repositorio en el diálogo Método de actualización, se mostrará la lista de repositorios, que le permitirá habilitar, inhabilitar, añadir o suprimir canales manualmente. Haga clic en Aceptar cuando haya terminado.

  7. Seleccione el tipo de migración:

    Migración completa

    Se actualizarán todos los paquetes al nivel más reciente del SP2.

    Migración mínima

    Se actualizará un conjunto mínimo de paquetes al nivel más reciente del SP2.

    Haga clic en Avanzado para seleccionar manualmente los repositorios empleados para la actualización.

    Confirme la selección.

  8. Se abrirá la pantalla Valores de actualización de la distribución, que muestra un resumen de la configuración de la actualización. Las secciones disponibles son las siguientes:

    Productos complementarios

    Podrá añadir productos complementarios de SUSE Linux Enterprise Server o productos de otro fabricante.

    Opciones de actualización

    Muestra las acciones que se llevarán a cabo durante la actualización. Puede decidir si se deben descargar todos los paquetes antes de empezar a instalarlos (valor por defecto y recomendado) o si se deben descargar e instalar de uno en uno.

    Paquetes

    Descripción general de estadísticas de la actualización.

    Copia de seguridad

    Defina las opciones de copia de seguridad.

    Haga clic en Siguiente y en Iniciar actualización para continuar.

    Importante
    Importante: cancelación de la migración en línea

    Puede cancelar la migración en línea de forma segura desde esta pantalla y las anteriores antes de hacer clic en Iniciar actualización. Haga clic en Cancelar para abandonar el procedimiento de actualización y restaurar el sistema al estado en el que se encontraba antes de iniciar YaST wagon. Siga las instrucciones que aparezcan en pantalla y repita el registro antes de salir de Wagon para eliminar los canales del SP2 del sistema.

  9. Durante el procedimiento de actualización se ejecutan los siguientes pasos:

    1. Los paquetes se actualizarán.

    2. SuSEconfig se ejecutará.

    3. El sistema se reiniciará (pulse Aceptar).

    4. El sistema recién actualizado se volverá a registrar.

  10. El sistema se ha actualizado correctamente al Service Pack 2.

7.5.1.3 Migración en línea con zypper

  1. Si se cumplen todos los requisitos (consulte la Sección 7.5.1.1, “Requisitos”), los productos necesarios para la migración en línea se añaden a /etc/products.d. Para obtener una lista de dichos productos, ejecute el siguiente comando:

    zypper se -t product | grep -h -- "-migration" | cut -d'|' -f2

    El comando debe devolver al menos SUSE_SLES-SP2-migration. Dependiendo del alcance de la instalación, es posible que incluya más productos.

  2. Instale los productos de migración recuperados en el paso anterior con el comando zypper in -t producto LISTA_DE_PRODUCTOS, por ejemplo.

    zypper in -t product SUSE_SLES-SP2-migration
  3. Registre los productos instalados en el paso anterior para obtener los canales de actualización correspondientes:

    suse_register -d 2 -L /root/.suse_register.log
  4. Vuelva a actualizar los repositorios y los servicios:

    zypper ref -s
  5. Compruebe la lista de los repositorios que puede recuperar con zypper lr. Al menos los siguientes repositorios deben estar habilitados:

    • SLES11-SP1-Pool

    • SLES11-SP1-Updates

    • SLES11-SP2-Core

    • SLES11-SP2-Updates

    Dependiendo del alcance de la instalación, será necesario habilitar más repositorios para productos complementarios o extensiones.

    Si uno de los repositorios no está habilitado (los del SP2 no están habilitados por defecto si se sigue este flujo de trabajo), habilítelos con el comando zypper modifyrepo --enable ALIAS DE REPOSITORIO, por ejemplo:

    zypper modifyrepo --enable SLES11-SP2-Core SLES11-SP2-Updates

    Si la configuración contiene repositorios de otros fabricantes que podrían no ser compatibles con el SP2, inhabilítelos con zypper modifyrepo --disable ALIAS DE REPOSITORIO.

  6. Todo está preparado para realizar la actualización de la distribución con zypper dup --from REPO 1 --from REPO 2 ... Asegúrese de que se enumeran todos los repositorios necesarios con --from, por ejemplo:

    zypper dup --from SLES11-SP2-Core --from SLES11-SP2-Updates

    Confirme con y para iniciar la actualización.

  7. Una vez completada la actualización de la distribución mediante el paso anterior, se habrá realizado una migración mínima (un conjunto mínimo de paquetes actualizados al nivel más reciente del SP2). Omita este paso si no pretende realizar una migración completa.

    Para realizar una migración completa (actualiza todos los paquetes al nivel más reciente del SP2), ejecute el siguiente comando:

    zypper update -t patch
  8. Ahora que se ha completado la actualización al SP2, deberá volver a registrar el producto:

    suse_register -d 2 -L /root/.suse_register.log
  9. Por último, reinicie el sistema.

  10. El sistema se ha actualizado correctamente al Service Pack 2.

7.5.2 Actualización mediante el arranque desde un origen de instalación

Como alternativa a la migración en línea (consulte la Sección 7.5.1, “Migración en línea” para obtener más información), también puede actualizar el sistema arrancándolo desde un origen de instalación (ya sea un DVD o un origen de instalación de red). La actualización comenzará como una instalación normal.

Puede obtener una imagen ISO del Service Pack 2 desde http://download.novell.com/. Grábela en un DVD o prepare un origen de instalación de red, tal como se describe en la Sección 14.2, “Configuración del servidor que almacena los orígenes de la instalación”.

7.5.2.1 Actualización desde una unidad de DVD local

Antes de comenzar una instalación nueva de un paquete de servicios de SUSE Linux Enterprise SP, asegúrese de que todos los medios de instalación del paquete de servicios (los DVD) están disponibles.

Procedimiento 7.1: Arranque desde el medio del Service Pack.
  1. Inserte el primer medio SUSE Linux Enterprise SP y arranque el equipo. Se mostrará una pantalla de arranque parecida a la de la instalación original de SUSE Linux Enterprise 11.

  2. Seleccione Instalación y continúe como se describe en las instrucciones de instalación de YaST en el Capítulo 6, Instalación mediante YaST.

7.5.2.2 Actualización desde un origen de instalación de red

Antes de iniciar una actualización de un SUSE Linux Enterprise SP desde un origen de instalación de red, compruebe que se cumplen los siguientes requisitos:

Consulte Capítulo 14, Instalación remota para obtener información más detallada sobre cómo iniciar la actualización desde un servidor remoto.

7.5.2.2.1 Instalación en red: arranque desde un DVD

Para realizar una instalación de red utilizando el DVD del paquete de servicios como medio de arranque, haga lo siguiente:

  1. Inserte el DVD 1 SUSE Linux Enterprise SP y arranque el equipo. Se mostrará una pantalla de arranque parecida a la de la instalación original de SUSE Linux Enterprise 11.

  2. Seleccione Instalación para arrancar el núcleo del paquete de servicios y pulse F4 para seleccionar el tipo de origen de instalación de red (FTP, HTTP, NFS o SMB).

  3. Proporcione la información de la vía adecuada o seleccione SLP como origen de instalación.

  4. Seleccione el servidor de instalación oportuno entre los que se ofrecen o utilice el indicador de opciones de arranque para proporcionar el tipo de origen de instalación y su ubicación real, como se describe en la Sección 6.1.2, “Instalación desde un origen de red sin SLP”. Se iniciará YaST.

    Complete la instalación como se describe en la Sección 7.5.2.3, “Procedimiento de actualización”.

7.5.2.2.2 Instalación de red: arranque PXE

Para realizar una instalación de un Service Pack de SUSE Linux Enterprise a través de la red, haga lo siguiente:

  1. Ajuste la configuración del servidor DHCP para proporcionar la información de dirección necesaria para el arranque PXE como se describe en la Sección 14.3.5, “Preparación del sistema de destino para arranque en PXE”.

  2. Configure un servidor TFTP para almacenar la imagen necesaria para el arranque PXE.

    Utilice el primer CD o DVD del paquete de servicios de SUSE Linux Enterprise o siga las instrucciones de la Sección 14.3.2, “Configuración de un servidor TFTP”.

  3. Prepare el arranque PXE y Wake-on-LAN en el equipo de destino.

  4. Inicie el arranque del sistema de destino y utilice el VNC para conectar de forma remota con la rutina de instalación en ejecución en ese equipo. Consulte la Sección 14.5.1, “Instalación de VNC” para obtener más información.

  5. Complete la instalación como se describe en la Sección 7.5.2.3, “Procedimiento de actualización”.

7.5.2.3 Procedimiento de actualización

Después de arrancar correctamente desde un medio de instalación o desde la red, lleve a cabo los pasos descritos a continuación para iniciar la actualización:

  1. En la pantalla de Bienvenida, seleccione el Idioma y el Teclado y acepte el Acuerdo de licencia. Haga clic en Siguiente.

  2. En caso de que haya arrancado desde un medio físico, realice una Comprobación de medios para verificar la integridad del medio. Omita este paso solo si ha comprobado el medio anteriormente.

  3. En la pantalla Modo de instalación, seleccione Actualizar. Al hacer clic en Siguiente, comenzará el procedimiento de actualización.

7.5.3 Actualización a través de Subscription Management Tool (SMT)

Como alternativa a la descarga de actualizaciones para cada sistema cliente desde el servidor de actualizaciones de Novell, es posible emplear el componente Subscription Management Tool (SMT) para SUSE Linux Enterprise, a fin de duplicar las actualizaciones en un servidor local.

Esta herramienta actúa como proxy del Centro de servicios al cliente de Novell para registrar clientes y como repositorio de actualizaciones de software. La documentación de SMT disponible en http://www.suse.com/doc/smt11/ ofrece una descripción general de sus funciones, así como instrucciones acerca de cómo implementarla.

7.5.4 Actualización a través de SUSE Manager

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.

La documentación de SUSE Manager http://www.suse.com/doc/suse_manager/ ofrece una descripción general de sus funciones e instrucciones acerca de cómo configurar servidores y clientes.

7.6 Actualizar SLE 11 SP2 a SLE 11 SP3

La migración en línea es compatible con las siguientes herramientas:

  • YaST wagon (interfaz gráfica de usuario)

  • zypper (línea de comandos)

Si actualiza el sistema mediante la migración en línea, la actualización se lleva a cabo con el sistema en ejecución. Solo es necesario reiniciar una vez, cuando la actualización ha finalizado. Sigue siendo posible actualizar mediante las siguientes alternativas:

7.6.1 Requisitos

Para efectuar una actualización en línea, deben cumplirse los requisitos descritos a continuación. No olvide leer también la Sección 7.4, “Preparativos generales para la actualización”.

Registro del producto

Para que sea posible conectar con los canales de actualización, el producto debe estar registrado. Si no es el caso, ejecute el módulo Configuración del Centro de servicios al cliente de Novell en YaST o la herramienta de línea de comandos suse_register para iniciar el registro.

Ejecución de una actualización en línea

Asegúrese de que la versión instalada actualmente dispone de los parches más recientes. Ejecute una actualización en línea antes de la migración en línea. Si utiliza una interfaz gráfica, inicie la actualización en línea de YaST, o el applet de actualización. En la línea de comandos, ejecute los siguientes comandos (el último debe ejecutarse dos veces):

zypper ref -s
zypper update -t patch
zypper update -t patch

Reinicie el sistema si es necesario.

Consulte el Chapter 1, YaST Online Update o la Section 6.1.3, “Updating Software with Zypper” para obtener más información acerca de las herramientas de actualización en línea.

Software de otros fabricantes

Si la configuración afecta a software de otros fabricantes o a software complementario, pruebe este procedimiento en otro equipo para asegurarse de que no se rompen las dependencias durante la actualización.

Importante
Importante: ejecute siempre una migración en línea completa

La migración en línea siempre debe completarse de principio a fin. Si una migración en línea se interrumpe, el sistema sufrirá daños irrecuperables.

7.6.2 Migración en línea con YaST Wagon

  1. Si se cumplen todos los requisitos (consulte la Sección 7.5.1.1, “Requisitos”), el applet de actualización de la bandeja del sistema mostrará un mensaje para indicar que hay una actualización de la distribución disponible. Haga clic en él para iniciar YaST Wagon Si lo prefiere, ejecute /usr/sbin/wagon como raíz desde la línea de comandos.

  2. Confirme el diálogo de Bienvenida con la opción Siguiente.

  3. Si Wagon detecta que no se cumplen los requisitos (hay actualizaciones de mantenimiento obligatorias disponibles pero no instaladas), realizará una actualización automática, lo que podría requerir un reinicio. Siga las instrucciones que aparecen en pantalla.

  4. Seleccione el método de actualización en el siguiente diálogo. Seleccione Centro de servicios al cliente para usar la configuración por defecto (recomendada).

    Haga clic en URL personalizada para elegir manualmente los canales de software que se deben emplear para la migración en línea. Se mostrará una lista de canales que le permitirá habilitar, inhabilitar, añadir o suprimir canales manualmente. Añada los orígenes de actualizaciones del SP3. Puede ser el medio de instalación del SP3 o los canales SP3-Pool y SP3-Updates. Haga clic en Aceptar para volver al diálogo Método de actualización.

    Si desea revisar los cambios en la configuración de canales causados por el proceso de actualización, seleccione Comprobar cambios automáticos del repositorio.

    Haga clic en Siguiente.

  5. El sistema se volverá a registrar. Durante este proceso, los canales SP3-Pool y SP3-Updates se añadirán al sistema (consulte Sección 7.2.3, “Modelo de canales” para obtener más información). Confirme la adición de los canales.

  6. Si ha seleccionado Comprobar cambios automáticos del repositorio en el diálogo Método de actualización, se mostrará la lista de repositorios, que le permitirá habilitar, inhabilitar, añadir o suprimir canales manualmente. Haga clic en Aceptar cuando haya terminado.

  7. Se abrirá la pantalla Valores de actualización de la distribución, que muestra un resumen de la configuración de la actualización. Las secciones disponibles son las siguientes:

    Productos complementarios

    Podrá añadir productos complementarios de SUSE Linux Enterprise Server o productos de otro fabricante.

    Opciones de actualización

    Muestra las acciones que se llevarán a cabo durante la actualización. Puede decidir si se deben descargar todos los paquetes antes de empezar a instalarlos (valor por defecto y recomendado) o si se deben descargar e instalar de uno en uno.

    Paquetes

    Descripción general de estadísticas de la actualización.

    Copia de seguridad

    Defina las opciones de copia de seguridad.

    Haga clic en Siguiente y en Iniciar actualización para continuar.

    Importante
    Importante: cancelación de la migración en línea

    Puede cancelar la migración en línea de forma segura desde esta pantalla y las anteriores antes de hacer clic en Iniciar actualización. Haga clic en Cancelar para abandonar el procedimiento de actualización y restaurar el sistema al estado en el que se encontraba antes de iniciar YaST Wagon. Siga las instrucciones que aparezcan en pantalla y repita el registro antes de salir de Wagon para eliminar los canales del SP2 del sistema.

  8. Durante el procedimiento de actualización se ejecutan los siguientes pasos:

    1. Los paquetes se actualizarán.

    2. SuSEconfig se ejecutará.

    3. El sistema se reiniciará (pulse Aceptar).

    4. El sistema recién actualizado se volverá a registrar.

  9. El sistema se ha actualizado correctamente al Service Pack 3.

7.6.3 Migración en línea con zypper

  1. Si se cumplen todos los requisitos (consulte Sección 7.5.1.1, “Requisitos”), los productos necesarios para la migración en línea se añaden a /etc/products.d. Para obtener una lista de dichos productos, ejecute el siguiente comando:

    zypper se -t product | grep -h -- "-migration" | cut -d'|' -f2

    El comando debe devolver al menos SUSE_SLES-SP3-migration. Dependiendo del alcance de la instalación, es posible que incluya más productos.

  2. Instale los productos de migración recuperados en el paso anterior con el comando zypper in -t producto LISTA_DE_PRODUCTOS, por ejemplo.

    zypper in -t product SUSE_SLES-SP3-migration
  3. Registre los productos instalados en el paso anterior para obtener los canales de actualización correspondientes:

    suse_register -d 2 -L /root/.suse_register.log
  4. Actualice los repositorios y servicios:

    zypper ref -s
  5. Compruebe la lista de los repositorios que puede recuperar con zypper lr.

    Si uno de los repositorios no está habilitado (los del SP3 no están habilitados por defecto si se sigue este flujo de trabajo), habilítelos con el comando zypper modifyrepo --enable ALIAS DE REPOSITORIO, por ejemplo:

    zypper modifyrepo --enable SLES11-SP3-Core SLES11-SP3-Updates

    Si la configuración contiene repositorios de otros fabricantes que podrían no ser compatibles con el SP3, inhabilítelos con zypper modifyrepo --disable ALIAS DE REPOSITORIO.

  6. Todo está preparado para realizar la actualización de la distribución con zypper dup --from REPO 1 --from REPO 2 .... Asegúrese de que se enumeran todos los repositorios necesarios con --from, por ejemplo:

    zypper dup --from SLES11-SP3-Pool --from SLES11-SP3-Updates

    Confirme con y para iniciar la actualización.

  7. Una vez finalizada la actualización de la distribución en el paso anterior, ejecute el siguiente comando:

    zypper update -t patch
  8. Ahora que se ha completado la actualización al SP3, deberá volver a registrar el producto:

    suse_register -d 2 -L /root/.suse_register.log
  9. Por último, reinicie el sistema.

  10. El sistema se ha actualizado correctamente al Service Pack 3.

7.7 Actualizar SLE 11 SP3 a SLE 11 SP4

Hay varios modos diferentes de actualizar un sistema SUSE Linux Enterprise Server 11 SP3 al Service Pack 4. Puede emplear las herramientas de actualización en línea para instalar los parches correspondientes (migración en línea), o bien realizar el proceso desde el medio de instalación del Service Pack. Además, las actualizaciones se pueden realizar mediante servidores en los que se encuentre Subscription Management Tool (SMT) o SUSE Manager.

La migración en línea es compatible con las siguientes herramientas:

  • YaST wagon (interfaz gráfica de usuario)

  • zypper (línea de comandos)

Si lo prefiere, puede descargar el medio con el Service Pack completo (imagen ISO de DVD). Inicie el proceso de actualización arrancando desde el medio físico del Service Pack o un origen de instalación de red.

7.7.1 Migración en línea

La actualización del sistema mediante la migración en línea se realiza desde el sistema en ejecución. Solo es necesario reiniciar una vez, cuando la actualización ha finalizado.

7.7.1.1 Requisitos

Para efectuar una actualización en línea, deben cumplirse los requisitos descritos a continuación. No olvide leer también la Sección 7.4, “Preparativos generales para la actualización”.

Registro del producto

Para que sea posible conectar con los canales de actualización, el producto debe estar registrado. Si no es el caso, ejecute el módulo Configuración del Centro de servicios al cliente de Novell en YaST o la herramienta de línea de comandos suse_register para iniciar el registro.

Ejecución de una actualización en línea

Asegúrese de que la versión instalada actualmente dispone de los parches más recientes. Ejecute una actualización en línea antes de la migración en línea. Si utiliza una interfaz gráfica, inicie la actualización en línea de YaST, o el applet de actualización. En la línea de comandos, ejecute los siguientes comandos (el último debe ejecutarse dos veces):

zypper ref -s
zypper update -t patch
zypper update -t patch

Reinicie el sistema si es necesario.

Consulte la Sección 1.0, Actualización en línea de YaST, (↑Guía de administración) o la Sección 6.1.3, Actualización del software con Zypper, (↑Guía de administración). para obtener más información sobre las herramientas de actualización en línea.

Software de otros fabricantes

Si la configuración afecta a software de otros fabricantes o a software complementario, pruebe este procedimiento en otro equipo para asegurarse de que no se rompen las dependencias durante la actualización.

Importante
Importante: ejecute siempre una migración en línea completa

La migración en línea siempre debe completarse de principio a fin. Si una migración en línea se interrumpe, el sistema sufrirá daños irrecuperables.

7.7.1.2 Migración en línea con YaST Wagon

Si tiene un sistema SLES 11 SP1, encontrará los pasos necesarios en https://www.suse.com/support/kb/doc.php?id=7011872. El procedimiento siguiente se aplica a la migración en línea de SP3 a SP4.

  1. Si se cumplen todos los requisitos (consulte la Sección 7.5.1.1, “Requisitos”), el applet de actualización de la bandeja del sistema mostrará un mensaje para indicar que hay una actualización de la distribución disponible. Haga clic en él para iniciar YaST Wagon Si lo prefiere, ejecute /usr/sbin/wagon como raíz desde la línea de comandos.

  2. Confirme el diálogo de Bienvenida con la opción Siguiente.

  3. Si Wagon detecta que no se cumplen los requisitos (hay actualizaciones de mantenimiento obligatorias disponibles pero no instaladas), realizará una actualización automática, lo que podría requerir un reinicio. Siga las instrucciones que aparecen en pantalla.

  4. Seleccione el método de actualización en el siguiente diálogo. Seleccione Centro de servicios al cliente para usar la configuración por defecto (recomendada).

    Haga clic en URL personalizada para elegir manualmente los canales de software que se deben emplear para la migración en línea. Se mostrará una lista de canales que le permitirá habilitar, inhabilitar, añadir o suprimir canales manualmente. Añada los orígenes de actualizaciones de SP4. Puede ser el medio de instalación del SP4 o los canales SP4-Pool y SP4-Updates. Haga clic en Aceptar para volver al diálogo Método de actualización.

    Si desea revisar los cambios en la configuración de canales causados por el proceso de actualización, seleccione Comprobar cambios automáticos del repositorio.

    Haga clic en Siguiente.

  5. El sistema se volverá a registrar. Durante este proceso, los canales SP4-Pool y SP4-Updates se añadirán al sistema (consulte Sección 7.2.3, “Modelo de canales” para obtener más información). Confirme la adición de los canales.

  6. Si ha seleccionado Comprobar cambios automáticos del repositorio en el diálogo Método de actualización, se mostrará la lista de repositorios, que le permitirá habilitar, inhabilitar, añadir o suprimir canales manualmente. Haga clic en Aceptar cuando haya terminado.

  7. Seleccione el tipo de migración:

    Migración completa

    Se actualizarán todos los paquetes al nivel más reciente del SP4.

    Migración mínima

    Se actualizará un conjunto mínimo de paquetes al nivel más reciente del SP4.

    Haga clic en Avanzado para seleccionar manualmente los repositorios empleados para la actualización. Confirme la selección.

  8. Se abrirá la pantalla Valores de actualización de la distribución, que muestra un resumen de la configuración de la actualización. Las secciones disponibles son las siguientes:

    Productos complementarios

    Podrá añadir productos complementarios de SUSE Linux Enterprise Server o productos de otro fabricante.

    Opciones de actualización

    Muestra las acciones que se llevarán a cabo durante la actualización. Puede decidir si se deben descargar todos los paquetes antes de empezar a instalarlos (valor por defecto y recomendado) o si se deben descargar e instalar de uno en uno.

    Paquetes

    Descripción general de estadísticas de la actualización.

    Copia de seguridad

    Defina las opciones de copia de seguridad.

    Haga clic en Siguiente y en Iniciar actualización para continuar.

    Importante
    Importante: cancelación de la migración en línea

    Puede cancelar la migración en línea de forma segura desde esta pantalla y las anteriores antes de hacer clic en Iniciar actualización. Haga clic en Cancelar para abandonar el procedimiento de actualización y restaurar el sistema al estado en el que se encontraba antes de iniciar YaST Wagon. Siga las instrucciones que aparezcan en pantalla y repita el registro antes de salir de Wagon para eliminar los canales del SP4 del sistema.

  9. Durante el procedimiento de actualización se ejecutan los siguientes pasos:

    1. Los paquetes se actualizarán.

    2. SuSEconfig se ejecutará.

    3. El sistema se reiniciará (pulse Aceptar).

    4. El sistema recién actualizado se volverá a registrar.

  10. El sistema se ha actualizado correctamente al Service Pack 4.

7.7.1.3 Migración en línea con zypper

  1. Si se cumplen todos los requisitos (consulte Sección 7.5.1.1, “Requisitos”), los productos necesarios para la migración en línea se añaden a /etc/products.d. Para obtener una lista de dichos productos, ejecute el siguiente comando:

    zypper se -t product | grep -h -- "-migration" | cut -d'|' -f2

    El comando debe devolver al menos SUSE_SLES-SP4-migration. Dependiendo del alcance de la instalación, es posible que incluya más productos.

  2. Instale los productos de migración recuperados en el paso anterior con el comando zypper in -t producto LISTA_DE_PRODUCTOS, por ejemplo.

    zypper in -t product SUSE_SLES-SP4-migration
  3. Registre los productos instalados en el paso anterior para obtener los canales de actualización correspondientes:

    suse_register -d 2 -L /root/.suse_register.log
  4. Actualice los repositorios y servicios:

    zypper ref -s
  5. Compruebe la lista de los repositorios que puede recuperar con zypper lr. Al menos los siguientes repositorios deben estar habilitados:

    • SLES11-SP4-Pool

    • SLES11-SP4-Updates

    Dependiendo del alcance de la instalación, será necesario habilitar más repositorios para productos complementarios o extensiones.

    Si uno de los repositorios no está habilitado (los del SP4 no están habilitados por defecto si se sigue este flujo de trabajo), habilítelos con el comando zypper modifyrepo --enable ALIAS DE REPOSITORIO, por ejemplo:

    zypper modifyrepo --enable SLES11-SP4-Pool --enable SLES11-SP4-Updates

    Si la configuración contiene repositorios de otros fabricantes que podrían no ser compatibles con el SP4, inhabilítelos con zypper modifyrepo --disable ALIAS DE REPOSITORIO.

  6. Todo está preparado para realizar la actualización de la distribución con zypper dup --from REPO 1 --from REPO 2 ... Asegúrese de que se enumeran todos los repositorios necesarios con --from, por ejemplo:

    zypper dup --from SLES11-SP4-Pool --from SLES11-SP4-Updates

    Confirme con y para iniciar la actualización.

  7. Una vez completada la actualización de la distribución mediante el paso anterior, se habrá realizado una migración mínima (un conjunto mínimo de paquetes actualizados al nivel más reciente del SP4). Omita este paso si no pretende realizar una migración completa.

    Para realizar una migración completa (actualiza todos los paquetes al nivel más reciente del SP4), ejecute el siguiente comando:

    zypper update -t patch
  8. Ahora que se ha completado la actualización al SP4, deberá volver a registrar el producto:

    suse_register -d 2 -L /root/.suse_register.log
  9. Por último, reinicie el sistema.

El sistema se ha actualizado correctamente al Service Pack 4.

7.7.1.4 Actualización mediante el arranque desde un origen de instalación

Como alternativa a la migración en línea, también puede actualizar el sistema arrancándolo desde un origen de instalación (ya sea un DVD o un origen de instalación de red). La actualización comenzará como una instalación normal.

Puede obtener una imagen ISO del Service Pack 4 desde http://download.suse.com/. Grábela en un DVD o prepare un origen de instalación de red, tal como se describe en la Sección 14.2, “Configuración del servidor que almacena los orígenes de la instalación”.

7.8 Backport de código fuente

SUSE hace un amplio uso de la técnica de backport. La información que encontrará en esta sección le ayudará a entender por qué puede resultar engañoso comparar números de versiones para juzgar la capacidad y posibles problemas del software.

7.8.1 ¿Por qué el concepto de backport?

A los desarrolladores en sentido ascendente les preocupa sobre todo que avance el software que están creando. En muchos casos, 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:

  • soluciones de errores con un potencial limitado para afectar a la funcionalidad; y

  • cambios que pueden afectar a la funcionalidad existente.

En la mayoría de los casos, 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:

  • cuando los cambios entre sus paquetes y las versiones de sentido ascendente son tan grandes que el enfoque de backport ya no es factible; o

  • en el caso de software que por sus características propias, se queda obsoleto con facilidad, como los productos contra el software dañino.

7.8.2 Motivos para emplear backport

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

  • Disponer de interfaces estables (API) en las que los fabricantes de software puedan confiar al crear componentes para su uso en los productos de empresa de SUSE.

  • Garantizar que los paquetes empleados para publicar los productos de empresa de SUSE sean de la mayor calidad y se hayan sometido a pruebas exhaustivas, por sí mismos y como parte del producto de empresa completo.

  • Mantener las diferentes certificaciones de los productos de empresa de SUSE por parte de otros fabricantes, como certificaciones para productos de Oracle o SAP.

  • Permitir que los desarrolladores de SUSE se concentren en crear una siguiente versión del producto tan buena como sea posible, en lugar de tener que dividir su atención entre un amplio número de versiones.

  • Mantener una visión clara de qué es una publicación de empresa particular, de modo que nuestra asistencia pueda proporcionar información precisa y más reciente sobre ello.

7.8.3 Argumentos en contra del enfoque de backport

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 una clase limitada 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.

7.8.4 Implicaciones del concepto de backport para interpretar números de versiones

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.

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

  • El registro de cambios del paquete:

    rpm -q --changelog name-of-installed-package
    rpm -qp --changelog packagefile.rpm

    El contenido documenta brevemente el historial de cambios del paquete.

  • El registro de cambios del paquete puede incluir entradas como bnc#1234, que hagan referencia al sistema de seguimiento de Bugzilla de Novell, o bien enlaces a otros sistemas de seguimiento de errores. (Por motivos de confidencialidad, quizá no sea posible acceder a toda la información al respecto.)

  • Los paquetes pueden incluir un archivo /usr/share/doc/packagename/README.SUSE o README.SuSE con información general de alto nivel, específica del paquete de SUSE.

  • El paquete de código fuente del RPM contiene los parches aplicados al crear los RPM binarios normales como archivos independientes. Puede interpretar dicha información si está familiarizado con la lectura de código fuente. Consulte el documento Maximum RPM para obtener más información.

  • Para conocer las soluciones a problemas de seguridad, consulte los avisos de seguridad de SUSE. Suelen hacer referencia a errores mediante nombres estandarizados, como CAN-2005-2495, mantenidos por el proyecto Common Vulnerabilities and Exposures (Vulnerabilidades y puntos expuestos habituales).

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 o pruebas suelen generar falsos positivos (indican que han detectado vulnerabilidades que en realidad no existen) cuando hay versiones de backport implicadas. Al evaluar informes de herramientas de seguridad, siempre se debe investigar si una entrada se basa solamente en un número de versión o en una prueba real de que existe una vulnerabilidad.

7.9 Actualización Atomic

La actualización Atomic se basa en herramientas que gestionan dos copias del sistema y permite recuperarlo fácilmente tras un fallo de actualización. Las herramientas proporcionadas requieren una configuración especial de partición del disco. Cada copia del sistema reside en su propia partición primaria. Si una actualización falla, siempre es posible volver al estado anterior del sistema, que está disponible en la otra partición.

7.9.1 Configuración

Aviso
Aviso: requisitos estrictos de particionamiento

La implementación se rige por unos estrictos requisitos de particionamiento del disco: la primera partición raíz es /dev/sda1 y no debe ocupar más de la mitad de todo el tamaño del disco. La herramienta crea entonces /dev/sda2 para la segunda partición raíz del sistema. Las demás particiones, si las hay, se reparten entre ambas particiones raíces: tienen en cuenta su tamaño y reducen el tamaño de la primera partición en consecuencia. Este es un cálculo aproximado:

El tamaño del disco completo menos el tamaño de sda1 menos sda2 es el espacio libre de las particiones adicionales.

  1. Instale el sistema con /dev/sda1 como única partición raíz y con menos de la mitad del tamaño total del disco.

  2. Personalice el sistema instalado según precise. Asegúrese de que el paquete multi-update-tools está instalado.

  3. Ejecute multi-update-setup --partition, que crea una segunda partición raíz del sistema (/dev/sda2) de un tamaño similar.

  4. Particione el resto del disco según precise y continúe con las personalizaciones(*).

  5. Ejecute multi-update-setup --clone para copiar el sistema a la otra partición. Con este comando, también se cambia la entrada / (raíz) de /etc/fstab del sistema de destino.

  6. Si es necesario, realice las personalizaciones(*) oportunas.

  7. Ejecute multi-update-setup --bootloader para iniciar la configuración del gestor de arranque. El menú del gestor de arranque incluirá una entrada para arrancar el otro sistema.

    Aviso
    Aviso: gestor de arranque GRUB obligatorio

    La instalación del gestor de arranque GRUB es obligatoria. Las herramientas no son compatibles con otros gestores.

  8. Si no hay que hacer más personalizaciones (las marcadas con asterisco anteriormente), ejecute multi-update-setup --complete para realizar los tres pasos.

7.9.2 Actualización del otro sistema

Ejecute multi-update. Este comando ejecuta zypper en un entorno chroot y actualiza el otro sistema sin importar cuál de los dos es el activo. Su menú de arranque será el que aparezca al arrancar.

7.9.3 Resolución de problemas

Si el sistema actualizado tiene un gestor de arranque dañado después de la actualización, debe cambiar el indicador Activo y definirlo en la partición raíz del otro sistema para poder arrancarlo.

Si el sistema actualizado no se arranca de ninguna forma, debe acceder al menú del gestor de arranque para seleccionar el otro sistema.

Para obtener más información sobre GRUB, consulte el Chapter 11, The Boot Loader GRUB.

7.9.4 Limitación

La partición raíz debe montarse según el nombre de partición, el ID o cualquier otro modo. No es posible montarla según el UUID o la etiqueta de la partición.

7.9.5 Información adicional

Para obtener más información, consulte /usr/share/doc/packages/multi-update-tools/README, que se incluye en el paquete multi-update-tools.

7.10 Hooks de migración para YaST Wagon

Los hooks de migración facilitan la ejecución de un guion externo personalizado en algún momento durante el proceso de migración. Estos guiones permiten gestionar problemas específicos que no se pueden resolver mediante los guiones RPM habituales, o bien realizar cualquier acción adicional que pueda ser necesaria durante la migración (y que no lo sea al realizar la actualización normal de los paquetes).

Los hooks de migración se ejecutan con privilegios de usuario "root", de modo que es posible realizar tareas de mantenimiento mediante los guiones (iniciar o detener servicios, realizar copias de seguridad de datos, migrar datos, etc.). Los guiones no deben ser interactivos; STDIN y STDOUT se redireccionan a conductos cuando se ejecutan en YaST. No debe emplearse la sesión X, ya que quizá no esté disponible en todos los casos (por ejemplo, si la ejecución se lleva a cabo en modo texto). No olvide configurar el permiso de ejecución para los guiones de hook.

Los hooks de migración se admiten a partir de la versión 2.17.32.1 (proporcionada como actualización para SLES11-SP2) o 2.17.34 (incluida en SLES11-SP3) del paquete yast2-wagon y versiones superiores.

7.10.1 Ubicación del guion de hook y convenciones de nombres

Los guiones se buscan en el directorio /var/lib/YaST2/wagon/hooks/. El nombre esperado del guion tiene el formato paso_secuencia_prefijo_nombre, donde:

paso

Es el nombre de un paso de migración predefinido que describe el paso actual de la migración.

secuencia

es un número de secuencia del intervalo 00...99, que permite establecer el orden de ejecución de los guiones. (Es importante mantener los ceros iniciales para que el orden sea correcto.)

prefijo

debe ser único para evitar conflictos (como un espacio de nombres). Use el nombre del paquete (si forma parte de un paquete) o el nombre de proveedor, el nombre de dominio de Internet, etc., básicamente cualquier contenido que pueda considerarse suficientemente único.

nombre

puede ser cualquier cadena (simplemente para diferenciar los guiones). Se recomienda emplear un nombre descriptivo.

Ejemplo 7.2: Guion de hook con vía completa
/var/lib/YaST2/wagon/hooks/before_package_migration_00_postgresql_backup

7.10.2 Valor de salida con guion de hook

El guion debe devolver el valor de salida 0. Si falla (cualquier valor de salida distinto de cero), se muestra un mensaje de error en Wagon y existe la posibilidad de reiniciar el guion, omitir el fallo (y continuar con otros guiones) o bien cancelar por completo los hooks del paso y la etapa actuales.

7.10.3 Guiones de idempotencia

Los guiones de hook pueden ejecutarse potencialmente más veces (al avanzar y retroceder en los diálogos de Wagon, Wagon puede reiniciarse o puede que algunos pasos se ejecuten varias veces en el flujo de trabajo de migración), de modo que los guiones deben tener en cuenta ese hecho (pueden comprobar al principio si es necesario realizar la acción o ya se ha realizado, o bien crear un archivo sencillo de sello temporal o solucionar de otro modo las ejecuciones múltiples de la forma adecuada).

7.10.4 Lista de hooks admitidos

Algunos hooks son opcionales (porque dependen de resultados anteriores o de valores seleccionados por el usuario). Tenga en cuenta que algunos hooks se invocan varias veces (por ejemplo, el de registro se invoca antes y después de la migración). A continuación encontrará una lista de los hooks admitidos (nombres de pasos) según su orden de ejecución:

before_init

Se inicia al principio (nota: se vuelve a invocar cuando se reinicia Wagon).

before_welcome , after_welcome

Se inician antes y después del diálogo de bienvenida.

before_registration_check , after_registration_check

Wagon comprueba el estado de registro (si el registro de algunos productos ha caducado, la migración podría fallar). Si todo es correcto, no se muestra ningún diálogo y Wagon continúa automáticamente con el siguiente paso.

before_custom_url , after_custom_url

Se inicia el gestor de repositorios (opcional, solo en modo de CD de parches).

before_self_update , after_self_update

Se invocan antes y después de que Wagon se actualice a sí mismo (para garantizar que se emplee la versión más reciente en la migración).

before_installing_migration_products , after_installing_migration_products

Se invocan antes y después de instalar los productos que se van a migrar.

before_selecting_migration_source , after_selecting_migration_source

Wagon pregunta al usuario si quiere realizar la migración mediante los repositorios del Centro de servicios al cliente de Novell; o mediante un repositorio personalizado (el siguiente paso depende de la elección del usuario)

before_registration , after_registration

Se ejecuta el registro de SUSE (para añadir repositorios de migración).

before_repo_selection , after_repo_selection

Gestión manual de repositorios.

before_set_migration_repo , after_set_migration_repo

selección de repositorios de migración (migración completa/mínima mediante el Centro de servicios al cliente de Novell) o selección de repositorios de actualizaciones (migración de repositorios personalizados)

before_package_migration

Antes de que comience la actualización de paquetes, tras este paso comienza la migración real y no es posible volver al estado anterior automáticamente (si se cancela el proceso durante este paso se obtiene un sistema actualizado a medias y es necesario deshacer los cambios manualmente).

before_registration , after_registration

Ejecución de registro de SUSE (para registrar productos actualizados).

before_congratulate , after_congratulate

Antes y después de que Wagon muestre el diálogo de felicitación como resultado de una migración correcta.

before_exit

Se invoca justo antes de que se cierre Wagon (siempre, sea cual sea el resultado de la migración, también tras una cancelación y al reiniciar).

7.10.5 Hooks de cancelación

Se trata de hooks de cancelación especiales que se invocan cuando el usuario cancela la migración. Estos hooks pueden invocarse en cualquier paso del flujo de trabajo de migración, por lo que no es posible garantizar el orden de ejecución. Los guiones deben comprobar el estado actual si dependen de los resultados de otros hooks.

before_abort

El usuario ha confirmado la cancelación de la migración.

before_abort_rollback , after_abort_rollback

El usuario ha confirmado que quiere deshacer el proceso tras la migración (y volver a los productos anteriores instalados antes de que comenzara la migración). Estos hooks se invocan después de before_abort y se omiten si el usuario no confirma que desea deshacer el proceso.

7.10.6 Hooks de reinicio

Estos hooks se invocan siempre que Wagon se reinicia.

before_restart

Wagon está finalizando y se reiniciará.

after_restart

Wagon se ha reiniciado y está ejecutando el siguiente paso del flujo de trabajo de migración.

7.10.7 Hooks utilizados normalmente

La lista de hooks es bastante larga, pero muchos solo tienen sentido en casos especiales. En los casos normales de uso, deben tener preferencia los siguientes:

  • Para realizar alguna acción antes de que se migre el sistema (todavía se ejecuta la versión anterior), utilice el hook before_package_migration.

    En este punto, está claro que la migración está preparada y a punto de comenzar, mientras que en los pasos anteriores era posible cancelarla.

  • Para llevar a cabo alguna acción después de migrar el sistema (el sistema ejecuta la versión recién migrada, pero algunos elementos podrían no estar activos, como un núcleo o algunos servicios actualizados que requieren reiniciar, etc.), utilice los hooks before_congratulate o after_congratulate.

    También se pueden emplear para limpiar los resultados temporales del hook before_package_migration. En este punto, la migración ha finalizado satisfactoriamente.

  • Para deshacer los cambios si la migración se cancela, use uno de los hooks para cancelar, según el caso. Recuerde que los hooks para cancelar se pueden invocar en cualquier momento, por lo que quizá no sea necesario deshacer nada (es posible que el hook que realiza los cambios aún no se haya invocado). Los hooks de cancelación deben comprobar el estado actual.

7.10.8 Hooks obsoletos

Las versiones anteriores de Wagon solo admitían dos guiones de hooks: /usr/lib/YaST2/bin/wagon_hook_init y /usr/lib/YaST2/bin/wagon_hook_finish. El problema era que solo se podía ejecutar un guion como hook y no era posible incluir hooks directamente en paquetes RPM.

Estos guiones de hooks se siguen admitiendo en las nuevas versiones de Wagon para ofrecer compatibilidad con versiones anteriores, pero se deben emplear los nuevos hooks before_init y before_exit en lugar de los obsoletos.

Imprimir esta página