Actualizar versión de GPFS (IBM Spectrum Scale)

Escrito por Blai el 26.2.19

Cómo actualizar GPFS a la última versión, como recuperar GPFS tras una actualización de Linux, cómo hacer que GPFS se inicie automáticamente tras cada reinicio de la máquina.



General Parallel File System (GPFS) es un sistema de ficheros de alto rendimiento desarrollado por IBM. Este sistema de archivos proporciona un acceso de alta velocidad a ficheros ubicados dentro de un clúster de discos y es usado principalmente en servidores con bases de datos de gran tamaño.

Las versiones antiguas de GPFS (< 4.2.0) funcionan correctamente sobre kernels 3.x de Linux. Si actualizamos el kernel de un sistema Linux a una versión de la rama 4, nos encontraremos que GPFS deja de funcionar. Esto se debe a que se realizaron cambios importantes en el código del kernel de Linux en su versión 4, que requirieron una actualización importante del código de GPFS para hacerlos compatibles. Esto significa que una máquina con kernel 4 debe ir acompañada de GPFS >=4.2.

En 2015, IBM renombró GPFS a IBM Spectrum Scale, por lo que a partir de la versión 4.2, deberíamos referirnos a la tecnología GPFS como Spectrum Scale.

Para actualizar a Spectrum Scale en su última versión, primeramente deberemos tener una licencia vigente con IBM y, obviamente, GPFS instalado. En mi caso, teníamos un sistema Linux con kernel 3.12 y GPFS 4.1.1.5. Al actualizar Linux a un kernel 4.12, me encontré con que la partición GPFS no montaba. Después de revisar la web de IBM de arriba a abajo, encontré algún apartado - que no soy capaz de recuperar - en que decía que Spectrum Scale 4.2 no es compatible con kernels 3.x.

Visto lo visto, me descargué los rpms de Spectrum Scale 4.2 y empecé el proceso de actualización.

Primero hay que parar el clúster GPFS:

HOST# mmshutdown Thu Feb 21 12:16:58 CET 2019: mmshutdown: Starting force unmount of GPFS file systems Thu Feb 21 12:17:03 CET 2019: mmshutdown: Shutting down GPFS daemons Shutting down! Unloading modules from /lib/modules/4.12.14-95.6-default/extra mmfsenv: The /lib/modules/4.12.14-95.6-default/extra/mmfslinux.ko kernel extension does not exist. mmfsenv: Unable to verify kernel/module configuration. Thu Feb 21 12:17:06 CET 2019: mmshutdown: Finished

Instalamos los rpms de la nueva versión de GPFS:

HOST# rpm -Uvh gpfs*rpm Preparing... ################################# [100%] Updating / installing... 1:gpfs.base-4.2.3-13 ...

Hacemos un rebuild del GPFS portability layer:

HOST# mmbuildgpl -------------------------------------------------------- mmbuildgpl: Building GPL module begins at Thu Feb 21 12:20:00 CET 2019. -------------------------------------------------------- Verifying Kernel Header... kernel version = 41214095 (41214095006000, 4.12.14-95.6-default, 4.12.14-95.6) module include dir = /lib/modules/4.12.14-95.6-default/build/include module build dir = /lib/modules/4.12.14-95.6-default/build kernel source dir = /usr/src/linux-4.12.14-95.6/include Found valid kernel header file under /lib/modules/4.12.14-95.6-default/build/ include Verifying Compiler... make is present at /usr/bin/make cpp is present at /usr/bin/cpp gcc is present at /usr/bin/gcc g++ is present at /usr/bin/g++ ld is present at /usr/bin/ld Verifying Additional System Headers... Verifying linux-glibc-devel is installed ... Command: /bin/rpm -q linux-glibc-devel The required package linux-glibc-devel is installed make World ... make InstallImages ... -------------------------------------------------------- mmbuildgpl: Building GPL module completed successfully at Thu Feb 21 12:20:24 CET 2019.

Arrancamos GPFS:

HOST# mmstartup Thu Feb 21 12:21:36 CET 2019: mmstartup: Starting GPFS ...

Activamos el autostart del GPFS:

HOST# mmchconfig autoload=yes mmchconfig: Command successfully completed

Hacemos que el servicio arranque automáticamente después de un reinicio:

HOST# systemctl enable gpfs Created symlink from /etc/systemd/system/multi-user.target.wants/gpfs.service to /usr/lib/systemd/system/gpfs.service.

