Category: sysadmin

9May

VMs CentOS con IP fija en Hyper-V

9 May 2020 pbenavent

El escenario es un hipervisor Hyper-V de Microsoft que alberga dos máquinas virtuales CentOS, que por ejemplo es el laboratorio en el que estudias o ensayas antes de hacer cambios en las máquinas productivas.

He hecho dos cambios; configurar en el hipervisor que la máquina virtual (el servidor CentOS) no admita DCHP de otros servidores y fijar una dirección IP en cada una de los servidores virtuales CentOS.

Configurar el hipervisor

Abrimos la configuración del hipervisor, pulsamos sobre “Configuración” de la máquina virtual y en las “Características avanzadas” del “Adaptador de red” marcamos “Habilitar protección DHCP”.

Configurar IP estática en las máquinas virtuales CentOS

Puedes encontrar otras maneras de hacerlo (vía nmcli, interfaz gráfica, etc.) aquí recojo la manera que permite hacerlo con los mínimos recursos, una sesión en la máquina y editando ficheros con VI.

  • Entramos en la máquina y empleamos el usuario “root”
  • Editamos el fichero de nuestro dispositivo de red. En el ejemplo es la tarjeta ethernet así que editamos /etc/sysconfig/network-scripts/ifcfg-eth0
  • Cambiamos la línea: BOOTPROTO=dchp por BOOTPROTO=none
  • Si no está (habitualmente en una configuración existente con dhcp, no estará), añadimos la línea IPADDR=192.168.0.10, con la ip de vuestra elección.Reiniciamos el servicio de red: # systemctl restart network

Confío que pueda resultar de ayuda a alguién.

2May

Postresql en Fedora 32: ¿Cómo actualizar?

2 May 2020 pbenavent

Recién actualizado el equipo de Fedora 31 a Fedora 32 si intentas iniciar el servicio de Postgrqsql ejecutando como root (en adelante, todo lo escrito se ejecuta como root) # systemctl start postgresql da un error.

Como siempre, miramos que dice el log tecleando:
# journalctl -xe

En alguna línea aparece un mensaje similar a este (las negritas son mías):

-- The job identifier is 5061. de maig 01 11:49:13 localhost.localdomain postgresql-check-db-dir[5619]: An old version of the database format was found.
de maig 01 11:49:13 localhost.localdomain postgresql-check-db-dir[5619]: Use 'postgresql-setup --upgrade' to upgrade to version '12'

Aplicamos lo que se recomienda y ejecutamos (el comando forma parte del paquete postgresql-server):
# postgresql-setup --upgrade

La actualización dejará un log en /var/lib/pgsql/upgrade_postgresql.log.
Si todo ha ido como se indica podremos iniciar el servicio con normalidad
# systemctl start postgresql

6Jan

¿Cómo ejecutar sql en batch en Postgresql?

6 Jan 2020 pbenavent

Hemos instalado el RDBMS Postgresql y tenemos una sentencia SQL que queremos ejecutar planificadamente. A modo de ejemplo tomemos una SQL sencilla:
# select count (*) cod_cli from client;

Evitaré utilizar el usuario predeterminado de Postgresql para que se parezca más al mundo real y conectaremos a una BD llamada factura.

La tarea en modo no batch

Consistiría en:

  1. Conectar a la BD tecleando nuestra contraseña :
    psql factura -h 127.0.0.1 -d factura
  2. Ejecutar la sentencia SQL :
    select count (*) cod_cli from client;
    cod_cli
    ---------
    49
    (1 fila)

La tarea en modo batch

Lanzaremos un shell script que se conecta a la BD, este shell script llama a un fichero query.sql que solo contiene una línea:
select count (*) cod_cli from client;

El shell script contiene dos líneas:

#!/bin/bash
psql factura -h 127.0.0.1 -d factura -f query.sql

Cómo hacer que el batch SQL no pida contraseña

La manera de que evitar que nos pida contraseña es crear un fichero .pgpass en nuestro directorio $HOME

El fichero contendrá una línea por cada acceso a BD que queramos tener siguiendo el formato:
nombre de host: puerto: base de datos: nombre de usuario: contraseña

El uso de este fichero está recogido en la -buena- documentación sobre .pgaccess en Postgresql.

30May

La BIOS no reconoce la tabla de particiones

30 May 2019 pbenavent

El problema: actualizo de Fedora 29 a 30 y al reiniciar el sistema aparece un mensaje de la BIOS diciendo que no reconoce la tabla de particiones. (Podía haber ocurrido en cualquier otra circunstacia.)
La solución: está profusamente documentada por Internet. Se trata de tres pasos básicamente;

  1. arrancar el sistema desde una distribución live (no es importante cuál, la que prefieras)
  2. montar el sistema de ficheros de tus discos duros y hacer chroot a tu Linux
  3. reinstalar grub y reiniciar

Y con más detalle:
Primero: Existen distribuciones Linux o CD de rescate orientados a esta tarea, por ejemplo System rescue CD. Un administrador de sistemas no siempre tiene el tiempo o las ganas de utilizarlas, o confía más en sus capacidades.
En el caso de seguir por esta opción, se toma cualquier distribución live y se entra en la BIOS e indicamos en el orden de arranque que inicie el sistema por el USB, en donde dejaremos la ISO live. En el caso real que me llevó a esto, no utilice una live, tomé una CentOS Minimal que tenía a mano y elegí iniciar en rescue mode. Aparecerá una pantalla como la que sigue y elegimos la opción 1:

CentOS in rescue mode

Segundo: El arranque elegido nos permite entrar en nuestro Linux haciendo cd /mnt/sysimage/ y si allí está nuestra instalación, entonces hacemos chroot /mnt/sysimage para convertirlo en nuestro sistema raiz.

Reinstalamos grub, en el caso del ejemplo era grub2; grub2-install –boot-directory=/boot/ –recheck /dev/sda lo que actualizará la tabla de particiones dañada y reinstalará GRUB en el MBR. Dañado, en nuestro caso, por un reinicio que acabó mal tras actualizar la distribución .

Tercero: reiniciamos el sistema y dejamos que SELinux vuelva a etiquetar el sistema de ficheros (lamento la calidad de la foto, se hizo con prisas para documentarlo). Se inició el sistema de nuevo, el MBR reconoció la tabla de particiones y todo fue bien,

SeLinux relabeling after grub2 reinstallation