Reiniciamos la máquina y vemos que el filesystem se monta correctamente haciendo un df -h.
En este momento, ya tenemos un sistema Linux con kernel actualizado y clúster Spectrum Scale compatible, a prueba de reinicios.


Fuentes:

https://es.wikipedia.org/wiki/General_Parallel_File_System
https://en.wikipedia.org/wiki/IBM_Spectrum_Scale
https://www.ibm.com/support/knowledgecenter/STXKQY_5.0.0/com.ibm.spectrum.scale.v5r00.doc

Leer más »

Reset del registro de un SUSE Linux Enterprise

Escrito por Blai el 20.2.19

Cómo resetear el código de registro de un SUSE Linux Enterprise Server.



Hoy me ha tocado actualizar un SUSE Linux Enterprise 12 (base, sin ningún Service Pack instalado). Por dependencias de cierto software, he tenido que actualizar el SLES al último Service Pack disponible, así que me he puesto a actualizarlo vía consola:

HOST# zypper migration Executing 'zypper refresh' El repositorio 'SLE-12-SAP-12-0' está actualizado. El repositorio 'SLE-12-SAP-Updates' está actualizado. El repositorio 'SLE-HA12-Pool' está actualizado. El repositorio 'SLE-HA12-Updates' está actualizado. El repositorio 'SLE12-SAP-Pool' está actualizado. El repositorio 'SLES12-Pool' está actualizado. El repositorio 'SLES12-Updates' está actualizado. Todos los repositorios han sido actualizados. Executing 'zypper --no-refresh patch-check --updatestack-only' Obteniendo los datos del repositorio... Leyendo los paquetes instalados... 0 parches necesarios (0 parches de seguridad) Can't get available migrations from server: SUSE::Connect::ApiError: Multiple base products found: ["SUSE Linux Enterprise Server for SAP Applications 12 x86_64", "SUSE Linux Enterprise Server for SAP Applications 12 SP4 x86_64"] '/usr/lib/zypper/commands/zypper-migration' exited with status 1

Me ha llamado la atención que el sistema sea un SUSE Linux Enterprise Server for SAP Applications 12 y el actualizador diga que ha encontrado tanto la versión base como el SP4. Buscando por internet, he visto que haciendo un rollback del registro se soluciona este problema, así que he hecho un rollback:

HOST# SUSEConnect --rollback > Beginning registration rollback. This can take some time... SUSEConnect error: SUSE::Connect::ApiError: The provided Registration Code 'XXXXXXXXXXXXXX' has expired

Veo que el código de registro del sistema ha expirado, así que he re-registrado el sistema con un código de registro vigente y he vuelto a probar de actualizar al Service Pack, pero me he encontrado con el mismo problema de antes (Multiple base products).

Llegados a este punto, he hecho una limpieza de los códigos de registro que el sistema tiene en cache:

HOST# SUSEConnect --cleanup

Este comando, básicamente, elimina el usuario y password con el que el sistema se conecta a scc.suse.com (elimina el contenido de los archivos situados en /etc/zypp/credentials.d).

En este momento el sistema no tenía credenciales de acceso a los repositorios, por lo que lo he registrado con el nuevo código de registro y luego he vuelto a lanzar el proceso de actualización:

HOST# zypper migration Executing 'zypper refresh' Repository 'SLE-12-SAP-12-0' is up to date. Retrieving repository 'SLE-12-SAP-Updates' metadata ...................[done] Building repository 'SLE-12-SAP-Updates' cache ........................[done] Retrieving repository 'SLE-HA12-Pool' metadata ........................[done] Building repository 'SLE-HA12-Pool' cache .............................[done] Retrieving repository 'SLE-HA12-Updates' metadata .....................[done] Building repository 'SLE-HA12-Updates' cache ..........................[done] Retrieving repository 'SLE12-SAP-Pool' metadata .......................[done] Building repository 'SLE12-SAP-Pool' cache ............................[done] Retrieving repository 'SLES12-Pool' metadata ..........................[done] Building repository 'SLES12-Pool' cache ...............................[done] Retrieving repository 'SLES12-Updates' metadata .......................[done] Building repository 'SLES12-Updates' cache ............................[done] All repositories have been refreshed. Executing 'zypper --no-refresh patch-check --updatestack-only' Loading repository data... Reading installed packages... 0 patches needed (0 security patches) Available migrations: 1 | SUSE Linux Enterprise Server for SAP Applications 12 SP3 x86_64 2 | SUSE Linux Enterprise Server for SAP Applications 12 SP2 x86_64 3 | SUSE Linux Enterprise Server for SAP Applications 12 SP1 x86_64 [num/q]:

Ahora sí, ya puedo actualizar el SLES al Service Pack correspondiente.


Fuentes:

https://www.suse.com/support/kb/doc/?id=3303599

Leer más »

Sincronizar tiempo en switch Aruba por SNTP

Escrito por Blai el 13.2.19

Cómo sincronizar el tiempo de un switch Aruba por NTP / SNTP, paso a paso.



Si, por ejemplo, queremos exportar logs de un switch para mandarlos a un SIEM, necesitamos que el tiempo de ese switch esté sincronizado con el resto de equipos de la red. Si el switch no está sincronizado, las marcas de tiempo en los logs no coincidirán y el SIEM no será efectivo.

Para que un switch se sincronice con un servidor de consulta SNTP (Simple Network Time Protocol, versión simplificada de NTP), primero debemos acceder al modo configuración del switch:

# config

Configuramos la sincronización por SNTP:

# timesync sntp

Configuramos SNTP para obtener el tiempo en modo unicast, es decir, desde un servidor:

# sntp unicast

Configuramos el servidor donde se realizarán las consultas. Se pueden configurar hasta 3 servidores:

# sntp server priority 1 192.168.1.1

Configuramos el horario de verano para España:

# time daylight-time-rule middle-europe-and-portugal

Guardamos la configuración para que esté presente si reiniciamos el switch:

# write memory

En el switch...

A continuación, la secuencia entera de comandos tal y como se vería en la terminal de un switch:

SW# config SW(config)# timesync sntp SW(config)# sntp unicast SW(config)# sntp server priority 1 192.168.1.1 SW(config)# time daylight-time-rule ? none alaska continental-us-and-canada middle-europe-and-portugal southern-hemisphere western-europe user-defined SW(config)# SW(config)# SW(config)# time daylight-time-rule middle-europe-and-portugal SW(config)# write memory

Hecho esto, el servicio de consulta SNTP ha quedado configurado en el switch. Podemos comprobar que el switch tiene el mismo tiempo que el resto de la red mediante el comando time:

SW# time Sat Feb 13 11:54:51 2019

También podemos ver la configuración de SNTP en cualquier momento con el comando show sntp:

SW# show sntp SNTP Configuration and Status Time Sync Mode : SNTP SNTP Mode : Unicast Poll Interval (sec) : 720 SNTP Authentication : Disabled Source IP Selection : Outgoing Interface Priority SNTP Server Address   Version OOBM Key-id -------- --------------------- ------- ---- ------- 1        192.168.1.1           3       No   0

Fuentes:

https://community.spiceworks.com/how_to/150465-how-to-configure-hpe-aruba-switches-for-sntp...
http://h22208.www2.hpe.com/eginfolib/networking/docs/switches/K-KA-KB/15-18/5998-8160_ssw...

Leer más »

Cómo obtener un certificado SSL en formato .pfx

Escrito por Blai el 6.2.19

Cómo generar un certificado en formato .pfx para usarlo en un IIS.



Si queremos habilitar el tráfico HTTPS hacia un dominio que apunte a un IIS de un Windows Server, necesitaremos generar primero un certificado en formato .pfx para luego cargarlo en el IIS.

Para generar un certificado SSL en formato .pfx, necesitamos dos archivos:

- certificado.crt: la clave pública de nuestro certificado SSL.
- archivo.key: la clave privada de nuestro certificado SSL.

Estos archivos los tenemos que haber obtenido previamente al crear un certificado SSL con una entidad certificadora. Para unirlos en un .pfx, podemos usar la utilidad openssl.

Tanto si usamos openssl desde Windows como si lo usamos desde Linux, la sintaxis será:

openssl pkcs12 -export -in certificado.crt -inkey archivo.key -out certificado.pfx

Si el certificado está protegido por un password, se nos pedirá que lo introduzcamos:

Enter Export Password: Verifying - Enter Export Password:

Una vez hecho esto, obtendremos el archivo .pfx, listo para ser usado en un IIS.

Leer más »